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. I hope I haven’t missed any simple hole/bug. It’s not an easy task to build something that you are constantly cracking and thinking about ways to defeat it. I haven’t cracked it myself but I have a few neat ideas on how to approach it. The real interest is to read and learn about your approaches and solutions.

This crackme started as a PoC for some tricks I found while working on a project. The original idea was to create something to demonstrate the issues but it got out of control and evolved into a crackme (I hate to lose and love a good challenge!). Two issues were sort of disclosed during an interview with the fruity company since my interest with overflows is almost 0 ;-). The impact of this is that the crackme is certified to run on OS X 10.6.8 up to 10.7.2. Newer Lion releases is a question mark. It is 32bits only and has no ASLR, due to coding time restrictions. As a matter of fact, I started the PoC with ASLR support, which poses no big problems to the concepts behind this crackme.
The code does nothing malicious or destructive so it’s safe to run! It is only hostile to your reversing efforts 😉

The challenge is to find the valid name/key pair and keygen it if you wish so. Use the “-h” argument for help. The crackme will accept the name and key via command line parameters, to make your life easier. Run with no parameters for the usual crackme questions.
I will disclose details as soon a solution is sent to me by mail or comment. If you wish to remain anonymous or keep the solution private just tell me.

Probably forgetting about some stuff so this post might be updated soon.

There are two or three little things taken from other people and proper credit will be given in due time.

This should be an advanced crackme with some unusual stuff in OS X (at least for me :-)). I hope you enjoy reversing it and learn/develop some new tricks.
Hint: it is quite amusing that Apple doesn’t follow its own specifications 😉

Have fun,
fG!

fg_crackme_nr1.gz
SHA256(fg_crackme_nr1.gz)= 9116e336f3979c1c68e63bec2868d193b6ccbf031e3521bdcdb7e14034c3c636

8 thoughts on “My first crackme… from hell, I hope :-)

  1. I’m pretty impressed that this thing runs ahahahah
    After long time without reversing this should be pretty fun, obviously standard tools don’t work work with this, had to attach gdb to even take a glimpse of what’s happening 😀 don’t know if it’s better to try to fix the current binary or write a disassembler ad hoc Now I know what to do after the exam tomorrow! And let me tell you, nice functions names you chose 🙂

  2. And I’m in a pickle, I’m running Mac OS X 10.5.8 and the crackme doesn’t sadly run, all I get is:

    dyld: unknown required load command 0x80000022
    Trace/BPT trap

    But I guess that’s the part of the crackme. For now I’m surprised that you can do such weird things with sections and I’m trying to figure out how to fix this, maybe once I get my OS updated I will have a better look at it.

    1. That command (LC_DYLD_INFO_ONLY) is most probably introduced in Snow Leopard so Leopard dyld doesn’t recognize it and refuses to run 🙁
      fG!

  3. Interesting but disappointingly seems to be mainly security through obscurity. Otx, Hopper, IDA, strings, and otool don’t initially work on the binary but attaching in gdb and disassembling with x/25i or so does. Then it just comes down to breaking the assembly up and working though it. To increase difficulty with the path you’re taking you could always have the process fork itself to stop gdb from attaching. Then you’d force people to fix the binary and analyze it statically.

    1. In the limit everything is security through obscurity and that was really the objective here.
      Your assumptions are oversimplified and the attach approach doesn’t imply a critical hole.
      I don’t want it to be uncrackable, I want people to learn and submit their approaches so everyone can benefit.

  4. (gdb) x/4i 0x20a5
    0x20a5 : pop %edx
    0x20a6 : add $0x7,%edx
    0x20a9 : jmp 0x20aa
    0x20ab : loop 0x20fd
    (gdb) x/2i 0x20aa
    0x20aa : jmp *%edx
    0x20ac : push %eax

    That is so mean. 🙂 Did you invent this trick?

  5. Very nice “heisenberg” crackme!
    My arsenal: VMware + IDA + mac_server + attach to process.
    This python script for IDA for deobfuscate string:
    p = ScreenEA()
    s = []
    while(Byte(p) == 0xc6):
    s.append(chr(Byte(p+3)))
    p = p + 4
    p = p + 4
    i = 0
    while(Byte(p) == 0x83):
    s[i] = chr(ord(s[i]) ^ Byte(p+2))
    p = p + 10
    i = i + 1
    MakeComm(ScreenEA(), ”.join(s))

Leave a Reply

Your email address will not be published. Required fields are marked *