Прочитайте (чтобы понять) шестнадцатеричный код в проекте, декомпилированном Reflector

Я использовал .NET Reflector 5.1.5.0 для декомпиляции файла с расширением: .exe. После экспорта в проект у меня есть несколько классов со многими «специальными» символами :(

Например:

  • Label_065C (почему исходное название ярлыка было преобразовано...)

  • Match matchBaseTag = new Regex(@"(?‹=base\s+href\=[\x27\x22])(?[^\x27\x22]* )(?=[\x27\x22])").Соответствие(Результат); (я думаю, что x27 - это шестнадцатеричный код)

  • Copyright \x00a9 ... Корпорация 2008 г.
  • если (this.SiteID == 0xce)
  • addArticle.Parameters.Add("@Title", SqlDbType.NVarChar, 0x100).Value

Я хочу спросить, почему значения (тот жирный) были изменены! и как понять их реальную стоимость (оригинал)

Извините, потому что мой английский не очень хорош, и большое спасибо! (Я жду твой ответ :( )


reflector
person Community    schedule 21.09.2009    source источник

Ответы (3)


arrow_upward
2
arrow_downward

вы можете установить десятичный формат числа в View-> options-> Disassembler-> Number Format

person manji    schedule 21.09.2009
comment
Благодарность! Я мог смотреть таким образом :) - person ; 23.09.2009

arrow_upward
1
arrow_downward

Информация в двоичном файле — это просто содержимое строки после, когда компилятор интерпретировал все escape-последовательности и т. д. — это необработанные текстовые данные, а не источник. Точно так же значения для таких вещей, как SiteID сравнения, являются просто целыми числами.

Reflector предлагает некоторый источник, который будет компилироваться в тот же двоичный код - он не знает, использовали ли вы шестнадцатеричный литерал или десятичный и т. д. Вы можете изменить формат числа, который он использует, в View / Options / Disassembler, заставив его в шестнадцатеричном или десятичном виде или оставив его решать. Не похоже, что есть аналогичная опция для определения того, как декомпилировать символы, отличные от ASCII, - было бы неплохо, если бы он мог использовать форму \uXXXX вместо \x, IMO.

Я не знаю о бите «ярлык», поскольку вы не дали достаточно контекста о том, где вы его видите или что это было раньше.

person Jon Skeet    schedule 21.09.2009

arrow_upward
0
arrow_downward

Обычно, когда есть разница между представлением Reflector и тем, что, по моему мнению, должно быть - я использую ILDasm. Я думаю, что целочисленные проблемы могут быть решены с помощью того, что сказали Джон и Наджмеддин. Строки немного сложнее (например, значение атрибута авторского права и строка вашего регулярного выражения).

Строковые константы (вещи, заключенные в кавычки в исходном коде) хранятся в виде последовательностей байтов Unicode в двоичном файле (либо в куче больших двоичных объектов, либо в куче пользовательских строк). Вы можете точно увидеть, что находится в вашем двоичном файле, используя ILDasm, если вы сделаете следующее: 0. Загрузите свою сборку в ILDasm 1. View->Meta Info проверьте Raw:Heaps 2. View->Meta Info нажмите Show!

Если вы выполняете поиск по «авторскому праву», он, скорее всего, будет в куче больших двоичных объектов (значения атрибутов используют другую сериализацию для байтов и находятся в куче больших двоичных объектов с другими двоичными значениями), а для вашей строки RegEx она должна быть в пользовательских строках. куча.

Как только вы посмотрите на значение в ILDasm, вы увидите, что на самом деле находится в сборке... если есть разница между этим и тем, что показывает Reflector... скорее всего, Reflector делает все возможное, чтобы декодировать двоичную строку, чтобы экранировать нечитаемые символы в более читаемый формат. Поскольку существует несколько возможных кодировок/декодирований, Reflecor иногда показывает правильную строку, но просто неправильно декодирует (например, декодирование \x27 и \x22 для ' и ").

Короче говоря, ваши значения не изменились в сборке (скорее всего), просто Reflector неправильно декодирует их в исходную строку.

person Jason Haley    schedule 22.09.2009
comment
Спасибо за объяснение. Попробую с ILDasm :) - person ; 23.09.2009