Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

string encryption pass #18

Open
wants to merge 12 commits into
base: llvm-3.4
Choose a base branch
from
Open

Conversation

yag00
Copy link

@yag00 yag00 commented Jan 19, 2015

functional string encryption pass. Some strings are not handle (skipped by the pass and left unencrypted...)

@jeffcasavant
Copy link

I've got a bug in this pass (same bug is in #11). I have two files, other.c and test.c. Their contents are as follows:

test.c

#include <stdio.h>

extern const char OPT_HELP_STR[];

int main() {
  printf(OPT_HELP_STR);
  return 0;
}

other.c

const char OPT_HELP_STR[] = "test pass";

When I compile this without the pass, it runs as expected.

/home/casavant/obfuscate/build/bin/clang test.c other.c -o obf_non02015-06-19_10:17:41
test.c:6:10: warning: format string is not a string literal (potentially insecure) [-Wformat-security]
  printf(OPT_HELP_STR);
         ^~~~~~~~~~~~
1 warning generated.

The output of the executable is test pass.

When I compile this with -xse, I get an undefined reference error at the linker step.

/home/casavant/obfuscate/build/bin/clang test.c other.c -mllvm -xse -o obf_xor02015-06-19_10:17:41
test.c:6:10: warning: format string is not a string literal (potentially insecure) [-Wformat-security]
  printf(OPT_HELP_STR);
         ^~~~~~~~~~~~
1 warning generated.
/tmp/test-9cbd75.o:test.c:function main: error: undefined reference to 'OPT_HELP_STR'
clang-3.5: error: linker command failed with exit code 1 (use -v to see invocation)
Makefile:6: recipe for target 'current' failed
make: *** [current] Error 1

Commenting out lines 70-73 in AbstractStringEncryptionPass.cpp alleviates this issue (but it neuters the pass since the plaintext strings are left in place). It seems that the issue is in what checkStringsCanBeEncrypted is deciding can be encrypted (if I had to bet; I have still not delved too deeply into this problem).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants