使用Reflector反编译
我已经完成了代码的反编译。但它不是显示字符串,而是显示负数。如何找到原始字符串?
我的反编译代码是这样的:
string str = .(-812265445);
它应该是:
string str = "My string";
请帮忙
请注意,当我添加对项目和调试的引用时,它可以看到字符串“My string”而不是 .(-812265445);
当我使用另一个反汇编程序时,它显示:
string str = ACK. STX(-812265445);
I guest ACK 和 STX 是二进制字符。
非常感谢
您的回答,这是我从 ILSpy 拍摄的两张图片,以便更好地想象:
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(-812265445);
I guest ACK and STX are binary characters.
Many thanks
Response for your answers are two pictures I took from ILSpy for better imagine:
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
字符串可能已加密……或者是 Reflector 中的错误。如果它已加密,这将无济于事(调试器是您最好的选择,因为加密器会在应用程序使用字符串之前注入解密代码)。
要使用 Reflector 和 ILDasm 在已编译的程序集中查找字符串:
获取指令旁边的行标签(例如:L_0060: )
在 ILDasm 中打开程序集并找到您正在研究的方法
要验证程序集中存储的字符串,可以执行以下操作:
这应该会将您带到用户字符串元数据堆中的条目,并准确显示二进制文件中编译的字符串。
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:
Get the line label beside the instruction (example: L_0060: )
Open your assembly in ILDasm and find the method you are investigating
To verify what string is stored in the assembly, you can do the following:
That should take you to the entry in the User Strings metadata heap and show you exactly what string was compiled in the binary.
请尝试Telerik Decompiler
Please try Telerik Decompiler
反编译不会返回原始代码。
您的示例看起来像一个简单的“使用字符串地址加载寄存器,用它做一些事情......”。
编译器不会将字符串(或任何数据)与指令内联,数据、字符串、数字都会移动到适当的部分。由于这是一个字符串常量,因此它可能会移至 .data 或 .rodata 部分。
将 -812265445 数字转换为十六进制使它更清晰一些,因为它变成了 0xCF95D01B,一个存储某些内容的有效地址。如果你的输出基数是带符号的十进制(看起来很常见),那么地址通常会出现巨大的负值。将它们转换为十六进制或更改默认值以让您看到(或更容易理解)它们指向的位置。
从这里(你上面的评论),很明显,第0x12行(L_0012)上有一个“带有字符串地址的加载寄存器”,调用“string::...”来转换它(我想),然后store 将生成的“字符串”指针放在某处。
然后在 0x1D-0x27 行再次执行此操作。也许有一个 4 字节长的 const char 字符串(因为第一个和第二个加载(ldc.i4)地址相距 5 个单位。(4 个字符 + 0 个终止符)。
使用调试器或任何您必须的东西来显示这些地址处的内存显示(尽管使用当前程序反汇编中实际存在的内容)并查看其中有什么。
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.
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!