Showing posts with label x64dbg. Show all posts
Showing posts with label x64dbg. Show all posts

Friday, April 16, 2021

FlawedAmmyy unpacking malware example

 FlawedAmmyy unpacking

https://guidedhacking.com/threads/how-to-unpack-flawedammyy-malware-unpacking-tutorial.16637/

7fb83e646cbabc50bec4b33c8130b5ae

https://app.any.run/tasks/97d8c688-a0ed-4602-af79-2409b6d8cd47/


steps

- open ida

- find bottom of "start" (using graph overview window)

- notice all to "WinMain", take it

- find "ret" near bottom of "WinMain" (using graph overview window)

- look just above & around to find any "call" statements, choose "call" closest to the "ret"

- find return of VirtualAlloc

- follow as it's moved from EAX to a "var_**"

- then moved to a register

- then moved to another "var_**"

- until you find a "call var_**" to near the end of the chain

- switch from graph to text view, find the memory address of the "call" statement (0x0040153F)

- open x32dbg

- right-click in CPU tab, "Go To -> Expression", enter that address "0x0040153F"

- cursor should be at same "call" statement as we had in IDA

- set a breakoint in x32dbg on that "call" statement (F2)

- push the play arrow (twice) and run to the breakpoint

- right-click on the "call" statement, choose "Follow in Dump -> Value" (no MX value yet)

- step into the "call" (F7)

- notice code has lots of Stack Strings (API calls like VirtualAlloc, VirtualProtect, etc.)

- when you see "VirtualAlloc", good time to put a breakpoint on all future calls (command: bp VirtualAlloc)

- scroll down until you find either a "call REGISTER", "jmp REGISTER", or "call/jmp DWORD that was a register"

ex: mov dword ptr ss:[ebp-54],eax

call word ptr ss:[ebp-54]

- set a breakpoint (F2) on the registry call

- then run by hitting play arrow

- If "VirtualAlloc" breakpoint is hit, right-click on EAX and "Follow in Dump"

- Keep going until the "Follow in Dump" shows a value at the bottom starting with "MZ" header

- open Hex Editor

- compare original EXE first chars after "MZ" header with what is in "Follow in Dump"

- if same, then hit play arrow again to keep running

- if different, then you may have the unpacked EXE

notes: It may take a while (unpacking can be slow)

When you hit a breakpoint you're looking at the content of "previous" memory regions

- right click "Follow in Memory Map"

- right click "Dump Memory to File"

- how do you know if you did it right?

drop into PE Studio, look at strings, do you see the actual "Ammyy.Service" or "ammy\svn" strings? 

Tuesday, June 30, 2020

ida bokbot / iced ida python upx

Bokbot/Iced

my notes on following OALabs tutorial, i'm going to try using IDA

https://www.youtube.com/watch?v=wObF9n2UIAM
https://app.any.run/tasks/5fb451b5-a3d6-451c-9ce1-76897bf53f2d/
0ca2971ffedf0704ac5a2b6584f462ce27bac60f17888557dc8cd414558b479e

because it appears like process injection in hybrid analysis, try these breakpoints
CreateProcessInternalW
WriteProcessMemory
ResumeThread

bp1 [CreateProcessInternalW]
string on stack is this EXEs full path

bp2 [WriteProcessMemory] <-- looking for a PE file in memory that is getting written
on the stack, 1st parameter is handle of process
2nd parameter is the "destination" memory location
3rd parameter is the "source" memory location, or WHAT DATA THEY ARE WRITING
debug041:002C0000, end 0x002E0000, size = 0x20000
starts with MZ so definitely an EXE
hit SHIFT-F2, select python, type in this code
filename = AskFile(1, "*.bin", "Output file name")
address = 0x002C0000
size = 0x20000
dbgr = False
with open(filename, "wb") as out:
  data = GetManyBytes(address, size, use_dbg=dbgr)
  out.write(data)
save the dumped file to your desktop

Open newly saved dump file in PE BEAR
notice sections are named UPX0, UPX1, UPX2

Open in Hex Editor, notice how "code" starts at the Virtual Addres (6000) (null bytes before) instead of the Raw (400)
this means it's mapped, so we need to change it to unmapped
1) change the addresses so Raw = Virtual Address in PE BEAR
2.) change the sizes to match also
3.) SAVE AS "dumped file unmapped.bin" to your desktop

Unfortunately UPX tools likely won't worked now that we changed it from mapped to unmapped addresses

Close IDA, re-open the new "dumped file unmapped.bin" from the desktop

start debugger, breakpoint at entry
look in graph view for a "jmp" statement following by oddness (this is common with UPX)
in this case it was
UPX1:0041E083
jmp near ptr byte_4015C3
and it has a red error message "start endp ; sp-analysis failed"

note: he says that VirtualAlloc, VirtualProtect trick should also work

so its about to jump to UPX0:004015C3, end 0x00406000, size = 0x4A3D
so i'm going to try in IDA hit SHIFT-F2, select python, type in this code
filename = AskFile(1, "*.bin", "Output file name")
address = 0x004015C3
size = 0x4A3D
dbgr = False
with open(filename, "wb") as out:
  data = GetManyBytes(address, size, use_dbg=dbgr)
  out.write(data)
but that doesn't seem to give me anything useful, no strings
If I open in IDA as a "binary file" i can see some code though, stack strings, etc. but not what APIs are called

try opening the "dump file unmapped.bin" in x32dbg, start and wait for initial breakpoint
change to graph view
search for the ugly jump in this case
jmp iceid_dumped_unmapped.4015C3
add byte ptr ds:[eax], al ; eax:BaseThreadInitThunk
add byte ptr ds:[eax], al ; eax:BaseThreadInitThunk
add byte ptr ds:[eax], al ; eax:BaseThreadInitThunk
......
breakpoint it and run to it

the value it points to is the new OEP (Original Entry Point)
0x4015C3
if i go in there, the APIs have been mapped so I can see calls to ExitProcess, GetCommandLineA, etc.

Click Scylla
Change OEP to 4015C3
Click dump to save to desktop
click IAT Autosearch
Click Get Imports
Click "Fix Dump"
Terminate in x32dbg

Open IDA, open the fixed dump

generate psuedocode

hover over integer ASCII , click 'r' and it turns it into characters

there are stack strings

this is unpacked but still more work to do

Friday, March 30, 2018

viewing virtualalloc contents

run malware with x64dbg
set breakpoint on Virtualalloc

BPX VirtualAlloc

once hit the break point
look in the call stack for last user code
go there, set breakpoint on next line after virtualalloc user call

Once hit breakspoint, look at EAX value (it will be the newly allocated address)
Follow EAX's value in the dump

Then F8 (step over) 1 line at a time until you see data in the dump

It could be data (like IP addresses) or it could be a full executable (MZ header)

If it's an executable (MZ Header) then right-click, "follow in memory map"
Then right-click in memory map in the address and select "dump memory to file"

open the new dumped EXE in PE Bear
If the text segment is all 0s
Then go to the Section Hdrs tab and change all Raw Addr columns to match Virtual Addr

Then go to Optional Hrd tab and change Image Base column to the address found on Memory Map screen in x64dbg

then open in pestudio and the EXE should look normal now, unpacked!  with urls, ips, iocs, etc.