Fluid App Keygen Mac

26.07.2019/ Comments off

While the Mac is rarely targeted for security exploits and viruses, it's no stranger to software piracy—likely because Mac apps are pretty easy to crack. Here's how it can be done and how to prevent it.

Core Keygen App
Keygen For Mac
Keygen

Apr 10, 2019 Unity PRO 2018.3.12 Crack is a sport engine that’s quickly gaining reputation. Its primary benefit is ease and intuitiveness with spectacular capabilities. With Unity 3D, you’ll be able to create video games for Home windows, Android, iOS, Blackberry, OSX, Wii, Ps three, Xbox and Flash. I was unaware that we needed to 'activate' the iLife and iWork packages in the way that one needs to 'activate' Photoshop or Windows. I thought that Apple wants you to 'register' to get updates, as in say yes this product key has been purchased, I am using it, so feel free to send me ads about newer versions and put another tally mark next to iLife for another purchase.

How I'd Crack Your Mac App

Disclaimer: I am fervently against software piracy, and I do not participate in piracy. Some will view this article as an endorsement of piracy, but rest assured that it is not. However, I do not believe that obscurity and ignoring the problem is an acceptable solution.

Well, not you specifically, but by you I mean the average Mac developer. It's too easy to crack Mac apps. Way too easy. By walking through how I can hack your app with only one Terminal shell, I hope to shed some light on how this is most commonly done, and hopefully convince you to protect yourself against me. I'll be ending this article with some tips to prevent this kind of hack.

In order to follow along you're going to need a few command line utilities. You're going to need the Xcode tools installed. And, lastly, you're going to need an app to operate on. I chose Exces, a shareware App I wrote a long time ago.

Let's start by making sure we have the two utilities we need: otx and class-dump. I like to use Homebrew as my package manager of choice. Note that I will use command line utilities only, including vim. If you prefer GUIs, feel free to use your code editor of choice, HexFiend and otx's GUI app.

The first step is to poke into the target app's headers, gentlemanly left intact by the unwitting developer.

Browse around, and find the following gem:

What do we have here?! A (badly spelt) variable and what looks like three methods related to registration. We can now focus our efforts around these symbols. Let's continue poking by disassembling the source code for these methods.

Note that Exces is a universal binary, and that we need to ensure we only deal with the active architecture. In this case, Intel's i386. Let us find out what verifyLicenseFile: does.

This is not straight Objective-C code, but rather assembly-what C compiles into. The first part of each line, the offset, +34, shows how many bytes into the method the instruction is. 0000521e is the address of the instruction within the program. e8c21e0100 is the instruction in byte code. calll 0x000170e5 is the instruction in assembly language. -[(%esp,1) verifyPath:] is what otx could gather the instruction to represent in Obj-C from the symbols left within the binary.

With this in mind, we can realize that verifyLicenseFile: calls the method verifyPath: and later sets the boolean instance variable registred. We can guess that verifyPath: is probably the method that checks the validity of a license file. We can see from the header that verifyPath: returns an object and thus would be way too complex to patch. We need something that deals in booleans.

Let's launch Exces in the gdb debugger and check when verifyLicenseFile: is called.

No bite. The breakpoint is not hit on startup. We can assume that there's a good reason why verifyLicenseFile: and verifyPath: are two separate methods. While we could patch verifyLicenseFile: to always set registred to true, verifyLicenseFile: is probably called only to check license files entered by the user. Quit gdb and let's instead search for another piece of code that calls verifyPath:. In the otx dump, find the following in awakeFromNib:

The code is almost identical to verifyLicenseFile:. Here's what happens:

verifyPath: is called. (+894 calll)
A test happens based on the result of the call. (+899 testl)
Based on the result of the text, jump if equal. (+901 je) A test followed by a je or jne (jump if not equal) is assembly-speak for an if statement.
The registred ivar is set, if we have not jumped away.

Since awakeFromNib is executed at launch, we can safely assume that if we override this check, we can fool the app into thinking it's registered. The easiest way to do that is to change the je into a jne, essentially reversing its meaning.

Search the dump for any jne statement, and compare it to the je:

7409 is the binary code for je 0x00004ca7. 7534 is a similar binary code. If we simply switch the binary code for the je to 7534, at address 00004c9c, we should have our crack. Let's test it out in gdb.

We break on awakeFromNib so we're able to fiddle around while the app is frozen. x/x reads the code in memory at the given address.Now here's the confusing thing to be aware of: endianness. While on disk, the binary code is normal, intel is a little-endian system which puts the most significant byte last, and thus reverses every four-byte block in memory. so while the code at address 0x4c9c is printed as 0x458b0974, it's actually 0x74098b45. We recognize the first two bytes 7409 from earlier.

We need to switch the first two bytes to 7534. Let's start by disassembling the method so we can better see our way around. Find the relevant statement:

Now let's edit code in memory.

Here we set the first byte at 0x00004c9c. By simply counting in hexadecimal, we know that the next byte goes at address 0x00004c9d, and set it as such. Let's disassemble again to check if the change was done right.

Whoops, we made a mistake and changed the destination of the jump from +912 to +955. We realize that the first byte (74) of the byte code stands for the je/jne and the second byte is the offset, or how many bytes to jump by. We should only have changed 74 to 75, and not 09 to 34. Let's fix our mistake.

And check again…

Hooray! This looks good! Let's execute the app to admire our crack.

Woot! Victory! We're in, and the app thinks we're a legitimate customer. Time to get wasted and party! (I recommend Vessel nightclub in downtown San Francisco.) Well, not quite. We still need to make our change permanent. As it currently stands, everything will be erased as soon as we quit gdb. We need to edit the code on disk, in the actual binary file. Let's find a chunk of our edited binary big enough that it likely won't be repeated in the whole binary.

That's the memory representation of the code, a whole 8 blocks of four bytes starting at 0x00004c9c. Taking endianness into account, we must reverse them and we get the following:

The very first byte of the series is the 74 that we switched into 75. By changing it back, we can deduce the original binary code to be:

Let's open the binary in a hex editor. I used vim, but feel free to use any hex editor at this point. HexFiend has a great GUI.

Core Keygen App

This loads up the binary as ascii text, which is of little help. Convert it to hex thusly:

vim formats hex like this:

The first part, before the colon, is the address of block. Following it are 16 bytes, broken off in two-byte segments. Incidentally, every Mach-O binary starts with the hex bytes cafebabe. Drunk Kernel programmers probably thought it'd be funny. Now that we have our beautiful hex code loaded up, let's search for the first two bytes of our code to replace:

Shit. Too many results to make sense of. Let's add another two bytes. Search for '7409 8b45' instead and boom, only one result:

Edit it to the following:

Convert it back to binary form, then save and quit:

And… We're done! To check our work, launch the app in gdb, break to [SSExcesAppController awakeFromNib] and disassemble.

Admire our work:

Quit gdb and relaunch the app from the Finder, and bask in your leet glory.

How to Prevent This

Objective-C makes it really easy to mess with an app's internals. Try to program the licensing mechanism for your app in pure C, that will already make it harder for me to find my way around your binary. Also read this older article of mine on three easy tips-stripping debug symbols, using PT_DENY_ATTACH, and doing a checksum of your binary-you can implement to make it a whole lot harder for your app to be cracked.

Keygen For Mac

A truly skilled hacker will always find his way around your protection, but implementing a bare minimum of security will weed out 99% of amateurs. I am not a skilled hacker-yet with some very basic knowledge I tore this apart in no time. Implementing the various easy tips above takes very little time, yet would have made it enough of a pain for me that I would have given up.

Kenneth Ballenegger develops cool Mac and iPhone software. Visit his personal blog for more writing on the world of design, software, and life. You can contact him at kenneth@ballenegger.com.