new approach on nk.bin modification

[mce2222]

when looking at the nk.bin I realized that the current firmware wastes a lot of RAM by storing large files in the NK.BIN as FileEntries.
for example all the dot net DLLs, the tv2client.exe and bootce.exe ... those combined are already about 6.5 MB.

so I think the best solution would be to create a new MIPS based minimalistic NK.BIN with the platform builder and add only the required DLLs to it.

The default search path should be extended, so that also some folders of the harddisk are searched. so we could place those 6.5 MB files on the harddrive.

the major advantage is of course that it is much easier to update the existing application when it is not in the NK.BIN.

this task needs some work, since the platform builder does not support modification of a generated NK.BIN
fortunately I found some tools from the PDA hacking community that will help us.

our NK.BIN is more or less the same as the XIP.BIN found in most PDAs. so I found that the XIPPORT.EXE is able to handle our NK.BIN.
XIPPORT allows dumping of XIP.BIN in a form, so that it can be recreated after modification (adding new DLLs, removing files and modules).
unfortunately an error occurrs during dumping of the NK.BIN (converted to NK.NB format)... so I couldnt test a full dump+recreation cycle

but still this looks very promising. the sources of the tool are available, so it shouldn't be too hard to figure out where the problem is.

let me know what you guys think about this.

[Hoernchen]

As far as i recall my problem was that there were no tools to recreate a compressed nk file from the modified nb0 file because most of the windows mobile devices use the nb0 file for flashing, the reason why they call the uncompressed nb0 file xip.bin is because it gets eXecuted In Place....

Interesting links:
dumprom
romtools
other tools for converting windows mobile image files

[mce2222]

I think the dumpromx tool is able to recompress the files...
but anyway there is no tool that will work 100% for our case.

I expect that the memory relocation is specific for ARM CPUs, so it would have to be redone for MIPS if we need to relocated files.

[is0-mick]

Would it not be possible to replace the TV2ClientCE.exe and the DLL's with files of 0 length, and then rename them?

Then have the runtime and exe on disk, this would save the need to rebuild the NK.BIN.

Mick

[mce2222]

with the FileEntries this is possible, however with the ModuleEntries it is a bit more tricky, since the Modules are a continous memory block of preloaded DLLs.
setting the length of a Module to 0 is possible, but it would just result in a memory gap that cannot be used. In theory this could be declared as additional RAM, but
the RAM areas are hardcoded in the nk.exe, so they wont be recognized dynamically.


I tried my approach on the minimalistic NK.BIN but it was not successful.
there are some problems:

the nk.exe contains some device specific pre-inits of the hardware, so we need to use an existing nk.exe from our NK.BINs.
but this is not so easy either, because that "3rd party component" approach that I found works fine with non-standard DLLs, but because the standard DLLs
are always created during the build process, so there is a conflict when a 3rd party component tries to overwrite these generated files.
if this happens, the build is canceled
as a workaround it should be possible to let the nk build process create a dummy nk.exe and replace it with a nk.exe from our NK.BIN
I havent tried that yet.

I also found out that the minimal NK.BIN contails just a nk.exe and a coredll.dll  ... so I suspect that one of these two could also be the cause of the strange
DLL and EXE search behaviour.

[is0-mick]

I was just trying something similar this morning.

I got quite a few duplicate filename warnings in platform builder and then
Pass 1...
Error: Failed reading o32 data in module coredll.dll
Fatal error hit, exiting...

I also was thinking about if we what would happen if we replaced the NK.exe or Core.DLL etc with versions from a previous build?
It then may be possible to figure out the cause of the odd behaviour.

Mick

[mce2222]

yes that was also what I wanted to do, but that is not so simple, because the size of the nk.exe is different... the coredll.dll is same size if I remember correctly.

if the older nk.exe is smaller, then it should be easy to do.

[is0-mick]

For some reason it does not look like it is possible to replace nk.exe .......
I tried with a different file, just to double check and that worked OK.

C:\Documents and Settings\mick\Desktop\PKG-270608>binmod -i NK.BIN -r nk.exe
BinMod V1.0 built Apr  5 2006 11:32:47

Checking record #78 for potential TOC (ROMOFFSET = 0x00000000)
Found pTOC  = 0x92db4c6c
rom offset = 0x00000000
Error: File not found in image
Error: Replacement failed!

Mick

[is0-mick]

I think I may have found something.

If I run tv2tasman.exe from \harddisk\tv2client\ folder using the web interface it works fine.
If i rename tv2tasman.exe to a different name I get the error, rename it back it works again.

Changing one byte of the file, results in the file not running...
Signature? or something?

Anyways I did some more digging and found this.. which is quite interesting.
http://www.windowsfordevices.com/articles/AT6765599475.html

Before the kernel loads an application, the OEMCertifyModule function verifies the application signature to help protect your system from unfamiliar applications. This ensures that the Windows CE based platform loads an application only if it contains a valid digital signature. The following table further describes the functions.

This part sounds like our problem

The simplest implementation of the trusted model uses the OEMCertifyModule function to return OEM_CERTIFY_RUN for all applications. This allows applications that are not part of the ROM MODULES section of the image to run, but they are restricted from making privileged function calls. By using the OEMCertifyModule implementation at run time, you do not have to specify which applications are trusted. If OEM_CERTIFY_FALSE is returned, applications in RAM will not be able to run. Regardless of which implementation of the trusted model you choose, OEMCertifyModuleInit or OEMCertifyModule, the operating system files in the ROM MODULES section of the image will always run with full privileges.

Mick

[mce2222]

about the nk.exe replacement... binmod.exe does only work on FileEntries... but nk.exe is a module, so the only way would be to modify the nk.bin manually with a hexeditor, or to write a tool to do that.
actually, I was thinking about writing a NK.BIN editor that allows adding, deleting, modifying any file or module... that would be really useful, but would also take some time to implement


I find it strange that it does not work when renamed. the filename should not be part of the regular signature, but of course they could have implemented a non standard signature.

but anyway I guess it should not be too hard to patch that OEMCertifyModule function

[is0-mick]

I can't seem to find any mention of that function in the nk.exe but something I did notice is when I use remote process viewer, filesys.exe seems to be using certmod.dll which has the following text in it.


C e r t M o d :   V e r i f y S i g n a t u r e :   F a i l e d   f o r   % s .   ( f i l e   h a s h   i s   i n c o r r e c t )

   C e r t M o d :   V e r i f y S i g n a t u r e :   S i z e   c o u l d   n o t   b e   v e r i f i e d   f o r   f i l e   % s .

may be they are using that?
That dll does not appear to be in the debug image.

[is0-mick]

OK, I put certmod into IDA, it looks straight forward to fix it...

                                                               
.text:03081034 00000018 unicode \\Hard Disk\\                                                         
.text:0308104C 0000007A unicode CertMod: VerifySignature: Error while reading the file %s.\r\n       
.text:030810C8 00000088 unicode CertMod: VerifySignature: Failed for %s. (file hash is incorrect)\r\n
.text:03081150 00000088 unicode CertMod: VerifySignature: Size could not be verified for file %s.\r\n
                                                         
.text:03081B14                 beqz    $v0, loc_3081B40 <--- change to branch always
.text:03081B18                 nop
.text:03081B1C                 lui     $v0, 0x308
.text:03081B20                 lw      $a1, 4($s6)
.text:03081B24                 jal     NKDbgPrintfW
.text:03081B28                 addiu   $a0, $v0, 0x10C8 ; VerifySignature: Failed for %s. (file hash is incorrect)\r\n
.text:03081B2C                 b       loc_3081B4C
.text:03081B30                 nop


also found some info on the file here: http://www.eggheadcafe.com/software/aspnet/29384155/certmod-how-to.aspx

The problem now, it seems it is a module, and binmod won't replace it

[mce2222]

damn... I didnt refresh this topic
but I found out the same thing.

here is the full documentation
http://msdn.microsoft.com/en-us/library/aa909421.aspx

the file does not need to be replaced... we can simply patch it in the nk.bin ... well the nk.nb0 to be precise.
so .. convert nk.bin to nk.nb0 .. patch ... and convert nk.nb0 to nk.bin .. thats it

actually the certmod.dll does the same thing as the booterce.exe, but it only checks .dll .exe files against the boot.sig hashes.
so thats why it does not accept any file that is not in the boot.sig file.

funny thing is that .exe files are executed when they are places in the /windows folder... it seems the filesys.exe consideres everything in /windows folder to be ROM    ... sounds like a serious security flaw.

I will look into patching the certmod.dll in the next hour.

[is0-mick]

hehe,
I was just looking at the same thing.
I tried converting to the nb0 as well, but could not find the same hex in the nb0 as what I did in the DLL?

[mce2222]

that is because it is stored as a module... so it is compiled for a fixed memory location.
thats why the memory pointers are different to those in the dll