I’ve been decompiling Cisco IOS’s malloc() in the past day or two, which is in MIPS asm, which I only learnt a couple of weeks ago, which is going really slow.
It appears, that if a global variable is set, and the size of the memory requrested is less than or equal to 128 bytes, plus a couple other minor requirements, then a new codepath in malloc is followed. This path I presume is part of the malloc fragment logic. I decompiled enough to see the use of a couple arrays maintaing various sizes for all allocations up to 128.
So I did a little bit of googling for IOS and malloc and 128 bytes, and found that there exists a ‘chunk manager’, which describes pretty much exactly what I’ve been seeing this past week! The chunk manager uses a larger allocation to house smaller allocations. You can view information on the chunks with ‘show chunk’. If only I knew about this a week ago..
Now there are ALOT of chunks being used, much more than I’m detecting as anomolies in my malloc interception. There must be a seperate API, to access the chunk manager. I do suspect however, that even using plain malloc, the chunk manager can be called when the above prereqesuites are met (the size being <= 128 bytes etc). This is probably there to avoid the overhead incurred when allocating small buffers, and also to avoid fragmentation.
I suppose I should really try to determine the API for the chunk manager and find the necessary functions in the IOS image.. I can’t use the same method I used to find malloc() which was by intercepting memory writes with the chunk header magic. But I do know some addresses from the chunk manager. It might end up easier to continue decompiling and follow malloc through to the chunk manager code (which I was thinking I had.. but hasn’t turned out to be fruitful yet).
Anyway.. thats all for now