Prevent tweak from being attached
Generally speaking, we need to analyze an app, which is usually smashing the shell at the beginning.
$ DYLD_INSERT_LIBRARIES= /path/to//XXX
Then throw the decrypted binary file to a decompiler like Hopper for processing. It is unreadable to throw the binary file that has not been smashed into a Hopper and decompiled content (encrypted by Apple). So smashing the shell is the first step in cracking and analyzing the app. There are two ways to prevent this step.
1. Restrict segments in binary file header
By project configuration in Xcode, the build setting option
-Wl,-sectcreate,__RESTRICT,__restrict,/dev/null
Add to "Other Linker Flags" (Note that I encountered a problem in the project here. On iPod touch iOS 9.3 devices, using swift will cause the inexplicable swift standard library to be found, while on iOS 10 devices there is no problem. I didn't think it was because of the addition of this. Until I searched for all solutions online, such as this SO Post, I found that it was the reason for this setting)
and setgid
Apple does not accept apps that call these two functions, because it can tell whether your binary run file contains these two functions by looking at the symbol table.
Detect whether there is targeted tweak on jailbreak devices
Generally speaking, on jailbreak phones, we will use TheOS to create tweak-type projects. Then, for the class we want to analyze, use the mk file generated by the provided command to print the in and out parameters of all methods of the class. This is of great help in analyzing how the app works. Of course, we can also create a certain class mk to hook a function and let it run the way we want. For example, for some apps that have certificate binding, if the framework it uses is AFNetWorking, then we can create an mk file and hook the following methods of the AFSecurityPolicy class:
- (BOOL)evaluateServerTrust:(SecTrustRef)serverTrust forDomain:(NSString *)domain
If this method returns YES forever, then the certificate binding made by most applications will be invalid. If you have used TheOS's tweak template, you will find this method is quite simple and fast.
For this step of prevention, you can add a layer of judgment to the main function of the project. First, read the contents of all plist files under /Library/MobileSubstrate/DynamicLibraries to check whether a plist contains the bundle id of your app. If so, it can be determined that someone wants to use tweak to attack your app. At this time, you can use methods such as crashing the app or restricting certain functions to deal with it.
For the specific principle, you can check Reference 4. Simply put, when the app loads into memory, you will first check whether there is a tweak that needs to be loaded under /Library/MobileSubstrate/DynamicLibraries. If so, load it. How to determine whether it is available? It is judged based on the bundle ID in the plist.
The code reference is as follows
static __inline__ __attribute__((always_inline)) int anti_tweak()
{
uint8_t lmb[] = {'S', 'u', 'b', 's', 't', 'r', 'a', 't', 'e', '/', 'D', 'y', 'n', 'a', 'm', 'i', 'c', 0, };
NSString *dir = [NSString stringWithFormat:@"/%@/%@%s%@", @"Library", @"Mobile", lmb, @"Libraries"];
NSArray *dirFiles = [[NSFileManager defaultManager] contentsOfDirectoryAtPath:dir error:nil];
NSArray *plistFiles = [dirFiles filteredArrayUsingPredicate:
[NSPredicate predicateWithFormat:
[NSString stringWithFormat:@"%@ %@%@ '.%@%@'",@"self", @"EN", @"DSWITH", @"pli", @"st"]]];
int cnt = 0;
for (NSString *file in plistFiles) {
NSString *filePath = [dir stringByAppendingPathComponent:file];
NSString *fileContent = [NSString stringWithContentsOfFile:filePath encoding:NSUTF8StringEncoding error:nil];
if (fileContent && [fileContent rangeOfString:[[NSBundle mainBundle] bundleIdentifier]].location != NSNotFound) {
cnt ++;
}
}
// Returns the number of tweaks for this app, which is 0, which means there is no return cnt;
}
Prevent http packet capture
Usually, if you crack an app, we will catch the package. In this way, all interfaces and interface data of our app will be exposed to the noses of reverse personnel. At this time, we can restrict http packet capture. The method is very simple, which is to set the connectionProxyDictionary of NSURLSessionConfiguration to an empty dictionary, because this property is used to control the available proxy for the session. You can refer to the official documentation, that is, Reference Material 5. Here is how to use AFNetWorking:
// Inherit AFHTTPSessionManager and rewrite the following methods- (instancetype)initWithServerHost:(PDLServerHost*)serverHost {
#ifdef DEBUG
// The debug version of the package can still capture the package normally self = [super initWithBaseURL:];
#else
// Requests initiated using ephemeralSessionConfiguration session do not contain cookies and cache, etc. NSURLSessionConfiguration *conf = [NSURLSessionConfiguration ephemeralSessionConfiguration];
= @{};
self = [super initWithBaseURL: sessionConfiguration:conf];
#endif
return self;
}
However, since the OC method is easily hooked, it is impossible to avoid packet capture. Therefore, I personally think the best way is to encrypt the request parameters (preferably asymmetric encryption, such as RSA).
Obfuscated (or encrypted) hard-coded plaintext strings
For binary files that are smashed, reverse analysts have an important clue to analyze the code, which is a hard-coded plain text string. For example，your app Been caught，Some data request interfaces have also been discovered，So very simple，Reverse personnel can directly copy more obvious strings to hopper Search，By viewing where the string is quoted，You can quickly find the corresponding logic code。
For this step of prevention, all you need to do is to encrypt or obfuscate the hard-coded plaintext. There is an open source code that can be used, UAObfuscatedString, but the string written by this open source obfuscated code is quite long (that is, troublesome), and does not support encryption. Recently I wrote a tool that can encrypt plaintext strings in all code during compilation and decrypt strings while the app is running. The features of this tool are as follows:
1. Simple, developers can hardcode plain text strings, all encryption will be processed automatically at the start of compilation
2. You can customize encryption or obfuscation methods (in order not to affect the operation efficiency of the app, you need to provide a simple and fast encryption or obfuscation method) to improve the difficulty of decryption.
Developed with Swift
Swift is currently a relatively new iOS language. Since Swift is not very stable yet, the jailbreak open source community's support for this is not very instant. For example, the class-dump tool currently does not support binary files containing Swift. TheOS has only recently started supporting Swift, but has not been added to the main branch (see Features). So at present, at least Swift may be a little safer than pure OC projects. Of course, this advantage may not be obvious when Swift becomes increasingly stable and the gradual support of the jailbreak open source community.
Use static inconnected C functions
Due to the dynamic nature of the OC language, the code of OC is the easiest to be cracked and analyzed. In terms of security, functions written in C are recommended. However, functions in C language can also be hooked, and there are three main ways:
1. Use Facebook's open source fishhook
2. Methods to use hook C language functions provided by MobileSubstrate
void MSHookFunction(void* function, void* replacement, void** p_original);
3. Use mach_override. For the difference between mach_override and fishhook, please see the difference between mach_override and fishhook.
Because the above three methods can hook C functions. The solution to avoid being hooked is to use static inline functions. In this way, the function that needs to be hooked has no unified entry, and the reverse personnel can only understand the logic of the function if they want to crack it.
Using block
Strictly speaking, using blocks does not greatly improve security, because as long as reverse personnel find a way to use the block, generally speaking, there will be logic in the block code near it.
However, I personally believe that the security of using block is higher than the direct use of oc method. In my experience in reverse analysis apps, I don’t know how to hook the block method (if you know, you can add an issue on the blog to tell me, thank you in advance). At the same time, for blocks containing nested or blocks passed as parameters, it is even more complicated to process. Therefore, if the converging C function, nested block, and block type parameters can be combined, the security should be improved.
Code obfuscation
There are several ways to obfuscate code:
Adding useless code snippets that don't affect logic, confusing reverse personnel
Name the key classes and methods as names that are not related to the real intention.
I personally think the best encryption obfuscation tool is ios-class-guard, but the project has been stopped at present. But I think this confusion is the ultimate solution.
Other methods
For example, ptrace anti-debugging, etc. (but it is said that it can be easily bypassed)
// see //Crack_prevention for detail
static force_inline void disable_gdb() {
#ifndef DEBUG
typedef int (*ptrace_ptr_t)(int _request, pid_t _pid, caddr_t _addr, int _data);
#ifndef PT_DENY_ATTACH
#define PT_DENY_ATTACH 31
#endif
// this trick can be worked around,
// see /questions/7034321/implementing-the-pt-deny-attach-anti-piracy-code
void* handle = dlopen(0, RTLD_GLOBAL | RTLD_NOW);
ptrace_ptr_t ptrace_ptr = dlsym(handle, [@"". UTF8String]);
ptrace_ptr(PT_DENY_ATTACH, 0, 0, 0);
dlclose(handle);
#endif
}
Things to note
By understanding the runtime characteristics of OC and the structure of mach-o binary files, with the help of existing tools, you will find that the hook method is very simple to complete. Although I mentioned several solutions to improve security above, all of these methods only increase the reverse difficulty of reverse personnel and cannot make the app indestructible. However, taking certain measures will definitely be safer than taking no measures.
The above is a detailed discussion on how IOS can securely reinforce the app. For more information about how IOS can securely reinforce the app, please pay attention to my other related articles!