H2HC 2016 University – SLIDES

Dear friends…happy new year! After receiving so many requests, both slides from my presentations in Hacker to Hackers Conference (H2HC) 2016 University follow:

Few Tricks Used by Malwares: https://alexandreborgesbrazil.files.wordpress.com/2017/01/h2hc_university_talk_1_2016_r.pdf

Few Malware Anti-Forensics Techniques: https://alexandreborgesbrazil.files.wordpress.com/2017/01/h2hc_university_talk_2_2016-_r.pdf

Respective photos follow:

https://alexandreborges.org/2016/10/23/h2hc-2016-day-1/

https://alexandreborges.org/2016/10/24/h2hc-day-2/

In fact, both presentations were extremely basic (it is almost impossible to be simpler than these ones) and targeted on professionals who are beginning in this amazing area.

Honestly, I hope both slides sets can encourage you to learn more about Reverse Engineering and Malwares.

!gnisreveR raeY weN yppaH (Happy New Year Reversing!)

Alexandre Borges.

(LinkedIn: http://www.linkedin.com/in/aleborges and Twitter: @ale_sp_brazil)

PS: if it is possible, let me know you impression about both presentations. 🙂

Easy anti-debugging technique during a reversing

Dear readers, how are you? Few days I ago, I received a request to publish few tips about reversing. Unfortunately, my time for writing is almost zero, but I’ve been trying to do something and it is a quick write up explaining a simple anti-debugging trick.

Look at the following code lines from a malware below (the numbering is mine):

  1. 0040866A call $+5
  2. 0040866F pop ebp ;
  3. 00408670 lea eax, [ebp+54h]
  4. 00408671 inc ebp
  5. 00408673 push eax
  6. 00408674 xor eax, eax
  7. 00408676 push dword ptr fs:[eax]
  8. 00408679 mov fs:[eax], esp
  9. 0040867C int 3
  10. ….(snip)….
  11. 00408694 nop
  12. 00408695 xor ebx, ebx
  13. 00408697 div ebx
  14. 00408699 pop dword ptr fs:0
  15. ….(snip)….

Few comments:

Line 1: Although the call $+5 instruction  appears to be complicated, it is calling the next instruction because $ means the current address  (0x0040866A) and it is adding  5 =  0x0040866F. Furthermore, the call instruction pushes the next address , which it will be the return address (RET), onto the stack.

Line2: The pop ebp instruction saves the top stack content (exactly the RET=0x0040866F) into EBP register.

Line3: The lea (load effective address) instruction (lea eax, [ebp+54h]) only sum up values. Therefore, the eax register will hold the ebp value (0x0040866F) + 0x54 = 0x004086C3

Line 4: The instruction inc ebp increases ebp register by 1. Thus, ebp = 0x00408670.

Line 5: The push eax instruction pushes the eax value (0x004086C3) onto the stack.  Looking ahead (at line 8), this address will be the address of an exception handler function.

Line 6: The xor eax,eax instruction makes eax=0.

Line 7 and 8: Both lines (push dword ptr fs:[eax] and mov fs:[eax], esp) set up an exception handler function by first “saving” the address of the current exception handler address onto stack and then copying the esp value (0x00408663) to FS register. Please, remember that Windows prepares the FS register to hold the base address address  of the current TEB (Thread Environment Block).  Additionally, the first item of this structure (which is at offset zero) is the head of a linked list of pointers to exception handler functions.

Line9: Purposely, the program generates an exception (through int 3 instruction), which is used by the debugger to implement a software breakpoint and, in this case, it causes a software trap (a kind of interrupt) to the debugger.

Therefore, if there was an attached debugger, it would take the control and it would be a terrible mistake because the int 3 instruction is a simple anti-debugging technique. The reason is that the malware expects to handle the exception (thus, the debugger should pass the exception to the malware) to dictate next steps of its operation, but if it doesn’t happen, so probably the program either will crash or make a strange thing.

Line 12: The xor ebx,ebx makes ebx =0.

Line 13: The div ebx instruction will trigger a division by zero and it is possible that the execution finishes.  Note that the div ebx instruction is wouldn’t be  executed whether the debugger had passed the exception to the malware (as it expects).

Line 14: The prior exception handler address (saved at line7) is restored from stack into the FS register through the pop dword ptr fs:0 instruction.

As a conclusion, the malware author configured an exception handler and forced the malware to trigger an exception to make additional steps (maybe changing registers and executing other instructions) during the exception handler function. If the analyst permit the debugger to catch the exception, so the malware won’t execute the intentioned steps and she/he won’t be able to understand the malware’s details.

Relax! I know that these few lines are very simple to analyze, but my intention it is to help students and beginners because the code above reflects a daily procedure of a malware analyst struggling against all kind of anti-forensic techniques (most them more complicated than this one).

Soon I will try to make a new and short post about malware analysis. Stay tuned.

I hope you have a nice day and…keep reversing. 😉

Alexandre Borges

(LinkedIn: http://www.linkedin.com/in/aleborges and twitter: @ale_sp_borges)