MicroHacker Forum

tasicky wrote: ↑19 Dec 2019, 21:40 The encoding algorithm in this program is not entirely correct.

True ,you also notice that? will we exchange insights?

Go4IT wrote: ↑17 Dec 2019, 11:59 This all was described in mine and Ursadons findings thread.

I checked this topic carefully. However, C+ has several color palettes. e.g. changing the background from blue to cream, changes the way the logo is displayed. BTW, the logo entered in the address 30xx will not appear. Must be entered in another flash memory location. you can choose the place yourself. There is a lot of space there.

I uploaded another logo(fb group I'm associated with) but the color palette during theme change doesn't let me sleep. Still the logo does not display as it should - in the picture you can't see it, but in live it looks bad.

tasicky wrote: ↑19 Dec 2019, 21:40 The encoding algorithm in this program is not entirely correct.

Shure, we are developing and reverse engineering. So, if you know the correct one, or the mistakes made, why don't clearify instead of just pointing to it?

What most of you might know, but just to have told for others is, that imagedata is of dynamic lenght. This is because of the compression algo used. So it is dangerous to just place a custom image onto the same location as the original one because it might be longer and then overwrite data behind it. It would be saver to look for an unused region (0xFF), place it there an change the pointer to it in the lookup table. For shure you need to know the table structure and location, which i currently don't have at hand.

Personal note: Most people here seem just to eager about start logos, which is somewhat uninteresting to me, but the topic seems to evolve like ringtones on handys BUT, as it is of global interest we should collect the discovered facts into a Wiki page, so that nobody needs to read all that stuff here to get it. https://mk4-wiki.denkdose.de/artikel/ip ... s/bootlogo

paxtonix wrote: ↑20 Dec 2019, 00:43

Go4IT wrote: ↑17 Dec 2019, 11:59 This all was described in mine and Ursadons findings thread.

I checked this topic carefully. However, C+ has several color palettes. e.g. changing the background from blue to cream, changes the way the logo is displayed. BTW, the logo entered in the address 30xx will not appear. Must be entered in another flash memory location. you can choose the place yourself. There is a lot of space there.

Why not share the information so we can all try and work together?
Also you say the 30 XX XX XX has to be entered into another location but 3 sets of files with different logos always different bytes at 145B5 6,7,8

Go4IT wrote: ↑20 Dec 2019, 06:14
Shure, we are developing and reverse engineering. So, if you know the correct one, or the mistakes made, why don't clearify instead of just pointing to it?

I'ts also important to point things out - like beta testing. To make it better, and talk about improvement.

I will take a closer look after x-mas . On this moment not much time.

FaceLift 14xx version has free space in external flash starting with 0x11FD00
PreFaceLift 12xx version has free space in external flash starting with 0x10A9C0

External flash is S29AL016J70TFI02 => Spansion CMOS Flash Memory S29AL016J with bottom boot sector device (CFI Support) =>
first sector available to erase and write without needing to rewrite the entire flash is SA21 which starts at 0x120.000 in byte mode (or 0x90.000 in word mode) and ends at 0x12F.FFF in byte mode (or 0x97.FFF in word mode).
One sector in byte mode is 64kbytes (or 32kwords in word mode).

As already said here, a 400*200*1 image needs 79KBytes => we need to delete and write only 2 sectors for a new boot image.
If changing the theme affects the color palette, then we can use 4 sectors (we can use only 3 sectors if we want to save space, but when we want to change a boot image, we will have to write again the other image too) to have 2 different boot images: they can represent the same thing, but coded for the 2 different color palettes or they can be completely two different images, but still encoded for that color palette.
=> SA21 till SA24 => 0x120.000 till 0x15F.FFF
Then, what needs to be done is to change the way the boot image is read from the external memory in order to take into consideration the current chosen Theme.

In the VBF that will load this images you will have to have something like this (for writing all 4 sectors):
// Erase information
// start, length
erase = {
{ 0x30.120.000, 0x00.030.000 }
};
Of course, this is only the readable part of VBF, in a HEX editor for the VBF file is something like this:
30 12 00 00 00 03 00 00 (instead of 30 00 00 00 00 20 00 00)

This way it will be faster to test different images, as writing the external flash is much slower.. and makes no point in writing the entirely flash every time.

For start, I would add 2 different images, each in its 2 sectors (1st image SA21 and SA22 and 2nd image SA23 and SA24) and then modify the main flash in order to load the 1st image instead of the standard one.
If it is all OK, then change it to show 2nd image.
If OK then create new function for ARM to look for the current saved Theme and based on this to load the boot image from SA21 or SA23.
Then find a place in main flash to put this function, writing down its starting address.
Next step would be to modify the original function that reads the boot image at original location to call the new function instead of going and loading the image at the address that is there (replace some calls for reading with "call function at address" then some NO OPs to fill the main flash space until original function steps for reading the original location ends - too keep its occupied space).

Theres 4 bytes that I have found in main that are for the stock logo how do these bytes relate to the address of the logo in flash and do you know how to work out these bytes for a new logo

OMG Folks, before tricking hightech devices, learn how to usefull make quotes. Is it so hard to just quote the sentence you are referring to? So less time to delete all those stuff already written before...

DGAlexandru wrote: ↑20 Dec 2019, 16:33 This way it will be faster to test different images, as writing the external flash is much slower.. and makes no point in writing the entirely flash every time.

100% agree. Just "update"/"patch" what needed is sufficient. So we should investigate on the image structure again. Maybe a disassemble give us more details on it, and where to patch what.

I have also found the bytes in preface and successfully extracted this logo and put it into the main, I will not share this file as it was not suppose to have been posted on here in the first place I am only using it for testing purpose only and will not share or sell

I also managed to extract it and put it into one of my files for facelift

This Is how I know these 4 bytes at the address I have found are for logo

Where I lack knowledge with things like reading code I will try and try things and I'm good at working things out I also have a lot of files to hand so it also helps for comparing