Here, let me teach you how to crack an iOS APP

Today I will give you some hard knowledge.

There is a type of hackers who are destined to be "mortal enemies" and nemeses of program developers.

They always go against the developers:

The daily routine of developers is to write software with pieces of code to implement various functions.

Their daily routine is to reverse engineer complete software and restore them into pieces of code.

They are the legendary "reverse engineers".

If you were asked to pick a lock with a key, you might feel you had no idea where to start. But if the outer shell of the lock was completely transparent and the internal structure was clearly visible, you would find it much easier.

In the cyber world, reverse engineering is the ability to see through an object.

Give them a mobile phone app or computer program, and it won’t take long for them to reverse the program’s operating logic, find the key codes inside, tamper with, crack, and discover loopholes.

People call this technology "reverse engineering". Most of the cracking software we see on the Internet are related to reverse engineering.

However,

There are both good and evil in the reverse world.

Righteous reverse engineers only do security research, while evil reverse engineers use this skill to do bad things for profit.

For example, pirated software. The programs that developers worked so hard to write were reverse-engineered in a matter of minutes, with ads and Trojans implanted, and then repackaged into pirated versions. Pinduoduo became Pinxixi, and one software had dozens of distant cousins.

For example, some friends always fail to grab red envelopes in the group and suspect that someone is using a plug-in. In fact, the so-called "red envelope grabbing plug-in" is that someone has reverse-engineered the WeChat APP and added a code for automatically receiving red envelopes.

For financial apps that deal with money, reverse engineering is even more of a nightmare. Once the app is reverse engineered, it is easy to face huge losses.

Recently I got in touch with a reverse engineering expert and talked about mobile APP cracking and anti-cracking. Today I would like to share it with you.

This expert is a bit peculiar. Although he is an expert in reverse engineering, he does not crack other people's mobile applications. Instead, he leads a team to help iOS application developers with anti-cracking.

Come, let’s meet this new friend, he is the Vice President of R&D of Tongfudun and the general manager of iOS hardening project, Hua Baojian.

[[245842]]

This guy is very capable. He is a PhD in computer science from the University of Science and Technology of China. He has been working in information security, system penetration and other fields for decades. Around 2015, he also led the research and development projects of Office 365 and Bing Search at Microsoft. Two years ago, he joined Tongfudun and was responsible for technology research and development.

Dr. Hua is devoted to technology and is a shy person, so I was not able to get a 1080P high-definition, uncensored photo of him. I could only get an AV-quality photo from his WeChat profile picture. I believe his technical story is very exciting, but there is still a long way to go, so I will write about it later.

Let’s continue talking about cracking and anti-cracking today.

1. The standard way to crack an app

Hua Baojian told me that there are actually some standard routines to crack an Apple phone APP.

The first step is to unshell.

The so-called "shell" is a layer of "shell code" wrapped on the original software code. When the machine runs the program, it runs the shell code first, which can protect the application's code logic from being easily exposed.

The Apple Store will add a shell to every iOS APP listed.

"However, this layer of shell has no substantial effect."

Hua Baojian said that since the Apple Store uses the same shelling method for millions of apps around the world, reverse engineers and hackers all over the world have been keeping an eye on it. They have long since developed deshelling tools for this type of shell, which are open source and available for free download online. In short, Apple's built-in shell can be removed in minutes.

After unpacking, the second step is decompilation.

At this point, I must first popularize some interesting computer knowledge to everyone.

Dear students, please look at the two people in the picture below. They are early programmers. They are checking the code:

[[245843]]

I don't know who came up with the idea, but early computer codes were recorded directly on long paper tapes by punching holes. A punched hole represented a 0, and no hole represented a 1, corresponding to the on and off state of the electronic components, which controlled the operation of the machine.

This original way of recording code is called "machine code", which is a binary code.

[[245844]]

I believe you have discovered that this code recording method is very troublesome to use.

It is said that at that time, it took several days and nights just to punch holes to write a program, and it was easy to make mistakes. Programmers not only had to punch holes and correct errors every day, but also had to remember a bunch of long codes like 0101010.

Later, someone invented an assembly language, and then began to use English characters to replace strings of binary characters.

From then on, codes like 1000100111011000 can be replaced by a string of letters like "mov ax,bx", which means "move the data in register b (a machine component) to register a".

Later, as programs became more and more complex, assembly language was no longer sufficient, and more advanced languages ​​were born. For example, C, C++, Java, Python, PHP, Rust, Nodejs, etc.

Since then, there has been a debate among programmers about "who is the best programming language in the world"...

So, the rules in today's programming world are as follows:

Programmers first write program codes in high-level languages, and the compiler compiles them into machine codes that the machine can understand for execution.

The work of reverse engineers is exactly the opposite. They grab the machine code directly from the machine, then deassemble it into assembly language, and then decompile it into high-level language.

At this point, congratulations, you have learned the principles of decompilation. Now let's continue to crack iOS applications.

"There are many decompilation tools on the Internet, but generally speaking, the methods can be divided into two categories: static analysis and dynamic debugging."

Hua Baojian said that the so-called "static analysis" is to directly decompile the program when it is not running, converting it from binary machine code into hexadecimal code, then to assembly code, and then to a language that humans can directly understand.

During this process, if the other party does not take any protective measures, you can directly find and change the key information inside, such as copyright information, game values, etc., and challenge the BOSS alone to get equipment.

Hua Baojian told me that since decompilation involves many different languages, it is impossible to directly restore the machine code to the source code, but the logic of the source code can be restored in the form of pseudocode.

The so-called dynamic debugging, as the name suggests, is to run the program first, enter different values ​​into it to observe the reactions of various components and functions, and thus sort out the relationship between them.

If static analysis is compared to translating a foreign comic, dynamic debugging is like translating a Blu-ray high-definition coded foreign blockbuster.

During the entire process, reverse engineers need to debug repeatedly and set "breakpoints" on the program so that they can pause at any time to appreciate and play with it repeatedly.

After these two steps, the operating logic of a program is completely restored. Next, you only need to find loopholes in key parts such as login verification, encryption, and authorization, tamper with key data, complete the cracking, and do whatever you want.

Finally, you can buy an iOS signature online and repackage the code into an APP and install it on your own or someone else’s phone.

Hua Baojian: At this point, the process of cracking an iOS application has been explained. In fact, cracking is very simple. There are only three steps: unpacking, decompiling, and signing and packaging. Do you understand?

Xie Yao: Got it!~

Hua Baojian: OK, now that you understand, just find an APP to practice. Why not try to crack WeChat?

Xie Yao: Uh... this...

[[245849]]

2. How to crack the system

Once you understand the basic routines of reverse cracking, you will naturally be able to prescribe the right remedy.

Huajianbao’s solution is to reinforce the APP.

If you have played the game "Plants vs. Zombies", you will understand the meaning of "APP reinforcement".

Hua Baojian told me that the first step of Tongfudun’s iOS hardening is “environmental testing”.

They will place many probes on the outermost layer of the APP, which monitor the running environment in real time. Once they find that the phone is in a jailbroken state, or that there are reverse analysis tools in the environment, they will immediately enter an alert state, issue an alarm, or directly crash the program.

This makes me imagine 10,000 potato mines surrounding the code...

The second step is called threat perception.

In addition to detecting the running environment, the probe also monitors the running status of the application in real time, because once the program is terminated midway, it means that someone has set a "program breakpoint" and is doing dynamic debugging.

The third and fourth steps are somewhat similar, namely constant encryption and symbol hiding.

There are some contents in the code that are always the focus of crackers, such as some strings called passwords and some secret URLs.

In order to prevent crackers from locating these key positions, "Constant Encryption" will encrypt and hide these key characters. "Symbol Hiding" is similar, and also encrypts and hides some class names, method names, and attribute names.

In short, the key to these two steps is "coding" to protect key parts.

The fifth step is "code logic obfuscation".

This is actually very easy to understand. Let me give you an analogy:

You want to go to the supermarket to buy Okamoto toilet paper and Durex, but you don’t want anyone to know, so you go to buy Okamoto and sweet potato first, then run two laps on the playground, go to the supermarket again to buy toilet paper and Coke, and finally buy Durex.

Although you bought Okamoto toilet paper and Durex in the end, you hid the purpose of your actions.

This is what "code logic obfuscation" does. It adds all kinds of redundant junk instructions and codes to clear and concise code, splits the original logic into various weird syntaxes, and changes it so that even its mother can't recognize it, thereby preventing it from being cracked.

"Once these steps are completed, the difficulty of reverse cracking will be greatly increased. Although theoretically there is no system that cannot be cracked, as long as the cost of cracking is increased high enough, hackers will give up cracking or turn to easier targets."

Hua Baojian said.

As long as the reinforcement is done, it can resist most cracks?

Yes.

It sounds like anti-cracking is quite simple, that's it.

However, reality is always more cruel than you imagine.

3. “Reinforcement is impossible”

"What bothers me is not that it cannot withstand reverse cracking, but that developers are unwilling to use hardening."

Hua Baojian said that currently only about 20% of iOS applications on the market have been reinforced, among which the proportion of financial apps is slightly higher, but it is only about 50%. Many small and medium-sized financial institutions and even bank apps have not been reinforced.

Xie Yao: What? If reinforcement is so safe, why do people like to run naked?

Hua Baojian: Because streaking is cooler~

Xie Yao: ???

Hua Jianbao said that although the previous reinforcement methods were safe, they also had obvious disadvantages, which is the same as "wearing too many clothes will make you look bloated" (it is indeed cooler to run naked... )

The first is to slow down program performance.

Take code logic obfuscation for example. A task that could originally be completed in one step now has to be divided into many steps. In order to confuse the opponent, one has to deliberately take his time, which will only slow down performance.

Secondly, the program size will be larger.

"Generally speaking, source code-based reinforcement methods can increase the size of the program by 20 to 30%," Hua Jianbao said frankly, and many developers cannot accept this because the increase in size will reduce users' desire to download.

However, what developers cannot stand the most is the risk of code leakage and compatibility issues brought about by hardening.

"Traditional iOS application hardening technology generally adopts the source code compilation method, which requires developers to submit the source code of the program to a third-party hardening platform. This alone makes many developers back off."

"Moreover, the source code-based reinforcement process requires repeated code changes, which may affect the compatibility and adaptation of the model and system version, causing the program to crash and affect the user experience."

Hua Baojian admitted that for a long time, he was not thinking about how to resist more powerful reverse crackers, but was solving the problem of "how to make developers willing to use reinforcement."

At first, they tried to "dance with shackles" and sacrificed a small amount of safety to improve performance, but found that it did not solve many problems, and blindly reducing the reinforcement strength was obviously not a solution.

Hua Baojian and his team spent more than half a year researching before they came up with a new idea.

So they began to borrow the technical ideas of "shelling" Android applications and directly added a special shell to the IPA (iOS program installation package) of iOS applications. On this basis, they used the underlying binary code to extract the key code logic from the program for obfuscation.

In this way, developers no longer need to upload program source code to third-party hardening vendors, and since there is no need to perform a large amount of logical obfuscation and modification on the source code, the hardening performance, installation package size, and compatibility can all be taken into account.

According to Huabaojian, developers can upload the IPA installation package to their hardening platform and the hardening can be completed directly in 10 minutes.

I haven’t had time to do a detailed test on the specific experience and strength of Tongfu Shield’s iOS reinforcement. If you are interested, you can try it yourself.

But having said that, I suddenly realized that the problem encountered by Huabaojian, "how to balance security and experience", is actually encountered by most security entrepreneurs.

I once met a friend who started a security business and was very puzzled. He said that his product was obviously better and more secure than the competitors' technology, so why couldn't it beat other competitors?

After a long journey, I finally realized that it was because his product was too difficult to use! My friend is a straightforward technical person who only wanted to maximize the security strength, but he overlooked one thing: the essence of security is to maintain the business, and the essence of technology is to output practical value.

Whether it is a person or a company, occasionally changing the perspective may seem like a compromise, but in fact it is also a way of retreating to advance.

Finally, let me introduce myself. My name is Xie Yao, a science and technology popularizer. I usually explain various advanced technical knowledge and black technology in a popular and interesting way.