Articles by fG!

You are currently browsing fG!’s articles.

Very small update…

June 8, 2010 in Uncategorized | 6 comments

Hi!

I just updated the crackmes with #5 from MSJ challenge and added a new tool for encrypting/decrypting apple encrypted binaries. I had planned to do this tool but it’s great that someone did it first! It’s good to see people developing tools for OS X, even if they are very simple. Thank you to the author and to the guy who pointed me to it and sent the crackme ;-)

My free time is back to very restricted and so I have been advancing very slowly on some projects. I have yet to fix onyx to 64bits and to release an update to ptool (fixed some bugs, added more output information, and added a simple option to modify the entrypoint).

Anyway, if you find more tools and crackmes feel free to send them to me. I love to collect this stuff and I can centralize that information (no monetary reasons since I don’t have any banners ;-) . Btw the original url for the encryptor/decryptor is here.

As usual, have fun! Keep learning but don’t spread your cracks ;-)
fG!

Onyx the Black Cat v0.4 for Snow Leopard

May 24, 2010 in Tools | 16 comments

I had this one working for a long time but I hadn’t released it because I was trying to hijack fork and vfork calls. My objective was to introduce an int3 so I could attach the debugger to a selected process. At that time I suspected that VLOK was forking and I couldn’t debug the new process since follow on fork gdb function isn’t implemented in OS X (so this looks like a good idea for a protection ;-) ). My idea was to inject an int3 or pause the new process so I could attach another gdb to it. Those attempts failed and one of these days I need to get back to the problem and think better about it (if you have a solution for how to do it in the kernel module feel free to contribute!!!).

The method to grab sysent address changed again in Snow Leopard and for now there is an hardcoded address. The method is to find nsysent address (nm /mach_kernel | grep nsysent) and then subtract 0×2850 from it. Matthie Suiche described a method in the paper ADVANCED MAC OS X PHYSICAL MEMORY ANALYSIS.
“Under Mac OS X Snow Leopard (10.6), we have to proceed with a different methodology. First, we have to retrieve the value of nsysent variable, then we multiply its value with the size of sysent structure, and then we subtract this value to nsysent offset to obtain the offset of sysent table.”

I would prefer a more elegant solution to this :-)

The structures had to change and more stuff had to be ripped off from xnu kernel headers. They are still incomplete but what is there is enough for current purposes.

Here it is:
onyx-the-black-cat-v0.4.tgz (SHA1(onyx-the-black-cat-v0.4.tgz)= 5dff3c4a9246f2886b470aa0ab60b5e237ca3659)

Have fun,
fG!

OS X Crackmes

May 21, 2010 in Mac Reversing | 3 comments

Hello,

I have just added a page to collect crackmes for OS X. I have added the ones that I already had and some recommended from user comments. Since corruptfire.com seems down I cannot retrieve the other ones they had.

If you have more crackmes please mail them to me so I can add them to the page. It would be nice to start having more crackmes developed for OS X.

fG!

Gdbinit v7.3

April 16, 2010 in Tools | 20 comments

I was bored and decided to fix gdbinit to support 64bits binaries. I had tried it before but the solution was a piece of crap (not that this one is much better). I was testing the registers to see if the binary was 32 or 64bits. Now there is a default setting to 32bits (change it if you want to default to 64bits) and two commands, 32bits and 64bits to change between the two types of targets. If you have 32bits by default and debug a 64bits target, the first time gdb breaks you will get an error; just issue the 64bits command to change and you can issue the context command to get the correct display and continue your debug session. I remember I couldn’t find a better way to detect the type of binary inside gdbinit, since there’s no support for regex and all that kind of tools. If you have an elegant method feel free to tell me about or patch this version and send it back :-)

I have patched too the 64bits mode to have available the 32 and 16bits registers versions. The ObjectiveC messages display and the stepo command still need to be fixed to 64bits. The calls are different in 64bits so I need to rework that part. Everything else seems to be working; please report if not!

Can’t remember anything else to say about this one.
As usual, have fun!
fG!

Grab it here: gdbinit73 (SHA1(gdbinit73)= c4da85f3ba6e8cfa311fb63c2ab5d606df6b837c)

reverse.put.as is back in a new format…

April 9, 2010 in Mac Reversing | 5 comments

I have been thinking about this and how to get this blog back to life. My free time has been almost zero but I miss the motivation to put my brain to tinker and create new things to publish, because reversing and everything around it sometimes is a great relaxing activity for me.

The last couple of days I had to revisit one of my favourite books ever, where it is written that “DO NOT COVET YOUR IDEAS: Give away everything you know, and more will come back to you.”. This was my original spirit and I miss it, even if the world is full of idiots who just want personal profit.

Since I don’t have so much time and I always wanted others to contribute, I’m searching for people who want to contribute and have a writing place at this blog. If people really miss this and find it a source of knowledge and value then they should contribute to it because it’s the only way to advance OS X reversing knowledge. Drop me an email so we can talk about it, if you are interested.

The new format will not have anything related to cracking and reversing protections, unless it’s about very specific bits that are really important and advance the general knowledge. I want to focus more on tools and new tricks, malware, packers and all that stuff. I know it will always have some impact into the protections world but if idiots want to release stuff then it is their problem. The latest news about a global treaty for copyright protections and infrigements should change the game.

So let’s see if this can go forward or not. If yes then I will get all the content back (non cracking related) and do my best to get this ship sailing once again.

fG!

A new util to process Mach-O binaries information (or a replacement to otool -l)

January 5, 2010 in Tools | 2 comments

For a long time I have been annoyed by the information displayed by otool -l because it mixes hexadecimal with decimal information. For example, offsets are displayed in decimal and relative to the cpu architecture in the fat binary. So I had to convert and calculate things by hand everytime I wanted to peek or modify something at the hex editor. HT allows to see this information and even edit it, but it doesn’t support fat binaries (and I have to start it under iTerm to support the keyboard shortcuts – I didn’t want to waste time researching to get it to work with Terminal.app).
Then a reader sent me a new protection (a packer) and I started having some fun with it and again I needed a tool to display all the offsets so I could try some crazy approach to the target. Since I’m on short vacations from the MBA and I miss the adrenalin of having all my time occupied I rewrote otool -l option in Perl (yeah lots of free time to reinvent the wheel and learn something ehehheh). So ptool.pl is born ! It will process x86, x86_64 and ppc binaries and dump all the information from the mach-o header, together with the correct offset location inside the binary. This way it is very easy to navigate inside the hex editor.
I’m thinking about converting it into a full mach-o editor using Perl+ncurses. I would love to have a nice GUI in Cocoa but I don’t have time to mess with Objective-C for now (and I suck at object-oriented languages, more than the other languages ;-) ). I’m thinking too to modify otool and fix that damn display and add some other features, like disassembling any chosen offset of the binary file (it’s helpful some times and it would remove the need for an external disassembler like this one – my idea is to integrate it into otool or use otool own disassembler). It will depend on time and motivation. I can’t reverse the protection if I take all the time to write and fix tools.

So here it is version 1.0 of ptool:
ptool1.0.zip (SHA1(ptool1.0.zip)= be754c87fcfbd4ee43d47aeba197a1f20c81e296)

If you find any bug or have any suggestion feel free to leave a comment or email.

Btw, the target protection is called VLOK and is available here (updates are protected so you can use them as targets). I’m not thinking about publishing full details and code but a general analysis and description of the tricks and its design. I still believe in full disclosure but the legal and business sides are more complex and the world isn’t always as we want (all that and a 500 pages book on Business Ethics that I had to read for an exam ;-) ). And what’s the fun of having everything cooked for you ? If you want to learn you have to think and practice !

Have fun!
fG!

Update: If you want to recompile otool you need to follow the gdb guide and then do the following:

  • Package name is cctools
  • First use darwinbuild -nochroot cctools
  • Compilation should fail with some include errors
  • Edit the following files:
  • Build10C540/BuildRoot/SourceCache/cctools/cctools-750/Makefile, search for -DTRIE_SUPPORT and remove it (you can leave echo “”)
  • Build10C540/BuildRoot/SourceCache/cctools/cctools-750/misc/Makefile and remove the options for LTO and TRIE
  • Build10C540/BuildRoot/SourceCache/cctools/cctools-750/libstuff/Makefile and remove the options for LTO
  • Recompile again, this time with darwinbuild -nochroot -nosource cctools
  • Wait and enjoy the recompiled otool. Now you can modify its source code :-)
  • Otool seems to work fine without those includes so hell with them !

« Older entries