That codepath in malloc() for allocations less than or equal to 128 bytes appears to be documented as ‘MallocLite’, which first appears in IOS 12.3. The documentation claims it reduces chunk overhead for small allocations, can be examined with the ‘show chunk’ command, and can even be disabled.
That global variable I was talking about for the codepath to be executed, probably is that malloc lite global configuration. It doesn’t actually become active until somewhat late in bootup. Looking at the addresses from ‘show chunk’ with titles of MallocLite, the recursive malloc call which allocates a 64k buffer is the same as the MallocLite addresses.
I pretty much gave up tonight trying to reverse the MallocLite code, and decided that I would just make a special case for recursive calls to Malloc. Remember that this 64k buffer is used to house the buffers returned by malloc, using the fragmentation logic I’ve been rambling about for days.
So the trick with IOS malloc() is to take into account MallocLite (kinda hacky by identifying recursive calls to malloc), and also equally important is to note that memory allocations in IOS are reference counted. So make sure to intercept IncRefCnt().
I will now probably ditch reversing anymore of the MallocLite code for now, as it has driven me insane over the past few days. Next I will probably implement the checks on memory reads/writes which is easy enough, but last time I uncommented that code, I got what seemed like a TON of false positives.. Without the chunk manager intercpeted, alot of heap corruption can be missed, but for now IT’LL DO🙂