This forum has been closed and no more support will be offered here! Don't worry! We have MOVED to:


To all existing and new members wanting to register here, visit the above website at our new forum and register yourself there!

Your NEW source for cracked Appstore and Cydia - Games & Apps, Themes and more! iPhoneFans.info

Thank you,

iPhoneFans Team

IE Users Only (Button):

Firefox Users:
Press Ctrl + D

Thank you!

Google Website Translator
Latest topics
» GBA Roms (.gba) + Bios File
Wed Mar 10, 2010 9:50 am by zillionaire

» iFile 1.1.0-1
Wed Mar 10, 2010 12:40 am by Heartbreaker

» Documents To Go® Premium v3.1
Tue Mar 09, 2010 3:50 pm by Heartbreaker

» Sonic at the Olympic Winter Games v1.0.6
Tue Mar 09, 2010 12:29 pm by hkay

» iFitness v9.58 [UPDATE]
Tue Mar 09, 2010 12:22 pm by naagn95

» Brothers In Arms® 2: Global Front v1.09 [NEW]
Tue Mar 09, 2010 12:19 pm by naagn95

» 2Do: A Stunning To Do List with Push and Sync v1.2.3
Mon Mar 08, 2010 3:50 pm by iPhoneFans.tk

» Cricket T20 Fever v2.0
Mon Mar 08, 2010 2:21 pm by hkay

» ibisMail - the first full-fledged email app v1.5.0
Sun Mar 07, 2010 10:51 pm by naagn95

» Jot Not Scanner v2.1
Sun Mar 07, 2010 10:47 pm by naagn95

» Bolt-IE Browser v3.5
Sun Mar 07, 2010 10:42 pm by naagn95

» QuickOffice Mobile Suite v3.0.1
Sun Mar 07, 2010 10:32 pm by naagn95

» Quota - Mobile, ISP, Traffic, Weather, News v12
Sun Mar 07, 2010 10:26 pm by naagn95

» Rayman 2: The Great Escape [NEW]
Sun Mar 07, 2010 9:41 am by iPhoneFans.tk

» TomTom Maps 1.2 and CoPilot Maps (IPA)
Sun Mar 07, 2010 9:16 am by iPhoneFans.tk

» Where is my Phone? v1.0
Sun Mar 07, 2010 7:28 am by kevdragster

» Need application
Sun Mar 07, 2010 5:27 am by zillionaire

» Cycorder (ad free)
Sun Mar 07, 2010 4:09 am by Scainer

» Nintendo DS Roms (.nds)
Sat Mar 06, 2010 3:19 pm by Heartbreaker

» Nintendo 64 Roms (.v64 and .z64)
Sat Mar 06, 2010 3:16 pm by Heartbreaker

You are not connected. Please login or register

How the cracking method works

Go down  Message [Page 1 of 1]

1 How the cracking method works on Mon Jan 18, 2010 3:06 pm


I found this on Hackulo.us and thanks to Kyek

Why are you writing this? We don't care.
More and more I find people who might fully understand the steps to take to crack a program, but STILL say things like "This shouldn't be public, Apple might find out how we're doing it and stop us" or "Apple might block our cracking method and we'll have to find another way" or "Apple might block IPAs." My goal with this thread is to give you a brief overview of what cracking actually DOES so that we can have intelligent conversations here about what Apple, developers, etc are ACTUALLY able to do about this.

So here's the scoop on how the App Store works
Apple has every application available in the app store on their servers. You already know that -- it's pretty obvious. You can download it, therefore it's coming from them. But what most people DON'T know is that every app on Apple's servers is already cracked. It's not encrypted. It's not signed. It will work on anyone's phone.

When you download an app from the store, though, Apple doesn't give you one of those programs right away. First, they take the program, and they pick out a chunk of it that the program needs to launch. And then they encrypt it -- turning that section into a code that can only be broken with YOUR iTunes account. Apple keeps the key that breaks it on file --
you don't even get to see it, but it is unique to you. Like a password you're never allowed to know.

Then Apple flips a switch on the program to let the iPhone know that it's been encrypted, Apple "signs" it (like a real signature on it that only Apple can make) so the iPhone knows it's a for-real Apple program, and then they send it to you. All of that happens instantly. You end up with a program that only you can run, since only you have access to your key.

Ok, that makes sense. So how do we crack it?
Before we get into that, you should know that the iPhone (I keep saying phone, but iPod Touch is the same thing) can run any code whether it's encrypted with your key or not -- it just has to be signed. So if you could get the unencrypted copy Apple has on their server, you could run
it with no problem. You just have to sign the sucker.

So here's what we do. The iPhone can't actually run encrypted code. No computer can. The computer has to DEcrypt it (using your iTunes account key) as soon as you run it, store that decrypted section in memory, and then run that.

It's a weird concept, I know, but think about it for a second and it makes sense. The phone can't read Apple's code directly, so it decodes it, writes down the decoded version, and runs that. Easy-peasey. And the iPhone holds on to that decoded section the whole time the app is
running, because it might need it again. It just stores it in the phone's memory.

What we do to crack it is freeze the phone when the program we want to crack is running, and we dump out all the memory from it. Actually, it's even better than that. We do a few simple calculations and figure out EXACTLY where in memory the decoded stuff is, and we dump JUST that out. We just save it to a file. The iPhone did all the decrypting work FOR us -- we just take what it came up with, and we write it down.

Finally, to crack the app itself, we take advantage of something really cool: The code that Apple sent us is the EXACT same size encrypted as it is decrypted! So all we need to do is take the decrypted stuff we just got from the iPhone's memory, open up the application file Apple
sent us, and replace the encrypted stuff with it. The idea is dead easy, right? That's because it is
This concept of taking decrypted code from memory and replacing encrypted stuff with it would be on the first page of Hacking for Dummies, if that book existed. EVERY hacker knows it. Most run-of-the-mill developers are fully aware that this is possible. It is not some profound secret that we came up with.

To finish the cracking process, all we need to do is turn off that little switch that tells the phone it's encrypted -- because it's not any more. Ta-da!

Cool, but what about the signing?
We can't fake Apple's signature. I could get into how signatures work and why they're so secure, but that doesn't even matter at this point because we just can't do it. But what we CAN do is alter the part of the iPhone's operating system that makes it CHECK for Apple's
signature, and make it so that it works with ANY signature -- not just Apple's. If your phone is Jailbroken, you've already done this. This is a small part of what Jailbreaking actually is -- letting your phone run code signed by anyone.

So all we need to do in order to run a cracked program on an iPhone is just sign it ourselves -- and that is the final step of cracking a program. Sign it, and now that no one's phone needs to decrypt the program, anyone with a jailbroken phone can run it!

Alright, I get all that, but what's your point?
What I'm trying to say is, this concept is something that anyone educated in computer security could have come up with. The second Apple heard about iPhone apps being cracked, they knew how it was done. And don't try to use the argument that they might not have thought of it,
because that's bogus. If their engineers couldn't figure out how we did it without being told, they are fucking retarded and complete failures in their field. And I have a tip for you: Apple's
security guys are smart as hell, and not even a little bit slow. You just have to trust that they knew.

What's more, this explanation shows you that this isn't some little switch that Apple can just "turn off". No one can go "Oh hey they were doing this one thing to crack apps, let's not let them do that anymore. Bing. Done. No more cracked apps." iPhone apps will always have encryption, and the phone will ALWAYS need to decrypt that and put it in memory before it can run it. Sure, Apple might be able to rewrite the ENTIRE CORE of their operating system and make sure that all that stuff isn't in memory at once, but that doesn't matter. It HAS to be there at some point because that's how computers work. Changing that would mean adding hardware. So we will always be able to get at decrypted information, and we will always know where to plug it into the original program because there will always have to be a way for the phone itself to know where things go.

You should also be aware that Apple, any time in the conceivably near future, *can't* make it so that the phone cannot run decrypted programs. It's how developers test code so it's a feature they WANT to be there, and a check like that is something amazingly easy to disable in the Jailbreak process as well, even if they DID do it.

Apple can't scan for cracked apps at run time, because the only way they can do that is by looking at checksums, or program information, or other identifying marks -- and we can change all of those if they do that.

All Apple can do is add steps to the cracking process. That's all.

Awesome, that's great news! But they can still see my cracked IPAs, so I should use the plain .app method, right?


Ok, ok, sorry to be so harsh .
See, the belief of the .APP crowd is that since IPA files have to go through iTunes, Apple can easily just look at what you're doing with them and sue you and send you to jail and make you drop the soap in the shower.

Let's look at this from a really high level first. Sure, Apple could make an update to iTunes that would send them information about all the IPA files you have installed, and which ones are illegitimate. Let's forget for now about this completely breaking Apple's privacy agreement and thereby giving them so much bad publicity that the company could never recover. Let's pretend that this would be legal for them to do.Do you honestly think that it would be any harder to check your phone's /Applications folder every time you plug it in, and report THAT information back to their headquarters? Think about this for a minute: if Apple wanted to flagrantly break the law and report these things back to themselves, why the hell would they leave out checking for .APP and *only* look for .IPA? Just because you can SEE the .IPA in iTunes doesn't mean it's any less safe than .APP is.

Now let's dig down a bit. Again, developers use unencrypted .IPA files to test their code. They use the same iPhone OS and the same iTunes as the rest of us, and iTunes does NOT do anything special for them. Apple does not have their iTunes accounts "flagged" as Developers and give them extra privileges. In their current system, they can't even physically do that because it would be ridiculously easy for us to fake. Being able to do this with IPA files is a FEATURE that they are not about to remove.

Let's sum this up. IPA does not put you more at risk than APP does, no matter how you feel about it.

So what can Apple or the developers actually do about this?
In short, not enough. As I mentioned above, all Apple can really do is add more steps to the cracking process. They could use checksums to make sure the executables don't get changed, but as long as we have a disassembler (hint: we do) we can crack that too. They can make it so
that decrypted code doesn't stay in memory but that doesn't matter because even if it's there for a nanosecond we can get at it. All Apple can do is in the software, and we can change the software. The only surefire way to stump us for a long period of time is to put a new chip
in it that can actually read code without decrypting it in memory first -- and that would take a brand new phone.

Developers, however, have been talking about ways that THEY can detect whether their software was cracked or not. The most popular idea at this point is to have their applications check and see if they're in a "sandbox" or not. See, when you legitimately install an App Store
program, the iPhone gives it its own Documents folder, Library folder, etc -- and when it runs, ALL THE APP CAN SEE are itself and those things. According to the app, that's the entire filesystem. If it tried to look in /Applications, the phone tells the app that /Applications doesn't exist.

So a developer can have a program check to see if /Applications is there, and if it is, the program knows it's been cracked and installed through SSH. Then it can shut itself down.

So how do you get around this?

IPA. Installing an app with the IPA method keeps the app inside the sandbox. There is absolutely no way for the app to know it's been cracked if it's using that method. Developers are ALREADY using this tactic in their programs, so it won't be long until we're finding more and more apps that, once cracked, will ONLY work as IPAs.

Anything else the developers do.. well, that's all software too. A disassembler and a smart mind is all that's needed to get around that, just like cracking software on Windows.

That's all folks
Hopefully I've dispelled some rumors here, and made everyone just a little bit smarter about how this goes. If you only take two little shreds of information from this post, let it be these: Apple already knows exactly how to crack apps so there is absolutely nothing gained by trying to hide our methods from them, and there is absolutely no security-related benefit to using the .app installation over .ipa.

That's been driving me insane

The more you know!




Back to top  Message [Page 1 of 1]

Permissions in this forum:
You cannot reply to topics in this forum