How can we help you today? How can we help you today?
haleyjason
What you want to do, you can't currently do with Reflector ... unless someone out there has an addin that I don't know about. There are a few things you can change the names of, but without doing a decompile and recompile you are going to limited. A .Net assembly file keeps all of its names stored in a byte array and each item is accessed by and index where the first thing is the length of the string (encoded) ... so if you change the length of any of the strings in the user strings byte array you'll have problems ... otherwise for simple changes you can use any hex editor ... but by simple I mean pretty simple like changing "hello world" to "12345678901". The names of types and other non user strings (like function names, namespaces, etc.) are stored in the strings heap. The strings heap is pretty much the same as the user strings - but one HUGE problem you'll run into is .Net loads things by their full name ... which it uses these strings to load/resolve the types JIT. So if you reference System.String and happen to change the string System to Ystsme (or something) you'll break pretty much all strings. The only way I know is to find something that will let you edit things and then create a new version of the assembly for you. You might look into Mono's Cecil libraries (http://www.mono-project.com/Cecil). If you find anything that works for you, I'd be interested to know how it goes. / comments
What you want to do, you can't currently do with Reflector ... unless someone out there has an addin that I don't know about. There are a few things you can change the names of, but without doing a...
0 votes
I forgot to mention, I have some general obfuscation information on my site at http://jasonhaley.com/obfuscation/ which you might be interested in. / comments
I forgot to mention, I have some general obfuscation information on my site at http://jasonhaley.com/obfuscation/ which you might be interested in.
0 votes
Those variables are in the code usually due to a debug build but sometimes the compiler needs to create a temp variable ... so it names it like that. Usually the Reflector translator can determine that it isn't needed and you won't see it in the C# translation - but in your case it is left over unoptimized code that Reflector didn't optimize out. If you change your optimization settings to None (View->Options->Optimization drop down), you'll see a lot more of these. For example, the following code: public class TestA { private string x; public string TestX { get { return x; } } } In debug version the property getter looks like this (notice the local variable CS$1$00000): //////////////////////////////////////////////////////////// .method public hidebysig specialname instance string get_TestX() cil managed { // Code size 12 (0xc) .maxstack 1 .locals init ([0] string CS$1$0000) IL_0000: nop IL_0001: ldarg.0 IL_0002: ldfld string Snippet/TestA::x IL_0007: stloc.0 IL_0008: br.s IL_000a IL_000a: ldloc.0 IL_000b: ret } // end of method TestA::get_TestX //////////////////////////////////////////////////////////// The release version looks like this: //////////////////////////////////////////////////////////// .method public hidebysig specialname instance string get_TestX() cil managed { // Code size 7 (0x7) .maxstack 8 IL_0000: ldarg.0 IL_0001: ldfld string Snippet/TestA::x IL_0006: ret } // end of method TestA::get_TestX //////////////////////////////////////////////////////////// So the short story is ... those variables are in there either due to your compiler and then Reflector not optimizing them out in translating to C# - though Reflector does optimize a lot of them out such as in the property getter above - that CS$ variable will get optimized out unless you set the Optimize=None. / comments
Those variables are in the code usually due to a debug build but sometimes the compiler needs to create a temp variable ... so it names it like that. Usually the Reflector translator can determine...
0 votes