【问题标题】:Read (to understand) hexa code in Project that decompiled by Reflector阅读(理解)反射器编译的项目中的十六进制代码
【发布时间】:2009-09-21 08:55:45
【问题描述】:

我使用 .NET reflector 5.1.5.0 反编译了一个扩展名为:.exe的文件。 导出到项目后,我有一些带有许多“特殊”字符的类:(

例如:

  • Label_065C(为什么要转换原始标签名称...)

  • 匹配 matchBaseTag = new Regex(@"(?\x27\x22])(?[^\x27\x22 ]*)(?=[\x27\x22])").Match(Result); (我认为 x27 是一个十六进制代码)

  • 版权所有\x00a9 ... Corporation 2008
  • 如果(this.SiteID == 0xce
  • addArticle.Parameters.Add("@Title", SqlDbType.NVarChar, 0x100).Value

我想问为什么值(那个粗体)被改变了! 以及如何理解它们的真正价值(原文)

对不起,因为我的英语不好,非常感谢! (我在等你的回复:()

【问题讨论】:

    标签: reflector


    【解决方案1】:

    可以在View->options->Disassembler->Number Format中设置数字格式为十进制

    【讨论】:

    • 谢谢!我可以通过这种方式查看:)
    【解决方案2】:

    二进制文件中的信息只是字符串的内容编译器已经解释了任何转义序列等 - 它是原始文本数据,而不是源。同样,SiteID 比较之类的值只是整数。

    Reflector 提供了一些可以编译为相同二进制代码的源代码 - 它不知道您使用的是十六进制文字还是十进制文字等。您可以在 View / Options / Disassembler 下更改它使用的数字格式,强制它为十六进制或十进制或让它自己决定。似乎没有类似的选项来确定如何反编译非 ASCII 字符 - 如果它可以使用 \uXXXX 形式而不是 \x,IMO,那就太好了。

    我不知道“标签”位,因为您没有提供足够的上下文来说明您在哪里看到它或它以前是什么。

    【讨论】:

      【解决方案3】:

      通常,当 Reflector 的表示与我认为应该的表示之间存在差异时 - 我使用 ILDasm。我认为整数问题可以通过 Jon 和 najmeddine 所说的来解决。字符串有点难(比如版权属性值和你的正则表达式字符串)。

      字符串常量(源代码中引号中的内容)在二进制文件中存储为 unicode 字节序列(在 blob 或用户字符串堆中)。如果您执行以下操作,您可以使用 ILDasm 准确查看二进制文件中的内容: 0. 在 ILDasm 中加载你的程序集 1. 查看->元信息检查 Raw:Heaps 2. 查看->元信息点击显示!

      如果您搜索“版权”,它很可能位于 blob 堆中(属性值对字节使用不同的序列化,并且与其他二进制值一起位于 blob 堆中),对于您来说,它应该在 RegEx 字符串中用户字符串堆。

      一旦您查看了 ILDasm 中的值,您就会看到程序集中的实际内容......如果这与 Reflector 显示的内容之间存在差异......很有可能 Reflector 正在尽最大努力解码二进制字符串将不可读的字符转义为更易读的格式。由于有几种可能的编码/解码,Reflecor 有时会显示一个有效的字符串 - 但只是没有正确解码(如 \x27 anc \x22 解码 ' 和 ")。

      简而言之,您的值在程序集中没有改变(很可能)只是 Reflector 没有将其正确解码为原始字符串。

      【讨论】:

      • 感谢您的解释。我会尝试使用 ILDasm :)
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2012-02-14
      • 1970-01-01
      • 2019-12-27
      • 2016-04-17
      • 2015-12-23
      • 2018-05-17
      • 1970-01-01
      相关资源
      最近更新 更多