Prevent Tweak Attachment

clamshell, and then throws the decrypted binaries to a decompiler like a hopper. Directly dumping a binary file without a clamshell. The decompiled content of the hopper is unreadable (encrypted by Apple). So the clamshell is the first step in cracking the analysis app. There are two ways to prevent this step:

Limit the sections in the binary header by configuring the build setting option in Xcode:

-Wl,-sectcreate,__RESTRICT,__restrict,/dev/null

Added to "Other Linker Flags" (Note that I have encountered a problem in the project here, on the iPod touch iOS 9.3 device, using the swift project will cause the inexplicable swift standard library not to be found. This is not the case on iOS 10 devices.

I didn't think it was because I added this until I found all the solutions online. For example, when this SO Post has no effect, I found out that this is the reason for this setting.

Setuid and setgid (Apple does not accept the app that calls these two functions, because it can look at the symbol table to determine if your binary run file contains these two functions)

Check if There is a Targeted Tweak on the Jailbroken Device

Generally，on the jailbroken phone, we will use The OS to create a tweak type of project. Then for the class we want to analyze, use the mk file generated by the provided logify.pl command to print the input and output parameters of all methods of the class. This is a great help in analyzing how the app works. Of course, we can also create a class's MK to hook a function and let it run the way we want it. For example, for some apps that do certificate binding, if the framework it uses is AFNetWorking, then we can create a mk file hook AFSecurityPolicy class with the following methods:

- (BOOL)evaluateServerTrust:(SecTrustRef)serverTrust forDomain:(NSString *)domain

Let this method always return YES, then the certificate bindings made by most applications will be invalid. If you have used the tweak template of TheOS, you will find this method quite simple and fast.

For the prevention of this step, you can add a layer of judgment in the main function of the project. First, read the contents of all the plist files under /Library/MobileSubstrate/DynamicLibraries to see if a plist contains the bundle id of your app. You can decide that someone wants to use the tweak to attack your app. At this time, you can take measures such as crashing the app or restricting certain functions.

To put it simply, MobileSubstrate will check if there is a tweak to be loaded under /Library/MobileSubstrate/DynamicLibraries when the app is loaded into memory. If it is loaded, how can I tell if there is any? It is judged based on the bundle ID in plist. There are many friends use ccie rs lab dumps from spoto and got their ccie number .

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, 0 means no

    return cnt;

}

Anti-http Capture

Usually crack an app, we will capture the package. In this case, all the interfaces of our app, interface data will be exposed under the eyes of the reverse personnel. At this time, we can limit http capture. The simple way is to set the connection Proxy Dictionary of NSURLSessionConfiguration to an empty dictionary, because this property is used to control the available proxy for the session. See the official documentation for reference, which is reference 5. Here's how to use AFNetWorking:

// inherit AFHTTPSessionManager，Rewrite the following methods

- (instancetype)initWithServerHost:(PDLServerHost*)serverHost {

#ifdef DEBUG

    // The debug version of the package can still capture packets normally.

    self = [super initWithBaseURL:serverHost.baseURL];

#else

// Requests initiated using ephemeralSessionConfiguration session without cookies and caching, etc.

    NSURLSessionConfiguration *conf = [NSURLSessionConfiguration ephemeralSessionConfiguration];

    conf.connectionProxyDictionary = @{};

    self = [super initWithBaseURL:serverHost.baseURL sessionConfiguration:conf];

#endif

    return self;

}

However, since the OC method is easy to hook and avoid capturing packets, it is impossible for individuals to think that the best way is to encrypt the request parameters (preferably asymmetric encryption, such as RSA).