У меня очень плохое представление о структуре EXE-фалов и вообще знания куриные. Есть у меня собственное приложение (на Delphi написанное), я хочу встроить в него проверку (без всяких крутых наворотов) целостности самого приложения. После компилирования, я упаковываю EXE, например UPX или другим упаковщиком. Я сделаю алгоритм рассчета контрольной суммы в самой программе, напишу второе приложение, которое будет уже после компиляции рассчитывать контрольную сумму и записывать куде-то в недры EXE. Вопрос: куда записывать-то эту контрольную сумму вторым приложением? При условии того, что я могу упаковать не только UPX'ом, но и другим упаковщиком. Спасибо.
Никогда подобного не релизовывал, но если бы пришлось, то контрольную сумму удобнее всего хранить в секции данных в специально отведенной для этого переменной. Вроде.
vaskyas Насколько могу себе представить, в общем случае решения нет. Для UPX можно попробовать писать в DOS заголовок, а в пакуемой программе из него читать. Для более сложных упаковщиков модифицировать готовый упакованный файл просто так (а-ля просто впихнуть туда DWORD или сколько-то там контрольной суммы) может иметь фатальные последствия для работоспособности программы. В общем случае невозможно провести проверку целостности программы, если собираетесь пользоваться упаковщиком. Упаковщик может распаковывать отдельные участки кода только по мере надобности, а потом их затирать, когда они отработают. Для проверки целостности либо полагаетесь на проверку, которая уже присутствует в упаковщике, либо пишете свой упаковщик.
Попробуйте упаковать упаковщиком, который распаковывает в память сразу всё. Если целостность секции .data необязательно проверять, то задача тривиальная: расчитать контрольную сумму кода в секции кода незапакованного файла, а записать её можно зашифрованной константой в самой программе. Таким образом, отпадает необходимость писать отдельный код для записи контрольной суммы "куде-то в недры EXE".
посчитать можно несколькими способами, причем хранить саму сумму можно где угодно, да только соверщенно непонятно контрольную сумму чего считать предполагается. Файла? Образа до распаковки? После распаковки (наверно плохая идея)? итд. Вся хитрость - как считать.
Ну разумнее и проще всего считать сумму распакованного файла в памяти. Её можно посчитать по дампу до запаковки. Сам когда-то так делал.
Думаю, все упаковщики (UPX точно) позволяют дописывать в конец екзешника данные. так что контрольную сумму считаешь по упакованному файлу и просто дописываешь ее в конец
scf или в досовый хидер. Или в промежуток между мз и ре хидерами (там где рич). Или.. Все зависит как считать.
Эээх... люди... вот нету у Вас способностей к ясновидению. scf _basmp_ Вы говорите о разных вещах. И не в тему говорит _basmp_ (разоблачение века ). scf говорит о записи контрольной суммы в упакованный файл, а _basmp_ о записи в оригинальный файл до упаковки. scf Не факт, не факт. Особенно осторожно нужно обращаться с теми упаковщиками, которые сами работают с оверлеем. К тому же у UPX есть возможность распаковки упакованного exe-шника не в памяти, а во временный файл. В таком случае можно вообще забыть о дозаписи в упакованный файл. _basmp_ (контраргумент при рассмотрении вопроса с Вашей точки зрения) А кто Вам сказал, что упаковщик восстановит DOS-заголовок из оригинального файла. И кто сказал, что не затрёт часть заголовка своими данными?
В самом деле, как и написано в 1м посте, что мешает 3й прогой посчитать контрольную сумму файла по закрытому алгоритму, записать ее кудаугодно в запакованный файл, а во время работы программы посчитать контрольную сумму файла на диске по тому же алгоритму и сравнить с сохраненной (на диске)? В чем вообще проблема-то?
GoldFinch Проблема 1) Это не то, что требуется. Автор, насколько могу судить, хочет проверять целостность своей программы в памяти, а не на диске. Возможно, некий вид антиотладки. Проблема 2) Любая дозапись в запакованный файл (хоть в оверлей, хоть в заголовок, хоть в дырки между секциями) может привести к падению распаковщика. Например, при его собственной проверке целостности. Проблема 3) В случае распаковки оригинальной программы во временный файл, а не в памяти, Вы вообще не знаете, где находится образ упакованного файла.
l_inc 1) если надо проверять целостность в памяти, то упаковка тут вообще нипричем, надо считать контрольную сумму секции кода и писать ее в секцию инициализированных данных 2) перефразируем - не любой упаковщик проверяет целостность файла. если же это происходит незачем проверять ее самим 3) если речь идет о файле на диске - с диска и надо читать а не искать в памяти
l_inc считаем и пишем контрольку в незапакованый файл хоть напрямки в код и исключаем это место из расчета или считаем последним. После запаковываем. Не понял, я что, всегда лажу несу или наоборот, непогрешим редкостно?
GoldFinch 1) В постановке задачи сказано, что производится последующая упаковка. Подсчёт контрольной суммы секции кода может быть очень затруднительным в случае постоянно "переупаковывающих" в рантайме упаковщиков. 2) Согласно постановке задачи мы не знаем, какой у нас упаковщик. 3) Если речь о файле на диске, то мы не всегда знаем, какой файл читать для проверки. Опять таки это может зависеть от поведения упаковщика. _basmp_ Я ж не говорил про всегда. А в данном случае не в тему, потому что постановка задачи иная (контрольная сумма записывается в запакованный файл). Хотя она и нечёткая, поэтому, может, гоню.
