There are other reasons for wanting to obfuscate your code. For example someone using bsdiff/bspatch to have your license checking code always return true. From a cybersecurity standpoint your code should always be protected. If an attacker can run strings and find "check license" it makes finding the verification function trivial.
Your assertion that this is "security through obscurity" is simplistic at best. In your view is code flattening the same?
I would suggest you look at :
https://mas.owasp.org/MASTG/iOS/0x06j-Testing-Resiliency-Against-Reverse-Engineering/#frida-detection
Post
Replies
Boosts
Views
Activity
Ghidra makes reverse engineering trivial, and free see https://ghidra-sre.org/InstallationGuide.html
In a case I'm working on substituting 20 00 80 D2 C0 03 5F D6 for FF 03 03 D1 F6 57 09 A9 at offset 00000001005DE584 bypasses our license and verification of integrity completely! That code simply does mov x0 #1 and then a ret.
Obfuscation would make finding that very hard, as it is a simple string search gives the code location away. Instead of picking through 21mb of code to try to find that one set of call you do a string search and bingo.
I'm looking for a good obfuscator for both Objective-c and swift.
I'm in the same boat. I'm looking at expanding this repo;
https://github.com/kam800/MachObfuscator/tree/master/Sources/App
Sad that Apple removed the llvm obfuscation tool years ago.
It appears that Quinn "The Ekimo" is not aware of how hackers work. As a pen tester with almost a decade of experience I LOVE the fact that there is no way to protect string literals, as the senior software security engineer of a large company I'm horrified by his stance.
Preventing debugging is trivial, hooking is a different *****. In hooking the symbol table for the dynamically linking methods/functions is altered.I want to be able to know when that table has been changed!
Look at the code in https://github.com/GGossip/InjectLib, /macOS-InjectPluginCode/InlineInjectPlugin/InlineInjectPlugin.m
//Adobe Illustrator
if (checkAppVersion("27.5.0")) {
NSLog(@"Loading com.adobe.illustrator 27.5.0");
hookPtrA(0x100BF9F84, ret1);
}
```BOOL hookPtrA(intptr_t addr, void *replaceMethod, void **retOriginalFunctionAddress) {
return hookPtr(0, addr, replaceMethod, retOriginalFunctionAddress);
}
int ret1(void) {
NSLog(@"==== return value 1.");
return 1;
}
The code that is supposed to check for a valid license, by simply changing the pointer in the link symbol table the licensing is bypassed.
This may not seem like a big issue BUT hooking dynamic libraries is very common and very dangerous. For example Pegasus/Trident used it to achieve persistence. I was on the team at LookOut that did the initial reverse engineering on Pegasus/Trident.
What I'm looking for is a way , at runtime, to verify the symbol table hasn't been altered.
So there are no "bad licenses" to check for!
We are using a hardened runtime.
One thing I am recommending is that the license checker doesn't return a bool, I was thinking something like a key modded by something variable, but that we can verify.