Load command 9 cmd LC_UNIXTHREAD cmdsize 80 flavor i386_THREAD_STATE count i386_THREAD_STATE_COUNT eax 0x00000000 ebx 0x00000000 ecx 0x00000000 edx 0x00000000 edi 0x00000000 esi 0x00000000 ebp 0x00000000 esp 0x00000000 ss 0x00000000 eflags 0x00000000 eip 0x186b2662 cs 0x00000000 ds 0x00000000 es 0x00000000 fs 0x00000000 gs 0x00000000 This is from the header of my crackme and that entrypoint is a random value. When the entrypoint is the original and valid one, IDA is more or less smart and uses that information if the headers are mangled (just the offsets)....

The fun with Mach-O headers continues, this time with a “simple” trick to inject a new constructor and “spoofing” its location. It does not work in iOS (non-jb) and it will be killed if Apple decides to do things right and respect the specification, so let’s disclose it! Might be useful for some wannabe malware writer. I bet that OS X malware analysts are demanding some fun into their “boring” work time....

I smile when I think about this “feature”! I liked it so much that things got out of control and I wrote a crackme to show it. It happens because Apple doesn’t follow their own documentation/specification and the reversing tools of the trade do. The result is that IDA terminates, disassemblers output the wrong disassembly, strings are messed up, LLDB disassembles the wrong code (not GDB), class-dump will fail, and the reverser looks at a weird Mach-O header....

I developed this funny trick while trying to find a solution for a problem in a project. It is pretty easy to implement and fun. The trick consists in abusing the offset field in the dylib_command and pointing it to somewhere else. From the Mach-O File Format Reference document, the command structures are: struct dylib_command { uint_32 cmd; uint_32 cmdsize; struct dylib dylib; } struct dylib { union lc_str name; uint_32 timestamp; uint_32 current_version; uint_32 compatibility_version; } union lc_str { uint32_t offset; #ifndef __LP64__ char *ptr; #endif } The definition of the offset field is:...

This Sunday I received a valid keygen solution for my crackme. Congratulations to the reverser who wishes to remain anonymous. When the solution is available our brain stops thinking and goes into lazy mode. So, my question is when do you want to have me starting to explain some of the tricks used in that crackme? Right now? Next week? In a month? I did some questions to the keygen author to better understand his attack....