Picking up Vogue firmware
After successfully tearing out the tronix286 and Odinokij_Kot firmware, material for cracking finally appeared. The minimum that was interesting was to determine what kind of device it was, whether it was possible to unlock some useful features, and at least change the intrusive screensaver.
(For impatient and practitioners: new software for changing the screen saver, flashing and picking the firmware below)
The very first and easiest thing to do is to view the files visually in text and HEX editors. It immediately catches your eye:
img_boot.bin and res.bin contain something very similar to the minios.bin
bitmaps - at the beginning there is something like a header with file names,
I’ll tell you more about them.
Let's start with img_boot.bin. Visually very similar to bitmap graphics. Based on the regularity of the data structure, we assume that a typical record takes 4 bytes. One byte is always $ 00. Let the other three be RGB values for the 24 bit bitmap. We are writing a simple program that reads data in a row and puts it into a bitmap. The bitmap size is set comparable to the screen size. We start. One can see something plus or minus folding in the picture. We select the width so that the picture develops directly. We get a width of 480.
Obviously, these are frames of a certain animation. The first 4 bytes are clearly knocked out of the picture, most likely some kind of header. We look at these very first 4 bytes. What is the most logical way to store in the header of the picture? The first thing is her permission. The first 2 bytes add up in $ 01E0 - 480, the second in $ 0CC0 - 3264. 12 frames are visible in the animation. The height of one frame is 3264/12 = 272. Actually, this is clear with the format img_boot.bin.
The resulting animation is not displayed anywhere during normal software operation. And most interestingly, this animation has little to do with America. 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, I managed to find that this is the logo of the Subor company, which also produces media players based on Ingenic chips. Alas, my attempts to use the found firmware for Subor were unsuccessful. But it may well be because different memory chips are used and nand settings are not known with which to flash these firmware, different displays, etc.
Img_boot.bin did not have a startup screen saver. The next applicant for the splash screen is res.bin. Using res.bin is clearly not as easy as using img_boot.bin. The volume says that there is more than one picture / data block. The header / directory of resources in the file is not explicitly viewed. We look into the file already written for img_boot.bin by the bitmap watcher. Immediately struck by the dispersed pictures at the beginning of the file. Scroll the file further and cheers - see the splash screen, adjust the offset. In this place, the first version of the program for changing the screen saver was slopped on an ambulance. Accordingly, information about these findings and the first version of the utility were presented in my LJ. Below is a link to the latest much more convenient version of this program.
If you look at the HEX editor for 4 bytes in front of the splash screen, you see a familiar header with a width and a fixed bitmap. Next, read the article Odinokij_Kot on the organization of memory / firmware. NAND memory is addressed in blocks of 2KB. It is logical to assume that, to optimize the work, access to resources can also be organized in blocks. We check. We see that, taking into account the title, the start of the splash screen is aligned on the border of the 2K block, and at the end, behind the bitmap, stuffing is clearly visible to the border of the next block. With this in mind, we can search for all other bitmaps in the resource file. Interestingly, in bitmaps from res.bin the 4th byte is used as a mask for transparency of the bitmap. 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 can be seen that there are clearly more bitmaps than are necessary for an advertising card. Almost all skins for a full-fledged media player. This suggests that the firmware was whipped up from some existing media player. Among the icons are photos, music, radio, TV, settings, clocks, books, voice recorder and even flash. In general, a good device was. I wanted to hope that they were not cut out of the firmware, but ...
At the beginning of the file, the module directory is visible. By the regularity of blocks in the directory, the record size is visible - 48 bytes. Suppose the first 32 is the name of the module since all names fit this length. 16 bytes left.
The first 4 for all records are 0, we consider them reserved.
The next 4 bytes are small values growing 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 block numbers within a file. The file clearly shows where the beginning of the first module after the directory is located - offset 0x1000. The address 0x02 is specified for it. We get a block size of 2048 bytes, which logically matches the addressing of the flash drive.
Next comes 4 bytes with values very similar to memory addresses. It is not known exactly what it is, but I assume that these are the module's load addresses in memory.
The remaining 4 bytes fit perfectly with the size of the module. This is easy to compare since the modules are aligned on the boundaries of 2048 byte blocks. Knowing the address of the beginning of the module, and tracking where 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, which allows you to unpack minios.bin into separate modules, as well as save minios.bin with the replaced modules / parameters. This allows you to replace the modules in this firmware with modules from the firmware from other similar players.
Comparison of the composition of minios.bin in different firmware 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, maybe someone will succeed. However, it should be borne in mind that in different firmware modules are loaded into memory at different addresses and because of this, most likely, when the module is loaded, the transition addresses inside the module will be knocked down, not to mention the call addresses of other modules. It is required to somehow correct this inside the module.
Download here: ifolder.ru/20663679
The program is a graphical shell for a utility written by tronix286.
Using is extremely simple:
- Unpack the archive and run MartiniLogoChanger.exe
- Turn off the card (close the card or turn off the battery).
- Hold the button (glued to the right and just below the screen).
- 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 the inscription 'connected' should be highlighted in green. After that, you can work with firmware and screensaver.
Changing the logo is done in two clicks:
1 Select the BMP image (there are a couple of examples in the folder)
2 If everything is ok, click the button “Flash it!”
Unlike the previous utility, now to change the logo you do not need to alter the entire firmware, only the desired piece is copied.
Everything for changing and restoring the firmware is located on the 'firmware updater' tab.
Input fields indicate the file names for the respective modules and the addresses for loading them into flash.
'Open dir' - searches for firmware files in the selected directory, writes them to the appropriate fields. If any files are missing - replace them from the original firmware
'Flash it!' - starts the firmware of the above files
'Download FW' - starts the download of the current firmware to the selected folder
'Restore Original FW' - restores the firmware from the original_fw folder
Script templates for filling / cream of the firmware are in the templates folder, if you need someone you can tweak to your taste.
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: new software for changing the screen saver, flashing and picking the firmware below)
The very first and easiest thing to do is to view the files visually in text and HEX editors. It immediately catches your eye:
img_boot.bin and res.bin contain something very similar to the minios.bin
bitmaps - at the beginning there is something like a header with file names,
I’ll tell you more about them.
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 a typical record takes 4 bytes. One byte is always $ 00. Let the other three be RGB values for the 24 bit bitmap. We are writing a simple program that reads data in a row and puts it into a bitmap. The bitmap size is set comparable to the screen size. We start. One can see something plus or minus folding in the picture. We select the width so that the picture develops directly. We get a width of 480.
Obviously, these are frames of a certain animation. The first 4 bytes are clearly knocked out of the picture, most likely some kind of header. We look at these very first 4 bytes. What is the most logical way to store in the header of the picture? The first thing is her permission. The first 2 bytes add up in $ 01E0 - 480, the second in $ 0CC0 - 3264. 12 frames are visible in the animation. The height of one frame is 3264/12 = 272. Actually, this is clear with the format img_boot.bin.
The resulting animation is not displayed anywhere during normal software operation. And most interestingly, this animation has little to do with America. 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, I managed to find that this is the logo of the Subor company, which also produces media players based on Ingenic chips. Alas, my attempts to use the found firmware for Subor were unsuccessful. But it may well be because different memory chips are used and nand settings are not known with which to flash these firmware, different displays, etc.
res.bin
Img_boot.bin did not have a startup screen saver. The next applicant for the splash screen is res.bin. Using res.bin is clearly not as easy as using img_boot.bin. The volume says that there is more than one picture / data block. The header / directory of resources in the file is not explicitly viewed. We look into the file already written for img_boot.bin by the bitmap watcher. Immediately struck by the dispersed pictures at the beginning of the file. Scroll the file further and cheers - see the splash screen, adjust the offset. In this place, the first version of the program for changing the screen saver was slopped on an ambulance. Accordingly, information about these findings and the first version of the utility were presented in my LJ. Below is a link to the latest much more convenient version of this program.
If you look at the HEX editor for 4 bytes in front of the splash screen, you see a familiar header with a width and a fixed bitmap. Next, read the article Odinokij_Kot on the organization of memory / firmware. NAND memory is addressed in blocks of 2KB. It is logical to assume that, to optimize the work, access to resources can also be organized in blocks. We check. We see that, taking into account the title, the start of the splash screen is aligned on the border of the 2K block, and at the end, behind the bitmap, stuffing is clearly visible to the border of the next block. With this in mind, we can search for all other bitmaps in the resource file. Interestingly, in bitmaps from res.bin the 4th byte is used as a mask for transparency of the bitmap. 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 can be seen that there are clearly more bitmaps than are necessary for an advertising card. Almost all skins for a full-fledged media player. This suggests that the firmware was whipped up from some existing media player. Among the icons are photos, music, radio, TV, settings, clocks, books, voice recorder and even flash. In general, a good device was. I wanted to hope that they were not cut out of the firmware, but ...
minios.bin
At the beginning of the file, the module directory is visible. By the regularity of blocks in the directory, the record size is visible - 48 bytes. Suppose the first 32 is the name of the module since all names fit this length. 16 bytes left.
The first 4 for all records are 0, we consider them reserved.
The next 4 bytes are small values growing 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 block numbers within a file. The file clearly shows where the beginning of the first module after the directory is located - offset 0x1000. The address 0x02 is specified for it. We get a block size of 2048 bytes, which logically matches the addressing of the flash drive.
Next comes 4 bytes with values very similar to memory addresses. It is not known exactly what it is, but I assume that these are the module's load addresses in memory.
The remaining 4 bytes fit perfectly with the size of the module. This is easy to compare since the modules are aligned on the boundaries of 2048 byte blocks. Knowing the address of the beginning of the module, and tracking where 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, which allows you to unpack minios.bin into separate modules, as well as save minios.bin with the replaced modules / parameters. This allows you to replace the modules in this firmware with modules from the firmware from other similar players.
Comparison of the composition of minios.bin in different firmware 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, maybe someone will succeed. However, it should be borne in mind that in different firmware modules are loaded into memory at different addresses and because of this, most likely, when the module is loaded, the transition addresses inside the module will be knocked down, not to mention the call addresses of other modules. It is required to somehow correct this inside the module.
Software
1. A 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.
Using is extremely simple:
- Unpack the archive and run MartiniLogoChanger.exe
- Turn off the card (close the card or turn off the battery).
- Hold the button (glued to the right and just below the screen).
- 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 the inscription 'connected' should be highlighted in green. After that, you can work with firmware and screensaver.
Logo change
Changing the logo is done in two clicks:
1 Select the BMP image (there are a couple of examples in the folder)
2 If everything is ok, click the button “Flash it!”
Unlike the previous utility, now to change the logo you do not need to alter the entire firmware, only the desired piece is copied.
Everything for changing and restoring firmware
Everything for changing and restoring the firmware is located on the 'firmware updater' tab.
Input fields indicate the file names for the respective modules and the addresses for loading them into flash.
'Open dir' - searches for firmware files in the selected directory, writes them to the appropriate fields. If any files are missing - replace them from the original firmware
'Flash it!' - starts the firmware of the above files
'Download FW' - starts the download of the current firmware to the selected folder
'Restore Original FW' - restores the firmware from the original_fw folder
Script templates for filling / cream of the firmware are in the templates folder, if you need someone you can tweak to your taste.
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. Picker minios.bin
Download here: ifolder.ru/20663735
Spread as is. I hope after reading the description above it should be clear what's what.