защитный механизм, предотвращающий
Задумаемся, что произойдет, если сбросить дамп с работающей программы? А произойдет вот что: в переменной p окажется указатель на когда-то выделенный блок памяти, условие (!p) обломится и новая память выделена не будет (!), а при обращении по старому указателю произойдет исключение. То есть, изготовить исполняемый файл из дампа хакер уже не сможет! Как минимум придется восстановить значения всех глобальных переменных, а это — геморрой! Ладно, изготовить исполняемый файл из дампа нельзя, но ведь дизассемблировать его можно? А вот и ни хрена!
После выполнение функции LoadIcon переменная my_icon будет содержать не идентификатор иконки, а ее обработчик! То есть, хакер не сможет установить, что это за иконка такая (строка, битмап или другой ресурс) и ему придется обращаться к отладчику, противостоять которому намного проще, чем дизассемблеру. Кстати говоря, такой прием экономит память и широко используется во многих программах (например, в стандартном "Блокноте" — попробуйте снять с него дамп и обломайтесь).
Стартовый код. Единственная надежда хакера — отловить момент завершения распаковки и тут же сбросить дамп, пока защита еще не успела нагадить в глобальные переменные. Пошаговая трассировка исключается (ей очень легко противостоять) и остается... только хвост! Он же стартовый код. Он варьируется от компилятора к компилятору, и в случае с Microsoft Visual C++ MFC выглядит так:
.text:00402A82 push ebp
.text:00402A83 mov ebp, esp
.text:00402A85 push 0FFFFFFFFh
.text:00402A87 push offset unk_403748
.text:00402A8C push offset loc_402C06
.text:00402A91 mov eax, large fs:0
.text:00402A97 push eax
.text:00402A98 mov large fs:0, esp
.text:00402A9F sub esp, 68h
...
.text:00402BAA call ds:GetModuleHandleA
.text:00402BB0 push eax
.text:00402BB1 call _WinMain@16 ; WinMain(x,x,x,x)
