Articles by fG!

You are currently browsing fG!’s articles.

Some comments about plugin-alliance.com protection…

January 9, 2012 in Mac Reversing | 2 comments

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!
- It has an annoying constant polling for the license file (I observed at least 5 hits per second – what a meaningless waste of cpu!). This can be patched without any problems :-)
- If you patch the polling, the program continues to work. What this means? License is read once and sets something somewhere (you should know what is the real meaning of this). This is bad, real bad!
- Class-dump is able to extract the license structure, although the fields sequence seems incorrect.
- It has a buffer overflow at getenv – doesn’t check the size of HOME environment variable before strcpy it to an allocated buffer. Bang! It is just a detail. Maybe that something somewhere can be taken care with a “proper” HOME variable – that would be a cool crack (never saw this against a real target).

Audio scene groups usually have great crackers so this will be a nice feast to them. Alliance guys, you must raise your efforts, seriously!

You can find below the source code to a license file decryptor, in case you are curious about its format.
I thought a while about this and I really think there is NO great harm in releasing this code. It doesn’t crack anything and the decrypted version of the license is too damn easy to dump from memory.
Alliance, if you are reading this and disagree please tell me.

This was sort of fun (I am disappointed!) and it’s time to move to more interesting things.
If you are using this protection to protect your assets, make some pressure to be improved!

Enjoy,
fG!

decrypt_pa_licensefilev0.2.c.gz
SHA256(decrypt_pa_licensefilev0.2.c.gz)= 071458084a22f91b126389490737e33bb3a6f0d047e205545b0c36f21c8a7ba0

Update:
I noticed (again) that what I call 1st stage in the decryption code is just decoding of a binary encoding format (modified base64?). I had this in mind the first time I approached this but got sick in between and never remembered this again. I was closing the hex-editor and my brain connected the dots again. It went into plain disassembly reverse without caring of what was behind (not that I care much now). Just a lame detail, too late in the night LOL :-)

Merry Christmas, Happy New Year and some notes…

December 18, 2011 in Uncategorized | 2 comments

Merry Christmas or whatever applies or not to your particular case, and much more important, Happy New Year!
The world is messed up and it will probably get worse in 2012. Cheer up and be positive!

Let me write some quick notes about some stuff:

- Take a look at Snare’s presentation about OS X Rootkits! Available at Papers section or here.
- Check out the fantastic Hopper disassembler and decompiler here or at the Mac App Store. It’s cheap and it’s great! I was quite surprised by its quality since such tool involves quite an amount of work!
- I have made a quick patch for MachOView to support the LC_ENCRYPTION_INFO command. Grab it here. Applies to the latest SVN version.
- The papers section is updated and better organized. It’s quite a collection!
- @DarkLapu has a new blog featuring a few Mac malware posts. Check it out here – great to see more work being published.
I did some analysis into Flashback-G but I have to ask to the person who submitted the sample if I can write about it. It has what I think will be (“cool”) features to be implemented in the near future. By the way, Flashback author I would love to have a talk with you. My PGP key is in the About page, total confidentiality guaranteed! I am just curious about some things in your code ;-)
- @hellais started a sandbox profiles project! The url is https://github.com/hellais/Buckle-Up. Glad to see new stuff coming up.
- Hum I think I am forgetting something else…

I have been working in some interesting stuff related to anti-debugging, rootkits and malware. Maybe I will try to make a presentation of this and submit it somewhere or just publish it here. In 2012 I have to (well, I should) move my ass into a job and stop my damn busy and too fun unemployment status, so let’s see where this ends.

Happy New Year! In crisis lies opportunity.
Live a long and prosper life, and more important, enjoy it!

fG!

Evil iTunes Plugins from Hell

November 22, 2011 in Mac Reversing | 5 comments

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).
But it also seems that governments and so on are exploiting security issues to do all kind of stuff on citizens. This is another interesting case (Google translate it). 3 months is more than enough to take a damn decision on this issue. If not, I maybe did a mistake. Live & learn :-)
So let’s start it…

The following problem seems like a pretty “lame” security issue with iTunes. I came across with it when one reader posted a comment about creating an iTunes plugin to have the same m3u removal functionality I did in my loader (original post here). My idea was to patch iTunes memory on the fly and remove the new m3u thing. To my surprise, this is a pretty easy thing to do with a plugin! Plugins are loaded into iTunes memory space (they are bundles/libraries) and can have total control over its memory. How? By using mach_task_self to acquire a port right (we don’t need any special/elevated permissions since the plugin shares the same permissions of iTunes) and then use mach_vm_write to patch whatever we want.

So how can we use this for devilish things? Well, we can capture those iTunes logins and credit card information. One alternative is to patch and redirect the code that asks for this information, another one is to make the plugin a small debugger, installing a breakpoint into the interesting place and retrieving the information.  Or we could maybe steal information from iTunes backups and upload it somewhere?

It’s not the easiest attack vector but it’s a damn easy one. If we have governments sponsoring backdoors installation then any vector is a good vector.

I did not created the PoC for stealing the iTunes account information. I found where to intercept that information and stopped there. Not interested in creating such thing. I will release the code for the m3u removal plugin (maybe tomorrow). Just need to clean some things – last time I used it was 3 months ago.

And that’s it! A simple security issue by design. Now go patch it Apple, close the damn holes :-)

Have fun,
fG!

Update:

Here’s the code. Check VisualPluginHandler in iTunesPlugIn.cpp, which handles the events (iTunes will be patched when plugin is loaded, unpatched if configuration is called, and patched again if show visualizer is called). The juice of the patching is located at hack.cpp. The mach-o headers information is grabbed from memory because of ASLR in Lion. Final step is to find the cstrings location and patch it.
I haven’t tested this with 64bits iTunes. Based on sample code provided by Apple’s Technical Note 2016. Some unnecessary code is still present and plugin could be improved by adding a configuration panel to enable/disable it. Maybe one of these days :-)

Disable_m3u_v0.1.zip
SHA256(Disable_m3u_v0.1.zip)= 7583d483ecba7dff93b958245e6801000251938a4f87e2dc71c58a4d9a7ee739

Gdbinit v7.4.3

November 4, 2011 in Tools | 2 comments

A small update to gdbinit. Many thanks to snare and Plouj for their reports :-)

Here is the changelog:

Version 7.4.3 (04/11/2011)
- Modified “hexdump” command to support a variable number of lines (optional parameter).
- Removed restrictions on type of addresses used in the “dd” command.
- Modified the assemble command to support 64bits – You will need to recompile nasm since the version shipped with OS X doesn’t supports 64bits (www.nasm.us).
Assumes that the new binary is installed at /usr/local/bin – modify the variable at the top if you need so.
It will assemble based on the target arch being debugged. If you want to use gdb for a quick asm just use the 32bits or 64bits commands to set your target.
- Added “asm” command – it’s a shortcut to the “assemble” command.
- Added configuration variable for colorized prompt. Plouj reported some issues with Ubuntu’s gdb 7.2 if prompt is colorized.

Enjoy!
fG!

gdbinit743.gz
SHA256(gdbinit743.gz)= 18931eac613917b4ef63be7708dfa052e7a0edb629c7d829705e231cf2154451

The latest version can always be found here.

Display Mach-O headers plugin for IDA

November 3, 2011 in Tools | 8 comments

This is a simple plugin to display mach-o headers inside IDA, something I miss from time to time. It was a good excuse to mess a little with IDA SDK.
It’s not quite what I had initially in mind but it does the job. I was thinking about something more sophisticated such as allow to display only the segment you wanted and so on. Now I am not sure if it’s worth the effort :-)

Tested with IDA 6.x in OS X and Windows, 32 and 64 bits. Included are Makefile and XCode project for OS X, and Windows DevC++ projects for 32 and 64 bits.

Give a look to the README file for extra information. Too tired and too late to write a long post :-)

Yeah, the code isn’t beautiful! Anyway I hope it’s useful for you.

Have fun,
fG!

MachOPlugin_v0.2.zip
SHA256(MachOPlugin_v0.2.zip)= aea01470a92a94a67ae29e6eba659b195829e599165265f8dd0fdc80333bc5a7

MachOPlugin_v0.3.zip
SHA256(MachOPlugin_v0.3.zip)= 73ea3471856027d7882b3b89986209f633bd19bc8b2159da7346a3e89c34fa4d

Also available at github.

Update:
v0.3 fixes some bugs/missing stuff and implements a workaround to IDA crashing.

IDA BUGS:
I seem to have found a few bugs in IDA QT GUI implementation.
The most annoying one is that the plugin will crash IDA if called more than once in the same session. What happens is that IDA happilly keeps opening new custom views even if there is code trying to prevent it.
The create_tform() function from the SDK should return a new handle if there is already a form with the same caption. Well this works with the old GUI but fails with the new one (QT). The same happens with find_tform. In this case, it never returns NULL if there’s no form (which is the expected behavior).
I implemented a small workaround, which is to add a number to the form caption. This way each call to the plugin will generate a new custom view and not crash IDA. Not pretty but the other workarounds I tried failed since I can’t find if form exists or not.

The other bugs are described in the README file. If you know a better workaround for this one please tell me :-)

How to create IDA C/C++ plugins with XCode

October 31, 2011 in Tips | No comments

This is just a simple post about using XCode to create IDA C/C++ plugins. Nothing fancy here :-)
For great references about IDA SDK plugin writing check out The IDA Pro Book by Chris Eagle and binarypool.com tutorial.

XCode 3.2.6 is the reference. The resulting project loads and compiles without any issues into XCode 4. Why not doing this in 4? Human brain is misterious (3.x still loads by default on my system :-X).

Let’s start…
Load XCode and start a New Project. Use the BSD C Library template, Dynamic type (found in the Framework & Library group). Choose whatever name you want for your plugin (we can rename the binary later).

Next step is to edit project settings. Go to “Project” menu, “Edit Project Settings”. Select the “Build” settings and go to the “Linking” options group. At the “Other Linker Flags” insert “-lida”. Next go to “Search Paths” options group. You need to set the path to the IDA SDK header files (the idasdk/include folder) in the “Header Search Paths” and the path to IDA library (libida.dylib). You can copy this from IDA application into the SDK folder or just point it to the IDA application folder. It’s your call!

The last step here is to add a preprocessor macro. Add “__MAC__” into “Preprocessor Macros” at “Preprocessing” group. You can also define this at your source file. The symbols “__EA64__” and “__X64__” might be useful. Check install_linux.txt at the SDK for their meaning. Probably you should add these at the source file together with the “__LP64__” to distinguish between 32 and 64 bits builds.

To finish this you may want to configure the target options. Since it’s a very simple project you can use the “Project”, “Edit Active Target xxxx” menu. Select the”Build” settings and go to “Packaging” group. Modify the “Executable extension” to “pmc”, remove/change the “Executable Prefix”, and configure the “Product Name” if you wish so.

Now add your plugin code (files should be C++ type), compile and install the plugin (you can configure XCode to execute this step when it finishes compilation – add a new copy files build phase).

If you don’t want to use XCode you can use this Makefile (original from binarypool.com tutorial). Adapt it to your own needs. It’s configured for producing 32bits binaries only.

SRC=formsample.cpp
OBJS=formsample.o
CC=g++
LD=g++
CFLAGS=-arch i386 -D__IDP__ -D__PLUGIN__ -c -D__MAC__ -I/path/to/idasdk/include $(SRC)
LDFLAGS=-arch i386 --shared $(OBJS) -L/path/to/libida -lida --no-undefined -Wl
 
all:
        $(CC) $(CFLAGS)
        $(LD) $(LDFLAGS) -o formsample.pmc

And that’s it!

fG!

« Older entries § Newer entries »