SHX File Modding Guide

From HowardForums Wiki
Jump to: navigation, search

NOTE: original text taken from PDF and edited to use mediaWiki markup formatting; no content alterations made intentionally. --rivvah 16:25, 23 Dec 2005 (CST)

SHX File Modding
Revision 2
07 / 01 / 2005
By Eyesonly_d of Howard Forums.

Eyesonly_d gives permission to distribute and host this document only in its entirety and unaltered.


This is phone modding to the extreme. This is not for the light-hearted casual user. There is no sugar coating this, you screw up and your phone is toast. I am including everything I know and have discovered in this document, but keep in mind to tread cautiously, and be conservative in what you try to do.

Eyesonly_d is providing this information without liability. If you start hacking on your phone with this information you do it at your own risk, Eyesonly_d is not responsible for damage to phones as a result of this information.

This is also written for the advanced user with a considerable level of hex editing experience. This guide assumes a background knowledge in hex editing and general computer architecture. The user should be familiar with the following terms: Bytes, Words, Offsets, Bits, Characters, “endian-ness”, ROM, RAM, FLASH, HEX, etc.

The following information was discovered using reverse engineering techniques, and publicly available documentation. No proprietary information was used. No Motorola employees have verified this information. This means that the accuracy of this information is not guaranteed.

In general this guide was created from investigating the E398. Much of this information is applicable to other GSM Motorola phones as well.

Source(s): SHX File Modding Guide

How this Document is Written
This is a difficult subject for a novice modder to learn. This makes it an even harder subject to teach. This document is divided into sections based on topic. Each topic can be read individually for the most part, but sometimes things will be referred to in other sections. Do not be surprised if you find yourself skipping back and forth between sections trying to make sense out of all this. In general, try to read all the information from start to finish, and then read it again to get the full understanding. Also having the actual files and other hand-on stuff in front of your will make learning this easier. In general if something has you completely confused or is over your head, Search Google on some of the key words for a more basic level explanation of terms and concepts.

A Note on BIN Names
Names given to the BIN files, or other items, are not official and only a identification given based on the current knowledge of the items purpose. It is not guaranteed to be 100% accurate.

In previous versions of this document, and also in common language online, BIN1 (128KB) is referred to as the "BOOTLOADER". Due to recent discoveries, this name is now found to be inappropriate. When the user powers up the phone in boot mode and initiates a firmware upgrade, the phone is put into a "Bootstrap mode". This mode will copy the 128KB BIN1 to CPU RAM at 0x03FD0000. The CPU is then reset to run the program in RAM. The program directs the phone to download chucks of the upgrade through USB to RAM, and then copy the RAM chunk to its appropriate place in FLASH. Then the phone gets the next chunk, and so on. BIN1 serves as a "Bootstrapping program for upgrading firmware" and thus BIN1 will now be referred to as the "BOOTSTRAP".

Likewise, BIN2 has taken the common name of “FLASH”. This name gets confusing with flash chip. BIN2 actually contains the core operating functionality. As a result, BIN2 will now be known as the “KERNEL”.

Information Sources
Phone hardware visual examination, FCC ID, Patent Information, Manufacturer public data sheets, Papers on similar commercial (non-proprietary) parts, Phone Memory Dumps, Wikipedia, Google, HowardForums, MotoX’s V3 0823 Bootloader Upgrade SHX file, plus my own personal experiences

About the Author
Eyesonly_d” is an American male living in Georgia, USA. He is currently pursuing his Electrical Engineering degree at the Georgia Institute of Technology and graduating soon. He many years of experience in computer programming in assembly, C++, JAVA, and other various languages. He also has experience in embedded system programming on many architectures including X86, ARM, Z80, 68K, and POWERPC. He also has previous expertise in programming and modding TI Calculators and PocketPCs. He is a HAM radio operator who enjoys tweaking with the electronics more then the actual communication. He has many years of work experience in RADAR systems.

Lately he has become interested in all aspects of Cellular Phones and Systems. He has excelled at many classes in the subject including Embedded System Design, RF Theory and Design, and Wireless Communication Systems. He is an active internet community member. Recent projects include work on a new cell tower RF propagation model to increase urban cellular planning efficiency, and Motorola GSM phone reverse engineering. He is the author of the V398 Firmware project used by hundreds of E398 users. He is a proud owner of a Motorola E398.



For software titles, check out our Software article.

Needed Utilities and Files

  • Hex Editor – This is your main tool. Get a good one. The XVI32 program that is recommended for seem editing is NOT enough. I use and recommend an older version of Hex Workshop, which is excellent. However I think Hex Workshop is no longer freeware.
  • RandomSHX – This is a general SHX BIN converter. More information on using this program can be found in the next section.
  • Paper and Pencil – Good for taking quick notes and keeping track of things, also it is a good place to write down quick ideas and discoveries. There is a lot to learn and discover in this domain of modding.
  • SHXCodec- Great utility to build SHX files from SMG ( code groups), splitting SHX files into SMG files. Also allows DRM editing, Language pack editing, Flex editing.
  • SHX files – Get as many of these as you can. Get 5 or 6 LANG PACKS. Get at least 3 or 4 REFLASH files. Get a couple MONSTER files. Get a copy of MotoX’s BOOTLOADER SHX file. When you are in doubt about how something should look, you should open up something similar and see how it looks. Or you can verify that a value stays the same for all of a certain phone’s SHX files, or all of just that phone’s language packs, etc. Also when going through these notes, open up the appropriate file in the hex editor and follow along, it will make you understanding MUCH easier.
  • MFF – MultiFlexFlash, part of Motorola Phone Service Tools (PST). This program is used to flash a phone’s FLASH with a firmware inside an SHX file. This program is proprietary, not freeware. This guide assumes you know how to use this software.
  • RAMLDR – Made by Vilko, the creator of P2KMan. This program allows you to dump a memory space of the phone to a file on your computer. More information on using this program can be found in the next section.

--Living sword 13:30, 15 December 2006 (EST)

Source(s): SHX File Modding Guide

Using RandomSHX for SHX <=> BIN Conversion

RandomSHX has two main capabilities.

  • Decrypt and split an SHX file into an LST file and group of BIN files.
  • Take the group of BIN format files plus a LST file and convert it back to an SHX file.

For more information on the different kinds of files (BIN,LST,etc) see section 2.

Using RAMLDR for Memory Dumping

In addition to mixing and matching parts SHX files, one can also incorporate a “Memory Dump” from a phone into an SHX. A “Memory Dump” is where an exact copy of a phone’s memory is created and “dumped” into a file. The only program able to do this on the E398/V3 is RAMLDR by Vilko (maker of P2kMan). Here are some instructions on how to use it.

Obtaining the dump files with RAMLDR

  1. First put the phone into flash mode
  2. Start up RAMLDR
  3. Press "Send RAMLDR" and select the ldr.bin file.
  4. Now we set the memory range we want to dump. For the E398:
           ROM: 0x00000000 0x00200000
           PROGRAM RAM: 03FD0000 03FF0000 (256KB)
           FULL RAM: 03FC0000 0x04000000
           COMPLETE FLASH CHIP: 10000000 to 12000000 (32MB)
           BOOTLOADER: 1000000 to 1000F000 (60KB)
           BOOTVECTOR: 1000F000 to 10010000 (4KB)
           KERNEL: 10080000 to 10D00000 (12.5MB)
           FLEX: 11140000 to 11FE0000 (14.6MB)
           DSP: 10040000 to 10080000 (256KB)
           LANGPACK: 10F40000 to 11140000 (2MB)
           DRM: 10D00000 to 10F00000 (2MB)
           SIGNATURE: 11FE0000 to 11FE0800 (2KB)
  1. Now click "Save Mem".

If all goes well the program should start churning along displaying DUMP messages. When it is finished there will be a file named as the start address in the RAMLDR folder.

When you are done, be sure to hit the reset button to bring your phone back to normal state, otherwise the phone will stay frozen!

While the phone is resetting, pull the cable out so RAMLDR does not force it into flash mode again.

Converting RAMLDR Dump Files to BIN
Each type of dump should be modified to be a valid BIN file as described below.

  • RAM: This is a volatile memory space, and should be not used in any SHX files.
  • FLEX: Just rename the dump file (11140000) to the bin name, eg (Name)2.bin.
  • SIGNATURE: Just rename the dump file (11FE0000) to the bin name, eg (Name)6.bin.
  • KERNEL: This dump file will have a long section of FFFF at the end. You can safely trim off these FFFF. The resulting file should be around 10MB-11MB.
  • DSP: This dump file will also have FFFF at the end. Also there is a characteristic hex pattern at the end of all DSP BIN files, look for it and trim the dump to make it match in length.
  • LANGPACK: This dump file will end in FFFF at the end, trim it like the
  • KERNEL dump file. It will end up being between 700KB and 1.5MB in size.
  • DRM: This dump file will end in FFFF at the end, trim it like the KERNEL dump file. It should end up being around 2000KB in size.

Note: The BOOTSTRAP must be taken from the appropriate type of SHX file. It cannot be obtained by a memory dump.

Now rename all the files for their appropriate bin number, include the appropriate LST file, reconfigure the header with file length and checksum info, compile it with RandomSHX, and you will have a MONSTER SHX backup of your exact phone. LANGPACK SHX and REFLASH SHX can also be made in similar fashion as long as you adhere to the formats specified in this document.

A Note about Triplets
Triplets based phones (V300, V600, etc) can use the P2KMem program to dump their phone memory. It is reported that RAMLDR will only work on R37X based phone models.

MFF Flashing Theory of Operation

  1. The phone is connected to the USB port. This connection is sensed by the hardware.
  2. BIN1 (128KB) is copied to RAM location 0x03FD0000.
  3. The cpu then goes through a "soft reset" The program counter and other registers are reset but the RAM is not flushed. This causes the phone boot off the ROM which automatically runs the RAM program at 0x03FD0000.
  4. The RAM program is the code for the phone transfer the flash data through the USB and write it to the flash chip memory space. This memory space is from 0x10000000 to 0x12000000, it is 32MB large. Various BINs in the SHX file go to specific memory areas in this address space. In general most of the FLASH memory is used.

The FLASH loading code in RAM is fairly generic among different SHX files of the same phone. The main difference is found in a table of addresses at the beginning of the BIN. This table specifies the address spaces to be flashed. Modifying this table can cause data can be flashed to other locations.

RAMLDR actually does a similar trick to do its memory dumping. When you select the "Send RAMLDR" operation and select the ldr.bin, it copies this small bin file to the same 03FD0000 RAM space and sets the phone to reset and run this new bin. The LDR.BIN is a program that accepts two address ranges over USB and then dumps out the values in memory between those two addresses.

Source(s): SHX File Modding Guide

File Formats and Types

SHX files

An SHX file is used by MFF to upgrade some part of a phones firmware.

There are five known types of SHX files.

  2. LANGPACK SHX – Contains a set of languages and fonts for that language for a phone, allows a phone to quickly change available languages without changing the entire firmware. This does not change the user data, flash, or flex. These contain just BOOTSTRAP and a LANGPACK bin. They are usually about 2MB in size.
  3. REFLASH SHX – This allows a user to upgrade the Flash of the phone without modifying or erasing the user data (FLEX). These contain a BOOTSTRAP, FLASH, DSP, LANGPACK, DRM, and SIGNATURE bin files. They are around 33MB in size.
  4. MONSTERPACK SHX – Similar to the REFLASH SHX in file contents, but also includes a ROM dump of a flex. This is a complete packaging of firmware and will completely erase a users existing data when they flash it. Contains BOOTSTRAP, FLASH, FLEX, DSP, LANGPACK, DRM, and SIGNATURE. These whoppers weigh in around 62MB in size.
  5. FLEXASH SHX – First created by the phone modding community and not Motorola. Made by modifying the HEADER bin and the BOOTSTRAP bin and packaging just the flex part of a monster pack. These files will upgrade just the FLEX of a phone without touching the FLASH. These are around 30MB in size.

SHX General Format
The general format of an SHX file is not in the same format as you would find it in your phone’s memory. The format is roughly as follows.

  • First 8kb are the SHX “header”
    • The first park of the header is always the words “P2K Superfile”
    • Next are some arbitrary version numbers and a date that the file was created.
    • Next is the clause “CSF Protected UNIX Generated Superfile” this is to identify the program typically used to create these SHX files.
    • Next in the Hex range 0x3B0 to 0x600 is the information about the included memory areas of the SHX file. This is where most of your editting will be done. Much more info on in section 3.
    • Next you will find zeros until the actual data starts around 0x2000.
    • The HEADER BIN (bin0) is just the first 8KB of the SHX file.
  • Next is the “data area”
    • Exact format is not known by me, but it is known by others who have successfully created the SHX to BIN programs, like RandomSHX.
    • Different data sections seem to be differentiated by an S#####.
    • Data is stored as a string representing the hex data to be written to the ROM, this is why SHX files are about twice as large as the E398 ROM (64MB vs 32MB). This is because each half a byte is being represented as a full byte character.


The LST file stores the memory addresses where each bin file starts at. It is generated automatically by RandomSHX when you split an SHX apart, and it is required for RandomSHX to put a SHX file together from a group of BIN files.

You can look at an LST file using a simple text editor like Notepad. In fact, by doing this, the following will make much more sense.

In General

  • SHX files of different types will have different LST files.
    • Example: A LANGPACK SHX and REFLASH SHX will have different LST files.
  • A LST file will contain exactly one line for each BIN file it contains.

For the same model phone:

  • SHX files of a similar type will have the same LST files.
    • Example: All LANGPACK SHX for E398 will have the same LST.
    • Example: All MONSTER SHX for V3 will have the same LST.

For different model phones:

  • SHX files of the same type will have different LST files.
    • Example: V620 and E398 LANGPACK SHX files will have different LST files.
  • As an exception to above, V3 and E398 will generally have the same LST.

Warning: A line specifying a BIN with wrong memory address will make the flasher put that BIN’s data in the wrong place on the phone. This results in a dead phone. It is always a good idea to double-check this file right before using RandomSHX to make sure everything in this file is correct.

Bin Files

Bin files are the exact image of what the memory on the phone holds. For the most part they look like random hex at first glance. But someone curious and knowledgeable who has read this guide will see patterns and meaning. RandomSHX can decrypt BIN files from an SHX file and vice-versa.

Here are some general notes on BIN files. Section 3 goes into full detail on each individual type of BIN file.

  • Bin files of similar type (type meaning LANGPACK, BOOTSTRAP, KERNEL, etc), will share patterns. Patterns mean something like a large section of 0000 at the end, or always starting out with “1093 1074”, or always have the phrase “Motorola App Signature” somewhere in the last third of the file. These patterns are how you can verify that the bin file you are looking at is really the type that you think it is.
  • For the most part you will not edit a bin file. These are the result of a compiled machine code and any attempt to directly edit it would most likely result in an unstable crashing phone at best, and a dead phone at worst. Also many parts have a digital signature that becomes invalid if a single bit is changed. If the signature is invalid, then the phone will not run the code, and will erase the offending program.
  • BIN files should not be mixed between phones. There are exceptions however. It seems V3 and E398 can exchange LANG PACK, and FLEX.
  • The one thing important to all bin files is their length. This can be found by going to the end of the bin file and getting the offset of the last byte. This is NOT the end of the file offset, but the last byte, meaning one before the end of the file.
  • The next important thing is the checksum. A checksum is where you take all the bytes and add them all together and you keep the last 4 digits. Later on if you flash the phone, MFF will perform the same check. If its checksum doesn’t match what you tell it that it should be, MFF will report an error. Also the phone’s bootloader will report that the code on the chip is corrupt and refuse to boot.
  • It seems that the different bin files record their checksums differently and I don’t know the algorithms. It seems the key is finding out between what two addresses the checksum is calculated between.

SHX/LST Examples

LANGPACK SHX Organization

  • LANGPACK LST – E398 example
    This file is created by Random's SHX Toolkit
    File: 1
    Addr: 03FD0000
    File: 2
    Addr: 10F40000
BIN0 HEADER 8kb always
BIN1 BOOTSTRAP 128KB always (must be LANGPACK type.)
BIN2 LANGPACK Around 1MB +/- 300KB

REFLASH SHX Organization

  • REFLASH LST – E398 example
    This file is created by Random's SHX Toolkit
    File: 1
    Addr: 03FD0000
    File: 2
    Addr: 10080000
    File: 3
    Addr: 10040000
    File: 4
    Addr: 10F40000
    File: 5
    Addr: 10D00000
    File: 6
    Addr: 11FE0000
BIN0 HEADER 8kb always
BIN1 BOOTSTRAP 128KB always (must be REFLASH type.)
BIN3 DSP around 200KB
BIN4 LANG PACK Around 1MB +/- 300KB
BIN5 DRM around 2MB (must match flash version)
BIN6 SIGNATURE 2KB always (must match flash version)

MONSTER SHX Organization

  • MONSTER LST – E398 example
    This file is created by Random's SHX Toolkit
    File: 1
    Addr: 03FD0000
    File: 2
    Addr: 10080000
    File: 3
    Addr: 11140000
    File: 4
    Addr: 10040000
    File: 5
    Addr: 10F40000
    File: 6
    Addr: 10D00000
    File: 7
    Addr: 11FE0000
BIN0 HEADER 8kb always
BIN1 BOOTSTRAP 128KB always (must be MONSTER type.)
BIN3 FLEX 14.6MB always
BIN4 DSP Around 200KB
BIN5 LANG PACK Around 1MB +/- 300KB
BIN6 DRM Around 2MB (must match flash version)
BIN7 SIGNATURE 2KB always (must match flash version)

BIN File Layouts

Below is a summery of all the BIN files. In each summery is a section about its header, this refers to an offset in the BIN0 file. The BIN0 file is the same as the first 8kb of the SHX file and stores all the information about the bin files included in the SHX package.

In the header descriptions:

  • If the hex numbers are shown as “####”, then you will need to change this to the appropriate value for your specific BIN.
  • If the number is shown as a constant number, then usually you will not need to change this number, and usually by changing it the flash file will fail.

See the attached numbered notes for each offset for more information.

Contrary to previous beliefs, the main phone OS and GUI is NOT programmed in JAVA. JAVA requires special class files with the identifying "magic" 0xCAFEBABE double word found near the beginning of all class files. This 0xCAFEBABE only occurs at one place in the kernel, in a function that loads JAVA code and starts the JAVAVM. It is found here because this function checks the 0xCAFEBABE value for itself.

The kernel seems to be coded in C++ which is then compiled into ARM machine code.

Investigation seems to show the Neptune LTE Boot ROM is identical for every phone using this chip. This in turn always puts the phone kernel in flash always at 0x10080000. This Boot ROM seems to be done in simple ARM assembly. Other areas may utilize the THUMB instruction set as well for increased code density and efficiency.


This is always BIN0 with RandomSHX. This is simply the first 8KB of the SHX file. It contains information about the SHX file, and information about all the BIN files it contains. This is the file you will usually modify extensively when modding SHX files.


This BIN holds the BOOTSTRAP program for upgrading the firmware on the phone. Contrary to prior naming, this is NOT the bootloader. This BIN is copied directly to the RAM on the Neptune LTE, then the Neptune is set to run the program in RAM. This RAM program communicates with USB and downloads chunks of the firmware upgrade to RAM, then writes these chunks to FLASH. This is always BIN1 with RandomSHX.

BIN Structure Notes
This file is in ARM machine code format. There are many tutorials, data sheets, and utilities for working with ARM code.

The beginning of the BIN holds a data table. If you look closely at this table you will see the memory spaces for the BINs in the SHX file. This table can be modified to create the different kinds of SHX bootstraps. Usually it is easier and safer to take an existing BOOTSTRAP from other similar kind of SHX file.

The last 2KB block begins with a digital signature. If you attempt to modify the BIN in anyway, this signature will become invalid and the phone will not run the BOOTSTRAP anymore. It is similar to the SIGNATURE BIN in operation, but different in format. It is unknown outside of Motorola how to generate these signatures, and most likely too complicated to ever figure out.

SHX Creation Notes
You must use a BOOTSTRAP from the same model phone, and from the same type of SHX file. All BOOTSTRAP BINs are identical among the same model phone and the same SHX type however.

Memory Space
The BOOTSTRAP is copied directly to RAM at 0x03FD0000. After the flashing operation it is erased on booting the phone. It cannot be dumped back off the phone.

Always 128KB

Header format for BOOTSTRAP BIN

0x3B0] 0800 0000 0000 FD03 F7FF FE03 03FE F800 B172 19E9 000C 0203 0100
       (1)  (2)       (3)       (4)  (5)                 (6)       (7)
       07E0 ####
       (8)  (9)

      (1) – This is the number of BIN files in the SHX file. This will be 0800 for a MONSTER SHX, 0700 for a REFLASH SHX, etc.
      (2) – This is always 0000.
      (3) – This is the offset of the last byte in the bin in backwards endian format.
      (4) – This is the ending address in RAM in backwards endian format.
      (5) – This is the address in RAM
      (6) – These bits are found a lot in the header, may be related to hardware.
      (7) – This is sometimes 0200. Not sure why, I couldn’t find any correlations
      (8) – This is the version of the bootloader, some flashing programs will not flash a software unless it is the same bootloader or higher.
      (9) – Checksum, unknown algorithm (8DCC for 98R and 99R reflash files)


This section holds the kernel OS of the phone. There is a large header with lots of information. If you try to modify this BIN the security signature will become invalid and phone will not boot and erase itself.

SHX Creation Notes
The kernel is very hardware specific and cannot be interchanged between phone models. If you do, then the phone will most likely become an irrecoverable paperweight. Different kernels will contain hardware driver code for newer features.

Memory Space
10080000 to 10D00000

Around 10MB to 11MB

Header Format for KERNEL BIN

0x3EE] 0810 C700 0810 #### #### 0000 00B1 000C 0206 FFFF 0E20 E88F 0200 C800
       (1)  (2)  (3)  (4)  (5)  (6)       (7)            (8)  (9)  (10)
       0810 #### BE10 #### #### 0000 00B1 010C 0206 FFFF 0E20 ####
       (11) (12) (13) (14) (15) (16)      (17)           (18) (19)

    (1) – This is the KERNEL’s starting address in ROM in backwards endian.
    (2) – This a small length, its always the same
    (3) – This is the KERNEL’s ending address in ROM in backwards endian, these three words above seem to suggest that the first section of the flash is separate from the rest. Why this is the case is unknown.
    (4) - This is the first word in the KERNEL bin file.
    (5) - This is the second word in the KERNEL bin file.
    (6) - These two words keep showing up 0000 001B.
    (7) - These three words also keep showing up 000C 0206 FFFF, may be hardware related or specify options on how to flash the bin.
    (8) - 0E20 – You will recognize this from a part in the file name, this specifies what hardware this KERNEL is for. (0E20 is for E398, 0E40 is V3)
    (9) - E88F – A checksum of sorts, but it is always the same value no matter what.
    (10) - This looks like a repeat of the first three words except the first word is 0200 and the second is C800 instead of C700.
    (11) – This is first two bytes the KERNEL’s starting address in ROM in backwards endian. (10080000)
    (12) – This is the offset of the last byte in the bin in backwards endian. So if the last byte is at address 0x01F0BC42, then this value is “42BC”
    (13) – This is the first two bytes of the KERNEL’s ending address in ROM in backwards endian. (10BE0000)
    (14) – This is the first word in the KERNEL bin file. (same as 4)
    (15) – This is the second word in the KERNEL bin file (same as 5)
    (16) – These two words keep showing up 0000 001B, they may be related to how the BIN file is to be flashed.
    (17) – These three words also keep showing up.
    (18) – 0E20 – Specifies the hardware this KERNEL is for.
    (19) – Checksum, algorithm unknown.


This section holds the Flex, the flex contains the file system and the seems. Everything customizable on the phone, from the Phonebook to Themes to Ring tones, is found in the FLEX.

BIN Structure Notes
There appears to be two copies of the seems, one near the beginning, one near the end. You can do a search in the BIN for a 5-6 byte long pattern that is found in a seem of interest to find the location of that seem in the flex.

Files are dispersed throughout. If you look carefully you can find the file name strings. They are divided into 1KB chunks with small headers in-between.

Empty space is denoted by large areas of FFFF.

SHX Creation Notes
In general flexes can be mixed and matched with little worry, some are better than others, and some don’t enable all functionality that a flash provides. By dumping the FLEX memory space on your phone and incorporating it into an SHX file, you can make an effective “backup” of your exact phone customization.

Memory Space
11140000 – 11FE0000

The flex bin is always 14.6MB, any space not utilized by files or seems is the free space for the phone’s user.

Header Format for FLEX BIN

       (1)       (2)  (3)                                     (4)  (5)

    (1) - This is the first two bytes of the starting address in ROM in backwards endian.
    (2) – This is the first two bytes of the ending address in ROM in backwards ending.
    (3) – 8 words of FFFF
    (4) – Checksum, standard checksum16 algorithm over the entire bin, bytes reversed.
    (5) – Always 0800


This section holds the DSP code. DSP stands for digital signal processor. The DSP is synthesized in the Neptune chip and is similar to the Motorola “Onyx” 56300. It functions as a coprocessor to the ARM for intense arithmetic operations and signal processing. Many DSP chips are programmed to do compression as well as multimedia codec encoding and decoding. You can check what version you have on your phone in the “Other Information” menu.

BIN Structure Notes
This BIN is machine code. The DSP is coded in the assembly language for the Motorola “Onyx” family of DSP processors. Documentation about this language is freely available from Motorola and FreeScale Semiconductor.

SHX Creation Notes
Many firmware versions of the same phone have the same DSP BIN, and you can generally mix and match them as you please as long as you stay in the same phone model.

Memory Space
10040000 - 10080000

Around 200KB

Header Format for DSP BIN

0x442] 0410 #### 0710 #### #### 0000 00B1 010C 0206 FFFF 0E20 ####
       (1)  (2)  (3)  (4)  (5)  (6)        (7)           (8) (9)

    (1) - This is the first two bytes of the starting address in backwards endian.
    (2) - This is the offset of the last byte in backwards endian. So if the last byte is at address 0x01F0BC42, then this value is “42BC”
    (3) - This is the first two bytes of the ending address in backwards endian.
    (4) – This is the first word of the bin file.
    (5) – This is the second word of the bin file.
    (6) – Sequence that shows up a lot 0000 001B
    (7) – These bytes show up a lot too 010C 0206 FFFF
    (8) – 0E20 this is just like the file name for the SHX file, this specifies what hardware this works on.
    (9) - Checksum, unknown algorithm.

Lang Pack BIN

Motorola designs their firmware to easily allow language and culture customizations to be integrated into a central section of the FLASH. This allows the phone to be easily changeable to be used in different parts of the world without developing a separate OS. This memory section holds the languages and the fonts for those languages. These are the heart of the LANGPACK SHX file.

BIN Structure Notes
Little is known about this BIN’s structure.

SHX Creation Notes
You are free to combine any LANGPACK BIN of a certain phone that you want with your SHX file. Traditionally LANGPACK 0003 is included with REFLASH files. Asian, Middle Eastern, or Cyrillic characters may not be displayable if a FLEX includes text with these charectors, but the appropriate language pack is missing.

Memory Space
10F40000 to 11140000

They range in sizes from 700kb (lang pack 0003) to 1.2MB (lang pack 0015)

Header Format for LANGPACK BIN

0x45E] F410 #### FF10 10F4 0010 0000 00B1 010C 0206 FFFF 0E20 ####
       (1)  (2)  (3)  (4)       (5)       (6)            (7)  (8)

    (1) – This is the first two bytes of the starting address in backwards endian.
    (2) - This is the offset of the last byte in backwards endian. So if the last byte is at address 0x01F0BC42, then this value is “42BC”
    (3) This is the first two bytes of the ending address in backwards endian. This can change between short language packs (like 0003) and longer language packs (like 0015), when in doubt, look at an official language pack of that version and see what value is here.
    (4) Address in forward endian
    (5) Sequence that shows up a lot 0000 001B
    (6) These bytes show up a lot too 010C 0206 FFFF
    (7) 0E20 this is just like the file name for the shx file, this specifies what hardware this works on.
    (8) Checksum, unknown algorithm.


Holds the media used directly by the kernel. Most E398 firmware versions list this as DRM0001 and are identical except for one part where a text string of the flash is. Since the flash differs in different SHX files, then this text string can differ. Also DRM0003 exists and is much smaller (about 500kb smaller). It was found with 96R_A.

The DRM is like a resource space for the flash. If you are familiar with Visual C++ programming, it is just like specifying a resource file with sounds, and pictures to be built in to the executable. Among other things included in this are a multitude of GIF files.

BIN Structure Notes
This BIN file contains many media files, including GIF pictures. These can be explored by searching for the “Gif89a” text that marks the beginning of each GIF file. You can simply copy out the code between “Gif89a” (include the first Gif89a text however), and dump it to a file to extract each GIF. You could also replace the GIF inside as long as it is exactly the same size, or it is smaller and you fill the remaining space with dummy data.

Other sound media seems to be in a raw format similar to WAV.

SHX Creation Notes
In general, if you found a certain DRM version with a flash, then you need to keep it together because a text string inside the BIN specifies it to that flash.

Memory Space
10D00000 to 10F00000

Usually around 2000KB, a DRM0003 type file is much smaller, by 500KB.

Header Format for DRM BIN

0x592] D010 #### EF10 0000 0000 0000 0000 10D0 001C 0000 001B ####
       (1)  (2)  (3)  (4)                 (5)       (6)       (7)

        (1) – This is the first two bytes of the starting address in backwards endian.
        (2) – This is the offset of the last byte in backwards endian. So if the last byte is at address 0x01F0BC42, then this value is “42BC”
        (3) – This is the first two bytes of the ending address in backwards endian.
        (4) – Four words of 0000
        (5) – Address in forward endian format
        (6) – Sequence that shows up a lot 0000 001B
        (7) – Checksum, unknown algorithm.

Signature BIN

The "Signature" BIN is the last thing in FLASH. It serves as a digital signature to guarantee code authenticity from Motorola and safeguard against hackers, and code corruption.

BIN Structure Notes
Data fills the first 1110 bytes, with the rest of the bytes at value 0xFF to fill up 2KB in total.

  • The first 16 bytes serve as an identification header.
  • For each model phone, all data up in address [0x11FE0000-0x11FE03D7] is identical.
  • After this address is 128bytes (1024bits) of seemingly random bytes that is different for each flash version.
    • This could be a 1024 bit RSA Key.
    • Or it could be related to a SHA-1 HASH of the Kernel.
    • Or it could be some unknown proprietary algorithm to check the flash code for tampering.

What is known is that the Neptune LTE contains a security chip that somehow hashes the flash kernel code to come up with a value. This value is compared to the signature on phone bootup. If they do not match, then the phone will not boot, and parts of the FLASH chip are erased.

SHX Creation Guidlines
The signature is kernel specific. For example, when creating REFLASH or MONSTER SHX files, be sure to match a 98R signature BIN to a 98R kernel BIN. To this day it is not known how to properly edit this file or generate new signatures. It is not likely to ever figure out the algorithm either since it was designed to be complicated and secure.

Memory Space
11FE0000 to 11FE0800

Always 2KB

Header Format for SIGNATURE BIN

       (1)  (2)  (3)  (4)                                     (5)  (6)

       (1) - FE11 – This is the first two bytes of the starting address in backwards endian.
       (2) – FF07 – This is the offset of the last byte in backwards endian, means to 07FF.
       (3) – FE11 – This is the first two bytes of the ending address, in this case it is the same as the starting address because the signature is so small.
       (4) – 8 words of FFFF
       (5) – Checksum – This is found by flipping the endian of the file (good hex editors can do this) and then generate a 16 bit checksum. (0B86 for 98R) (0183 for 99R)
       (6) – This is the length of the BIN.



Many times you can get the correct checksum value by looking at the SHX header of the file where the BIN file originally came from. This original header will contain the correct checksum value for the BIN, as long as you did not directly edit the contents of the BIN.

If you cannot get the original header, or one doesn’t exist, the checksums can be found by running a Checksum16 algorithm on the data between certain memory ranges in the BIN files. For the flex this is especially easy, just run a Checksum16 algorithm over the entire file. Good hex editors, like Hex Workshop, will contain the functionality to run these kinds of checksum operations on files, or sections of files.

In general, the exact memory ranges for many of the BIN files are not known. In this case you must use the alternate checksum finding method in section 4.2. When you enter the checksum value into the header, the bytes are reversed. For example, if the checksum of the file is “2A67”, then the checksum word to put in the header is “672A”.


If you are unable to determine a checksum by looking at the original headers, or calculating it on your own, here is another way. This method was first documented by fboesh.

  1. First use RandomSHX to create the SHX file with the wrong checksum values.
  2. Now use MFF and attempt to flash this SHX file to the phone. The file will flash, but at the end MFF will report a checksum error. At this point do not close the program or pull the cable!
  3. Go to the directory where the SHX file lies and open up the .log file found there. Inside it will report the checksum errors for each numbered bin.
  4. For each bin with a bad checksum there will be a line saying “File: XXXX Phone: XXXX” where XXXX are hex values. Write all these down.
  5. Now go back to your header file to the location of the bad checksum values. The values should read the same value reported next to the “File: XXXX” part in the error log. Verify this.
  6. Now change this value to the “Phone: XXXX” value.
  7. Repeat for all the bad checksum values, save the header.
  8. Recompile the SHX with the new header and everything should now work.

Phone Hardware

About the Neptune Chip

The CPU is a Motorola proprietary part, the Neptune LTE. This is an upgraded version of the Neptune LTS to include EDGE capability. The Neptune LTS is in turn an upgrade to the Neptune LT chip with enhancements for use in cellular technology. The Neptune LTE is a complex core with many different parts synthesized onto one chip. (Triplets phones are actually based on the Neptune LTS)

First is an ARM7TDMI synthesizable CPU built into the chip. There is a built in ROM (0x00000000) and RAM (0x03FC0000) for the ARM7.

There is a Motorola DSP based on the Motorola Onyx 56300. There is a memory controller for mapping the FLASH chip to I/O (0x10000000-0x12000000). There is hardware to interface with the SIM, USB, Bluetooth, Video, Transmitter and Receiver RF paths. There is also a great deal of traffic between this chip and the PCAP chip that contains the power management and audio functions.

There is also a built in security chip that will not run any code that is not digitally signed by Motorola, the signatures are different for each phone model, and part of the signature is calculated from a CRC-like algorithm. These signatures are found at various parts of the FLASH ROM and the RAM flash loader.

Memory System

There are four main "chips" of memory for the phone.

  • CPU ROM - This is synthesized on the Neptune LTE. It is 1120KB in size. It is mapped to 0x00000000. It is permanently burned to the Neptune LTE (i.e. it is never updatable) and survives regardless of battery power. This is a basic program that initializes the CPU registers, and initializes all other hardware on the Neptune to prepare the chip for running a program. Finally looks in RAM for a program to run. If a program was previously loaded and the CPU was hot-reset, then a program will still exist here and this program will be run. If not, then the ROM will copy the bootloader from FLASH at 0x10000000 to RAM at 0x03FD0000 and then this program will run and normally boot the phone.
  • CPU RAM - Discussed a bit in the previous paragraph. This is main program workspace for the CPU. It is 256KB in size on the LTE (some versions have 512KB). Data can easily be read or written to in this memory. This memory is also very fast. However when the phone powers down or loses battery, this memory loses all data. This is called a "Cold" or "Hard" reset.
  • FLASH - This is a chip separate from the Neptune LTE. It is 32MB in size. It is mapped from [0x10000000-0x12000000]. This is generally thought of as a ROM.

Usually data is read from FLASH and copied to RAM if it is to be modified. However FLASH ROM is special in that it can be written by putting the chip into a special "Write mode". A Flash can only survive a limited number of writes, usually around 100,000. This write ability allows the phone to have "upgradeable firmware". All the firmware is stored on this chip, kernel, flex, dsp, lang pack, etc. Data survives on this chip regardless of battery power. Data reading from FLASH is much slower than RAM, and writing to FLASH very much slower then that.

  • T-FLASH - Many Motorola phones have the capability to use an add-on T-FLASH memory chip up to 256MB. This memory is an oddball of sorts. It is not directly interfaced to the Neptune, nor directly mapped to memory. It is attached to the chip the operates the camera, and communicates with the Neptune via special commands in that chip. However it is removable, and can be very large in capacity. Reading and writing to this chip are slower then even the Neptune's mapped FLASH. This is the memory that is used when the phone is put into the "Removable Storage" mode. Data survives on this chip regardless of battery power.

Note: Plans are to release T-FLASH chips of higher capacity. Rumors of 512MB and 1GB being available soon have surfaced. Regardless of the appearance of these chips, there is evidence to show that the phone will not be able to address more than 256MB with its current hardware interface.

Example E398 Memory Map

Mem Space   Description         Size (Hex)       Size (Kb/MB)
0x00000000 Neptune ROM          0x001C0000       1120KB
0x001C0000 0xFFFF
[LTS - 3168KB LTE - 1792KB]
0x03FC0000 Neptune RAM??       0x40000          256KB
[LTS - 436KB LTE - 256KB (EDGE) or 512KB (GPRS)]
0x03FC0000 (MASK) 32MB offset,
     start at the bottom of the next 32MB chunk, up 256KB.
0x03FC0000 ????                0x00010000         64KB
0x03FD0000 BootProgram         0x00020000        128KB
0x03FF0000 ????                0x00010000         64KB
0x10000000 Flash ROM           0x02000000       32MB
0x10000000 Bootloader          0xF000           60KB
0x1000F000 Data Offsets??      0x1000            4KB
0x10010000 inside F000-F0F0,rest=0xFFFF
0x10010000 PDS???              0x10000          64KB
0x10020000 (data)???           0x20000          128KB
0x10040000 29420-40000=FFFF
0x10040000 DSP CODE            0x40000          256KB
0x10080000 KERNEL OS           0xC80000         12.5MB
0x10D00000 DRM                 0x200000         2MB
0x10F00000 (media)
0x10F00000 0xFFFF              0x40000          256KB
0x10F40000 LANG PACK           0x200000         2MB
0x11140000 FLEX                0xEA0000         14.625MB
0x11FE0000 (file system)
0x11FE0000 Signature           0x800            2KB
0x11FE0800 0xFFFF              0x1F800          126KB

I can confirm from my own e378i that the ROM layout given above also applies to phones with software labled r3722 (in addition to the r372 of the e398). If you wish to dump a r3722 phone, use flashbackup with 32mb memory size and "additional loader for 32mb" and you will get a usable backup. You can also use "create flash file" with the e398 setting to get an shx out of your phone. WARNING: I have not tested actually loading anything back onto the phone.



Once you fix your header to the correct values, and collect all the appropriate BIN files, you can then recompile a SHX file with Random SHX. After this you will have a working SHX file if you did everything right. Here are some recommendations if you choose to make public releases of your work.

  • Use file names with the same format as other file of the same type. Don’t just make the SHX file “MyGermanSHX.shx.” It will still work, but it is much more useful to include the official file name. This official file name includes information about what phone it works on, what flash it came from, the number of the lang pack, etc.
  • Put a phrase at the end so people will know this is an artificial firmware, not and official one. I always put “EYEZHACKED” at the end of my file names. This also will help you keep track of what is official and what is artificial. Also this helps give you credit for your work, and lets everyone know who to blame if it doesn’t work.
  • If you release an SHX file, you have an inherent responsibility for your release. Expect individuals with little or no modding experience to download and use your file. This means your file needs to be well-tested, and as fool-proof as possible. Include good directions, explanations, support, etc.
  • If you discover something new, it is proper to publish the details of your discovery as soon as you can. By sharing information, others can quickly build upon your knowledge and new discoveries can be made. Unfortunately there are many who like to keep knowledge to themselves or even try to profit from it. Always remember you are standing on the shoulders of the freely published information you learned from.



  • Mix and match language packs, flashes, and flexes of a certain phone to create new monster packs.
  • Extract LANGPACK bin out of a REFLASH SHX or MONSTER SHX and create a new LANGPACK SHX.
  • Extract the LANGPACK memory space out of an E398 and create a new LANGPACK SHX file that will work on any E398.
  • Create new reflashes, monster packs, and langpacks based on the data dumps from a phone.
  • Create a complete single flash phone backup.


  • You can’t mix and match part of a single BIN. You can’t combine the Chinese part of one language pack into the German part of another.
  • You can’t extract features out of a flash and put it into another, IE you can’t take video recording out of a V3 or V620 flash and put it into a E398 flash.
  • You can’t mix BIN files from different phones. The files must fit the same size and format requirements, and even if they do the hardware on the other phone will probably be too different for the phone to even boot up after the flash.
  • Take a BIN file and convert it to an HS file directly. You can flash the flex bin to the phone, and then use a program like Motokit to create a flex from the files on the phone. (This is an indirect way to accomplish the same thing)
  • You cannot modify the KERNEL BIN. If you change even a single bit, the digital signature BIN becomes invalid. Not only will the phone refuse to boot after this, but it will also erase the offending program from flash memory.
  • Related to above, but you cannot generate new signatures for modified KERNEL BIN. (It’s too bad, because this is the only thing standing in the way of Video Recording on an E398. (I’ve figured out the necessary changes to add the feature, but without a proper signature, the phone erases out the hacked KERNEL.))

End of Eyesonly_d’s SHX File Modding Guide Jasa SEO Jasa SEO Murah Jasa SEO Murah Jasa SEO Jasa Google Adwords Jasa Adwords Google Adwords Sepatu Online Toko Sepatu Online Sepatu Sepatu Murah Sepatu Safety Sepatu Futsal Cheapes Hostgator Coupon Link Booking Televisori offerte Notebook Offerte Berita Terkini Internet Marketer Muda Internet Marketer Indonesia Portatile Apple RDAnet Lorks Karikatur Bisnis Modal Kecil Bisnis UKM Berita Terbaru Iklan Baris Jasa SEO Jasa SEO Murah SEO Indonesia Konsultan SEO SEO Belajar SEO Kursus SEO Kursus SEO Murah Jam Tangan Casio Jam Tangan Casio Jam Tangan Murah Jam Tangan Grosir Baju Terbaru Grosir Baju Baju Terbaru Grosir Baju Murah Bisnis Online Belajar SEO Kerupuk Kerupuk kulit Social Bookmark Dofollow Social Bookmark Kumpulan Puisi Kirim Puisi Penumbuh Rambut Penumbuh Rambut timbangan WBC Wonogiri Jasa SEO Murah Jasa SEO Jam Tangan Murah Jam Tangan Murah

Cupu Berita Terbaru Android Store Upinson Berita Terkini Edo Ziedo Aplikasi Symbian Sepatu Safety Upin Upin Tablet Android Sepatu Murah Upinson Blogger Radio Streaming SEO Star Upinson Cinta EDU Jasa SEO Sepatu Murah Sepatu Murah Sepatu Murah Penumbuh Rambut Penumbuh Rambut Penumbuh Rambut Penumbuh Rambut Penumbuh Rambut Penumbuh Rambut Penumbuh Rambut

Personal tools