Related
Hello,
I am starting this thread in the hopes of spurring some investigation into how to unlock the Samsung Galaxy Ace 2(X) without paying for an unlock code or for a service box such as Octoplus etc. All other methods for unlocking Samsung devices (dialer code, nv_data etc) do not work on this device.
I have made a little bit of progress on my own device, the GT-S7560m or Galaxy Ace 2X, outlined here. Unfortunately, I cannot provide a method to unlock as of yet, as the method I currently have found will replace the target device IMEI with the IMEI of the 'donor' device. I have not found a way to change the IMEI back (yet).
First, what I did was simple: Root the phone and backup all partitions other than /system, /data, /cache (/dev/block/mmcblk0pX) I did this a couple of times in between reboots and factory resets to have multiple backups as well as to see if any partitions change after reboots or resets.
It turns out that there are five partitions which change (slightly or drastically) after reboots/resets. These are:
mmcblk0p9
mmcblk0p10
mmcblk0p11
mmcblk0p13
mmcblk0p19 (/efs, found via mount command)
Since the S7560M does not have a GPT partition table, I can't find the labels for what these partitions actually are. 11,13 and 19 are mostly blank, while 9 and 10 are chock full.
Next, I bought an unlock service on eBay. Once unlocked, I took another image of all the partitions, and compared which ones were changed (locked vs unlocked). Unsurprisingly, the same five partitions were different.
To narrow it down, I the flashed back the locked versions of these partitions until my simlock returned.
mmcblk0p9 is the partition that holds the simlock data
I tested flashing only p9 and, indeed, simlock disappeared and reappeared according to the version being flashed. I have multiple devices to test with at the moment, so I took the unlocked p9 from Phone A and flashed it to Phone B, and sure enough, Phone B could then accept foreign SIM cards.
Unfortunately, this also changed Phone B's IMEI to that of Phone A
I tried various tools to attempt to zero out the IMEI (so that the partition image can be shared between devices and the end-user can then restore their proper IMEI) to no avail. It seems the NV items on this device are locked or read-only for some reason.
CDMA Workshop, NV Items Reader-Writer, QPST, QXDM, all these tools are able to read NV items fine, but when trying to write back NV item 550 ue_imei it inevitably fails. In QPST an unknown error (0x80004005) is thrown when writing, whereas in QXDM the program states "No DIAG response received" when attempting to write the NV item. I tried multiple phones, PCs and versions of Windows with the same error.
You'll recall that on other devices such as the GS3, QPST/QXDM/etc works perfectly fine to restore the IMEI through NV editing.
I believe mmcblk0p9 is the 'real' EFS partition, holding the NV items for the device. It also seems to be encrypted, since I cannot find the IMEI in hex nor decimal format inside it, yet the IMEI is changed when the partition is cross-flashed. Across phones and even simply rebooting, the partition almost completely changes, save for a header and a couple of other bytes.
In order to unlock the device freely, I believe the next step is to either decrypt mmcblk0p9, or find a way to get QPST/QXDM to write to the phone
If you have any thoughts/experience, feel free to post below! I am sort of stuck here.
This is a REALLY interesting thread. We need more of these! I know that to unlock my good old Galaxy Gio, you had to pull the bml5 partition and look at it with a hex editor to find 8 digits surrounded by nonsense symbols. Unlocking this device is gonna be MUCH harder, but maybe we just need to look at one of the 5 partitions you mentioned with a hex editor? I have no need of unlocking my device, nor have I ever actually tried it, but I'd like to get involved in this. Tell me, what happens when you insert a foreign sim card into your Ace II X (then you power it on or reboot it)? Does a dialog pop up asking for a code?
Dont bother with tools from market, they are made for units with samsung and qualcomm cpus. Ace2/S3 mini/S Advance/Xperia Sola/Xperia U and few others use NovaThor cpu from ST-Ericsson. So you should look in that direction. I have posted partition info here http://forum.xda-developers.com/showpost.php?p=42096782&postcount=22
You should also look those threads about partitions and some other info:
http://forum.xda-developers.com/showthread.php?t=2145464
http://forum.xda-developers.com/showthread.php?t=2352064
http://forum.xda-developers.com/showthread.php?t=2389395
http://forum.xda-developers.com/showthread.php?t=2132670
IIRC imei is most likely in cspsa partition, but encrypted. Search also for binaries in /system/lib/tee.
Some things i think may help further:
- gap betwwen partitions
- serial number is not encrypted, you can find it by searching the dump
If you want you can buy development board for NovaThor pretty cheap at http://shop.strato.com/epages/61428605.sf/en_GB/?ViewObjectID=11538 as this platform seems dead since ST-Ericsson split and so is with price of the board.
For i8160/p/l (and for all phones with novathor soc) the imei, serial and simlock data is on cspsa_fs that's 100%, but it's encrypted and I think there is a hash check or something similar because if you edit something (no matter what) in cspsa partition dump after reflashing the modem completely stops working - no signal, no imei.
Szaby59 said:
For i8160/p/l (and for all phones with novathor soc) the imei, serial and simlock data is on cspsa_fs that's 100%, but it's encrypted and I think there is a hash check or something similar because if you edit something (no matter what) in cspsa partition dump after reflashing the modem completely stops working - no signal, no imei.
Click to expand...
Click to collapse
angrybb said:
Dont bother with tools from market, they are made for units with samsung and qualcomm cpus. Ace2/S3 mini/S Advance/Xperia Sola/Xperia U and few others use NovaThor cpu from ST-Ericsson. So you should look in that direction. I have posted partition info here http://forum.xda-developers.com/showpost.php?p=42096782&postcount=22
You should also look those threads about partitions and some other info:
http://forum.xda-developers.com/showthread.php?t=2145464
http://forum.xda-developers.com/showthread.php?t=2352064
http://forum.xda-developers.com/showthread.php?t=2389395
http://forum.xda-developers.com/showthread.php?t=2132670
IIRC imei is most likely in cspsa partition, but encrypted. Search also for binaries in /system/lib/tee.
Some things i think may help further:
- gap betwwen partitions
- serial number is not encrypted, you can find it by searching the dump
If you want you can buy development board for NovaThor pretty cheap at http://shop.strato.com/epages/61428605.sf/en_GB/?ViewObjectID=11538 as this platform seems dead since ST-Ericsson split and so is with price of the board.
Click to expand...
Click to collapse
You guys are mistaken. The device being discussed is not the Ace II, but instead the Ace II X (same as S7560 Galaxy Trend or S7562 S Duos but with single sim). It does have a Snapdragon S1 clocked to 1 GHz (MSM7227A) with an Adreno 200 GPU. @op maybe you should modify the thread name to Ace II X instead of Ace 2 (X). It makes it less misleading.
angrybb said:
Dont bother with tools from market, they are made for units with samsung and qualcomm cpus. Ace2/S3 mini/S Advance/Xperia Sola/Xperia U and few others use NovaThor cpu from ST-Ericsson. So you should look in that direction. I have posted partition info here http://forum.xda-developers.com/showpost.php?p=42096782&postcount=22
You should also look those threads about partitions and some other info:
http://forum.xda-developers.com/showthread.php?t=2145464
http://forum.xda-developers.com/showthread.php?t=2352064
http://forum.xda-developers.com/showthread.php?t=2389395
http://forum.xda-developers.com/showthread.php?t=2132670
IIRC imei is most likely in cspsa partition, but encrypted. Search also for binaries in /system/lib/tee.
Some things i think may help further:
- gap betwwen partitions
- serial number is not encrypted, you can find it by searching the dump
If you want you can buy development board for NovaThor pretty cheap at http://shop.strato.com/epages/61428605.sf/en_GB/?ViewObjectID=11538 as this platform seems dead since ST-Ericsson split and so is with price of the board.
Click to expand...
Click to collapse
wrong thread dude..
---------- Post added at 08:59 PM ---------- Previous post was at 08:59 PM ----------
Codename13 said:
You guys are mistaken. The device being discussed is not the Ace II, but instead the Ace II X (same as S7560 Galaxy Trend or S7562 S Duos but with single sim). It does have a Snapdragon S1 clocked to 1 GHz (MSM7227A) with an Adreno 200 GPU. @op maybe you should modify the thread name to Ace II X instead of Ace 2 (X). It makes it less misleading.
Click to expand...
Click to collapse
they should read the entire thread first right?(first post) see how observent they are
Is this thread dead?
Codename13 said:
Is this thread dead?
Click to expand...
Click to collapse
I think so
---------- Post added at 09:21 PM ---------- Previous post was at 08:35 PM ----------
krazykipa said:
Hello,
I am starting this thread in the hopes of spurring some investigation into how to unlock the Samsung Galaxy Ace 2(X) without paying for an unlock code or for a service box such as Octoplus etc. All other methods for unlocking Samsung devices (dialer code, nv_data etc) do not work on this device.
I have made a little bit of progress on my own device, the GT-S7560m or Galaxy Ace 2X, outlined here. Unfortunately, I cannot provide a method to unlock as of yet, as the method I currently have found will replace the target device IMEI with the IMEI of the 'donor' device. I have not found a way to change the IMEI back (yet).
First, what I did was simple: Root the phone and backup all partitions other than /system, /data, /cache (/dev/block/mmcblk0pX) I did this a couple of times in between reboots and factory resets to have multiple backups as well as to see if any partitions change after reboots or resets.
It turns out that there are five partitions which change (slightly or drastically) after reboots/resets. These are:
mmcblk0p9
mmcblk0p10
mmcblk0p11
mmcblk0p13
mmcblk0p19 (/efs, found via mount command)
Since the S7560M does not have a GPT partition table, I can't find the labels for what these partitions actually are. 11,13 and 19 are mostly blank, while 9 and 10 are chock full.
Next, I bought an unlock service on eBay. Once unlocked, I took another image of all the partitions, and compared which ones were changed (locked vs unlocked). Unsurprisingly, the same five partitions were different.
To narrow it down, I the flashed back the locked versions of these partitions until my simlock returned.
mmcblk0p9 is the partition that holds the simlock data
I tested flashing only p9 and, indeed, simlock disappeared and reappeared according to the version being flashed. I have multiple devices to test with at the moment, so I took the unlocked p9 from Phone A and flashed it to Phone B, and sure enough, Phone B could then accept foreign SIM cards.
Unfortunately, this also changed Phone B's IMEI to that of Phone A
I tried various tools to attempt to zero out the IMEI (so that the partition image can be shared between devices and the end-user can then restore their proper IMEI) to no avail. It seems the NV items on this device are locked or read-only for some reason.
CDMA Workshop, NV Items Reader-Writer, QPST, QXDM, all these tools are able to read NV items fine, but when trying to write back NV item 550 ue_imei it inevitably fails. In QPST an unknown error (0x80004005) is thrown when writing, whereas in QXDM the program states "No DIAG response received" when attempting to write the NV item. I tried multiple phones, PCs and versions of Windows with the same error.
You'll recall that on other devices such as the GS3, QPST/QXDM/etc works perfectly fine to restore the IMEI through NV editing.
I believe mmcblk0p9 is the 'real' EFS partition, holding the NV items for the device. It also seems to be encrypted, since I cannot find the IMEI in hex nor decimal format inside it, yet the IMEI is changed when the partition is cross-flashed. Across phones and even simply rebooting, the partition almost completely changes, save for a header and a couple of other bytes.
In order to unlock the device freely, I believe the next step is to either decrypt mmcblk0p9, or find a way to get QPST/QXDM to write to the phone
If you have any thoughts/experience, feel free to post below! I am sort of stuck here.
Click to expand...
Click to collapse
Can you post a zip file op your efs folder?
Thanks in advance.
Hello all,
Unfortunately at this point I have sold all the Ace 2X units I had previously. I wasn't really getting anywhere anyway and ended up buying a Z3X box. Thread can be closed, or feel free to continue in my absence. Good luck!
I'd like if we, as developers working together, could get this done. Just a question: Is there an issue if we share the same IMEI? Why can't one of us pay to unlock our device, then share our mmcblk0p9 with others? Would it cause problems if others flashed our efs partition to their device?
Codename13 said:
I'd like if we, as developers working together, could get this done. Just a question: Is there an issue if we share the same IMEI? Why can't one of us pay to unlock our device, then share our mmcblk0p9 with others? Would it cause problems if others flashed our efs partition to their device?
Click to expand...
Click to collapse
1- multiple phones with the same IMEI on the same network cause problems for all other (the only reason this can normally happen is your phone losing signal or crashing then reconnecting, so it's reasonable for the phone company to drop all other active links when it connects again)
2- on the U8500 Sonys, the role of CSPSA, EFS and some other firmware partitions is done by the "TA" partition. We know parts of it are signed (with different keys, some specific to the individual hardware) and changing them results in hard bricks... not terribly related to this phone, but the moral is that without knowledge about this undocumented binary sequence that is partition 9 (probably requiring a JTAG backup and trial and error) we common mortals can't afford to experiment blindly
Hello,
An S7560M came through my hands again, and I've taken the time to capture the data that is sent to the proprietary Z3X server for generating the unlock codes. The tool bypasses the MSL, reads some data from the modem, sends it to the server for analysis, and sends back your unlock code(s). If anybody is good at cryptography or data analysis, feel free to analyze the Wireshark dump that contains all the data. Somehow, the unlock code shown in the screenshot is attainable with only that data.
I myself have no idea how to get from there to an unlock code on my own. The only modification I've made is removing the serial number of my Z3X equipment in the dump for security. The IMEI and SN do not appear to be transmitted in the dump, but I've removed them from the screenshot.
Hope this helps, good luck.
krazykipa said:
Hello,
An S7560M came through my hands again, and I've taken the time to capture the data that is sent to the proprietary Z3X server for generating the unlock codes. The tool bypasses the MSL, reads some data from the modem, sends it to the server for analysis, and sends back your unlock code(s). If anybody is good at cryptography or data analysis, feel free to analyze the Wireshark dump that contains all the data. Somehow, the unlock code shown in the screenshot is attainable with only that data.
I myself have no idea how to get from there to an unlock code on my own. The only modification I've made is removing the serial number of my Z3X equipment in the dump for security. The IMEI and SN do not appear to be transmitted in the dump, but I've removed them from the screenshot.
Hope this helps, good luck.
Click to expand...
Click to collapse
Not sure how to help, but this is some serious looking stuff! I downloaded your attachment, extracted S7560M.pcapng and I converted it to S7560M.pcap using this guide. I then tried opening it and Ubuntu searched for a program that could open it. I got Wireshark and was able to open it. I'm guessing that's no such sort of hacking, right? Anyways, I'd like to help out. In the image you uploaded in that 7z archive, what is the unlock code? I want to scour the data in the Wireshark dump and see if I can find any correlations between the data in the image and the data in the dump. All I have to guess at this time is that all the code is hex, and it probably translates to decimal.
In the screenshot the unlock code is the NET lock code. The other numbers and * # are dialer codes (for unlocking direct from dialer without inserting a foreign SIM) but the actual code is 30385735.
If i understand it right the sim-partition is 9?
Why whe can't just share that partition from someone who payed for unlocking his device and changing imei (there are some tuts on xda)?
imei
the unlock code is based on the imei..
somebody unlocked his phone based just on his imei and the name of his carrier over the internet..
Anas Karbila said:
If i understand it right the sim-partition is 9?
Why whe can't just share that partition from someone who payed for unlocking his device and changing imei (there are some tuts on xda)?
Click to expand...
Click to collapse
I'll say this again, Partition 9 is unique to each phone. Another way of seeing it is: two people own the same car, when one person is driving the car, the other person can't drive the car, vice versa. You can't duplicate that car, because each numberplate is specific to one car.
Likewise, you can't copy partition 9 to another phone, because it would be the same as using the same numberplate on two different cars. The partition 9 includes the IMEI, if you will, the "numberplate" of the phone.
Mod Edit
Changing imei numbers is illegal.
Any such discussion is not allowed on XDA
Thread closed
malybru
Forum Moderator
Unfortunately, my Casio GZOne Commando was bricked while I upgrade rom for it. My computer recognizes it as a com port. This comport was name is Qualcomm HS-USB QDLoader 9008 Mode. Please, some one can help me rescuse my phone. Please tell me step by step instructions to unbrick the phone :crying:
I unfortunately have almost the same problem, I've been looking for a solution, in general; Qpst app does recognize the com port, and you can flash a set of required files such as the firefighter /MCC/XML (not sure of the names), you can find them on the gethub website.
For me, I did so, but got to nowhere except the c811 is now recognized by Windows as g'zone!
Please do update me on what happened with your phone.
Good luck
PLEASE CAREFULLY READ WHOLE MESSAGE and OBEY ALL THE PRECAUTIONS!
Please do NOT DO a thing unless you UNDERSTAND all the infos!!!
This was a total problem for a years. Casio/Nec have hidden original FW and loader required to flash the phone with damaged GPT or SBL (SBL level loaders. It's illegal in the context of consumer rights in many countries and violates GNU/GPL Linux/components licenses (independently of the fact the loaders itself are the Qualcomm/OEM proprietary SW, but we couldn't use and develop this particular Linux build w/o them). No FW sources were published. Casio-NEC JSC ****ed up the users and now gone from the market and closed support services/servers just upon closing. It's a shame for these respectable Japanese companies which reputation was clear for the decades. I don't care about any law aspects related to the JSC. Casio and Nec have used their brands to sell these devices and it's a shame for them all. I can't realize why could a web server support and source publishing cost any much for a billion corps. There are the laws in many countries requiring parts supply for a whole time of declared device serve period. Is Casio/Nec device's serve period now is set as 1 year only now?
If you have lost some money for an ineffective market policy, should your customers , respond for that?
These phines due to unique 'protected' design, good quality and parts are widely popular around the world far away from the official market places. Who have decided not to officially expand to these markets at the time?
There is good sales potential for a good quality protected phones (especially high branded) at the current time.
Adequate ads activity should provide a small but valuable market share.
Let's back to our problems
Now this, PBL-only bricking (QDloader 9008 only) problem has been partially fixed.
You should read my articles here (in English):
http://androidforums.com/threads/rom-stock-c811-m070-firmware-zip-file-4-1-2.878959/page-3
to understand internal eMMC architecture. Please realize you should try to UNDERSTAND, but not simply think how to quickly FIX your brick! You'll fix nothing unless you will understand what's going on and what's the parts responsible for which state.
Next step, go to the Russian 4dpa.ru forums and read my instructions how to flash loaders and get into the Qualcomm QHSUSB_DLOAD 9006 mode.
http://4pda.ru/forum/index.php?showtopic=497930&view=findpost&p=50105534
Sorry, Russian only for a while. You can translate pages with Google translator.
DO NOT DO a THING YET NOW! Simply READ and THINK!
Also read the discussion on that page and a few on the previous and the next pages. DL files (e.g. FW's, utils), you think could help you later on context. (4PDA reg req'd to DL attachments. It's isn't complicated, but service may ask you to enter a numeric capcha described as numeric-words in Russian. That's the problem for non Russian speakers. Once you get the problem note it ask you a random 4-cipher number. Try to translate somehow or request req'd files to upload here. Look may be these files are already uploaded on the AndroidForums (link above and other topics).
(If the messages/links will some kind shift by the time look for the manual posted on 03.06.2016, 02:28 GMT+3 and around)
Big thanks for the correct and the only working Casio C811 / CA-201L loaders go to the nugiedha @ANDROIDForums
http://androidforums.com/threads/casio-c811-soft-brick-possible-fix.967172/#post-7136788
Then realize simple thing. Loaders will NOT bring your phone back to the working condition immediately!!!
They will allow you to get the direct access to the eMMC and do WHAT YOU WANT with it. You can partition it as FAT32 UFD and then write your favorite pron there if you want, as you do it with your favorite UFD, but sure, it's simply useless. and stupid. and it will kill the rest of the data on the phone.
PLEASE NOTE! Upon an eMMC detection as a mass storage device in your PC, YOU SHOULD NOT OCCASIONALLY CLICK OK ON ANY WINDOWS REQUESTS ASKING TO INITIALIZE A NEW DRIVE/PARTITIONS!!! IT WILL DAMAGE DATA ON THE PHONE! BE CAREFUL!!!
THERE ARE MORE THEN 20 PROPRIETARY PARTITIONS ON THIS MEDIA WINDOWS SYSTEM HAVE NOTHING TO DO WITH!
Important! The first thing you should do is to BACKUP the whole image of the BROKEN phone including partition table (GPT) and all the partitions (intact or damaged) as a one big 16GB whole physical disk image to some partition that have enough free space. Do NOT try to backup to the FAT32 partitions. The maximum single file size there is 4GB.
I.e. DO a FULLFLASH backup, aka eMMC full backup image, etc., independently on the fact FW is broken at the moment!
Use HDD Raw Copy Tool form the HDDGuru forums or similar tools to make a full image backup.
You can use any data recovery / disk editing utils, like R-Studio or DMDE later to extract any data and/or whole partition images from there later. Please note, that after the MSImage loader flashing your original GPT will be replaced with a small GPT built into the loader, independently on fact was it correct or damaged at the moment of the failure.
However there is NO way to avoid this. There is NO any other way out to boot damaged phone from the QDLoader 9008 state (it's PBL mode) except JTAG involving tools. That's why you will not ba able to easily find all the partitions in the broken phone eMMC image. But you can scan the image (e.g. with R-Studio) and find the remaining partitions (except proprietary) on their places unless partition header/data was not damaged upon crash.
Next you have 3 options to recover the phone to the working condition:
1. Find Casio CA-201L or C811 FULL FLASH IMAGE (eMMC USER_PART) image dumped from phone placed in the same DLOAD mode
2. Find same image got using JTAG tools (in fact same as above)
3. Recreate partitions (write correct GPT) and all the partition data manually using parts of your backup and original factory partition images, most of which (for C811 and partially for CA-201L) you can find on the AndroidForums topic.
Option 1 (or 2) is easy to understand and perform. But there are 3 notes on it
1. You should find Full eMMC image for your phone or the one who will dump his phone's image for you
2. All the ID's, i.e. IMEI, MAC's etc and current User Data will move from that image to your phone.
You can make a user data wipe (Hard Reset) to destroy user data and get a 'factory state' phone later.
I do not know a way to patch IMEI/MAC's back to your originals for a while (do not have phone on my hands for experiments),
but sure these ID's are stored on some of the 'unique' partitions, listed in AndroidForums topic and you can find and extract this partition (unless it damaged) from your damaged eMMC image and flash it to the recovered phone. by any method (directly to the eMMC, using FastBoot mode, using ADB/Linux DD commands). It's theory, that I can't revert to the practice for a while.
3. YOU SHOULD NOT TO ASK A MAN, WHO WILL AGREE TO DUMP HIS PHONE IMAGE FOR YOU TO USE MSImage LOADER METHOD TO SWITCH PHONE TO THE QHSUSB_DLOAD 9006 MODE!!! Otherwise he will DAMAGE HIS GPT AND MODEM FW and you BOTH will get 2 NON WORKING phones instead of 1!!!
There are another methods available to switch this phone to the eMMC DLOAD mode while it resides in the working condition (unless SBL is able to load). The first is to hold both VOL keys at the powering up.
Switch phone off, remove and insert battery to be on the safe side, then hold down VOL+VOL- and press Power Key, then connect USB cable. Other options is to hold VOL keys and connect USB cable without Power key or hold keys and connect USB cable without battery. However these options, most probably will bring QDLoader 9008 mode related to the PBL instead of QHSUSB_DLOAD 9006 mode related to the SBL. That's why if your phone have GPT or SBL structures you can't get it into the QHSUSB_DLOAD 9006 mode unless you will flash MSImage (containing GPT and all SBL-related code) using described procedure.
So, please NOTE one more time YOU SHOULD NOT flash MSImage loader to the working phone! You will damage GPT and get phone to the non working condition!
Another way to switch WORKING phone to the QHSUSB_DLOAD 9006 mode id to use software switcher like the ones, that can be found in QPST eMMC Flashing app and QPST Memory Debug app. Search by google for a detailed manuals with screenshots how to do it (switch to DLOAD) with any Qualcomm based phone (You can try with any, but not all the phones will switch because of customizations!)
There are some other methods circulating around how to force particular WORKING Qualcomm based phones switch to DLOAD mode (using ARM native code app / loader or send command to the Debug port of the modem).
Upon the eMMC image creation you should disconnect working phone fro the USB cable and reboot it to switch back to the normal mode., Just hold Power key for a long time or remove and reinsert the battery.
You should reserve 15-20 minutes of time to perform full eMMC backup procedure.
Upon your damaged phone will switch to the QHSUSB_DLOAD 9006 mode using MSImage loader,
you can simply write one's full working phone's eMMC image using HDD Raw Copy Tool.
Just write from Image file to the eMMC device, then disconnect phone, reset it (reinsert battery) and switch it on.
Phone will boot identically to the donor phone. Perform further generic recovery procedures to revert to your phone to the required condition. You may switch is to the DLOAD mode again using 'normal' way and continue to perform eMMC editing, particular partition images writing, patching, etc.
Option 3 (manual image combining without one's working full image) is much more complicated to proceed, but there are almost all the required data can be found around. Get the original GPT (and GPT backup) from the AndroidForums factory images or look for the GPT backup at the end of the eMMC (It's standard. GPT should have a backup copy at the end of media and eMMC holds this backup, look for it). If you will find GPT backup, try to compare it with ones from the factory images from the AndroidForums.
It will clear for you is your previous FW have had same GPT partition structure and find differences in the partition sizes and locations between your old FW and particular Factory FW. This will help you to extract unique and/or any other req'd partition images from your broken full and inject them to the new full, you building up for whole phone flashing. Use DMDE Disk Editor (Free version is absolutely enough, unless you would like to mass recover files from your data partition with it). It will show you all the GPT structures, their sector ranges. It will help you to locate and extract particular partition Upon correct GPT written to the device (or your new image preparation), you can start to write partitions at their dedicated places. Once you have checked (and/or fixed) all the partitions your phone is ready to swich on. In most cases you have great chance to recover without one's full. The only condition all the small 'unique' partitions that is not included to the factory FW images should be NOT damaged. Please note, that many people reported that damaged/incorrect ModemSTx (modem data / NVRAM) erasure on THIS PARTICULAR PHONE will lead to the working partition recreation (assume w/o IMEI loss) and could be used as one of the NVRAM fixation techniques.
So you should have at least be able to extract important ID's (may be a few others) partition(s) and inject them to your new image (or directly to the eMMC).
That's why you should NEVER start to the recovery (eMMC writing) UNLESS YOU HAVE MADE A BACKUP COPY OF THE DAMAGED eMMC IMAGE!
Sure in 99% you will recover your phone whether you will find one's full (simple) or your will be able to rebuild it using factory (others, why not?) images and the part of your broken eMMC contents.
Good Luck!
I'm attaching here the required files. Please be careful!
Some people just DL files and do not copy the description.
The novices can broke their devices trying to do 'something idiotic'.
Please note, that attached GPT images are definitely for factory M070 FW for C811 version.
You can flash it to the any compatible versions (like CA-201L) but I don't know, will it be identical to your old partition scheme, so real unique partition data you could look to find mat be located at another offsets.
Check manually if you can and always make full broken FW eMMC image at first.
Get flesh QPST 2.7.425 here, thanks to drkcobra
http://forum.xda-developers.com/showpost.php?p=59235714&postcount=15
Or look the topic to find later vers (if any)
Direct Link:
http://www.mediafire.com/download/neeapht51ub2333/QPST.WIN.2.7_Installer-00425.1.zip
Important Update:
Casio C811 GPT images were broken due to the Windows decryption utility compilation problem.
File re-uploaded! Please update!
TheDrive said:
PLEASE CAREFULLY READ WHOLE MESSAGE and OBEY ALL THE PRECAUTIONS!
Please do NOT DO a thing unless you UNDERSTAND all the infos!!!
This was a total problem for a years. Casio/Nec have hidden original FW and loader required to flash the phone with damaged GPT or SBL (SBL level loaders. It's illegal in the context of consumer rights in many countries and violates GNU/GPL Linux/components licenses (independently of the fact the loaders itself are the Qualcomm/OEM proprietary SW, but we couldn't use and develop this particular Linux build w/o them). No FW sources were published. Casio-NEC JSC ****ed up the users and now gone from the market and closed support services/servers just upon closing. It's a shame for these respectable Japanese companies which reputation was clear for the decades. I don't care about any law aspects related to the JSC. Casio and Nec have used their brands to sell these devices and it's a shame for them all. I can't realize why could a web server support and source publishing cost any much for a billion corps. There are the laws in many countries requiring parts supply for a whole time of declared device serve period. Is Casio/Nec device's serve period now is set as 1 year only now?
If you have lost some money for an ineffective market policy, should your customers , respond for that?
These phines due to unique 'protected' design, good quality and parts are widely popular around the world far away from the official market places. Who have decided not to officially expand to these markets at the time?
There is good sales potential for a good quality protected phones (especially high branded) at the current time.
Adequate ads activity should provide a small but valuable market share.
Let's back to our problems
Now this, PBL-only bricking (QDloader 9008 only) problem has been partially fixed.
You should read my articles here (in English):
http://androidforums.com/threads/rom-stock-c811-m070-firmware-zip-file-4-1-2.878959/page-3
to understand internal eMMC architecture. Please realize you should try to UNDERSTAND, but not simply think how to quickly FIX your brick! You'll fix nothing unless you will understand what's going on and what's the parts responsible for which state.
Next step, go to the Russian 4dpa.ru forums and read my instructions how to flash loaders and get into the Qualcomm QHSUSB_DLOAD 9006 mode.
http://4pda.ru/forum/index.php?showtopic=497930&view=findpost&p=50105534
Sorry, Russian only for a while. You can translate pages with Google translator.
DO NOT DO a THING YET NOW! Simply READ and THINK!
Also read the discussion on that page and a few on the previous and the next pages. DL files (e.g. FW's, utils), you think could help you later on context. (4PDA reg req'd to DL attachments. It's isn't complicated, but service may ask you to enter a numeric capcha described as numeric-words in Russian. That's the problem for non Russian speakers. Once you get the problem note it ask you a random 4-cipher number. Try to translate somehow or request req'd files to upload here. Look may be these files are already uploaded on the AndroidForums (link above and other topics).
(If the messages/links will some kind shift by the time look for the manual posted on 03.06.2016, 02:28 GMT+3 and around)
Big thanks for the correct and the only working Casio C811 / CA-201L loaders go to the nugiedha @ANDROIDForums
http://androidforums.com/threads/casio-c811-soft-brick-possible-fix.967172/#post-7136788
Then realize simple thing. Loaders will NOT bring your phone back to the working condition immediately!!!
They will allow you to get the direct access to the eMMC and do WHAT YOU WANT with it. You can partition it as FAT32 UFD and then write your favorite pron there if you want, as you do it with your favorite UFD, but sure, it's simply useless. and stupid. and it will kill the rest of the data on the phone.
PLEASE NOTE! Upon an eMMC detection as a mass storage device in your PC, YOU SHOULD NOT OCCASIONALLY CLICK OK ON ANY WINDOWS REQUESTS ASKING TO INITIALIZE A NEW DRIVE/PARTITIONS!!! IT WILL DAMAGE DATA ON THE PHONE! BE CAREFUL!!!
THERE ARE MORE THEN 20 PROPRIETARY PARTITIONS ON THIS MEDIA WINDOWS SYSTEM HAVE NOTHING TO DO WITH!
Important! The first thing you should do is to BACKUP the whole image of the BROKEN phone including partition table (GPT) and all the partitions (intact or damaged) as a one big 16GB whole physical disk image to some partition that have enough free space. Do NOT try to backup to the FAT32 partitions. The maximum single file size there is 4GB.
I.e. DO a FULLFLASH backup, aka eMMC full backup image, etc., independently on the fact FW is broken at the moment!
Use HDD Raw Copy Tool form the HDDGuru forums or similar tools to make a full image backup.
You can use any data recovery / disk editing utils, like R-Studio or DMDE later to extract any data and/or whole partition images from there later. Please note, that after the MSImage loader flashing your original GPT will be replaced with a small GPT built into the loader, independently on fact was it correct or damaged at the moment of the failure.
However there is NO way to avoid this. There is NO any other way out to boot damaged phone from the QDLoader 9008 state (it's PBL mode) except JTAG involving tools. That's why you will not ba able to easily find all the partitions in the broken phone eMMC image. But you can scan the image (e.g. with R-Studio) and find the remaining partitions (except proprietary) on their places unless partition header/data was not damaged upon crash.
Next you have 3 options to recover the phone to the working condition:
1. Find Casio CA-201L or C811 FULL FLASH IMAGE (eMMC USER_PART) image dumped from phone placed in the same DLOAD mode
2. Find same image got using JTAG tools (in fact same as above)
3. Recreate partitions (write correct GPT) and all the partition data manually using parts of your backup and original factory partition images, most of which (for C811 and partially for CA-201L) you can find on the AndroidForums topic.
Option 1 (or 2) is easy to understand and perform. But there are 3 notes on it
1. You should find Full eMMC image for your phone or the one who will dump his phone's image for you
2. All the ID's, i.e. IMEI, MAC's etc and current User Data will move from that image to your phone.
You can make a user data wipe (Hard Reset) to destroy user data and get a 'factory state' phone later.
I do not know a way to patch IMEI/MAC's back to your originals for a while (do not have phone on my hands for experiments),
but sure these ID's are stored on some of the 'unique' partitions, listed in AndroidForums topic and you can find and extract this partition (unless it damaged) from your damaged eMMC image and flash it to the recovered phone. by any method (directly to the eMMC, using FastBoot mode, using ADB/Linux DD commands). It's theory, that I can't revert to the practice for a while.
3. YOU SHOULD NOT TO ASK A MAN, WHO WILL AGREE TO DUMP HIS PHONE IMAGE FOR YOU TO USE MSImage LOADER METHOD TO SWITCH PHONE TO THE QHSUSB_DLOAD 9006 MODE!!! Otherwise he will DAMAGE HIS GPT AND MODEM FW and you BOTH will get 2 NON WORKING phones instead of 1!!!
There are another methods available to switch this phone to the eMMC DLOAD mode while it resides in the working condition (unless SBL is able to load). The first is to hold both VOL keys at the powering up.
Switch phone off, remove and insert battery to be on the safe side, then hold down VOL+VOL- and press Power Key, then connect USB cable. Other options is to hold VOL keys and connect USB cable without Power key or hold keys and connect USB cable without battery. However these options, most probably will bring QDLoader 9008 mode related to the PBL instead of QHSUSB_DLOAD 9006 mode related to the SBL. That's why if your phone have GPT or SBL structures you can't get it into the QHSUSB_DLOAD 9006 mode unless you will flash MSImage (containing GPT and all SBL-related code) using described procedure.
So, please NOTE one more time YOU SHOULD NOT flash MSImage loader to the working phone! You will damage GPT and get phone to the non working condition!
Another way to switch WORKING phone to the QHSUSB_DLOAD 9006 mode id to use software switcher like the ones, that can be found in QPST eMMC Flashing app and QPST Memory Debug app. Search by google for a detailed manuals with screenshots how to do it (switch to DLOAD) with any Qualcomm based phone (You can try with any, but not all the phones will switch because of customizations!)
There are some other methods circulating around how to force particular WORKING Qualcomm based phones switch to DLOAD mode (using ARM native code app / loader or send command to the Debug port of the modem).
Upon the eMMC image creation you should disconnect working phone fro the USB cable and reboot it to switch back to the normal mode., Just hold Power key for a long time or remove and reinsert the battery.
You should reserve 15-20 minutes of time to perform full eMMC backup procedure.
Upon your damaged phone will switch to the QHSUSB_DLOAD 9006 mode using MSImage loader,
you can simply write one's full working phone's eMMC image using HDD Raw Copy Tool.
Just write from Image file to the eMMC device, then disconnect phone, reset it (reinsert battery) and switch it on.
Phone will boot identically to the donor phone. Perform further generic recovery procedures to revert to your phone to the required condition. You may switch is to the DLOAD mode again using 'normal' way and continue to perform eMMC editing, particular partition images writing, patching, etc.
Option 3 (manual image combining without one's working full image) is much more complicated to proceed, but there are almost all the required data can be found around. Get the original GPT (and GPT backup) from the AndroidForums factory images or look for the GPT backup at the end of the eMMC (It's standard. GPT should have a backup copy at the end of media and eMMC holds this backup, look for it). If you will find GPT backup, try to compare it with ones from the factory images from the AndroidForums.
It will clear for you is your previous FW have had same GPT partition structure and find differences in the partition sizes and locations between your old FW and particular Factory FW. This will help you to extract unique and/or any other req'd partition images from your broken full and inject them to the new full, you building up for whole phone flashing. Use DMDE Disk Editor (Free version is absolutely enough, unless you would like to mass recover files from your data partition with it). It will show you all the GPT structures, their sector ranges. It will help you to locate and extract particular partition Upon correct GPT written to the device (or your new image preparation), you can start to write partitions at their dedicated places. Once you have checked (and/or fixed) all the partitions your phone is ready to swich on. In most cases you have great chance to recover without one's full. The only condition all the small 'unique' partitions that is not included to the factory FW images should be NOT damaged. Please note, that many people reported that damaged/incorrect ModemSTx (modem data / NVRAM) erasure on THIS PARTICULAR PHONE will lead to the working partition recreation (assume w/o IMEI loss) and could be used as one of the NVRAM fixation techniques.
So you should have at least be able to extract important ID's (may be a few others) partition(s) and inject them to your new image (or directly to the eMMC).
That's why you should NEVER start to the recovery (eMMC writing) UNLESS YOU HAVE MADE A BACKUP COPY OF THE DAMAGED eMMC IMAGE!
Sure in 99% you will recover your phone whether you will find one's full (simple) or your will be able to rebuild it using factory (others, why not?) images and the part of your broken eMMC contents.
Good Luck!
I'm attaching here the required files. Please be careful!
Some people just DL files and do not copy the description.
The novices can broke their devices trying to do 'something idiotic'.
Please note, that attached GPT images are definitely for factory M070 FW for C811 version.
You can flash it to the any compatible versions (like CA-201L) but I don't know, will it be identical to your old partition scheme, so real unique partition data you could look to find mat be located at another offsets.
Check manually if you can and always make full broken FW eMMC image at first.
Get flesh QPST 2.7.425 here, thanks to drkcobra
http://forum.xda-developers.com/showpost.php?p=59235714&postcount=15
Or look the topic to find later vers (if any)
Direct Link:
http://www.mediafire.com/download/neeapht51ub2333/QPST.WIN.2.7_Installer-00425.1.zip
Important Update:
Casio C811 GPT images were broken due to the Windows decryption utility compilation problem.
File re-uploaded! Please update!
Click to expand...
Click to collapse
The Drive, Thank you so much, it 's working. My phone is work normally. Now I want to backup my image phone to restore when my phone was bricked by Qualcomm Qloader 9008, but my computer is recognize it as Gz'One Commando 4G LTE virtual serial port, not HSUSB qloader. What should I do?
To backup eMMC full image from the WORKING device you SHOULDN'T get it into the QDLoader 9008 mode nor flash loaders!!!
Loaders flashing will bring you into the QHSUSB_DLOAD 9006 but It WILL BREAK your GPT so you'll be forced to rebuild it to boot normally later!!! I don't know the name device is detected by the PC because I've never had this device in my hands, but I've explored it's FW's and code and found the way to recover it in many aspects including loader flashing (thanks go to nugiedha from Android Forums) IMEI/MAC/S/N patching (look in the 4pda topic), etc. The QDLoader mode has PID=9008, DLOAD mode has PID=9006. Diags port of the working device usually has PID=9025. USB VID should be 05C6 or may be customized by the device's OEM. There are decades of another PID's for the virtual Qualcomm chipset devices (PID's, e.g. Modem, RMNet, GPS, Mass Storage, MTP, etc)
To get eMMC dump from the WORKING device you should use QPST.
Configure QPST to make it find device's Diags COM port (Qualcomm HS-USB Diagnostics 9025). There are decades of the screened manuals on how to setup and work with QPST around. Then run QPST eMMC Download util (Windows start menu). Then select your found phone on some port and click 'Switch device to DLOAD' button. That's all! Device should switch to the QHSUSB_DLOAD 9006 mode in a few seconds. You should note the new mass storage device found in your Windows device manager. Please avoid occasionally click OK on the any of the device initialization requests Windows will bring to the screen (otherwise you'll damage your FW!). Then get some HDD low level managing tool and backup/restore any partitions/whole image from/to the device. HDD Raw Copy Tool is found good and reliable one for the whole disk image operations. There is also eMMC Raw Tool which is known to useful to backup/restore particular partitions, but I've found it's not reliable for some reasons. Sometimes it doesn't see any eMMC devices (it has too strong restrictions on the accepted USB medias trying to avoid non-eMMC devices) , sometimes it's known to some kind broken FW (many reports but I don't know whether it the tool's or user's failure). You can use DMDE/R-Studio/others professional data recovery utils to manage (recover) any data on the eMMC in the 9006 mode.
GPT images for Casio G'zOne Commando C811 (US Verizon) and Casio CA-201L (Korean) are slightly different.
Compare partition tables below. Most important difference is Modem FW partition size is 100MB for C811 vs 64MB for CA-201L. Modem FW partition is the first one so all the following partitions have the different sector offsets that is important for the successful recovery targets. Also there is ExtRes partition at the end of the C811 eMMC. It contains about a 200MB of the useless Verizon/Commando promotion videos so you can simply omit it when porting FW between devices (simply format it to the ext4 and use as a small 'secret' storage. )
Code:
CASIO C811 vs CASIO CA-201l GPT's
С811 CA-201l
offset : name : size offset : name : size
0x000000000000: partitions : 4608 0x000000000000: partitions : 4608
0x000004000000: modem : 104857600 0x000004000000: modem : 67108864
0x00000c000000: sbl1 : 131072 0x000008000000: sbl1 : 131072
0x00000c020000: sbl2 : 262144 0x000008020000: sbl2 : 262144
0x00000c060000: sbl3 : 524288 0x000008060000: sbl3 : 524288
0x00000c0e0000: aboot : 524288 0x0000080e0000: aboot : 524288
0x00000c160000: rpm : 524288 0x000008160000: rpm : 524288
0x000010000000: boot : 10485760 0x00000c000000: boot : 10485760
0x000014000000: tz : 524288 0x000010000000: tz : 524288
0x000014080000: pad : 1024 0x000010080000: pad : 1024
0x000014080400: modemst1 : 3145728 0x000010080400: modemst1 : 3145728
0x000014380400: modemst2 : 3145728 0x000010380400: modemst2 : 3145728
0x000014680400: nvbackup : 3145728 0x000010680400: nvbackup : 3145728
0x000018000000: system : 1342177280 0x000014000000: system : 1342177280
0x00006c000000: userdata : 11710496768 0x000068000000: userdata : 12113149952
0x000326000000: persist : 8388608 0x00033a000000: persist : 8388608
0x000326800000: cache : 734003200 0x00033a800000: cache : 734003200
0x000354000000: tombstones : 73400320 0x000368000000: tombstones : 73400320
0x000358600000: misc : 1048576 0x00036c600000: misc : 1048576
0x00035c000000: recovery : 10485760 0x000370000000: recovery : 10485760
0x00035ca00000: fsg : 3145728 0x000370a00000: fsg : 3145728
0x000360000000: ssd : 8192 0x000374000000: ssd : 8192
0x000364000000: fota : 536870912 0x000378000000: fota : 536870912
0x000384000000: ftm : 131072 0x000398000000: ftm : 131072
0x000384020000: crash : 131072 0x000398020000: crash : 131072
0x000384040000: f3 : 131072 0x000398040000: f3 : 131072
0x000384060000: log : 8388608 0x000398060000: log : 8388608
0x000388000000: extres : 467648000 0x000398860000: grow : 190430720
0x000398000000: grow : 0
Both binary GPT images are attached below
Update:
Earlier in summer I have fully discovered IMEI/MAC/etc ID storage locations and found the ways to recover them with a binary patch.
This unique phone (unless most other similar Qualcomm-based devices) has a very good feature. It has encrypted EFS/NVRAM partitions (ModemST1/ModemST2) seems to have binary structure identical or close to the reference Qualcomm design. But OEM have made extension to the modem FW. There is one more important partition in the eMMC called nvbackup. This partition contains most important NVRAM setting required to reinitialize NVRAM in the case of the fatal failure.
Binary data structure in the nvbackup is proprietary to the Casio-Nec OEM, however this partition is not encrypted in any manner. For a people familiar with a binary patching there is no problem to find and patch any ID's (IMEI/MAC/Serial/etc) to recover originals lost due to e.g. foreign full eMMC image uploading.
When the main EFS/NVRAM storage is intact, phone will work OK with ID's found there. Once EFS becomes some kind damaged modem FW will erase it and immediately reinitialize the new NVRAM inside. Then NVRAM will be filled with the default values, and ID's will be copied from the nvbackup partition. That's why many users reported (in android-forums etc) they have had ModemSTx partitions erased and got a working modem no other problems, that is simply impossible in any other similar devices. Once encrypted ModemSTx (EFS/NVRAM) some kind damaged it will bring any other device to the inoperable mode with lost IMEI and non-working modem (SP connectivity will be completely impossible). That's why this phone is unique and NVRAM failure-proof.
So to restore your original IMEI/MAC/etc just:
1. Get the working nvbackup image (from other's full or dump from your phone),
2. Find in image and patch all the ID'd you want to restore with the values from the device sticker.
3. Flash [back] nvbackup image to its place (partition). in the device.
4. Erase ModemST1/ModemST2 partitions (make the backup first to be on the safe side!)
5. Reboot device and check modem is working and ID's are in their places.
The big and detailed articles on the theme how to find and patch the particular ID's and other details you can find in the topic on the 4pda.ru Russian forums mentioned above. (in Russian, use google translator.) Look closer to the last pages (May-July 2016)
Moreover!
Yiou can use standard Qualcomm QPST application to work with NVRAM of this device through the Qualcomm Diag COM port.
Use QPST -> Software Download -> Backup/Restore interface to backup or restore the whole [main] NVRAM image to the Qualcomm QCN format file. You can binary patch this file before restoration to fix your ID's. There are many instructions around the internet how to patch QCN with the correct IMEI. You can also view QCN file and export its structure to the human-readable ASCII text form using QCNView utility (provided with QPST installation).
However if you will fix the main NVRAM with a correctly patched QCN uploading you will get the ID's (IMEI) you have written in. and your device will work with them unless EFS/NVRAM failure will occure. On the failure NVRAM will be reinitialized as I've described above and your ID'd will be filled in with the values from the nvbackup. Probability of the EFS failure is very small unless you do not perform 'massive' (dangerous) modem FW related 'experiments'. But this possibility persists. anyway. That's why it's preferred to patch nvbackup image neither QCN to permanently recover ID's.
Now upon a disclosure of all the most important boot and modem related facts, data structures and required code, this device can be recovered, probably, from ANY damaged state and condition, related to the SOFTWARE failure. All you have to do is 'heavily' read and try to understand thousands strings of the multiple articles. There is enough information to recover this device but many procedures are complicated even for an advanced users, who familiar with many advanced techniques and tools. 'The man can do anything' say people in my country. I've done the exploration and disclosure of all these complicated device internals even though I've never seen this device nor touched it with my hands. Sure, you will can fix this device once you willy want to.
Hi, TheDrive . Are you following this post? I have found instruction guide build AOSP for casio GZone from NEC in here: http://www.n-keitai.com/gpl/w/list/GzOne_COMMAND_4G_LTE_Jelly_Bean.html (instruction in procedure.txt). But I don't know how to flash this rom to my device, can you help me to do, please. This is screen from my computer with files built from this project:
https://goo.gl/photos/ARj54MHfThxsB5WV7, and this is some system file was built: https://drive.google.com/file/d/0B46dIM-QMF8pWHY4cXRNWS13LVU/view?usp=sharing
thaihoangduylinh said:
Hi, TheDrive . Are you following this post? I have found instruction guide build AOSP for casio GZone from NEC in here: http://www.n-keitai.com/gpl/w/list/GzOne_COMMAND_4G_LTE_Jelly_Bean.html (instruction in procedure.txt). But I don't know how to flash this rom to my device, can you help me to do, please. This is screen from my computer with files built from this project:
https://goo.gl/photos/ARj54MHfThxsB5WV7, and this is some system file was built: https://drive.google.com/file/d/0B46dIM-QMF8pWHY4cXRNWS13LVU/view?usp=sharing
Click to expand...
Click to collapse
1. Thanks for the sources. Casio closed original site and sources too.
I do attach all the files they published. It seems to be a small piece of all the sources they hide.
View attachment CasioGzOneC811_OpenSource.zip
2. I do rarely visit this topic. I do NOT have this device nor ever had nor even ever seen it live. You can find me via PM here or in the Russian 4pda.ru forums.
It's a good idea to write to this topic, but you should some kind aknowledge me to read. I've now subscribed to this thread and will try to visit if someone is looking for me.
3. I never compiled AOSP for any device. I do afraid and wanna escape when I see instructions I should get 10GB of sources, setup 1GB compilation environment and compile for 2-3 hours on the multicore PC.
I've explored your binaries .
I've no working Casio FW's by my hand now to compare
I don't know what is bootloader (w/o extension). Secondary booloader - SBL on these Casio phones as far as I can remember consists of the files SBL1/SBL2/SBL2/RPM/TZ. 3rd bootoader is aboot - it seems to be bootloader is identical to emmc_appsboot.mbn and EMMCBOOT.MBN so it should be the aboot image.
Aboot should provide fastboot finctionality, useful to flash FW, so I wouldn't touch (reflash) it w/o a reason.
Kernel should be the kernel built into the boot.img It useless for flashing.
Same about ramdisk.img
Same about recovery-ramdisk.img but this package should be built into the recovery.img not the boot.img. boot.img is a Linux kernel with a RAM disk ready to flash. boot.img seems to be correct, but I don't know will it work or hang.
system.img and userdata.img should be ext4 images of the system and data (userdata) partitions. I don't know are they full of required files or not.
Compare contents (unpack ExtFS images compare file lists and contents) with and original firmare images.
cache.img and persist.img seems to be empty ext4 images. I can't remember should factory persist image contain any data or not. Do compare.
You can find a variety of the factory and custom FW's in the 4pda.ru topic I've linked in the above messages. There are instructions there how to flash custom FW's too. That topic seems to be the place this device(s) most discussed in the world ever (over 250 pages). However this device was never officially sold in Russia at all. Idiot's in Casion/Nec failed to enter the most perspective market.
Russians (and CIS) ordered these devices from the USA (locked ones!) and other countries including used ones for an expensive prices. Our country is full of the wild nature places free for visiting and trip (unless you wouldn't do a something scary to the nature). That's why these phones, ready to fall-and-wet, are so required here, espacially by the professional and amateur fishers and hunters and simply trippers.
To flash use standard procedures, I don't know which mode is the best to use.
Images should be ready to flash in the standard fastboot mode. To use official upgrade method there was some util which flashed official FW's assembled into the one-big-file container. One user from AndroidForums have developed util to unpack them. I don't think you should write your util to repack it back.
To be on the safe side you should have all the backups, including full flash image and the particular partition images of the every partition.
In common people most probably custom some parts of the system image. More rarely the kernel (boot.img) and yet more rarely anything else.
It seems userdata partition contains 133MB of the initial data. In many devices userdata could be freely erased and formatted to make device 'factory new' in the FW part. This one contains something of amount. Probably some bundled applications and their data.
You can discuss also in some AOSP/other FW customization topics related to the recompilation of the sources. There should be more people there able to advice you with a source related aspects.
Sorry for an errors and mistyping, if any, no time to check and correct.
Hey guys!
Where are your reports, happy-end stories and thanks?
Files downloaded hundreds of times but no one tries to help
thaihoangduylinh.
Are there no people familiar with an Android compilation? (it dev's forum!!!)
Guys! Please help each other and God will help you!
TheDrive said:
1. Thanks for the sources. Casio closed original site and sources too.
I do attach all the files they published. It seems to be a small piece of all the sources they hide.
View attachment 4128870
2. I do rarely visit this topic. I do NOT have this device nor ever had nor even ever seen it live. You can find me via PM here or in the Russian 4pda.ru forums.
It's a good idea to write to this topi, but you should some king aknowledge me to read. I've now subscribed to this thread and will try to visit if someone is looking for me.
3. I never compiled AOSP for any device. I do afraid and wanna escape when I see instructions I should get 10GB of sources, setup 1GB compilation environment and compile for 2-3 hours on the multicore PC.
I've explore your binaries .
I've no working Casio FW's by my hand now to compare
I don't know what is bootloader (w/o extension). Secondary booloader - SBL on these Casion phones as far as I can remember consists of the files SBL1/SBL2/SBL2/RPM/TZ. 3rd bootoader is aboot - it seems to be bootloader is identical to emmc_appsboot.mbn and EMMCBOOT.MBN so it should be the aboot image.
Aboot should provide fastboot finctionality, useful to flash FW, so I wouldn't touch (reflash) it w/o a reason.
Kernel should be the kernel built into the boot.img It useless for flashing.
Same about ramdisk.img
Same about recovery-ramdisk.img but this package should be built into the recovery.img not the boot.img. boot.img is a Linux kernel with a RAM disk ready to flash. boot.img seems to be correct, but I don't know will it work or hang.
system.img and userdata.img should be ext4 images of the system and data (userdata) partitions. I don't know are they full of required files or not.
Compare contents (unpack ExtFS images compare file lists and contents) with and original firmare images.
cache.img and persist.img seems to be empty ext4 images. I can't remember should factory persist image contain any data or not. Do compare.
You can find a variety of the factory and custom FW's in the 4pda.ru topic I've linked in the above messeages. There are instructions there how to flash custom FW's too. That topic seems to be the place this device(s) most discussed in the world ever (over 250 pages). However this device was never officially sold in Russia at all. Idiot's in Casion/Nec failed to enter the most perspective market.
Russians (and CIS) ordered these devices from the USA (locked ones!) and other countries including used ones for an expensive prices. Our country is full of the wild nature places free for visiting and trip (unless you wouldn't do a something scary to the nature). That's why these phones, ready to fall-and-wet, are so requested here, espacially by the professional and amateur fishers and hunters and simply trippers.
To flash use standard procedures, I don't know which mode is the best to use.
Images should be ready to flash in the standard fastboot mode. To use official upgrade method there was some util which flashed official FW's assembled into the one-big-file container. One user from AndroidForums have developed util to unpack them. I don't think you should write your util to repack it back.
To be on the safe side you should have all the backups, including full flash image and the particular partition images of the every partition.
In common people most probably custom some parts of the system image. More rarely the kernel (boot.img) and yet more rarely anything else.
It seems userdata partition contains 133MB of the initial data. In many devices userdata could be freely erased and formatted to make device 'factory new' in the FW part. This one contains something of amount. Probably some bundled applications and their data.
You can discuss also in some AOSP/other FW customization topics related to the recompilation of the sources. There should be more people there able to advice you with a source related aspects.
Sorry for an errors and mistyping, if any, no time to check and correct.
Click to expand...
Click to collapse
TheDrive, You helped me a lot. Thanks for all your help efforts .
My device has so many bugs, I'm disappointed with the casio brand.
But I like casio gzone, I really want to recreate the rom for it, but it looks like it's not ok, it's beyond my ability
Same problem
TheDrive said:
Hey guys!
Where are your reports, happy-end stories and thanks?
Files downloaded hundreds of times but no one tries to help
thaihoangduylinh.
Are there no people familiar with an Android compilation? (it dev's forum!!!)
Guys! Please help each other and God will help you!
Click to expand...
Click to collapse
Hi Ive been trying to follow your instructions but Im completely lost. Casio gz c811 basically doing the encryption unsuccessful loop. And when I get to recovery the only appears is the dead android dude with no options
Described unbrick procedure was successfully performed by many people and should work unless hardware is OK. There are many cases, not only with this device, when eMMC catches bad blocks and/or fully blocks or hangs due to the internal structures damages (particularily translation tables like it often occures to the USB flash drives). There is no way to fix it mostly because eMMC and SD cards require professional equipement to deal with low level firmware initialization and capacity format. Factory utilities do not leak, like occures with UFD, because almost no one can execute them without a special factory card readers. There are the professional utils for the onboard eMMC management including some eMMC internal FW interaction like ATF-box. But in most cases internal eMMC failures lead to the expensive eMMC replacement (reballing) of the whole device drop.
If you suspect your eMMC have the hardware faiilures you should get you phone to the 9006 DL mode and when it will expose eMMC contents to the PC as a mass storage device try to test capacity for readability. At first make a full image for test and backup. If there will be no read errors, you can test device for write performance.
You have not described your actions to fix the problem and any results you got. If the described architecture and recovery procedures are too complicated for you you can ask some advanced friend to help you on site using provided instructions and discussions in other forums I've pointed to.
WOW Thanks for all the info
TheDrive said:
PLEASE CAREFULLY READ WHOLE MESSAGE and OBEY ALL THE PRECAUTIONS!
Please do NOT DO a thing unless you UNDERSTAND all the infos!!!
This was a total problem for a years. Casio/Nec have hidden original FW and loader required to flash the phone with damaged GPT or SBL (SBL level loaders. It's illegal in the context of consumer rights in many countries and violates GNU/GPL Linux/components licenses (independently of the fact the loaders itself are the Qualcomm/OEM proprietary SW, but we couldn't use and develop this particular Linux build w/o them). No FW sources were published. Casio-NEC JSC ****ed up the users and now gone from the market and closed support services/servers just upon closing. It's a shame for these respectable Japanese companies which reputation was clear for the decades. I don't care about any law aspects related to the JSC. Casio and Nec have used their brands to sell these devices and it's a shame for them all. I can't realize why could a web server support and source publishing cost any much for a billion corps. There are the laws in many countries requiring parts supply for a whole time of declared device serve period. Is Casio/Nec device's serve period now is set as 1 year only now?
If you have lost some money for an ineffective market policy, should your customers , respond for that?
These phines due to unique 'protected' design, good quality and parts are widely popular around the world far away from the official market places. Who have decided not to officially expand to these markets at the time?
There is good sales potential for a good quality protected phones (especially high branded) at the current time.
Adequate ads activity should provide a small but valuable market share.
Let's back to our problems
Now this, PBL-only bricking (QDloader 9008 only) problem has been partially fixed.
You should read my articles here (in English):
http://androidforums.com/threads/rom-stock-c811-m070-firmware-zip-file-4-1-2.878959/page-3
to understand internal eMMC architecture. Please realize you should try to UNDERSTAND, but not simply think how to quickly FIX your brick! You'll fix nothing unless you will understand what's going on and what's the parts responsible for which state.
Next step, go to the Russian 4dpa.ru forums and read my instructions how to flash loaders and get into the Qualcomm QHSUSB_DLOAD 9006 mode.
http://4pda.ru/forum/index.php?showtopic=497930&view=findpost&p=50105534
Sorry, Russian only for a while. You can translate pages with Google translator.
DO NOT DO a THING YET NOW! Simply READ and THINK!
Also read the discussion on that page and a few on the previous and the next pages. DL files (e.g. FW's, utils), you think could help you later on context. (4PDA reg req'd to DL attachments. It's isn't complicated, but service may ask you to enter a numeric capcha described as numeric-words in Russian. That's the problem for non Russian speakers. Once you get the problem note it ask you a random 4-cipher number. Try to translate somehow or request req'd files to upload here. Look may be these files are already uploaded on the AndroidForums (link above and other topics).
(If the messages/links will some kind shift by the time look for the manual posted on 03.06.2016, 02:28 GMT+3 and around)
Big thanks for the correct and the only working Casio C811 / CA-201L loaders go to the nugiedha @ANDROIDForums
http://androidforums.com/threads/casio-c811-soft-brick-possible-fix.967172/#post-7136788
Then realize simple thing. Loaders will NOT bring your phone back to the working condition immediately!!!
They will allow you to get the direct access to the eMMC and do WHAT YOU WANT with it. You can partition it as FAT32 UFD and then write your favorite pron there if you want, as you do it with your favorite UFD, but sure, it's simply useless. and stupid. and it will kill the rest of the data on the phone.
PLEASE NOTE! Upon an eMMC detection as a mass storage device in your PC, YOU SHOULD NOT OCCASIONALLY CLICK OK ON ANY WINDOWS REQUESTS ASKING TO INITIALIZE A NEW DRIVE/PARTITIONS!!! IT WILL DAMAGE DATA ON THE PHONE! BE CAREFUL!!!
THERE ARE MORE THEN 20 PROPRIETARY PARTITIONS ON THIS MEDIA WINDOWS SYSTEM HAVE NOTHING TO DO WITH!
Important! The first thing you should do is to BACKUP the whole image of the BROKEN phone including partition table (GPT) and all the partitions (intact or damaged) as a one big 16GB whole physical disk image to some partition that have enough free space. Do NOT try to backup to the FAT32 partitions. The maximum single file size there is 4GB.
I.e. DO a FULLFLASH backup, aka eMMC full backup image, etc., independently on the fact FW is broken at the moment!
Use HDD Raw Copy Tool form the HDDGuru forums or similar tools to make a full image backup.
You can use any data recovery / disk editing utils, like R-Studio or DMDE later to extract any data and/or whole partition images from there later. Please note, that after the MSImage loader flashing your original GPT will be replaced with a small GPT built into the loader, independently on fact was it correct or damaged at the moment of the failure.
However there is NO way to avoid this. There is NO any other way out to boot damaged phone from the QDLoader 9008 state (it's PBL mode) except JTAG involving tools. That's why you will not ba able to easily find all the partitions in the broken phone eMMC image. But you can scan the image (e.g. with R-Studio) and find the remaining partitions (except proprietary) on their places unless partition header/data was not damaged upon crash.
Next you have 3 options to recover the phone to the working condition:
1. Find Casio CA-201L or C811 FULL FLASH IMAGE (eMMC USER_PART) image dumped from phone placed in the same DLOAD mode
2. Find same image got using JTAG tools (in fact same as above)
3. Recreate partitions (write correct GPT) and all the partition data manually using parts of your backup and original factory partition images, most of which (for C811 and partially for CA-201L) you can find on the AndroidForums topic.
Option 1 (or 2) is easy to understand and perform. But there are 3 notes on it
1. You should find Full eMMC image for your phone or the one who will dump his phone's image for you
2. All the ID's, i.e. IMEI, MAC's etc and current User Data will move from that image to your phone.
You can make a user data wipe (Hard Reset) to destroy user data and get a 'factory state' phone later.
I do not know a way to patch IMEI/MAC's back to your originals for a while (do not have phone on my hands for experiments),
but sure these ID's are stored on some of the 'unique' partitions, listed in AndroidForums topic and you can find and extract this partition (unless it damaged) from your damaged eMMC image and flash it to the recovered phone. by any method (directly to the eMMC, using FastBoot mode, using ADB/Linux DD commands). It's theory, that I can't revert to the practice for a while.
3. YOU SHOULD NOT TO ASK A MAN, WHO WILL AGREE TO DUMP HIS PHONE IMAGE FOR YOU TO USE MSImage LOADER METHOD TO SWITCH PHONE TO THE QHSUSB_DLOAD 9006 MODE!!! Otherwise he will DAMAGE HIS GPT AND MODEM FW and you BOTH will get 2 NON WORKING phones instead of 1!!!
There are another methods available to switch this phone to the eMMC DLOAD mode while it resides in the working condition (unless SBL is able to load). The first is to hold both VOL keys at the powering up.
Switch phone off, remove and insert battery to be on the safe side, then hold down VOL+VOL- and press Power Key, then connect USB cable. Other options is to hold VOL keys and connect USB cable without Power key or hold keys and connect USB cable without battery. However these options, most probably will bring QDLoader 9008 mode related to the PBL instead of QHSUSB_DLOAD 9006 mode related to the SBL. That's why if your phone have GPT or SBL structures you can't get it into the QHSUSB_DLOAD 9006 mode unless you will flash MSImage (containing GPT and all SBL-related code) using described procedure.
So, please NOTE one more time YOU SHOULD NOT flash MSImage loader to the working phone! You will damage GPT and get phone to the non working condition!
Another way to switch WORKING phone to the QHSUSB_DLOAD 9006 mode id to use software switcher like the ones, that can be found in QPST eMMC Flashing app and QPST Memory Debug app. Search by google for a detailed manuals with screenshots how to do it (switch to DLOAD) with any Qualcomm based phone (You can try with any, but not all the phones will switch because of customizations!)
There are some other methods circulating around how to force particular WORKING Qualcomm based phones switch to DLOAD mode (using ARM native code app / loader or send command to the Debug port of the modem).
Upon the eMMC image creation you should disconnect working phone fro the USB cable and reboot it to switch back to the normal mode., Just hold Power key for a long time or remove and reinsert the battery.
You should reserve 15-20 minutes of time to perform full eMMC backup procedure.
Upon your damaged phone will switch to the QHSUSB_DLOAD 9006 mode using MSImage loader,
you can simply write one's full working phone's eMMC image using HDD Raw Copy Tool.
Just write from Image file to the eMMC device, then disconnect phone, reset it (reinsert battery) and switch it on.
Phone will boot identically to the donor phone. Perform further generic recovery procedures to revert to your phone to the required condition. You may switch is to the DLOAD mode again using 'normal' way and continue to perform eMMC editing, particular partition images writing, patching, etc.
Option 3 (manual image combining without one's working full image) is much more complicated to proceed, but there are almost all the required data can be found around. Get the original GPT (and GPT backup) from the AndroidForums factory images or look for the GPT backup at the end of the eMMC (It's standard. GPT should have a backup copy at the end of media and eMMC holds this backup, look for it). If you will find GPT backup, try to compare it with ones from the factory images from the AndroidForums.
It will clear for you is your previous FW have had same GPT partition structure and find differences in the partition sizes and locations between your old FW and particular Factory FW. This will help you to extract unique and/or any other req'd partition images from your broken full and inject them to the new full, you building up for whole phone flashing. Use DMDE Disk Editor (Free version is absolutely enough, unless you would like to mass recover files from your data partition with it). It will show you all the GPT structures, their sector ranges. It will help you to locate and extract particular partition Upon correct GPT written to the device (or your new image preparation), you can start to write partitions at their dedicated places. Once you have checked (and/or fixed) all the partitions your phone is ready to swich on. In most cases you have great chance to recover without one's full. The only condition all the small 'unique' partitions that is not included to the factory FW images should be NOT damaged. Please note, that many people reported that damaged/incorrect ModemSTx (modem data / NVRAM) erasure on THIS PARTICULAR PHONE will lead to the working partition recreation (assume w/o IMEI loss) and could be used as one of the NVRAM fixation techniques.
So you should have at least be able to extract important ID's (may be a few others) partition(s) and inject them to your new image (or directly to the eMMC).
That's why you should NEVER start to the recovery (eMMC writing) UNLESS YOU HAVE MADE A BACKUP COPY OF THE DAMAGED eMMC IMAGE!
Sure in 99% you will recover your phone whether you will find one's full (simple) or your will be able to rebuild it using factory (others, why not?) images and the part of your broken eMMC contents.
Good Luck!
I'm attaching here the required files. Please be careful!
Some people just DL files and do not copy the description.
The novices can broke their devices trying to do 'something idiotic'.
Please note, that attached GPT images are definitely for factory M070 FW for C811 version.
You can flash it to the any compatible versions (like CA-201L) but I don't know, will it be identical to your old partition scheme, so real unique partition data you could look to find mat be located at another offsets.
Check manually if you can and always make full broken FW eMMC image at first.
Get flesh QPST 2.7.425 here, thanks to drkcobra
http://forum.xda-developers.com/showpost.php?p=59235714&postcount=15
Or look the topic to find later vers (if any)
Direct Link:
http://www.mediafire.com/download/neeapht51ub2333/QPST.WIN.2.7_Installer-00425.1.zip
Important Update:
Casio C811 GPT images were broken due to the Windows decryption utility compilation problem.
File re-uploaded! Please update!
Click to expand...
Click to collapse
Well im try and go step by step on this and see if i can get this to work thanks for your help and time
---------- Post added at 10:11 AM ---------- Previous post was at 10:04 AM ----------
TheDrive said:
Hey guys!
Where are your reports, happy-end stories and thanks?
Files downloaded hundreds of times but no one tries to help
thaihoangduylinh.
Are there no people familiar with an Android compilation? (it dev's forum!!!)
Guys! Please help each other and God will help you!
Click to expand...
Click to collapse
still working on it will keep you posted
I would like to sacrifice my C811 for helping all of you to unbrick your devices
TheDrive said:
Please do NOT DO a thing unless you UNDERSTAND all the infos!!!
Click to expand...
Click to collapse
Thanks a lot for so useful infos, Drive :good:
I was made a brick a few years ago and today i saw a little bright of sun, when made a load by your instruction. Now i faced a small hitch - my device after loading by MPRG8960+8960_msimage almost load as a flash-drive, but in devices list i see NCMC_DLOAD
Already tried a drivers from google (com, mdm), qualcomm (most of them) for usb and com-devices - only ADB-drivers from google seems useful, but my system didnt finding an any flash-drives with them
Device working as NCMC_DLOAD even w/o battery.
Update - solutions for all newbies like me novices which will asking about this NCMC_DLOAD - guys, you should install G'zone_USB_driver.exe (found on 4pda.ru community - now i can't add link in my message)
Let's make an next steps and first experiment for me
Sampson78, congrats with your first personal unbricking experience! Knowledge is power and it couldn't be given 'easy'. You've shown your strong intention and got result!
Added native Windows driver from 4pda, you mentioned above.
На 4pda, конечно, читайте. Там подробнее все расписано, больше аспектов раскрыто, обсуждение куда шире и плодотворнее, еще и на русском. В частности там раскрыта структура хранения данных модема и методы работы, есть люди, которые девайс постоянно эксплуатируют и могут помочь (напомню у меня его никогда и не было). Однако, того, что здесь успел дать, достаточно чтобы кирпич поднять, если он аппаратно исправен. Вполне достаточно, еще и подробно очень. Затруднения лишь в том, что много незнакомой инфы для новичка и вся сразу, в один момент, а не как в школе, когда новое добавляют по чуть чуть. Понимание делает процедуру не то что, простой, но куда проще и понятнее. Все это тоже люди делали и для людей, там все разумно и понятно, хотя не всегда оптимально. Другое дело, что "власти скрывают" и втирают примитивные идиотские методы работы, дающие лишь малую долю контроля, хотя и никак не более простые или понятные. Аналогично работают почти все аппараты на Квалкомм, но везде свои нюансы, иногда очень значимые.
Hi guys,
I'm still owning an old i9300 and would like to flash CM14.1 to it (already have the same model running CM14).
This particular device is.. well kind of soft bricked - I think. I'm running out of ideas.
It shows the developer IMEI 00049... and no valid serial #
Not a single howto/patched kernel/app is solving this. I searched not only the xda-developers forum but all parts of g**gle I can handle the language
What I tried already:
- Installed the stock FW with ODIN (even after a full wipe of the internal eMMC partitions with CM13 as root )
- Downgraded to 4.0.4 ICS (and in this step I was able to re-create the serial # by manually patching nv_data and .nv_data)
- Removed /efs with mke2fs and let the device re-create it (it re-creates all the necessary files including nv_data.bin etc.) - without showing the IMEI
- Built a serial cable to talk to the modem (nice - but no solution for my problem)
- Maybe my biggest mistake: Tried (by accident) to restore an entire OS from a similar phone - INCLUDING /efs - to this phone. After that step my phone displayed a while the wrong serial #
My questions are:
- If I delete all the partitions of the internal eMMC (dd if=/dev/zero of=/dev/block/mmcblk0 - DON'T TRY THIS AT HOME). From *where* is /efs re-created? Where exactly is serial ä and IMEI stored?
- Is there a chance to bring this device back to live? I really want to bring this device to a repair shop, but the repair shop in my village does not even know what /efs or UART is - they are replacing just glasses and stuff
And: No, I don't have an /efs backup of this phone....
Have you tried flashing via kies?.
Yes you did brick it by cross flashing another devices identity.
If the device is an international btu you can try flashing the stock rom twice with a factory reset in between. If no joy then try kies again. The phone has lost who it is. You have to get it to remember.
The stock btu rom: https://drive.google.com/file/d/0B4vTiHTBB629OVlvY0pkcXN4ak0/view?usp=drivesdk
Beamed in by telepathy.
Hello shivadow,
shivadow said:
Have you tried flashing via kies?.
Click to expand...
Click to collapse
Yes - *plenty* of times (like 20..30) to rest the device to a defined state after a non-working [patched modem|EFS-repair|differnent firmware|...]
shivadow said:
The stock btu rom: [...]
Click to expand...
Click to collapse
Thanks a lot - but even this firmware does not help (I tried this - oh, before Christmas holidays, I think)
In the meantime I have learned a lot about the EFS folder:
- Never, ever restore a foreign EFS folder - it will not work
- Manually fiddling around with the nv_data bin is hard work (although I'm now able to switch the serial number back to the one printed under the battery)
- The device is fixable, but most probably not without a box - just because the necessary information is not freely available. With a free trial of a software I was able to reset the IMEI to a fake one and all of sudden I had network and was able to make calls
- With some AT+MSLSECUR/AT+IMEITEST stuff I'm not able to set the IMEI - it seems some certificate is missing (maybe the protection from Samsung for modifying the IMEI?). I was always stuck in the last step: actually write/set the IMEI does not work.
I think tomorrow I will bring the device to a repair shop in a larger town (they will have the knowledge I hope) and then I will compare broken EFS/fixed EFS (i.e. nv_data.bin) to learn even more.
So, you flashed another devices nvram and didn't have a backup of your own?.
Beamed in by telepathy.
shivadow said:
So, you flashed another devices nvram and didn't have a backup of your own?.
Click to expand...
Click to collapse
Exactly - it restored by mistake the backup to the wrong device. So not even parts of the original EFS folder - not even one single bit - is available. (Of course, the EFS folder of the wrong device is also not working...)
Looks like the phone will need to be repaired by a cell shop.
Hi guys,
the people in a repair shop were able to restore the original IMEI although undelete/forensics in an ext4 FS is not what I do every day it looks like:
- "they" replaced the nv_data.bin with another one (maybe some "empty" one?)
- the IMEI is definitely properly integrated (*#0011# menu is telling "IMEI CERTI: PASS and AT+MSLSECUR is now requesting a proper certificate)
Now I will start some investigation with the two (well, three) different versions of nv_data.bin
I'm still wondering *where* an i9300 is storing the identity after i.e. an eMMC replacement..
Has somebody particular informations of the RPMB area of the eMMC? Maybe I'm going to JTAG that device to find out...
Hello my freindes
i rooted my sm-c7000 and after download a custom rom it stuck on logo so i back to stuck rom but when i go to recovery mode it said "E:failed to mount /efs (Invalid argument)" and after search on google i found that i should flash esp by odin
so i need the EFS for C7000ZH please
+------------------------+
Thanks in advance
Best regards
@misyo.nour
EFS isn't a file but is a partition on your Android device that stores all the important data associated with your phone. For instance, these data include the IMEI number, Mac address of Wireless devices, important files of internet and product code, etc. Hence the EFS partition holds data to a specific phone, isn't generic, will say can't simply get transferred from one phone to another one.
jwoegerbauer said:
@misyo.nour
EFS isn't a file but is a partition on your Android device that stores all the important data associated with your phone. For instance, these data include the IMEI number, Mac address of Wireless devices, important files of internet and product code, etc. Hence the EFS partition holds data to a specific phone, isn't generic, will say can't simply get transferred from one phone to another one.
Click to expand...
Click to collapse
is there any way to fix it so i can open wifi and blutooth ??
btw sim card working fine
Hi everyone and Happy New Year,
I am trying to open ROM_0 file created with SP Flash tool. I have tried ROM explorer 0.9.1, I have tried various option converting with simg2img and opening with 7zip but nothing has worked so far.
The file is about 100GB and it is a SP Flash tool backup of my userdata on which I have a lot of images which i need to save.
I was using Dot OS 5.2 general image and a message popped up about trying Android 12 and I have clicked on it just to get rid of it but I assume it has triggered a download. My phone crashed yesterday evening when I started the cmera app and once restarted it was in a boot loop mode stuck on the dot os logo.
So far I have tried various options unsuccessful - I have reflashed the image which I originally flashed, I have set the partitions active - a and b and reverted to the initial active one which was "a".
I have also flashed system.img (with the treble general image) but still it is in a boot loop mode.
I have just decided to flash back the super.img image from the stock and guess what - still stuck.
Flashed the stock boot.img again thinking there might be an issue with the kernel but that didn't help.
I understand that it is the case of fully flashing back the stock ROM which will lock the bootloader and delete all my userdata in order to have the phone back.
However the phone IS NOT important, the ONLY IMPORTANT thing are the images in the userdata.
I have created the backup of it straight after the boot loop appeared. Tried to read here on XDA but it is not clear what format is that file and how I can access the data on it.
Looked for a recovery partition but there is none. Potentially hidden as you can get into stock recovery via fastbootd. But the options there are only to wipe the partitions/reset.
The phone is Umidigi Bison Pro and I have been having all but troubles with it.
Any help greatly appreciated it.
Regards
s80_gad said:
Hi everyone and Happy New Year,
I am trying to open ROM_0 file created with SP Flash tool. I have tried ROM explorer 0.9.1, I have tried various option converting with simg2img and opening with 7zip but nothing has worked so far.
The file is about 100GB and it is a SP Flash tool backup of my userdata on which I have a lot of images which i need to save.
I was using Dot OS 5.2 general image and a message popped up about trying Android 12 and I have clicked on it just to get rid of it but I assume it has triggered a download. My phone crashed yesterday evening when I started the cmera app and once restarted it was in a boot loop mode stuck on the dot os logo.
So far I have tried various options unsuccessful - I have reflashed the image which I originally flashed, I have set the partitions active - a and b and reverted to the initial active one which was "a".
I have also flashed system.img (with the treble general image) but still it is in a boot loop mode.
I have just decided to flash back the super.img image from the stock and guess what - still stuck.
Flashed the stock boot.img again thinking there might be an issue with the kernel but that didn't help.
I understand that it is the case of fully flashing back the stock ROM which will lock the bootloader and delete all my userdata in order to have the phone back.
However the phone IS NOT important, the ONLY IMPORTANT thing are the images in the userdata.
I have created the backup of it straight after the boot loop appeared. Tried to read here on XDA but it is not clear what format is that file and how I can access the data on it.
Looked for a recovery partition but there is none. Potentially hidden as you can get into stock recovery via fastbootd. But the options there are only to wipe the partitions/reset.
The phone is Umidigi Bison Pro and I have been having all but troubles with it.
Any help greatly appreciated it.
Regards
Click to expand...
Click to collapse
May I'm wrong, but I guess that if you didn't give it an extension then the file doesn't have a format; when you make a backup of a partition using SP Flash tool you should give it an extension, for example userdata_backup.img will work, in some devices, for some partition the .bin extension is used.
And to restore the device to a working state without losing data you could flash the stock ROM unchecking the userdata partition and using Download only option won't re-lock your bootloader.
If actually your userdata was not overwritten you still can try a second attempt to preserve it using mtk-client, search for it in GitHub, also consider what I stated about re-flash your original ROM preserving the userdata partition.
Thanks SubwayChamp, I appreciate your comment.
I have tried .img, .bin, ext4 etc but cannot open it - I am not sure if there is another application that can convert it in a readable format or maybe if we can mount it and access the files.
I had the impression that if you flash the stock rom the bootloader is locked and you loose everything.
But thanks for your advice - I will flash everything apart from the userdata partition which is last in the order anyway. Should I select or deselect the preloader partition- will that make a difference?
Regards
Just flashed the full stock rom without the userdata partition - still stuck on the logo in a boot loop . I really need to open the userdata backup file from SP flash tool as I feel I have to do a full reset/wipe.
Any other suggestions about explorer for the sp flash dump file, please?
Regards
s80_gad said:
Just flashed the full stock rom without the userdata partition - still stuck on the logo in a boot loop . I really need to open the userdata backup file from SP flash tool as I feel I have to do a full reset/wipe.
Any other suggestions about explorer for the sp flash dump file, please?
Regards
Click to expand...
Click to collapse
No, I didn't say to change the extension now and try it in various format, unfortunately I feel that if you didn't give you the extension at the time to make a backup then the file is unreadable, what I mean is that when you make the dump through SP Flash tool you have to give to the file a name and an extension, not letting it as is offered by SP Flash tool, for example you did see the name ROM_0 or similar, but you have to give it a name and an extension, in this case userdata_backup.img would work.
Did you check mtk-client?, you can read (dump) the userdata partition through this CLI tool, and after that you can restore it at any time.
Using the download option (only) you never re-lock your bootloader.
But wait a minute, keep in mind that your device is A/b, so you have to double-try all the things, for example, if you want to flash a specific partition like boot you have to be sure in which partition you are right now BUT unfortunately you don't know which partition is the working one, so better use fastboot to flash the missed partition, target to both slots.
And what about the option to get to a custom recovery? (I guess you had it previously to flash CR Droid) either taking a backup of userdata or re-flashing the same CR Droid that was functional previously.
Thanks SubwayChamp for your reply.
So I will try to dump the userdata again then - I still haven't touched it so I hope the partition and the data on it is fine.
I assume it is that mtkclient you are referring to. Will see if I can get some time today to try the live cd first as I am on Windows at this moment.
So my device is indeed A/B - the system is on "a" and I have flashed dot os using fastbootd and overwriting the system.img within the super.img. It worked fine for about 20 days until that crash (I only assume it is due to the update - nothing else has happened that could create trouble).
Also tried to set the b partition active but didn't help so switched back to "a".
Unfortunately there is no recovery partition, from what I learned the recovery is within the boot img. I have tried to load temporary unofficial twrp - fastboot boot twrp.img - and the first step is ok, but then it crashes. so no luck to load custom recovery even temporary in order to save the userdata on sdcard.
Tried to get to the contents trough adb shell but while some directories are listed, I get access denied to the userdata - I think maybe the links are broken?
I will try with the mtk to see if I can back it up - and what I'll do is I'll flash the full stock rom including the userdata and potentially will try to flash the old userdata through fastboot or sp flash or mtk.
TBH I don't understand why the phone is still in a bootloop - can't be only because I haven't cleared the userdata?
Regards
s80_gad said:
Thanks SubwayChamp for your reply.
So I will try to dump the userdata again then - I still haven't touched it so I hope the partition and the data on it is fine.
I assume it is that mtkclient you are referring to. Will see if I can get some time today to try the live cd first as I am on Windows at this moment.
Click to expand...
Click to collapse
It works on Windows though.
s80_gad said:
So my device is indeed A/B - the system is on "a" and I have flashed dot os using fastbootd and overwriting the system.img within the super.img. It worked fine for about 20 days until that crash (I only assume it is due to the update - nothing else has happened that could create trouble).
Click to expand...
Click to collapse
The issue was originated due to the lack of the other system files that also occupy this space; vendor, odm, product (may vary depending on the device), can be fixed flashing the super.img using fastbootd again.
s80_gad said:
Also tried to set the b partition active but didn't help so switched back to "a".
Unfortunately there is no recovery partition, from what I learned the recovery is within the boot img. I have tried to load temporary unofficial twrp - fastboot boot twrp.img - and the first step is ok, but then it crashes. so no luck to load custom recovery even temporary in order to save the userdata on sdcard.
Click to expand...
Click to collapse
Yes, this device doesn't have a dedicated recovery partition, but it is placed in a tiny portion of the boot image (usually the ramdisk) you can try by flashing the TWRP image onto the boot partition (flashing, not booting only) then boot to it, do the stuff you need through TWRP, from there you could solve the bootloop. To can boot to Android again you should need to flash a boot image.
s80_gad said:
Tried to get to the contents trough adb shell but while some directories are listed, I get access denied to the userdata - I think maybe the links are broken?
Click to expand...
Click to collapse
No, it's encrypted.
s80_gad said:
I will try with the mtk to see if I can back it up - and what I'll do is I'll flash the full stock rom including the userdata and potentially will try to flash the old userdata through fastboot or sp flash or mtk.
TBH I don't understand why the phone is still in a bootloop - can't be only because I haven't cleared the userdata?
Regards
Click to expand...
Click to collapse
When you flashed a system image onto the super partition the other partitions that are set dynamically didn't find a place to be recreated or couldn't play its role, added to this, a different system image that which is contained in the super image can differ in sizes either logical and/or dynamical (virtual sized).
SubwayChamp said:
The issue was originated due to the lack of the other system files that also occupy this space; vendor, odm, product (may vary depending on the device), can be fixed flashing the super.img using fastbootd again.
Click to expand...
Click to collapse
Flashed already the original stock rom super. img and everything else apart from userdata - it doesn't work.
see below
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
SubwayChamp said:
Yes, this device doesn't have a dedicated recovery partition, but it is placed in a tiny portion of the boot image (usually the ramdisk) you can try by flashing the TWRP image onto the boot partition (flashing, not booting only) then boot to it, do the stuff you need through TWRP, from there you could solve the bootloop. To can boot to Android again you should need to flash a boot image.
Click to expand...
Click to collapse
Tried to flash it - it just restarts the phone straight away - in fact replaced it with sp flash tool as well which recognises only the "a" partition and flashes it there.
SubwayChamp said:
No, it's encrypted.
Click to expand...
Click to collapse
I see
SubwayChamp said:
When you flashed a system image onto the super partition the other partitions that are set dynamically didn't find a place to be recreated or couldn't play its role, added to this, a different system image that which is contained in the super image can differ in sizes either logical and/or dynamical (virtual sized).
Click to expand...
Click to collapse
I am guessing this is why I have to reflash the whole rom incl userdata in order to make the phone usable.
What I'll do is I'll try to dump userdata with mtk and then will reflash everything with the stock rom ()hopefully the phone will boot) and then will flash the dumped userdata with mtk. Hopefully that will work.
I'll see if I can somehow mount the mtk .bin file to see if I can get to the contents of it
Will have to use the live dvd as I have win 7 and python 3.9 cannot run on win 7.
EDIT: Can't start anything through the live dvd - is there any workaround for win 7 or is there a direct executable file which I can get to start the mtkclient?
Regards
Hello,
I also have an Umidigi Bison Pro that I am going to use as a daily driver. (It's a pity that it's unpopular it would be a great device for modding, it's cheap, rugged and has source code availability of the official ROM and kernel). I created a Telegram group about this phone if you want to join is https://t.me/UmidigiBisonPro
About your problem you can read this guide (it describes how to backup and extract from the file created by SP Flash Tool even the partitions that not visible such as the b slots) https://www.hovatek.com/forum/thread-21970.html
To give you an idea on my Bison Pro a total of 52 partitions were extracted.
If you have the full backup from before the bootloop (before the upgrade, when it was still working) my advice is to restore all partitions.
I consider myself a novice regarding modding but it is likely that after the upgrade the userdata partition is no longer readable.
I have read that you should not update the GSI ROMs but repeat the whole flash sequence.
I also recommend removing the forced encryption of the userdata partition (you can do this when rooting) to avoid exactly these problems where you have the partition backup but not the decryption key.
s80_gad said:
Flashed already the original stock rom super. img and everything else apart from userdata - it doesn't work.
see below
View attachment 5499133
Tried to flash it - it just restarts the phone straight away - in fact replaced it with sp flash tool as well which recognises only the "a" partition and flashes it there.
I see
I am guessing this is why I have to reflash the whole rom incl userdata in order to make the phone usable.
What I'll do is I'll try to dump userdata with mtk and then will reflash everything with the stock rom ()hopefully the phone will boot) and then will flash the dumped userdata with mtk. Hopefully that will work.
I'll see if I can somehow mount the mtk .bin file to see if I can get to the contents of it
Will have to use the live dvd as I have win 7 and python 3.9 cannot run on win 7.
EDIT: Can't start anything through the live dvd - is there any workaround for win 7 or is there a direct executable file which I can get to start the mtkclient?
Regards
Click to expand...
Click to collapse
Sorry for delay, I didn't receive any notification on this (or I didn't notice it), I hope you sorted out your issue, if not, let me know.
SubwayChamp said:
Sorry for delay, I didn't receive any notification on this (or I didn't notice it), I hope you sorted out your issue, if not, let me know.
Click to expand...
Click to collapse
I didn't received notification too on your message and I found out on profile account that the notification for new message on a thread are default disabled.
I recently had some problems and experimented with partitions.
Reducing the possible cases I think the decryption key for the userdata partition might be in these partitions: super , misc , nvdata , nvcfg , md_udc
and I noticed that if one of them is corrupted/different version the dm-verity check fails (in my case it is written on the screen) and it was necessary to reflash all partitions except userdata (I don't know if there is a faster combination, from the few tests done in this case I didn't find any)
Do you have more information about where the decryption key might be between those partitions?
I have made a brief description of the role of all the partitions encountered but I still don't know some of them:
boot_para
gz_a (/ gz_b)
md_udc
otp
spmfw_a (/ spmfw_b)
sspm_a (/ sspm_b)
teksunhw_a (/ teksunhw_b)
Werve said:
I didn't received notification too on your message and I found out on profile account that the notification for new message on a thread are default disabled.
I recently had some problems and experimented with partitions.
Reducing the possible cases I think the decryption key for the userdata partition might be in these partitions: super , misc , nvdata , nvcfg , md_udc
and I noticed that if one of them is corrupted/different version the dm-verity check fails (in my case it is written on the screen) and it was necessary to reflash all partitions except userdata (I don't know if there is a faster combination, from the few tests done in this case I didn't find any)
Do you have more information about where the decryption key might be between those partitions?
I have made a brief description of the role of all the partitions encountered but I still don't know some of them:
boot_para
gz_a (/ gz_b)
md_udc
otp
spmfw_a (/ spmfw_b)
sspm_a (/ sspm_b)
teksunhw_a (/ teksunhw_b)
Click to expand...
Click to collapse
Why do you think userdata has a decryption key? Unless the user set it in a backup done through a custom recovery or through the device itself, I don't think so, may I'm wrong, but which is your scenario?
SubwayChamp said:
Why do you think userdata has a decryption key? Unless the user set it in a backup done through a custom recovery or through the device itself, I don't think so, may I'm wrong, but which is your scenario?
Click to expand...
Click to collapse
Since the userdata partition is now usually encrypted either with FBE or FDE but once the system loads the files are readable and moveable even externally then it is clear that somehow the data has been decrypted precisely using the relevant decryption key, AES encryption usually.
So if the user has not specified any key this must be derived from the information already in the partitions from the factory.
Then by restoring the right combination of partitions the system can boot correctly by decrypting the userdata partition. Hence the tests and the report I wrote in my last post.
At the moment I was able to remove the forced encryption of the userdata partition by modifying super (specifically fstab present in the /vendor sub partition) but I would like to achieve the same systemless modification using Magisk (to be OTA compatible). Unfortunately, the options to remove dm-verity and forceencrypt have been hidden in the latest versions of Magisk to avoid problems with inexperienced uses.
Since I don't have a custom recovery on the Umidigi Bison Pro I can't force flag those options in the .magisk file so I have to find another way.
Werve said:
Since the userdata partition is now usually encrypted either with FBE or FDE but once the system loads the files are readable and moveable even externally then it is clear that somehow the data has been decrypted precisely using the relevant decryption key, AES encryption usually.
So if the user has not specified any key this must be derived from the information already in the partitions from the factory.
Then by restoring the right combination of partitions the system can boot correctly by decrypting the userdata partition. Hence the tests and the report I wrote in my last post.
At the moment I was able to remove the forced encryption of the userdata partition by modifying syper (specifically fstab present in the /vendor sub partition) but I would like to achieve the same systemless modification using Magisk (to be OTA compatible). Unfortunately, the options to remove dm-verity and forceencrypt have been hidden in the latest versions of Magisk to avoid problems with inexperienced uses.
Since I don't have a custom recovery on the Umidigi Bison Pro I can't force flag those options in the .magisk file so I have to find another way
Click to expand...
Click to collapse
Well, what I said is a different thing, the other user had a different interest than this. They did want to access to some data from a backup in a non-booting device, I referred to that, the userdata image backed up doesn't have an encryption by default, unless the user set one through a custom recovery, suppose that someone did take a backup from the userdata partition, this userdata image can be opened/readable for anyone with minimum skills and the appropriate tool.
In regard to your issue, I don't think, the userdata partition has any kind of restrictions to take OTA updates, most likely this resides in the bootloader, kernel or even a "silent/hidden" partition with no more functions than that.
As a side note, you should check some custom recoveries, specially in Xiaomi devices that easily allow taking OTA updates, for example I always can take OTA, when I use Orange Fox recovery, although I'm not interested, so I make updates manually, to be sure that all run fine.
SubwayChamp said:
Well, what I said is a different thing, the other user had a different interest than this. They did want to access to some data from a backup in a non-booting device, I referred to that, the userdata image backed up doesn't have an encryption by default, unless the user set one through a custom recovery, suppose that someone did take a backup from the userdata partition, this userdata image can be opened/readable for anyone with minimum skills and the appropriate tool.
In regard to your issue, I don't think, the userdata partition has any kind of restrictions to take OTA updates, most likely this resides in the bootloader, kernel or even a "silent/hidden" partition with no more functions than that.
As a side note, you should check some custom recoveries, specially in Xiaomi devices that easily allow taking OTA updates, for example I always can take OTA, when I use Orange Fox recovery, although I'm not interested, so I make updates manually, to be sure that all run fine.
Click to expand...
Click to collapse
The methodology I was referring to that is not OTA supported is to modify the super partition (the dynamic partition that from Android 8? contains system, vendor, product--for Project Treble) to disable the forced encryption of the userdata partition. In my case FBE (File Based Encryption) Android 11 encryption.
Even having disabled the dm-verity if you apply an OTA update the super partition is replaced with the one that does not have the modification to remove the forced encryption and from the tests I have done this refuses to read unencrypted partitions and asks to do a factory reset.
So, the userdata partition makes the OTA update problematic (it doesn't block it, but you lose your personal data).
I am sure that instead of modifying the super partition to disable encryption you can achieve the same result via Magisk and a modified boot partition.
Unfortunately despite many trials due to my inexperience with Magisk I could not do it.
I wanted to do all this to avoid problems as described in the case of this thread that is, have the userdata partition intact but not the rest to be able to describe it. But seems I must let the encryption and do a backup after every OTA update.
Werve said:
The methodology I was referring to that is not OTA supported is to modify the super partition (the dynamic partition that from Android 8? contains system, vendor, product--for Project Treble) to disable the forced encryption of the userdata partition. In my case FBE (File Based Encryption) Android 11 encryption.
Even having disabled the dm-verity if you apply an OTA update the super partition is replaced with the one that does not have the modification to remove the forced encryption and from the tests I have done this refuses to read unencrypted partitions and asks to do a factory reset.
So, the userdata partition makes the OTA update problematic (it doesn't block it, but you lose your personal data).
I am sure that instead of modifying the super partition to disable encryption you can achieve the same result via Magisk and a modified boot partition.
Unfortunately despite many trials due to my inexperience with Magisk I could not do it.
I wanted to do all this to avoid problems as described in the case of this thread that is, have the userdata partition intact but not the rest to be able to describe it. But seems I must let the encryption and do a backup after every OTA update.
Click to expand...
Click to collapse
If you want to apply an OEM vendor stock update then it is a restriction from the OEM itself, and if you want to apply a GSI based update, it's a different approach, not sure if the restriction is FBE related or if the userdata is encrypted or not but probably related to AVB.
There are some tools/scripts you should search for, that can unpack and repack super partition, maybe you find something in the ODM or product image, this is assuming that the super partition it is the culprit.
Just know that it's a nonsense that an order (script) to restore a specific partition, be placed just there, but in other partition.
You should check what the OTA update contains, try to catch the OTA update through some ADB script, then unpack it, and see inside.
Also, you can try backing up every partition, and restoring them one by one, seeing if it boots.
SubwayChamp said:
If you want to apply an OEM vendor stock update then it is a restriction from the OEM itself, and if you want to apply a GSI based update, it's a different approach, not sure if the restriction is FBE related or if the userdata is encrypted or not but probably related to AVB.
There are some tools/scripts you should search for, that can unpack and repack super partition, maybe you find something in the ODM or product image, this is assuming that the super partition it is the culprit.
Just know that it's a nonsense that an order (script) to restore a specific partition, be placed just there, but in other partition.
You should check what the OTA update contains, try to catch the OTA update through some ADB script, then unpack it, and see inside.
Also, you can try backing up every partition, and restoring them one by one, seeing if it boots.
Click to expand...
Click to collapse
I have already done these tests, not with an OTA update but with a different version of the firmware for all partitions, and set out the conclusions.
Obviously it's an OEM restriction since it left the forced FBE encryption on and the way it was created (so I guess also from AOSP) it refuses to read the userdata partition if it doesn't find it encrypted.