Manufacturer's Firmware Modification

From S1MP3 Wiki

Jump to: navigation, search

Contents

Introduction

Before you begin, you need to acquire proper firmware binary file for your mp3/mp4 player. You can use full dump that you may find on CD shipped with the player or use s1fwx tool to download partial dump from your player (remember to 'repair' it after retrieving). In case of using dump acquired from other sources first upload it to test if it works unmodified.
Warning Uploading firmware not designed for your player's board model gives 99% chance of making player inoperative - then you will have to follow the Dead Recovery Guide.

Methods of modifying firmware

  • FWModify allows to modify some basic player's parameters.
  • s1res allows to modify all applications' images/icons/symbols/character sets and messages in all languages.
  • use s1fwx to manually modify contents of dump file.

First two methods are very safe and easy to perform, read about mentioned software tools to learn how to perform those modifications.

The third method when performed incorrectly may make player inoperative, but gives many interesting possibilities. This method will be described in more detail below.

Manually modifying firmware

General steps to manually modify firmware:

  1. Extract files
    1. repair firmware: s1fwx r dump.bin
    2. create script file for dump.bin: s1fwx s dump.bin > dump.script
    3. extract dump file: s1fwx x dump.bin
    4. extract fwimage.fw: s1fwx x fwimage.fw
    5. create script file for fwimage.fw: s1fwx s fwimage.fw > fwimage.script
  2. Modify extracted files
    1. you can add/modify files, changing file sizes won't damage whole firmware
  3. Create modified dump file
    1. rename original fwimage.fw to some other name
    2. use script to recreate fwimage with modified files: s1fwx a fwimage.fw:fw < fwimage.script
    3. use dump.script to create modified dump file: s1fwx a mod_dump.bin:afi < dump.script
    4. check logs displayed on screen for errors
    5. check if final dump file size seems to be correct
  4. Upload modified dump
    1. Run Mp3 Update Tool application on PC
    2. Open modified dump file
    3. check if displayed dump file details are the same as those on the player
    4. perform firmware upgrade

If you can't edit your extracted firmware files, it could be because they are encypted. Read How to decrypt manufacturer's firmware.

Example of modification for mp4 players

As a simple example it is possible to exchange names of tester.ap and record.ap files so REC main menu entry will launch a test application normally unaccesible to the user. This operation is an advised warm up before attempting to perform more serious modifications - like using data from other players version, as it helps to understand the whole process and is quite easy and safe to perform.
Effect of this modification performed on YaGu 1521CF+:

Tester.ap's main screen
Screen that tests OLED colors
Keys test


You can exchange less used applications - like the recorder, for any other application by simply renaming your new application to the name of the undesired application - in this case, RECORD.AP. This is how S1SDK works.

Merging files from different firmware versions

The method described above seem to make it possible to use applications found in other firmware versions, but there are some identified problems:

  1. most applications depend on resource files to display graphics and internationalized messages, so it is needed to include both resource files, and use an Hex-Editing tool to have some applications from one firmware version and some from other
  2. drv files should be used from firmware designed for exactly the same player as players usually differ with keys layout and OLED type (to be verified).
  3. It seems that some applications written for a release firmware are unable to 'communicate' with drivers from other firmware release making the player reboot when launching this application.

Ad 1. A successful test was performed on porting tester.ap between different firmware versions (3.5.35 to 3.2.16), but same test on reader.ap failed - player rebooted after launching the application. It may be possible although risky to upgrade all files except .drv and .bin (leaving those original).

Example of firmware hacking: changing the backlight behavior

in case someone else is interested in practising or know how I managed to keep my backlight from changing, here's the whole stuff.

Since I detected the light didn't change color randomly but following a sequence (the same colors in the same order all the time, let's imagine from 0 to 6 and over again) I began searching the whole file for something like

INC A  --> let's increment the light color identifier
CP 07H --> is is 7? (then it should be set to 0 again!)
(or in hexa 3C / FE 07)

but with no luck. Then I thought maybe they were using some mask before doing the comparison, and performing and AND with 7 seemed to be the most logical option:

INC A
AND 07H
(or in hexa 3C / E6 07)

and... bingo! Only one occurence! Smile Exactly in KY_HARD.DRV file (sounds good, hmmm... "key"...). The piece of code involving this one was this (followed by some interesting stuff filled of IN and OUT instructions):

(all addresses relative to the beginning of KY_HARD.DRV file)

Addr Hexa bytes  Label   Disassembled code
---- ----------- ------- -----------------
0422 3A E9 06            LD A,(06E9H)
0425 3C                  INC A
0426 E6 07               AND 07H
0428 FE 07               CP 07H
042A 20 01               JR NZ,L0022
042C AF                  XOR A
042D 32 E9 06    L0022:  LD (06E9H),A

Well, when I was about 13 one book taught me you should always try to alter as little code as possible, so I decided to fix the value for my accumulator (A register) to the value I wanted as follows:

Addr Hexa bytes  Label   Disassembled code
---- ----------- ------- -----------------
0422 3A E9 06            LD A,(06E9H)
0425 3C                  INC A
0426 3E 03               LD A,03H          <=== Let's hold our color value! 3, that is, always cyan
0428 FE 07               CP 07H
042A 20 01               JR NZ,L0022
042C AF                  XOR A
042D 32 E9 06    L0022:  LD (06E9H),A

Since the comparison with 7 afterwards is never going to be true, the XOR A instruction which would set our A registry to 0 is never going to be executed, so this should do the trick. Ok, I saved everything, fixed my .BIN packed file, reflashed and... bingo! It works! (it's a kind of maaagiiic... Razz)

I hope this would be of any help to someone else! :)

Personal tools
about this site
Advertisement