HDD GURU FORUMS http://forum.hddguru.com/ |
|
Help needed - Serious challange with this one http://forum.hddguru.com/viewtopic.php?f=10&t=31151 |
Page 6 of 7 |
Author: | joanorsky [ May 26th, 2015, 9:39 ] |
Post subject: | Re: Help needed - Serious challange with this one |
Yes... the FTL translation is not completely right... here are some parts of the above files but on the wceusr.reg (from the sean's dump). This makes me believe that some pages are miss aligned.. http://www.joaocesarsilva.com/echo/wceusr_dump.rar |
Author: | HaQue [ May 26th, 2015, 10:09 ] |
Post subject: | Re: Help needed - Serious challange with this one |
yes it goes pear-shaped at 0x800. interesting. I recreated what Sean did at my end, and I noticed a block conflict, though each choice didn't seem to look any better than each other, so I think this doesn't matter. This could mean a couple of things.. the data on the chip is corrupted, ECC comes into play, there are some blocks/pages on the chip that were updated or GetDataBack didn't carve quite well enough. I used R-Studio and the file "MSGALARM.MSG" is exactly the same as your "MSGALARM_original.MSG" GDB nk.bin is also different than R-Studio's result, I think R-Studios looks ok. "LOADCEPC.EXE" , the .ini file R.BAT are identical. Attachment: As an excersise, I may load this up in VNR and see what the FTL looks like. I think it is more GDB issue, and Seans disk image is fine. |
Author: | joanorsky [ May 26th, 2015, 10:12 ] |
Post subject: | Re: Help needed - Serious challange with this one |
I have a few original files as well.. i will give it a check now. |
Author: | joanorsky [ May 26th, 2015, 10:23 ] | ||
Post subject: | Re: Help needed - Serious challange with this one | ||
Yes.. your files seem not to have the errors Sean files had. The directory structure is "all over the fence" though (but this can be easily reconstructed by file analysis, if not by anything else).. but.. this makes me assume that either your software has ECC correction and it was used on the assembly of these files or that there is something wrong with the File Translation used by Sean. Some files also have missing the first name letter.. but these are probably deleted files that the structure remained on the nand.. i guess.. (correct me if i am wrong) By the way.. the file structure should be something like this image.. (although i am still not quite clear on what the "A99" name is)
|
Author: | HaQue [ May 26th, 2015, 10:55 ] |
Post subject: | Re: Help needed - Serious challange with this one |
To be clear, these are not my files, this is simply running R-Studio on Seans disk Image. There is NO ECC involved. Seans File Translation is fine, more a GetDataBack issue. [A99] is probably a named placeholder for a folder that GDB couldn't properly name. The byte at the start in the image is not regular ascii (0xE5). Quote: to allow undeleting files that were deleted by mistake, the DEL command will replace the first byte of the name by 0xe5 to signify "deleted". http://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html
|
Author: | joanorsky [ May 26th, 2015, 11:20 ] |
Post subject: | Re: Help needed - Serious challange with this one |
HaQue wrote: [A99] is probably a named placeholder for a folder that GDB couldn't properly name. Yes.. i understood that, my English is not that good.. i must have expressed myself badly. That was not my meaning... i was just saying that i figured what all directory names were expect the one marked by "A99".. all the others (that were also with improper names) i could figure them out and named them correctly. I was also saying that there might have been some problems on the FTL translation assembly procedure with Sean's files, because although the initial code on each file was ok.. there were errors within that on your files (or R-Studio's) did not, as if there were misplaced pages (which i confirmed by looking at the posted files). So.. i suspect that there was in fact some sort of chain assembly error on GDB. I have assembled a image to inject on the DOC using both recoveries. I will try them out in a few hours and get back with some feedback.. Thanks for all the help and attention provided.. i much appreciate it! |
Author: | HaQue [ May 26th, 2015, 11:53 ] |
Post subject: | Re: Help needed - Serious challange with this one |
Good Luck - The best outcome will be a new Jumper for Sean.. gets cold in the UK I believe |
Author: | fzabkar [ May 26th, 2015, 15:19 ] |
Post subject: | Re: Help needed - Serious challange with this one |
HaQue wrote: GDB nk.bin is also different than R-Studio's result, I think R-Studios looks ok DMDE recovers the same NK.BIN as R-Studio. I have also carved it out by hand by referring to its directory entry and then walking through the FAT. Cluster 0x1EA is located at offset 0xFE400.
The file is contiguous and ends at offset 0x583BFF. My manual result matches DMDE's and R-Studio's. |
Author: | fzabkar [ May 26th, 2015, 15:44 ] |
Post subject: | Re: Help needed - Serious challange with this one |
fzabkar wrote: HaQue wrote: GDB nk.bin is also different than R-Studio's result, I think R-Studios looks ok DMDE recovers the same NK.BIN as R-Studio. I have also carved it out by hand by referring to its directory entry and then walking through the FAT. Cluster 0x1EA is located at offset 0xFE400.
The file is contiguous and ends at offset 0x583BFF. My manual result matches DMDE's and R-Studio's. On closer examination there appears to be an anomaly in one of the recovered files. GDB NK.BIN Code: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00457FC0 01 DF 63 2E 1E 35 35 64 7D FE F5 17 29 01 FC 02 .ßc..55d}þõ.).ü. 00457FD0 FC 75 8D 25 41 71 01 E6 6B 27 1F 26 26 17 25 75 üu.%Aq.æk'.&&.%u 00457FE0 FD 92 0E 6A 51 C0 01 FF FF 00 1B FF E4 03 29 03 ý’.jQÀ.ÿÿ..ÿä.). 00457FF0 AF 01 53 02 7D 03 6F 00 00 C0 00 40 00 00 0F B7 ¯.S.}.o..À.@...· 00458000 CC AE 28 75 51 FF 90 85 01 44 C2 47 B2 01 9F 99 Ì®(uQÿ.….DÂG².Ÿ™ 00458010 87 C3 39 B1 C9 89 FF 01 01 5B B3 80 8B 6C 01 01 ‡Ã9±É‰ÿ..[³€‹l.. 00458020 01 01 FF 01 01 01 01 01 01 01 01 FF 01 01 01 01 ..ÿ........ÿ.... 00458030 01 01 01 01 FF 01 01 01 01 01 60 BE 0B B0 AE 00 ....ÿ.....`¾.°®. 00458040 56 C4 FF A6 C1 F7 D3 9B AF 01 01 01 4E C4 14 D8 VÄÿ¦Á÷Ó›¯...NÄ.Ø 00458050 FF 3B D5 16 D8 01 0B D7 01 01 01 01 FF 01 01 01 ÿ;Õ.Ø..×....ÿ... 00458060 01 01 01 01 01 FF 01 01 01 01 01 01 01 01 FF 01 .....ÿ........ÿ. 00458070 01 01 01 01 01 01 01 FF 01 01 01 01 01 01 01 01 .......ÿ........ 00458080 FF 01 01 01 01 01 01 01 01 FF 01 01 01 01 01 01 ÿ........ÿ...... 00458090 01 01 FF 01 01 01 01 01 01 01 01 FF 01 01 01 01 ..ÿ........ÿ.... 004580A0 01 01 01 01 FF 01 01 01 01 01 01 01 01 FF 01 01 ....ÿ........ÿ.. R-Studio / DMDE NK.BIN Code: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00457FD0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00457FE0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00457FF0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00458000 2E 20 20 20 20 20 20 20 20 20 20 10 00 00 00 00 . ..... 00458010 00 00 00 00 00 00 19 5D 4E 2E 9A 0A 00 00 00 00 .......]N.š..... 00458020 2E 2E 20 20 20 20 20 20 20 20 20 10 00 00 00 00 .. ..... 00458030 00 00 00 00 00 00 19 5D 4E 2E 99 0A 00 00 00 00 .......]N.™..... 00458040 E5 52 4F 56 41 53 55 20 4D 47 4C 20 00 00 00 00 åROVASU MGL .... 00458050 00 00 00 00 00 00 77 86 5A 2B 9B 0A A2 02 00 00 ......w†Z+›.¢... 00458060 50 52 4F 56 41 53 55 20 50 47 4C 20 00 00 00 00 PROVASU PGL .... 00458070 00 00 00 00 00 00 6E 81 56 2B 9C 0A 5B 43 00 00 ......n.V+œ.[C.. 00458080 50 52 4F 56 41 41 4C 4C 43 47 4C 20 00 00 00 00 PROVAALLCGL .... 00458090 00 00 00 00 00 00 9A 5C 94 2B A5 0A 76 14 00 00 ......š\”+¥.v... 004580A0 50 52 4F 56 41 41 4C 4C 4D 47 4C 20 00 00 00 00 PROVAALLMGL .... 004580B0 00 00 00 00 00 00 99 5C 94 2B A8 0A FE 03 00 00 ......™\”+¨.þ... 004580C0 50 52 4F 56 41 53 55 20 43 47 4C 20 00 00 00 00 PROVASU CGL .... 004580D0 00 00 00 00 00 00 77 86 5A 2B A9 0A 52 15 00 00 ......w†Z+©.R... 004580E0 50 52 4F 56 41 41 4C 4C 50 47 4C 20 00 00 00 00 PROVAALLPGL .... 004580F0 00 00 00 00 00 00 85 5D 2B 2C AC 0A 5B 43 00 00 ......…]+,¬.[C.. 00458100 50 52 4F 56 41 32 20 20 4D 47 4C 20 00 00 00 00 PROVA2 MGL .... 00458110 00 00 00 00 00 00 06 86 39 2B B5 0A 0B 03 00 00 .......†9+µ..... 00458120 50 52 4F 56 41 32 20 20 50 47 4C 20 00 00 00 00 PROVA2 PGL .... 00458130 00 00 00 00 00 00 C5 84 39 2B B6 0A 5B 43 00 00 ......Å„9+¶.[C.. 00458140 50 52 4F 56 41 32 20 20 43 47 4C 20 00 00 00 00 PROVA2 CGL .... 00458150 00 00 00 00 00 00 06 86 39 2B BF 0A 9E 15 00 00 .......†9+¿.ž... 00458160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00458170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ The latter dump contains a directory structure. Surely that can't be right? |
Author: | fzabkar [ May 26th, 2015, 16:41 ] |
Post subject: | Re: Help needed - Serious challange with this one |
Here is a directory remnant (?) that appears to have been crosslinked with the NK.BIN file. Code: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00457800 2E 20 20 20 20 20 20 20 20 20 20 10 00 00 00 00 . ..... 00457810 00 00 00 00 00 00 19 5D 4E 2E 99 0A 00 00 00 00 .......]N.™..... 00457820 2E 2E 20 20 20 20 20 20 20 20 20 10 00 00 00 00 .. ..... 00457830 00 00 00 00 00 00 19 5D 4E 2E 00 00 00 00 00 00 .......]N....... 00457840 50 52 4F 47 52 41 4D 20 20 20 20 10 00 00 00 00 PROGRAM ..... 00457850 00 00 00 00 00 00 19 5D 4E 2E 9A 0A 00 00 00 00 .......]N.š..... The PROGRAM directory occupies cluster 0x0A9A. Its parent directory occupies cluster 0x0A99. Clusters 0x0A99 and 0x0A9A in the FAT are assigned to NK.BIN. Code: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00001B20 91 0A 92 0A 93 0A 94 0A 95 0A 96 0A 97 0A 98 0A 00001B30 99 0A 9A 0A 9B 0A 9C 0A 9D 0A 9E 0A 9F 0A A0 0A 00001B40 A1 0A A2 0A A3 0A A4 0A A5 0A A6 0A A7 0A A8 0A Offsets within Disk.image
((0xA9A - 2) x 0x800) + 0xA400 = 0x556400 ISTM that this explains the mysterious [A99] folder reported by GDB. BTW, why does GDB identify the file system as FAT12? |
Author: | fzabkar [ May 26th, 2015, 18:26 ] |
Post subject: | Re: Help needed - Serious challange with this one |
I suspect that the [A99] directory could be CESTORE. Code: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 000FDC10 73 72 2E 72 65 67 0D 0A 5C 61 70 70 6C 5C 77 69 sr.reg..\appl\wi 000FDC20 6E 63 65 5C 77 63 65 73 79 73 2E 72 65 67 0D 0A nce\wcesys.reg.. 000FDC30 1A 00 00 00 00 00 AE 5C 4D 2C 00 00 00 00 00 00 ......®\M,...... 000FDC40 E5 4F 4D 4D 41 4E 44 20 43 4F 4D 20 00 00 00 00 åOMMAND COM .... 000FDC50 00 00 00 00 00 00 C0 22 BF 1C 13 0B 75 D5 00 00 ......À"¿...uÕ.. 000FDC60 E5 59 53 20 20 20 20 20 43 4F 4D 20 00 00 00 00 åYS COM .... 000FDC70 00 00 00 00 00 00 C0 2A BF 1C E2 05 D8 24 00 00 ......À*¿.â.Ø$.. 000FDC80 43 4F 4E 46 49 47 20 20 53 59 53 20 00 00 00 00 CONFIG SYS .... 000FDC90 00 00 00 00 00 00 4C 52 8A 2B 2E 0B E7 00 00 00 ......LRŠ+..ç... 000FDCA0 41 55 54 4F 45 58 45 43 42 41 54 20 00 00 00 00 AUTOEXECBAT .... 000FDCB0 00 00 00 00 00 00 26 52 8A 2B 12 0B F1 00 00 00 ......&RŠ+..ñ... 000FDCC0 41 50 50 4C 20 20 20 20 20 20 20 10 00 00 00 00 APPL ..... 000FDCD0 00 00 00 00 00 00 B9 5C 4D 2C E9 05 00 00 00 00 ......¹\M,é..... 000FDCE0 E5 45 54 20 20 20 20 20 20 20 20 10 00 00 00 00 åET ..... 000FDCF0 00 00 00 00 00 00 44 5D 4D 2C B4 3A 00 00 00 00 ......D]M,´:.... 000FDD00 44 4F 53 20 20 20 20 20 20 20 20 10 00 00 00 00 DOS ..... 000FDD10 00 00 00 00 00 00 FD 75 54 2C 67 34 00 00 00 00 ......ýuT,g4.... 000FDD20 E5 54 49 4C 20 20 20 20 20 20 20 10 00 00 00 00 åTIL ..... 000FDD30 00 00 00 00 00 00 C1 5C 4D 2C F7 20 00 00 00 00 ......Á\M,÷ .... 000FDD40 57 49 4E 43 45 20 20 20 20 20 20 10 00 00 00 00 WINCE ..... 000FDD50 00 00 00 00 00 00 C2 5C 4D 2C CF 21 00 00 00 00 ......Â\M,Ï!.... 000FDD60 E5 45 54 20 20 20 20 20 20 20 20 10 00 00 00 00 åET ..... 000FDD70 00 00 00 00 00 00 CD 5C 4D 2C 0D 34 00 00 00 00 ......Í\M,.4.... 000FDD80 E5 4D 44 20 20 20 20 20 20 20 20 10 00 00 00 00 åMD ..... 000FDD90 00 00 00 00 00 00 D1 5C 4D 2C 34 37 00 00 00 00 ......Ñ\M,47.... 000FDDA0 E5 49 4F 53 20 20 20 20 20 20 20 10 00 00 00 00 åIOS ..... 000FDDB0 00 00 00 00 00 00 D1 5C 4D 2C 37 37 00 00 00 00 ......Ñ\M,77.... 000FDDC0 43 45 53 54 4F 52 45 20 20 20 20 10 00 00 00 00 CESTORE ..... 000FDDD0 00 00 00 00 00 00 D4 5C 4D 2C E8 39 00 00 00 00 ......Ô\M,è9.... 000FDDE0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000FDDF0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Code: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00AF0400 00 00 00 00 00 00 00 00 98 0D AA 55 00 00 5C 46 ........˜.ªU..\F 00AF0410 6C 61 73 68 20 44 69 73 6B 5C 43 45 53 54 4F 52 lash Disk\CESTOR 00AF0420 45 5C 50 52 4F 47 52 41 4D 5C 53 41 50 41 54 4F E\PROGRAM\SAPATO 00AF0430 33 37 00 4D 47 4C 00 00 00 00 00 00 00 00 00 00 37.MGL.......... |
Author: | joanorsky [ May 27th, 2015, 5:27 ] |
Post subject: | Re: Help needed - Serious challange with this one |
fzabkar wrote: I suspect that the [A99] directory could be CESTORE. You are correct... Nice spotting.. I have tested the recoveries and the nk.bin (from RSoft) seems ok (it does require specific hardware in order to run ok). Although the DOS files are almost all corrupted i have been able to recover those from a clean DOS image. This might be one of the problems on the original machine's software and not due to file's chain assembly on the dump. The mainboard also seems to have some hardware failures which will be solved now... But i think, since the nk.bin is running ok (or so it seems), that further carving procedures should be stoped by now. I will report further advances on the next few days.. Thank you all for helping on this.. |
Author: | fzabkar [ May 27th, 2015, 15:08 ] |
Post subject: | Re: Help needed - Serious challange with this one |
I would test the integrity of NK.BIN by extracting its individual files with a tool such as binmod.exe or viewbin.exe. I haven't followed this up in detail, but here are the results of a quick search: http://webcache.googleusercontent.com/s ... Iz5QrwwM2M http://web.archive.org/web/201308241851 ... d.exe.aspx https://msdn.microsoft.com/en-us/library/ms937378.aspx |
Author: | fzabkar [ May 27th, 2015, 16:31 ] | ||
Post subject: | Re: Help needed - Serious challange with this one | ||
Attached are the results of an examination of NK.BIN with Microsoft's viewbin.exe.
|
Author: | fzabkar [ May 27th, 2015, 17:34 ] | ||
Post subject: | Re: Help needed - Serious challange with this one | ||
Attached are the extracted files from NK.BIN. I used the information in the following thread: http://forum.xda-developers.com/showthr ... ?t=2078325 Some relevant resources ... http://download913.mediafire.com/qp9ql9 ... ntools.zip http://www.mediafire.com/download.php?qacdz4prtq9omol http://forum.xda-developers.com/attachm ... 1357195084 BTW, I didn't change the machine type, so the PE files have been dumped as MIPS R4000.
|
Author: | jermy [ May 27th, 2015, 17:41 ] |
Post subject: | Re: Help needed - Serious challange with this one |
wow fzabkar amazing work |
Author: | fzabkar [ May 27th, 2015, 18:50 ] |
Post subject: | Re: Help needed - Serious challange with this one |
The TIMES.TTF file within NK.BIN is corrupt. It's a font definition file, so that's probably why it wasn't noticed. Code: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
000224F0 40 0E 05 09 05 2E 20 20 20 20 20 20 20 20 20 20 @..... 00022500 10 00 00 00 00 00 00 00 00 00 00 19 5D 4E 2E 99 ............]N.™ 00022510 0A 00 00 00 00 2E 2E 20 20 20 20 20 20 20 20 20 ....... 00022520 10 00 00 00 00 00 00 00 00 00 00 19 5D 4E 2E 00 ............]N.. 00022530 00 00 00 00 00 50 52 4F 47 52 41 4D 20 20 20 20 .....PROGRAM 00022540 10 00 00 00 00 00 00 00 00 00 00 19 5D 4E 2E 9A ............]N.š 00022550 0A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00022CF0 00 00 00 00 00 2E 20 20 20 20 20 20 20 20 20 20 ...... 00022D00 10 00 00 00 00 00 00 00 00 00 00 19 5D 4E 2E 9A ............]N.š 00022D10 0A 00 00 00 00 2E 2E 20 20 20 20 20 20 20 20 20 ....... 00022D20 10 00 00 00 00 00 00 00 00 00 00 19 5D 4E 2E 99 ............]N.™ 00022D30 0A 00 00 00 00 E5 52 4F 56 41 53 55 20 4D 47 4C .....åROVASU MGL 00022D40 20 00 00 00 00 00 00 00 00 00 00 77 86 5A 2B 9B ..........w†Z+› 00022D50 0A A2 02 00 00 50 52 4F 56 41 53 55 20 50 47 4C .¢...PROVASU PGL 00022D60 20 00 00 00 00 00 00 00 00 00 00 6E 81 56 2B 9C ..........n.V+œ 00022D70 0A 5B 43 00 00 50 52 4F 56 41 41 4C 4C 43 47 4C .[C..PROVAALLCGL 00022D80 20 00 00 00 00 00 00 00 00 00 00 9A 5C 94 2B A5 ..........š\”+¥ 00022D90 0A 76 14 00 00 50 52 4F 56 41 41 4C 4C 4D 47 4C .v...PROVAALLMGL 00022DA0 20 00 00 00 00 00 00 00 00 00 00 99 5C 94 2B A8 ..........™\”+¨ 00022DB0 0A FE 03 00 00 50 52 4F 56 41 53 55 20 43 47 4C .þ...PROVASU CGL 00022DC0 20 00 00 00 00 00 00 00 00 00 00 77 86 5A 2B A9 ..........w†Z+© 00022DD0 0A 52 15 00 00 50 52 4F 56 41 41 4C 4C 50 47 4C .R...PROVAALLPGL 00022DE0 20 00 00 00 00 00 00 00 00 00 00 85 5D 2B 2C AC ..........…]+,¬ 00022DF0 0A 5B 43 00 00 50 52 4F 56 41 32 20 20 4D 47 4C .[C..PROVA2 MGL 00022E00 20 00 00 00 00 00 00 00 00 00 00 06 86 39 2B B5 ...........†9+µ 00022E10 0A 0B 03 00 00 50 52 4F 56 41 32 20 20 50 47 4C .....PROVA2 PGL 00022E20 20 00 00 00 00 00 00 00 00 00 00 C5 84 39 2B B6 ..........Å„9+¶ 00022E30 0A 5B 43 00 00 50 52 4F 56 41 32 20 20 43 47 4C .[C..PROVA2 CGL 00022E40 20 00 00 00 00 00 00 00 00 00 00 06 86 39 2B BF ...........†9+¿ 00022E50 0A 9E 15 00 00 00 00 00 00 00 00 00 00 00 00 00 .ž.............. 00022E60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
Author: | fzabkar [ May 28th, 2015, 4:30 ] | ||
Post subject: | Re: Help needed - Serious challange with this one | ||
I have refined the procedure for extracting the WinCE components. I was using the wrong decompression method (wince4.x) when I should have been using wince3.x. Code: Usage: dumprom [options] imagefile [offset [imagefile offset ...]] -d <dirpath> - save found files/modules to this path -v - verbose : print alignment, struct contents -q - quiet : don't print anything -n - don't use negative rva fix -u <ofs>L<len>:desc - add user defined memory regions to complete image -x <offset> - process XIP chain at offset -i <offset> - specifiy image start offset -3 - use wince3.x decompression -4 - use wince4.x decompression [ default ] -5 - use wince4.x decompress, and e32rom for wm2005 Execute viewbin.exe to determine the start and length of the ROM image, and the CPU type.
Code: ViewBin... \downloads\Knit_Machine\root\nk.bin Image Start = 0x00200000, length = 0x004C2B7C <------------- Start address = 0x00204990 Checking record #142 for potential TOC (ROMOFFSET = 0x80000000) Found pTOC = 0x806c1eec ROMOFFSET = 0x80000000 ROMHDR ---------------------------------------- DLL First : 0x01A70000 DLL Last : 0x02000000 Physical First : 0x80200000 Physical Last : 0x806C2B7C RAM Start : 0x806C3000 RAM Free : 0x806E8000 RAM End : 0x81000000 Kernel flags : 0x00000000 Prof Symbol Offset : 0x00000000 Num Copy Entries : 1 Copy Entries Offset : 0x806C2B6C Num Modules : 86 Num Files : 13 MiscFlags : 0x00000000 CPU : 0x014c (x86) <------------- Extensions : 0x802026E0 Use a hex editor to change the CPU type in dumprom.exe from MIPS R4000 (66 01) to x86 (4C 01) and rename the file to dumprom_x86.exe.
Then execute the following commands: Code: cvrtbin -r -a 0x00200000 -w 32 -l 0x004C2B7C nk.bin md dumpwce3 dumprom_x86 -d dumpwce3 -v -3 nk.nb0 > dumprom_wce3.log The contents of NK.BIN will be extracted/decompressed to the dumpwce3 directory and the results will be logged in dumprom_wce3.log. Attachment: WinCeDin.gif [ 4.27 KiB | Viewed 14205 times ]
|
Author: | fzabkar [ May 28th, 2015, 16:37 ] | ||
Post subject: | Re: Help needed - Serious challange with this one | ||
I found a copy of TIMES.TTF in the following archive: http://www.software.rockwell.com/downlo ... 20card.zip I patched it into the damaged NK.BIN file from offset 0x43530B to 0x463C82. I then repeated the extraction pocedure and confirmed that the extracted file contents were identical to the replacement TTF file. I also confirmed that the next file in NK.BIN (WinCeDin.BMP) was extracted correctly.
|
Author: | joanorsky [ May 29th, 2015, 5:07 ] |
Post subject: | Re: Help needed - Serious challange with this one |
I am impressed... Although i have used the dumprom before i never have realized that there was a offset to x86 cpu type.. That was why it failed on my extractions.. Newbie mistake i guess.. Excellent analysis fzabkar... Top forensics i see. |
Page 6 of 7 | All times are UTC - 5 hours [ DST ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |