Processes in IOS

I had this idea, that maybe the reason I was getting alot of false positives from my memcheck tool which claimed memory writes were happening outside of allocated blocks, and the writes werent part of malloc, free or IncMallocRefCnt was that maybe a process like the ‘Chunk Manager’ was working in the background making those modifications.

CreateThread which Lynn documented in his Cisco exploitation, creates a new process (or really thread) and returns the process ID (lynn documents this as returning void *).  FX documents in his phrack article, that there exists a ‘Process Array’ that contains an array of pointers to Process Control Blocks.  You can see the allocation by using ‘show mem’ in IOS, or intercepting the malloc calls as I do in Dynamips.

The Process Array is a block of 1032 bytes, the first 4 bytes appear to be 0, and i suspect this field might actually be a pointer to the next block if the current block becomes full of processes.  The next 4 bytes are the number of active processes, or maybe the highest allocated pid.  The remaining 1024 bytes, is an array of 32 bit words pointing to process control blocks (pcb’s).  pid 1 starts at the beginning of this array (ie, 8 bytes in from the initial block).  A 0 for the pcb pointer indicates not in use, seemingly.  I think 256 processes seems very small, so back to that first word being a pointer to the next Process Array, but I would need to confirm that.

A PCB contains a few things, as far as I can tell, it contains a pointer to the stack base, the next word contains according to FX the stack pointer, the next word I think was the entry point of the thread (from memory.. I will have to re-run my code to verify this again, but I commented out the memory dumps for now).  The next fields I think, but not 100% sure contain saved registers.  At least the return address seems to match with what I believe is a context switch function I found in IDA, or rather, the return address points to the return address after a yield/context switch.

From looking at this context switch function, which I dont fully follow its working with the stack pointer, it uses a  global variable which I think is a pointer to the current PCB.  Looking at memory writes to this value, it certainly appears to use PCB’s that CreateThread creates.

There also appears to be another PCB in use (assuming that global currentPCB variable is correct), which I think represents the init process or pid 0.  Not too sure about that, but it makes the most sense.  It seems that a process can yield to the init process which can perform work.. at least, when i’m checking what the current process is when one of the memcheck false positives occur (like i talked about in the first paragraph). 9 times out of 10 its coming from the same unknown PCB.

After booting, I’m getting about 9149 false positives from what I think is the init process, and around 855 false positives coming from around 13 other processes.  These other processes seem random, one example being RADIUS INITCONFIG.  There must be one or mare functions called by these processes that modify the heap structures, but it doesn’t seem to be all at the hands of the Chunk Manager process..

Back to the drawing board..  having to do so much reversing of IOS is really slowing me done.  In the first couple days of working on the symbolic execution, I wrote nearly 3000 lines of code to do the constraint generation from parsing MIPS asm.. But in the past week, I’ve barely written 300 lines, and it’s all wild stabbing in the dark.