yes, thnx a lot for this doc. since we know the instruction code set we are able to investigate the firmware files (RFW) to find out where code gets stored and which format gets used to separate between different apps. because the image data get's stored unencrypted directly inside the file (that's why dancemammals editor works) i don't think the code get's encrypted in any way. the update tool directly writes this data to the flash chip, page by page. when you have a quick look at the RFW header, you are able to extract the following content (from file "RockChip_firmware_(PowerPack).zip"):
Code:
id: ROCK260x
year: 2005
version: VER5.00
name: Rockchip
block 00: fofs=00000690, size=00000F54, attr=00000000
block 01: fofs=000015E4, size=0000FC70, attr=00000000
block 02: fofs=00011254, size=00002D82, attr=00000000
block 03: fofs=00011254, size=00002D82, attr=00000000
block 04: fofs=00013FD6, size=00009618, attr=00007900
block 05: fofs=0001D5EE, size=00005F0C, attr=00006506
block 06: fofs=000234FA, size=00008B76, attr=00001700
block 07: fofs=0002C070, size=0000AFBE, attr=00007900
block 08: fofs=0003702E, size=00008A24, attr=00001700
block 09: fofs=0003FA52, size=0000907E, attr=00006300
block 10: fofs=00048AD0, size=00003816, attr=00007900
block 11: fofs=0004C2E6, size=00000756, attr=00006C00
block 12: fofs=0004CA3C, size=000086AA, attr=00001700
block 13: fofs=000550E6, size=00008392, attr=00007900
block 14: fofs=0005D478, size=00000FEA, attr=00009D00
block 15: fofs=0005E462, size=00010278, attr=00001700
block 16: fofs=0006E6DA, size=000038BE, attr=00001C5F
block 17: fofs=00071F98, size=00001B9C, attr=00000DCE
block 18: fofs=00073B34, size=0000255C, attr=000012AE
block 19: fofs=00076090, size=000041EC, attr=00007900
block 20: fofs=0007A27C, size=0000203C, attr=00001700
block 21: fofs=0007C2B8, size=0000F864, attr=00002B00
block 22: fofs=0008BB1C, size=00000000, attr=0000B100
block 25: fofs=0008BB1C, size=0000178A, attr=0000C300
block 27: fofs=0008D2A6, size=00000820, attr=0000B000
block 28: fofs=0008DAC6, size=0000759C, attr=00007900
block 29: fofs=00095062, size=00002D2A, attr=00001700
block 30: fofs=00097D8C, size=00002EE8, attr=00008000
block 31: fofs=0009AC74, size=00001FF8, attr=00007900
block 32: fofs=0009CC6C, size=0000003C, attr=000060D0
block 33: fofs=0009CCA8, size=0000607C, attr=00001700
block 34: fofs=000A2D24, size=00001F06, attr=0000C300
block 37: fofs=000A4C2A, size=00001620, attr=0000C300
block 38: fofs=000A624A, size=00000702, attr=0000B000
block 61: fofs=000A694C, size=00210CB2, attr=00000000
block 62: fofs=002B75FE, size=000C0000, attr=00800000
block 63: fofs=003775FE, size=0004D1BE, attr=282779CB
block 64: fofs=003C47BC, size=006417DC, attr=6FAEFFB2
block 01 (or file 01) get's written to the flash chip directly on every upload. blocks of greater numbers too, but to different places. the last block contains all image ressources. maybe the attribute 6FAEFFB2 is uniqe for ressource data. to be sure on that i have to test this against all other firmware files first. possibly one block contains the bootloader ROM for the RK chip. this one should be detectable, because it directly starts with a JMP instruction in 99% of all cases and it may be of fixed size for all firmwares (how large is the ROM?).
the RFW file header structure i used to retrieve this informations:
Code:
typedef struct {
unsigned __int32 flag;
unsigned __int32 fofs;
unsigned __int32 size;
unsigned __int32 unkwn;
} RFW_HEADER_ENTRY;
typedef struct {
char id[8]; //"ROCK260x"
char year[4]; //eg. "2005"
char ver[7]; //eg. "VER5.00"
unsigned __int8 unkwn0013[12];
char name[17];
unsigned __int8 unkwn0030[0x250];
RFW_HEADER_ENTRY entry[65];
} RFW_HEADER;
any more details about the unkwn0013/0030 fields are appreciated.
does the game-disassembler reads any special application-header, or in other words: do we have more informations how application code get's stored?
