The solution uses the Low-Level Obfuscator app which provides:
By incorporating these features, the Low-Level Obfuscator fortifies your app, making it significantly harder for attackers to exploit. In the following sections, we'll explore how these functionalities work together to protect your iOS applications.
| Platforms | Prerequisites |
| iOS | macOS– v11.0+ (Big Sur or higher) |
| Integrity SDK – v12.0+ |
The best way to start is to set up the LowLevelObfuscator app and the Deobfuscator SDK before moving onto obfuscating.
To use the Deobfuscator SDK and the MacOS application a valid license must be provided.
The licenses are issued per iOS app and are tied to the bundle identifier. Each license should be entered in the MacOS app’s licensing menu and in the initialization function provided by the SDK.
To be able to run the app, and later the SDK, a valid licence should be provided.
The licensing menu can be accessed by choosing the Licensing option from the menu bar in the upper left corner of the screen. To insert a new license a plus button should be clicked. Once a valid license is inserted a bundle identifier will be listed in the menu and marked as valid.
Tip
If you can’t open the program because integrity can’t be verified, go to System Settings -> Privacy & Security -> Open Anyway to verify and open the program.
Code signing settings can be accessed by clicking the list icon that will appear when a provisioning profile has been dragged and dropped to the user interface.
Code signing can be a complex process, often involving multiple parameters and configurations.
This feature offers users a clear overview of code signing information, enabling them to verify the correctness of their parameters.
The Deobfuscator SDK should be imported into the iOS applications by the developer as follows:
c. For an application to run successfully, it is necessary to set the Enable Bitcode option in the Build Settings to the value "No".
d. The license key required for initializing the Deobfuscator SDK can be generated by selecting the licensed bundle ID from the provided list and clicking the "Generate SDK License" button.
e. Import the SDK in your application and initiate the SDK using the generated licence.
This functionality aims to enhance the security of sensitive string constants that can often be found in plain text format within the mobile app executable file. Some examples of such constants are:
The security enhancement is provided in the form of white-box AES encryption performed
during the development process of the iOS mobile application.
Select the appropriate bundle ID from the identifiers drop down menu so that the obfuscation would work properly.
If you do not see your bundle ID it means that the licensing process was not successful!
Tip
To have better control over what is obfuscated it is suggested to extract strings that will be obfuscated in a separate class.
After this process finishes, all string literals that were found in the selected files will be obfuscated.
The second functionality provided by the Low-Level Obfuscator is the Code Obfuscation. The purpose of this functionality is to prevent the attacker from understanding the internal programming logic of the mobile application. This is done by preforming the low-level modification of the executable files in the Mach-O format.
The symbols containing internal names (e.g., class names, function names, variable names, etc.) defined by the developer are extracted from the sections of the Mach-O file and replaced with the randomly generated strings.
In this way the symbols that can be extracted from the final app package during the process of reverse engineering have no descriptive value that can help the attacker to understand the internal programming logic of the mobile application.
Select code signing certificate from the drop-down menu.
Once the obfuscate button is clicked the obfuscation of all the Mach-O files within the application archive will be performed. After the obfuscation process finishes the modified .ipa file will be resigned using the attached provisioning profile and the chosen signing certificate.
The resulting .ipa file will be ready to install on the mobile devices or upload to the App Store.
The Low-Level Obfuscator is still in the early development stage; hence the current version does not provide obfuscation support for .nib or storyboard files.
It is possible that a new application will crash on start. Following section will in detail explain how to recover from this error.
When performing code obfuscation for the first time on a new application it is highly possible that some of the following errors will occur:
This section will provide guidance on how to effectively recover from the errors listed above.
The symbols are identifiers for various elements within the code, such as framework, class, variable or function names. Since code obfuscation is based on symbol concealment, errors can occur when certain symbols are obfuscated inappropriately or not handled correctly. These errors can result in application crashes or inconsistent behaviour because the application cannot find the symbol it needs to execute a particular operation. Inappropriate symbol handing can occur for various reasons, and it may vary from one application to another. In such cases, the best practice is to exclude the problematic symbol from obfuscation by using the whitelist. The usage of whitelist is described in more detail in the Whitelisting section of this document.
To determine which symbols should be whitelisted the following options can be used:
The device console can be accessed from Xcode’s toolbar as follows:
Window -> Devices and Simulators -> Open Console.
Once the console is open and the test device is selected the message stream can be started. If a missing symbol is causing an app to crash, the crash log can be found by searching the key word “Crash” or “Symbol not found”. An example is shown in Figure 20.
The symbols found in console logs will be obfuscated so the original symbol name must be found for a symbol to be correctly whitelisted.
The original name can be found by checking the log file generated in the Logs folder next to the processed .ipa file.
The log file contains the map of original symbol names and the obfuscated names.
If you can’t immediately find the value, try erasing letters at the beginning/end of the string.
Once the original symbol name has been found it should be added to the whitelist and the obfuscation process should be repeated using the original, not obfuscated .ipa file.
After adding a new item to the whitelist, re-obfuscate the .ipa file using “Obfuscate” button. Make sure you are using the original .ipa file!
The results of the obfuscation process can be verified using MachOView, Hex Fiend, IDA Pro or similar third-party software. Your app has now been additionally hardened against malicious attacksReverse engineering poses a significant threat to mobile app security, allowing attackers to extract and exploit sensitive data from app executables. To address this risk, ASEE provides a solution for obfuscating your application.
The solution uses the Low-Level Obfuscator app which provides:
By incorporating these features, the Low-Level Obfuscator fortifies your app, making it significantly harder for attackers to exploit. In the following sections, we'll explore how these functionalities work together to protect your iOS applications.
Karolina is an iOS Software Developer. She works on preventing security attacks on iOS phones and frequently tests ASEE’s applications. Her greatest passions are designing and developing new applications.
