Monday, June 19, 2006

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


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
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] 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 :)


Anonymous said...

How can i set hardware breakpoint on the memory section?

1. I tried to set hardware breakpoint
but not interupted

2.I trun on the remote debugger plugin by using (ctrl + F1)

but the message listed below are shown in the IDA PRO

Harware breakpoints have been enabled
Successfully attached kernel debugger stub
Command "ProcessStart" failed
Command "ProcessExit" failed
Connection to the Windows CE device has been stopped.

and rapiclnt error occured in the PDA

3. I modified the registry on the PocketPC device. To change the security policy,
set the key '00001001' to dword:1 in HKLM\Security\Policies\Policies

but i doesn`t work.

How can i set hardware breakpoint on the memory section?

newsoft said...

Hello anonymous,

It is hard to debug your issue through blog comments :) Here are a few ideas:

- You might want to check if your processor supports hardware breakpoints.

- Security policies are not always that easy to change. Some operator-customized SmartPhones require "privileged" application to be signed by the operator.

- You might want to be sure that your operating system is supported by IDA Debugger. I have heard that Windows Mobile 6.0 now supports access controls (there is a LSASS process). This might interfere with IDA Debugger. Just try in Windows Mobile 4.2 or 5.0 emulator first (it is a free download from Microsoft).

In any case, for IDA-related questions, Hex-Rays forums might be the best place to go.

Anonymous said...

Tanks for your replying.
I`m from Korea.
And I`m not good at writing in English.
You may have some trouble in reading my sentence.

I use WM 5.0 Emulator included in Visual studio 2008. It uses ARM processor.
Security policies have set 1 as a default.

I have a HP IPAQ pocket PC based on WM5.0.(ARM processor)

Should I have to use a PDA instead of an Emulator?

newsoft said...

@anonymous: I really don't know for sure.

My bet is that the emulator should be closer to the default configuration and easier to debug than a "real" PDA.

So you might have an issue with the IDA debugging stub. After all, it still should be considered as of "beta" quality (I reported a couple of bugs myself).

Maybe you should try upgrading to a newer version of IDA.