9

If I obfuscate a vb.net assembly using Eazfuscator with symbol names encryption turned on (so that I can use the Eazfuscator stack trace decoder), is this effectively undone if I ship the PDB file? I want to ship the PDB file so that I get line numbers in stack traces that are sent back to me in error reports.

I know I can get line numbers by keeping the PDB file for the shipped version but this is an extra layer of complexity that I don't need right now, I will implement this in the future. I just want to make sure I am not effectively shipping non-obfuscated code by including the PDB file.

Thanks in advance for any advice.

Guy
  • 413
  • 6
  • 20
  • Line numbers are not typically useful in a Release build, the jitter optimizer reorders lines of code. – Hans Passant Aug 30 '11 at 13:17
  • Hmm...interesting..I hadn't heard of this. I will try it out and see if I get incorrect line numbers. Thanks. – Guy Aug 30 '11 at 14:32
  • Hans - You are right. A quick test shows that an error that occurrs on line 1003 is reported as ocurring on 1000. – Guy Aug 30 '11 at 15:54

2 Answers2

4

No, shipping PDB files does not make obfuscation useless. Note however that PDB files can contain names of local variables so that is another piece of information which a disassembler like Reflector can use. PDB files can also contain full paths of the source code files, however, this rarely does any harm in terms of revealing sensitive information.

Some obfuscators like Crypto Obfuscator support PDB file generation - after obfuscation, it outputs new PDB files which are in sync with the obfuscated assemblies so that your stack traces remain correct. Further, the PDB files contain obfuscated names of the source code files mentioned above. It also strips all local variable names from the PDB files.

DISCLAIMER: I work for LogicNP Software, the developer of Crypto Obfuscator.

logicnp
  • 5,796
  • 1
  • 28
  • 32
4

PDBs don't contain actual code. But I have a strong feeling that after obfuscation PDB will be incompatible with binary. Here is what located inside PDB:

  • Public, private, and static function addresses
  • Global variable names and addresses
  • Parameter and local variable names and offsets where to find them on the stack
  • Type data consisting of class, structure, and data definitions
  • Frame Pointer Omission (FPO) data, which is the key to native stack walking on x86
  • Source file names and their lines

As far as I understand obfuscation will ruin things like non-public types, methods, parameters etc. So if it doesn't change original IL offsets, showing line numbers might work, but it will provide some information that was actually obfuscated, question is it recoverable or not.

What I suggest is to add rich logging if you are very concerned about deobfuscation.

Andrey
  • 59,039
  • 12
  • 119
  • 163
  • Andrey - Thanks. I thought that Eazfuscator's stack trace decoder will take care of things, then I thought I better test it. Sure enough, there is no line number in the decoded stack trace, where there is one in a non-obfuscated version. It seems logical to me (now that I know) that the PDB is of no use at the point at which it is needed i.e. when the stack trace is written out, because at that point the obfuscated code and the PDB symbol names do not match. However, given the inaccuracy of the line numbers I'm now not so sure of their value. – Guy Aug 30 '11 at 23:46