Develop Bugs

Building Stock Firmwares (Verizon Specifically)

Hey guys, I've been reading for a while now, finally decided to sign up.
I'm making some modifications to the Galaxy Tab, just playing around and seeing what all is possible. Before I go start deleting potentially important system files, I wanted to get myself a little 'brick insurance'. I'm looking to get a copy of the stock firmware for the US Verizon Wireless version of the Tab (SCH-I800). It is currently running DJ11.
I don't think it is available from either Samsung or Verizon currently, although Samsung HAS provided all of the source code. If I wanted to make a backup of the firmware, something that I could load from the SDCard (ideally, just give it one of those update.zip files) how would I go about doing that?
This is my current plan, tell me if I'm not on track here. I have downloaded the Android Froyo source code available on the Android site. I downloaded the SCH-I800_OpenSource files from Samsung's open source center. If I combine these files as described in the readme from Samsung, and then build the whole project, I should get some sort of "stock" software, in basically the exact same state that it was when I got it from Verizon. Does this sound right?
I want to be able to quickly revert back to like-new set up, so I would prefer to not have to use one of the modified European/International versions if possible. Is there any other trick to getting an unmodified firmware to revert to? Any suggestions?
Thank You

I don't think it'll matter until someone creates a new recovery image. If you could get a clockwork recovery image, you'd be a hero

DavidThompson256 said:
This is my current plan, tell me if I'm not on track here. I have downloaded the Android Froyo source code available on the Android site. I downloaded the SCH-I800_OpenSource files from Samsung's open source center. If I combine these files as described in the readme from Samsung, and then build the whole project, I should get some sort of "stock" software, in basically the exact same state that it was when I got it from Verizon. Does this sound right?
Click to expand...
Click to collapse
Not even close i'm afraid!
Samsung are only required to release the Linux kernel source. The actual OS is not licensed under a "copy left" license, so Samsung are under no obligation to release their customized Android code.
So, you could create your own AOSP build, but this would be absolute stock Froyo - no Samsung launcher, or any of their custom apps.
Regards,
Dave

Yaotl said:
I don't think it'll matter until someone creates a new recovery image. If you could get a clockwork recovery image, you'd be a hero
Click to expand...
Click to collapse
You can use odin or redbend_ua to flash firmwares, you don't necessarily need clockwork - although it would be nice!

Hey infamousjax,
Do you happen to have an update.zip for the verizon tab you can upload? I managed to ninjamorph my framework so nothing opens anymore. I must have used a file that was the wrong png format or something. Anyway I do have the backup framework-res.apk, but I am unsure on the "update-script" as I can't get programs on my tab at the moment.

ninja4hire said:
Hey infamousjax,
Do you happen to have an update.zip for the verizon tab you can upload? I managed to ninjamorph my framework so nothing opens anymore. I must have used a file that was the wrong png format or something. Anyway I do have the backup framework-res.apk, but I am unsure on the "update-script" as I can't get programs on my tab at the moment.
Click to expand...
Click to collapse
I have the Sprint version... and the stock recovery can't flash update.zips unless they are signed.

infamousjax said:
I have the Sprint version... and the stock recovery can't flash update.zips unless they are signed.
Click to expand...
Click to collapse
Yeah I just tried to make an update.zip and sign it with a test signer. Now when go into recovery and run the update.zip it freezes on an Android icon with an exclamation point.

ninja4hire said:
Yeah I just tried to make an update.zip and sign it with a test signer. Now when go into recovery and run the update.zip it freezes on an Android icon with an exclamation point.
Click to expand...
Click to collapse
Can you boot up regularly?

yeah, it's just that I can't open programs or the settings menu.
edit: I have been trying to do an update.zip, but I keep getting "E: signature verification failed". I have tried to different signers already...
This one
http://www.robmcghee.com/android/creating-an-android-update-zip-package/
and this one
http://www.londatiga.net/it/how-to-create-android-update-zip-package/

Your not going to able to sign it without Samsung's signatures... and good luck finding those

yeah I pretty much gave up. I called last night and got the verizon insurance. So now I'm just gonna wait a few days then tell them I dropped it and pay $80 for a new one.

just tell them it started bootlooping for no reason... they should replace it for free if its within 30 days

So it sounds as though I'm not really on the right track here, perhaps I don't need to recompile this thing myself. From some of the replies, I've gathered that there IS at least some way to create a backup of the firmware, in case I screw it up.
Can anyone point me to specific steps on how to do a backup for the Tab? I've seen several guides for other phones before, but I believe that each device is slightly different, and may take different steps. Any suggestions?
Thanks again.

For your stock recovery
Code:
cat /dev/block/bml8 > /sdcard/recovery.bin
For your kernel
Code:
cat /dev/block/bml7 > /sdcard/zImage

Thanks a lot, that info was really helpful!
So, unrelated now, but just kind of curious... is there a reference sheet somewhere or something that explains what each of the files in /dev/block is for? I know they are different sections of the filesystem.
I have about 60 different files in that directory, and was just curious to know what each of them was for.
Thanks again for all the info.

DavidThompson256 said:
is there a reference sheet somewhere or something that explains what each of the files in /dev/block is for? I know they are different sections of the filesystem.
Click to expand...
Click to collapse
What they represent is different devices, not different sections of filesystems. At best (without RAID or LVM) each device holds one filesystem. In unix, filesystems can be mounted at various points into the root filesystem to appear as a single namespace, but they will still be separate filesystems.
Under the block dir you will see anything that is a block device, anything that can be written to randomly, as opposed to a serial type of device. So, all the random access hardware on your device (SDCARD, NAND...) will be represented there except for your RAM. Each physical device will likely have partitions on them so, if a device is named xxx, xxx01 will likely mean partition one on device xxx. Sometimes the same device will appear with several names, one may be buffered access, the other may be raw.
Your internal NAND is likely on the same device, just different partitions of that device. Some of these partitions may not hold filesystems, they may hold other blobs such as a boot loader, or the kernel. To see which ones hold filesystems, you can type df in a terminal and you will likely see which devices are mounted where in the filesystem namespace.
As for the rest of the devices and partitions, they are very hardware device specific. And I don't own a Galaxy tab, so I can't help with that, sorry. But, I hope I didn't give you info you already knew and I hope it might have been at least somewhat helpful...

Docomo SIM unlock: Jup's Grand Theory of Permanent SIM Unlock

This theory now seems to be confirmed by number of successful applications & my additional research. It should be generally safe to try both experiments. However, it still requires you know basics of shell. Above all, backup. And as allways, I am not responsible for anything, I don't even exist, etc...
And if you test this, please provide feedback.
This post will be updated as needed. For update list see the end.
What you need
Rooted GNEX with perm unlock & generic IMEI by ****Docomo app from this thread: http://forum.xda-developers.com/showthread.php?t=1548210. If you bought Docomo device from Negri, you already have this "patch" applied & just need root.
4.0.4 based ROM, yakju and takju builds are tested. Feel free to try different versions but we know that 4.0.3 is different.
Some form of shell access to your device
Busybox helps, but is not really needed.
The basic theory of permanently unlocking gnex w/ IMEI intact
Theorems
lock status and your IMEI are contained in nv_data.bin files on gnex.
there are usually three nv_data.bin file: /factory/.nv_data.bak, /factory/nv_data.bin, /data/radio/nv_data.bin. The one in /data/radio is the one really used under normal operation, but the least important one. In some way, it gets updated during every boot (boot counter?) and if you destroy it, it will get replaced from /factory ones (I am not sure which one is preferred).
all of these files are signed and signature is in accompanying files with .md5 sum.
unfortunately, it's not clean md5, there is some seed added to it, so nobody knows how to generate them correctly.
From these follows
It would appear that on Galaxy S 2 and other phones you could get around SIM lock simply by editing nv_data.bin files. There are well known locations where one can find unlock status and some additional data and basically unlocking consists of resetting byte at 0x181469 with 0 (contains 1) and replacing about 30 bytes before that with 0xff. If you did this for /data/radio/, you'd get temp unlock, if you replaced files in /factory, you'd get permanently unlocked phone. Easy.
This also (partially) worked on 4.0.3 ICS for files in /data/radio, however /factory files are now protected by md5 checksum with unknown seed. Since 4.0.4 this md5 protection was extended to /data files. THIS IS UNCONFIRMED AS OF NOW.
md5 protection makes it impossible to tamper with those files unless one has a way to generate correct checksum. When system encounters files that have incorrect checksum, it will simply ignore them.
****DocomoV2 perm unlock correctly replaces nv_data.bin files with their unlocked versions (hex manipulation above) but where it fails is generating correct md5 files. Hence all the nv_data.bin files get ignored outright and gnex falls back to some nv_data.bin with generic IMEI that is obviously last resort and probably meant for developers. So unlock only works as side effect. On further reboots, /data/radio/nv_data.bin is correctly checksumed, so it's used, but it contains generic IMEI. On wipe, it's regenerated from fallback again.
If you have phone from negri that has permanent lock applied, you don't even have backup of your original DOCOMO locked nv_data.bin files. This may not be
true for all versions, but it's true for recent shipments from negri with ICS
4.0.4 and can be confirmed by checking byte 0x181469 at all three nv_data.bin
files. It will be 0x00 == unlocked. However, except for unlocking them, ****Docomo didn't do any damage to them, it just rendered them invalid from samsung point of view - checksums don't match.
So if we have way how to generate correct md5 files matching these, we will get unlocked phone with real IMEI. And thanks to little oversight on Samsung part, we do. This oversight is called log files.
Following tests assume that you have phone with permanent unlock of ****Docomo applied. Ie you have phone from Negri with generic IMEI.
1. Theory test (reasonably SAFE)
It's probably better to have phone in airplane mode for these tests. I did for some, didn't for others. But it may overwrite /data/radio if you don't. Switch it off only after reboot.
Log into your phone. su to root. I use adb shell, but any shell will work as
long as you can get root privileges.
Code:
$ su
# cd /data/radio/log
# cat nv.log
Check that it contains lines like this example (2 different at least):
Code:
Tue Apr 17 11:33:47 2012: MD5 fail. orignal md5 '24989da14a3ad550546d2d23254c8f03' computed md5 'adaa0bf9506d939d18d57f96c0c330a3' (rild)
hashes will obviously differ for each gnex. If you can't see these, you could try wiping /data/radio/nv_* (2 files) and rebooting. This will attempt to regenerate files from factory files. If then you still don't see lines, then either your phone hasn't been tampered with or my theory is incorrect. Let me know.
Code:
# cat /factory/nv_data.bin.md5
this will output another md5 hash. Try to find it in above log in column original md5. It should be there. If it is, congratulations, you have correctly f*&^%ed device. The line tells us that md5sum in the aforementioned md5 file is invalid. It also tells us what valid md5 should be! How kind of Samsung. Let's correct this "glitch". Copy somewhere the part in apostrophes after computed md5 on the SAME line that contains hash from above md5 under original md5 (32 characters, for example, if cat outputs 24989da14a3ad550546d2d23254c8f03, it will be adaa0bf9506d939d18d57f96c0c330a3 for above line). I will call it COMPUTED.
Code:
# cd /data/radio
# rm nv_data.bin nv_data.bin.md5
# busybox cp /factory/nv_data.bin .
# echo COMPUTED > nv_data.bin.md5
# chown radio.radio nv_data.bin*
# chmod 700 nv_data.bin*
So we're copying original file from /factory to /data/radio and creating brand new md5 file that contains hash matching this nv_data.bin.
Code:
# reboot
If you did everything correctly, you end up with your original IMEI after reboot. If you destroyed something in /data/radio, don't worry. The files in /data/radio will be regenerated if md5 sum doesn't match or if you delete them, you'll just end up with generic IMEI. Check the log file and try to figure out what happend. If it says default NV restored at the end with current timestamp, well, default NV is the generic one. If you end up with completely wiped IMEI, that usually means permissions of the files in /data/radio are incorect. If above procedure worked, no lines should be added to it, because /data/radio/nv_data.bin was correct.
Mention that we're only touching /data/radio/. This is mostly to prove theory. This file WILL get wiped on factory reset and you'll end up with generic IMEI again. So we just recreated, painfully, temp unlock of ****Docomo app, except that this version works for 4.0.4. But this is side effect just to prove the theory. The real goodie comes now:
2. Theory application (do at your OWN RISK)
You know what's coming anyway. You're smart guys. But first:
BACKUP your /factory off the device
BACKUP your /factory to the cloud
the best thing is to use tar from busybox (preserves file permissions), you can probably use recovery ROMs etc. Just make the good backup. If you damage your /factory/, you may screw your device and never get GSM access again unless paying somebody with SPTBox. There's NO SAFEGUARD unlike when you modify /data/radio. NONE. I hope you got it.
Remount /factory rw. I used root explorer, you can use command line, but you need write access. Do not touch nv_data.bin or .nv_data.bak files. They've been already fixed by ****Docomo and you really NEED them, so please, don't delete them. Also, remember that files starting with dot are treated as hidden by linux, meaning if you want to see them in output of ls, you need to use -a argument.
Now we just need to fix md5 sums. So do as above for data. Find matching lines in nv.log by original md5 and correct md5 sum in computed md5 part and
Code:
$ su
# cd /factory
# echo COMPUTED > nv_data.bin.md5
# chown radio.radio nv_data.bin.md5
# chmod 700 nv_data.bin.md5
# echo COMPUTED2 > .nv_data.bak.md5
# chown radio.radio .nv_data.bak.md5
# chmod 700 .nv_data.bak.md5
So yes, COMPUTED is the same as for /data/radio (it matches nv_data.bin), COMPUTED2 is different (and matches .nv_data.bak).
Remount /factory R/O (probably not needed, but it should sync it so recommended).
Wipe /data/radio/nv_* (2 files):
Code:
# cd /data/radio
# rm nv_data.bin nv_data.bin.md5
This is strictly speaking redundant, if you did the theory test before, since you already have correct files there. However, it will verify that everything is fine and it simulates what happens during factory reset. So wipe them.
Code:
# reboot
... and hope for the best. If you have original IMEI after that, you're probably unlocked forever and may forget about terminals. Try factory reset if you want, flash roms, your gnex is liberated. Go get a beer, it's worth it. If something broke, chances are you're back on generic imei, in which case, nv.log is your friend. And let me know.
Notes
it would be probably better to use "echo -n" instead of "echo", somone could give it try, but I used "echo" myself and it works. However, md5 sums have redundant newline at the end.
I am quite sure this will stop working on future firmwares. This is a loophole that will be closed once people at Samsung mention it (and I am pretty sure they monitor these forums, uhm, hello there). However, I believe that once you have complete set (nv_data.bin & matching md5 files), you're basically not distinguishable from stock sim unlocked phone, so you should be safe there. There's no 100% guarantee though - they are the guys that know their hardware inside out.
Backup /factory if everything works. SEPARATELY from previous backup. This may come handy in future as it contains /factory files matching unlocked version of you phone, so if you loose it, you can use it again.
If you run ****Docomo yourself, you might also want to backup /sdcard/.unlock_backup (or where ****Docomo creates its backup) or better yet, backup /factory off device before running ****Docomo. We, with Negri phones, don't have this luxury.
DISCLAIMER: I don't think this method can be used to spoof IMEI and that's a good thing. Some people claim they know how to change IMEI in nv_data.bin, but I am quite sure there are other security measures to protect it. So this can only return you your old IMEI. Which is good thing in my books (and probably evil in Samsung's, although they're just playing by carrier's tune here)
If this theory is confirmed, someone should write an app. It can be automated with grep or sed.
Updates:
Changed slightly commands in theory test to make sure that nv_data.bin has correct permissons. If it doesn't, you'll end up with wiped up IMEI (which is not really problem, this can be fixed, but you won't be able to get GSM connection until then) -- thanks cpxchewy for this
4/20 - Added Docomo to title, changed intro to reflect successful tests
4/26 - Added info about takju test.
4/27 - mention that files with dot are hidden

The theory test that I tried erased my IMEI and baseband completely. I wonder if it's because I used echo instead of echo -n? I'll try again after I restore from Nandroid (I tried it twice, and both time same results)
EDIT: oh I know why, on your tutorial you left out a line to chown radio.radio nv_data.bin Just did that and now it works!

very exciting news!!!!!!!

Tested and verified. Good job figuring this out man.
If you had a donate button I'd buy you a beverage ;D

hi can anyone build a app

jup007 said:
BACKUP your /factory off the device
BACKUP your /factory to the cloud
Click to expand...
Click to collapse
Hi, sory I'm really new on this..
How can I make a TAR backup of this folder? (I'm not sure how to do this with busybox)
I was only able to copy the entire folder to my pc. I "need" to do this backup before starting flashing anything.
thanks

Till an app is built, I wish some good soul could make at least a bash script to run it from computer or from a mobile shell...I am not good at using "grep" or "sed" command.
That would complete the excellent JUP insight on this issue.

cpxchewy said:
The theory test that I tried erased my IMEI and baseband completely. I wonder if it's because I used echo instead of echo -n? I'll try again after I restore from Nandroid (I tried it twice, and both time same results)
EDIT: oh I know why, on your tutorial you left out a line to chown radio.radio nv_data.bin Just did that and now it works!
Click to expand...
Click to collapse
Good info, thanks. I'll update the initial post. I used busybox cp which preserves permissions but if you use other methods, yes, you need to make sure the file has correct permission. It seems logical that when radio process can't read or write to it, it doesn't know how to read/update the file and just ends up with all zeros/question marks IMEI. So that's another phone state explained.

albsat said:
Till an app is built, I wish some good should could make at least a bash script to run it from computer or from a mobile shell...I am not good at using "grep" or "sed" command.
That would complete the excellent JUP insight on this issue.
Click to expand...
Click to collapse
I know. If nobody picks this up, I may write some script in future, but don't expect it to happen this week. I already lost enough time on this plus I believe it's good to test on people who know their way around bash first before writing an app/script. If you break something by hand, you probably have general idea how to fix it. If script breaks something, I will have to go into hiding.
It's not like there wouldn't be too much hurry anyway. Generic IMEI mostly works just fine. And this thread so far seems to confirm that permanent unlock & unique IMEI is possible. And rest assured, if it's possible, there will be automated way in near future. So those who don't dare to play with it by hand, you can still sleep more lightly now and survive on generic IMEI few more days.
etche said:
Hi, sory I'm really new on this..
How can I make a TAR backup of this folder? (I'm not sure how to do this with busybox)
I was only able to copy the entire folder to my pc. I "need" to do this backup before starting flashing anything.
thanks
Click to expand...
Click to collapse
Code:
# busybox tar -cvf /sdcard/factory.tgz /factory
This assumes you have busybox installed. It's good idea to do it while /factory is still read only mounted.
Then just on computer do:
Code:
adb pull /sdcard/factory.tgz .
and save it somewhere.

jup007 said:
I know. If nobody picks this up, I may write some script in future, but don't expect it to happen this week. I already lost enough time on this plus I believe it's good to test on people who know their way around bash first before writing an app/script. If you break something by hand, you probably have general idea how to fix it. If script breaks something, I will have to go into hiding.
Click to expand...
Click to collapse
It would be great to have a script just for the what you called 1. Theory test (reasonably SAFE) at least.
---------- Post added at 10:06 AM ---------- Previous post was at 09:27 AM ----------
Question please.
When I issue the command
# cd /data/radio/log
# cat nv.log
Click to expand...
Click to collapse
I get two lines with two different correct MD5. So in total it mentions 4 md5 sums.
Which is the correct one?

albsat said:
I get two lines with two different correct MD5. So in total it mentions 4 md5 sums.
Which is the correct one?
Click to expand...
Click to collapse
There should be two, that's correct. You need to run the next command I wrote in that post, # cat /factory/nv_data.bin.md5 . This will only match one of the lines (it must match exactly the code in "orignal md5" section on one line). That's your line and computed md5 there is the one that needs to be in md5.
The other line belongs to /factory/.nv_data.bak .

if i used temp unlock in ****docomo (keep original imei)
is this method also work ? and get a perm unlock?
or i have get a forever unlock 1st(wrong imei)

Hi,
Just to confirm that the first method worked perfectly. I managed to do it just by phone using terminal application and a file manager like ES File.
I will try the second and permanent method when I get back home.
Great job JUP!!!!
---------- Post added at 02:58 PM ---------- Previous post was at 02:13 PM ----------
@Jup
Another idea. Following the first temporary unlock method, I have this idea.
If we unlock temporary the files, can a backup of correct files from /data/radio be used again in case of a factory reset or new rom install? In such case, we can make a CWM package of these files and install it through CM recovery or through a file manager.
What do you think?
@Admin
Please make this thread a sticky. There are so many Docomo users that will be happy with Jup's work.

Wow, this is pretty incredible. I didn't think your theory would actually work but since it's confirmed by others this is fantastic.
I hope this method transcends what it is now.
Update: I'll be trying this method and I'll be willing to test out things should you need me. I'm not too confident in my ability but know how to follow explicit details.

albsat said:
@Jup
Another idea. Following the first temporary unlock method, I have this idea.
If we unlock temporary the files, can a backup of correct files from /data/radio be used again in case of a factory reset or new rom install? In such case, we can make a CWM package of these files and install it through CM recovery or through a file manager.
What do you think?
Click to expand...
Click to collapse
I am pretty sure this will work. Once you have correct set of files from /data/radio, you can make backup of them and restore them after wipe. Heck, I am quite sure this is what "condom" functionality of current fdocomo.apk does - it keeps backup of these files somewhere and can just restore them after wipe. No need to touch /factory at all. The only thing here is, you still have to do this restore manually after wipe. If you modify /factory, you should not have to worry and it may increase resale value of your phone quite a bit - if you have, for the same price, device that keeps IMEI after wipe and device that needs to run some wierd app, which will you buy?

ygvuhb said:
if i used temp unlock in ****docomo (keep original imei)
is this method also work ? and get a perm unlock?
or i have get a forever unlock 1st(wrong imei)
Click to expand...
Click to collapse
I don't think it will work with temp unlock.
But honestly, I don't really know how temp unlock of fdocomo apk works because negri phone I got was already perm unlocked. I believe it uses some vulnerability in 4.0.3 and earlier versions to get correct md5 sum for files in data, so more or less it does similar thing to theory test by different means. However, I don't know how it modifies the files in /factory - according to author, it does modify one, not the other. And this method relies on the fact that you have both of files in /factory (nv_data.bin & .nv_data.bak) are in unlocked state. Which is done by perm unlock.
Strictly speaking, you don't need fdocomo for this method to work. You could achieve same results by using hexedit and unlocking factory nv_data files by hand. It's just much more convinient this way.

thanks i will try this later

Just to confirm that even the second method worked perfectly. You can do all the procedure by your phone alone using a terminal and Root Explorer.
Thanks again jup007. Please add Docomo or Negri at subject. I think there will be more people interested.
Sent from my Galaxy Nexus using Tapatalk

I 2nd the proposal to please add Negri or Docomo to the subject line.
also, i 2nd the proposal to make this thead a sticky. there are so many people concerned about this.

Could also maybe clean up the instructions a bit and slim it down?
So I'm gonna try this out, but basically. Do we have to do theory 1 in order to do theory 2? or can we just go straight to theory 2 if we already have perm unlock with generic IMEI?
The backing up thru busybox code you put would also be helpful if you just put it in at Theory 2

T999L, failed unlock - now no imei, baseband nor nv_data

My tail of woe. From what I have read there is nothing that can be done but I thought I would ask anyhow.
I was overseas with an SGH-T999L, and took it to a man in a market to be unlocked. 2 hours later it was useless. The man said it would be OK once it was back in the US, but it wasn't. Obviously he didn't keep backups.
Dialing *#06# gives me "null/null".
I cannot turn on wifi (I slie the switch and it slides right back) but can turn on bluetooth, gps and nfc.
Baseband version is "Unknown"
Build number is JSS15J.T999LUVUBNC1
It appears that he used vRoot to get root.
According to the "odin screen"
CUSTOM BINARY DOWNLOAD: No
CURENT BINARY: Samsung Official
SYSTEM: STATUS: Custom
QUALCOMM SECUREBOOT: ENABLE
Warranty Bit: 0
BOOTLOADER AP SWREV: 1
I used this article from techglobal101.wordpress.com 2013/05/02/how-to-solve-no-service-on-samsung-galaxy-s3/ following the imei already corrupt steps to generate
the text file with the imei in it. However the NV Reader/writer has problems. Firstly *#7284# only gives me a choice of "Modem" or "PDA". However *#0808# does give me more options including "RMNET + DM + MODEM". The bigger problem is that the SPC code of 000000 is not accepted, so NV reader/writer can not access anything.
Looking in the /efs filesystem (using "adb shell" and "su" and "busybox find /efs -size +1000k" ) does not find any files larger than 1MB (I believe the nv_data.bin should be at least 2MB) so no original ".nv_data" file, no "nv_data.bin" nor "nv_data.bak". There are smaller files, for example there is a file /efs/imei/mps_code.dat, 3 bytes long containing TMB. The /efs partition is 13716 blocks in size and is only 33% full (4556 blocks in use).
I can use adb to install and uninstall packages, and copy files.
Things which look interesting to me in the output of "getprop" are (with a valid sim card installed)
[DEVICE_PROVISIONED]: [1]
[gsm.operator.alpha]: []
[gsm.sim,state]: [NOT_READY]
[gsm.sim.unknownready]: [1]
So far I have not done anything else. In particular I have not tried using ODIN to download a stock image, nor have I tried removing the files which are in /efs.
I also have not tried creating a 2MB file of NUL characters called /efs/nv_data.bin in the hope that that would at least advance the solution.
I would be pleased to get any good advice on what to do next. Please assume I know my way around a unix command prompt, but this is my first venture into the world of Android.

First thing, don't mess with the efs. It's not relevant to the issue at hand and sounds to be just fine. Most of the NV Data is stored on different partitions. Don't assume its the same as on other devices like many others seem to advise.
Second, download your stock firmware (NC1)(root66 firmware is ok), flash via Odin on your computer, and factory reset (will wipe internal sd). This often fixes these problems without having to touch the NV data.
Something tells me that whoever you took it to may have tried to flash the 4.1.1 modem to use our free unlock method. If so, that will cause the exact same thing you are experiencing now.
If after that it is still not fixed, PM me and I will try to help get your imei restored. We are not allowed to post information, tools, links or further discuss that here, so if it comes to that, I can only help you via PM.
Sent from my SAMSUNG-SGH-I747 using Tapatalk

2016 version (new fingerprint scanner, combined sim/sd)

Hey guys,
It seems more and more people are receiving the new version of the P8000:
- Stock Android 6
- New fingerprint scanner that is moved slightly higher and is able to unlock phone from screen-off (I confirm this is working)
- Sim 2 is combined with the micro-sd (I haven't tried whether you can have them both in at the same time)
- Somethings new about the display, since people are reporting errors with it after flashing older roms.
Warning: do NOT flash other roms. We have no way to unbrick the soft bricks yet!
---
Other topics that refer to this version:
http://forum.xda-developers.com/elephone-p8000/general/rom-p8000-t3431571
http://forum.xda-developers.com/elephone-p8000/help/stock-rom-p8000b-t3434477
http://forum.xda-developers.com/elephone-p8000/general/p8000-version-announced-t3346848
---
For development:
- The phone does not come pre-rooted. We have no way to flash custom recovery yet. Any tips for getting root? I've tried such tools as Kingo and vRoot, they don't work.
- We need the blocks file (scatter file) for SP Flash Tools. MTKDroidTools reports "unknown rom structure". Any help? Would love to start working on this.
Looking forward to hearing from others who have this version/who can help me with these questions.
Thanks!
Emile

Nice! Can you provide a dump from /system and /boot maybe?

BlueFlame4 said:
Nice! Can you provide a dump from /system and /boot maybe?
Click to expand...
Click to collapse
I would, if I knew how to. Any pointers?

Emileh said:
I would, if I knew how to. Any pointers?
Click to expand...
Click to collapse
Sure thing. On a rooted device, go into adb shell.
Then use "mount" command to check which partitions are mounted. One should be "/dev/block/platform/mtk-msdc.0/by-name/system" or similar. Use "dd if=/dev/block/platform/mtk-msdc.0/by-name/system of=/storage/emulated/0/system.img bs=1M" to dump the system to the internal sdcard to the file "system.img". If adb complains that bs=1M is an invalid option, try again without that one. A system dump can take some time where you will not get any feedback, so be patient there
Do the same for boot. So "/dev/block/platform/mtk-msdc.0/by-name/boot" should be the way to go for the path. I cannot tell the definite pathes on Android 6.0 but I am rather sure they are more or less like this.
If you run into troubles, just ask

BlueFlame4 said:
Sure thing. On a rooted device, go into adb shell.
Then use "mount" command to check which partitions are mounted. One should be "/dev/block/platform/mtk-msdc.0/by-name/system" or similar. Use "dd if=/dev/block/platform/mtk-msdc.0/by-name/system of=/storage/emulated/0/system.img bs=1M" to dump the system to the internal sdcard to the file "system.img". If adb complains that bs=1M is an invalid option, try again without that one. A system dump can take some time where you will not get any feedback, so be patient there
Do the same for boot. So "/dev/block/platform/mtk-msdc.0/by-name/boot" should be the way to go for the path. I cannot tell the definite pathes on Android 6.0 but I am rather sure they are more or less like this.
If you run into troubles, just ask
Click to expand...
Click to collapse
Thank you for your great instructions! The problem is that we've yet to achieve root on this device. We don't have a custom recovery for this version of the P8000 yet and other 'standard' methods of rooting don't work for me.
(I'm pretty solid in shell, so I'll do this afterwards, but I guess root is actually the first step).
// Edit to say: it does not come pre-rooted

Since the elephone support on facebook didn't realize there are two different versions of the P8000 available, I still need a ROM to unbrick my phone.

flo1k said:
Since the elephone support on facebook didn't realize there are two different versions of the P8000 available, I still need a ROM to unbrick my phone.
Click to expand...
Click to collapse
Ok, we know that, but doesn't really help us
Can you write them an e-mail?

I will do
Edit: OK, see if there will be an answer.

Thank you flo1k!

I have e-mailed as well, and would like to post on the Elephone forum, but don't seem to have access (because of minimum post count, I guess)
Anyone willing to ask for a ROM for the new P8000 on the forum there?

ROM Dump
@BlueFlame4
I can provide ROM dump in two versions:
1) a dump from adress 0000 0000 to 9d80 0000 (apr. 2.5 GB in one file)
2) a readback generated with the scatter.txt of the 'old' 5.1 stock ROM (apr. 2.8 GB seperated in 23 files)

FrauHofrat said:
@BlueFlame4
I can provide ROM dump in two versions:
1) a dump from adress 0000 0000 to 9d80 0000 (apr. 2.5 GB in one file)
2) a readback generated with the scatter.txt of the 'old' 5.1 stock ROM (apr. 2.8 GB seperated in 23 files)
Click to expand...
Click to collapse
The second choice looks promising

Maybe a stupid question
where shall I upload the files - any preferred webspace?
I'm uploading the files - because they contain my NVRAM I send the link as PM as soon as the upload is finished

FrauHofrat said:
Maybe a stupid question
where shall I upload the files - any preferred webspace?
I'm uploading the files - because they contain my NVRAM I send the link as PM as soon as the upload is finished
Click to expand...
Click to collapse
Are you sure we're talking about the same version of the P8000? Cause as far as I know there isn't 5.1 available for this version... Right?
Just checking thank you for your help in any case!! Really looking forward to it.
// edit: ah, you just used the old scatter file. But does that one work for this version?

Emileh said:
Are you sure we're talking about the same version of the P8000? Cause as far as I know there isn't 5.1 available for this version... Right?
Click to expand...
Click to collapse
No, there is only one Firmware available - the mysterious P8000_6.0_20160516.
Btw, this Phone contains a new mainboard model "K06TS-L-V2.0.3" - the 'old' mainboard is moder "K05T...."
// edit: ah, you just used the old scatter file. But does that one work for this version?
Click to expand...
Click to collapse
No, it doesn't work resp. the phone boots with this firmware, but the LCD-driver is the wrong one - the display only shows coloured lines and blurry spots. And there are probabely some more bugs ....

FrauHofrat said:
No, there is only one Firmware available - the mysterious P8000_6.0_20160516.
Btw, this Phone contains a new mainboard model "K06TS-L-V2.0.3" - the 'old' mainboard is moder "K05T...."
No, it doesn't work resp. the phone boots with this firmware, but the LCD-driver is the wrong one - the display only shows coloured lines and blurry spots. And there are probabely some more bugs ....
Click to expand...
Click to collapse
But if the phone boots with the firmware, doesnt that mean that the scatter file of the regular P8000 works? Since it flashes the firmware correctly.

The problem is that I was not able to flash the 'readback files' to the faulty phone.
When selecting 'Only Download' at SP-Flashtool I got the error "PMT... must be download"
When selecting 'Firmware Upgrade" I got some BROM error code
In both cases I used the same scatter,txt which I used to 'readback' the firmware from the working phone
Actually I have to correct my statement in post #15:
I flashed the faulty phone with the last 5.1 stock ROM (160711) - with this stock ROM the phone boots up but LCD (and probably more things) is not working.

I have actually gotten alot further
You have the use the scatter.txt from Android 6.0, which works perfectly fine. I have been able to extract boot.img, system.img and recovery.img that way (using Readback in SP Flash Tools)
Which ones do you need?
They probably flash fine (only thing I've flashed so far are custom recoveries, and although my ported PhilZ starts, I havent gotten it to mount anything.)
A little warning: don't use anything that has anything to do with Android 5.1. Those scatter files don't work

These are great news!
"Which ones do you need?"
Probably all of them

Ok this contains the scatter file, preloader, system.img, boot.img and stock recovery.img
https://ehaffmans.stackstorage.com/index.php/s/uKGKCir0BociydU
You need SP Flash Tools v5, select the scatter file first, then deselect everything, and only select these 4 and manually select the correct files.
Btw, the name of the preloader file is wrong, don't worry. It came from this phone
I am of course not responsible for anything!
Can you guys please confirm this doesn't contain anything personal? Like personal files or IMEI or something. Thanks!

no signal - a2lite 4gb

Hi,
I did something wrong with my A2 Lite, i've updated the Magisk boot file from the Magisk app. Caused my phone to stop booting Android.
So i tried reflashing it with Mi Flash in EDL mode. That worked but i don't have any signal when i put a SIM in.
It shows my provider in settings so it recognizes the SIM but doesn't do anything with it.
Tried 10.0.13.0 manually and via Mi Flash = no signal
Tried 10.0.2.0 via Mi Flash = no signal
Loaded TWRP, switch A/B = no effect
Does anyone have a clue what i can do now?
Looks like the IMEI numbers are 0.

terrorsource said:
Looks like the IMEI numbers are 0.
Click to expand...
Click to collapse
I don't know how you got here, but it looks like some important stuff was overwritten.
The mobile network is probably blocking you due to the invalid IMEI...
This is typically something that is stored only in the phone's flash. I'm not sure you'll be able to recover the phone.

a1291762 said:
I don't know how you got here, but it looks like some important stuff was overwritten.
The mobile network is probably blocking you due to the invalid IMEI...
This is typically something that is stored only in the phone's flash. I'm not sure you'll be able to recover the phone.
Click to expand...
Click to collapse
Is it possible to write back the IMEI's if i have them?

terrorsource said:
Is it possible to write back the IMEI's if i have them?
Click to expand...
Click to collapse
It might be. In theory. You'd need to know the format of whatever was overwritten.

You can't rewrite the IMEI, I've have that issue before and I created a guide on how to fix it
https://forum.xda-developers.com/mi...-to-fix-efs-corruption-sim-card-t3928910/amp/
Enjoy ?
You can download the latest rom and install it (ignore the rom that's in the guide it is outdated, but the rest of the guide stays the same).

Noam5651 said:
You can't rewrite the IMEI, I've have that issue before and I created a guide on how to fix it
https://forum.xda-developers.com/mi...-to-fix-efs-corruption-sim-card-t3928910/amp/
Enjoy
You can download the latest rom and install it (ignore the rom that's in the guide it is outdated, but the rest of the guide stays the same).
Click to expand...
Click to collapse
Thanks, will check it out the next couple of days.
I do see some websites/youtube video's of people/apps claiming it is possible by re-writing the QCN file...
I do know where i made a mistake, i tried to manually install all files in an image folder, including flashing a not-so-good QCN file...

terrorsource said:
Thanks, will check it out the next couple of days.
I do see some websites/youtube video's of people/apps claiming it is possible by re-writing the QCN file...
I do know where i made a mistake, i tried to manually install all files in an image folder, including flashing a not-so-good QCN file...
Click to expand...
Click to collapse
https://forum.xda-developers.com/mi-a2-lite/how-to/sim-network-solution-alternatively-t3914161
if this doesn't work ,pm me

nikoman1987 said:
https://forum.xda-developers.com/mi-a2-lite/how-to/sim-network-solution-alternatively-t3914161
if this doesn't work ,pm me
Click to expand...
Click to collapse
Works partially!
I cannot install the latest "QPST_2.7.453" due to "Installation errors".
If i try "QPST_2.7.422" i can restore the created QCN but i cannot select "Enable Multi-SIM" and it only restores IMEI-1

nikoman1987 said:
https://forum.xda-developers.com/mi-a2-lite/how-to/sim-network-solution-alternatively-t3914161
if this doesn't work ,pm me
Click to expand...
Click to collapse
Works now! both IMEI's are now shown in the settings.
IMEI SV is still at 0 though.
Your manual needs some work though.
Latest QFI: https://androidmtk.com/download-qualcomm-flash-image-loader-qfil
Enable Multi-SIM is not in all versions. I've used v2.0.1.9
Restoring QCN with this version can take a while. DO NOT USE PC until done!
8. daisy_sprout:/ $ su
/system/bin/sh: su: not found
127|daisy_sprout:/ $ setprop sys.usb.config rndis,diag,adb
setprop: failed to set property 'sys.usb.config' to 'rndis,diag,adb'
16. is not "QPST.exe" but "QFIL.exe"
20. 21. 22. not needed. directly went to 23 from 19.
stopped at 27, rebooted phone, IMEI's are back. Did not proceed with the manual any further.

terrorsource said:
Works now! both IMEI's are now shown in the settings.
IMEI SV is still at 0 though.
Your manual needs some work though.
Latest QFI: https://androidmtk.com/download-qualcomm-flash-image-loader-qfil
Enable Multi-SIM is not in all versions. I've used v2.0.1.9
Restoring QCN with this version can take a while. DO NOT USE PC until done!
8. daisy_sprout:/ $ su
/system/bin/sh: su: not found
127|daisy_sprout:/ $ setprop sys.usb.config rndis,diag,adb
setprop: failed to set property 'sys.usb.config' to 'rndis,diag,adb'
16. is not "QPST.exe" but "QFIL.exe"
20. 21. 22. not needed. directly went to 23 from 19.
stopped at 27, rebooted phone, IMEI's are back. Did not proceed with the manual any further.
Click to expand...
Click to collapse
We'll I have never had an issue with losing my IMEI , the manual is not mine ,I'm glad that it worked!