Obfuscation #2: Playing entrypoint hide & seek game with dyld

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). [Read More]

A little more fun with Mach-O headers: adding and spoofing a constructor

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. [Read More]

Anti-disassembly & obfuscation #1: Apple doesn’t follow their own Mach-O specifications?

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. [Read More]

Anti-debug trick #1: Abusing Mach-O to crash GDB

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: [Read More]

We have a crackme winner!!!

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. [Read More]

My first crackme... from hell, I hope :-)

My first OS X crackme is finally ready, after a long wait and some unnecessary teasing. Ready means that it is good enough to be released and hopefully give you some trouble to reverse and crack it. I still have many more ideas to implement and some areas could be more polished – it was time to take an executive decision and freeze the code. There are some assumptions (economists love this term) due to the crackme nature – if it was an application more fun games could be played. [Read More]

Some comments about plugin-alliance.com protection...

It sucks, sort of! Let me rewind to the beginning. I was very curious about this one because it was announced with great fanfare. I interpreted it as something more robust than it really is – maybe I was over enthusiastic with the “we know this will be cracked someday” sentence. Some brief comments: There are no anti-debug measures. There are no binary integrity protections – patch whatever you want! [Read More]

Evil iTunes Plugins from Hell

Let me start this with some sort of disclaimer. I do not support/condone stealing credit card information, logins, and other personal information. Disclosing security issues is always a double edge sword and a tricky problem with some politics in the mix. This problem was reported almost 3 months ago to Apple. It’s still not fixed after, at least, two iTunes releases. I perfectly understand the business side of fixing bugs and how business most of the times must come first (I have experience in critical environments where these type of problems can cost a lot of money and bad publicity). [Read More]

Poking around Sentinel HASP Envelope for Mac OS X :-)

I am a sucker for all OS X anti-debug promises I can find. There are so few tricks available that I am always curious to see if there is something new in town. So I started poking around Sentinel HASP Envelope for OS X to see what they use to fool my dear debuggers. Well, we have the usual ptrace and sysctl tricks, a check for a kernel debugger (via kernel boot arguments), and, to my (good) surprise, one of the anti-debug tricks I discovered a few months ago. [Read More]

A small rant about dongles: the developer who can’t correctly implement a HASP!

Dongles always had something mistique about them. Before this new age of packers, cryptors, etc, they were the top target to beat. In practice, that fame was only real in a reduced set of applications that correctly implemented the dongle. Most dongle-protected software feature bad implementations. Developers don’t spend enough time in this area or think that it’s the magic bullet to solve their problems. [Read More]