Mac Reversing

You are currently browsing the archive for the Mac Reversing category.

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

October 13, 2011 in Mac Reversing | 1 comment

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. I will not tell you what is it so you can have some fun with it :-)

There is also an import table built on the fly, with symbol strings & other strings being encrypted (gdb “info symbol address” command is useful here). And some functions where IDA disassembly fails, totally out of sync. This is where I am at the moment.

In theory I shouldn’t be able to progress much more because the unpacking will require a dongle plugged in, which is something I don’t have. I will just try to disassemble those messed up functions :-)

Has anyone else picked up on this one? Are there any more interesting things to look at here?

Don’t worry Aladdin, I will not publish any details ;-)

You can download the Sentinel CD from Aladdin website, containing all tools for Windows, Linux and OS X. The program that creates the envelope is located in VendorTools folder. Btw, the enveloped program seems to be around 10 times bigger than the original size. I am glad storage is cheap these days.

Have fun,
fG!

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

October 11, 2011 in Mac Reversing | 2 comments

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 features bad implementations. Developers don’t spend enough time in this area or think that it’s the magic bullet to solve their problems.

This program is another fine example of this problem. I saw this one and decided to give it a look – it had HASP in the request so my curiosity had to be fulfilled. Less than three hours later, I was disappointed! Another crappy and rushed dongle implementation. It is so damn easy that it hurts (picture is for the basic edition, the advanced is one byte away). The full crack is 5 bytes, where 4 are NOPs ;-)

I have emailed the developers 5 days ago but received no answer. The auto-reply promises feedback in 24h so they don’t seem to care. Of course I will not publish details about this. It is annoying because it would be a good example of what not to do.

Anyway, if you are a developer implementing a dongle, let me give you this small piece of (important!) advice. Your application should have an healthy dialog with the dongle instead of a “good morning” before starting to work. You can also trust it to keep your secrets instead of storing them in computer’s memory.
Explore the dongle possibilities and think a little about how can you use them. In this case, HASP examples are a bit bad because they are way too simple. Remember that example of the App Store receipt sample code that a lot of developers copied, even when they were warned not to ? Do not do the same ;-)

Back to some other projects. My baby girl seems to have inherited her parents strong personality and doesn’t want to come out, so I still have another week of free time :-)

fG!

 

Using Apple’s sandbox feature for reversing purposes :-)

August 30, 2011 in Mac Reversing | 3 comments

I was just messing with Apple’s sandbox implementation to see if it was possible to close a “vulnerability” in iTunes (more on that later after Apple answers my email) and decided to experiment with something that has been in my mind for a long time and never bothered to try. The idea is to use the sandbox feature to find, for example, hidden files that applications use for serial numbers, time limits, demo limits, etc, or to trace install scripts or malware. In this last case, I find fs_usage too noisy to be really useful. If we deny any kind of writing we can easily follow what the program is trying to write, improving this process.

Documentation on Apple’s sandbox is very scarce, with the best references being the presentation by Dionysus Blazakis (here and here) and some scripts by s7ephen (here). You can also find Apple scripts at /usr/share/sandbox.

You can adapt these scripts and make them more or less granular, where the most important part in this case is to deny all type of file writing. Most probably you will need to tweak this and allow some writing to known files else the application will not start.
The errors are always logged to /var/log/system.log, so the best idea is to “tail -f” that file to watch the errors and fix them.

This is an example of TranslateIt! Deluxe trying to write some hidden files known to be protection related:

Aug 30 23:04:15 desktop sandboxd[3234]: TranslateIt!(3233) deny file-write* /Users/myself/Library/Preferences/.ti_tick_stmp_14.0
Aug 30 23:04:15 desktop sandboxd[3234]: TranslateIt!(3233) deny file-write* /Users/myself/Library/Preferences/.ti_tick_dy_14.0

When you are tweaking the scripts you might get some weird crashes. These seem to be related to missing permissions on “mach-lookup” rule. Check /usr/share/sandbox/bsd.sb. The configuration for this rule seems to help on these crashes!

Maybe I will try to write a document about sandbox rules and features. It’s a useful security feature although not perfect! Better than nothing :-)

Have fun messing with the scripts!
fG!

Removing iTunes 10.4 m3u processing feature with a small loader

August 25, 2011 in Mac Reversing | 7 comments

I just discovered that iTunes 10.4 finally introduced support to load m3u files. If you are importing large quantities of mp3 archives like me then you probably will be very annoyed by the mess that iTunes 10.4 will make out of this – playlists will be created and a ugly mess will emerge (and takes longer to process). So it was time to try to remove this feature, which is curious since I always wanted this in iTunes, before I surrended myself to its way of managing mp3s. A quick google search shows that I am not the only one having “issues” with this new feature :-)

First attempt was to disassemble and search for the code. Well, iTunes is a huge program and I just wanted a quick hack (I did find more or less where the interesting code is). So why not searching for the string m3u and modify it? Most probably iTunes was processing the files based on extension and modifying that string would effectively remove this feature.

A quick test with GDB and voila, it works. No more m3u/m3u8 (unicode version) processing! Hurray :-)
To make the change effective there are two solutions; first patch the binary, which would require an update to codesign, second create a small loader to patch the strings in memory, leaving the original binary intact. Second one is more fun, so here it is, a small loader for iTunes 10.4.1 that will remove this feature. For now it’s 32 bits  only, which is the version that runs on Snow Leopard. I will test later with Lion.

To use this loader, execute the following commands in Terminal.app (after downloading and unpacking the loader.gz):

$ sudo cp /Applications/iTunes.app/Contents/MacOS/iTunes /Applications/iTunes.app/Contents/MacOS/iTunes.orig
$ sudo cp loader /Applications/iTunes.app/Contents/MacOS/iTunes
$ sudo chgrp procmod /Applications/iTunes.app/Contents/MacOS/iTunes
$ sudo chmod g+s /Applications/iTunes.app/Contents/MacOS/iTunes

And that’s it, you can click the usual iTunes icon. The program will start and no more m3u processing! If you check Activity Monitor, you will have two iTunes processes, one with a very small memory footprint (the loader), and the real iTunes. When you exit iTunes the loader will also exit, so everything is nice & clean.

I might improve this loader to be smart and support any new iTunes updates, and maybe create a Cocoa application to launch iTunes with this m3u enabled or disabled. I need a small excuse to start coding Cocoa apps ;-)

Have fun,
fG!

loader.gz
SHA256(loader)= 4cff14a3e2e5a58d4de22c74a064ab3448bdb63210440c232bedcd410acefdbf

Update:

Here it is a version that should work with all future iTunes updates and also for Lion with ASLR support (ASLR isn’t disabled by the loader!). Install as in the previous version.

loaderv2_snowleopard.gz
SHA256(loaderv2_snowleopard)= 35453a6622699cc60fa4edb5def8b0d597c56e2850c3d165b1d080fe31c97cfe

loaderv2_lion.gz
SHA256(loaderv2_lion)= 7d0bd9934042141061710abea349284c553afdaee90342d4034bd9a916e6d099

How gdb disables ASLR in Mac OS X Lion

August 11, 2011 in Mac Reversing | 8 comments

This isn’t a rocket science post but more like some notes for future reference :-)
Lion finally introduces full ASLR and gdb has the possibility to disable that feature when analyzing target binaries. A new gdb setting was added, “disable-aslr”, which allows to enable or disable this feature.

By default this feature appears to be enabled (I am just looking at gdb source code) and it’s set by the variable “disable_aslr_flag” configured at gdb/macosx/macosx-tdep.c source file. But this isn’t the place where the magic happens. That is located in gdb/fork-child.c file (well there’s a second version at macosx/macosx-nat-inferior.c).
A very rough draft of gdb workflow is something like this:

  1. Fork
  2. If we are the child process, drop privileges
  3. If we are the child process, use ptrace to “stop” the new process
  4. Exec the target
  5. Use again ptrace to resume the child
  6. Wait for breakpoint events

Step 4 in Apple’s gdb version tries to use posix_spawn instead of exec (or any of its variants) to launch the target. This allows to set some special attributes in the new process. One of the new attributes in Lion is “_POSIX_SPAWN_DISABLE_ASLR”. The name should be explicit about its purpose :-)

The piece of code that sets it in gdb/fork-child.c is:

(...)
            if (disable_aslr_flag)
              ps_flags |= _POSIX_SPAWN_DISABLE_ASLR;
            retval = posix_spawnattr_setflags(&attr, ps_flags);
(...)

If posix_spawn fails gdb will then try to execvp the target. At the kernel side, this is dealt with in “posix_spawn()” at “bsd/kern/kern_exec.c”:

(...)
                /*
                 * Disable ASLR for the spawned process.
                 */
                if (px_sa.psa_flags & _POSIX_SPAWN_DISABLE_ASLR)
                        OSBitOrAtomic(P_DISABLE_ASLR, &p->p_flag);
                /*
                 * Forcibly disallow execution from data pages for the spawned process
                 * even if it would otherwise be permitted by the architecture default.
                 */
                if (px_sa.psa_flags & _POSIX_SPAWN_ALLOW_DATA_EXEC)
                        imgp->ip_flags |= IMGPF_ALLOW_DATA_EXEC;
        }
 
        /*
         * Disable ASLR during image activation.  This occurs either if the
         * _POSIX_SPAWN_DISABLE_ASLR attribute was found above or if
         * P_DISABLE_ASLR was inherited from the parent process.
         */
        if (p->p_flag & P_DISABLE_ASLR)
                imgp->ip_flags |= IMGPF_DISABLE_ASLR;

And that’s it! A new flag added, processes spawned with that flag active and bye bye ASLR ;-)
Enjoy,
fG!

There’s a new protection in town, Software Passport, from the developers of Armadillo :-)

February 16, 2011 in Mac Reversing | 23 comments

A reader sent me the link for a new software protection package called Software Passport (here). This is from The Silicons Realms, the makers of Armadillo for Windows. Since I’m as curious as cats, I started giving a quick look on it, to see if it has any interesting things related to anti-debugging and anti-disassembly.

The good news is that there are some new tricks that I haven’t seen before, for example, gdb can’t trace the initial loader. I haven’t explored this yet so I don’t know how it’s being done. When I approach a target, I prefer to understand the general pattern of things instead going immediatly to understand every single obstacle that appears.
The bad news is that the packed/encrypted/whatever binary is easy to dump and recover, allowing to disassemble and poking at the real binary. I was interested in finding the registration routine (I’m playing with the protector itself) but it’s not so straightforward. Anyway, the following screenshot shows that’s easy to dump the binary and modify stuff. It’s still too early and too much left to explore but I have a feeling that this protection needs more work ;-)

Have fun,
fG!

modified about box

« Older entries § Newer entries »