Jak zmienić sumę kontrolną modułu w minizrzadku?

Question

Oprogramowanie, które piszę (i sprzedam) jest skompresowane i zaszyfrowane przed ich dystrybucją. Za każdym razem, gdy wydaję nową kompilację, przechowuję wszystkie pliki .map i wygenerowane pliki binarne, w tym plik exe, zanim zostanie skompresowany i zaszyfrowany.

Po awarii na komputerze klienta otrzymuję z powrotem minizestaw. Otwieram te minizrzuty w Visual Studio i odkrywam je tam.

Dobrze wykorzystałem te minizakupy, wyszukując adresy w plikach .map. Zazwyczaj dostanę się w odpowiednim obszarze kodu i ogólnie mogę uzasadnić przyczyny awarii i naprawić ją, ale jest to BARDZO czasochłonne.

Byłoby pomocne, gdybym mógł użyć symboli, które zapisałem z oryginalnej wersji podczas debugowania minizrzutu.

Mój problem polega na tym, że dostaję ostrzeżenia o tym, że nie mogę znaleźć odpowiednich symboli. Moje badania prowadzą mnie do przekonania, że ​​dzieje się tak, ponieważ suma kontrolna exe na komputerze klienta nie pasuje do sumy kontrolnej exe, które zbudował Visual Studio. Rozumiem, dlaczego został skompresowany i encypowany. Oczywiście sumy kontrolne nie pasują do siebie.

Myślę, że mogę ręcznie edytować minizrzutu lub zmienić sumę kontrolną zapisanych plików binarnych, aby dopasować sumę kontrolną do dystrybucji. Wolałbym manipulować przechowywanymi kopiami, więc nie muszę modyfikować wszystkich zrzutów, które przychodzą, ale byłbym zachwycony.

Moje pytanie brzmi: jak mogę zlokalizować te sumy kontrolne i dowiedzieć się, co powinienem je zastąpić? Jako pytanie pomocnicze: czy istnieje lepszy sposób?

Answer 1

Nie wiem, jak dokładnie kompresujesz i zaszyfrujesz swoje pliki binarne, więc trudno mi być bardzo konkretnym.

Ten blog post autorstwa Johna Robbinsa wskazuje, że pliki wykonywalne są powiązane z ich danymi wstępnymi za pomocą identyfikatora GUID osadzonego w nagłówku PE pliku wykonywalnego. Powinieneś być w stanie go wyświetlić, uruchamiając DUMPBIN/HEADERS na pliku wykonywalnym i szukając danych wyjściowych katalogów debugowania. Jeśli kompresja i szyfrowanie zmodyfikowały nagłówki PE w taki sposób, że te informacje nie są dostępne (lub poprawne), to wyjaśniałoby to, dlaczego twój debugger nie może znaleźć niczego.

Istnieje kilka podejść, które moim zdaniem mogą pomóc rozwiązać ten problem. Aby naprawdę spróbować uruchomić to, możesz rozważyć użycie WinDbg zamiast debugera Visual Studio. Zrozumiesz, dlaczego polecam to za chwilę ...

WinDbg oferuje kilka opcji, które pozwalają na swobodne ładowanie plików symboli. Pomysł z tą opcją polega na tym, że jeśli kod źródłowy nie został zmieniony, ale pliki binarne pochodzą z innej kompilacji niż PDB, można zrezygnować z kontroli GUID i załadować niepasujący plik symboli. Nie wiem, jak dobrze to będzie działać z twoją kompresją i szyfrowaniem, więc YMMV.

WinDbg i towarzyszące mu narzędzia mogą być użyte do zrzutu GUID zarówno z pliku wykonywalnego, jak i z PDB, ale na razie pomijam to, ponieważ mam nadzieję, że te kroki nie będą konieczne.

Po otwarciu swoje Minidump w WinDbg, trzeba będzie wprowadzić kilka komend w wierszu poleceń, aby to wszystko działa:

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

Pierwsze polecenie umożliwia opcję SYMOPT_LOAD_ANYTHING że pomija sprawdzanie GUID .Komenda !sym włącza szczegółowe wyświetlanie dla ładowania symboli, dzięki czemu można zobaczyć bardziej szczegółowe komunikaty o błędach. Polecenie ld kieruje WinDbg, aby spróbować załadować symbole dla nazwy pliku wykonywalnego, który zostanie wpisany w miejsce <exe name>. Jeśli powtórzysz polecenie ld, WinDbg wskaże, czy pomyślnie załadował symbole za pierwszym razem.

Mam nadzieję, że to pomoże - znowu, nie wiem, jak dobrze to będzie działać z kompresją i szyfrowaniem, ale warto spróbować.

Answer 2

Czy ta kompresja/szyfrowanie przypomina UPX? Jeśli rzeczywista zawartość plików wykonywalnych plików binarnych się zmienia (tak jak w przypadku narzędzi takich jak UPX), będziesz miał pecha (chyba że lubisz debugowanie złożonych aplikacji w języku asemblerowym). Czy twoje oprogramowanie jest tak ważne/specjalne, że jego pliki binarne muszą zostać zaszyfrowane przed dostarczeniem? Z mojego doświadczenia wynika, że ​​możliwość debugowania zrzutów usterek jest o wiele ważniejsza niż powstrzymywanie ludzi przed inżynierią wsteczną kodu.