MemoryMapDB's nameBlockMap and DSC's "Add to Program"

[nmggithub]

As of writing, MemoryMapDB uses a HashMap called nameBlockMap, to map strings to MemoryBlock's that have that name. It seems to be used as a cache for the getBlock method.

This is a nice caching measure, but it seems like it may run into issues where multiple blocks have the same name. This is definitely the case with Mach-O binaries extracted from a dyld shared cache, especially if a user has performed an "Add to Program" operation, adding another Mach-O into the program (as they share block names). This is potentially exacerbated now that Mach-O's like libobjc are included by default.

I don't personally understand the way that the sorted list of blocks that the getBlockMethod traverses works. But regardless, it seems this will always grab the first instance.

If the list of blocks is always sorted with the original binary at beginning, this might not be an issue (as that's likely the intended target of a getBlock call anyway). However, is that the case? Or is it sorted by memory address? If it's the latter, then a program.memory.getBlock("__const") call might return the block that's first in memory, rather than the one from the original binary.

[nmggithub]

Ok, after digging deeper, it does seem to be sorted based on memory address. I'm not entirely sure how Apple maps their libraries together, but I do know that if I extract libsystem_blocks.dylib from the cache on my machine, program.memory.getBlock("__const") will return the __const section from the automatically-included libobjc, not libsystem_blocks.dylib.

[ryanmkurtz]

Memory.getBlock(String) always returning one block seems problematic. While there is no enforcement, loaders we develop will typically set a block's source field to where it originated from...that's what the MachoLoader does. It would be nice if you could look up a block by both its name and source. For now, you'd have to write your own helper method to achieve that (using Memory.getBlocks() and looping through).