Related
I am in need of the PIT file for a SCH-I535 32Gb version.
Anyone willing/able to rip one for me? My 32Gb phone got JTAG'd back to life but using files from a 16Gb version, so it's kinda confused as to how much internal storage it has. I'm hoping I can flash the PIT from a 32Gb phone, then do a reinstall of the ROM and it'll recognize all of my available storage....
Thanks for your help!
-Andy
EDIT:
Problem solved: See post#57
Bump
Sent from my SCH-I535 using xda app-developers app
letinsh said:
I am in need of the PIT file for a SCH-I535 32Gb version.
Anyone willing/able to rip one for me? My 32Gb phone got JTAG'd back to life but using files from a 16Gb version, so it's kinda confused as to how much internal storage it has. I'm hoping I can flash the PIT from a 32Gb phone, then do a reinstall of the ROM and it'll recognize all of my available storage....
Thanks for your help!
-Andy
Click to expand...
Click to collapse
do you have a pit from the 16 gb version
man that would be great if somebody would post a pitfile for both versions...I know that would help a few folks that corrupted thier emmc internal memory and get the "e cant mount" errors in recovery.
I am game ... how would I extract the PIT file?
Sent from my SCH-I535 using xda premium
Standby. Getting confirmation, then I'll post instructions.
Sent from my SCH-I535 using xda app-developers app
bump...
il gladly dump my 32gb blue if there's instructions.
here is some info from the i9300 forum
http://forum.xda-developers.com/showthread.php?t=1742668
What I'm trying to get confirmation on is using darkyy's dd command from the first post in this thread:
http://forum.xda-developers.com/showthread.php?t=960946
Just trying to verify that's the correct place to get it for the SGS3 and that that would produce a flashable .pit file.
Sent from my SCH-I535 using xda app-developers app
please post as soon as you get the ok because i think then we would also be able to use heimdall but i might be wrong.
Bump
Sent from my SCH-I535 using xda premium
aight, darkyy's method won't work as /dev/mount/bml2 (or any of the bml's) doesn't exist on the GS3. I think I posted without knowing enough info.
I don't know where the PIT file's located on the GS3, and whether it's a function of the phone or the OS (ie ICS vs Gingerbread). I didn't have time over the weekend to look into it, too much. Going to look on that i9300 thread posted and also try to learn a little about Heimdall, as I've only ever used Odin.
To sum up:
Goal is to have a .pit file for SCH-I535 for both the 16Gb and 32Gb versions.
Needed:
I don't know enough about Android/SGS3 to know where the .pit is located. Once that's determined, we'll figure out how to extract it and make a functional flash.
Sorry for the false start, still learning here.
letinsh said:
aight, darkyy's method won't work as /dev/mount/bml2 (or any of the bml's) doesn't exist on the GS3. I think I posted without knowing enough info.
I don't know where the PIT file's located on the GS3, and whether it's a function of the phone or the OS (ie ICS vs Gingerbread). I didn't have time over the weekend to look into it, too much. Going to look on that i9300 thread posted and also try to learn a little about Heimdall, as I've only ever used Odin.
To sum up:
Goal is to have a .pit file for SCH-I535 for both the 16Gb and 32Gb versions.
Needed:
I don't know enough about Android/SGS3 to know where the .pit is located. Once that's determined, we'll figure out how to extract it and make a functional flash.
Sorry for the false start, still learning here.[/QUOTE\]
Maybe try the code won't work is you have to use with yaffs2 in the middle or somewhere, i know that the phone runs off of that but that's pretty much all i say since i don't know much.
Click to expand...
Click to collapse
joka10 said:
Maybe try the code won't work is you have to use with yaffs2 in the middle or somewhere, i know that the phone runs off of that but that's pretty much all i say since i don't know much.
Click to expand...
Click to collapse
What I was saying is that /dev/block/bml2 doesn't exist in our file structure on this phone.
Code:
C:\Users\my_computer>adb shell
~ # cd /dev/block
cd /dev/block
/dev/block # ls
ls
loop0 mmcblk0boot0 mmcblk0p16 mmcblk0p3 platform ram2
loop1 mmcblk0boot1 mmcblk0p17 mmcblk0p4 ram0 ram3
loop2 mmcblk0p1 mmcblk0p18 mmcblk0p5 ram1 ram4
loop3 mmcblk0p10 mmcblk0p19 mmcblk0p6 ram10 ram5
loop4 mmcblk0p11 mmcblk0p2 mmcblk0p7 ram11 ram6
loop5 mmcblk0p12 mmcblk0p20 mmcblk0p8 ram12 ram7
loop6 mmcblk0p13 mmcblk0p21 mmcblk0p9 ram13 ram8
loop7 mmcblk0p14 mmcblk0p22 mmcblk1 ram14 ram9
mmcblk0 mmcblk0p15 mmcblk0p23 mmcblk1p1 ram15
/dev/block #
As you can see, no bml's of any kind.
I don't know if that's because darkyy was messing with a GB version of Android, or because the phone (Samsung) has put the PIT file in a different location. I've got a PM out to Odia from that I9300 thread and he should have some helpful info as to where it's stored and how to get it.
Stay tuned.
letinsh said:
What I was saying is that /dev/block/bml2 doesn't exist in our file structure on this phone.
Code:
C:\Users\my_computer>adb shell
~ # cd /dev/block
cd /dev/block
/dev/block # ls
ls
loop0 mmcblk0boot0 mmcblk0p16 mmcblk0p3 platform ram2
loop1 mmcblk0boot1 mmcblk0p17 mmcblk0p4 ram0 ram3
loop2 mmcblk0p1 mmcblk0p18 mmcblk0p5 ram1 ram4
loop3 mmcblk0p10 mmcblk0p19 mmcblk0p6 ram10 ram5
loop4 mmcblk0p11 mmcblk0p2 mmcblk0p7 ram11 ram6
loop5 mmcblk0p12 mmcblk0p20 mmcblk0p8 ram12 ram7
loop6 mmcblk0p13 mmcblk0p21 mmcblk0p9 ram13 ram8
loop7 mmcblk0p14 mmcblk0p22 mmcblk1 ram14 ram9
mmcblk0 mmcblk0p15 mmcblk0p23 mmcblk1p1 ram15
/dev/block #
As you can see, no bml's of any kind.
I don't know if that's because darkyy was messing with a GB version of Android, or because the phone (Samsung) has put the PIT file in a different location. I've got a PM out to Odia from that I9300 thread and he should have some helpful info as to where it's stored and how to get it.
Stay tuned.
Click to expand...
Click to collapse
Yea your right it's because he's using a exynos processor instead of the one we have, have you tried replacing the command with those listed above. I know from the odin thread it can't be mmcblk0p1, mmcblk0p15, mmcblk0p18,mmcblk0p14, mmcblk0p12, mmcblk0p13, mmcblk0p17, nor mmcblk0p7.
joka10 said:
Yea your right it's because he's using a exynos processor instead of the one we have, have you tried replacing the command with those listed above. I know from the odin thread it can't be mmcblk0p1, mmcblk0p15, mmcblk0p18,mmcblk0p14, mmcblk0p12, mmcblk0p13, mmcblk0p17, nor mmcblk0p7.
Click to expand...
Click to collapse
Here's the partition table as seen when using the "parted print" command on a properly formatted VZW SGS3 32Gb:
Code:
Disk /dev/block/mmcblk0: 31268536320B
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 4194304B 67108863B 62914560B modem
2 67108864B 67239935B 131072B sbl1
3 67239936B 67502079B 262144B sbl2
4 67502080B 68026367B 524288B sbl3
5 68026368B 70123519B 2097152B aboot
6 70123520B 70647807B 524288B rpm
7 70647808B 81133567B 10485760B boot
8 81133568B 81657855B 524288B tz
9 81657856B 82182143B 524288B pad
10 82182144B 92667903B 10485760B param
11 92667904B 106954751B 14286848B ext4 efs
12 106954752B 110100479B 3145728B modemst1
13 110100480B 113246207B 3145728B modemst2
14 113246208B 1686110207B 1572864000B ext4 system
15 1686110208B 30337400831B 28651290624B ext4 userdata
16 30337400832B 30345789439B 8388608B ext4 persist
17 30345789440B 31226593279B 880803840B ext4 cache
18 31226593280B 31237079039B 10485760B recovery
19 31237079040B 31247564799B 10485760B fota
20 31247564800B 31253856255B 6291456B backup
21 31253856256B 31257001983B 3145728B fsg
22 31257001984B 31257010175B 8192B ssd
23 31257010176B 31262253055B 5242880B grow
So, from this, we know it's not any of the mmcblk0p1 through mmcblk0p23 partitions.
If you notice, partition 1 starts 4Mb into storage. I think the PIT is located somewhere in the first 4Mb, but I don't know what memory addresses/file to look under to grab it.... is it in one of the other locations listed above under /dev/block ? Is it in /dev/block/mmcblk0/ ? I just don't know....
After looking at Heimdall, the tool has an option to rip the PIT, but I haven't been able to get it to recognize my SGS3. I've tried both 1.3.2 and 1.3.1
Once that's ripped, can we flash it using Odin in the PIT field? Or do we have to use Heimdall to to put it back?
letinsh said:
Here's the partition table as seen when using the "parted print" command on a properly formatted VZW SGS3 32Gb:
Code:
Disk /dev/block/mmcblk0: 31268536320B
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 4194304B 67108863B 62914560B modem
2 67108864B 67239935B 131072B sbl1
3 67239936B 67502079B 262144B sbl2
4 67502080B 68026367B 524288B sbl3
5 68026368B 70123519B 2097152B aboot
6 70123520B 70647807B 524288B rpm
7 70647808B 81133567B 10485760B boot
8 81133568B 81657855B 524288B tz
9 81657856B 82182143B 524288B pad
10 82182144B 92667903B 10485760B param
11 92667904B 106954751B 14286848B ext4 efs
12 106954752B 110100479B 3145728B modemst1
13 110100480B 113246207B 3145728B modemst2
14 113246208B 1686110207B 1572864000B ext4 system
15 1686110208B 30337400831B 28651290624B ext4 userdata
16 30337400832B 30345789439B 8388608B ext4 persist
17 30345789440B 31226593279B 880803840B ext4 cache
18 31226593280B 31237079039B 10485760B recovery
19 31237079040B 31247564799B 10485760B fota
20 31247564800B 31253856255B 6291456B backup
21 31253856256B 31257001983B 3145728B fsg
22 31257001984B 31257010175B 8192B ssd
23 31257010176B 31262253055B 5242880B grow
So, from this, we know it's not any of the mmcblk0p1 through mmcblk0p23 partitions.
If you notice, partition 1 starts 4Mb into storage. I think the PIT is located somewhere in the first 4Mb, but I don't know what memory addresses/file to look under to grab it.... is it in one of the other locations listed above under /dev/block ? Is it in /dev/block/mmcblk0/ ? I just don't know....
After looking at Heimdall, the tool has an option to rip the PIT, but I haven't been able to get it to recognize my SGS3. I've tried both 1.3.2 and 1.3.1
Once that's ripped, can we flash it using Odin in the PIT field? Or do we have to use Heimdall to to put it back?
Click to expand...
Click to collapse
Heimdall has never been able to recognize my phone...and I was looking somewhere and the developer said it wasn't working and to try 1.3.1 which was not successful either. I had to borrow a computer to use Odin...I know this isn't a solution for getting heimdall to work but I personally don't think it will...if you do get it to work the steps you took would be appreciated
Sent from my SCH-I535 using xda premium
letinsh said:
Here's the partition table as seen when using the "parted print" command on a properly formatted VZW SGS3 32Gb:
Code:
Disk /dev/block/mmcblk0: 31268536320B
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 4194304B 67108863B 62914560B modem
2 67108864B 67239935B 131072B sbl1
3 67239936B 67502079B 262144B sbl2
4 67502080B 68026367B 524288B sbl3
5 68026368B 70123519B 2097152B aboot
6 70123520B 70647807B 524288B rpm
7 70647808B 81133567B 10485760B boot
8 81133568B 81657855B 524288B tz
9 81657856B 82182143B 524288B pad
10 82182144B 92667903B 10485760B param
11 92667904B 106954751B 14286848B ext4 efs
12 106954752B 110100479B 3145728B modemst1
13 110100480B 113246207B 3145728B modemst2
14 113246208B 1686110207B 1572864000B ext4 system
15 1686110208B 30337400831B 28651290624B ext4 userdata
16 30337400832B 30345789439B 8388608B ext4 persist
17 30345789440B 31226593279B 880803840B ext4 cache
18 31226593280B 31237079039B 10485760B recovery
19 31237079040B 31247564799B 10485760B fota
20 31247564800B 31253856255B 6291456B backup
21 31253856256B 31257001983B 3145728B fsg
22 31257001984B 31257010175B 8192B ssd
23 31257010176B 31262253055B 5242880B grow
So, from this, we know it's not any of the mmcblk0p1 through mmcblk0p23 partitions.
If you notice, partition 1 starts 4Mb into storage. I think the PIT is located somewhere in the first 4Mb, but I don't know what memory addresses/file to look under to grab it.... is it in one of the other locations listed above under /dev/block ? Is it in /dev/block/mmcblk0/ ? I just don't know....
After looking at Heimdall, the tool has an option to rip the PIT, but I haven't been able to get it to recognize my SGS3. I've tried both 1.3.2 and 1.3.1
Once that's ripped, can we flash it using Odin in the PIT field? Or do we have to use Heimdall to to put it back?
Click to expand...
Click to collapse
We can use either or I thin for odin you flash using repartition checked and placing it in the pda field but it will allow us to flash with heimdall using that pit since it can't find the one on the phone. Lastly internal flash /dev/block/mmcblk0 becomes /dev/block/mmcblk1 is what i have found so it looks like either im wrong or it has to be one of the 24 blocks.
Can someone with a working 32 run this in a Terminal? It should pull the PIT from your phone and place it in the SD card. I'm sure those with a 16gb would love to have their PIT file as well.
Code:
dd if=/dev/block/mmcblk0 of=/sdcard/pit.bin bs=4096 count=1 skip=4
Info from HERE (International device, but the blocks should be the same)
Hello
I want to make an image Back-up of my Core and I cannot find something!
I tried the search but I couldn't.
I tried also the rom manager but it does not support my Core.
I want to make this image back up so I can go back if i install an other ROM.
How can I do this?
I hope you can help me!!
(I have already succesfully rooted my phone)
Thank you for your time and help!
trelozakinthinos said:
Hello
I want to make an image Back-up of my Core and I cannot find something!
I tried the search but I couldn't.
I tried also the rom manager but it does not support my Core.
I want to make this image back up so I can go back if i install an other ROM.
How can I do this?
I hope you can help me!!
(I have already succesfully rooted my phone)
Thank you for your time and help!
Click to expand...
Click to collapse
Try this. https://play.google.com/store/apps/details?id=com.h3r3t1c.onnandbup PM me if u have any problems.
Smack that Thanks button if I helped!
KitKat came in on my OmniROM, running on my Note 2.
Sent from a small country called Singapore.
P.S. Time for school, not much time for XDA
Irwenzhao said:
Try this. nandroid PM me if u have any problems.
Smack that Thanks button if I helped!
KitKat came in on my OmniROM, running on my Note 2.
Sent from a small country called Singapore.
P.S. Time for school, not much time for XDA
Click to expand...
Click to collapse
Thank you for your reply... I have used already this app and I have some questions...
a) When it asks me for select device it says
"Your device code is arubaslimss. Please select the path that corresponds to your device!
If device is nit in list please click the Get Identified button"
So my phone is not on the list and I clicked the get identified button and it sends an email
Code:
Android version: REL 4.1.2
onandroid script version: 9.2
Device: arubaslimss samsung samsung GT-I8260
Contents of: /proc/partitions
major minor #blocks name
179 0 7634944 mmcblk0
179 1 20 mmcblk0p1
179 2 175 mmcblk0p2
179 3 20480 mmcblk0p3
179 4 1 mmcblk0p4
179 5 1000 mmcblk0p5
179 6 1000 mmcblk0p6
179 7 2000 mmcblk0p7
179 8 12288 mmcblk0p8
179 9 3072 mmcblk0p9
179 10 3072 mmcblk0p10
179 11 4096 mmcblk0p11
179 12 8192 mmcblk0p12
179 13 12288 mmcblk0p13
179 14 4096 mmcblk0p14
179 15 4096 mmcblk0p15
179 16 12288 mmcblk0p16
179 17 24576 mmcblk0p17
179 18 4096 mmcblk0p18
179 19 512 mmcblk0p19
179 20 2048 mmcblk0p20
179 21 1331200 mmcblk0p21
179 22 737280 mmcblk0p22
179 23 327680 mmcblk0p23
179 24 5115488 mmcblk0p24
179 32 3870720 mmcblk1
179 33 3869696 mmcblk1p1
I din't get any response yet...
b) Without identifying my phone I pressed the backup and it did a 2GB backup.
Although I don't know how to check if this works. I mean I can't my phone restore this backup. Any help?
trelozakinthinos said:
Thank you for your reply... I have used already this app and I have some questions...
a) When it asks me for select device it says
"Your device code is arubaslimss. Please select the path that corresponds to your device!
If device is nit in list please click the Get Identified button"
So my phone is not on the list and I clicked the get identified button and it sends an email
Code:
Android version: REL 4.1.2
onandroid script version: 9.2
Device: arubaslimss samsung samsung GT-I8260
Contents of: /proc/partitions
major minor #blocks name
179 0 7634944 mmcblk0
179 1 20 mmcblk0p1
179 2 175 mmcblk0p2
179 3 20480 mmcblk0p3
179 4 1 mmcblk0p4
179 5 1000 mmcblk0p5
179 6 1000 mmcblk0p6
179 7 2000 mmcblk0p7
179 8 12288 mmcblk0p8
179 9 3072 mmcblk0p9
179 10 3072 mmcblk0p10
179 11 4096 mmcblk0p11
179 12 8192 mmcblk0p12
179 13 12288 mmcblk0p13
179 14 4096 mmcblk0p14
179 15 4096 mmcblk0p15
179 16 12288 mmcblk0p16
179 17 24576 mmcblk0p17
179 18 4096 mmcblk0p18
179 19 512 mmcblk0p19
179 20 2048 mmcblk0p20
179 21 1331200 mmcblk0p21
179 22 737280 mmcblk0p22
179 23 327680 mmcblk0p23
179 24 5115488 mmcblk0p24
179 32 3870720 mmcblk1
179 33 3869696 mmcblk1p1
I din't get any response yet...
b) Without identifying my phone I pressed the backup and it did a 2GB backup.
Although I don't know how to check if this works. I mean I can't my phone restore this backup. Any help?
Click to expand...
Click to collapse
Guess the phone's not supported yet then. But if u already made a backup, backup all your apps using helium (backup to sd) and try restoring using the backup u have. (wipe data first)
Smack that Thanks button if I helped!
KitKat came in on my OmniROM, running on my Note 2.
Sent from a small country called Singapore.
P.S. Time for school, not much time for XDA
trelozakinthinos said:
Hello
I want to make an image Back-up of my Core and I cannot find something!
I tried the search but I couldn't.
I tried also the rom manager but it does not support my Core.
I want to make this image back up so I can go back if i install an other ROM.
How can I do this?
I hope you can help me!!
(I have already succesfully rooted my phone)
Thank you for your time and help!
Click to expand...
Click to collapse
Use CWM to backup the phone. It's way easier. Preferably backup to external sd card
sawan.aware.1 said:
Use CWM to backup the phone. It's way easier. Preferably backup to external sd card
Click to expand...
Click to collapse
CWM does not work with my phone! Not in the list! That's why I was searching for nandroid!
trelozakinthinos said:
CWM does not work with my phone! Not in the list! That's why I was searching for nandroid!
Click to expand...
Click to collapse
Dude follow guide in forum of galaxy core. Cwm is ported for galaxy core amd I am using cwm. It's yet not available in list.
sawan.aware.1 said:
Dude follow guide in forum of galaxy core. Cwm is ported for galaxy core amd I am using cwm. It's yet not available in list.
Click to expand...
Click to collapse
Sorry my friend but I do not understant this. What it means ported?
I downloaded but when i try to find my phone on the list i can't! so I can't use it. Right?
Where exavtly in the galaxy core forum? Give me a link please!
Thank you
trelozakinthinos said:
Sorry my friend but I do not understant this. What it means ported?
I downloaded but when i try to find my phone on the list i can't! so I can't use it. Right?
Where exavtly in the galaxy core forum? Give me a link please!
Thank you
Click to expand...
Click to collapse
Here is the link where you can find cwm for galaxy core and its working. The issues are also discussed.
http://forum.xda-developers.com/showthread.php?t=2517850
1) Remove SD card
2) Boot into CWM Recovery by pressing Power + Volume Up + Home button.
3) Choose "Backup and Restore" and then choose "Backup".
Wait for few minutes and you will get your Nandroid backup in phone's internal memory.
NOTE : You should have enough memory(around 1.8GB - it was in my case) and yup i have got BLACK screen when i did it without removing SD card so i have said remove SD card in the very first step.
I have succesfully backed up my phone's ROM without removing the SD CARD, many times. I haven't got any error's afterall.
Personally, I don't recommend backing up to the internal memory, because it's the /data partition, wich oftenly gets wiped (or you wipe it yourself) when flashing a new ROM.
Just some thought.
MirXas said:
I have succesfully backed up my phone's ROM without removing the SD CARD, many times. I haven't got any error's afterall.
Personally, I don't recommend backing up to the internal memory, because it's the /data partition, wich oftenly gets wiped (or you wipe it yourself) when flashing a new ROM.
Just some thought.
Click to expand...
Click to collapse
You are right friend but i just told him how to take nandroid backup and that is just a matter of common sense that anyone will transfer the backup either to PC or external SD card.
How big is nandroid backup for Core? (Stock rom)
friendfriend said:
How big is nandroid backup for Core? (Stock rom)
Click to expand...
Click to collapse
Depends on what you have. Mine was over 2GB
1 gb
Sent from my GT-I8260 using XDA Premium 4 mobile app
Depends on how much tada you have in your /data and /system partitions, 'cause all of that is backed up. Mine was from 1 to about 1,5 GB.
Sent from my Lenovo A3000-H using xda app-developers app
mine was 1.8 gb on stock odexed rom
Sent from my GT-I8262 using XDA Premium 4 mobile app
Mine iz 1.7gb.
Hi, I finally made the jump to BigPart on my MZ604 Wingray and started off with CM10.1 with the BigPart boot partition. Everything went perfectly and for days I had no problems whatsoever UNTIL I had used up 10GB of my initial 27.7GB free Internal storage with 17.7GB showing as remaining. At this point I can no longer install any apps or updates to existing ones as I get a "not enough storage" error. Also using any file manager, if I try to copy anything to the internal storage it shows that it copied successfully but only the folder names actually copy over, all file content is missing? If I delete some things to achieve more than 17.7GB free I can successfully copy, install, update again until I reach 17.7GB free again!
Everything actually works perfectly except I only seem to have 10GB available instead of the full 27.7GB, indicated in Settings>Storage and any other app I try, after a clean BigPart repartition and format. If I run cat /proc/partitions I get;
179 0 7761920 mmcblk0
179 1 7760896 mmcblk0p1
179 8 31162368 mmcblk1
179 9 3072 mmcblk1p1
179 10 2048 mmcblk1p2
179 11 2048 mmcblk1p3
179 12 4096 mmcblk1p4
179 13 2048 mmcblk1p5
179 14 12288 mmcblk1p6
179 15 8192 mmcblk1p7
259 0 1048576 mmcblk1p8
259 1 524288 mmcblk1p9
259 2 29525504 mmcblk1p10
To me this looks fine but I am no expert. Could anyone shed any light as to why I can only seem to use 10GB of my 27.7GB remaining internal storage? This has now occurred twice in a row after wiping and repartitioning again using the TWRP BigPart recovery and going for my 3rd attempt now as I really would like to be able to use ALL of my internal storage for music etc. as I use my Xoom as my car music player, sat nav, reversing camera display, etc...etc...
OK after deleting, repartitioning, and reformatting the 3rd time it all seems good as I have now been able to use more than 10GB.
I have no idea how or why this occurred but I'm glad it's fixed now.
Hello!
I need enlightenment and help from all of you, I spent hours looking for information and solutions but I wasn't able to find a situation similar to mine, rather small pieces from different scenarios.
Here's my situation:
After installing lj50036's pre-nightly OmniROM and setting it up, I decided to reboot and "clean" it. My BIG mistake was that for some reason (probably sleep-deprivation effects) I thought that doing a format in TWRP was a good idea...yeah, messed up.
I will try my best to describe the current situation and the solutions that I tried...
Currently, I am able to access fastboot and ADB sideload., even able to flash the recovery. The problem lies with not being able to install a ROM properly. What I can't do is access TWRP after a reboot, I must first flash it via fastboot in order to be able to access it, then of course it will reset after a reboot. TWRP will just keep being stuck in a loop if I don't go to fastboot. Whenever I try to install a ROM, it will fail not long after due to errors like : "Unable to mount data, system,cache etc."
I tried the following:
-The 'Repair' option in the advanced menu.
-Formatting using the 'ADB shell..." commands (I'm trying to find the correct command, as soon I arrive to my desktop, I'll update this post). What I did noticed is after entering that command, it would return strange characters. According to some posts, it could be some color formatting but I'm not sure.
-'sideloading' recoveries and ROMs.
INFO:
-Bootloader is 10.6.1.14.10
-Recovery is TWRP 2.8.6.0
From what I read, my guess is to correct the partition errors. Any tips on how to achieve this?
Could this be fixed by flashing a new bootloader or would it make it worse? I don't want to risk it further until I get some professional advice
Any assistance is greatly appreciated, Thank you all!
razgrizpr said:
Hello!
Here's my situation:
After installing lj50036's pre-nightly OmniROM and setting it up, I decided to reboot and "clean" it. My BIG mistake was that for some reason (probably sleep-deprivation effects) I thought that doing a format in TWRP was a good idea...yeah, messed up.
Click to expand...
Click to collapse
Why was doing a format a BIG mistake ???
Thx Josh
lj50036 said:
Why was doing a format a BIG mistake ???
Thx Josh
Click to expand...
Click to collapse
Doesn't formatting via TWRP erase all the data including the OS?
razgrizpr said:
Doesn't formatting via TWRP erase all the data including the OS?
Click to expand...
Click to collapse
Depends what partitions you formatted. The OS is in /system; your data is in /data.
_that said:
Depends what partitions you formatted. The OS is in /system; your data is in /data.
Click to expand...
Click to collapse
Makes sense. So I guess I erased them all? I honestly don't know since I left it formatting and returned a few hours later only to find it turned off. When I booted it, I experienced the mentioned issues. Battery was full as well. So maybe something went wrong during the formatting?
Is there a way to diagnose the partitions?
Did you try this?
http://forum.xda-developers.com/showpost.php?p=54521117&postcount=10
berndblb said:
Did you try this?
http://forum.xda-developers.com/showpost.php?p=54521117&postcount=10
Click to expand...
Click to collapse
Yes, I tried that. Upon entering 'make_ext4fs /dev/block/mmcblk0p8' I get the message 'Need size of file system'.
Found a similar thread where the issue was not being able to mount /data. It appears that for some people 'this' helped them although I'm not sure if I should try it. Others have mentioned 'downgrading' the bootloader and then go through all the process again with success.
razgrizpr said:
Yes, I tried that. Upon entering 'make_ext4fs /dev/block/mmcblk0p8' I get the message 'Need size of file system'.
Found a similar thread where the issue was not being able to mount /data. It appears that for some people 'this' helped them although I'm not sure if I should try it. Others have mentioned 'downgrading' the bootloader and then go through all the process again with success.
Click to expand...
Click to collapse
From recovery run this and post the output ....
Code:
adb pull /proc/partitions
You will get a file called 'partitions' in the current directory.....
Thx Josh
lj50036 said:
From recovery run this and post the output ....
Code:
adb pull /proc/partitions
You will get a file called 'partitions' in the current directory.....
Thx Josh
Click to expand...
Click to collapse
Thank you lj50036, I'm at work at the moment so I will try that as soon I get home and report back.
lj50036 said:
From recovery run this and post the output ....
Code:
adb pull /proc/partitions
You will get a file called 'partitions' in the current directory.....
Thx Josh
Click to expand...
Click to collapse
Here are the results:
Code:
major minor #blocks name
179 0 31039488 mmcblk0
179 32 2048 mmcblk0boot1
179 16 2048 mmcblk0boot0
179 48 31166976 mmcblk1
179 49 24901600 mmcblk1p1
razgrizpr said:
Here are the results:
Code:
major minor #blocks name
179 0 31039488 mmcblk0
179 32 2048 mmcblk0boot1
179 16 2048 mmcblk0boot0
179 48 31166976 mmcblk1
179 49 24901600 mmcblk1p1
Click to expand...
Click to collapse
Code:
major minor #blocks name
179 0 31039488 mmcblk0
179 1 786432 mmcblk0p1
179 2 438272 mmcblk0p2
179 3 2048 mmcblk0p3
179 4 835584 mmcblk0p4
179 5 5120 mmcblk0p5
179 6 512 mmcblk0p6
179 7 5120 mmcblk0p7
179 8 28924416 mmcblk0p8
179 9 8192 mmcblk0p9
179 10 8192 mmcblk0p10
179 32 2048 mmcblk0boot1
179 16 2048 mmcblk0boot0
That is what it should look like ....
So if you still have fastboot flash the pt.blob will give you these partition back ....
After you flash the pt.blob boot back into recovery and run the same command and see it matches mine ...
Thx Josh
lj50036 said:
Code:
major minor #blocks name
179 0 31039488 mmcblk0
179 1 786432 mmcblk0p1
179 2 438272 mmcblk0p2
179 3 2048 mmcblk0p3
179 4 835584 mmcblk0p4
179 5 5120 mmcblk0p5
179 6 512 mmcblk0p6
179 7 5120 mmcblk0p7
179 8 28924416 mmcblk0p8
179 9 8192 mmcblk0p9
179 10 8192 mmcblk0p10
179 32 2048 mmcblk0boot1
179 16 2048 mmcblk0boot0
That is what it should look like ....
So if you still have fastboot flash the pt.blob will give you these partition back ....
After you flash the pt.blob boot back into recovery and run the same command and see it matches mine ...
Thx Josh
Click to expand...
Click to collapse
Thank you so much lj50036!
Looks like correcting the partitions did the trick. After flashing the file, I managed to flash the ROM successfully.
All is good now, thank you all!
razgrizpr said:
Thank you so much lj50036!
Looks like correcting the partitions did the trick. After flashing the file, I managed to flash the ROM successfully.
All is good now, thank you all!
Click to expand...
Click to collapse
Great to see you up and running ....
Can you add 'SOLVED' to the thread tittle ...... :good:
Thx Josh
Software root method for Mediatek MT816x, MT817x and MT67xx!
A tool that gives you a temporary root shell with Selinux permissive to do with as you please
STATUS
Confirmed Working
Fire HD 8 8th gen (2018) (thanks @xyz`) -- up to Fire OS 6.3.0.1 only
Fire HD 8 7th gen (2017) -- up to Fire OS 5.6.4.0 build 636558520 only
Fire HD 8 6th gen (2016) (thanks @bibikalka) -- up to Fire OS 5.3.6.4 build 626536720
Fire HD 10 7th gen (2017) (thanks @bibikalka) -- up to Fire OS 5.6.4.0 build 636558520 only
Fire TV 2 2015 (mt8173-based) (thanks @el7145) -- up to Fire OS 5.2.6.9 only
Fire 7 9th gen (2019) (thanks @Michajin) -- up to Fire OS 6.3.1.2 build 0002517050244 only
Fire HD 10 9th gen (2019) -- up to Fire OS 7.3.1.0 only
Various phones and tablets up to Android 9.x (see link below for full list)
Note that for Fire OS 5, OS version 5.3.x.x is newer than 5.6.x.x.
Amazing Temp Root for MediaTek ARMv8: expanded thread covering all compatible MTK devices
DISCLAIMER
Anything you do that is described in this thread is at your own risk. No one else is responsible for any data loss, corruption or damage of your device, including that which results from bugs in this software.
REQUIREMENTS
Proficiency with the Thanks button under XDA posts
A Fire HD tablet based on mt8163 or mt8173 (or another MTK ARMv8 device)
Either:
A PC with ADB installed to interact with your device, or
A terminal emulator app
Familiarity with ADB (if using PC) and basic Linux shell commands
INSTRUCTIONS
Download the current mtk-su zip file to your PC and unzip it. Inside will be 2 directories: 'arm' & 'arm64' with an 'mtk-su' binary in each. Pick one for your device. Differences between the flavors:
arm64: 64-bit kernel and userspace
arm: 32-bit userspace on a 64-bit or 32-bit kernel (will also work in 64-bit userspace)
The arm64 one is suitable for most devices. The notable devices that need the arm version are the Fire HD 8 2018, Fire 7, and Fire HD 10 2019.
Connect your device to ADB and push mtk-su to your /data/local/tmp folder
Code:
adb push path/to/mtk-su /data/local/tmp/
Open an adb shell
Code:
adb shell
Change to your tmp directory
Code:
cd /data/local/tmp
Add executable permissions to the binary
Code:
chmod 755 mtk-su
At this point keep your tablet screen on and don't let it go to sleep. Run the program
Code:
./mtk-su
If the program gets stuck for more than a few seconds, press Ctrl+C to close it.
The -v option turns on verbose printing, which is necessary for me to debug any problems.
It will take several seconds, but using the -v option, you should see output similar to this (with id command added):
Code:
$ ./mtk-su -v
param1: 0x3000, param2: 0x18040, type: 2
Building symbol table
kallsyms_addresses pa 0x40bdd500
kallsyms_num_syms 70337, addr_count 70337
kallsyms_names pa 0x40c66d00, size 862960
kallsyms_markers pa 0x40d39800
kallsyms_token_table pa 0x40d3a100
kallsyms_token_index pa 0x40d3a500
Patching credentials
Parsing current_is_single_threaded
ffffffc000354868+50: ADRP x0, 0xffffffc000fa2000
ffffffc000354868+54: ADD xd, x0, 2592
init_task VA: 0xffffffc000fa2a20
Potential list_head tasks at offset 0x340
comm swapper/0 at offset 0x5c0
Found own task_struct at node 1
cred VA: 0xffffffc0358ac0c0
Parsing avc_denied
ffffffc0002f13bc+24: ADRP x0, 0xffffffc001113000
ffffffc0002f13bc+28: LDR [x0, 404]
selinux_enforcing VA: 0xffffffc001113194
Setting selinux_enforcing
Switched selinux to permissive
starting /system/bin/sh
UID: 0 cap: 3fffffffff selinux: permissive
#
Some other options:
mtk-su -c <command>: Runs <command> as root. Default command is /system/bin/sh.mtk-su -s: Prints the kernel symbol tableIf you see any errors other than about unsupported or incompatible platform or don't get a root shell, report it here.
Important: in rare cases, it may be necessary to run the tool multiple times before you hit UID 0 and get selinux permissive. If you don't achieve root on a particular run, the "UID: N cap: xxxxx...." line will reflect that. If it doesn't say "UID: 0 cap: 3fffffffff selinux: permissive", type exit to close the subshell and try mtk-su again.
If you succeed in getting temporary root, at that point you might want to install SuperSU for a more permanent root solution. Here is the official guide on which files should be present to kickstart SuperSU from temporary root. They are available in the latest SuperSU zip file. Remember that this only applies to Fire OS 5.
FIRE OS 5 AND ANDROID 5 USERS: There's an automated SuperSU loader by @Rortiz2 that makes jumpstarting SuperSU quick and easy.
WARNING FOR FIRE HD 8 2018 AND OTHER FIRE OS 6 DEVICES: If you have achieved root on such a device, do not remount the system partition as read/write. The remount command will probably not work. But forcing it will trigger dm-verity, which will result in a very bad day. Your tablet will become inoperable until you restore the stock system partition. You can accomplish a lot without modifying /system. But if you would like to get persistent root with Magisk by unlocking the bootloader, head on over to @bibikalka's outstanding Unlock/Magisk/TWRP Tutorial.
DOWNLOAD
Current Version
Release 23
Past releases & change log live at Amazing Temp Root for MediaTek ARMv8
FAQ
I got the error, "This firmware cannot be supported". What do I do?
This means that your device's firmware is not prone to the mechanism used by mtk-su. Check the firmware version and build number of the OS on your device. If your version is higher than that next to your device on the list above, then mtk-su will no longer work on your device. There may be other ways to achieve root. Check elsewhere on the forum.
Will this work on the Fire 7?
No, it is very doubtful this method can be used on the MT8127 chipset. The same also goes for the Fire TV stick.
After getting a root shell I'm still getting 'permission denied' errors. WTH?
It may be that selinux is still being enforced. Having root with selinux enabled is somehow more restrictive than a normal shell user. First, check that mtk-su succeeded in setting selinux to permissive by running getenforce. If it says Enforcing, then exit your shell and run mtk-su again.
Does this thing unlock the bootloader?
No, it does nothing to unlock the bootloader. But after running mtk-su, you may be able to use @xyz`'s revolutionary LK exploit or derivative works to achieve what is effectively an unlocked bootloader on some devices. Namely, you should be able to flash the specially crafted TWRP image using dd from Android.
How does this tool work?
It overwrites the process's credentials & capabilities in the kernel in order to gain privileges. It also turns off selinux enforcement by overwriting the kernel's selinux_enforcing variable. As for how it accesses that memory, I don't think I should discuss that as of yet.
Will this work on the Fire TV Stick 4K?
Unfortunately, no. While it has a 64-bit chip, the required vulnerabilities are not present in its OS.
Can I include mtk-su in my app or meta-tool?
Generally speaking, you may not distribute any mtk-su zip or binaries with your software. That includes doing any automatic download of those files into your app. You can still use it with your tools. But you should ask your users to visit this thread and download the current release zip themselves. No apps have been permitted to bundle or auto-download mtk-su.
Why don't you reply to my post?
I read every post in this thread, and respond to practically every post that warrants a response. Sometimes I will only click a Thanks as an acknowledgement. The reasons I may not answer your question are:
It has already been answered in the FAQ or multiple times in the thread.
Your post is unrelated to this project. It may be specific to your device, which would make it off topic for this thread.
Your question is extremely vague and you appear to be intentionally leaving out basic information (e.g. fishing).
CREDITS
@Supersonic27543 for helping me port it to Fire OS 5 and namely the HD 8 7th gen
Thank you to everyone who has donated. You're the best!
I want to thank you again for your efforts on this! I was ill the days before, so I didn't get much time to test SuperSU, and I'm trying to make a script now. Good luck to everyone who tries this!
EDIT: Oops, sorry for the reserve post.
How to use without a PC
INSTRUCTIONS FOR TERMINAL APP
You can optionally use mtk-su from a terminal emulator such as Termux or Terminal Emulator for Android (my preference). The gist of the process is to copy the executable to the terminal app's internal directory and run it from there. These are the instructions for Termux, but a similar procedure applies to all terminal shell apps.
Download the current mtk_su zip to your device and unzip it. Take note of where you extracted it. Pick the variant that fits your device. (See above.)
Open Termux and copy the mtk-su binary to its home directory, which in this case is the shell's initial working directory.
General idea: cp path/to/mtk-su ./
For example,
Code:
cp /sdcard/mtk-su_r14/arm64/mtk-su ./
For this to work, you have to enable the Storage permission for your term app. Do not try to circumvent the cp command with clever copying methods involving file managers or external tools. Mtk-su will not get the right permissions that way.
Make file executable
Code:
chmod 700 mtk-su
Run the program
Code:
./mtk-su
If mtk-su fails, post the output of ./mtk-su -v here along with a link to firmware and kernel sources, if possible.
Note that for most terminal shell apps, the internal app directory is stored in the variable $HOME. So in general you would do
cd
cp path/to/mtk-su ./
chmod 700 mtk-su
./mtk-su
Great work!
So could this theoretically work for any Mediatek device? Or do specific modifications need to be done for another model chip?
What do you think is likely the worst to happen if this is tried as-is on another device? Will it just not work? Or explode the device?
I have an Acer B3-A40 that has an MT8167 chip that I wouldn't mind rooting.
@cybersaga, yes, it's very possible it will work on an mt8167 device. Although I can't 100% guarantee it won't damage your device, I would just go ahead and try it. The risk is very minimal. It will print some error if it fails. I think realistically, I would need to tweak some parameters or make a workaround if there's a problem.
The method should be applicable to most 64-bit platforms. There are newer 4.x kernels where the necessary hole is not present, though. But time will tell what devices this ultimately will be compatible with.
That's super neat. I'll probably give it a try sometime this week.
Very cool from what I can see, however it doesn't work on HD8 2018 because there's no 64-bit userspace (only the kernel is 64-bit), could you recompile it for arm?
Oh, that's a bummer, @xyz`. Why would they do that? I think there's some other tweaks I have to make besides compiling it. I'll post a test version as soon as I can. This might be the case for other devices too...
diplomatic said:
Oh, that's a bummer, @xyz`. Why would they do that? I think there's some other tweaks I have to make besides compiling it. I'll post a test version as soon as I can. This might be the case for other devices too...
Click to expand...
Click to collapse
Maybe you can just compile it as a static binary instead if that's easier.
Awesome! I just rooted my HD8 2017
Try the automated script by @Rortiz2
Previous instructions:
For anyone that is confused by the process of manually installing SuperSu, I did the following...
IMPORTANT: This is for FireOS 5 devices such as HD8 2017. Do not attempt this on HD8 2018
Install SuperSu from Playstore
Download SuperSu and unzip somewhere
adb push arm64/su arm64/supolicy arm64/libsupol.so /data/local/tmp
Follow directions from OP to get a root shell. You should not get permission denied when running ls. If you see permission denied, run exit and try again. Took me a few tries
mount -o remount -rw /system
cp /data/local/tmp/su /system/xbin/su
cp /data/local/tmp/su /system/xbin/daemonsu
cp /data/local/tmp/supolicy /system/xbin/
cp /data/local/tmp/libsupol.so /system/lib/
cp /data/local/tmp/libsupol.so /system/lib64/
chmod 0755 /system/xbin/su
chcon ubject_r:system_file:s0 /system/xbin/su
chmod 0755 /system/xbin/daemonsu
chcon ubject_r:system_file:s0 /system/xbin/daemonsu
at this point, running su should work and show a root shell
daemonsu --auto-daemon
Open SuperSu app and allow it to update the su binary
My tablet hung at the boot logo when I manually installed SuperSu via the linked instructions. Installing the bare minimum and letting the SuperSu app do the rest seems less error-prone
@diplomatic
Wow!!! This is crazy !!! Where have you been before??? I almost had to drill a hole into HD8 2016!!!
I tried this on HD8 2016, FireOS 5.3.2.1, and the method worked! It takes less than 1 second to run, way faster than any Kingoroot. I had to exit and run again to get system mounting permissions rw as per @dutchthomas recommendation {mount -o remount -rw /system}. Then I updated su manually (using armv7 binaries from SR5-SuperSU-v2.82-SR5-20171001224502.zip - on HD10 2017 I am always using armv7 versions as well), and let SuperSu update itself. Full success! SuperSu needs to be set to "Grant" as per this link.
Now, for HD8 2018 I believe the following could work. 0) Drain the battery to really minimal amount ~ 3% 1) Run this to get temp root. 2) Zero out boot0 {dd if=/dev/zero of=/dev/block/mmcblk0boot0}. At this point the device should be booting into BootRom mode (as claimed by others - @xyz`, @hwmod, @k4y0z, can you confirm?). In BootRom, run the scripts from this link. If it hangs in BootRom, just let it sit disconnected from anything. The low battery should shut it down, and you can try again later in BootRom. Low battery would remove the need to open the case should the amonet script hang.
Actually, for HD8 2018, if RPMB does not need to be cleared, all of amonet steps could be done via dd while having a temporary root shell. One could dd all of LK/TZ/boot/recovery/preloader. If RPMB needs clearing, then one should still dd everything but the preloader, which instead should be zeroed out {dd if=/dev/zero of=/dev/block/mmcblk0boot0}. Then amonet would be used to clear our RPMB, and put the preloader back. One of the current seeming issues is that amonet appears to write LK exploit into the memory area outside of boot0 size (thus precluding dd operation for that piece of code into boot0) - see this link for details. If this issue could be addressed, then HD8 2018 could be unlockable without ever opening the case.
My HD8 2016 output:
Code:
C:\Program Files\Minimal ADB and Fastboot>adb shell
[email protected]:/ $ cd /data/local/tmp
[email protected]:/data/local/tmp $ chmod 755 mtk-su
[email protected]:/data/local/tmp $ ./mtk-su -v
Building symbol table
kallsyms_addresses_pa 0x40ad8f00
kallsyms_num_syms 67082, addr_count 67082
kallsyms_names_pa 0x40b5c100
Size of kallsyms_names 805834 bytes
kallsyms_markers_pa 0x40c20d00
kallsyms_token_table_pa 0x40c21600
kallsyms_token_index_pa 0x40c21a00
Patching credentials
init_task va: ffffffc000edaa20
Possible list_head tasks at offset 0x338
0xffffffc0030c8338 0xffffffc050347638 0x000000000000008c
comm offset 0x5a8 comm: swapper/0
Found own task_struct at node 0
real_cred: 0xffffffc052669900, cred: 0xffffffc052669900
New UID/GID: 0/0
Setting selinux permissive
Found adrp at offset 4
ADRP x0, base is 0xffffffc001030000
Found ldr at offset 28
LDR [x0,444], selinux_enforce VA is 0xffffffc0010301bc
Switched selinux to permissive
starting /system/bin/sh
[email protected]:/data/local/tmp #
Edit: Despite my super careful SuperSu injection into FireOS 5.3.6.4 system image, I still could not get SuperSu to work after I restored this image using FlashFire. Regardless, the method from this thread also rooted 5.3.6.4 in no time! Awesome!
dutchthomas said:
Awesome! I just rooted my HD8 2017
For anyone that is confused by the process of manually installing SuperSu, I did the following:
Install SuperSu from Playstore
Download SuperSu and unzip somewhere
adb push arm64/su arm64/supolicy arm64/libsupol.so /data/local/tmp
Follow directions from OP to get a root shell. You should not get permission denied when running ls. If you see permission denied, run exit and try again. Took me a few tries
mount -o remount -rw /system
cp /data/local/tmp/su /system/xbin/su
cp /data/local/tmp/su /system/xbin/daemonsu
cp /data/local/tmp/supolicy /system/xbin/
cp /data/local/tmp/libsupol.so /system/lib/
cp /data/local/tmp/libsupol.so /system/lib64/
at this point, running su should work and show a root shell
daemonsu --auto-daemon
Open SuperSu app and allow it to update the su binary
My tablet hung at the boot logo when I manually installed SuperSu via the linked instructions. Installing the bare minimum and letting the SuperSu app do the rest seems like a less error-prone middle ground.
Click to expand...
Click to collapse
Thanks for this! I'm not sure if I'm doing it correctly, but everything works fine until I get to #11. Do I just type su? When I do, it says permission denied.
EDIT: Just tried the new commands you edited and it worked. My FireHD 8 7th gen is now rooted.
diplomatic said:
Software root method found for Mediatek MT8163, MT8173 and MT67xx!
Click to expand...
Click to collapse
Great work!
bibikalka said:
Now, for HD8 2018 I believe the following could work. 0) Drain the battery to really minimal amount ~ 3% 1) Run this to get temp root. 2) Zero out boot0 {dd if=/dev/zero of=/dev/block/mmcblk0boot0}. At this point the device should be booting into BootRom mode (as claimed by others - @xyz`, @hwmod, @k4y0z, can you confirm?). In BootRom, run the scripts from this link. If it hangs in BootRom, just let it sit disconnected from anything. The low battery should shut it down, and you can try again later in BootRom. Low battery would remove the need to open the case should the amonet script hang.
Actually, for HD8 2018, if RPMB does not need to be cleared, all of amonet steps could be done via dd while having a temporary root shell. One could dd all of LK/TZ/boot/recovery/preloader. If RPMB needs clearing, then one should still dd everything but the preloader, which instead should be zeroed out {dd if=/dev/zero of=/dev/block/mmcblk0boot0}. Then amonet would be used to clear our RPMB, and put the preloader back. One of the current seeming issues is that amonet appears to write LK exploit into the memory area outside of boot0 size (thus precluding dd operation for that piece of code into boot0) - see this link for details. If this issue could be addressed, then HD8 2018 could be unlockable without ever opening the case.
Click to expand...
Click to collapse
If you want to zero out preloader, you should do it this way:
Code:
su -c "echo 0 > /sys/block/mmcblk0boot0/force_ro; cat /dev/zero > /dev/block/mmcblk0boot0; echo 'EMMC_BOOT' > /dev/block/mmcblk0boot0"
that way the sanity check of amonet won't fail.
I'm not sure about the boot0 size on the HD8. According to @xyz` it is 4MB on the HD8 as well.
bibikalka said:
@diplomatic
Wow!!! This is crazy !!! Where have you been before??? I almost had to drill a hole into HD8 2016!!!
I tried this on HD8 2016, FireOS 5.3.2.1, and the method worked! It takes less than 1 second to run, way faster than any Kingoroot. I had to exit and run again to get system mounting permissions rw as per @dutchthomas recommendation {mount -o remount -rw /system}. Then I updated su manually (using armv7 binaries from SR5-SuperSU-v2.82-SR5-20171001224502.zip - on HD10 2017 I am always using armv7 versions as well), and let SuperSu update itself. Full success! SuperSu needs to be set to "Grant" as per this link.
Now, for HD8 2018 I believe the following could work. 0) Drain the battery to really minimal amount ~ 3% 1) Run this to get temp root. 2) Zero out boot0 {dd if=/dev/zero of=/dev/block/mmcblk0boot0}. At this point the device should be booting into BootRom mode (as claimed by others - @xyz`, @hwmod, @k4y0z, can you confirm?). In BootRom, run the scripts from this link. If it hangs in BootRom, just let it sit disconnected from anything. The low battery should shut it down, and you can try again later in BootRom. Low battery would remove the need to open the case should the amonet script hang.
Actually, for HD8 2018, if RPMB does not need to be cleared, all of amonet steps could be done via dd while having a temporary root shell. One could dd all of LK/TZ/boot/recovery/preloader. If RPMB needs clearing, then one should still dd everything but the preloader, which instead should be zeroed out {dd if=/dev/zero of=/dev/block/mmcblk0boot0}. Then amonet would be used to clear our RPMB, and put the preloader back. One of the current seeming issues is that amonet appears to write LK exploit into the memory area outside of boot0 size (thus precluding dd operation for that piece of code into boot0) - see this link for details. If this issue could be addressed, then HD8 2018 could be unlockable without ever opening the case.
My HD8 2016 output:
Code:
C:\Program Files\Minimal ADB and Fastboot>adb shell
[email protected]:/ $ cd /data/local/tmp
[email protected]:/data/local/tmp $ chmod 755 mtk-su
[email protected]:/data/local/tmp $ ./mtk-su -v
Building symbol table
kallsyms_addresses_pa 0x40ad8f00
kallsyms_num_syms 67082, addr_count 67082
kallsyms_names_pa 0x40b5c100
Size of kallsyms_names 805834 bytes
kallsyms_markers_pa 0x40c20d00
kallsyms_token_table_pa 0x40c21600
kallsyms_token_index_pa 0x40c21a00
Patching credentials
init_task va: ffffffc000edaa20
Possible list_head tasks at offset 0x338
0xffffffc0030c8338 0xffffffc050347638 0x000000000000008c
comm offset 0x5a8 comm: swapper/0
Found own task_struct at node 0
real_cred: 0xffffffc052669900, cred: 0xffffffc052669900
New UID/GID: 0/0
Setting selinux permissive
Found adrp at offset 4
ADRP x0, base is 0xffffffc001030000
Found ldr at offset 28
LDR [x0,444], selinux_enforce VA is 0xffffffc0010301bc
Switched selinux to permissive
starting /system/bin/sh
[email protected]:/data/local/tmp #
Click to expand...
Click to collapse
Thanks for the feedback, bro! So the HD8 2016 is crossed off the untested list. For the HD8 2018, as far as I see, you can just flash the premade TWRP to recovery by dd. Why do you need to do the whole bootrom procedure? Then reboot to recovery to check if everything's ok. If not, Android will just restore the stock recovery on next boot. If TWRP works, just install Magisk or whatever you do to modify boot.
dutchthomas said:
Awesome! I just rooted my HD8 2017
For anyone that is confused by the process of manually installing SuperSu, I did the following:
Install SuperSu from Playstore
Download SuperSu and unzip somewhere
adb push arm64/su arm64/supolicy arm64/libsupol.so /data/local/tmp
Follow directions from OP to get a root shell. You should not get permission denied when running ls. If you see permission denied, run exit and try again. Took me a few tries
mount -o remount -rw /system
cp /data/local/tmp/su /system/xbin/su
cp /data/local/tmp/su /system/xbin/daemonsu
cp /data/local/tmp/supolicy /system/xbin/
cp /data/local/tmp/libsupol.so /system/lib/
cp /data/local/tmp/libsupol.so /system/lib64/
at this point, running su should work and show a root shell
daemonsu --auto-daemon
Open SuperSu app and allow it to update the su binary
My tablet hung at the boot logo when I manually installed SuperSu via the linked instructions. Installing the bare minimum and letting the SuperSu app do the rest seems like a less error-prone middle ground.
Click to expand...
Click to collapse
Oh, nice, thanks for this... This is more straightfoward than doing it "offline". I just realized Chainfire has instructions specifically for dealing with exploits here.
diplomatic said:
Thanks for the feedback, bro! So the HD8 2016 is crossed off the untested list. For the HD8 2018, as far as I see, you can just flash the premade TWRP to recovery by dd. Why do you need to do the whole bootrom procedure? Then reboot to recovery to check if everything's ok. If not, Android will just restore the stock recovery on next boot. If TWRP works, just install Magisk or whatever you do to modify boot.
Click to expand...
Click to collapse
Flashing TWRP isn't enough.
LK-payload needs to be written to boot0 at offset 0x200000.
Additionally you need to have the correct version of LK installed.
If you have an older version it could just be overwritten.
If your installed LK is newer, you will have to zero out RPMB.
LOL
Very nice!
Awesome work @diplomatic
If you had discovered it before, I would not have asked you to compile TWRP for the BQ M8 and I would not have bothered you. By the way I I prefer to have TWRP. (thanks!)
I have reinstalled stock in my BQ M8 and the script has worked! If you want you can add it to the list of devices...
On Fire 7 7th Gen it not worked.. But we have TWRP.
EDIT: I have tried again and now I get this error
Code:
130|[email protected]_M8:/data/local/tmp $ ./mtk-su -v
Building symbol table
kallsyms_addresses_pa 0x40a43000
kallsyms_num_syms 49221, addr_count 49221
kallsyms_names_pa 0x40aa3400
Size of kallsyms_names 602609 bytes
kallsyms_markers_pa 0x40b36600
kallsyms_token_table_pa 0x40b36c00
warning: token_count 1
kallsyms_token_index_pa 0x40b36d00
Patching credentials
__ksymtab_init_task not found
New UID/GID: 2000/2000
Setting selinux permissive
find_selinux_enforce_var() returned -1
starting /system/bin/sh
k4y0z said:
Flashing TWRP isn't enough.
LK-payload needs to be written to boot0 at offset 0x200000.
Additionally you need to have the correct version of LK installed.
If you have an older version it could just be overwritten.
If your installed LK is newer, you will have to zero out RPMB.
Click to expand...
Click to collapse
diplomatic said:
... For the HD8 2018, as far as I see, you can just flash the premade TWRP to recovery by dd. Why do you need to do the whole bootrom procedure? Then reboot to recovery to check if everything's ok. If not, Android will just restore the stock recovery on next boot. If TWRP works, just install Magisk or whatever you do to modify boot.
Click to expand...
Click to collapse
Yep! Cannot just flash TWRP on HD8 2018 - need to also unlock bootloader, otherwise TWRP won't boot. Which is not a problem, and in theory can be done all via dd - except for the amonet address issue (2Mb), see more below.
k4y0z said:
If you want to zero out preloader, you should do it this way:
Code:
su -c "echo 0 > /sys/block/mmcblk0boot0/force_ro; cat /dev/zero > /dev/block/mmcblk0boot0; echo 'EMMC_BOOT' > /dev/block/mmcblk0boot0"
that way the sanity check of amonet won't fail.
I'm not sure about the boot0 size on the HD8. According to @xyz` it is 4MB on the HD8 as well.
Click to expand...
Click to collapse
OK - once boot0 is zeroed out, how does one get into BootRom after that? One basically turns off the tablet, and then plugs it into Linux with amonet listening? Which tablet models were tested so far with this BootRom activation method?
For the boot0 size, see these outputs from 2 tablets, 'cat /proc/partitions'. In both cases, boot0 is only 1Mb - 1024 blocks below. So it's not possible to dd beyond that 1Mb from within FireOS. If the exploit was placed at ~512 Kb, then it'd be all in range.
Fire HD8 2016:
Code:
major minor #blocks name
179 0 15388672 mmcblk0
179 1 3072 mmcblk0p1
179 2 5120 mmcblk0p2
179 3 10240 mmcblk0p3
179 4 10240 mmcblk0p4
179 5 256 mmcblk0p5
179 6 500 mmcblk0p6
179 7 16268 mmcblk0p7
179 8 16384 mmcblk0p8
179 9 6144 mmcblk0p9
179 10 512 mmcblk0p10
179 11 8192 mmcblk0p11
179 12 10240 mmcblk0p12
179 13 1024 mmcblk0p13
179 14 5120 mmcblk0p14
179 15 5120 mmcblk0p15
179 16 40320 mmcblk0p16
179 17 1024 mmcblk0p17
179 18 1024 mmcblk0p18
179 19 1653024 mmcblk0p19
179 20 434176 mmcblk0p20
179 21 512 mmcblk0p21
179 22 16384 mmcblk0p22
179 23 4320 mmcblk0p23
179 24 13138927 mmcblk0p24
179 96 4096 mmcblk0rpmb
179 64 4096 mmcblk0boot1
179 32 1024 mmcblk0boot0
179 33 2 mmcblk0boot0p1
179 34 2 mmcblk0boot0p2
179 35 256 mmcblk0boot0p3
179 36 747 mmcblk0boot0p4
Fire HD8 2018:
Code:
major minor #blocks name
179 0 15267840 mmcblk0
179 1 3072 mmcblk0p1
179 2 4608 mmcblk0p2
179 3 1024 mmcblk0p3
179 4 1024 mmcblk0p4
179 5 1024 mmcblk0p5
179 6 5120 mmcblk0p6
179 7 5120 mmcblk0p7
179 8 40448 mmcblk0p8
179 9 512 mmcblk0p9
179 10 8192 mmcblk0p10
179 11 16384 mmcblk0p11
179 12 20480 mmcblk0p12
179 13 3177472 mmcblk0p13
179 14 230400 mmcblk0p14
179 15 512000 mmcblk0p15
179 16 11240431 mmcblk0p16
179 96 4096 mmcblk0rpmb
179 64 4096 mmcblk0boot1
179 32 1024 mmcblk0boot0
179 33 2 mmcblk0boot0p1
179 34 2 mmcblk0boot0p2
179 35 256 mmcblk0boot0p3
179 36 747 mmcblk0boot0p4
@diplomatic - awesome work - just had to give it a go for myself...
Factory reset my HD8 (2017) (root originally via @t0x1cSH "Fire hd8 2017 root, debrick" post) and followed your post plus the 'speedy SU install' from @dutchthomas - post 10.
One difficulty: mtk-su seemed to run fine and UID= 0 was shown - but I did have trouble getting the the 'mount -o remount -rw /system' command to work at first - it needed a few attempts.
And then, using the work-through from post 10, I couldn't get full root (i.e. 'su' accepted at command prompt) until I changed permissions on each of the copied SU components (su, daemonsu etc) to those prescribed in @<br />'s awesome Hardmod post.
Bit strange? I was using Fire OS 5.3.6.0 - I wonder if version makes any difference? Got there eventually tho' :good:
bibikalka said:
Yep! Cannot just flash TWRP on HD8 2018 - need to also unlock bootloader, otherwise TWRP won't boot. Which is not a problem, and in theory can be done all via dd - except for the amonet address issue (2Mb), see more below.
OK - once boot0 is zeroed out, how does one get into BootRom after that? One basically turns off the tablet, and then plugs it into Linux with amonet listening? Which tablet models were tested so far with this BootRom activation method?
For the boot0 size, see these outputs from 2 tablets, 'cat /proc/partitions'. In both cases, boot0 is only 1Mb - 1024 blocks below. So it's not possible to dd beyond that 1Mb from within FireOS. If the exploit was placed at ~512 Kb, then it'd be all in range.
Fire HD8 2016:
Code:
major minor #blocks name
179 0 15388672 mmcblk0
179 1 3072 mmcblk0p1
179 2 5120 mmcblk0p2
179 3 10240 mmcblk0p3
179 4 10240 mmcblk0p4
179 5 256 mmcblk0p5
179 6 500 mmcblk0p6
179 7 16268 mmcblk0p7
179 8 16384 mmcblk0p8
179 9 6144 mmcblk0p9
179 10 512 mmcblk0p10
179 11 8192 mmcblk0p11
179 12 10240 mmcblk0p12
179 13 1024 mmcblk0p13
179 14 5120 mmcblk0p14
179 15 5120 mmcblk0p15
179 16 40320 mmcblk0p16
179 17 1024 mmcblk0p17
179 18 1024 mmcblk0p18
179 19 1653024 mmcblk0p19
179 20 434176 mmcblk0p20
179 21 512 mmcblk0p21
179 22 16384 mmcblk0p22
179 23 4320 mmcblk0p23
179 24 13138927 mmcblk0p24
179 96 4096 mmcblk0rpmb
179 64 4096 mmcblk0boot1
179 32 1024 mmcblk0boot0
179 33 2 mmcblk0boot0p1
179 34 2 mmcblk0boot0p2
179 35 256 mmcblk0boot0p3
179 36 747 mmcblk0boot0p4
Fire HD8 2018:
Code:
major minor #blocks name
179 0 15267840 mmcblk0
179 1 3072 mmcblk0p1
179 2 4608 mmcblk0p2
179 3 1024 mmcblk0p3
179 4 1024 mmcblk0p4
179 5 1024 mmcblk0p5
179 6 5120 mmcblk0p6
179 7 5120 mmcblk0p7
179 8 40448 mmcblk0p8
179 9 512 mmcblk0p9
179 10 8192 mmcblk0p10
179 11 16384 mmcblk0p11
179 12 20480 mmcblk0p12
179 13 3177472 mmcblk0p13
179 14 230400 mmcblk0p14
179 15 512000 mmcblk0p15
179 16 11240431 mmcblk0p16
179 96 4096 mmcblk0rpmb
179 64 4096 mmcblk0boot1
179 32 1024 mmcblk0boot0
179 33 2 mmcblk0boot0p1
179 34 2 mmcblk0boot0p2
179 35 256 mmcblk0boot0p3
179 36 747 mmcblk0boot0p4
Click to expand...
Click to collapse
When you execute that command, simply turn off the tablet and when you connect it to the PC it will detect it in BootROM Mode. Checked in Fire 7 2017.
Wait, will this work for a mt6753 chipset?