• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

[ROM] [Stock] C811 M070 firmware ZIP file (4.1.2)

ad_rai said:
These files came from http://ncmc-eut.necam.com/ server when it was alive, which is not available anymore. On C811 image there is an EUT tool to reflash firmware, I extracted URLs and methods to access that server and fetched the file. So the modem image here is designed to have US 700MHz band (forgot the exact number).

Although the original file extension is ".mbn", it is XOR encrypted and uses some custom header structure. I will post the raw files and header decoder soon.

Do not complain me about modemst and other missing contents, as they were not there from the first place. I used CWM recovery to flash these to my CA-201L and never bricked my phone beyond recovery failure.

Moreover, I don't have access to my CA-201L right now so no further experiments are possible at the moment.
Click to expand...
Very Very Interesting! And Big thanks for the description!
What the FW version here? M070? It would be helpful for all who will DL this FW.
Tp be correct I still don't definitely know which version is for which device. M020 M040 M050 M070, 410, 470... :) There is also pure japanse version FYI which is not an C811 nor CA-21L, already forgot the name. :)

Please note I can't install and check I don't have the device on my hands and never had.
Some ppl online asked me to help w/it.

I've explore you mbn and images and it seems they are plain w/no any xoring excluding GPT files
It seems I've already found your xor tool
https://blog.peremen.name/entry/extracting-gzone-eut/
Curiously this tool doesn't contain GPT Keys
I can tell you key for the gpt_main0.bin right now
gpt_main0.bin Key is 136EF083 (don't know is it big or little endian in terms of the util)
On my hand its plain so if you'll get all non zero bytes from the 0'th and xor them you should get decypted file (most probably). If 0 to 3 zero bytes are the part of the 4 'valuable' they also should be xored.
Will check later. Why? The first sector of the GPT is an MBR dummy, left for the compatibility w/old OS's/utils. MBR is always 1 sector long with additional EBR records around the disk. Dummy MBR has one dummy partition allocating the whole space on the disk. And as any standard MBR it has 55AA signature at the and of sector and a bunch of zeros before. As there is not a bootable MBR is has empty code section also filled with zeros. Finally you can see just a one sting of the binary data at 1C0h and a signature at 1FEh. Two xored zeros before 1FEh tell us that "key" (just an xor argument :)) is 4 byte long and not a 1 or 2 bytes long. All's simple here.

EUT isn't available anywhere. Furthermore f-n VZ didn't provided it for a free DL before, as they state...
As I found it's BootStrap is build in the device's internal driver CD
Some ppl discussed it here
http://androidforums.com/threads/verizon-updating-to-4-1-2-without-ota.824931/#post-6443168
and attached BootStrap
Then found VZ Update Tool
VZ allowed to DL it before at the particular links
https://web.archive.org/web/2013071...m/content/wcms/overlays/bua-plus-overlay.html
You can still DL 32/64bit Linux versions from the Archive (73MB each one)
https://web.archive.org/web/20130315160951/http://vcast-mm.com/dl/current/verizon21-2.1.13-9.deb
https://web.archive.org/web/2013031....com/dl/current/verizon21-2.1.13-64bit-13.deb
Win/Mac versions didn't archived for some reason
Old 404 links
http://vcast-mm.com/dl/current/verizon25-2.5.192-3.exe
http://vcast-mm.com/dl/current/verizon25-2.5.196-2.pkg
But you can get Windows package here now from this mirror (138MB):
http://public.atronicsys.com/Old Programs/verizon25-2.5.192-3 Backup Assistant.exe
I've got it but it's too scary to setup such a monster... :)
May be... It could contain loaders to flash bricked phones or something else useful.

So I assume:
1. It's definitely a factory/service Firmare Version ??? for North American Casio G'zOne C811 with North American modem Firmware (of unknown version), supporting NA LTE ranges.

2. All parts are decoded from XORing except GPT images (DO NOT FLASH THEM NOW!!!)

Service/Factory firmware for Qualcomm based devices never contain ModemST images since they contain unique device ID'd and calibration settings. There should be separate service procedure to fill in ID's and calibrate RF part as I stated before.
You can't flash nor change (edit) GPT (partitions) with CWM nor any available recovery. There could be theoretically some Recovery builds equipped with such a functionality. That's why you can't damage it flashing encrypted GPT images using TWRP.
Once GPT is damaged yor phone will not start at all in any mode. the only activity you can see is Qualcomm HS USB QDLoader 9008 detecting on the connected PC USB bus. Now you can partially fix this state as I described above and on the 4pda in Russian but it will not bring you phone to the life but will allow to mount whole eMMC outside as a PC USB mass storage disk. Recovery loaders will build new GPT but it will contain just a part of pertitions required to load SBL related stuff. As soon as eMMC will be mounted to your PC you can recreate full GPT manually or write in GPT images containing in your archive (after XOR DECODING!) Then you can flash damaged partitions and/or check which ones are still the intact (no need to flash if your ones still consistent, no need to erase your data and settings unless the data or data holding partition is damaged.

Everyone can dump his full image from the working phone, containing all the data stored on the eMMC.
I can't clear remember which buttons you should hold starting the device.
Most probably you should hold Vol+Vol- on the switched OFF device, then push Power holding Vols and then insert USB. Another possibility is to plug in UBS cable holding both Vol keys. Third possible sequence is to take off the battery, hold Vol keys and then connect battery and/or USB cable (this way you must probably can get into the mask ROM QDLoader 9008, not into the SBL's QHSUBS_DLOAD 9006 which is useless for the full dumping unless you have selfmade dumping loader. BTW everyone can look for one on the Forth32's QTools page/sources and explore Casio compatibility.
In case you can't get into the QHSUSB_DLOAD 9006 using keys you most probably can use QPST DLOAD mode switching. Look for the insructions with sreenshots over the net.
One you have mounted your whole eMMC to the PC NEVER click INITIALIZE partition once Windows will ask you to! Be careful! Do not write any data to the eMMC storage unless you know what you do!
Just make a full backup of the eMMC disk using any RAW! disk imageing tools. Good one is the HDD Raw Copy Tool from the HDDGuru. Do not compress images unless you will not plan to explore them or patch/change. If you have got compressed .imgc image by default using HDDRT you can decompress it later. You can use DMDE Disk Editor to explore and edit eMMC itself or dumped images or use R-Studio and other data recovery tools to recover data.
 
I'm dumbass in C programming
I've compiled your util in TinyCC 0.9.26 compiler for Win
Just a 5Kb long
Forced to remove
// #include <unistd.h>
and
// #include <strings.h>
and changed mkdir(out_dir, 0777); to mkdir(out_dir);
It's better to use #IfDef Win/Lin to easily make source crossplatform compilable

Then util compiled and works OK.
Here's log
Code: 
G:\CasioC811\FWs from_UpdateServer\Unp>eut_extract_v2.exe C811M070.mbn Out
Magic = 0x40061028, Number of partitions = 21
PartName:NON-HLOS.bin  , Flags:2, ActualSize: 0x2796a00  , StartSector: 0x20000  , StartAddr: 0x0  , PartitionSize: 0x6400000
PartName:sbl1.mbn  , Flags:2, ActualSize: 0x17df4  , StartSector: 0x60000  , StartAddr: 0x2796a00  , PartitionSize: 0x20000
PartName:sbl2.mbn  , Flags:2, ActualSize: 0x1e928  , StartSector: 0x60100  , StartAddr: 0x27ae800  , PartitionSize: 0x40000
PartName:sbl3.mbn  , Flags:2, ActualSize: 0x565f4  , StartSector: 0x60300  , StartAddr: 0x27cd200  , PartitionSize: 0x80000
PartName:emmc_appsboot.mbn  , Flags:2, ActualSize: 0x44634  , StartSector: 0x60700  , StartAddr: 0x2823800  , PartitionSize: 0x80000
PartName:rpm.mbn  , Flags:2, ActualSize: 0x21098  , StartSector: 0x60b00  , StartAddr: 0x2868000  , PartitionSize: 0x80000
PartName:boot.img  , Flags:2, ActualSize: 0x65a000  , StartSector: 0x80000  , StartAddr: 0x2889200  , PartitionSize: 0xa00000
PartName:tz.mbn  , Flags:2, ActualSize: 0x2ea40  , StartSector: 0xa0000  , StartAddr: 0x2ee3200  , PartitionSize: 0x80000
PartName:modemst1  , Flags:1, ActualSize: 0x0  , StartSector: 0xa0402  , StartAddr: 0x2f11e00  , PartitionSize: 0x300000
PartName:modemst2  , Flags:1, ActualSize: 0x0  , StartSector: 0xa1c02  , StartAddr: 0x2f11e00  , PartitionSize: 0x300000
PartName:system.img.ext4  , Flags:0, ActualSize: 0x3135a320  , StartSector: 0xc0000  , StartAddr: 0x2f11e00  , PartitionSize: 0x50000000
PartName:userdata.img.ext4  , Flags:0, ActualSize: 0x8581a00  , StartSector: 0x360000  , StartAddr: 0x3426c200  , PartitionSize: 0xba000000
PartName:persist.img.ext4  , Flags:0, ActualSize: 0x42d088  , StartSector: 0x1930000  , StartAddr: 0x3c7edc00  , PartitionSize: 0x800000
PartName:cache.img.ext4  , Flags:0, ActualSize: 0xd0816c  , StartSector: 0x1934000  , StartAddr: 0x3cc1ae00  , PartitionSize: 0x2bc00000
PartName:recovery.img  , Flags:2, ActualSize: 0x6ad000  , StartSector: 0x1ae0000  , StartAddr: 0x3d923000  , PartitionSize: 0xa00000
PartName:fsg  , Flags:1, ActualSize: 0x0  , StartSector: 0x1ae5000  , StartAddr: 0x3dfd0000  , PartitionSize: 0x300000
PartName:crash  , Flags:1, ActualSize: 0x0  , StartSector: 0x1c20100  , StartAddr: 0x3dfd0000  , PartitionSize: 0x20000
PartName:f3  , Flags:1, ActualSize: 0x0  , StartSector: 0x1c20200  , StartAddr: 0x3dfd0000  , PartitionSize: 0x20000
PartName:log  , Flags:1, ActualSize: 0x0  , StartSector: 0x1c20300  , StartAddr: 0x3dfd0000  , PartitionSize: 0x800000
PartName:gpt_main0.bin  , Flags:0, ActualSize: 0x4400  , StartSector: 0x0  , StartAddr: 0x3dfd0000  , PartitionSize: 0x4400
PartName:gpt_backup0.bin  , Flags:0, ActualSize: 0x4200  , StartSector: 0x1d1efdf  , StartAddr: 0x3dfd4400  , PartitionSize: 0x4200

Important Update:
To compile program for the windows environment you should also add file opening option O_BINARY.
Otherwise the files will be opened as text and it will lead to adding 0x0D aftere the every 0x0A in the output (unpacked) files, so will lead to broken files!
Problem is described here:
http://stackoverflow.com/questions/5537066/strange-0x0d-being-added-to-my-binary-file

Changes:
int in_fd = open(in_fname, O_RDONLY);
TO
int in_fd = open(in_fname, O_RDONLY | O_BINARY);
and
out_fd = open(fname_buf, O_WRONLY | O_CREAT | O_TRUNC, 0666);
TO
out_fd = open(fname_buf, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY, 0666);
 
Last edited:
If the IMEI/MAC/some S/N are NOT stored in the NVRAM/EFS on ModemSTz part's (otherwise ModemSTx erasure should absolutely lead to the IMEI and connectivity loss) then the suspicious places are F3, may be logs or crash. There may be unpartitioned blocks left where some info could reside, however it's unsafe in programming guidelines. May be some part's are missed in the package (even with zero size).
 
I have slightly sent you the wrong way. At 1st I've compared decrypted file with 'what should be'.
Then I've explored source and realized that XOR parameter for GPT's are incorrectly set
It seems that in C811M070.mbn at offset 3DFD01FC to FF stored xored 000055aa.
You should use XOR Key 29 91 D6 6E (may be reversed order) to decrypt gpt_backup0.bin
I didn't explored why. I simply saw data structures I should see.

Why do you set enc_key to 0xEDd26FF3A if Flag is 0 but I've added gpt files to the case struct with the correct key. Then sound key is set to 0xed26ff3a anyway, but for ext4 part's which have flag=0 too it's set correctly. Should look deeply into the logic, but wanna sleep, morning soon.

I've succefully decoded Main GPT with the key shown above. Can't guarantee, but it look clear
Here's full list of partitions
modem
sbl1
sbl2
sbl3
aboot
rpm
boot
tz
modemst1
modemst2
nvbackup
system
userdata
persist
cache
tombstones
misc
recovery
fsg
ssd
fota
ftm
crash
f3
log
extres
grow

But some can be named slightly different under the Linux (Android).
Partition naming (mounting names) is an internal affair of the firmware.

gpt_backup0.bin XOR key is: 0xC8B2374D

Keys should be reversed to use in program so C CONSTANTs should look like:
gpt_main0.bin XOR key is: 0x6ed69129
gpt_backup0.bin XOR key is: 0x4d37b2c8

Compiled, checked, decodes OK!

Look for the error in key obtaining tech.
May be somewhere also logic errors persist.
 
I think you also should add copyright notice to the header of the source file and GPL notice. Then add program name printf and short desc to the executable. Ppl should know their heroes. :)
Otherwise, when people will DL file, then it will circulate around as noname. It's also better to upload readymade Win/Lin executables for a "generic ppl".
 
TheDrive said:
Tp be correct I still don't definitely know which version is for which device. M020 M040 M050 M070, 410, 470... :) There is also pure japanse version FYI which is not an C811 nor CA-21L, already forgot the name. :)
Click to expand...

I have American M040, M050, M070 in the original form. Japanese variant is CAL21. Japanese and Korean variants are using different firmware update structure from American (trust me), and only delta images for Korean ones were available without full image like Verizon ones. In fact, I posted article here to ask about CAL21 firmware, but nobody replied till this point :( Obtaining CAL21 by myself was somewhat risky.

TheDrive said:
Very cool!
Getting to explore!
Have you reversed/developed this util urself?
Click to expand...

Yes, I never touched Verizon EUT tool and just used my 'senses' to decode it.

TheDrive said:
Keys should be reversed to use in program so C CONSTANTs should look like:
gpt_main0.bin XOR key is: 0x6ed69129
gpt_backup0.bin XOR key is: 0x4d37b2c8
Click to expand...

Thanks! I never cared about GPT keys, will fix it soon.

TheDrive said:
I think you also should add copyright notice to the header of the source file and GPL notice. Then add program name printf and short desc to the executable. Ppl should know their heroes. :)
Otherwise, when people will DL file, then it will circulate around as noname. It's also better to upload readymade Win/Lin executables for a "generic ppl".
Click to expand...

When I was writing the source code, I deliberately decided to distribute only as source code and not to be compiled on Windows, due to some reason that is still valid. Thank you for suggestion.
 
ad_rai said:
I never cared about GPT keys, will fix it soon.
Click to expand...
GPT partition table is very important part of the FW and any generic disk (where applicable).
Partition table describes which parts the drive is divided to, their types (FS types) bootability (not applicable here) and where each partition begins (offset, beginning sector) and ends (ending sector or length).
If you loose partition table you will not be able to access any byte on the drive unless you will open raw sectors an browse binary data. In terms of OS or any bootloaders this drive is empty.
It's relatively simple to recover when you have damaged partition table with only the one partition for the whole drive. It's slightly more difficult to recover partition when the drive is divided to a few standard partitions (you should just search for a well known signatures in headers.
This device has standard GPT partition table, but with a more then 20 partitions most of which are proprietary non standard blocks of data. Is would be difficult for me to recover such a partition. I don't think a man without a rich recovery experience could recover this partition in reasonable time. We have most of the partition images, so we can find reliable signatures by analysis. Then find what we can find and fill in the partition manually. Then we can explore gap holes to locate the remaining partitions, but this stage seems to be most complicated and unpredictable. When you have partition image you just write it in to its place and start to explore what partitions of the eMMC look normal, which ones are seem to be damaged.

More simple way is at first locate 'unique' partitions in the eMMC. Theoretically, they may have a different offsets if the device have a few revisions/FW's with different partitioning scheme. If you find differences and would like to recover 'unique' data, you should stop device recovery and find the way to correct partition table to affect real partition structure ob the drive. It's a bad case. Very much complicated work expected. May be it's easier to find original GPT and partition images for the old FW version.
If it's OK with 'unique' partition location ad state you're in good position.
Now backup them or previously backup the whole drive (best and safest way).
Then flash all the available images to their partitions to back the device to the working condition.
If there is no damages ion the unique partitions your device will switch on and work like a factory new.
You can also flash old data (userdata) partition to bring back all your apps and data located in the 'Internal memory' before.

Compare to the case you have the correct full flash image from the working phone. (This one or other's)
You just write full eMMC image to the drive and reboot the device (disconnect USB, reinsert battery).
the phone will switch on and work being in state identical the phone you have dumped from. All ID's and calibration settings will be cloned too. That's why it's always better to locate all your unique partitions in the damaged phone, back them up and try to reflash after recovery of the device (unless they are not damaged). Anyway this is a quick, simple and good salvation.

Attachment ZIP contains both the Main and Backup factory GPT images for Casio C811 FW M070
After MSImage flashing procedure, the Main GPT should be written to the eMMC's 0 sector and occupies 34 sectors (17KB)
Backup GPT should be written somwhere in the last sectors end of the eMMC after the last partition's end (see specs for detail of real locaction on the working device). You can write Backup later. Do not reboot device upon GPT flashing. This will most probably get you into the QDLoader 9008 mode again, because SBL/etc locations will not be correct according GPT. You should continue recovery (look above for the details!) and write the partition images to their places to be able to successfully boot the device.

Important Update:
Previous GPT images were broken due to the Windows compilation problem described some posts above
Please re-download the correct ones!
 

Attachments

Last edited:
TheDrive said:
GPT partition table is very important part of the FW and any generic disk (where applicable).
Click to expand...

Now I know what exactly you want... fixing the phone beyond recovery failure and eMMC mode. As I never thought about beyond recovery failure, that is the reason why I didn't tried properly decoding GPT data. Please don't assume that I don't know about that :)
 
Wow! Yes, I'm talking about recovery from any position/state, except fatal HW failure, or something impossible w/o inadequate expenses. For a long time there was a fatal situation for many ppl, when phone had damaged GPT or SBL related stuff. The loader above allow to recover from this failure, but a complicated way. Even though nugiedha have published the only working loaders in the Nov 2015 he'd not supplied some kind detailed description / manual. That's why so few ppl have known how to recover their phones from the PBL only QDLoader 9008 state for a while. Some ppl, who are some kind professional service engineers in Rus forums stated they was decided (forced to) to disassemble a few fully working G'zOnes bricked in QDLoader state to the parts to sell.

It's serious problem and Casio-Nec/VZ are responsible for a user rights violation because they didn't published any sources nor enough files to recover the device from any state. Nor even a simple FW package accessible for a years from their web page w/o any 'encryption' just to satisfy their customers lawful and reasonable needs. Why should customer who've paid $700 for a $50 costed device, equipped with free GNU/GPL Linux wonder around off site and forums and beg to provide the working FW, he have the full right to, even if he wouldn't bought any devices and paid any pennies. Absurd and fraud.

Important Update:
Previous GPT images were broken due to the Windows compilation problem described some posts above
Please re-download the correct ones!
 

Attachments

Last edited:
Helo Everybody , I need your help. Can anyone send a link to download C811 FULL FLASH IMAGE (eMMC USER_PART) ?? Please thank your very much !!!
 
You must log in or register to reply here.
Back
Top Bottom