Skip to content

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