views:

98

answers:

1

I have been asked to help with a C# project where the source code is no longer available. Fortunately a non-obfuscated debug build of the project is available, so I ran it through Reflector and the reconstructed source code looks largely fine.

There is one oddity that I have a question about. Some objects that pretty clearly should be a string are coming out like this:

string str7 = new string();
str7.Value = strArray3[k];

Now, string does not have a parameterless constructor nor does it have a Value property. I think I can just remove the instantiation and remove the .Value property and things will probably work as expected, but I would like to understand if there might be something more going on than a Reflector bug.

One other interesting piece is that almost all of the variables were reconstructed with original-sounding names, but this one (and a few others) seem to have been assigned random names.

Any insight is very welcome.

+1  A: 

Can you post both the IL and decompiled C# for the same method where this happens?

There isn't by chance a "class string { ... }" in that assembly, is there?

Ben Voigt
D'oh! Yes, there is a class string in the assembly. It was included without any namespace declaration like public class @string (@ to be able to use a language keyword as a symbol... just learned about that last week). Is this possibly an artifact of the reverse engineering process? Hard to imagine why anyone would intentionally code that way.
Eric J.
The name of the class isn't an artifact of reverse engineering, but Reflector could well have a bug in the C# decompiler that fails to escape every reference. After all, a class conflicting with a keyword name is rather an obscure case. As for why, possibly the programmer was trying to duplicate a class by that name in another language, or possibly they were using obscure features on purpose, knowing that decompiler support would be poor, to foil reverse engineering. Score one for psychic debugging.
Ben Voigt