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

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

0 голосов
/ 21 сентября 2009

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

Для экзамена:

  • Label_065C (почему имя оригинальной метки было преобразовано ...)

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

  • Авторские права \ x00a9 ... Corporation 2008
  • if (this.SiteID == 0xce )
  • addArticle.Parameters.Add ("@ Title", SqlDbType.NVarChar, 0x100 ). Значение

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

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

Ответы [ 3 ]

2 голосов
/ 21 сентября 2009

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

1 голос
/ 21 сентября 2009

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

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

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

0 голосов
/ 22 сентября 2009

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

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

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

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

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

...