Unzipped Vogue firmware
After the successful ripping out of the firmware tronix286 and Odinokij_Kot, finally the material for scratching appeared. The minimum that was interesting is to determine what kind of device it is, whether it is possible to unblock some useful features, well, at least change the annoying screensaver.
(For impatient and practitioners: a new software for changing the screen saver, flashing and picking the firmware below)
The very first and simple thing you can do is to view the files visually in the text and HEX editors. Immediately striking:
img_boot.bin and res.bin contain something very similar to bitmaps
minios.bin - at the beginning has something like a header with file names
I will tell you about them further.
')
Let's start with img_boot.bin. Visually very similar to bitmap graphics. Based on the regularity of the data structure, we assume that the typical record is 4 bytes. One byte is always $ 00. Let the other three be RGB values for 24 bits of bitmap. We write a simple program that reads data in a row and puts it in a bitmap. The size of the bitmap is set comparable to the size of the screen. We start. We see something plus or minus folding in the picture. We select the width to make the picture right. We get a width of 480.
Obviously, these are frames of some kind of animation. The first 4 bytes are clearly out of the big picture, most likely some kind of header. We look at these same 4 first bytes. What is most logical to store in the header of the picture? First of all its permission. The first 2 bytes are added to $ 01E0 - 480, the second to $ 0CC0 - 3264. 12 frames are visible in the animation. The height of one frame is 3264/12 = 272. Actually, this is all clear with the img_boot.bin format.
The resulting animation is not displayed anywhere during normal operation. And the most interesting this animation has little to do with American chip. Perhaps here they are the "ears" of the original device / firmware, of which at least a part is taken as the basis of the postcard.
With the help of colleagues, we managed to find out that this is the logo of the Subor company, which also manufactures media players on Ingenic chips. Alas, my attempts to use the found firmware for Subor were unsuccessful. But it may well be because Different memory chips were used and the nand settings with which to flash these firmware, various displays, etc. are not known.
In img_boot.bin there was no boot saver. The next contender for screen saver is res.bin. Res.bin is clearly not as simple as img_boot.bin. The volume says that there is not one picture / data block. The title / directory of resources in the file is not explicitly viewed. We look into the file already written for bitmaps for img_boot.bin. Immediately striking parted pictures at the beginning of the file. Scroll the file further and hooray - we see the splash screen, adjust the offset. In this place, the first version of the program for changing the screensaver was stuck to the fast paw. Accordingly, information about these findings and the first version of the utility were presented in my LiveJournal. Below is a link to the last much more convenient version of this program.
If you look at the HEX editor for 4 bytes before the splash screen, we see a familiar header with the width and height of the bitmap. Next, read the article Odinokij_Kot on the organization of memory / firmware. NAND memory is addressed in 2 KB blocks. It is logical to assume that to optimize the work, the appeal to resources can also be organized in blocks. We are checking. We see that, taking into account the header, the start of the splash screen is aligned on the 2K block boundary, and at the end, behind the bitmap, stuffing to the boundary of the next block is clearly visible. With this in mind, we can search for all other bitmaps in the resource file.
Interestingly, in the bitmaps from res.bin, the 4th byte is used as the bitmap transparency mask. Also, in addition to standard bitmaps, interesting service blocks similar to graphics are visible at the beginning of the file. I assume that they are used to create interface animation effects.
It is seen that bitmaps are clearly more than necessary for an advertising card. Almost all skins for a full-fledged media player. This suggests that the firmware hastily doped from some existing media player. Among the icons are photos, music, radio, TV, settings, watches, books, voice recorder and even flash. In general, a good device. I wanted to hope that they were not cut out from the firmware, but ...
At the beginning of the file the catalog of modules is visible. By the regularity of the blocks in the directory, the record size is visible - 48 bytes. Suppose that the first 32 is the module name because All names fit into this length. There are 16 bytes left.
The first 4 for all records are equal to 0, we consider them as reserved.
The next 4 bytes are small increments from module to module. It is logical to assume that this is the offset of the beginning of the block relative to the beginning of the file, but they are too small to directly address the data. Suppose these are the block numbers inside the file. The file clearly shows where the beginning of the first module is after the directory - offset 0x1000. For it is the address 0x02. We get the block size of 2048 bytes, which logically fits with the addressing of the flash drive.
Next come 4 bytes with values very similar to memory addresses. It is not exactly known what it is, but I assume that these are the addresses of the module loading into memory.
The remaining 4 bytes fit perfectly with the size of the module. It is easy to compare as the modules are aligned on the block boundaries of 2048 bytes. Knowing the address of the beginning of the module, and tracking where the stuffing begins, we can determine the size of the module and compare it with the number in the corresponding header.
As a result, a simple utility was made that allows you to unpack minios.bin into separate modules, as well as save minios.bin with replaced modules / parameters. This allows you to replace the modules in this firmware with modules from the firmware from other similar players.
Comparing the composition of minios.bin in different firmwares showed that, unfortunately, some modules are missing in the current firmware, and some modules like desktop.bin are suspiciously smaller.
Those interested can play with the substitution of modules, perhaps someone will succeed. However, it should be noted that in different firmware modules are loaded into memory at different addresses and because of this, most likely when loading a module, the transition addresses inside the module will be knocked down, not to mention the call addresses of other modules. Something is required to correct it in the module.
Download here: ifolder.ru/20663679
The program is a graphical shell for a utility written by tronix286.
It is extremely simple to use:
- Unpack the archive and run MartiniLogoChanger.exe
- Turn off the card (close the card or turn off the battery).
- Clamp the button (glued to the right and just below the screen).
- We connect the card via USB to the computer.
- If necessary, install the driver from the usbboot_driver folder.
If everything is normal - in the upper right corner of the program should be highlighted in green the inscription 'connected'. After that, you can work with the firmware and screensaver.
Changing the logo is done in two clicks:
1 Select BMP image (there are a couple of examples in the folder)
2 If everything is OK - press the button “Flash it!”
Unlike the previous utility, now you do not need to change the entire firmware to change the logo; only the desired piece is overwritten.
Everything for changing and restoring the firmware is located on the 'firmware updater' tab.
The input fields indicate the file names for the respective modules and the addresses to load them into the flash.
'Open dir' - looks for firmware files in the selected directory, writes them into the appropriate fields. If any files are missing, replace them from the original firmware.
'Flash it!' - launches the firmware of the above files
'Download FW' - starts downloading the current firmware in the selected folder
'Restore Original FW' - restores the firmware from the folder original_fw
Script templates for filling / cream firmware are in the templates folder, if you need, you can tweak it to your liking.
ATTENTION! The length of the path to the firmware files along with the file name should not exceed 50 characters, otherwise USB_Boot is buggy!
Download here: ifolder.ru/20663735
Spread as is. I hope after reading the description above it should be clear what's what.
(For impatient and practitioners: a new software for changing the screen saver, flashing and picking the firmware below)
The very first and simple thing you can do is to view the files visually in the text and HEX editors. Immediately striking:
img_boot.bin and res.bin contain something very similar to bitmaps
minios.bin - at the beginning has something like a header with file names
I will tell you about them further.
')
img_boot.bin
Let's start with img_boot.bin. Visually very similar to bitmap graphics. Based on the regularity of the data structure, we assume that the typical record is 4 bytes. One byte is always $ 00. Let the other three be RGB values for 24 bits of bitmap. We write a simple program that reads data in a row and puts it in a bitmap. The size of the bitmap is set comparable to the size of the screen. We start. We see something plus or minus folding in the picture. We select the width to make the picture right. We get a width of 480.
Obviously, these are frames of some kind of animation. The first 4 bytes are clearly out of the big picture, most likely some kind of header. We look at these same 4 first bytes. What is most logical to store in the header of the picture? First of all its permission. The first 2 bytes are added to $ 01E0 - 480, the second to $ 0CC0 - 3264. 12 frames are visible in the animation. The height of one frame is 3264/12 = 272. Actually, this is all clear with the img_boot.bin format.
The resulting animation is not displayed anywhere during normal operation. And the most interesting this animation has little to do with American chip. Perhaps here they are the "ears" of the original device / firmware, of which at least a part is taken as the basis of the postcard.
With the help of colleagues, we managed to find out that this is the logo of the Subor company, which also manufactures media players on Ingenic chips. Alas, my attempts to use the found firmware for Subor were unsuccessful. But it may well be because Different memory chips were used and the nand settings with which to flash these firmware, various displays, etc. are not known.
res.bin
In img_boot.bin there was no boot saver. The next contender for screen saver is res.bin. Res.bin is clearly not as simple as img_boot.bin. The volume says that there is not one picture / data block. The title / directory of resources in the file is not explicitly viewed. We look into the file already written for bitmaps for img_boot.bin. Immediately striking parted pictures at the beginning of the file. Scroll the file further and hooray - we see the splash screen, adjust the offset. In this place, the first version of the program for changing the screensaver was stuck to the fast paw. Accordingly, information about these findings and the first version of the utility were presented in my LiveJournal. Below is a link to the last much more convenient version of this program.
If you look at the HEX editor for 4 bytes before the splash screen, we see a familiar header with the width and height of the bitmap. Next, read the article Odinokij_Kot on the organization of memory / firmware. NAND memory is addressed in 2 KB blocks. It is logical to assume that to optimize the work, the appeal to resources can also be organized in blocks. We are checking. We see that, taking into account the header, the start of the splash screen is aligned on the 2K block boundary, and at the end, behind the bitmap, stuffing to the boundary of the next block is clearly visible. With this in mind, we can search for all other bitmaps in the resource file.
Interestingly, in the bitmaps from res.bin, the 4th byte is used as the bitmap transparency mask. Also, in addition to standard bitmaps, interesting service blocks similar to graphics are visible at the beginning of the file. I assume that they are used to create interface animation effects.
It is seen that bitmaps are clearly more than necessary for an advertising card. Almost all skins for a full-fledged media player. This suggests that the firmware hastily doped from some existing media player. Among the icons are photos, music, radio, TV, settings, watches, books, voice recorder and even flash. In general, a good device. I wanted to hope that they were not cut out from the firmware, but ...
minios.bin
At the beginning of the file the catalog of modules is visible. By the regularity of the blocks in the directory, the record size is visible - 48 bytes. Suppose that the first 32 is the module name because All names fit into this length. There are 16 bytes left.
The first 4 for all records are equal to 0, we consider them as reserved.
The next 4 bytes are small increments from module to module. It is logical to assume that this is the offset of the beginning of the block relative to the beginning of the file, but they are too small to directly address the data. Suppose these are the block numbers inside the file. The file clearly shows where the beginning of the first module is after the directory - offset 0x1000. For it is the address 0x02. We get the block size of 2048 bytes, which logically fits with the addressing of the flash drive.
Next come 4 bytes with values very similar to memory addresses. It is not exactly known what it is, but I assume that these are the addresses of the module loading into memory.
The remaining 4 bytes fit perfectly with the size of the module. It is easy to compare as the modules are aligned on the block boundaries of 2048 bytes. Knowing the address of the beginning of the module, and tracking where the stuffing begins, we can determine the size of the module and compare it with the number in the corresponding header.
As a result, a simple utility was made that allows you to unpack minios.bin into separate modules, as well as save minios.bin with replaced modules / parameters. This allows you to replace the modules in this firmware with modules from the firmware from other similar players.
Comparing the composition of minios.bin in different firmwares showed that, unfortunately, some modules are missing in the current firmware, and some modules like desktop.bin are suspiciously smaller.
Those interested can play with the substitution of modules, perhaps someone will succeed. However, it should be noted that in different firmware modules are loaded into memory at different addresses and because of this, most likely when loading a module, the transition addresses inside the module will be knocked down, not to mention the call addresses of other modules. Something is required to correct it in the module.
Soft
1. More convenient and faster utility for changing the logo and flashing firmware.
Download here: ifolder.ru/20663679
The program is a graphical shell for a utility written by tronix286.
It is extremely simple to use:
- Unpack the archive and run MartiniLogoChanger.exe
- Turn off the card (close the card or turn off the battery).
- Clamp the button (glued to the right and just below the screen).
- We connect the card via USB to the computer.
- If necessary, install the driver from the usbboot_driver folder.
If everything is normal - in the upper right corner of the program should be highlighted in green the inscription 'connected'. After that, you can work with the firmware and screensaver.
Logo change
Changing the logo is done in two clicks:
1 Select BMP image (there are a couple of examples in the folder)
2 If everything is OK - press the button “Flash it!”
Unlike the previous utility, now you do not need to change the entire firmware to change the logo; only the desired piece is overwritten.
Everything for changing and restoring firmware
Everything for changing and restoring the firmware is located on the 'firmware updater' tab.
The input fields indicate the file names for the respective modules and the addresses to load them into the flash.
'Open dir' - looks for firmware files in the selected directory, writes them into the appropriate fields. If any files are missing, replace them from the original firmware.
'Flash it!' - launches the firmware of the above files
'Download FW' - starts downloading the current firmware in the selected folder
'Restore Original FW' - restores the firmware from the folder original_fw
Script templates for filling / cream firmware are in the templates folder, if you need, you can tweak it to your liking.
ATTENTION! The length of the path to the firmware files along with the file name should not exceed 50 characters, otherwise USB_Boot is buggy!
2. picking minios.bin
Download here: ifolder.ru/20663735
Spread as is. I hope after reading the description above it should be clear what's what.
Source: https://habr.com/ru/post/109507/
All Articles