2009-10-15 2 views
2

Мне нужно написать относительно небольшую программу для синтаксического анализа исполняемых файлов .net и генерации списка вызовов внешним методам. Например, если внутри файла вызывается System.Console.WriteLine, инструмент должен печатать, что System.Console.WriteLine называется где-то. Я не могу (ограниченный мозг и время) и не нуждаюсь (все, что мне нужно, это список вызовов), реализуют реальную разборку. Я хочу grep friendly perl friendly относительно короткое решение, которое записывает имена вызываемых функций и смещение, где произошел звонок.Частично дизассемблировать .net исполняемый файл

Вещи, которые я уже пробовал:

  1. Скачивание функции от MSDN. Теперь я знаю, что статический вызов переведен в 0x28 в байт-код. :) За ним следует дескриптор метода, но понимание того, что означает дескриптор метода, вероятно, потребует прочтения всей спецификации.

  2. Открытие простого exe в рефлекторе. Рефлектор точно воспроизвел код моего оригинального приложения, но я не могу видеть байт-код для вызовов.

Возможно ли реализовать требуемые ограниченные функциональные возможности с ограниченным временем и знаниями?

Если да, то что я знаю для его реализации? Есть ли инструкция «CIL assembly for dummies»?

+2

В рефлекторе вы можете «проанализировать» метод и узнать, где он используется (называется) из других загруженных сборок. Идя в другом направлении, я не уверен ... –

+0

Спасибо, Agent_9191, я пропустил это. – Muxecoid

+0

Анализ фактически не показывает вам байтовый код, где он используется. Он отображает список зависимостей со всеми используемыми вызовами, но список зависимостей ничего не говорит о местоположении вызова относительно начала файла exe или о фрагменте байт-кода, ответственном за фактический вызов. – Muxecoid

ответ

2

Если вы хотите что-то grep/perl-friendly, используйте ildasm (в режиме командной строки, то есть с/out или/text), чтобы разобрать байт-код на текстовый IL. Затем вы можете использовать grep, perl или язык по вашему выбору, чтобы найти инструкции по вызову. (grep, вероятно, не хватило бы, чтобы определить, какие методы были указаны в инструкциях вызова, но perl должен иметь возможность.)

+0

Спасибо, созданный ildasm CIL помогает находить и идентифицировать все интересные звонки. Есть ли способ легко обнаружить блоки try-catch? – Muxecoid

+0

Попробуйте блокировать начало с .try {и заканчивается}. Блокировка начинается с catch [mscorlib] System.Exception (или независимо от исключения), затем {и заканчивается с}. (Лучший способ увидеть это - написать тестовую сборку в C# и ildasm it. См. Также комментарий Джейсона о форме обработчика/метки.) Поэтому размещение этих блоков не должно быть слишком сложным. Тем не менее, может быть больно использовать линейный процессор, такой как perl, чтобы определить, является ли данная строка частью блока try-catch или нет: вместо этого вы можете исследовать проекты Cecil и CCI, упомянутые VirtualBlackFox и Jason. – itowlson

4

Проект Ceci l - это библиотека, которая сделает именно то, что вы хотите.

1

Общая инфраструктура компилятора также может помочь вам: http://ccimetadata.codeplex.com/.

Я бы предпочел второе предложение itowlson просто разобрать сборку в файл .il и проанализировать ее с помощью grep, если это то, что вы ищете. Поскольку ILDasm будет отображать полные пространства имен для всех типов, которые вы должны устранить, достаточно быстро определить, является ли это вашим типом или ссылочным типом.

+0

Забыл упомянуть о командной строке для вас. Что-то вроде следующего даст вам текстовый файл, который вы могли бы затем grep: ildasm /out:.il –

+0

Я верю в ildasm, отправленный с vs2008, если вы не используете команду/raweh в команде line, ваш try/catch /, наконец, будет в коде (расширен) как .try/catch/finally. Если вы используете/raweh, то блок обработки exeception в формации находится в конце метода (например, он хранится в байтовом коде). Вам придется расшифровать их, где они идут в коде, используя метки. –

Смежные вопросы