[Windows Phone 7 Development and Hacking] Martin7Pro:
Soluted:

extern "C" int WP7RunInKernelMode(const wchar_t * szDllName, const wchar_t * szFunctionName, void * lpInStructurePointer, unsigned long nInStructureLength, void * lpOutStructurePointer, unsigned long nOutStructureLength, const wchar_t * szTraceOut, unsigned long nTraceOutLength);
#define RunInKernelMode(FunctionName, InStructurePointer, InStructureLength, OutStructurePointer, OutStructureLength, OutTrace, OutTraceLen) WP7RunInKernelMode(L"kmodedll.dll", FunctionName, InStructurePointer, InStructureLength, OutStructurePointer, OutStructureLength, OutTrace, OutTraceLen)

#define DEF_WP7GETCPR(Name, Cpr, Op1, CRn, CRm, Op2)	\
static inline uint32 Name (void) {	\
VOID_STRUCT vs = { };	\
uint32 MMU = 0;	\
wchar_t szTraceMsg[100];	\
int status = RunInKernelMode(L"K" #Name, (void * )&vs,	\
sizeof(vs), (void * )&MMU,	\
sizeof(MMU), szTraceMsg, sizeof(szTraceMsg) - 2);	\
Output(#Name " returned %i", status);	\
return MMU;	\
}

Now:

Output:

WP7RunInKernelMode(kmodedll.dll, KGetProcInfo, 0x3E2F248, 1, 0x3E2F274, 576, 0x3E2F180, 198)

DeviceIoControl returns 1

WP7RunInKernelMode(kmodedll.dll, Kget_p15r2, 0x3E2F6B8, 1, 0x3E2F6B4, 4, 0x3E2F5EC, 198)

DeviceIoControl returns 1

WP7RunInKernelMode(kmodedll.dll, Kget_p15r1, 0x3E2F6E4, 1, 0x3E2F6E0, 4, 0x3E2F5E8, 198)

DeviceIoControl returns 1

Error: 'Terminating haret due to unhandled exception (pc=03ce7894)'

haretlog.txt:

Detecting ram size

WinCE reports memory size 520093696 (phys=499146752 store=-1)

Mapping mmu table

get_p15r2 returned 1

Build L1 reverse map

get_p15r1 returned 1

Terminating haret due to unhandled exception (pc=03ce7894)

DriverOut.txt:

KMD_Open

KMD_Open

KMD_IoControl entry, dwCode=9

KMD_IoControl WP7_DLL_CALL, dwCode=9

Function kmodedll.dll::KGetProcInfo returns 0

KMD_IoControl returned 1

KMD_IoControl entry, dwCode=9

KMD_IoControl WP7_DLL_CALL, dwCode=9

Function kmodedll.dll::Kget_p15r2 returns 0

KMD_IoControl returned 1

KMD_IoControl entry, dwCode=6

KMD_IoControl IOCTL_WP7_ALLOC_ADDRESS, dwCode=6

Function VirtualAllocEx(0x42,0x0,16384,0x2000,0x1) returns D98A0000

KMD_IoControl returned 1

KMD_IoControl entry, dwCode=8

KMD_IoControl IOCTL_WP7_COPY_ADDRESS, dwCode=8

Function VirtualCopy(0xD98A0000,0x2A1C00,16384,0x604) returns 1

KMD_IoControl returned 1

KMD_IoControl entry, dwCode=9

KMD_IoControl WP7_DLL_CALL, dwCode=9

Function kmodedll.dll::Kget_p15r1 returns 0

KMD_IoControl returned 1

KMD_IoControl entry, dwCode=10303FF

KMD_IoControl default, errorneous dwCode=10303FF

KMD_IoControl returned 0

KMD_IoControl entry, dwCode=10303FF

KMD_IoControl default, errorneous dwCode=10303FF

KMD_IoControl returned 0

KMD_IoControl entry, dwCode=10303FF

KMD_IoControl default, errorneous dwCode=10303FF

KMD_IoControl returned 0

KMD_IoControl entry, dwCode=10303FF

KMD_IoControl default, errorneous dwCode=10303FF

KMD_IoControl returned 0

KMD_Close

KMD_Close

DllOut.txt:

KcpuGetMMU(0x2212614, 1, 0x2212830, 4)

cpuGetMMU() returns 0x17354000

KGetProcInfo(0x3E322E4, 1, 0x3E32500, 576)

pinfo filled, GetProcInfo returns ERROR_SUCCESS

wVersion = 1

szProcessCore = Snapdragon

wCoreRevision = 0

szProcessorName = QSD8250

wProcessorRevision = 0

szCatalogNumber =

szVendor = QUALCOMM

dwInstructionSet = 0

dwClockSpeed = 998

Kget_p15r2(0x3E32614, 1, 0x3E32830, 4)

get_p15r2() returns 0x2A1C0010

Kget_p15r1(0x3E32A14, 1, 0x3E32C30, 4)

get_p15r1() returns 0x11E5787D

HaRET crashes somewhere after get_p15r1() calling.

Edit: Crash is caused by unavailable MMUTable pointer in HaRET address space, reserved by WP7VirtualAlloc and allocaded/filled by WP7VirtualCopy. WP7VirtualAlloc is implemented in kernel driver as VirtualAllocEx wiht HaRET process Id as first parameter. I tried to use HaRET process handle too with the same wrong result. Do you know anybody, if it is a right way in CE6/CE Embdedded 7 system?

Can you anybody explain this HaRET code?

area = WP7VirtualAlloc(NULL, 4096*4, MEM_RESERVE, PAGE_NOACCESS);

When I chnge it to

area = WP7VirtualAlloc(NULL, 4096*4, MEM_COMMIT/*MEM_RESERVE*/, /*PAGE_NOACCESS*/PAGE_READWRITE);

then no crash is occured, but this is probably wrong idea.

Is not necessary to use VirtualCopyEx instead of VirtualCopy to use virtual pointer in HaRET adress space? Or is there better to use VirtualAllocCopyEx instead both?

Edit:

I tried it. Result is crash anyway.

KMD_IoControl entry, dwCode=6

KMD_IoControl IOCTL_WP7_ALLOC_ADDRESS, dwCode=6

Function VirtualAllocEx(0x18C403E6,0x0,16384,0x2000,0x1) returns 2920000

KMD_IoControl returned 1

KMD_IoControl entry, dwCode=8

KMD_IoControl IOCTL_WP7_COPY_ADDRESS, dwCode=8

Function VirtualCopyEx(0x18C403E6,0x42,0x2920000,0x17DF40,16384,0x604)

returns 0

KMD_IoControl returned 1

Is normal GetDirectCallerProcessId() returns so high number as 0x18C403E6?

I hope 0x42 returned by GetCurrentProcess() is OK.

I found this way in examples, but need not be it converted to HANDLE by OpenProcess?

But, when I do it, nothing is better, VirtualCopyEx allways returns FALSE.

May be, this article http://www.tech-archive.net/Archive...ndowsce.app.development/2010-01/msg00023.html is true and both (non-ex and ex too) function versions are needed to be used together. I will try it, but it means MSDN and CE API contain mistake. I do not believe it, probably little mistake is in our code or WP7 CE version contains any hidden kernel restrictions.

I tried VirtualAllocCopyEx instead VirtualAllocEx + VirtualCopyEx couple. Function returns address, but unreadable in calling process. Parameter is MMU physical pointer given from cpuGetMMU() function. This pointer seems to be wrong. Need it to be divided by page size (I tried both with no success)? Is possible this pointer is different in two repeated cpuGetMMU() calling (after application restart)? Really memory mapping structure changes its position? May not be problem in get_p15r2() & 0xffffc000; function (bitwise operation means rounding to memory page begin)? I will try to compare gotten values with HaRET 0.3.8 asm code version.

EDIT: VirtualAllocCopyEx is working now (problem was in parameters difference to VirtualCopyEx). Then, we can use VirtualAllocCopyEx instead VirtualAllocEx + VirtualCopyEx couple.

CCA 1/2 of HaRET system access code is working now!

But i tried to load Linux - too preliminary. Phone seems bricked. After battery removing this was restarted, but in two days old state (no newest files, no yesterday SMS, no yesterday calls etc.). It will very danger work to make Linux loading working.

Little note:

We can use oalioctl.dll user mode exports to implement safely a part of HaRET functionality. Standard CE oalioctl switch knows:

IOCTL_HAL_GET_CACHE_INFO

IOCTL_HAL_GET_DEVICE_INFO

IOCTL_HAL_GET_DEVICEID

IOCTL_HAL_GET_UUID

IOCTL_PROCESSOR_INFORMATION,

advantage is primarilly in OAL opposite to own implementation.

We can discovery other, undocumented oalioctl export, if exists. See https://sites.google.com/a/cevx.net...-quality-oal/production-quality-oal-reference pages. Some is available from user mode, most from kernel one. We can use some OEM provided API to retrieve a part of device information instead HaRET direct functions. Especially ceddk contains usefull functions in WP7 ROMs. http://msdn.microsoft.com/en-us/library/aa913117.aspx

spavlin: Can you share your extracted ceddk.dll? http://xdaforums.com/showpost.php?p=31890687