Recovering Pocket Outlook passwords, part 1
What are we doing here ?
We are trying to recover stored passwords inside a Windows Mobile PDA. The target configuration is:
- Software: Windows Mobile 2003 1st Ed.
- Hardware: HP iPaq 5550 w/ French ROM v1.10
- Tools: IDA Pro 5.0 w/ WinCE Debugging Module, ITSME tools
Analysis
Looking for an entry point
"Pocket Outlook" is named internally the "TMAIL.EXE" application. One way to begin the analysis is to look for the "save password" checkbox inside resources. However, "TMAIL.EXE" has few resources and many dependencies. Having a closer look, it appears that all resources are located inside "OUTRES.DLL". This is not an explicit dependency, for it is loaded through a LoadLibraryW() call.
Two dialogs have the "save password" checkbox: #32803 and #32955.
At some point, the application will have to get the password value from the textbox. This is where debugging comes into play. There are only 10 references to GetDlgItemTextW() - it seems easy to put 10 breakpoints and narrow down the search.
Debugging TMAIL.EXE
However TMAIL.EXE is a ROM application, so no breakpoint can be set! The trick here is to kill the running TMAIL.EXE application and have the TMAIL.EXE application running from Flash memory.
Z:\TMAIL Reversing\ITSME tools\itsutils\build>pps
handle n base kern user heap exe
13878f82 1 1c000000 0.0 0.0 0 Notes.exe
1395a67e 5 16000000 0.0 0.0 0 DM_k.exe
13a27efe 2 12000000 0.0 0.0 0 BTTrayCE.exe
13c528fe 5 0a000000 0.0 0.0 0 srvtrust.exe
13cfa6de 15 06000000 0.0 0.0 0 gwes.exe
13fb7002 1 c2000000 0.0 0.0 0 NK.EXE
337a1d4a 5 22000000 0.0 0.0 0 tmail.exe -RunInBKG
33809952 3 1a000000 0.0 0.0 0 repllog.exe /remote /all /h /p:all
33ef189a 1 14000000 0.0 0.0 0 BioDetect.exe
5346547e 1 1e000000 0.0 0.0 0 calc.exe
53f47e5e 67 08000000 0.0 1.9 0 device.exe
73c578c6 5 0c000000 0.0 0.0 0 shell32.exe
73f8e822 6 04000000 0.0 0.0 0 filesys.exe
9335818e 3 26000000 0.0 0.0 0 udp2tcp.exe
93405292 1 28000000 0.0 0.0 0 cerdisp.exe
934dd936 4 20000000 0.0 13.0 0 rapisrv.exe
b395afd6 5 18000000 0.0 0.0 0 poutlook.exe
b3c577d6 2 10000000 0.0 0.0 0 connmgr.exe
f340541e 2 24000000 0.0 0.0 0 rnaapp.exe -n -m -e"`USB Default"
f3c5790e 5 0e000000 0.0 0.0 0 services.exe
60 0 ........ 0.0 14.9 0 total
Z:\TMAIL Reversing\ITSME tools\itsutils\build>pkill tmail.exe
00000000 | tmail.exe killed Now we can see that the "good" call is coming from some sub @ 0x3AEE8.
Tracing further
GetDlgItemTextW() prototype is the following (including registers used in ARM calling convention):
UINT GetDlgItemText( [R0] HWND hDlg, [R1] int nIDDlgItem, [R2] LPTSTR lpString, [R3] int nMaxCount );R1 will take the following values:
- 0x805B account name
- 0x805C login name
- 0x805D password
Now we have to track the use of the password string. Placing a hardware read breakpoint on it, we are interrupted inside COREDLL with the following call stack: COREDLL <- wcslen() <- sub_355D8().
The heart of it all
A few lines below lays what we were looking for: a CryptProtectData() call!
CryptProtectData() prototype is the following (including registers used in ARM calling convention):
BOOL WINAPI CryptProtectData(
[R0] DATA_BLOB* pDataIn,
[R1] LPCWSTR szDataDescr,
[R2] DATA_BLOB* pOptionalEntropy,
[R3] PVOID pvReserved,
[stack] CRYPTPROTECT_PROMPTSTRUCT* pPromptStruct,
[stack] DWORD dwFlags,
[stack] DATA_BLOB* pDataOut
);
Now the values are:
arg0 = input buffer (our password, in Unicode form)
arg1 = NULL
arg2 = "Software\Microsoft\Inbox\Svc" (optional entropy string, of length 0x38)
arg3 = NULL
arg4 = NULL
arg5 = 0x20000000
arg6 = some output buffer
The problem
From WINCRYPT.H, we can see that 0x20000000 corresponds to the CRYPTPROTECT_SYSTEM flag.
And there we have a problem: only a "trusted" process will be allowed to access the data. In this case, that means a ROM-based process.
Solution ? You will have to wait for the next blog entry :)
