Known "Bugs"

Every single bug listed below is directly extracted from @LeadroyaL 's blog

My implementation is far from perfect and I'm more than happy to discuss such issues, but calling someone else's DOCUMENTED FEATURE a "very stupid bug" multiple times while can't even provide any reasonable improvement himself is just beyond me

Strings are copied on a per-function basis so the following code won't work:

#include<stdio.h>
char hello[] = "HelloWorld!\n";
void repeat(){
printf(hello);
}
int main(){
hello[0] = 'A';
printf(hello);
repeat();
return 0;
}

This "very stupid bug"(direct quote from his blog) 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.

Parallel Access to StringEncrypted function results in racing condition:

Also documented since the very beginning.
Our guy also purposed a "solution" using pthread APIs. Below is his purposed fix.

bool isDecrypt = 0;
pthread_mutex_t lock;
 
__attribute__ ((constructor(101)))
void before(){
    pthread_mutex_init(&lock, 0);
}
 
int func(){
    if(!isDecrypt){
        pthread_mutex_lock(&lock);
        if(!isDecrypt){
            xor_decrypt(data);
            isDecrypt = 1;
        }
        pthread_mutex_unlock(&lock);
        pthread_mutex_destroy(&lock);
    }
    printf(data);
}

I wonder why nobody has ever thought of this implementation. Oh wait, I did! Why I didn't do this?

• Constructing the type for pthread_mutex_t could be very troublesome and error-prone
• 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 and nop the comparison part, essentially bypassing the whole protection. Genius move!
• 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.
• Also, hey genius you really shouldn't call pthread_mutex_destroy at the end, imaging the function is called again : )

Cross-TU String Reference is handled incorrectly:

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.

StringEncryption inserts junk code even if the function contains no string references

This is probably the only actual bug, congratulations! Although it should be apparent that the actual impact of this bug is approximately zero.

EDIT: Just so you know, all these StringEncryption "bugs" are fully documented (maybe except the last one) and there are methods to disable/enable them on a function-by-function basis. Imagine someone actually read the documentation before asking questions. Very surprising and unexpected, I know.