Come posso modificare il checksum di un modulo in un minidump?

Question

Il software che scrivo (e vendo) è compresso e crittografato prima di distribuirlo. Ogni volta che rilascio una nuova build, tengo tutti i file .map e i binari generati incluso l'exe prima che venga compresso e crittografato.

Quando si arresta in modo anomalo sul computer di un cliente, recupero un minidump. Apro questi minidump in Visual Studio e li esploro lì.

Ho fatto buon uso di questi minidump cercando gli indirizzi nei file .map. Questo in genere mi porta nell'area corretta del codice e in genere posso ragionare sul perché si è verificato l'arresto anomalo e correggerlo, ma questo richiede MOLTO tempo.

Sarebbe utile se potessi usare i simboli che ho salvato dalla build originale nel debug del minidump.

Il mio problema è che ricevo avvertimenti sull'impossibilità di trovare i simboli giusti. La mia ricerca mi porta a credere che ciò sia dovuto al fatto che il checksum dell'exe sulla macchina del client non corrisponde al checksum dell'exe creato da Visual Studio. E capisco perché, è stato compresso e codificato. Ovviamente i checksum non coincidono.

I figura I può modificare manualmente il minidump o modificare il checksum dei file binari salvati per abbinare il checksum del distribuibile. Preferirei manipolare le copie memorizzate in modo da non dover modificare tutti i dump in arrivo, ma sarei estatico con entrambi.

Quindi, la mia domanda è: come posso individuare questi checksum e capire con cosa dovrei sostituirli? Come domanda ausiliaria: c'è un modo migliore?

Answer 1

Senza sapere esattamente come si stanno comprimendo e crittografando i file binari, è difficile per me essere molto specifico.

Questo blog post di John Robbins indica che le immagini eseguibili sono associate ai loro PDB tramite un GUID incorporato nell'intestazione PE dell'eseguibile. Dovresti essere in grado di visualizzarlo eseguendo DUMPBIN/HEADERS sull'eseguibile e cercando l'output di Debug Directories. Se la compressione e la crittografia hanno modificato le intestazioni PE in modo tale che queste informazioni non siano disponibili (o corrette), spiegherebbe perché il debugger non riesce a trovare nulla.

Ci sono alcuni approcci che penso che potresti prendere per risolvere questo problema. Per provare davvero a farlo funzionare, potresti prendere in considerazione l'utilizzo di WinDbg invece del debugger di Visual Studio. Capirai perché lo raccomando tra un momento ...

WinDbg offre alcune opzioni che consentono il caricamento rilassato dei file di simboli. L'idea con questa opzione è che, se il codice sorgente non è cambiato ma i file binari provengono da una build diversa dal PDB, è possibile annullare il controllo GUID e caricare il file di simboli non corrispondenti. Non so quanto bene funzionerà con la compressione e la crittografia, quindi YMMV.

WinDbg ei relativi strumenti di accompagnamento possono essere utilizzati per scaricare il GUID dal file eseguibile e dal PDB, ma per il momento lo sto omettendo perché spero che quei passaggi non siano necessari.

Dopo aver aperto il tuo minidump in WinDbg, è necessario inserire diversi comandi nella riga di comando per ottenere questo tutti al lavoro:

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

Il primo comando abilita l'opzione SYMOPT_LOAD_ANYTHING che salta il controllo GUID .Il comando !sym abilita l'output dettagliato per il caricamento dei simboli in modo che sia possibile visualizzare messaggi di errore più dettagliati. Il comando ld indirizza WinDbg per provare a caricare i simboli per il nome dell'eseguibile che verrà inserito nella posizione di <exe name>. Se si ripete il comando ld, WinDbg indicherà se è stato caricato correttamente i simboli la prima volta.

Speriamo che questo aiuti - ancora una volta, non so quanto bene questo funzionerà con la compressione e la crittografia, ma vale la pena provare.

Answer 2

Questa compressione/crittografia è simile a UPX? Se il contenuto eseguibile effettivo dei file binari sta cambiando (come avviene con strumenti come UPX), sarai sfortunato (a meno che non ti piaccia il debug di applicazioni complesse in linguaggio assembly). Il tuo software è davvero così importante/speciale che i suoi file binari devono essere crittografati prima di essere consegnati? Nella mia esperienza, la possibilità di eseguire il debug di dump di crash è molto più importante che impedire alle persone di decodificare il codice.