It is well known that most iOS code is generally not encrypted, because iOS apps are generally released via AppStore, and Apple's system is hard to break, so code hardening in iOS is generally a thankless task. Everything is an exception, regardless of iOS, ADR or JS, the purpose of encryption is for code security, although now open source, but regardless of individual developers or manufacturers have the need to protect code security, so iOS code to strengthen the survival of the soil. The following is a brief introduction to iOS code encryption in several ways.
Several ways to encrypt iOS code
1. String encryption
The string exposes a lot of key information about the app, and the attacker can quickly find a handler for the relevant logic based on the string obtained from the interface, thus parsing and cracking. Encrypting a string can increase the difficulty of an attacker reading the code and searching statically based on a string.
The general approach is to encrypt the string that needs to be encrypted, save the encrypted data, and then insert the decryption algorithm where the string is used. The simple encryption algorithm can convert NSString to byte or NSData, and can also put the string back to return, as much as possible to expose the page information. Here is a simple example of converting a nsstring to a 16 binary string:
2. Symbol confusion
The central idea of symbolic confusion is to replace the class name, method name, variable name with meaningless symbols, to improve application security, to prevent sensitive symbols from being extracted by the Class-dump tool, and to prevent tools such as Ida Pro from parsing business code after disassembly. Currently, iOS apps on the market are basically not confused with the class name method name.
A. Aliases
It is probably the simplest way to use aliases when writing code, and a way to work. Because your app is cracked, if it is easy to find clues from your class name, that is only a step away from the hook, before the plug-in to grab the red envelopes should be the way to execute the hook.
B.C rewrite
The way you write aliases is not easy to read, and is not conducive to subsequent maintenance, you may need to upgrade your protection, and C to rewrite your code. This hides the function name in the struct, stores it as a member of the function pointer, compiles, leaves only the address, removes the name and the parameter list, and makes them impossible (copy from Reading). Here's an example:
C. Script Processing
A bit more advanced is the script scan processing replacement code, because to use the Linux command to write scripts, there may be a threshold, but after learning you can go out and brag about your full stack engineer's name ...
Several common commands for Linux scripts are as follows:
Script obfuscation replacement is to scan the above several commands to replace the string, such as the method name, class name, variable name, and do replace, if you can skillfully apply the above several commands, congratulations, you have learned the script of a little fur.
The following script searches through the code directory to confuse the keyword:
The alternative is to scan the file directly and replace all the contents of the file, or you can define the alias in a define way. For example:
D. Open Source Project Ios-class-guard
The project is based on Class-dump extension, and similar to script processing, is to use Class-dump scan out the compiled class name, method name, property name and so on and do replace, but do not support the implicit C method of substitution, interested students can use the next.
3. Confusing code logic
The code logic confusion has the following meanings:
The method body is confused, to ensure that the source code is reversed after the part of the coding is very confusing, because there are some garbage code exists;
The application logical structure is scrambled and mixed, to ensure the readability of the source code is minimized, it is easy to bring the cracker to the ditch;
It has the same functionality as the original code, which is the most critical.
It is common to use OBFUSCATOR-LLVM to confuse code logic, and perhaps a brief introduction to the open Source tool.
iOS encryption may be small, but there must be a reason, in the jailbreak/open source/Geek's eyes, your app is not as safe as you think, if you want your code more secure, you should encrypt the iOS code.
Several ways to encrypt iOS code