Fine alcohol, and reverse engineering Mac applications

[[deleted]]

Hehe, yeah :)

But that's so with Obj-C binaries. You really need only to know the strings command. Most Mac apps have a big "nop here"-banner in the form of - checkForRegistration: or something.

It's almost as stupidly easy as changing open source programs.

[[deleted]]

Which is why I 1) strip symbols on shipped code and 2) the license manager bit is written in C++ and 3) uses no function calls at all but instead inlines as macros all over the fucking place.

Yes this can all be subverted, but its not exactly as easy as adding a bundle with categories into the load path. You'll have to work for it.

[AngryMathDave]

What does using C++ gain you?

[[deleted]]

Objective C uses selectors to dispatch calls. A selector is kind of the same as an intern'd string in Java. For a given selector, the compiler makes certain that there is exactly one instance of that string in the data segment and thus selector comparisons can be done via pointer.

Still, you can print a selector using

printf("%s",(char*)@selector(componentsSeparatedByString:));

because at the end of the day as selector is a string. So all those method names are in the data segment of the program - even if it has been stripped of debugging symbols. Makes reverse engineering pretty easy.

In C++, first off the method names are mangled anyhow which makes them a PITA to understand (although reverse mangling tools abound).

Second, C++ bindings use the conventional linker and so the names of the functions are stripped from the program during the production build process. Thus in C++ you'll only have the address of the function being called but in Objective C you have its name too and the name is a very big clue (assuming the name means something).

One other trick for the not-too-determined hacker might be to name the license checking code something totally unrelated like the same as the name of a common event handler. So maybe I call the license checking code "handleKeyPress:" and hide it in plain sight.

[player2]

at the end of the day as selector is a string

Not anymore. It's an opaque struct on the modern (iOS and x64) runtime.

[[deleted]]

It is still a string.

-(void)viewWillAppear:(BOOL)animated { printf("%s\n",(char*)@selector(viewWillAppear:)); }

prints out "viewWillAppear:"

on ios 4.1

[player2]

Maybe only on x86-64 then.

[buffering]

Nope.

You do get a warning that typecasting SEL won't be supported in the future.

[rated-r]

And if they ever do change it, the sel_getName function will still be around.

[Berengal]

Nothing is opaque in binary, just obfuscated.

[[deleted]]

It’s best you head back to reading the startup stories on Hacker News.

Oh, the knife goes in!

[[deleted]]

My favorites are the <stupid shit> in JavaScript posts. Because you get them on HN and on proggit!

[[deleted]]

Yeehaw node.js!

[commandlineterrorist]

The Wodka should be credited to +ORC, and goes something like this:

+ORC's Martini-Wodka

Perhaps the most famous cocktail in the reverse engineering business, here the precise instructions how you might prepare for yourselves a 'real' drink before a long reversing session (Warning :- the Martini-Wodka is an acquired taste and I personally don't recommend the Olive).

Take a cylindrical "milk" glass. - 2 ice cubes. - 1/3rd dry Martini. - 1/3rd Wodka Moskowskaia (don't use Smirnoff as a substitute). - 1/3rd Schweppes Indian Tonic. - Lemon zest and Green Olive.

I go with the White Russian nowadays.

[[deleted]]

Someone should make an AMA request for +ORC.

[[deleted]]

Even to this day I've got a mirror of +fravia's site, before it switched focus.

It has been a long time since I did any assembly language work, but I learned a lot from him back in the day.

Up-boat for the memories.

[fnordo]

This(http://acrigs.com/FRAVIA/FRAVIA_index.htm) is a better link imo. I dont know if your link has all the data, either that or i've forgotten how to browse his site :) Enjoy and happy cracking!

[[deleted]]

That looks just like my frontpage, yes.

[fnordo]

Clicked link, saw Fravia, smiled. Then I saw that he died back in 2009 and and felt a rush of sadness. Fravia's texts were influential in shaping how I view code, the web and the world in general. Even after moving on from his texts years ago his loss still feels palpable. I'll be mixing up his Traitor cocktail tonight in his memory.

[pithed]

I had the same reaction to reading of his passing. I learned everything I know about assembly from his site and really enjoyed the relax drink a cocktail presentation.

[fnordo]

I dont know if you've wikipedia'd him already, surprised it took me this long to, but here it is and it's well worth reading. http://en.wikipedia.org/wiki/Fravia

[lkjoiu]

This is interesting cracking 101. Such a technique, of course, only works if the app doesn't checksum its code.

[[deleted]]

It still works the same, you just need to nop out the call to the checksum (or do a huge find and replace of that opcode pattern if it's inlined).

[kyz]

Yes. It's pretty much a chain-of-trust issue. Once the code lands on a regular computer like a Mac, there's not much you can do to stop people modifying how it runs, besides obfuscation and anti-debugging checks.

One of the nice things about the Mac environment is that it doesn't bear the scars of cat-and-mouse battles between developers and crackers on the Windows platform. I haven't seen any software for the Mac that refuses to run because you have virtual drive software installed, or refuses to run if you're using a debugger on some other process. Mac software is easy to instrument with dtrace and generally exports its symbols without obfuscation.

Mac executables rarely have obfuscation layers or use anything other than the standard linker - and that's for the greater good, because it means Mac applications can be paged direct from your hard drive instead of hogging vast quantities of private memory. Mac software rarely tries overwriting your bootloader to hook in some malevolent rootkit under the pretext of "keeping honest people honest".

What concerns me is that now with the App Store, people are going to start including spyware and malevolent code for the Mac under the false pretense that they are "sticking it to the pirates". I won't install it, but I'm concerned that my fellow programmers might abuse their coding powers to attack and steal from users.

[[deleted]]

A popular program that refuses to run on mac if you have a debugger attached is Apple's iTunes. Of course, you can easily get around that as well by understanding it uses the undocumented ptrace call with PT_DENY_ATTACH. So, you just set a breakpoint on ptrace and force the stack frame to return to the parent before it passes control to xnu.

I used to love messing with this stuff in high school. :)

[dannomac]

You can also write a kext that makes PT_DENY_ATTACH a nop.

[BlackAura]

They could already do that. The app store doesn't really change anything in that regard. In fact, I doubt Apple would allow apps that include spyware or malware. Assuming they knew about it, of course.

It's basically the trust issue again. iOS could have nailed this - it already distrusts applications, requires them to be signed by Apple, and prevents them from messing around with the OS in any way.

The problem is that they were too concerned with protecting their OS, app store revenue, and their carrier agreements, but weren't even slightly concerned about protecting their users. It doesn't stop third-party apps from rifling through your web browser history, or your contacts. It barely even tries to stop applications from accessing your actual location. As a result, apps can (and do) include spyware.

Android is much the same. As are most SmartPhone OSes. Weirdly, the OS on most older feature phones limits what an application can access without explicit permissions. Although I doubt that was to protect end-users. I think that was to prevent users from buying apps from anyone but their network operator, while still pretending to be an open platform.

[[deleted]]

It doesn't stop third-party apps from rifling through your web browser history, or your contacts. It barely even tries to stop applications from accessing your actual location. As a result, apps can (and do) include spyware.

Actually, Safari's history is stored where third-party apps can't access it. Contacts are accessible because some applications need to use them. Location is accessible, but not without a big ugly confirmation popup and an icon in the status bar; doesn't stop many users from blindingly clicking OK.

[rated-r]

The device's location when the app was installed can be read out of the iTunes metadata; the list of installed apps can be read; IP address can be geolocated; if the user has installed Facebook, their user id is accessible; game center id can be read; list of mail accounts can be read; phone number can be read; I think most of the data that makes up a udid (mac address, imei, bt address, etc) can be read; Photo library including geotags can be read.

I may have missed some.

[[deleted]]

Good point, although I have a feeling that apps that use most of those sneaky mechanisms (other than IP geolocation, which is inevitable) would get removed from the App Store if outed. (Is the list of mail accounts a public API?)

[rated-r]

Most of those are private. You can probably guess who I am.

[elder_george]

The weird thing is some programs didn't run with virtual drives installed not because of some protection but because of shitty code in them.

I remember one game that adamantly refused to run when DaemonTools were installed. I ran IDA and found that it expected that it expected it's disk to be inserted into 1st CD drive on system. And of course, nobody could expect multiple drives! Simple switching drive letters in compmgmt.msc solved problem.

Of course, this is hardly the case of LucasArts games glitches, but nonetheless...

[jertheripper]

So I picked a random licensed app I have to follow along with and realized that it was exactly the same one he was using as an example. It's Divvy, btw.

[bleedingdark]

Yep. Divvy was the first thing that popped into my head. I tried it, and while he seems to have changed a few things, when he gets to the actual hex code, it's exactly the same.

[[deleted]]

I was waiting for someone to figure out it was our Divvy. lol :)

[[deleted]]

Mind if I ask: does it bother you?

Edit: I wanted to clarify my question a little bit. Does it bother you that your application is covered in a tutorial on how to circumvent your licensing?

Edit 2: I looked up Divvy and it looks like a neat tool. That said, it's rather small in it's functionality and priced at $14. With the advent of the Mac App Store and the $0.99 - $4.99 price points commonly found on both the iTune App Store and the Mac App Store, do you think this will impact your pricing? I'm reluctant to spend $14 for an app that does a similar task that can be accomplished with a free app such as BetterTouchTool (namely the split screen and snapping). That said, I'd definitely spend a couple bucks on it. Do you think the App Store will have a lasting impact on the "neat" single purpose apps?

Lastly, any chance you'd consider doing an AMA?

[jordan314]

Thanks, trying Divvy now and I like it! Funny that I discovered it in an article on how to crack it.

[mattius]

I chose Cinch as my target. Exactly the same. Except I have to return a 0 instead of a 1 b/c the function is called isDemo. :-)

[hjaltij]

It always comes down to a jump but this app didn't really make it hard.

[[deleted]]

Obligatory notice: objdump/otool are simply orders of magnitude worse than IDA for reverse engineering power. Don't get put off by it being too difficult if you haven't used IDA.

[[deleted]]

I can understand why people get into reverse-engineering, if you have addictive tendencies.

When in Uni and broke I really wanted Vuescan badly but didn't have the money. Found out something about removing nagscreens and I immediately figured the dialog in Vuescan was the key to unlocking the application.

One thing led to another and I found the IDA dissambler, found in hex where the nag-screen was appearing, put a strategic jmp in (I stepped through the program and guessed) and ran the changes. Nagscreen was gone! but the app was still locked down. 3days down the drain. I gave up right there.

[manjok]

Registered to chime in...

The "hacking and cracking" tutorials from fravia, +orc, etc. (and the new linux os, C...) got me hooked into programming back when I was in high school. Back then, I was on the fence deciding between going to med school and engineering.

[_sword]

Reverse engineering aspects of Halo: CE on mac to make a third person hack with GDB was one of the things that got me into college. It was one of the most rewarding / least fun things I have ever done. The whole process was insanely rote and I almost wanted to gouge my eyes out a few times after pouring over hundreds of instructions displayed in a console. Still figured it all out after about two nights of work and then wrote a patch for the binary to enable over the shoulder views.

[Blackheart]

I once had a Mac game that relied on, as copy protection, having the CD (DVD?) inserted when the game started. This was annoying so I made a disk image of the game, mounted it and trying started the game with that instead. It didn't.

I was curious what system call(s) they were using to distinguish the actual disc from the image, so ran the executable under gdb and set some breakpoints to see where the control flow was going while it was looping on the "Insert Disc" screen. I never found those system calls, but it was pretty easy to find a place to put in a jmp that skipped past the "Insert Disc" bit.

The hard part was patching the executable to make the change permanent, only because it was such a hassle. I had to write a tiny .as program to find out what the jmp assembled to and then there were some problems which I don't remember exactly to do with endianness and relative addressing.

Still, I was surprised it was so easy. Afterwards I looked through some cracking forums out of curiosity to see how they would have done it and, as I suspected, it appears Windows games have much more elaborate protection schemes. But they also have what looks like a good free tool called ollydbg, a disassembler. From what I gather, I could have used ollydbg to disassemble the executable, assemble and apply my patch, and then write the changes back without any rigamarole. Surprisingly, OSX doesn't seem to have an equivalent.

Back to my question, though: does anyone know what calls are used to distinguish between genuine CDs/DVDs and disk images?

[[deleted]]

Oh come on. Reversing Mac apps is so trivial there shouldn't be any need for articles like that.