[Windows Phone 7 Development and Hacking] Martin7Pro:
Driver+App Source Code

There is source code of driver and launching application too (include driver load/unload from WP7 Kernel for easy driver updating on runtime). You may use it from VS2008 debugger, or create shell links by Phone Commander and run from it. Driver output is wrote to \DriverOut.txt file (readable simply by Phone Commander or any remote tool, do not forget clean it sometime). Needed registry file is included (is parsable by Phone commander if unicode, or by any other tool, or you can write keys and values manually). If somebody solves data copying problem after physical memory reading, write it here or send me PM. Without VS2008 you can use binaries for your own risc, native kernel operations are unsafe.

WRONG, see next note: News: I am not sure, but swscanf(largeNum, L"%llu", &lpPhysicalAddress) is probably wrong, when I want to read 64bit hexadecimal value, and SetDlgItemInt(IDC_STATICValue, dwValue), where dwValue is valid 32bit value returned from driver physical memory reading. Do you know anybody, what may be wrong in this case? Cannot be stack overwrited in DeviceIoControl calling time? Application breaks after this code and hangs up, when working under debugger, or crashes, when working outside debugger. But, it seems, this problem occures after returning from driver memory RW functions only.

Edit: I found very stupid error (diagnostics is difficult without debugging fully working). GetDlgItemText(IDC_EDITAddress,largeNum, sizeof (largeNum)) is wrong on Unicode system, must be GetDlgItemText(IDC_EDITAddress,largeNum, sizeof (largeNum) / sizeof (WCHAR)). My stack overwriting assumption was right, but I do not understand, why it occures, when a half of buffer is distinctly bigger then readed text. Even after correcting tracing reports to me senseless values ​​in some variables. But it is already testing application error, the driver appears to be working. You can use test appplication for reading 4-Bytes value from any physical address (it may be safe for all), or to unsafe write 4-Bytes value (may be 8-bit in unfinished version, I will repair writing part as soon as possible) to subset of secure physical address ranges (for experienced users only, you can try for example phone reboot by value writing, but there is also possible to activate hard/factory reset by a certain address and value!). Repaired source and binaries are attached. Driver also can directly work with IOCTL (based on Bruce Eitman CE6 source code). It is still not tested on WP7. Can be, this way allows to add second SIM card or SD card slot etc. to WP7 phones in future.

Important note: Added code and driver is kernel mode example only. It uses IO range mapping instead full physical memory addressing and access. It must be changed to VirtualAlloc, VirtualCopy and VirtualFree functions using. I will study more and publish, when it will finished.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

1. I urgently need a request from Haret designers for a specific feature. Is it needed, eg, the functions UART_setup (), UART_puts (char * s), UART_s3c24xx_map (void), uint8 *memPhysMap (uint32 paddr) and IOCTL functions, or something else? Uart.cpp, Memory.cpp and CPU-s3c24xx.cpp modules only? These simple functions would not be a problem to implement in the kernel driver with simple marshaling to HaRET application.

2. Where can I get IOCTL maps for WP7 devices (especially my HTC7Pro)?

3. Have got any WM/CE emulator low-level hardware specification to be usable for HaRET-kernel driver interaction testing (on device testing is difficult without full debugging working)?

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

I tried also simple callback called from kernel driver to calling application, but with no success, by any restriction or different address space (callback must be marshaled probably, but this is not good way by big security hole). Better way is calling another dll from (universal)driver, which will contain kernel mode HaRET parts and to address functions by name. Edit: User code injection to kernel driver is definitely possible. But, we must:

1. To fix injectable code in unbroken user space (solutable by compiler/linker directives),

2. To compute size of all fixed code parts (all functions etc.),

3. To realize all kernel functions (VirtualAlloc etc) by pointers call, the same for all injected own subroutines,

4. To map code to kernel space (needs to send addresses and sizes too in DeviceIoControl InputBuffer parameter),

5. To fill kernel and injected functions pointers and call injected entry function in kernel mode.

It is so much work. I mean reducing kernel mode needs in HaRET and calling little low-level parts transfered to driver (or kernel export dll called by very small driver) is easier way now.