Как я могу изменить контрольную сумму модуля в минидампе?

Программное обеспечение, которое я пишу (и продаю), сжимается и зашифровывается, прежде чем я распространю его. Каждый раз, когда я выпускаю новую сборку, я сохраняю все файлы .map и сгенерированные двоичные файлы, включая exe, до того, как он будет сжат и зашифрован.

Когда он вылетает на клиентской машине, я получаю обратно минидамп. Я открываю эти минидампы в Visual Studio и исследую их там.

Я хорошо использовал эти минидампы, ища адреса в файлах .map. Обычно это приводит меня в правильную область кода, и я могу обычно рассуждать о том, почему произошел сбой, и исправлять его, но это ОЧЕНЬ много времени.

Было бы полезно, если бы я мог использовать символы, которые я сохранил из исходной сборки, при отладке минидампа.

Моя проблема в том, что я получаю предупреждения о том, что не могу найти нужные символы. Мои исследования заставляют меня поверить, что это связано с тем, что контрольная сумма исполняемого файла на клиентском компьютере не совпадает с контрольной суммой исполняемого файла, созданного Visual Studio. И я понимаю, почему он был сжат и зашифрован. Конечно, контрольные суммы не совпадают.

Я полагаю, что могу вручную отредактировать минидамп или изменить контрольную сумму сохраненных двоичных файлов, чтобы она соответствовала контрольной сумме распространяемого файла. Я бы предпочел манипулировать сохраненными копиями, чтобы мне не приходилось модифицировать каждый дамп, который приходит, но я бы предпочел и то, и другое.

Итак, мой вопрос: как мне найти эти контрольные суммы и выяснить, чем их заменить? В качестве вспомогательного вопроса: есть ли способ лучше?


c++ debugging crash-dumps
person Jere.Jones    schedule 09.12.2009    source источник

Ответы (2)


arrow_upward
5
arrow_downward

Не зная, как именно вы сжимаете и шифруете свои двоичные файлы, мне трудно быть очень конкретным.

Это сообщение в блоге Джона Роббинса указывает, что исполняемые образы связаны со своими PDB через GUID, встроенный в PE-заголовок исполняемого файла. Вы должны иметь возможность просмотреть его, запустив DUMPBIN / HEADERS в исполняемом файле и выполнив поиск выходных данных Debug Directories. Если ваше сжатие и шифрование изменили заголовки PE так, что эта информация недоступна (или верна), это объяснит, почему ваш отладчик ничего не может найти.

Есть несколько подходов, которые, я думаю, можно использовать для решения этой проблемы. Чтобы действительно попытаться заставить это работать, вы можете рассмотреть возможность использования WinDbg вместо отладчика Visual Studio. Вы поймете, почему я рекомендую это через мгновение ...

WinDbg предоставляет несколько параметров, которые позволяют без труда загружать файлы символов. Идея этой опции заключается в том, что, если исходный код не изменился, но двоичные файлы взяты из другой сборки, чем PDB, от проверки GUID можно отказаться и можно загрузить файл несовпадающих символов. Я не знаю, насколько хорошо это будет работать с вашим сжатием и шифрованием, поэтому YMMV.

WinDbg и сопутствующие ему инструменты можно использовать для дампа GUID как из исполняемого файла, так и из PDB, но я пока это опускаю, потому что надеюсь, что эти шаги не понадобятся.

После того, как вы открыли свой минидамп в WinDbg, вам нужно будет ввести несколько команд в командную строку, чтобы все это заработало:

.symopt +0x40
!sym noisy
ld <exe name>

Первая команда включает параметр SYMOPT_LOAD_ANYTHING, который пропускает проверку GUID. Команда !sym включает подробный вывод для загрузки символов, чтобы вы могли видеть более подробные сообщения об ошибках. Команда ld указывает WinDbg попытаться загрузить символы для имени исполняемого файла, которое вы введете вместо <exe name>. Если вы повторите команду ld, WinDbg сообщит, успешно ли он загрузил символы в первый раз.

Надеюсь, это поможет - опять же, я не знаю, насколько хорошо это будет работать с вашим сжатием и шифрованием, но попробовать стоит.

person Aaron Klotz    schedule 09.12.2009
comment
Я думаю, что первая команда должна быть .symopt + 0x40 (вы забыли начальную точку). - person Patrick; 08.03.2010

arrow_upward
0
arrow_downward

Это сжатие / шифрование что-то вроде UPX? Если фактическое исполняемое содержимое двоичных файлов изменяется (как это делается с такими инструментами, как UPX), вам не повезет (если вам не нравится отлаживать сложные приложения на языке ассемблера). Действительно ли ваше программное обеспечение настолько важно / особенное, что его двоичные файлы необходимо зашифровать перед доставкой? По моему опыту, возможность отлаживать аварийные дампы гораздо важнее, чем мешать людям выполнять обратную разработку вашего кода.

person Luke    schedule 10.12.2009
comment
Я бы не сказал, что мое программное обеспечение особенное / важное. Это коммерческий потребительский продукт, поэтому обратная разработка не является проблемой. Взлом и кейгены есть. - person Jere.Jones; 10.12.2009
comment
Люди найдут способы взломать ваши приложения, независимо от того, что вы делаете, по крайней мере, если они популярны или достаточно полезны. По моему опыту, усилия по защите вашего приложения от подобных вещей просто не стоят того времени и денег, которые требуются, особенно если это вызывает головную боль отладки у законных пользователей. - person Luke; 10.12.2009
comment
Это то же самое, что запереть машину и забрать ключи. Это не останавливает решительных воров, но и не бесполезно. - person Jere.Jones; 10.12.2009