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)
Friday, July 31, 2020
Ida Pro Python Save Dump Extract In Memory Unpacked Binary Bin
Wednesday, July 29, 2020
further into the emotet 1st level packer
emotet mfc
https://app.any.run/tasks/585ddd5e-0dde-421f-8b8a-e7dbaf4f8c05/
3F32E053657036D09C84D6DAD220EF50
my random notes on where i got and what i saw
Go into AfxDlgProc() set breakpoint on
call dword ptr [edx+144h]
step into the call (renamed to subEmotetDecryptor)
this is likely the start of the Emotet Decryptor
subEmotetDecryptor()
- CDialog::OnInitDialog()
- GetSystemMenu()
- FromHandle()
- subMove1ValuetoEAX()
- call dword ptr [edx+0ch]
- AfxFindStringResourceHandle()
- subFindResource()
-- FindResourceA()
-- localFunction9()
--- LoadResource()
--- LockResource()
--- SizeOfResource()
--- localFunction10() [GetVersionExA, InterlockedExchange]
--- WideCharToMultiByte()
--- localFunction11()
---- call dword ptr [edx+8]
--- localFunction10() [GetVersionExA, InterlockedExchange]
--- WideCharToMultiByte()
--- localFunction6()
- AppendMenuA()
- AppendMenuA()
- "mshta.exe" stack string
- _wcslen()
- subLotsSubCalls1()
- _wcslen()
- subLotsSubCalls1()
- _wcslen()
- subLotsSubCalls1()
- subLotsSubCalls1b()
- subLotsSubCalls1b()
- subLotsSubCalls1b()
- LoadLibraryExW()
- long string "9xgnie40s......"
- subGetApis()
-- LoadLibraryExA()
--- stack string "VirtaAocExNuma"
--- stack string "kerne32.d"
--- LoadLibraryExA()
--- GetProcAddress
--- stack string "taskmgr.exe"
--- LoadLibraryExA()
--- GetCurrentProcess()
--- subFindResourceHandleCallPtr()
--- call ebp (1st unpacked code????)
---- subGetApiIntoEax (LoadLibraryA)
---- subGetApiIntoEax (GetProcAddress)
---- subGetApiIntoEax (VirtualAlloc)
---- subGetApiIntoEax (VirtualProtect)
---- subGetApiIntoEax (ZwFlushInstructionCache)
---- subGetApiIntoEax (GetNativeSystemInfo)
---- call ebx (GetNativeSystemInfo)
---- eax = 4096 (on my machine) - 1 = 4095 <== dwPageSize? size of page used by VirtualAlloc
---- ebx = 53248 (on my machine)
---- ecx = FFF + C200 = D1FF
---- edx = !FFF = FFFFF000
---- eax = eax + ebx = DFFF
---- ecx = ecx & edx = D000
---- eax = eax & edx = D000
---- if eax != ecx [exit]
---- call ebp (VirtualAlloc(null, 53248, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE), returns EAX = 00300000
---- call [esp+5Ch+var_3C] (LoadLibraryA("Kernel32.dll"), returns EAX=76140000
---- call esi (GetProcAddress(7614000, IsProcessorFeaturePresent), returns EAX=76155135
---- loop
----- call [esp+68h+var_2C] (VirtualProtect(0x00301000, 28160, PAGE_EXECUTE_READ)
----- call [esp+68h+var_2C] (VirtualProtect(0x00308000, 512, PAGE_READONLY)
----- call [esp+68h+var_2C] (VirtualProtect(0x00309000, 3072, PAGE_READWRITE)
----- call [esp+68h+var_2C] (VirtualProtect(0x0030B000, 512, PAGE_READONLY)
----- call [esp+68h+var_2C] (VirtualProtect(0x0030C000, 512, PAGE_READONLY)
---- call [esp+64h+var_28] (ZwFlushInstructionCache(0xFFFFFFFF, null, null)
---- call esi (local code debug038:0034244)
----- call localFunction1()
------ ***lots of calls to decryptApi() and many much more code***, i set breakpoints on decryptApi calls, they are below
------ GetProcessHeap(), returns EAX=0x00520000
------ GetModuleHandleA("NTDLL"), returns EAX=77910000
------ RtlAllocateHeap(0x00520000, HEAP_ZERO_MEMORY, 48)
------ GetProcessHeap()
------ RtlAllocateHeap(0x00520000, HEAP_ZERO_MEMORY, 48) <== lots of these, skipping them in the future
------ LoadLibraryW("advapi32.dll"), returns EAX=75D20000
------ GetProcessHeap() <== lots of these, skipping them in the future
------ HeapFree() <== lots of these, skipping them in the future
------ LoadLibraryW("crypt32.dll"), returns EAX=753C0000
------ LoadLibraryW("shell32.dll"), returns EAX=76480000
------ LoadLibraryW("shlwapi.dll"), returns EAX=760B0000
------ LoadLibraryW("urlmon.dll"), returns EAX=750C0000
------ LoadLibraryW("userenv.dll"), returns EAX=76080000
------ LoadLibraryW("wininet.dll"), returns EAX=75680000
------ LoadLibraryW("stsapi32.dll"), returns EAX=74B50000
------ OpenScManagerW(null, null, SC_MANAGER_ALL_ACCESS)
------ CloseServiceHandle()
------ SHGetFolderPathW()
------ GetModuleFileNameW(null) <-- gets full path of this exe
------ PathSkipRootW()
------ PathFindExtensionW()
------ lstrcpynW()
------ GetModuleFileNameW(null)
------ snwprintf()
------ FindFirstFileW("c:\windows\system32\")
------ loop
------- FindNextFileW()
------- sometimes ==> PathFindExtensionW("12520437.cpx") <-- ran multiple file names, folders, dlls, etc.
------ FindClose()
------ GetCommandLineW()
------ CommandLineToArgW()
------ LocalFree()
------ GetModuleFileNameW(null)
------ CreateFileW("c:\users\win7\desktop\emotet.exe", FILE_READ_ATTRIBUTES, FILE_SHARE_READ) <-- name of this executable
------ GetFileInformationByHandleEx()
------ CloseHandle()
------ GetSystemTimeAsFileTime()
------ OpenScManagerW()
------ OpenServiceW(, "emotet", ) <-- name of current executable, returns NULL because doesn't exist
------ CloseServiceHandle()
------ GetTickCount()
------ lstrcpyW()
------ lstrlenW()
------ GetTickCount()
------ lstrcpyW()
------ lstrlenW()
------ GetCurrentProcessID()
------ memset(0x18E76Ch, 0, 30)
------ memset(0x18E76Ch, 0, 500)
------ memset(..)
------ lstrcpyW("c:\windows\syswow64\cmdl32\negoexts.exe", ..)
------ SHFileOperationW()
*** IDS thew a next step debugger exception here ***
----- call decryptApi()
----- call eax
---- *** more code ***
---- call eax (near the bottom)
- call dword ptr [edx+4]
- SendMessageA()
- SendMessageA()
- SendMessageA()
- call dword ptr [edx+140h]
- string "http://www.ucancode.net..."
- subFindResourceHandleCallPtr2()
- call dword ptr [eax+138h]
- Cwnd::GetDlgItem()
- GetWindowRect()
- Cwnd::ScreenToClient()
https://app.any.run/tasks/585ddd5e-0dde-421f-8b8a-e7dbaf4f8c05/
3F32E053657036D09C84D6DAD220EF50
my random notes on where i got and what i saw
Go into AfxDlgProc() set breakpoint on
call dword ptr [edx+144h]
step into the call (renamed to subEmotetDecryptor)
this is likely the start of the Emotet Decryptor
subEmotetDecryptor()
- CDialog::OnInitDialog()
- GetSystemMenu()
- FromHandle()
- subMove1ValuetoEAX()
- call dword ptr [edx+0ch]
- AfxFindStringResourceHandle()
- subFindResource()
-- FindResourceA()
-- localFunction9()
--- LoadResource()
--- LockResource()
--- SizeOfResource()
--- localFunction10() [GetVersionExA, InterlockedExchange]
--- WideCharToMultiByte()
--- localFunction11()
---- call dword ptr [edx+8]
--- localFunction10() [GetVersionExA, InterlockedExchange]
--- WideCharToMultiByte()
--- localFunction6()
- AppendMenuA()
- AppendMenuA()
- "mshta.exe" stack string
- _wcslen()
- subLotsSubCalls1()
- _wcslen()
- subLotsSubCalls1()
- _wcslen()
- subLotsSubCalls1()
- subLotsSubCalls1b()
- subLotsSubCalls1b()
- subLotsSubCalls1b()
- LoadLibraryExW()
- long string "9xgnie40s......"
- subGetApis()
-- LoadLibraryExA()
--- stack string "VirtaAocExNuma"
--- stack string "kerne32.d"
--- LoadLibraryExA()
--- GetProcAddress
--- stack string "taskmgr.exe"
--- LoadLibraryExA()
--- GetCurrentProcess()
--- subFindResourceHandleCallPtr()
--- call ebp (1st unpacked code????)
---- subGetApiIntoEax (LoadLibraryA)
---- subGetApiIntoEax (GetProcAddress)
---- subGetApiIntoEax (VirtualAlloc)
---- subGetApiIntoEax (VirtualProtect)
---- subGetApiIntoEax (ZwFlushInstructionCache)
---- subGetApiIntoEax (GetNativeSystemInfo)
---- call ebx (GetNativeSystemInfo)
---- eax = 4096 (on my machine) - 1 = 4095 <== dwPageSize? size of page used by VirtualAlloc
---- ebx = 53248 (on my machine)
---- ecx = FFF + C200 = D1FF
---- edx = !FFF = FFFFF000
---- eax = eax + ebx = DFFF
---- ecx = ecx & edx = D000
---- eax = eax & edx = D000
---- if eax != ecx [exit]
---- call ebp (VirtualAlloc(null, 53248, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE), returns EAX = 00300000
---- call [esp+5Ch+var_3C] (LoadLibraryA("Kernel32.dll"), returns EAX=76140000
---- call esi (GetProcAddress(7614000, IsProcessorFeaturePresent), returns EAX=76155135
---- loop
----- call [esp+68h+var_2C] (VirtualProtect(0x00301000, 28160, PAGE_EXECUTE_READ)
----- call [esp+68h+var_2C] (VirtualProtect(0x00308000, 512, PAGE_READONLY)
----- call [esp+68h+var_2C] (VirtualProtect(0x00309000, 3072, PAGE_READWRITE)
----- call [esp+68h+var_2C] (VirtualProtect(0x0030B000, 512, PAGE_READONLY)
----- call [esp+68h+var_2C] (VirtualProtect(0x0030C000, 512, PAGE_READONLY)
---- call [esp+64h+var_28] (ZwFlushInstructionCache(0xFFFFFFFF, null, null)
---- call esi (local code debug038:0034244)
----- call localFunction1()
------ ***lots of calls to decryptApi() and many much more code***, i set breakpoints on decryptApi calls, they are below
------ GetProcessHeap(), returns EAX=0x00520000
------ GetModuleHandleA("NTDLL"), returns EAX=77910000
------ RtlAllocateHeap(0x00520000, HEAP_ZERO_MEMORY, 48)
------ GetProcessHeap()
------ RtlAllocateHeap(0x00520000, HEAP_ZERO_MEMORY, 48) <== lots of these, skipping them in the future
------ LoadLibraryW("advapi32.dll"), returns EAX=75D20000
------ GetProcessHeap() <== lots of these, skipping them in the future
------ HeapFree() <== lots of these, skipping them in the future
------ LoadLibraryW("crypt32.dll"), returns EAX=753C0000
------ LoadLibraryW("shell32.dll"), returns EAX=76480000
------ LoadLibraryW("shlwapi.dll"), returns EAX=760B0000
------ LoadLibraryW("urlmon.dll"), returns EAX=750C0000
------ LoadLibraryW("userenv.dll"), returns EAX=76080000
------ LoadLibraryW("wininet.dll"), returns EAX=75680000
------ LoadLibraryW("stsapi32.dll"), returns EAX=74B50000
------ OpenScManagerW(null, null, SC_MANAGER_ALL_ACCESS)
------ CloseServiceHandle()
------ SHGetFolderPathW()
------ GetModuleFileNameW(null) <-- gets full path of this exe
------ PathSkipRootW()
------ PathFindExtensionW()
------ lstrcpynW()
------ GetModuleFileNameW(null)
------ snwprintf()
------ FindFirstFileW("c:\windows\system32\")
------ loop
------- FindNextFileW()
------- sometimes ==> PathFindExtensionW("12520437.cpx") <-- ran multiple file names, folders, dlls, etc.
------ FindClose()
------ GetCommandLineW()
------ CommandLineToArgW()
------ LocalFree()
------ GetModuleFileNameW(null)
------ CreateFileW("c:\users\win7\desktop\emotet.exe", FILE_READ_ATTRIBUTES, FILE_SHARE_READ) <-- name of this executable
------ GetFileInformationByHandleEx()
------ CloseHandle()
------ GetSystemTimeAsFileTime()
------ OpenScManagerW()
------ OpenServiceW(, "emotet", ) <-- name of current executable, returns NULL because doesn't exist
------ CloseServiceHandle()
------ GetTickCount()
------ lstrcpyW()
------ lstrlenW()
------ GetTickCount()
------ lstrcpyW()
------ lstrlenW()
------ GetCurrentProcessID()
------ memset(0x18E76Ch, 0, 30)
------ memset(0x18E76Ch, 0, 500)
------ memset(..)
------ lstrcpyW("c:\windows\syswow64\cmdl32\negoexts.exe", ..)
------ SHFileOperationW()
*** IDS thew a next step debugger exception here ***
----- call decryptApi()
----- call eax
---- *** more code ***
---- call eax (near the bottom)
- call dword ptr [edx+4]
- SendMessageA()
- SendMessageA()
- SendMessageA()
- call dword ptr [edx+140h]
- string "http://www.ucancode.net..."
- subFindResourceHandleCallPtr2()
- call dword ptr [eax+138h]
- Cwnd::GetDlgItem()
- GetWindowRect()
- Cwnd::ScreenToClient()
Labels:
AfxDlgProc,
emotet,
IDA,
LoadLibraryW,
mfc,
OpenScManagerW,
OpenServiceW
Tuesday, July 28, 2020
emotet mfc using CreateDlgIndirect lpDialogFunc call-back
emotet mfc starting point notes, trying to figure out where the malicious code starts
https://app.any.run/tasks/585ddd5e-0dde-421f-8b8a-e7dbaf4f8c05/
3F32E053657036D09C84D6DAD220EF50
WinMain()
-AfxGetThread()
-AfxGetModuleState()
-AfxWinInit()
--AfxGetModuleState()
--AfxGetModuleState()
--CWinApp::SetCurrentHandles()
--AfxGetModuleState()
--AfxInitThread()
---AfxGetModuleState()
---AfxGetThreadState()
---AfxMsgFilterHook()
--GetModuleHandleA(user32.dll)
--GetProcAddress(NotifyWinEvent)
-call dword ptr [eax+90h] (which is CWinApp::InitApplication)
-call dword ptr [eax+50h] (which is local function in .text)
-- AfxEnableControlContainer()
-- call localFunction1()
--- CDialog::CDialog()
--- call localFunction3()
---- CWnd::CWnd
---- call localFunction4() [just moves 1 memory slot]
---- call dword ptr [edx+0ch]
---- CToolTipCtrl::CToolTipCtrl()
---- GetSysColor
---- call localFunction5()
----- branches to possibly these items
------ localFunction6()
------- branches to possibly these items
-------- unknown_libname (mfc 3.1-14.0 32bit)
-------- AfxThrowOleException
------ call dword ptr [edx+4]
----- call dword ptr [eax+0ch]
--- CWnd::CWnd()
--- call ??_L@... (vector constructor iterator)
--- AfxGetModuleState()
--- AfxGetModuleState()
--- LoadIconA
-- CDialog::DoModal()
-- call localFunction2()
-if success
--call dword ptr [eax+54h] (which is CWinApp::Run)
-if failure
--call dword ptr [eax+68h] (which is CWinApp::ExitInstance)
-AfxWinTerm
my 1st assumption was to break on
CWinApp::Run
that didn't work, emotet still installed service & never hit my breakpoint
so instead i end up looking at that local function in .text that calls
AfxEnableControlContainer, DoModal
googling shows this template below is common in C# mfc code that does a "popup dialog box"
CWinApp::InitInstance()
AfxEnableControlContainer()
CMainDialog dlg
dlg.DoModal()
emotet doesn't show a modal (unless it's hidden?) but maybe there is hidden code in the modal???
trying to find a good breakpoint
- AfxEnableControlContainer is hit
- call localFunction1 is hit
- DoModal is hit
- call localFunction2 is NOT hit
malicious code appears to execute & exit when DoModal is called
Inside DoModal i first tried breakpoints at
CDialog::PostModal
but it never hit my breakspoint, so malicious code ran before that
DoModal (still in the .text section)
- AfxGetModuleState()
- AfxGetModuleState()
- FindResourceA()
- LoadResource()
- LockResource()
- CDialog::PreModal()
- AfxUnhookWindowCreate()
- AfxHookWindowCreate()
- CWnd::FromHandle()
- CWnd::CreateDlgIndirect()
- ... more ...
Stepping thru DoModal, the malicious code runs after call to
CWnd::CreateDlgIndirect()
so I need to dig more in there
msdn ( https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-createdialogindirecta )
appears to indicate that there is a lpDialogFunc of type DLGPROC
this can be a call-back procedure, i think there is where the malicious code is
CreateDlgIndirect()
- CreateDialogIndirectParamA(..., AfxDlgProc/lpDialogFunc, )
-- CreateDialogIndirectParamAorW()
--- call near ptr unk_76371801
--- call near ptr unk_763718E1
---- AfxDlgProc() <-- i think this is the CreateDlgIndirect using the call-back function
---- call dword ptr [edx+144h]
------ call localFunction7() in .text
------- CDialog::OnInitDialog()
------- GetSystemMenu()
------- FromHandle()
------- localFunction4()
------- call dword ptr [edx+0ch]
------- AfxFindStringResourceHandle()
------- localFunction8() <-- possibly the start of the malicious code
-------- FindResourceA()
-------- localFunction9()
--------- LoadResource()
--------- LockResource()
--------- SizeOfResource()
--------- localFunction10() [GetVersionExA, InterlockedExchange]
--------- WideCharToMultiByte()
--------- localFunction11()
---------- call dword ptr [edx+8]
--------- localFunction10() [GetVersionExA, InterlockedExchange]
--------- WideCharToMultiByte()
--------- localFunction6()
------- AppendMenuA()
------- !!! DEFINITELY EVIL CODE !!!
------- (stack string for mshta.exe)
https://app.any.run/tasks/585ddd5e-0dde-421f-8b8a-e7dbaf4f8c05/
3F32E053657036D09C84D6DAD220EF50
WinMain()
-AfxGetThread()
-AfxGetModuleState()
-AfxWinInit()
--AfxGetModuleState()
--AfxGetModuleState()
--CWinApp::SetCurrentHandles()
--AfxGetModuleState()
--AfxInitThread()
---AfxGetModuleState()
---AfxGetThreadState()
---AfxMsgFilterHook()
--GetModuleHandleA(user32.dll)
--GetProcAddress(NotifyWinEvent)
-call dword ptr [eax+90h] (which is CWinApp::InitApplication)
-call dword ptr [eax+50h] (which is local function in .text)
-- AfxEnableControlContainer()
-- call localFunction1()
--- CDialog::CDialog()
--- call localFunction3()
---- CWnd::CWnd
---- call localFunction4() [just moves 1 memory slot]
---- call dword ptr [edx+0ch]
---- CToolTipCtrl::CToolTipCtrl()
---- GetSysColor
---- call localFunction5()
----- branches to possibly these items
------ localFunction6()
------- branches to possibly these items
-------- unknown_libname (mfc 3.1-14.0 32bit)
-------- AfxThrowOleException
------ call dword ptr [edx+4]
----- call dword ptr [eax+0ch]
--- CWnd::CWnd()
--- call ??_L@... (vector constructor iterator)
--- AfxGetModuleState()
--- AfxGetModuleState()
--- LoadIconA
-- CDialog::DoModal()
-- call localFunction2()
-if success
--call dword ptr [eax+54h] (which is CWinApp::Run)
-if failure
--call dword ptr [eax+68h] (which is CWinApp::ExitInstance)
-AfxWinTerm
my 1st assumption was to break on
CWinApp::Run
that didn't work, emotet still installed service & never hit my breakpoint
so instead i end up looking at that local function in .text that calls
AfxEnableControlContainer, DoModal
googling shows this template below is common in C# mfc code that does a "popup dialog box"
CWinApp::InitInstance()
AfxEnableControlContainer()
CMainDialog dlg
dlg.DoModal()
emotet doesn't show a modal (unless it's hidden?) but maybe there is hidden code in the modal???
trying to find a good breakpoint
- AfxEnableControlContainer is hit
- call localFunction1 is hit
- DoModal is hit
- call localFunction2 is NOT hit
malicious code appears to execute & exit when DoModal is called
Inside DoModal i first tried breakpoints at
CDialog::PostModal
but it never hit my breakspoint, so malicious code ran before that
DoModal (still in the .text section)
- AfxGetModuleState()
- AfxGetModuleState()
- FindResourceA()
- LoadResource()
- LockResource()
- CDialog::PreModal()
- AfxUnhookWindowCreate()
- AfxHookWindowCreate()
- CWnd::FromHandle()
- CWnd::CreateDlgIndirect()
- ... more ...
Stepping thru DoModal, the malicious code runs after call to
CWnd::CreateDlgIndirect()
so I need to dig more in there
msdn ( https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-createdialogindirecta )
appears to indicate that there is a lpDialogFunc of type DLGPROC
this can be a call-back procedure, i think there is where the malicious code is
CreateDlgIndirect()
- CreateDialogIndirectParamA(..., AfxDlgProc/lpDialogFunc, )
-- CreateDialogIndirectParamAorW()
--- call near ptr unk_76371801
--- call near ptr unk_763718E1
---- AfxDlgProc() <-- i think this is the CreateDlgIndirect using the call-back function
---- call dword ptr [edx+144h]
------ call localFunction7() in .text
------- CDialog::OnInitDialog()
------- GetSystemMenu()
------- FromHandle()
------- localFunction4()
------- call dword ptr [edx+0ch]
------- AfxFindStringResourceHandle()
------- localFunction8() <-- possibly the start of the malicious code
-------- FindResourceA()
-------- localFunction9()
--------- LoadResource()
--------- LockResource()
--------- SizeOfResource()
--------- localFunction10() [GetVersionExA, InterlockedExchange]
--------- WideCharToMultiByte()
--------- localFunction11()
---------- call dword ptr [edx+8]
--------- localFunction10() [GetVersionExA, InterlockedExchange]
--------- WideCharToMultiByte()
--------- localFunction6()
------- AppendMenuA()
------- !!! DEFINITELY EVIL CODE !!!
------- (stack string for mshta.exe)
Labels:
AfxDlgProc,
CreateDialogIndirectParamA,
CreateDialogIndirectParamAorW,
CreateDlgIndirect,
DLGPROC,
DoModal,
emotet,
lpDialogFunc,
mfc,
WinMain
emotet api resolution, fs:30h, _PEB_LDR_DATA
just summarizing important parts in this great blog
https://distributedcompute.com/2020/04/19/how-emotet-resolves-apis/
-----------
STEPS TO GET THE DLL NAMES CURRENTLY IN MEMORY
-----------
mov eax, large fs:30h
EAX now contains pointer to TEB (thread environment block)
-----------
mov esi, [eax+0ch]
ESI now contains pointer to PEB (process environment block)
-----------
add esi, 0ch
ESI now contains pointer to _PEB_LDR_DATA (doubly linked list of in memory modules/dlls)
-----------
-----------
STEPS TO GET THE EXPORTED FUNCTION NAMES FROM A DLL
-----------
mov eax, [esi+3ch] #esi = _PEB_LDR_DATA from above
EAX now contains pointer to PE Header
------------
add eax, 78h
EAX now contains pointer to Export Table from PE Header
-------------
mov edi, [eax]
add edi, esi
mov eax, [edi+20h]
EAX now contains point to Export NAME table
---------------
mov eax, [edi+1Ch]
EAX now contains pointer to Export ADDRESS table
EAX now
https://distributedcompute.com/2020/04/19/how-emotet-resolves-apis/
-----------
STEPS TO GET THE DLL NAMES CURRENTLY IN MEMORY
-----------
mov eax, large fs:30h
EAX now contains pointer to TEB (thread environment block)
-----------
mov esi, [eax+0ch]
ESI now contains pointer to PEB (process environment block)
-----------
add esi, 0ch
ESI now contains pointer to _PEB_LDR_DATA (doubly linked list of in memory modules/dlls)
-----------
-----------
STEPS TO GET THE EXPORTED FUNCTION NAMES FROM A DLL
-----------
mov eax, [esi+3ch] #esi = _PEB_LDR_DATA from above
EAX now contains pointer to PE Header
------------
add eax, 78h
EAX now contains pointer to Export Table from PE Header
-------------
mov edi, [eax]
add edi, esi
mov eax, [edi+20h]
EAX now contains point to Export NAME table
---------------
mov eax, [edi+1Ch]
EAX now contains pointer to Export ADDRESS table
EAX now
attempt at emotet api resolver
random scattered notes
https://app.any.run/tasks/585ddd5e-0dde-421f-8b8a-e7dbaf4f8c05/
3F32E053657036D09C84D6DAD220EF50
update: after-the-fact This blog seems useful
https://distributedcompute.com/2020/04/19/how-emotet-resolves-apis/
"...the FS register points to the Thread Environment Block, or TEB. The offset 0x30 contains a pointer to the Process Environment Block, or PEB. From there the malware will walk the structure to _PEB_LDR_DATA which contains the head of a doubly-linked list called InMemoryOrderModuleList. This list contains the list entries containing BaseDllName and DllBase. When the entry point to the PE header is located, the PE structure is walked to find the export table. Emotet will then loop over the exported names to find the API function it is searching for..."
-----------
api monitor
-----------
910.exe
- spawned child "mssvp.exe" in appdata
- create windows service mssvp
sc delete "service name"
copy emotet_copy.exe emotet.exe
breakpoint openscmanager
ctrl-f7 (run until return, until get back to "debug" code)
select program segment, highlight, click 'C' for code, analyze
change to "Graph View"
look for code
mov ecx, [esi+30h]
call sub_???? (transform api with bunch of xors)
xor eax, 11D20899h
cmp eax, ebx
looking for 23F29385 (in ebx)
dll name transformed xor'd
emotet-910.exe C9F6F7D9 D824FC40
ntdll.dll D22E2014 C3FC288D
kernel32.dll 8F7EE672 9EaCEDEB
KERNELBASE.dll 6267DEE4 73B5D57D
USER32.dll D3361080 C2E41B19
GDI32.dll B6C64D61 A71446F8
LPK.dll FF368B1D EEE48084
UPS10.dll F73320A7 E6E12B3E
msvcrt.dll 88053F6B 99D734F2
ADVAPI32.dll 3220981C 23F29385 (found it)
mov edx, 4A609DFEh
mov ecx, 23F29385h #transformed & xor'd api to resolve
call apiResolver
apiResolver(edx=not used (4A609DFEh), ecx=transformAndXordApi (23F29385))
apiResolverInternal(edi=4A609DFEh, ecx=transformAndXordApi (23F29385))
foreach api in fs:30h
eax = subTransformModule(ecx=edi+esicounter) #30h intervals
eax = eax | 11D20399h
if(eax == transformAndXordApi)
eax = [esi+18h] # the starting address of the module dll (75D20000 for ADVAPI32)
exit loop & use it
functionResolver(edx=function looking for (4A609DFEh), ecx=apiResolutionDllAddress (75D20000 for ADVAPI32))
foreach function
ecx = ecx + apicounter #ecx starts as ADVAPI32 address
eax = subTransformFunction(ecx)
eax = eax | 5776499Bh
if(eax == edx)
eax=ecx
exit loop & use it
looking for 4A609DFEh (in ebp+var8)
function name transformed xor'd
** F82294E8 AF54DD73
** 838A4B1E D4FC0285
** FC3ECBB7 AB48822C
** 4C8FA46C 1BF9EDF7
** 4C8FA482 1BF9ED19
CloseServiceHandle *** ***
https://app.any.run/tasks/585ddd5e-0dde-421f-8b8a-e7dbaf4f8c05/
3F32E053657036D09C84D6DAD220EF50
update: after-the-fact This blog seems useful
https://distributedcompute.com/2020/04/19/how-emotet-resolves-apis/
"...the FS register points to the Thread Environment Block, or TEB. The offset 0x30 contains a pointer to the Process Environment Block, or PEB. From there the malware will walk the structure to _PEB_LDR_DATA which contains the head of a doubly-linked list called InMemoryOrderModuleList. This list contains the list entries containing BaseDllName and DllBase. When the entry point to the PE header is located, the PE structure is walked to find the export table. Emotet will then loop over the exported names to find the API function it is searching for..."
-----------
api monitor
-----------
910.exe
- spawned child "mssvp.exe" in appdata
- create windows service mssvp
sc delete "service name"
copy emotet_copy.exe emotet.exe
breakpoint openscmanager
ctrl-f7 (run until return, until get back to "debug" code)
select program segment, highlight, click 'C' for code, analyze
change to "Graph View"
look for code
mov ecx, [esi+30h]
call sub_???? (transform api with bunch of xors)
xor eax, 11D20899h
cmp eax, ebx
looking for 23F29385 (in ebx)
dll name transformed xor'd
emotet-910.exe C9F6F7D9 D824FC40
ntdll.dll D22E2014 C3FC288D
kernel32.dll 8F7EE672 9EaCEDEB
KERNELBASE.dll 6267DEE4 73B5D57D
USER32.dll D3361080 C2E41B19
GDI32.dll B6C64D61 A71446F8
LPK.dll FF368B1D EEE48084
UPS10.dll F73320A7 E6E12B3E
msvcrt.dll 88053F6B 99D734F2
ADVAPI32.dll 3220981C 23F29385 (found it)
mov edx, 4A609DFEh
mov ecx, 23F29385h #transformed & xor'd api to resolve
call apiResolver
apiResolver(edx=not used (4A609DFEh), ecx=transformAndXordApi (23F29385))
apiResolverInternal(edi=4A609DFEh, ecx=transformAndXordApi (23F29385))
foreach api in fs:30h
eax = subTransformModule(ecx=edi+esicounter) #30h intervals
eax = eax | 11D20399h
if(eax == transformAndXordApi)
eax = [esi+18h] # the starting address of the module dll (75D20000 for ADVAPI32)
exit loop & use it
functionResolver(edx=function looking for (4A609DFEh), ecx=apiResolutionDllAddress (75D20000 for ADVAPI32))
foreach function
ecx = ecx + apicounter #ecx starts as ADVAPI32 address
eax = subTransformFunction(ecx)
eax = eax | 5776499Bh
if(eax == edx)
eax=ecx
exit loop & use it
looking for 4A609DFEh (in ebp+var8)
function name transformed xor'd
** F82294E8 AF54DD73
** 838A4B1E D4FC0285
** FC3ECBB7 AB48822C
** 4C8FA46C 1BF9EDF7
** 4C8FA482 1BF9ED19
CloseServiceHandle *** ***
Thursday, July 16, 2020
IDA Pro Debug Load DLL export function, getting Error WerMgr fault
If you are trying to debug a DLL and getting a wermgr fault using IDA it may be because you are using the WRONG version of rundll32.exe
there are 2 versions on a 64 bit windows 7/10 machine
c:\windows\system32\rundll32.exe <-- this is the 64 bit and should be used with 64 bit dlls
c:\windows\syswow64\rundll32.exe <-- this is the 32 bit and should be used with 32 bit dlls
so if i am analyzing a DLL with an export function such as "update.dll" with function "StartW"
if i open in PEstudio and see that it's a 32 bit DLL then my IDA Debugger -> process options would be
Application: c:\windows\syswow64\rundll32.exe
Input file: [my dll path]
Directory: [my dll folder]
Parameters: [my dll path], [my export function]
I noticed that initially i was trying
Application: c:\windows\system32\rundll32.exe
but rundll32 would just crash and IDA would never hit my breakpoint
but if i changed it to
Application: c:\windows\syswow64\rundll32.exe
there are 2 versions on a 64 bit windows 7/10 machine
c:\windows\system32\rundll32.exe <-- this is the 64 bit and should be used with 64 bit dlls
c:\windows\syswow64\rundll32.exe <-- this is the 32 bit and should be used with 32 bit dlls
so if i am analyzing a DLL with an export function such as "update.dll" with function "StartW"
if i open in PEstudio and see that it's a 32 bit DLL then my IDA Debugger -> process options would be
Application: c:\windows\syswow64\rundll32.exe
Input file: [my dll path]
Directory: [my dll folder]
Parameters: [my dll path], [my export function]
I noticed that initially i was trying
Application: c:\windows\system32\rundll32.exe
but rundll32 would just crash and IDA would never hit my breakpoint
but if i changed it to
Application: c:\windows\syswow64\rundll32.exe
then it would hit my breakpoint in IDA
nice!