Comment by jfactorial
Comment by jfactorial 8 days ago
> Why would you assume that?
I thought too highly of modern compiler string literal obfuscation.
Comment by jfactorial 8 days ago
> Why would you assume that?
I thought too highly of modern compiler string literal obfuscation.
What obfuscation? Do you think that is happening automatically? If you compile literals into your program they are sitting in the data section of your binary verbatim so they can be read directly once the binary itself is memory mapped.
There's at least one plugin for LLVM to obfuscate strings from binaries [1], and for Android there is DexGuard [2]. The general idea is to make life as difficult as possible for reverse engineers, crackers and whomever else - hardcoded stuff just showing up in "cat .binfile | strings" is about the first thing I do when investigating some random stuff, and there's tools like binwalk that can automatically do stuff like extracting PEM certificates and other easily identifiable content.
Of course they can all be reverse engineered by hand, if you figure out the scheme used you can write yourself an IDA or Ghidra plugin/script to automate the process - which assumes that the method doesn't (subtly) change between different builds of the target. Or you can attempt to intercept memory accesses of the application. But that's tedious, annoying and complex busywork that no one really wants to do.
Compilers are there to make things more efficient for the machine running the code. Obfuscating a string is the opposite of that. What they actually do much of the time is collect all the string literals into a contiguous pool so that their addresses are fixed and well-packed, providing efficiency at runtime.
It's actually very easy to find string literals in executables because of this, not hard.