Благодарю за комментарии. Однако, у меня есть несколько вопросов:
Здравствуйте, Harley, Вы писали:
H>2. Может быть я пропустил чего, но изначально для парсинга PE файла (в част-ности — таблиц метаданных)надо знать что за формат файла используется — tiny или fat.
О формате tiny и fat методов я написал. Но, честно говоря, о таких форматах файла ничего не знаю. Если есть возможность, укажите, пожулуйста, ссылку, где можно найти эту информацию. Самому искать не лень, просто нет времени.
H>3. Количество записей в таблице можно узнать вычислив по формату полей длину одной записи и поделив размер таблицы на нее, размер записи может также зави-сеть от формата tiny или fat.
Наверное, можно и так. Но число записей в каждой таблице определено и в мета-данных, не так ли?
H>Формат PE.Net файла вообще содержит в себе много всяких условностей, так как есть еще mixed images — содержащие managed и unmanaged код — его легко получить собрав managed С++ сборку не позаботившись о том чтобы она была 100% managed — unmanaged методы могут быть впихнуты компилятором через таблицы релокаций — об этом автор не упомянул,так как исследование mscorlib — это не все. Лучше всего исследо-вать 3 типа сборки — от VB.Net, C#, и managed C++ (для очистки совести можно еще и от компилятора Borland C#Builder привести). Наиболее соответствовать ECMA будут первые два типа (и Borland-вский).
Проверял ВСЕ сборки, которые оказались доступны. Сейчас ищу такие сборки, на которых мой Researcher "упадёт", то есть окажутся неправильными мои представления о формате PE-файла. Пока таковых не нашёл, но нашёл много интересного. В частности, заметил, что г. Рихтер в своей книге не совсем прав, когда говорит, что метаданные пи-шутся только в сегмент .text. По моим данным, в случае MC++ код пишется в сегмент .text, метаданные — в сегмент .rdata. Находил случаи, когда часть метаданных оказывалась в сегменте .data (ISysWrapper.dll). Других случаев просто не встречал. Если Вы встречали, пришлите, пожалуйста, мне эти файлы, ладно?
H>Конечно до кода добраться можно и сделать его дизассемблинг тоже легко, но вот даже здесь есть темные пятна, так как managed метод тоже можно "спрятать" через таблицу релокаций.
Недьзя ли привести пример? Интересно, как мой Researcher определит, где этот код находится?
H>Одна статья конечно мало чего дает заинтересованному читателю, тут стоит по-святить этому вопросу цикл статей, так как ответ на вопрос "легко ли добраться до кода методов" уже давно дан тем же самым ILDASM.
Ну, тут я не совсем согласен. С моей точки зрения, ILDasm специально написан так, чтобы, раскрыв внутренности, не раскрывать, как все эти внутренности расположены. Но, это только IMHO.
H>И я бы назвал бы структуру метаданных, содержащихся в PE.Net реляционной базой данных, которую можно проверить утилитой PEVerify на "правильность", правда тут тоже есть обход — можно выставить SkipVerification атрибут для ублажения этой ути-литки. Так что интересно было бы поставить вопрос — насколько совместимы собранные тем или иным компилятором сборки с положениями ECMA. У меня напрашивается только один ответ — C# compiler это может.
Не совсем понял, что Вы имеете в виду. ТОЛЬКО С#-компилятор это может? Если Вы имели в виду именно это, тогда я (на основе опыта, полученного при анализе массы файлов) согласен.
H>Кстати в Роторе представлены несколько подходов по парсингу PE, самый не-структурированный — это в ILDASM. Оба подхода достаточно трудны для изучения.
Какие ещё подходы имеются? Расскажите вкратце, Ок?
