使用Reflector反编译

发布于 2024-12-09 17:54:10 字数 437 浏览 0 评论 0原文

我已经完成了代码的反编译。但它不是显示字符串,而是显示负数。如何找到原始字符串?
我的反编译代码是这样的:

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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

只是在用心讲痛 2024-12-16 17:54:10

字符串可能已加密……或者是 Reflector 中的错误。如果它已加密,这将无济于事(调试器是您最好的选择,因为加密器会在应用程序使用字符串之前注入解密代码)。

要使用 Reflector 和 ILDasm 在已编译的程序集中查找字符串:

  1. 打开 Reflector 并找到您正在研究的成员/方法
  2. 将语言从 C# 更改为 IL(以便查看 ILDASM 将向您显示的内容)
  3. 验证字符串是否仍无法正确显示
  4. 获取指令旁边的行标签(例如:L_0060: )

  5. 在 ILDasm 中打开程序集并找到您正在研究的方法

  6. 从 Relector 中找到指令标签(应该与 IL_0060: 相同的行)
  7. 如果此处的字符串仍然不正确,则字符串已加密

要验证程序集中存储的字符串,可以执行以下操作:

  1. 在 ILDasm 中,关闭显示该方法的 IL 的对话框
  2. 转至“视图”菜单并选中“显示令牌”
  3. 在中再次打开该方法ILDASM,这次当您找到代码行时,它后面应该有一个标记,如 /* 70002C92 */ (当然您的数字会不同),但这是该字符串位于程序集的用户字符串元数据堆中的位置。
  4. 转到视图 ->元信息并检查 Raw:Heaps
  5. 转到视图 ->元信息和显示!
  6. 在这个新对话框中,转到“查找”菜单并将令牌放入其中,然后单击“查找”,

这应该会将您带到用户字符串元数据堆中的条目,并准确显示二进制文件中编译的字符串。

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:

  1. Open Reflector and find the member/method you are investigating
  2. Change the language from C# to IL (in order to see what ILDASM will show you)
  3. Verify the string is still not showing correctly
  4. Get the line label beside the instruction (example: L_0060: )

  5. Open your assembly in ILDasm and find the method you are investigating

  6. Locate the instrucion label from Relector (should be the same line like IL_0060: )
  7. 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:

  1. In ILDasm, close the dialog showing the IL for the method
  2. Go to the View menu and Check Show Tokens
  3. 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.
  4. Go to the View -> Meta Info and check Raw:Heaps
  5. Go to the View -> Meta Info and Show!
  6. 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.

抽个烟儿 2024-12-16 17:54:10

反编译不会返回原始代码。

您的示例看起来像一个简单的“使用字符串地址加载寄存器,用它做一些事情......”。

编译器不会将字符串(或任何数据)与指令内联,数据、字符串、数字都会移动到适当的部分。由于这是一个字符串常量,因此它可能会移至 .data 或 .rodata 部分。

将 -812265445 数字转换为十六进制使它更清晰一些,因为它变成了 0xCF95D01B,一个存储某些内容的有效地址。如果你的输出基数是带符号的十进制(看起来很常见),那么地址通常会出现巨大的负值。将它们转换为十六进制或更改默认值以让您看到(或更容易理解)它们指向的位置。

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

从这里(你上面的评论),很明显,第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.

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!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文