Known "Bugs"

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 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.
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 and nop 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.

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

Probably an actual bug but the user could just disable the option for affected functions