BSIDES LATAM 2016 – Hunting Malwares on the Memory

Dear readers, how are you? Yesterday, June/12, I taught a lecture titled “Hunting malwares on the memory” in BSIDES Latin America 2016. It follows few photos:

I am proud of having taken part of the first BSIDES LATAM 2016 for three reasons:

  1. Attendees from my lectures were amazing. They were smart, very interested and made good questions.
  2. Ponai Rocha (one of the organizers) was very polite and an outstanding host.
  3. BSIDES LATAM is a technical event with few vendors and quite really interesting lectures taught by experts.

Honestly, I hope my attendees have learned and gotten motivated to study a bit more about Malware and Memory Analysis.

I hope you have a nice day.

Alexandre Borges.

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

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)

Reversing: few words about a trivial code

(this short write up can be read in pdf format: https://alexandreborgesbrazil.files.wordpress.com/2016/01/reversing_few_words_about_a_trivial-code2.pdf)

Dear readers, how are you? During my classes and presentations, it is extremely common to hear students and professionals comparing different areas inside IT security, but honestly I think is neither possible nor feasible to do this “mental exercise”. Yesterday, I received one of this kind of message and, in the middle of the e-mail, I could read that “doubtless, hacking (pentest) is more difficult than reverse engineering and malware analysis”. I am not sure if it’s possible to state it. As an super easy educative example, I sent this code (I cleaned it a bit to make it clearer) below to my student and I asked him about two things: a) What’s the equivalent structure in C that the code is representing? b) How does it work?

.text:004028BC mov [ebp+var_C], eax

.text:004028BF mov ecx, [ebp+var_10]

.text:004028C2 movsx edx, byte ptr [ecx]

.text:004028C5 mov [ebp+var_14], edx

.text:004028C8 mov eax, [ebp+var_14]

.text:004028CB sub eax, 64h

.text:004028CE mov [ebp+var_14], eax

.text:004028D1 cmp [ebp+var_14], 0Fh ;

.text:004028D5 ja short loc_402923 ;

.text:004028D7 mov edx, [ebp+var_14]

.text:004028DA xor ecx, ecx

.text:004028DC mov cl, ds:byte_40293E[edx]

.text:004028E2 jmp ds:off_40292A[ecx*4] ; switch jump

.text:004028E9 ; —————————————————————————

.text:004028E9 loc_4028E9:

.text:004028E9        ; CODE XREF: sub_402884+5Ej

.text:004028E9 ; DATA XREF: .text:off_40292Ao

.text:004028E9 mov eax, [ebp+var_C] ;

.text:004028EC push eax ; char *

.text:004028ED call sub_401565

.text:004028F2 add esp, 4

.text:004028F5 jmp short loc_402923

.text:004028F7 ; —————————————————————————

.text:004028F7 loc_4028F7:

.text:004028F7         ; CODE XREF: sub_402884+5Ej

.text:004028F7 ; DATA XREF: .text:off_40292Ao

.text:004028F7 mov [ebp+var_4], 1 ;

.text:004028FE jmp short loc_402923 ;

.text:00402900 ; —————————————————————————

.text:00402900 loc_402900:

.text:00402900         ; CODE XREF: sub_402884+5Ej

.text:00402900        

.text:00402900 mov ecx, [ebp+var_C] ;

.text:00402903 push ecx ; char *

.text:00402904 call sub_402813

.text:00402909 add esp, 4

.text:0040290C jmp short loc_402923 ;

.text:0040290E ; —————————————————————————

.text:0040290E

.text:0040290E loc_40290E:

.text:0040290E

.text:0040290E mov edx, [ebp+var_C] ;

.text:00402911 push edx ; char *

.text:00402912 call sub_402851

.text:00402929 add esp, 4

.text:0040291A mov eax, [ebp+arg_4]

.text:0040291D mov dword ptr [eax], 1

.text:00402923

.text:00402923 loc_402923:

.text:00402923

.text:00402923 mov eax, [ebp+var_4] ; jumptable 004028E2 default case

.text:00402926 mov esp, ebp

.text:00402928 pop ebp

.text:00402929 retn

.text:00402929 sub_402884 endp

.text:00402929

.text:00402929 ; —————————————————————————

.text:0040292A        dd offset loc_4028E9 ; DATA XREF: sub_402884+5Er

.text:0040292A        dd offset loc_4028F7 ; jump table for switch statement

.text:0040292A        dd offset loc_40290E

.text:0040292A        dd offset loc_402900

.text:0040292A         dd offset loc_402923

.text:0040293E        db 0, 4, 4, 4 ; DATA XREF: sub_402884+58r

.text:0040293E        db 4, 4, 4, 4 ; indirect table for switch statement

.text:0040293E        db 4, 4, 1, 4

.text:0040293E        db 4, 4, 2, 3

.text:0040294E

 

As I stated previously, the code above is trivial and, in a nutshell, although this code have been extracted from a malware, there is only reverse engineering here. Few comments follow:

  • The represented structure is a simple “switch case” statement (it is easily identified by IDA Pro).
  • There’re 16 possible cases (you should pay attention in the comparison at 0x004028D1 and remember that 0x0F is equal to 16).
  • The variable which is defining the cases is var_16 (look at 0x004028D7). It is will be loaded to edx and it will be acting as an index (more details below).
  • A jump table (0x0040292A) is being used to represent the switch case statements.
  • Looking at the jump table pointers (0x0040293E), we notice that there’re only five different indexes (0 to 4), so we have only five different statements in a nutshell. Therefore, the instruction mov cl, ds:byte_40293E[edx] (at 0x004028DC) servers as an index to jump table pointers. Depending on this index (0 to 15 – you remember that there are 16 possible cases in this example), the program chooses a pointer. For example, if the index is A(0x10) then the index in the jump table pointer is “1” (check this information by counting the values at 0x0040293E lines). Looking at jump table(0x0040292A), the second switch statement (remember, the range is from 0 to 4) is the address 0x004028F7
    (dd offset loc_4028F7).
  • Thus, the “switch jump” instruction jmp ds:off_40292A[ecx*4] at address 0x004028E2 finally jumps the code flow to the mentioned address above (0x004028F7).

As I said previously, this is an super easy and basic construction, but most time while I am analyzing malwares I see pieces of code like that. In fact, it is suitable to tell that malware analysis is much more difficult than a simple switch case statement. Sure, I could explain several kind of hooking, injections, hijacking , and so on, but I chose this example to prove to my student that is not possible to compare different areas before having a better knowledge about both them (in time: my student wasn’t able to answer my questions at beginning of this write up).

Personally, my life is IT Security and I have a strong preference by malware analysis, so I am available to help you when necessary. If you want, I will be teaching few courses this year (more at https://alexandreborges.org/my-courses/) and I hope see you there.

Have a nice day.

Alexandre Borges.

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

Meeting Michael Sikorski in NYC (SEP/2015)

Dear readers, how are you? Today I have an amazing and unforgettable day lunching with Michael Sikorski in NYC. For people who do not know Michael, he is author of Practical Malware Analysis book and director of FLARE (FireEye Labs Advanced Reverse Engineering) at FireEye. Certainly I can tell you that Michael is very polite, friendly, an extremely humble person and so different from other professionals who I know that do not have (even close) the same knowledge.There are not enough good words to praise Michael. Follow below a picture with Michael in a restaurant:

I’ve been learning with top minds such as Michael Sikorski for being able to share the knowledge. Honestly, I hope I am successful.

In this world, we meet few relevant and remarkable people. Michael is one of them.

Have a nice day.

Alexandre Borges.

(LinkedIn: http://www.linkedin.com/in/aleborges)

GPU Malware – Update 2

Hello readers, how are you? This is an updated post about Malwares, which run on GPU (Graphics Processing Units) and keep stealthy. I have added two new documents below:

Stay tuned for further updates!

If you liked this post then let me know, please.

Have a nice day.

Alexandre Borges

(LinkedIn: http://www.linkedin.com/in/aleborges)