[Defrag] procdump

Kolejny fajna porcja podcastów z Defrag dostępna na channel9, dotycząca narzędzia ProcDump (sysinternals).

• http://channel9.msdn.com/Shows/Defrag-Tools/Defrag-Tools-9-ProcDump
• http://channel9.msdn.com/Shows/Defrag-Tools/Defrag-Tools-10-ProcDump-Triggers
• http://channel9.msdn.com/Shows/Defrag-Tools/Defrag-Tools-11-ProcDump-Windows-8--Process-Monitor

ProcDump jest programem konsolowym do zrzucania dump-ów pamięci (zdolności takie posiada też TaskManager, czy Process Explorer, ale nie tak zaawansowane). To co w nim najfajniejsze to tworzenie dump-ów programów w wyniku wystąpienia określonych warunków (pojawienie się wyjątku, określone zużycie pracy procesora/pamięci). Warto zacząć do przeglądnięcia dostępnych przykładów:

procdump.exe -? -e

Trzeba pamiętać o podaniu nazwy pliku gdzie dump zostanie zrzucony, jakoś przykłady o tym nie wspominają, a komunikat zwrotny nie jest intuicyjny. Kilka użytecznych przełączników:

• -mp, -ma - domyślnie procdump, tworzy mini-dump, czasami jest to wystarczające, ale jeżeli będzie potrzebna nam większa ilość pamięci, można skorzystać z opcji Mini-Plus (-mp), lub do zrzutu całej pamięci (-ma)
• -r - opcja tworzy klon pamięci, dzięki czemu proces tworzenia dumpa, nie przerywa działania oryginalnego programu
• -w - jeżeli proces jeszcze nie jest odpalony, poczekaj na niego
• -e - zrzuć dump w razie wystąpienie wyjątku. Domyślnie zadziała, gdy nie obsłużona zostanie druga szansa na złapanie wyjątku. Np. program zgłosi wyjątku access violation, na który system nie będzie umiał zareagować, więc nastąpi crash aplikacji. W ten sposób w dump-ie pojawi się miejsce, z którego pierwszy wyjątek został złapany, a nie gdzie został rzucony. Aby reagować na pierwsze pojawienie się wyjątku można skorzystać z opcji "-e 1"
• -f - filter na wyjątki i debug logi

Przykład użycia:

#include "stdafx.h"
#include <iostream>

int main() {
    std::cout << "Hello crash" << std::endl;
    int *ptr = new((int *)0xdeadbeaf) int(44);
    return 0;
}

C:\userdata\>procdump.exe -mp -e 1 -f "ACCESS_VIOLATION" -w ConsoleCrash.exe crash.dmp

ProcDump v7.1 - Writes process dump files
Copyright (C) 2009-2014 Mark Russinovich
Sysinternals - www.sysinternals.com
With contributions from Andrew Richards

Waiting for process named ConsoleCrash.exe...

Process:               ConsoleCrash.exe (3344)
CPU threshold:         n/a
Performance counter:   n/a
Commit threshold:      n/a
Threshold seconds:     10
Hung window check:     Disabled
Log debug strings:     Disabled
Exception monitor:     First Chance+Unhandled
Exception filter:      *ACCESS_VIOLATION*
Terminate monitor:     Disabled
Cloning type:          Disabled
Concurrent limit:      n/a
Avoid outage:          n/a
Number of dumps:       1
Dump folder:           C:\userdata\
Dump filename/mask:    crash


Press Ctrl-C to end monitoring without terminating the process.

[22:33:05] Exception: C0000005.ACCESS_VIOLATION
[22:33:05] Dump 1 initiated: C:\userdata\crash.dmp
[22:33:06] Dump 1 complete: 1 MB written in 0.5 seconds
[22:33:06] Waiting for dump to complete...
[22:33:07] Dump count reached.

Back to crackme

Wróciłem po latach do zabawy z crackme, z którymi wcale tak dużo się nie bawiłem. Zaczynam od nauki narzędzi i oglądanie podcastów Gynvaela Coldwinda - ReverseCraft:

• https://www.hex-rays.com/products/ida/support/download.shtml
  
• http://www.ollydbg.de/
  

Link z listą instrukcji procesora:

• http://en.wikipedia.org/wiki/X86_instruction_listings
  

Code reading

Fajny artykuł dotyczący czytania kodu, stojący trochę w opozycji do tego, że kod powinno się czytać jak dobrą książkę. I trochę szczery, deweloperzy nie mają jednak nawyku czytania kodu...

• http://www.gigamonkeys.com/code-reading/

Praca z cudzym kodem

Zastanawiam się ostatnio jak ugryźć temat analizowania cudzego kodu. Nigdy nie brałem się za to zadanie formalnie, a w różny sposób zdobyta wiedza, szybko mi wyparowuje. Proces badania (reverse engineering), czasami przydaje się jedynie do zrozumienia istniejącej funkcjonalności, a czasami jest konieczny, do przeprowadzenia jakiś zmian (reengineering) np. naprawy błędów. W ostateczności, kod jest wyrocznią, tego jak działa program, nawet jak specyfikacja mówi co innego. Poniżej ciekawy link:

http://blog.smartbear.com/software-quality/bid/167035/How-to-Inherit-Somebody-Else-s-Code

I moje wnioski:
- Nie staraj się, zagłębiać w szczegóły
- Nie myśl jeszcze, o refaktoryzacji - to rozprasza
- Nie wymyślaj koła od nowa - nie myśl o przepisaniu czegoś od początku, tylko dlatego, że nie wiesz jak działa
- Analizując możesz spójrz na aplikację z punktu widzenia, końcowego użytkownika
- Bądź zorganizowany - dopasowuje istniejące moduły do opisu, który znajduje się w dokumentacji
- Najwięcej korzyści przynosi praca z kodem, który napisał ktoś mądrzejszy