-
Notifications
You must be signed in to change notification settings - Fork 550
Known "Bugs"
#include<stdio.h>
char hello[] = "HelloWorld!\n";
void repeat(){
printf(hello);
}
int main(){
hello[0] = 'A';
printf(hello);
repeat();
return 0;
}
This is documented since the very beginning. The reason is that not many people will write code like that, and this kind of implementation helps to prevent cases that one dump of the decrypted string broke the encryption on all global references.
Flags in FunctionCallObfuscate
uses hard-coded values from host platform and could be wrong in cross-platform environments and could break on non-Apple platforms:
This is by-design because most users of this project are only targeting Apple platform and it's probably stupid to ask for the value from naive users. In the private version, this valve is calculated on-the-fly depending on target triple.
Also documented since the very beginning.
A seemingly straightforward using pthread
APIs.
Why I didn't do this?
- Constructing the type for pthread_mutex_t could be very troublesome and error-prone due to many reasons.
- By simply analyzing the assembly, the attacker could obtain a one-to-one mapping for the flag and its corresponding function. Then he/she could just hook
pthread_mutex_unlock
and dump out the decrypted strings, then he/she could just write dumped strings back andnop
the comparison part, essentially bypassing the whole protection. - Your
pthread_mutex_lock
should be placed at the very beginning otherwise the comparison might leads to racing condition too afaik. This leads us to the next issue. - Since the function needs to do lock/unlock on every entry, blindly implementing this could introduce another heavy performance overhead on functions that don't need to be thread-safe. Thus I documented this behaviour and asks the user to manage their own thread safety structure.
- Since the function needs to do lock/unlock on every entry, you really shouldn't be calling
pthread_mutex_destroy
for obvious reasons.
The following two code snippets won't compile due to original string wiped:
#include <stdio.h>
extern char c[10];
int main() {
printf("c=%s\n", c);
}
#include <stdio.h>
char c[10] = {'1', '2', '3', '4', '5'};
Also documented since the very beginning.
Probably an actual bug but the user could just disable the option for affected functions