Firmware 'hacking'

prongs_386

My first question is, has anyone here attempted to decode the hex in the firmware into asm? If so, is there information provided on the process of conversion...

If not my second question is, does anyone know what the processor architecture in the meizu m6 is?

With that information I should be able to start manually disassembling it.

member

I don't think anyone has tried it. I imagine it's not at all easy, as it's an ARM9 architecture:

Rockbox - CLOSED

I think there's only one free ARM disassembler, at version 0.1 .

prongs_386

ok, i've looked into it a bit more.
Bassically the only information I can get is that its a 32 bit load store RISC architecture with 16 registers. I've got a list of assembly instructions supported under arm, but no info on the structure of the bit paterns... might have to assume things such as a 6 bit opcode with opcode extension..
Any ideas?

b-w-d

Ive had a look at the .EBN files in the past. I have not tried to decompile it & honestly I have limited working experience with asm, but I have run it through a hexeditor and come up with the following:

From address 2000 you will notice that the file is infact.. thats right, a RAR archive (note the infamous "Rar!" header data there). I havent quite got the rar extraction down perfectly.. but extracting the data from this point onwards to a .rar file does provide access to \Source\Blues_Dual_Lib_Data\SDRAM_SAMSUNG_DUAL\SDR AM_image.bin. This procedure is far from perfect though, as WinRAR kept reminding me this results in a rar file with a partially corrupted header, I assume since there is additional data appended after the end of the rar archive.

Opening this SDRAM_image.bin in a hexeditor shows a trend between this file and the original .EBN file. Both contain a large section of header data which includes "CUFD", so I am inclined to believe this is header data for executable code for this platform. .EBN then holds a means of extracting the .rar file (which holds more interesting data) into the correct area of the M6.

In this file there are references to DokDoFS and a lot of suprious english text regarding USB connection/disconnection, audio codec errors and so forth. I also noticed a few file paths here and there (e.g. \SYSTEM\SYS_MUSICBG.DAT) which appear to be in 16bit unicode format (ASCII chars with leading 00s). There is also some text saying "Usb type is USB_HOST", which looks hopeful for later releases

Theres even references to assertions & semaphores in what looks like more extensive debugging text. Relatively high level concepts for such a dinky little embedded device.

Other text of interest:

• "no camera" (seems to be some generic blocks of code?)
• "file not seekable" (file IO is obviously available here)
• "D:\8700\Blues_SDK\Source\APP\WMALSL\WMALSL_Lib\ms audiocodec.c" (in ASCII, there are actually quite a few of these references to c files) .. the WMA codec perhaps? I think so!
• "D:\8700\Blues_SDK\Source\DEVICES\JANUS\JanusDRM\k div.c" - intriguing
• "Microsoft Corporation" (making its rounds)
• "FCLK_CPU = %d Mhz", "FCLK_DSP", "HCLK", "PCLK", "MCLK" some interesting text for speed outputs, most notably CPU & digital signal processor
• An extensive XML sample for Microsoft DRM certificates
• "M6.EBN" and "RESOURCE.BIN" (16bit unicode) - a couple of references each
• "\SYSTEM\SETTINGS.DAT" (16bit unicode)
• "FAT32" "FAT16"
• "D:\8700\Blues_SDK\Source\FileSystem\Whimory_v2.1. 2_P02\Core\FTL\FTLInterface.c"
• "Is the volatile memory being used for code execution? -.-;; Internal SRAM is too small to contain all code images! I made a constraint that the code size on iSRAM should be less than 128KB" <-- note the use of japanese emoticons ^_^ hehe
• "S5L8700 uCOSII with DOkdo FS 2007.02.05(3.44)" see line 13C00

So, what have we learnt from this?

• There are references to uCosII (Also see my post here: http://www.meizume.com/showpost.php?...1&postcount=33 )
• Some parts of the code seem rather generic, such as the references to cameras and USB host (which is still not implemented fully in our latest releases).
• The reason why firmware updates take a while is simply because the data needs unpacking from a RAR before writing to non-volatile memory.
• Now what id really be interested to know is whether the SDRAM_image is the entire firmware, or just an OS for the firmware with an API and hooks?
• Comments and debugging text are not removed from compiled code for releases
• It is quite possible that the developers have a software emulator (re: use of assertions, which should ALWAYS be removed from public releases)
• I crave access to this "Blue SDK"

This little rundown was done against "M6 S2.003.2-3" from this forum

b-w-d

I think this may also be relevant (only available via google cache, the actual forum is down right now): http://216.239.59.104/search?q=cache...lnk&cd=1&gl=uk

We should try and get someone here to translate it for us

audiofish

you can sortof understand what's being said with google translate:
http://google.com/translate?u=http%3A%2F%2F216.239.59.104%2Fsearch%3 Fq%3Dcache%3ASLzJVxbNTtUJ%3Awww.qrme.net%2Farchive r%2Ftid-1755.html%2B%2522DokDo%2BFS%2522%26hl%3Den%26ct%3D clnk%26cd%3D1%26gl%3Duk&langpair=zh%7Cen&hl=en&ie= UTF8

__________________
~audiofish~

member

Wow. That analysis done by b-w-d was way more than i thought was possible starting cold! An embedded RAR file... who'd have thought it?

It's interesting that those embedded comments are in english - maybe one of the developers is a native English speaker. I wonder if there are Chinese comments too, hidden away in UTF-16 encoding. Someone who speaks Chinese would have a look at it maybe? Iversonjack?

So it sounds like someone in Russia is working on a Linux port to Meizu? That would be colossal. It would probably carry forward to the M8 (which is an ARM11 I believe).

Erwin

Would be great if rockbox could work on the meizu M6

Beathan

Hello to everyone, I am for the first time writting a post, so quick enough:
I tried to contact with Czech's group doing translations for M6, and NO RESPONSE at all. That would mean they have got an agreement with original developers (Meizu Team) not to share any knowledge.
I asked them just for my freelance support, as a person experienced with software localizing (translation to native Polish version).
I tried to see if a BIN file could have just strings of menus and options inside, to re-compile changing for examples strings without cutting or prolonging their lenghts, but I noticed there are only a few comments (or did not pass it trough exact enough
Can anyone tried to do such attempt?

Regards,
Beathan

vcf

guys!i amporting rockbox to meizu m6.if anyone understands (ARM) assembly language then you may help us if you dissembly this binary(its a decryption of original frimware) and find out more about the hardware of player
thanks

roelandb

there is a special page for meizu m6 over at the rockbox website, there is some information about the hardware components used in the m6, i hope you can make rockbox work on the m6 becouse that would be really great for a lot of people!!

vcf

roelandb i know that there is such a topic.you see to port rockbox to m6 we need not just many people who WANTS it we need many people who WANTS and is able to help with porting.because we need testing hadwsre and so one.....hope you will carry it to meizu users.
luck

roelandb

if i knew how to make rockbox work i would certainly do it,

perhaps it would be a good idea to set up a donation fund and donate a meizu m6 to one of the rockbox developers, so they can experiment with it?

vcf

its a good idea.i dont exactly know how to port rockbox but i have the desire to do it.ofcourse i know how to port rockbox but not excatly.that is the most important thing(about the desire)that is the most important thing.