Mac Reversing

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

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!

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

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!

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

I just saw the following at MSJ and the reaction of the one byte fag and other idiots is simply childish, to not digress much about it.  The author of Remote Buddy leaves the post below, asking for them to stop distributing cracks on his software. As a response, tons of links with the crack are published and they start complaining about the price. I really hope that these guys one day get what they deserve, their works pirated or them exploited by their bosses and underpaid. Everyone wants to have tons of shit, for free if possible, but then they forget that money drives the economy. I’m not saying that the price is right or wrong, that’s a market/customer decision. What really pisses me off is the lack of effort for all those idiots downloading the cracks and bashing the developer. At least make an equivalent effort and learn how to do it and take on a “fair fight”.

Disclaimer: I did cracked Remote Buddy in the past and published some information regarding it. The author asked for removal and I kindly refused because, at that moment, I believed that the published information wasn’t valuable enough.

Update: Just to put some things in perspective, let me show a simple math example:

Months 12
Monthly Salary $2,500
Annual $30,000
App Price $20
Total Sales 1504
Monthly Sales 125

If selling this program is the only source of income to this developer and we project a $30k annual salary (low salary by US standards for developers!), this will require 125 copies sold each month. Let me remind this values are not liquid, so there are still other costs and tax burden on the developer (you can add Apple’s 30% as a good estimative).
Now, you could say that 125 monthly or 1500 annual copies is a piece of cake to sell…  Have a read at this article,  and observe the low numbers of books sold for each book that guy wrote. They are pretty shocking and a good example about how hard is to sell (start a company and try it yourself ;-) ). Not every app is Angry Birds or equivalent!


Hello,

I’m the author of Remote Buddy and am kindly asking you to stop what you’re doing here.

You may not be aware of it, but the development of Remote Buddy has cost and continues to cost _a lot_ of money and I can only keep working on this and other related projects, if Remote Buddy sales stay above a certain level that allows me to pay all bills for the company, for product development and – most importantly – for my family.

I know many of you believe that piracy doesn’t do any harm or even helps sales, but I sure know that the bare numbers – at least for Remote Buddy – speak a very different language.

Whenever there has been a crack or serial number floating around in the past, sales dropped significantly. It was only when pirated serials had been blocked and cracks went offline that the revenue stream slowly (but luckily!) recovered to a level where Remote Buddy could have a future again.

I’ve always been very generous with my work.

Users can fully try out Remote Buddy for a full 30 days, they can purchase a license for as little as 19.99 Euro and for the last 4 (four!!) years there’s been nothing but free updates (many of them major redesigns you’ll usually have to pay an upgrade fee for at other software companies, plus free updates to support three major OS X releases as they appeared).

When Snow Leopard appeared, I helped out the Plex and many other open source and commercial projects with a free, instant fix for their Apple Remote issues that SL brought along: Candelair. It certainly helped out many of you and some software like Hulu Desktop can’t use an Apple Remote under SL without it to date.

I also spent a lot of time developing and documenting the HIDRemote class (which I have no use for personally) and made it available for free to vastly improve the state of Apple Remote support in OS X applications. I continue to work with open source and commercial developers (even competitors!) to help them with providing better Apple Remote integration in their applications.

You all benefit of this work whenever you use an Apple Remote – regardless of whether you use it with Remote Buddy or not.

I’ve worked very hard to make all of this happen – and I happily did so, because I believe in community and fairness.

But if instead of at least a minimum of respect, all I get in return from the community is that they try to find a way to exploit the generous, feature-unlimited demo time, or that they crack my software and are seemingly happy uploading it to a dozen filehosters, which – in end result – directly cuts into the personal income of my family, I really have to wonder why I’m doing all this – and what for.

Some of you may not have realized that – as a matter of fact – what you are doing directly affects and hurts real people that live off of this project – and – that what you’re doing is part of the biggest threat for the future of this product that you all obviously seem to like.

I’m appealing to nothing else but your sense of honor, community and fairness when I ask you to stop cracking Remote Buddy, to stop spreading copies of cracked versions or instructions on demo timeout circumvention – and to remove any copies from where you’ve already uploaded them to.

If you ignore this and just continue, be aware that you are taking away from the table of my family and that you are working on killing an important, unique product for all Mac users that there’ll be no replacement for.

I’m hoping for your sense of honor, community and fairness – and that my open words are really all that’s necessary.

Thanks.

- Felix Schwarz

I have decided to re-release my beginners tutorial, this time based on a crackme, so it deserves the upgrade to Universe instead of World.

It includes patching, serial fishing and a keygen. I have updated some errors that I found in the original tutorial.

Reversing and breaking protections is a great hobby and fantastic knowledge to possess.
The problem is that many abuse this and want to profit from it. I really don’t like not sharing
knowledge because sharing also allows me to progress, seeking new challenges and learning new things.
I really hope that you make good use of this information and do not share your cracks with the world,
especially in MSJ that is full of idiots just wanting to rip off others work. Don’t do that please.
Enjoy the process, learn, get frustrated, and buy the apps if you really use them in your day to day.

Don’t make me regret once again releasing knowledge that may ease piracy! Don’t rush to MSJ spreading your cracks (ok it might be acceptable if you can teach the one byte fag how to crack real targets and not the easy ones he usually does ;-) ). Seriously, don’t spread your cracks, you don’t get any glory from that :-)

Have fun,
fG!

Here it is: beginners tut II.txt

« Older entries § Newer entries »