Ida Pro Python Save Dump Extract In Memory Unpacked Binary Bin

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)

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()

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)

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

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  ***                ***

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

then it would hit my breakpoint in IDA

nice!