درمورد سوال آقا هادی در مورد CopyMem II ، مطالبی داشتم که عرضه میکنم ، فقط شرمنده وقت ترجمه نداشتن ، زحمتش رو خودتون بکشید.
1. garbage instructions:
insert many many garbage instructions to hide special instructions, disturb analysis and make people fret;
2. garbage loops:
same as the first item;
3. time comparing:
classic method, as step in/over need much longer than normal execution;
4. check parent process:
if target process is debugged, its parent process usually are not explorer.exe :)
5. check debugger:
windows provides some APIs to check if process is being debugged, such as: IsDebuggerPresent/NtQueryInformationProcess.
of course, you could also test CreateFile/PEB(just like IsDebuggerPresent to do).
6. dynamic encrypt/decrypt:
make analysis much more complex; re-encrypt the instructions which are passed could prevent cracker to check the old instructions effectivelly;
7. IAT encrypt:
stop the tools, e.g: ImpREC to recover IAT;
8. Fuzzy the instructions:
there are many ways to fuzzy the instructions, e.g: fuzzy the OEP instructions or fuzzy a random codes in process;
9. call:
use call instruction to confuse the cracker;
10. self-debug:
windows allows only one debugger to debug the target process, so we could use two or more processes. one process used to debug the special process to prevent cracker to debug the special process.
if we let one process to hook one interrupt, we could use this interrupt to decode or fuzzy some part codes;
11. SEH:
raise an exception manually to change process flow, such as: memory access exception, interrupt (int3,int1 or others), invalid instruction, invalid eip and so on;
12. multi-thread:
when a process is debugged and enter a breakpoint, all threads may be suspended. We could use this method to stop cracker:
a. change flow with multi-thread: modify main thread codes in sub thread, if sub thread is suspended, then main thread will fail;
b. use multi-thread decrypt main/sub thread codes;
13. anti-SMC:
use Timer or sub thread to set core memory space to READONLY access in a short time;
14. CRC checksum:
check codes CRC checksum to do a self test;
15. destroy debug environment:
modify DR register, interrtup process (int 1, int 3) or handle special interrupt by ourselves;
16. anti-DUMP:
set some useless memory space to NO_ACCESS, then some dump tools (e.g: LordPE) would not dump this process;
17. monitor keyboard:
monitor keyboard input, e.g: F7, F8, F9, F10;
18. Lock display:
lock display to prevent cracker to see the screen content;
19. destroy SEH environment:
invoke SetUnhandledExceptionFilter to stop debugger to catch exception;
20. debug parent process:
anti-debug;
21. CC protection or CopyMem-II protection:
such as modify all jump to CC (int 3), then we could use INT 3 handler to process the jump to correct address;
CopyMem-II means copy ourselves to another memory space to prevent to dump;
22. anti Attach:
destroy passed instruction to anti-attach; or create a process which doesn't support attach mode (require NT or later system);
23. instruction pre-fetch:
use CPU pre-fetch feature to disturb step trace, e.g:
mov word ptr [@@], 20cdh
@@:
nop
nop
24. create polymorphism packer codes:
25. save sensitive data to random space:
26. P-code:
use virtual CPU to run P-code to anti-debug;
When using CopyMem-II or the Debugger-Blocker, this variable will contain the program
ID of the SoftwarePassport/Armadillo control process for your program (the number that
is normally returned by the GetCurrentProcessId() API call), in decimal format. This is
sometimes needed to handle DDE messages.
یادم رفت بگم ، تمامی این روشهایی که عنوان شدن همشون تاریخ مصرفشون گذشته ( کرک شدن )