Sunday 31 October 2010

Almost everything about Wayteq 770 GPS navigator

I. Overview

- Processor Centrality Atlas III ARM 926T-400* MHz
- TFT 480x272 (very good)
- 2 GB internal Flash drive, RAM 64 MB
- Windows CE 5.00 (Build 1400) with SDHC support
- Ability to switch between ActiveSync(default) and Mass Storage
*In reality 324MHz; the specs from the factory are 396MHz, but never heard of any device equipped with this processor to go above 324MHz.


II. The good stuff

Given that the device supports SDHC, the first thing was to search the registry (remote, with CeRegEditor). It seemed normal to find "\Drivers\BuiltIn\SDBusDriver" and "Drivers\SDCARD" with everything beneath them. The surprise was that in the "\Windows" folder there is no "SDBus.dll" nor "SDMemory.dll", therefore the SDHC issue was solved without using these "classic" drivers. I've found "\Drivers\SDMMC" and the associated DLL, 34KB, almost double from the one present in .Net 4.2 and earlier CE5, who were without SDHC support.



Another strange thing was this key: "\Drivers\BuiltIn\NewFlashDrive". We find a structure extremely strange when defining system files: the key MYFATFS! In the partition table it has a new name: 41 (in hex) and all the hints were leading to a hidden FAT partition. I've changed the keys that were makeing it hidden, but nothing. Then I realized that the flash disk is mounted during the boot process using the copy of the registry located in ROM (Boot.hv), so any setting in the registry is no longer taken into account. And yet it is possible to make it visible using a trick: set "MountHidden = DW:0" everywhere where "MYFATFS" appears (defined as "ResidentFlash2"), then go to "Control Panel" -> "Storage Manager" and select "Properties" for "Partition 01", then "Dismount" followed by "Mount". This time it has to read the registry, to the extent that we see a new folder called "ResidentFlash2". Well, here you can find all the programs and DLL's that are used by YFLoader.exe (the main menu). Even more, though YFLoader.exe is part of the ROM, it has the "file" attribute and you can copy it, the same with all DLL's associated with the .NET Framework 2.0 (implemented by the manufacturer) as well as a number of other files from "\Windows".

And now:

The "Flash Disk" has 4 partition: P00 - 25MB, P01 - 50MB, P02 - user and P03 - hive. Liiting the size, a ROM could fit into 25 MB, but what is with partition 1? We know already that it has a FAT partition in it, but the files in there are 14.2MB in total, so it remains about 35MB unused. It resembles the dimensions of a ROM.

The next step was to physically copy the 2 partitions to be able to see what's in them. It's clear that one of them must contain the ROM, but then what's in the other? The copies were all done through an ActiveSync connection, using "pdocread" from itsme's website (http://www.xs4all.nl/~itsme/projects/xda/tools.html).

We check with an hexeditor if partition 0 contains a ROM header and we find that it is present.

(Paranthesis)

Use the hexeditor and do a search in the binary image for the sequence (in hex) "FE 03 00 EA" and check if at offset "0x40" you have the ascii string "ECEC". If both elements are present, clearly we have to do with a ROM entry.

For other devices, if you want to experiment with them:
It can happen that you will not find that sequence in some ROM images. In this case look for the first occurence of "ECEC" and check if it represents or not a valid ROM entry. First, if the first character of the "ECEC" string it's not found at an address multiple of 4, look for for the next occurence.
Verification: the first 4 bytes after "ECEC" represents the virtual address (little endian) where the image will load and should be in the form of "xx xx xx 8x". The reason is that the virtual address at which the ROM is loaded must be >= with 0x80000000; it is important to be >8x. The next 4 bytes (little endian) represents the offset of the physical address where the ROM header begins. It must be a reasonable address, i.e. on one hand, the address to be inside a 32MB space limit and on the other hand to be inside the binary image. Don't forget that a ROM can contain multiple images, each of them starting with "ECEC" and that sequence must be found at an address multiple of 4.
The sequence "FE 03 00 EA" represents an unconditional jump to offset 0x1000 in regards to the first byte (FE). Being little-endian, the statement looks actually this: "EA 00 03 FE":
-bits 31-28: condition (in our case 0xE,1110) = unconditional jump;
-bits 27-25: opcode (in our case 101) = jump;
-bit 24: what kind of jump (0 = simple, 1 = with return to address from R14); for us is 0, so the next 4 bits have the value 0xA = simple jump without return
-bit 23: sign
-bits 22-0: the offset where jump is to be executed; before execution, bit 23 (if present) passes into the carry and bits 22-0 are shifted to the left with 2 positions (the equivalent of multiplying by 4) and the result is added o PC; this system allows jumping ahead or back into a domain of +-32MB

** Note to calculate address ** The ARM processor has a pipe-line of 3 instructions, which means that at the time of execution of the actual PC was increased by 8 (2 instructions). In such conditions, the jump will be at offset (0x3FE) * 4 + 8 = 0x1000

(close parenthesis)

Dumprom (also from itsme) finds in partition 0 one valid image (the kernel), and it also finds another valid entry but which exceeds the size of the partition P00. Same dumprom finds in partition P01 a second image, and that's why you have in your current working directory all the files from "\windows". More briefly: partition 0 contains only the kernel and partition 1 contains the entire ROM. Looking through partition 0, we find that at 0x20000 address begins a huge piece of code, very likely to be the boot-loader, that goes close up to 0x180000 where the ROM begins(only the kernel). That's good news, since many PNA's don't have this, only a bootstrap (a small code that loads the operating system directly).

A few observations about the "Mass Storage" mode. Servicing this way is made of a soft dedicated, located in the folder, name the USBConnect ResidentFlash2 on Setup.exe. A part of the external dependentelor are still in the same folder, the rest (coredll .dll and mfcce400 .dll) in \Windows.

Before the reset switch menu, change some specific keys media storage/ActiveSync regime (HKLM\Drivers\USB\FunctionDrivers\ClientDriver: "\Drivers\USB\FunctionDrivers\Mass_Storage_Class" or "enter Serial_Class and DefaultClientDriver \Mass_Storage_Class" or "\Serial_Class"); mass storage will go only as long as the program USBConnect is active. Interesting is the fact that this program accomplishes conexiumea mass storage using a driver from the bluetooth software suite, more exactly BTDRV .dll, under the conditions defined in HKLM\Drivers\BuiltIn\BTPort. During the connection process creates an active port COM2:, maintained only as long as the program is in execution USBConnect. Should be added that during connection system ' sees ' no nand-flash nor any external card, so it's not accidentally that outsourced media storage to persist with incapatanare that screen.

This package would be an interesting option for those who want a temporary connection, but is also need a .dll btdrv incarcabil in memory because the ROM is the XIP (ii missing table relocation). Maybe once I'll redo this table for the DLL in question, but if anyone of you is in possession of one which can load in RAM, are willing to continue the close of the project "mass storage".

NOTE:
1) If you don't have an "Explorer" button in the menu, you can enter directly in windows explorer without modifying the registry or making changes of any kind:
- Create with Notepad a file in the root of an SD card with the name "YFGo2CE.DLL". Insert at least one character (minimum length of 1 byte) in it (the file name is case sensitive!!!);
- Insert the card and reset the device using the hole on the side;
- After the start up screen, it will go into windows;
- Taking out the card and resetting, returns to the initial menu;

2) you can easily change the start up logo with any image you like.
- Select the desired image and make it exactly 480x272 pixels in size, then save it as ".BMP" format with 24 bit color depth and name it (!! case sensitive!!!) "Logo72C.bmp" (the name varies from one ROM version to another).
- Place the image in the root of an SD card, insert the card and then hard reset. ** After loading the image, remove the file from the SD Card, since every hard reset will load again ***



As for those interested in accessing the hidden partition, it can be opened with any disk explorer: double-click "ResidentFlash", and up in the address bar stick a "2" after the name ("ResidentFlash2"), then hit "Enter".

Note:
All tweaks presented here refer to WAYTEQ 770, but (possibly) they will work on any other Chinese device if the following conditions are met:

1) In \Windows folder there is an executable called "YFLoader.exe".
2) There is a hidden partition named "ResidentFlash2" which contains a folder with the name YFAP20, YFAP30 or YFAPP.

Note:
To format the partition that contains the operating system, the SD Card must must have the ".img" file along with a file named "YFormat.bld" which contains the string "666F726D6174" without quotes. Use Notepad to create it.

No comments:

Post a Comment