Decompile with Reflector
I have done decompile the code. But instead of display string, it display an negative number. How can I find the original string?
My decompiled code like this:string str = .(-812265445);
it should be:
string str = "My string";
Please help
Note, when I add reference to project and debug, it can see the string "My string" not .(-812265445); When I use another disassembler program, it display:string str = ACK. STX(-812265开发者_如何学C445);
I guest ACK and STX are binary characters.
Many thanks
Response for your answers are two pictures I took from ILSpy for better imagine:
Chances are the string is encrypted ... or its a bug in Reflector. If its encrypted this won't help (the debugger is your best bet because encryptors inject the decrypt code right before your application uses the string).
To find a string in a compiled assembly using Reflector and ILDasm:
- Open Reflector and find the member/method you are investigating
- Change the language from C# to IL (in order to see what ILDASM will show you)
- Verify the string is still not showing correctly
Get the line label beside the instruction (example: L_0060: )
Open your assembly in ILDasm and find the method you are investigating
- Locate the instrucion label from Relector (should be the same line like IL_0060: )
- If the string is still not correct here, then the string has been encrypted
To verify what string is stored in the assembly, you can do the following:
- In ILDasm, close the dialog showing the IL for the method
- Go to the View menu and Check Show Tokens
- Open the method up again in ILDASM, this time when you locate your line of code it should have a token after it like /* 70002C92 */ (of course your number will be different) but this is where the string is located in the user strings metadata heap of the assembly.
- Go to the View -> Meta Info and check Raw:Heaps
- Go to the View -> Meta Info and Show!
- In this new dialog, go to the Find Menu and put your token in there and click find
That should take you to the entry in the User Strings metadata heap and show you exactly what string was compiled in the binary.
Please try Telerik Decompiler
Decompiling won't return the original code.
Your example looks like a simple 'load register with address of string, do something with it...'.
The compiler doesn't put strings (or any data) inline with the instructions, the data, strings, numbers, are all moved to appropriate sections. Since this is a string constant, it's likely moved into the .data or .rodata section.
Converting your -812265445 number to hex makes it a little clearer, since it becomes 0xCF95D01B, a valid address to store something. If your output-radix is signed decimal (the usual it seems), then addresses often end up huge negative values. Convert them to hex or change your defaults to let you see (or more easily grok) where they point.
L_0012: ldc.i4 -812265440 (0xCF95D020)
L_0017: call string ::(int32)
L_001c: stloc.0
L_001d: ldc.i4 -812265445 (0xCF95D01B)
L_0022: call string ::(int32)
L_0027: stloc.s str5
From this (your comment above), it's plain there is a 'load register with address of the string' on line 0x12 (L_0012), a call to 'string::...' to convert it (I suppose) and then a store to put the resultant 'string' pointer somewhere.
Then you do it again on lines 0x1D-0x27. Maybe with a 4 byte long const char string there (since the first and second load (ldc.i4) addresses are 5 units apart. (4 chars + 0 terminator).
Use your debugger or whatever you have to display the memory at those addresses shown (use whatever's actually in your current program disassembly though) and see what's there. Explore!
精彩评论