Related
I managed to get the system folder. Via http://forum.xda-developers.com/showthread.php?t=1578099
CWM
Instructions and discussion available here
Click to expand...
Click to collapse
CWM Flashable Recovery
Both have been tested by me
Stock Recovery
CWM 6.0.3.6 by Unjustified Dev
Click to expand...
Click to collapse
DOWNLOAD:
System.img (/dev/block/mmcblk0p22)
Boot.img (/dev/block/mmcblk0p20)
Recovery.img (/dev/block/mmcblk0p21)
Modem.img - T599UVAMB5 (/dev/block/mmcblk0p12)
modem.bin (/dev/block/mmcblk0p16)
param.lfs (/dev/block/mmcblk0p19)
Preload.img (/dev/block/mmcblk0p24)
efs.img (/dev/block/mmcblk0p11)
Click to expand...
Click to collapse
Hmmm... can you explain me what is that? Thx
Feyerabend said:
Hmmm... can you explain me what is that? Thx
Click to expand...
Click to collapse
It is for development purposes. It is basically the stock firmware minus the kernel and recovery.
goldfingerfif said:
I uploaded the system tar its almost 1GB I cannot pull the Kernel though.
I managed to get the system folder. Via http://forum.xda-developers.com/showthread.php?t=1578099
If someone can assist with getting the kernel without root I would be forever grateful. If it is unpossible then please let me know as well as I cannot find a root method that works.
Click to expand...
Click to collapse
So, what you basicly need is someone with linux who can make a system.img from this, and add supersu and su binary?
And then someone who makes a factoryreset and flash it in odin I guess..
That person might then be able to extract recovery.img and boot.img. Am I right?
tys0n said:
So, what you basicly need is someone with linux who can make a system.img from this, and add supersu and su binary?
And then someone who makes a factoryreset and flash it in odin I guess..
That person might then be able to extract recovery.img and boot.img. Am I right?
Click to expand...
Click to collapse
You don’t NEED linux, you can use Cygwin with windows, but yes someone can then make system.img or system.tar.md5 with supersu and su.
From there if a root shell is obtained recovery and boot partitions should be able to be extracted from the phone.
Then insecure kernel and custom recovery can be installed.
I’ve done something like this with the T989 but this phone is for someone at my work and so bricking is an issue unlike if it was a personal phone as well there is less motivation to do it if it isn’t mine.
goldfingerfif said:
You don’t NEED linux, you can use Cygwin with windows, but yes someone can then make system.img or system.tar.md5 with supersu and su.
From there if a root shell is obtained recovery and boot partitions should be able to be extracted from the phone.
Then insecure kernel and custom recovery can be installed.
I’ve done something like this with the T989 but this phone is for someone at my work and so bricking is an issue unlike if it was a personal phone as well there is less motivation to do it if it isn’t mine.
Click to expand...
Click to collapse
Somethimg like this I guess? http://forum.xda-developers.com/showthread.php?t=1081239&highlight=odin
tys0n said:
Somethimg like this I guess? http://forum.xda-developers.com/showthread.php?t=1081239&highlight=odin
Click to expand...
Click to collapse
Yes just like that minus the need to unpack it because it is just a tarball so 7zip or whatever should open it fine. I am at work but I believe my home computer has either a linux vm installed or Cygwin with dsixda’s kitchen.
I should be able to manually or through dsixda’s kitchen add supersu and su convert to a odin img and flash.
If it successfully roots so I can at least get a rooted shell so I can dd if=/dev/block/….. of=/sdcard/…img to get a recovery.img and boot.img then carefully cook up a TWRP or CWM recovery to flash then make a “custom” or modified stock rom to flash with insecured kernel.
Anything new on how this is going?
thecasual01 said:
Anything new on how this is going?
Click to expand...
Click to collapse
I added SuperSU.apk and su binary.
Scared to flash it without a known good working factory image. Need to read up on a couple things a little more like triple check I can flash just the system partition without boot, etc.
goldfingerfif said:
I added SuperSU.apk and su binary.
Scared to flash it without a known good working factory image. Need to read up on a couple things a little more like triple check I can flash just the system partition without boot, etc.
Click to expand...
Click to collapse
Excuse me if this may come across as stupid or ignorant, but to my understanding the SGH-T599 seems to be an alternative version of the S3 Mini , I think the main difference is the screen size? That being said, can you not use the current existing kernel, boot.img of the S3 mini? I'm basing this off the fact that I had soft-bricked my phone by attempting to flash CWM Recovery but it didn't work, and I couldn't get myself the stock recovery.img file so in an attempt to revive my phone, I substituted that with the S3 mini's and it worked. Although at first every time i turned on and off the phone it displayed noise (TV Static) but it no longer does so.
I would offer being a test monkey, but this is my only phone and I do not have any other phones that I could use in the scenario it does get bricked.
goldfingerfif said:
I added SuperSU.apk and su binary.
Scared to flash it without a known good working factory image. Need to read up on a couple things a little more like triple check I can flash just the system partition without boot, etc.
Click to expand...
Click to collapse
I think it will be fine to flash system.img only as long as you don't use any pit and repartition. Factory reset first to prevent bootloops.
tamil.soljahz said:
Excuse me if this may come across as stupid or ignorant, but to my understanding the SGH-T599 seems to be an alternative version of the S3 Mini , I think the main difference is the screen size? That being said, can you not use the current existing kernel, boot.img of the S3 mini? I'm basing this off the fact that I had soft-bricked my phone by attempting to flash CWM Recovery but it didn't work, and I couldn't get myself the stock recovery.img file so in an attempt to revive my phone, I substituted that with the S3 mini's and it worked. Although at first every time i turned on and off the phone it displayed noise (TV Static) but it no longer does so.
I would offer being a test monkey, but this is my only phone and I do not have any other phones that I could use in the scenario it does get bricked.
Click to expand...
Click to collapse
Are you saying you used a boot.img from s3 mini?
tamil.soljahz said:
Excuse me if this may come across as stupid or ignorant, but to my understanding the SGH-T599 seems to be an alternative version of the S3 Mini , I think the main difference is the screen size? That being said, can you not use the current existing kernel, boot.img of the S3 mini? I'm basing this off the fact that I had soft-bricked my phone by attempting to flash CWM Recovery but it didn't work, and I couldn't get myself the stock recovery.img file so in an attempt to revive my phone, I substituted that with the S3 mini's and it worked. Although at first every time i turned on and off the phone it displayed noise (TV Static) but it no longer does so.
I would offer being a test monkey, but this is my only phone and I do not have any other phones that I could use in the scenario it does get bricked.
Click to expand...
Click to collapse
What exactly did you use to get it up and running, just the recovery.img, system.img, or boot.img (kernel) you flashed or some combo?
Looks like processor, screen and possibly bluetooth are different
T-599 vs i8190
goldfingerfif said:
What exactly did you use to get it up and running, just the recovery.img, system.img, or boot.img (kernel) you flashed or some combo?
Looks like processor, screen and possibly bluetooth are different
T-599 vs i8190
Click to expand...
Click to collapse
I just flashed the recovery.img, and (incorrectly) came to the assumption that the boot.img and system.img would work on the phone as well. In fact, I realize I can't access recovery. I was asking whether that the S3 mini's boot.img would work on the T599V as well.
Also, according to this link: http://www.sammobile.com/2012/11/24/review-samsung-galaxy-s-iii-mini-gt-i8190-2/
it says the S3 mini uses the U8420 chipset as well, which is why I thought the phones were similar.
tamil.soljahz said:
I just flashed the recovery.img, and (incorrectly) came to the assumption that the boot.img and system.img would work on the phone as well. In fact, I realize I can't access recovery. I was asking whether that the S3 mini's boot.img would work on the T599V as well.
Also, according to this link: http://www.sammobile.com/2012/11/24/review-samsung-galaxy-s-iii-mini-gt-i8190-2/
it says the S3 mini uses the U8420 chipset as well, which is why I thought the phones were similar.
Click to expand...
Click to collapse
The site you linked doesn't mention the SGH-T599 just the GT-8190 and the GT-i9300, did you send the right link?
According to http://www.gsmchoice.com/en/catalogue/samsung/galaxyexhibit/ it's built on same board. ST-Ericsson U8420.
It' same for i8190, some sites say U8500 others say U8420.
The Cydia Impactor root method works on the T599, I just did it to mine. Stays rooted on reboot.
marksalot said:
The Cydia Impactor root method works on the T599, I just did it to mine. Stays rooted on reboot.
Click to expand...
Click to collapse
Cool
So, first guy who "dd" will be hero of the day
If partition layout is the same as i8190 it should look like this.
Code:
GT-I8190 PARTITION LAYOUT
Official Name * Fs * Mount point * Known as * Contents
/efs * ext4 * /dev/block/mmcblk0p11 * Efs folder *Device IMEI,mac address etc
/modemfs * ext4 * /dev/block/mmcblk0p12 * Radio *
/SdCcard * vfat * /dev/block/mmcblk1 /dev/block/mmcblk1p1 * Internal sd * Your stuff
/boot * emmc * /dev/block/mmcblk0p20 * kernel/zimage * Drivers etc
/recovery * emmc * /dev/block/mmcblk0p21 * Recovery partion * ??????
/system * ext4 * /dev/block/mmcblk0p22 * System folder * The operation system
/cache * ext4 * /dev/block/mmcblk0p23 * Cache partition * Update.zips csc,samsung and carriers customizations
/preload * ext4 * /dev/block/mmcblk0p24 * Hidden partition * Media files,apks etc from Samsung/carriers
/.lfs * j4fs * /dev/block/mmcblk0p19 * param.lfs ## * splash screen,charging animation download mode pngs, etc
/data * ext4 * /dev/block/mmcblk0p25 length=-16384 * data folder * Your download apps, current device and use, settings
/temp * ? * /dev/block/mmcblk0p5 * nedded to load *
* * * psccd and CSPSA *
* * * when reset is *
* * * triggered *
* * * *
* * * *
* *
* * * *
I guess boot, recovery, and param is most wanted
Here is the content of /proc/partitions
Code:
major minor #blocks name
7 0 5229 loop0
179 0 3866624 mmcblk0
179 1 128 mmcblk0p1
179 2 384 mmcblk0p2
179 3 1024 mmcblk0p3
179 4 1024 mmcblk0p4
179 5 512 mmcblk0p5
179 6 512 mmcblk0p6
179 7 512 mmcblk0p7
179 8 512 mmcblk0p8
179 9 1024 mmcblk0p9
179 10 1024 mmcblk0p10
179 11 16384 mmcblk0p11
179 12 16384 mmcblk0p12
179 13 16384 mmcblk0p13
179 14 51200 mmcblk0p14
179 15 64 mmcblk0p15
179 16 14336 mmcblk0p16
179 17 2048 mmcblk0p17
179 18 2048 mmcblk0p18
179 19 16384 mmcblk0p19
179 20 16384 mmcblk0p20
179 21 16384 mmcblk0p21
179 22 1228800 mmcblk0p22
179 23 737280 mmcblk0p23
179 24 102400 mmcblk0p24
179 25 1535983 mmcblk0p25
179 64 2048 mmcblk0boot1
179 32 2048 mmcblk0boot0
179 96 15637504 mmcblk1
179 97 15633408 mmcblk1p1
254 0 5229 dm-0
Here is the output of busybox df -h
I have a 16GB SD Card, apparently Maverick (GPS map app I installed) creates it's own partition.
Code:
busybox df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 402.1M 112.0K 401.9M 0% /dev
tmpfs 402.1M 0 402.1M 0% /mnt/asec
tmpfs 402.1M 0 402.1M 0% /mnt/obb
tmpfs 402.1M 0 402.1M 0% /dev/shm
/dev/block/mmcblk0p22
1.2G 965.4M 215.7M 82% /system
/dev/block/mmcblk0p12
15.7M 4.3M 11.4M 28% /modemfs
/dev/block/mmcblk0p23
708.7M 12.0M 696.7M 2% /cache
/dev/block/mmcblk0p11
15.7M 4.5M 11.2M 29% /efs
/dev/block/mmcblk0p24
98.4M 11.6M 86.8M 12% /preload
/dev/block/mmcblk0p25
1.4G 1.3G 173.7M 88% /data
df: /mnt/.lfs: Function not implemented
/dev/fuse 1.3G 1.3G 73.7M 95% /storage/sdcard0
/dev/block/dm-0 5.0M 2.9M 2.1M 57% /mnt/asec/com.codesector.maverick.full-1
/dev/block/vold/179:97
14.9G 10.1G 4.8G 68% /storage/extSdCard
cat /proc/partitions gives me in I8190.
Code:
major minor #blocks name
7 0 16664 loop0
7 1 2111 loop1
7 2 5229 loop2
7 3 2111 loop3
7 4 2111 loop4
7 5 2111 loop5
7 6 2111 loop6
7 7 17703 loop7
179 0 7634944 mmcblk0
179 1 128 mmcblk0p1
179 2 384 mmcblk0p2
179 3 1024 mmcblk0p3
179 4 1024 mmcblk0p4
179 5 512 mmcblk0p5
179 6 512 mmcblk0p6
179 7 512 mmcblk0p7
179 8 512 mmcblk0p8
179 9 1024 mmcblk0p9
179 10 1024 mmcblk0p10
179 11 16384 mmcblk0p11
179 12 16384 mmcblk0p12
179 13 16384 mmcblk0p13
179 14 51200 mmcblk0p14
179 15 64 mmcblk0p15
179 16 14336 mmcblk0p16
179 17 2048 mmcblk0p17
179 18 2048 mmcblk0p18
179 19 16384 mmcblk0p19
179 20 16384 mmcblk0p20
179 21 16384 mmcblk0p21
179 22 1228800 mmcblk0p22
179 23 860160 mmcblk0p23
179 24 327680 mmcblk0p24
179 25 4945920 mmcblk0p25
179 64 2048 mmcblk0boot1
179 32 2048 mmcblk0boot0
179 96 15558144 mmcblk1
179 97 13473792 mmcblk1p1
179 98 2075648 mmcblk1p2
254 0 16663 dm-0
254 1 2110 dm-1
254 2 5229 dm-2
254 3 2110 dm-3
254 4 2110 dm-4
254 5 2110 dm-5
254 6 2110 dm-6
254 7 17703 dm-7
7 8 2111 loop8
254 8 2110 dm-8
7 9 26019 loop9
254 9 26019 dm-9
Looks like it matches pretty well
So, I used the Online Nandroid app, it detects the T599 as "codinatmo" and doesn't have a patch available.
Manually chose the "Samsung Galaxy S III mini GT-l8190" patch and installed.
Was able to back up boot.img and recovery.img, both 16MB.
Hi guys,
I am in desperate need of a raw img of mmcblk0. All I need one of you to do is get an adb shell or in terminal emulator with root type:
dd if=/dev/block/mmcblk0 of=/sdcard/unbrick.img count=524288
This creates a raw image dump I can use to help unbrick my device. It does NOT contain any sensitive data like IMEI or ESN, etc... I need MJE on Verizon Note 3 specifically. Thank you very much in advanced!
EDIT: 2/14 11:15am CST I am still in need of MJE N900V image. Surely would appreciate anyone with the time.
ryanbg said:
Hi guys,
I am in desperate need of a raw img of mmcblk0. All I need one of you to do is get an adb shell or in terminal emulator with root type:
dd if=/dev/block/mmcblk0 of=/sdcard/unbrick.img
This creates a raw image dump I can use to help unbrick my device. It does NOT contain any sensitive data like IMEI or ESN, etc... I need MJE on Verizon Note 3 specifically. Thank you very much in advanced!
Click to expand...
Click to collapse
Dev Edition matter? I can offer one up if that is acceptable
TechSavvy2 said:
Dev Edition matter? I can offer one up if that is acceptable
Click to expand...
Click to collapse
It's worth a shot, I sure would appreciate it.
/dev/mmcblk0 is the entire device - 32 GB
Is that really what you mean?
ryanbg said:
It's worth a shot, I sure would appreciate it.
Click to expand...
Click to collapse
aight, give me a minute
Edit: Sorry give me another minute, had to re-root really quick
Edit: PS, any other dd's you want me to run for you while I'm at it?
---------- Post added 14th February 2014 at 12:12 AM ---------- Previous post was 13th February 2014 at 11:58 PM ----------
bftb0 said:
/dev/mmcblk0 is the entire device - 32 GB
Is that really what you mean?
Click to expand...
Click to collapse
This.
TechSavvy2 said:
aight, give me a minute
Edit: Sorry give me another minute, had to re-root really quick
Edit: PS, any other dd's you want me to run for you while I'm at it?
---------- Post added 14th February 2014 at 12:12 AM ---------- Previous post was 13th February 2014 at 11:58 PM ----------
This.
Click to expand...
Click to collapse
Cancel that!!! I gave you a bad command. Just delete unbrick.img
ryanbg said:
Cancel that!!! I gave you a bad command. Just delete unbrick.img
Click to expand...
Click to collapse
Already cancelled it out when I realized the size and time it was gonna take. Another memory block you need perhaps?
Code:
major minor #blocks name Label
7 0 21861 loop0
7 1 3150 loop1
7 2 26019 loop2
7 3 9387 loop3
7 4 2111 loop4
7 5 4190 loop5
7 6 26019 loop6
179 0 30535680 mmcblk0
179 1 15360 mmcblk0p1 apnhlos
179 2 58816 mmcblk0p2 modem
179 3 512 mmcblk0p3 sbl1
179 4 32 mmcblk0p4 dbi
179 5 32 mmcblk0p5 ddr
179 6 2048 mmcblk0p6 aboot
179 7 512 mmcblk0p7 rpm
179 8 512 mmcblk0p8 tz
179 9 10240 mmcblk0p9 pad
179 10 10240 mmcblk0p10 param
179 11 14336 mmcblk0p11 efs
179 12 3072 mmcblk0p12 modemst1
179 13 3072 mmcblk0p13 modemst2
179 14 11264 mmcblk0p14 boot
179 15 13312 mmcblk0p15 recovery
179 16 13312 mmcblk0p16 fota
179 17 7159 mmcblk0p17 backup
179 18 3072 mmcblk0p18 fsg
179 19 1 mmcblk0p19 fsc
179 20 8 mmcblk0p20 ssd
179 21 8192 mmcblk0p21 persist
179 22 9216 mmcblk0p22 persdata
179 23 2777088 mmcblk0p23 system
179 24 1048576 mmcblk0p24 cache
179 25 26521583 mmcblk0p25 userdata
179 32 512 mmcblk0rpmb
179 64 30702592 mmcblk1
179 65 30701568 mmcblk1p1
254 0 21861 dm-0
254 1 3150 dm-1
254 2 26019 dm-2
254 3 9387 dm-3
254 4 2110 dm-4
254 5 4189 dm-5
254 6 26019 dm-6
TechSavvy2 said:
Already cancelled it out when I realized the size and time it was gonna take. Another memory block you need perhaps?
Code:
major minor #blocks name Label
7 0 21861 loop0
7 1 3150 loop1
7 2 26019 loop2
7 3 9387 loop3
7 4 2111 loop4
7 5 4190 loop5
7 6 26019 loop6
179 0 30535680 mmcblk0
179 1 15360 mmcblk0p1 apnhlos
179 2 58816 mmcblk0p2 modem
179 3 512 mmcblk0p3 sbl1
179 4 32 mmcblk0p4 dbi
179 5 32 mmcblk0p5 ddr
179 6 2048 mmcblk0p6 aboot
179 7 512 mmcblk0p7 rpm
179 8 512 mmcblk0p8 tz
179 9 10240 mmcblk0p9 pad
179 10 10240 mmcblk0p10 param
179 11 14336 mmcblk0p11 efs
179 12 3072 mmcblk0p12 modemst1
179 13 3072 mmcblk0p13 modemst2
179 14 11264 mmcblk0p14 boot
179 15 13312 mmcblk0p15 recovery
179 16 13312 mmcblk0p16 fota
179 17 7159 mmcblk0p17 backup
179 18 3072 mmcblk0p18 fsg
179 19 1 mmcblk0p19 fsc
179 20 8 mmcblk0p20 ssd
179 21 8192 mmcblk0p21 persist
179 22 9216 mmcblk0p22 persdata
179 23 2777088 mmcblk0p23 system
179 24 1048576 mmcblk0p24 cache
179 25 26521583 mmcblk0p25 userdata
179 32 512 mmcblk0rpmb
179 64 30702592 mmcblk1
179 65 30701568 mmcblk1p1
254 0 21861 dm-0
254 1 3150 dm-1
254 2 26019 dm-2
254 3 9387 dm-3
254 4 2110 dm-4
254 5 4189 dm-5
254 6 26019 dm-6
Click to expand...
Click to collapse
Sorry I'm in a bit of a panic. Trying to remember how to piece together a debrick image. Appreciate your patience again.
EDIT: Here we go Link
ryanbg said:
Hi guys,
I am in desperate need of a raw img of mmcblk0. All I need one of you to do is get an adb shell or in terminal emulator with root type:
dd if=/dev/block/mmcblk0 of=/sdcard/unbrick.img
This creates a raw image dump I can use to help unbrick my device. It does NOT contain any sensitive data like IMEI or ESN, etc... I need MJE on Verizon Note 3 specifically. Thank you very much in advanced!
Click to expand...
Click to collapse
Actually it DOES contain sensitive data since it contains ALL 32GB of the internal flash
You need to be rooted and with a decent busybox and do more like:
dd if=/dev/block/mmcblk0 of=/sdcard/unbrick.img count=524288
(this will create a 256MB image).
IMHO you also need to create the debrick image on the same family product - it would be VERY interesting if that would work from a verizon developer edition model (and I would really want to see that tested) but I have some doubts. I would also be interested if any other debrick image would work - I assume you have N900V but IMHO it would be again VERY interesting to try with a N900W8 debrick image (but be very, very careful when you later write stuff with the modem-related stuff, which is very different in N900W8 and you really want to keep your N900V modem and stuff ).
xclub_101 said:
... it would be VERY interesting if that would work from a verizon developer edition model (and I would really want to see that tested) but I have some doubts. I would also be interested if any other debrick image would work ...
Click to expand...
Click to collapse
I guess I need to go looking for the right threads, but is it correct to say that the SDcard unbrick method (Qualcomm phone versions) only provides a kind of volatile boot scaffolding so that the device owner can enter Odin/download mode... and that no flashing of the device occurs until the owner actually performs the subsequent flash operation using Odin? (That is, none of the content of the unbrick image is ever written to the device being rescued?)
A second question is whether version locking occurs - I thought I saw someone claiming that a prior release unbrick image, even if taken from the same device (e.g. MI9 or MJ7 prior to a MJE upgrade) will not launch into download mode - is that right?
bftb0 said:
I guess I need to go looking for the right threads, but is it correct to say that the SDcard unbrick method (Qualcomm phone versions) only provides a kind of volatile boot scaffolding so that the device owner can enter Odin/download mode... and that no flashing of the device occurs until the owner actually performs the subsequent flash operation using Odin? (That is, none of the content of the unbrick image is ever written to the device being rescued?)
A second question is whether version locking occurs - I thought I saw someone claiming that a prior release unbrick image, even if taken from the same device (e.g. MI9 or MJ7 prior to a MJE upgrade) will not launch into download mode - is that right?
Click to expand...
Click to collapse
That is somehow true, but IMHO if all relevant partitions are wiped on the internal flash (from SBL1 to ABOOT) then all those will be read from microSD and have the code and signatures from there, and the "Odin mode" itself will be the version from microSD.
And here we have a number of interesting paths:
- the signature/hash on SBL1 itself is similar among Note 3 versions - that would result on all steps up to and including ABOOT being valid, so the "special Odin mode" will be entered; if the signature/hash on SBL1 is NOT similar between Note 3 families (or even before and after a major bootloader version) not even the "special Odin mode" will be started;
- if "special Odin mode" is started we can see another fork - if the "downgrade limitations" are part of the microSD code itself then you will be able to write any single firmware you were able to write when the internal SBL1/ABOOT was at the same version as the microSD SBL1/ABOOT - in other words you will be able to downgrade as far back as the microSD SBL1/ABOOT will let you!
- however there are some reports that the "downgrade restrictions" are actually stored in the internal flash in the "invisible/protected" regions there - and can be reset with special JTAG-like hardware:
http://forum.gsmhosting.com/vbb/f672/regarding-knox-s4-1775213/
Even in that last case there would still be a small chance that the "downgrade restrictions" might be skipped when booting from microSD since the internal flash could be considered at that point "less reliable" (or hopefully somebody at Samsung forgot to read that extra info on this special path - we can all hope )
So yes, I have also seen some people claiming stuff but I would still like to see more detailed tests on it with detailed reports on what is failing at what point! And especially on the microSD with the N900W8 "happy bootloader" or even with some much earlier "early development bootloader" (I have seen something like that mentioned somewhere)!
bftb0 said:
I guess I need to go looking for the right threads, but is it correct to say that the SDcard unbrick method (Qualcomm phone versions) only provides a kind of volatile boot scaffolding so that the device owner can enter Odin/download mode... and that no flashing of the device occurs until the owner actually performs the subsequent flash operation using Odin? (That is, none of the content of the unbrick image is ever written to the device being rescued?)
A second question is whether version locking occurs - I thought I saw someone claiming that a prior release unbrick image, even if taken from the same device (e.g. MI9 or MJ7 prior to a MJE upgrade) will not launch into download mode - is that right?
Click to expand...
Click to collapse
My theory on this (for public, bftb0 already knows) is you can boot anything that isn't fused to a lower binary counter, and since these values are inconsistent with firmware updates, it gives you a little wiggle room. AKA if A flag in ODIN is A2, you can not use an A1 aboot (MI9), but I (think) could use MJ7 since it's counter value is 2, same as MJE. These values are stored in AP RAW ANTI ROLLBACK in QFPROM. It is my belief that these values are also accessed from the shadow register as opposed to being read every time, since I was able to downgrade and replicate. I'm almost positive it's pulling these flags from RPMB. I'm extremely curious what P is since I may have full control. P1 changed to P0 when I downgraded my SBL1, TZ, and RPM to the testbit bootloader leaked by designgears, which doesn't make much since I believe all three of those have their own counters.
well ryanbg can summarize when he gets some free time (and I think that there are further experiments in the queue) but an initial attempt at performing a rescue of his bricked retail SM-900V phone (which was on MJE prior to hard bricking by a TZ partition mod) using a 200 MiB dump of mmcblk0 from a MJ7 device resulted in .... nothing.
I haven't seen anything in any of the posts so far about folks talking extra precautions involving repair of the secondary GPT (after doing a raw dump of the unbrick.img to their SDcard media), so I suppose that means that the SDCard unbrick method is - when it works - supposed to be insensitive to the fact that the unbrick SD Card does not have a complete UEFI set of primary & secondary GPTs - and might even have garbage sitting at the secondary GPT offsets.
For the MJ7 trial, we used dd if=/dev/block/mmcblk0 bs=4096 count=50000 (200 MiB) which is sufficiently large to capture everything including some amount of slop at the beginning of /system (p23). I thought I saw a post where someone was using 300 MB unbrick images, making the claim that smaller sizes didn't seem to work. Doesn't make much sense though, as only about ~ 180 MB are needed for everything up to and including p22. (p1 - p22 are ordered contiguously in LBA address space on the SM-900V, and p23 is 2.7GB, so clearly an intact copy of /system can't be needed).
any ideas welcome
sorry to resurrect this thread, but I can't seem to find a sm-n900v debrick/unbrick img anywhere. i've found the 900T, 900A, 9005 images, but nothing for 900v.
my retail edition n900v is definitely hard bricked and I could use some assistance.
Does any one have a note 3 verizon mj7 debrick/unbrick.img
I am in the process of flashing a custom rom. My phone is an original unlocked Consumer Cellular which had 2.2.1 installed and later on got an OTA update to 2.2.2.
I rooted the Bravo, made a system dump, installed 2nd-init and created a nandroid backup. As a final check I wanted to look at the partition table and that's when things got interesting. I tried parted but parted terminated with an error message about a partition "beyond" the device's last sector.
Looked around a bit and found out that fdisk is preinstalled in /system/xbin. So I used fdisk and this is what I found:
fdisk's info about the device:
Code:
Disk /dev/block/mmcblk1: 1958 MB, 1958739968 bytes
16 heads, 16 sectors/track, 14944 cylinders
Units = cylinders of 256 * 512 = 131072 bytes
That sounds about right, it is a 2 GByte flash rom. The problem is partition p4 (the "extended" partition) and partition p25 (aka "userdata"). Partition p4 is listed in the partition table as:
Code:
Device Boot Start End Blocks Id System
/dev/block/mmcblk1p4 13 122496 15677952 5 Extended
Well, "start" and "end" are cylinders, so the "end" being 122496 is waaaay beyond 14944! Partition p25 also seems to be messed up the same way:
Code:
Device Boot Start End Blocks Id System
/dev/block/mmcblk1p25 4633 122496 15086592 83 Linux
However, a "cat /proc/partitions" shows this:
Code:
cat /proc/partitions
major minor #blocks name alias
179 32 1912832 mmcblk1
179 33 128 mmcblk1p1
179 34 512 mmcblk1p2
179 35 512 mmcblk1p3
179 36 1 mmcblk1p4
179 37 512 mmcblk1p5
179 38 512 mmcblk1p6
179 39 4096 mmcblk1p7 pds
179 40 512 mmcblk1p8
179 41 512 mmcblk1p9
179 42 1024 mmcblk1p10
179 43 2048 mmcblk1p11
179 44 512 mmcblk1p12
179 45 512 mmcblk1p13
179 46 4096 mmcblk1p14
179 47 8192 mmcblk1p15 boot
179 48 8192 mmcblk1p16 recovery
179 49 14336 mmcblk1p17 cdrom
179 50 512 mmcblk1p18 misc
179 51 512 mmcblk1p19 cid
179 52 4096 mmcblk1p20 kpanic
179 53 334848 mmcblk1p21 system
179 54 512 mmcblk1p22 prek
179 55 512 mmcblk1p23 pkbackup
179 56 204800 mmcblk1p24 cache
179 57 1319936 mmcblk1p25 userdata
179 0 1931264 mmcblk0
179 1 1930240 mmcblk0p1
So besides the partition data which I seem to not understand the size of userdata seems to be 1319936 blocks which is ~1.3 GByte.
This leads to my 2 questions:
Is there a problem here or do I simply misunderstand fdisk's partition list (parted says that is something wrong though!)?
Do I have to try to "fix" this before installing a custom rom (planning on trying cm-10.2-20131030-NIGHTLY-mb520.zip)?
Thanks,
Markus
Ok ... I'm answering my own question here, just in case someone else is interested in the solution:
General Information:
Historically (pc compatible) partitions used to be aligned on cylinder boundaries. Nowadays partitions are usually aligned on a sector number which is a multiple of 2048. For standard 512 sectors this evaluates to a 1 MByte boundary - which is also compatible with drives with a larger sector size (4096 bytes for drives > 2 TByte).
Logical volumes within the extended partition do not use the first head of the first cylinder (or the first 2048 sectors) because the area holds the volume's EBR - which is only a 512 byte record, similar to a MBR.
Implementation in the Motorola Bravo:
The Linux kernel reports 16 heads per cylinder and 16 tracks per head, resulting in 128 kByte per cylinder.
Partitions are aligned to this "virtual" disk geometry.
Digging through the list of EBRs (using dd and hexdump) I found that the partitioning utility used by Motorola creates volumes in the extended partition in a different (but still compatible) way: instead of wasting the first "track" (for the volume's EBR) in each volume, it consolidates all the EBRs in the disk space wasted by the partition entry for the extended partition itself (which usually is 1 cylinder or 2048 sectors).
Motorola actually allocated 512 kByte (1024 sectors) for the extended partition itself, giving the system the theoretical limit of 1024 volumes.
The question still unanswered though is: why does the extended partition (and the last volume in that partition) extend way beyond the end of mmcblk1?
Findings:
I searched around and I discovered that the tool Motorola used to create the partition table was most likely something like nand-part (part of the sunxi tools, please look it up on Wikipedia, I am not allowed yet to post links outside this forum).
This tool creates the EBRs for logical volumes in the same way as they appear in the Bravo's partitions. And most important, this tools also allows to create partitions which extend beyond the end of the device!
Ok ... on with the story: whenever a file system utility like mkfs wants to format a partition, it asks the kernel for information about that partition. The kernel is smart enough to correct partition definitions which extend beyond the end of device in order to avoid a failure or crash of the file system formatting utility. This "correction" is not permanent (partition table stays as it is) but done on the fly.
Conclusions:
nand-part's lack of parameter checking together with the kernel's smartness about partitions exceeding the device made it possible for Motorola to create one common partition layout for devices with different flash capacities: the setup used in the Bravo would be sufficient for flash up to 8 GByte without even changing the partition tables. The last partition (userdata) would simply benefit from a higher flash capacity.
Having answered that question, I still wanted to know what happenes when I try to correct that error (I know, I just asked for trouble). So I went ahead and as a first step I corrected the size in userdata's (mmcblk1p25) EBR to the correct value (using dd and a hex editor). After the correction everything looked fine. The definition of mmcblk1p25 now matched the actual size. I rebooted the phone and ... boom! The bootloader obviously was extremely unhappy and I was forced to do my first "sbf" - which I managed to do and meanwhile my Bravo is happily running CM10.2.
Dear Moderator:
If this post is of any use for the "Dev" section, please move it over there. I do not have the permission (yet) to post in the dev section.
Happy hacking,
Markus
Hi,
I´ve wiped clean my LEX720 to install a new rom, the fact is I have 4GB assigned to a System Image Partition and I can not recover them. So a 32Gb phone is now only showing 24 before flash. Any idea?? This partition only shows under TWRP backup, I've tried deleting it with fast boot but no luck so far.
Thanks!
1. 32 GB in fact is 32 000 000 000 B. In IT you should convert by 1024 (2^10). So, for 32 GB it is 29,80 GiB (Gigi mean true IT Giga). Then, this store can have hidden, blocked data for system, recovery, backup or sth else. My x720 64 GB at 018s shows 64 GB capacity formatted to 59.59GB. If you lost any storage, it is less than 2 GB.
2. As i remembered, 020s shows storage aviable, exclude system.
Thank you for your answer. The fact is I have a partition called System Image, only shows under TWRP. It uses 4Gb and I really don´t know if I can get rid of it. Thanks
Luis.Vidania said:
Thank you for your answer. The fact is I have a partition called System Image, only shows under TWRP. It uses 4Gb and I really don´t know if I can get rid of it. Thanks
Click to expand...
Click to collapse
Hi!
To clearify a little bit: The entry "System Image" you see in TWRP's backup screen, is not a separate partition. This is just a different mode to backup the "system" partition.
So in short: "System" and "System Image" backup the same "/system" partition, just with different methods. There is no such thing like a "System Image" partition.
Background:
Normally TWRP is creating file-based backups, which means it stores and compresses the content of a partition file by file. But since modern Android versions on many phones use dm-verity for the verified boot process it is important that the system partition is not only file-by-file unmodified, but really bit by bit. So if you would change a single bit (maybe just the created-filestamp of a single file) the verified boot process (i.e. the dm-verity device mapper) would recognize the system image as modified.
For this reason TWRP introduced a new form for backing up the system partition as bit-by-bit image file (so it really dumps the raw partition content bit by bit). The disadvantage of doing this is, that the resulting backup needs more space as it always of the size of the whole partition, no matter how much data actually is stored on it (of course TWRP compresses the backup after dumping so in reality it might vary in size but still typically is larger than the file-based backup).
That's why TWRP also left intact the "classic" way of backing up the system partition, so that users which need a bit-by-bit identical system image can use "System Image" backup option and all others can use the classical file-by-file "System" backup option.
So you don't have an extra partition "System image".
Your storage problem must have some other reasons.
You could enter these commands in a terminal app on the phone or via "adb shell" and check which partitions take which size:
Code:
cat /proc/partitions > /sdcard/partitions.txt
mount > /sdcard/mount.txt
df > /sdcard/diskfree.txt
Look into the 3 textfiles afterwards to check the layout and usage of your storage.
Hope that helps!
Wow! You are the man. I will check and get back to you. Thank you
Hi,
Just had a chance to do what you said, but I can´t get a clear image of what I am looking for. These are my txt files, let me know if you see anything out of the ordinary.
Thank you in advance!
Filesystem Size Used Free Blksize
/ 1.7G 5.4M 1.7G 4096
/dev 1.8G 128.0K 1.8G 4096
/sys/fs/cgroup 1.8G 12.0K 1.8G 4096
/mnt 1.8G 0.0K 1.8G 4096
/system 3.9G 2.7G 1.2G 4096
/data 23.8G 12.0G 11.9G 4096
/cache 248.0M 164.0K 247.8M 4096
/persist 27.5M 812.0K 26.7M 4096
/dsp 11.7M 4.1M 7.6M 4096
/firmware 109.9M 83.2M 26.8M 16384
/bt_firmware 1023.7M 112.0K 1023.6M 16384
/storage 1.8G 0.0K 1.8G 4096
/storage/emulated 23.8G 12.0G 11.9G 4096
rootfs on / type rootfs (rw,seclabel,size=1815040k,nr_inodes=453760)
tmpfs on /dev type tmpfs (rw,seclabel,nosuid,relatime,size=1917232k,nr_inodes=479308,mode=755)
devpts on /dev/pts type devpts (rw,seclabel,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,seclabel,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,seclabel,relatime,size=1917232k,nr_inodes=479308)
adb on /dev/usb-ffs/adb type functionfs (rw,relatime)
/dev/block/bootdevice/by-name/cache on /cache type ext4 (rw,seclabel,nosuid,nodev,relatime,data=ordered)
/dev/block/sda10 on /data type ext4 (rw,seclabel,relatime,data=ordered)
/dev/block/sda10 on /sdcard type ext4 (rw,seclabel,relatime,data=ordered)
major minor #blocks name
254 0 378212 zram0
8 0 25833472 sda
8 1 8 sda1
8 2 32768 sda2
8 3 262144 sda3
8 4 1024 sda4
8 5 512 sda5
8 6 128 sda6
8 7 128 sda7
8 8 512 sda8
8 9 4096 sda9
8 10 25532108 sda10
8 16 4096 sdb
8 17 4052 sdb1
8 48 131072 sdd
8 49 32 sdd1
8 50 4 sdd2
8 51 1024 sdd3
8 80 32768 sdf
8 81 2048 sdf1
8 82 1024 sdf2
8 83 2048 sdf3
8 84 1024 sdf4
8 85 4 sdf5
8 86 4 sdf6
8 87 4 sdf7
8 88 4 sdf8
8 89 4 sdf9
8 90 512 sdf10
8 91 512 sdf11
8 92 512 sdf12
8 93 512 sdf13
8 94 10240 sdf14
8 64 5242880 sde
8 65 512 sde1
8 66 512 sde2
8 67 2048 sde3
8 68 2048 sde4
8 69 512 sde5
8 70 512 sde6
8 71 2048 sde7
8 72 1024 sde8
8 73 16 sde9
8 74 512 sde10
8 75 512 sde11
8 76 112640 sde12
8 77 16384 sde13
8 78 1024 sde14
8 79 32768 sde15
259 0 1024 sde16
259 1 1024 sde17
259 2 65536 sde18
259 3 4194304 sde19
259 4 65536 sde20
259 5 4 sde21
259 6 1024 sde22
259 7 512 sde23
259 8 512 sde24
259 9 256 sde25
259 10 256 sde26
259 11 256 sde27
259 12 256 sde28
259 13 256 sde29
259 14 256 sde30
259 15 4 sde31
259 16 102400 sde32
259 17 2048 sde33
8 32 4096 sdc
8 33 4052 sdc1
Maybe someone can give me some light here...
Just wiped clean my phone, no ROM installed. Ran the command and got these readings...
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 1917232 20 1917212 0% /dev
tmpfs 1917232 40 1917192 0% /tmp
/dev/block/sde12 112576 85184 27392 76% /firmware
/dev/block/sde19 4062912 8172 4038356 0% /system
/dev/block/sda10 24999968 45084 24938500 0% /data
/dev/block/sda10 24999968 45084 24938500 0% /sdcard
Still can't find my missing 4Gb... Nothing installed and only 23.78GB available
I have the same issue on my leeco le s3 x522.
System image takes 4gb and can't recover it.
I have this problem on my lenovo.....not getting 2.6 gb
Hi, I recently decided to dust off my old nexus 10 and install a current version of android on it. With some guides I unlocked the bootloader, installed TWRP, installed AOSP Android 9.0 Pie and then when I wanted to install open gapps I got an not enough space error. After some searching I found a post with a repit file, which should automatically increase the size of my system partition. Unfortunatelly while this repit thing was running the display flickered for a second and the resize failed. (Stupid as I am I didnt make screenshot of the error :/) I think the screen flickering thing is a hardware problem, as it did this even without cutum recovery/rom from time to time. But i always thought it was only a problem with the the screen backlight, as it had no impact on any running software before. (I replaced the battery now to maybe fix this.) But my main problem now is, that TWRP cant mount any partitions. I think the partition table is broken.
fdisk -l doesnt output anything
fdisk -l /dev/block/mmcblk0
Code:
warning: GPT array CRC is invalid
Found valid GPT with protective MBR; using GPT
Disk mmcblk0: 61071360 sectors, 1148M
Logical sector size: 512
Disk identifier (GUID): 52444e41-494f-2044-4d4d-43204449534b
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 61071326
Number Start (sector) End (sector) Size Code Name
1 8192 49151 20.0M 0700 efs
2 49152 65535 8192K 0700 param
3 65536 98303 16.0M 0700 boot
4 98304 163711 31.9M 0700 recovery
5 163712 163839 65536 0700 metadata
6 163840 172031 4096K 0700 misc
7 172032 376831 100M 0700 cache
8 2301952 2826239 256M 0700
9 2891776 61063167 27.7G 0700 userdata
I think 8 should be the corrupted system partition. But isnt there also "data" missing?
Should I resize 8 to 376832 - 2891775 and fix the missing name?
ls /dev/block
Code:
loop0 loop5 mmcblk0boot1 ram11 ram2 ram7
loop1 loop6 platform ram12 ram3 ram8
loop2 loop7 ram0 ram13 ram4 ram9
loop3 mmcblk0 ram1 ram14 ram5 zram0
loop4 mmcblk0boot0 ram10 ram15 ram6
There mmcblk0p7, mmcblk0p8, etc. are missing. How can I fix this?
Can someone help me please? I dont want to break it even further :/
I think I solved it. I downloaded the factory image and ran flash-all. Now the stock rom is running again and I can try flashing a custom rom again.