Related
[GUIDE] Huawei Ascend G6 LTE [G6-L11] (Root & Xposed Framework)
ROOTING
Phone was rooted using ROOT Genius
- Download from shuame.com/en/root/
- Install and turn on USB debugging on your phone
- Connect the phone and wait for a little bit, it will work
- After rooting your phone will reboot
*Users who rooted with TOWELROOT*
When rooting with Towelroot there is a problem accesing partitions in root mode.
So now please use Root Genius method!
Uninstalling Towelroot
- Uninstall Towelroot (tr.apk) like normal app
- Go to SuperSU, settings then press permanent unroot
- Check your root status, then reboot the phone
- Now you can root with ROOT Genius method
You can check root with Root Checker or similar app.
Congratulations, your phone is rooted now
Xposed Framework
Xposed Framework will work only if you rooted the phone!
- Download Xposed Framework dl.xposed.info/latest.apk and install it
***Xposed will not work on Huawei devices because of conflict between Xposed and Huawei Theme engeine***
To make it work there are 2 options:
1 - Launch Xposed Installer, go to Settings and in the bottom tick "Disabled resource hooks"
Note: many modules will NOT work with this option checked
2 - This option involves editing build.prop file so be VERY CAREFUL! Also please BACKUP your build.prop file before editing!!!
You need to DISABLE Huawei Theme engeine then you DONT NEED "Disabled resource hook" and many modules will work.
In build.prop file you need to change this line: ro.config.hwtheme=2 to this line: ro.config.hwtheme=0
*If you dont have this line you have to add it
To edit build.prop file download app "BuildProp Editor" from Google play run it, allow root privileges for app
and tick search (down left corner)
Write "ro.config.hwtheme" tick the found line and change PROPERTY VALUE to 0 and tick save.
BE VERY CAREFUL TO NOT CHANGE ANY OTHER LINE THAN THIS!
After applying option 1 or 2 you can install Xposed Framework. (I recommend option 2 beacuse more modules will work)
Open the Xposed Installer, go to Framework (press OK) (make shure that INSTALLATION MODE is Classical (write to /system directly)
then tick Install/Update button and finnaly reboot the phone.
You now have fully working Xposed
Some nice Xposed modules:
- GravityBoxJB (Jelly Bean)
- BootManager
- Tinted Status Bar (works better with Google Now Launcher)
*Also im finding method to unlock bootloader for G6 LTE, when i suceed i will update this guide.
DISCLAMER:
I am not responsible for any damage to your phone, do this on your own risk!!!
need urgent helpp
man i broke my phone, Its soft brick right now. can u please me copy if system.img partition... my phone wont work till then:crying:
Please explain what you did to make it softbricked? Did you made build.prop backup?
Sent from my HUAWEI G6-L11 using XDA Free mobile app
wow bro
very good :victory:
Doesn't work
I've tried so many thing to root this phone but nothing works.
Towelroot just stay open for ages when i press make it rain, it stays freezed until i close it.
Still looking for a way to root this phone.
i have rooted my g6, but i have a problem.. when i use root-explorer end it get root access , bhot sdcards (internal and external) disappear.. how can i fix this?
Sent from my HUAWEI G6-L11 using XDA Free mobile app
Install File Explorer from NextApp and File Explorer root addon from Google play, and tell me if works.
Sent from my HUAWEI G6-L11 using XDA Free mobile app
If you having problems with Towelroot try RootGenius, Vroot or Kingo to root it.
Sent from my HUAWEI G6-L11 using XDA Free mobile app
the device is rooted, i can put and edit files in the /system folder and other root access folders, thevonly problem is the access on external cards... it appears unmounted in superuser mode..
if i try virtual terminal:
ls /storage/sdcard0 (or sdcard1) it show the external memory files
if i try :
su
ls /stoage/sdcard0 the folder is empty...
...i have also tryed to mount dev/block/mmcblk0p25 (sdcard0) it result busy
Sent from my HUAWEI G6-L11 using XDA Free mobile app
amonpaike said:
the device is rooted, i can put and edit files in the /system folder and other root access folders, thevonly problem is the access on external cards... it appears unmounted in superuser mode..
if i try virtual terminal:
ls /storage/sdcard0 (or sdcard1) it show the external memory files
if i try :
su
ls /stoage/sdcard0 the folder is empty...
...i have also tryed to mount dev/block/mmcblk0p25 (sdcard0) it result busy
Sent from my HUAWEI G6-L11 using XDA Free mobile app
Click to expand...
Click to collapse
I have tryed that now, I can confirm that when in root mode its "empty"
But tell me what are you trying to do? With File Explorer from NextApp and File Explorer root addon i can acces storage and / partiton with root privileges and see all the content. I will try to find out why is it like that.
whit fx explorer and root addon when i try to access to -> system(root)->storage/sdcard0/ it is empty...
i have rooted the g6-l11 whit towelroot.
this is the device block composition... in case any developer can make clockworkmod or other recovery for the g6-l11
[email protected]:/ # cat /proc/partitions
major minor #blocks name
179 0 7634944 mmcblk0
179 1 512 mmcblk0p1
179 2 32 mmcblk0p2
179 3 32 mmcblk0p3
179 4 500 mmcblk0p4
179 5 500 mmcblk0p5
179 6 5592 mmcblk0p6
179 7 1024 mmcblk0p7
179 8 65536 mmcblk0p8
179 9 4096 mmcblk0p9
179 10 4096 mmcblk0p10
179 11 98304 mmcblk0p11
179 12 4096 mmcblk0p12
179 13 1 mmcblk0p13
179 14 8 mmcblk0p14
179 15 32768 mmcblk0p15
179 16 65536 mmcblk0p16
179 17 8192 mmcblk0p17
179 18 12288 mmcblk0p18
179 19 16384 mmcblk0p19
179 20 262144 mmcblk0p20
179 21 196608 mmcblk0p21
179 22 4096 mmcblk0p22
179 23 1048576 mmcblk0p23
179 24 2097152 mmcblk0p24
179 25 3694575 mmcblk0p25
179 32 512 mmcblk0rpmb
(this is my 32gb external sdcard..)
179 64 30703616 mmcblk1
179 65 25626483 mmcblk1p1
179 66 4882874 mmcblk1p2
179 67 193536 mmcblk1p3
---------------------------------------------------------
ls - al /dev/block/platform/msm_sdcc.1/by-name/
lrwxrwxrwx root root 1970-05-06 22:58 DDR -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 1970-05-06 22:58 aboot -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 1970-05-06 22:58 bkbootup -> /dev/block/mmcblk0p16
lrwxrwxrwx root root 1970-05-06 22:58 boot -> /dev/block/mmcblk0p18
lrwxrwxrwx root root 1970-05-06 22:58 cache -> /dev/block/mmcblk0p21
lrwxrwxrwx root root 1970-05-06 22:58 cust -> /dev/block/mmcblk0p20
lrwxrwxrwx root root 1970-05-06 22:58 fsc -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 1970-05-06 22:58 fsg -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 1970-05-06 22:58 grow -> /dev/block/mmcblk0p25
lrwxrwxrwx root root 1970-05-06 22:58 log -> /dev/block/mmcblk0p15
lrwxrwxrwx root root 1970-05-06 22:58 misc -> /dev/block/mmcblk0p22
lrwxrwxrwx root root 1970-05-06 22:58 modem -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 1970-05-06 22:58 modemst1 -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 1970-05-06 22:58 modemst2 -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 1970-05-06 22:58 oeminfo -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 1970-05-06 22:58 pad -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 1970-05-06 22:58 persist -> /dev/block/mmcblk0p17
lrwxrwxrwx root root 1970-05-06 22:58 recovery -> /dev/block/mmcblk0p19
lrwxrwxrwx root root 1970-05-06 22:58 rpm -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 1970-05-06 22:58 sbl1 -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 1970-05-06 22:58 sdi -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 1970-05-06 22:58 ssd -> /dev/block/mmcblk0p14
lrwxrwxrwx root root 1970-05-06 22:58 system -> /dev/block/mmcblk0p23
lrwxrwxrwx root root 1970-05-06 22:58 tz -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 1970-05-06 22:58 userdata -> /dev/block/mmcblk0p24
Sent from my HUAWEI G6-L11 using XDA Free mobile app
Maybe it's SuperSU binary, some users reported problems. If you find out the problem please report it here also
dont think it's a superSu binary problem...
this is
fstab.qcom
file in the root folder, there are no sdcards block mounted....
# Android fstab file.
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
#TODO: Add 'check' as fs_mgr_flags with data partition.
# Currently we dont have e2fsck compiled. So fs check would failed.
#
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1 wait
/dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc wait,check,encryptable=footer,continue
/dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 nosuid,nodev,barrier=1 wait,check,continue
/dev/block/platform/msm_sdcc.1/by-name/persist /persist ext4 nosuid,nodev,barrier=1 wait,check,continue
/dev/block/platform/msm_sdcc.1/by-name/log /log ext4 nosuid,nodev,barrier=1 wait,check,continue
-----------------------------------------------------
the internal and external sdcard are mounted for non root mode by
/etc/internal_sd.fstab
#
/devices/msm_sdcc.2/mmc_host /storage/sdcard1 vfat nosuid,nodev wait,voldmanaged=external_sd:auto
/devices/msm_sdcc.1/mmc_host /storage/sdcard0 vfat nosuid,nodev wait,voldmanaged=internal_sd:25
/devices/platform/msm_hsusb_host /storage/usb vfat nosuid,nodev wait,voldmanaged=usbotg:auto
Sent from my HUAWEI G6-L11 using XDA Free mobile app
---------- Post added at 07:52 PM ---------- Previous post was at 07:22 PM ----------
the my big problem is... for example
i cant bakup system files to sdcard for same tests or cant copy a bootanimation.zip from sdcard to the root /cust folder for a personalized bootanimation etc etc..
Sent from my HUAWEI G6-L11 using XDA Free mobile app
Joseph Katana said:
If you having problems with Towelroot try RootGenius, Vroot or Kingo to root it.
Sent from my HUAWEI G6-L11 using XDA Free mobile app
Click to expand...
Click to collapse
Well, i just tried, Root Genius: stuck at connecting, Vroot detects my phone but fails at the end, Kingo doesn't detect my g6-l11.
Tried with 2 cables and 2 computer ( just in case )
So i guess, i'll just give up and wait for a better way to root it later.
amonpaike said:
i have rooted my g6, but i have a problem.. when i use root-explorer end it get root access , bhot sdcards (internal and external) disappear.. how can i fix this?
Sent from my HUAWEI G6-L11 using XDA Free mobile app
Click to expand...
Click to collapse
that problem is know. you can read how to solve it here: http://forum.xda-developers.com/android/general/huawei-ascend-g6-root-method-t2805938
washichi said:
that problem is know. you can read how to solve it here: http://forum.xda-developers.com/android/general/huawei-ascend-g6-root-method-t2805938
Click to expand...
Click to collapse
ok! i have used rootgenius metod and now sdcards are accessible in root mode.. tankyou!
Sent from my HUAWEI G6-L11 using XDA Free mobile app
Thank you for this info I will update the guide and post a link to this thread.
need urgent helpp
Joseph Katana said:
Please explain what you did to make it softbricked? Did you made build.prop backup?
Sent from my HUAWEI G6-L11 using XDA Free mobile app
Click to expand...
Click to collapse
Yes i have a backup but phone isnt starting and bootloader is locked and i dont know how to unlock it and flash the built.prop back. this is my first huawei phone. I downloaded whole firmware but dont know how to flash it
feetsonfire said:
Yes i have a backup but phone isnt starting and bootloader is locked and i dont know how to unlock it and flash the built.prop back. this is my first huawei phone. I downloaded whole firmware but dont know how to flash it
Click to expand...
Click to collapse
extract the downloaded official firmware to your sd, so you will get: SD:/dload/UPDATE.APP
then reboot your phone, and it will install
trouble with bootloader lock and firmware upgrades
Hi everyone!
I'm fairly new (to the board, too) and this thread has been resting for a while, but still I want to share my experience of rooting the Huawei Ascend P7 mini (or G6-L11) since there are tons of posts and threads out there on how to do it and they all did not work for me.
First of all, thanks for your guide, Joseph Katana! Helped me out partially.
I spent days on searching and trying and finally (just 2 hours ago!) I did it! So here are my Do's and Dont's:
After unpacking and booting for the first time, of course I went straight to updating from P7miniV100R001dontaskmeforgottomakescreenshot to P7miniV100R001C??B370 (also forgot to do a screenshot). First mistake, as the new firmware updates to Android 4.4.2 and I was not able to root my phone with whatever tool there is.
Took me a few hours of researching why I could not flash my phone, since its bootloader was locked to begin with. Turn to [email protected] for requesting an unlock code and make sure to include your phone specs such as Model-no, S/N, IMEI and PID. Alternatively, there are tons of 3rd-party softwares and websites which offer the same service (tho they'll want your PayPal specs, too : ).
So, I was basically all set, my phone was quickly unlocked via Fastboot. After some hours more of devouring tutorials and stuff I also had the appropriate USB-Drivers and HiSuite v2.3.42 installed (tho now I'm not sure, if that was even needed). Still RootGenius v1.8.7 kept complaining what a tough cookie I had, so I told it to shut it and turned to Framaroot, Towelroot, RootGenius v2.20(Chinese version) and basically went through each and every other tool. All failed.
And here's where it's back to Point 1. Just out of frustration I downgraded the firmware B370 back to B127. And surprisingly my phone was game since it rebooted without complaint and I was back to where I started. Of course I ran RootGenius again, but it wouldn't connect so I tried the Chinese versions. I know pretty risky to push buttons without knowing what they're doing, but the program recognized my phone correctly and I was able to root it successfully! Just to be sure, I checked with RootGenius v1.8.7. It connected immediately and also confirmed the root.
And to be absolutely sure I installed Xposed Framedwork, checked "Disable Resource Hooks" ("Ressourcen-APIs deaktivieren" in german) and voila, I was free to pick any module I so desired.
My phone is now running Android 4.3 Emotion UI 2.0 Lite G6-L11V100R001C00B127. Actually I had been expecting SuperSU but now it's Kinguser-Root, but I'm fine with that.
I have not yet tried out much with installing modules and stuff since it's all quite fresh.
Just wanted to let you know that it is doable : )
I have an incident that I have accrued myself so no need for those comments. The history of the hardbrick i created. If any information regarding anything feel free.
First of all i rooted my device using towelroot. It works for alot of devices and runs as 3rd party apk installer. Created by the infamous Geohotz. Godbless. https://towelroot.com/ for those of you who do not know.
2nd i was looking and trying to swap my extSdCard with my internal /sdcard. I edited the vold.fstab and the vold.conf files thinking hey i can use the external as full internal to have the devive install apps on properly w/o manually moving and use the internal remaining sdcard memory as virtual Ram. I have not completed this process yet. Ill explain.
After mounting the internal as external and vice. I ended up being stuck in a boot loop. NOTE: i did not have custom recovery(was one of the oopsies) so was stuck with basic android recovery. Reset device did not fix. Was going to Odin flash the stock rom and/or CWM Recovery, but there is absolutely NO STOCK or LEAKED rom anywhere for the verizon model. I also pulled those 2 files off of my other tab 2 10.1 NON VERIZON *vold.fstab and vold.conf and places it into zip file and signed it using signapk.
which now i feel like an idiot finding this link "http://forum.xda-developers.com/galaxy-nexus/themes-apps/tutorial-making-flashable-zips-edify-t1611615"
NOTE: I used a different post somewhere that didnt explain to have the right binary so it gave me a signature mismatch error when trying to flash. Use above post to make sure you use propery binary.
Luckily i did some research and knowledge of what i actually did to fix it and plus my addiction to play around and learn things. I manually duplicated the vold.fstab/vold.conf files from my one device to the bricked one
Boot up device in Android recovery.
installed and loaded up ADB.exe from command line.
Code:
adb shell
su
echo *yourlinehere*> /system/etc/vold.fstab
echo *yourlinehere*>> /sytem/etc/vold.fstab
the first > rewrites the file from start black document and inputs the first line
the 2nd >> note the double >> appends to the next line.
i rebooted and VOILA FIXED!!! but wait....theres more ><
So knowing the troubles i had to fix my lil play around mistake. I wanted to get custom recovery partition installed. Used Rom Manager to install CWM Recovery. I picked the wrong rom for my device and flashed it. The one i used was for the international Tab 2 10.1 the gt-5100. It said it successfully flashed so i figured wth it couldnt hurt right? WRONG i clicked reboot to recovery to check it. and here is where I lie. HARD BRICK. No boot up at all. Plug in charger to outlet or PC i dont even get the charging device battery image. So now here we go more research fun!!!
I looked up some information on how to fix a hard bricked device. some posts say using a jig to bypass it and get into download mode. Ok this is a 30 pin connector not a 4 pin like most the android devices. I could do some research on this and probably rig a jig to convert and match the pin layouts but meh my problem still lies within not having stock firmware for this model. I also learn of Jtag methods. Oh all well and handy but buying the Riff Box and all this gets your device bootable, but hey guess what? it would allow me to boot into that download mode or android recovery. Which still bottom line fails as i dont have a stock rom to flash. OH the dilemna.
What ive come up with. I plugged in my device into my pc. Well what do you know i can actually get recognition. but this is where i am stuck at.
I figured out that the device is recognized and i needed drivers. I found this handy site
https://developer.qualcomm.com/forum/qdevnet-forums/general-discussion/9428 Which also explains that i messed up my boot partition.
I download and installed the QPST program and installed the drivers on win7. I had to reboot and use advanced options to disable the unsigned drivers check. OK sweet connection is up!
I tried using ADB shell but device isnt connected that way.
In the QPST program it shows my device on com10 in download mode. I tried to retrieve some data or partition information from the device but it says i cannot when device is in download mode. So no pulling files and fixing and reflashing them. Back to the same problem before NO STOCK ROM.
So here are the questions I have regarding my situation. The android device im playing with has the base partitions. As an example of this http://www.all-things-android.com/content/review-android-partition-layout
I do not have my partition layout for my device as its bricked. I dont even know if it needs to be repaired yet. If any of you with a verizon tab 2 10.1 sch-i915 has a rooted device and can get me this table or a pit file for this device it would be appreciated
2nd firmware vs firmware. As previously stated I do not have firmware for this verizon tab. HOWEVER i did find firmware for the Sprint version of this exact tablet. My question is, could these stock firmwares be exact duplicates with the exclusion of the boot up screen bs and the /misc partition containing the imei phone stats and carrier information?
3rd Flashing just certain partitions of this firmware. Is it possible if the above is feasible considering i know my /boot partition is messed up and my /recovery partition is messed up to only flash those 2 partitions with the one from sprint. The stock kernal should be the same in both devices for the /boot and the /recovery partition should hold the same android recovery should it not?
4th. If anyone has a rooted sch-i915 device would you be willing to make dump of the partitions using this guide http://forum.xda-developers.com/showthread.php?t=2450045. That would be appreciated.
Let Me Work On That
You Are Possibly In Luck. I Know Somone That Has That Tablet. Problem Is It Is My Mom's And Well She Rather Beat Me With It Then Let Me Touch It. I'll See What I Can Do And Will Post Back.. Wish Me Luck i Will Need It :fingers-crossed:
][NT3L][G3NC][ said:
You Are Possibly In Luck. I Know Somone That Has That Tablet. Problem Is It Is My Mom's And Well She Rather Beat Me With It Then Let Me Touch It. I'll See What I Can Do And Will Post Back.. Wish Me Luck i Will Need It :fingers-crossed:
Click to expand...
Click to collapse
Appreciated good luck.
If not possible and i get it fixed ill post how i did it and such. and also post up a JB 4.12 stock/updated leaked rom of this device which apparently seems to be missing in the world for some damn reason.
I Got A Question
Sorry I Been Busy, & Google Has Not Been Kind 2 Me. I Did Find The California Lottery Vulnerability Report Generated By Nessus. But If Someone Could Please Point Me In The Right Direction Or Just Break It Down For Me As Quickly And Light As You Could, Short, Straight Forward, The LIghtest Kliff Notes Ever Would Be Appreciated.
Verizion SCH-I915 [ 4.1.2 ]
I Only Had A Few Minutes With The Tablet But I Already Rooted It, Installed BusyBox, I Barely Started To Get Into The FIle System.... I'm Using Kali LInux
1. What Partitions/Blocks Do I Need To Obtain To Create An Odin Flashable Recovery Image
2. Is There A Droid Binary, Or Script I Can Use To Dump The Rom While Creating The Above For Odin?
Just Found Something I Downloaded At Some Point Called: ROMGEN Any Idea On That Binary??? And phantomphr33k Any Request.
Forgive Me I Work Nights, Two Kids, So I'm Up Days + On Call During The Day.
lrwxrwxrwx root root 1970-10-27 01:41 aboot -> /dev/block/mmcblk0p5 ???
lrwxrwxrwx root root 1970-10-27 01:41 backup -> /dev/block/mmcblk0p20
lrwxrwxrwx root root 1970-10-27 01:41 boot -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 1970-10-27 01:41 cache -> /dev/block/mmcblk0p17
lrwxrwxrwx root root 1970-10-27 01:41 efs -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 1970-10-27 01:41 fota -> /dev/block/mmcblk0p19
lrwxrwxrwx root root 1970-10-27 01:41 fsg -> /dev/block/mmcblk0p21
lrwxrwxrwx root root 1970-10-27 01:41 grow -> /dev/block/mmcblk0p23
lrwxrwxrwx root root 1970-10-27 01:41 modem -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 1970-10-27 01:41 modemst1 -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 1970-10-27 01:41 modemst2 -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 1970-10-27 01:41 pad -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 1970-10-27 01:41 param -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 1970-10-27 01:41 persist -> /dev/block/mmcblk0p16
lrwxrwxrwx root root 1970-10-27 01:41 recovery -> /dev/block/mmcblk0p18
lrwxrwxrwx root root 1970-10-27 01:41 rpm -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 1970-10-27 01:41 sbl1 -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 1970-10-27 01:41 sbl2 -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 1970-10-27 01:41 sbl3 -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 1970-10-27 01:41 ssd -> /dev/block/mmcblk0p22
lrwxrwxrwx root root 1970-10-27 01:41 system -> /dev/block/mmcblk0p14
lrwxrwxrwx root root 1970-10-27 01:41 tz -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 1970-10-27 01:41 userdata -> /dev/block/mmcblk0p15
Should Post The Rest Tomorrow
I Have Attached Some Text Files With The Output Of A Couple Commands To Get The block/partition layout.
I Have Dumped The system.img which is 1.6gb In SIze
Tomorrow I Should Have : Modem "firmware" , Boot , Recovery
QUESTIONS:
What Is aboot?
Which Is The Kernel?
What Is Modemst*?
And More Important, Which Ones Do I Need To Pull For A Complete ROM Dump?
lrwxrwxrwx 1 0 0 20 Nov 2 1970 aboot -> /dev/block/mmcblk0p5
lrwxrwxrwx 1 0 0 21 Nov 2 1970 backup -> /dev/block/mmcblk0p20
lrwxrwxrwx 1 0 0 20 Nov 2 1970 boot -> /dev/block/mmcblk0p7
lrwxrwxrwx 1 0 0 21 Nov 2 1970 cache -> /dev/block/mmcblk0p17
lrwxrwxrwx 1 0 0 21 Nov 2 1970 efs -> /dev/block/mmcblk0p11
lrwxrwxrwx 1 0 0 21 Nov 2 1970 fota -> /dev/block/mmcblk0p19
lrwxrwxrwx 1 0 0 21 Nov 2 1970 fsg -> /dev/block/mmcblk0p21
lrwxrwxrwx 1 0 0 21 Nov 2 1970 grow -> /dev/block/mmcblk0p23
lrwxrwxrwx 1 0 0 20 Nov 2 1970 modem -> /dev/block/mmcblk0p1
lrwxrwxrwx 1 0 0 21 Nov 2 1970 modemst1 -> /dev/block/mmcblk0p12
lrwxrwxrwx 1 0 0 21 Nov 2 1970 modemst2 -> /dev/block/mmcblk0p13
lrwxrwxrwx 1 0 0 20 Nov 2 1970 pad -> /dev/block/mmcblk0p9
lrwxrwxrwx 1 0 0 21 Nov 2 1970 param -> /dev/block/mmcblk0p10
lrwxrwxrwx 1 0 0 21 Nov 2 1970 persist -> /dev/block/mmcblk0p16
lrwxrwxrwx 1 0 0 21 Nov 2 1970 recovery -> /dev/block/mmcblk0p18
lrwxrwxrwx 1 0 0 20 Nov 2 1970 rpm -> /dev/block/mmcblk0p6
lrwxrwxrwx 1 0 0 20 Nov 2 1970 sbl1 -> /dev/block/mmcblk0p2
lrwxrwxrwx 1 0 0 20 Nov 2 1970 sbl2 -> /dev/block/mmcblk0p3
lrwxrwxrwx 1 0 0 20 Nov 2 1970 sbl3 -> /dev/block/mmcblk0p4
lrwxrwxrwx 1 0 0 21 Nov 2 1970 ssd -> /dev/block/mmcblk0p22
lrwxrwxrwx 1 0 0 21 Nov 2 1970 system -> /dev/block/mmcblk0p14
lrwxrwxrwx 1 0 0 20 Nov 2 1970 tz -> /dev/block/mmcblk0p8
lrwxrwxrwx 1 0 0 21 Nov 2 1970 userdata -> /dev/block/mmcblk0p15
Sorry its the Holidays so its understandable. Cant really twist your arm to rush it Im by far not an expert on this i do research myself. Ill do my best and if anyone else can shed light please do.
][NT3L][G3NC][ said:
QUESTIONS:
[*]What Is aboot?
[*]Which Is The Kernel?
[*]What Is Modemst*?
[*]And More Important, Which Ones Do I Need To Pull For A Complete ROM Dump?
Click to expand...
Click to collapse
1) Aboot partition is basically your "Odin Downloader" protocol. while booting pressing power + Vol Dwn will put your device in this mode.
2) The kernel/ramdisk is stored in the /boot partition
Note Primary Bootloader and SB* are secondary bootloaders 1,2,3 those are loaded up as well to set certain params + setup/initialize hardware as far as im understanding. and loads up the kernel/ramdisk.
3)Ill quote from another thread: http://forum.xda-developers.com/showthread.php?t=2582811
][NT3L][G3NC][ said:
- backup and restore important device partitions - EFS (Samsung), TA (Sony), MODEM (Exynos devices), MODEMST1 & MODEMST2 (Qualcomm devices),
- root is required
- easy to use
- many localizations
- see paths to important partitions of your device using Menu -> Device Partitions
Click to expand...
Click to collapse
As far as im understanding these partitions hold carrier information/imei and all other sorts of GRPS information in regards to connecting your devices radio to Service. Sorta like your network card drivers and Mac Address
I looked at another persons rom dump and I seen only these partitions in the archive. Sadly I dont remember where i found this but is from a guy who JTAGS devices. So im pretty sure its legit. Its from the Sprints version of this device.
/system.img.ext4(going to be the biggest dump)
/recovery.img
/cache.img.ext4
/boot.img
[QUOTE=']
1. What Partitions/Blocks Do I Need To Obtain To Create An Odin Flashable Recovery Image
2. Is There A Droid Binary, Or Script I Can Use To Dump The Rom While Creating The Above For Odin?
Just Found Something I Downloaded At Some Point Called: ROMGEN Any Idea On That Binary??? And phantomphr33k Any Request.
[/QUOTE]
So basicallly special request if you could is mainly dump those partitions above
This Romgen seemingly looks to dump what is needed for the rom. It also makes and update-script flashable Odin file. Never tried it myself. ive used cygwin/kitchen personally.
If you would do that would be sufficient as a stock rom. Granted if the rom is updated its not stock.....BUT at least it will be an updated stock vwz sch-i915 out there in public finally.
AND...extra special request is a pit file. Reason being is i need to attempt to flash by other means not via odin.(more personal use than general public) and i need the block information to flash partitions to the chip at the certain points. Im extracting the *.img/bin files and compiling *.mbn files and going to attempt to flash directly to the chip. As far as ive seen its worked on a few other devices and i might as well try considering this is a Qualcomm device and it is recognized in QPST. Maybe the security on the bootloader may not allow it but what could it hurt? its already hard bricked right? lol
http://forum.xda-developers.com/showthread.php?t=1916936
program here for windows. I never checked for any linux based tools cuz i use cygwin if i absolutely need linux.
Much appreciated ][NT3L][G3NC][ your making my day :laugh:
happy new years intelligence since it seems ur the only one to view this thread.
so did you ever get a good romdump? I have been trying all night to do it to mine but can not get it to work.
NOTE:
I'm not a developer or something even near to that. I'm a newbie and will be, seems so. All information provided here is copied and compiled from different internet sources like this and many others.
This information is according to best of my knowledge and comprehension and is just for curious souls like me who want to understand things in quite simple words. It might be wrong and I will open-heartedly welcome any correction or addition from anyone.
I'm not responsible for any harm to you or your device resulting from this.
1. PARTITION TABLE
The Phone's Internal Memory (eMMC or UFS; not the SD card) is solid-state (flash) memory, aka NAND. Raw NAND, as it's called, is basically a pure flash memory dependent on CPU to control it. But in order to use flash memory just like a traditional hard drive (block device), NAND is equipped with an (embedded multimedia) micro-controller. It's called eMMC.
eMMC can be partitioned much like a hard drive on PC. PC's have traditionally been partitioned with BIOS compatible Master Boot Record (MBR) scheme in which first sector of disk contains the details of partitions called Partition Table. Limited size of boot sector (512 bytes) puts a limitation of at maximum 4 (primary) partitions listed in MBR. Extended partition has been used for 4+ partitions.
GUID Partition Table (GPT) was introduced with UEFI booting system which isn't dependent on first boot sector and hence may contain up to 128 partitions. GPT also does CRC check, has backup GPT, identifies partitions by GUID and partitions have a label.
Android devices use GPT. We can view and manipulate GPT using Linux tools such as parted and gdisk while fdisk is the traditional tool for MBR partitions.
To view partition table on internal memory:
Code:
~# parted /dev/block/mmcblk0
(parted) p free
~# gdisk -l /dev/block/mmcblk0
(The external SD Card can also be partitioned to include a section dedicated to storing user apps (like Link2SD does) or to create partitions for secondary or tertiary OS on Android device using some multiboot kernel and recovery system). Even we can put whole OS/ROM on an SD card.
2. BRIEF INTRO
Contents of Android partitions can be partially or completely modified by flashing an image (filesystem .img or executable binary or a flashable zip) to them. But we never need to modify most of them and whatever manufacturer wrote on them, resides there unmodified (read-only) for the whole of device life. A user uses only one partition /data to save personal data like photos, music etc. All the other are for device to run. There are typically in the range of 50 partitions on an Android device but only a few partitions are modified for the purpose of adding new features or upgrading the device. A custom ROM or minor upgrade is also limited to modify /boot, /system and /data partitions usually. Most of the partitions are almost intact, containing bootloaders, firmwares, settings etc. Here is a "summarized" detail to these partitions which matter to a common but interested user.
On most devices /system and /data are larger partitions (on some devices /custom or a similar partition too) covering almost 90% of eMMC. All others are smaller ones of a few KB's or MB's.
3. SoC / CHIPSET / PROCESSORS RELATED PARTITIONS
SoC is the first component when we start a PC or Mobile phone which initialzes hardware and processors and loads bootloaders in memory to bootstrap OS. It's an integrated chip containing multiple things e.g. CPU, GPU, modem, wifi etc. It varies for device manufacturers and SoC vendors (chipset plus processor).
Some partitions are specific to SoC, most of them are closed-source executable binary blobs (like aboot, sbl, rpm, tz, cmnlib, devcfg, keymaster, lksecapp and others on a Qualcomm device), loaded step-by-step by bootloaders.
MODEM or RADIO - the phone's radio
Also called baseband, it is responsible for signals and on older devices may control wifi, bluetooth, and GPS (on most newer devices, these are handled by the kernel and ROM). Upgrades are country dependent and may improve or diminish battery performance, network signal strength, and roaming capability. It is also sometimes required to have a minimum Baseband version to use a ROM so that the RIL will play nice with the Baseband.
Modem firmware is a mini-OS for the cellular radio chip which has its own processor. Firmware is a general term, firmware exists for a lot of things on phone. The wireless chip for WiFi, GPS, and Bluetooth often has a firmware as can the GPU core among other things. These firmware files are usually located inside the SYSTEM or VENDOR partition. The modem firmware is special because it has its own separate Baseband Processor (BP) so the firmware is left out of the system image in its own partition.
Modem is not an Android-specific partition. It is tied to the hardware of the phone, but the kernel has a code allowing Android to interact with the hardware. But the baseband processor (BP) - which runs modem and is responsible for all communication through mobile networks e.g. call, SMS and internet - is totally isolated from Application Processor (the one we call CPU) and is not governed by Android kernel; it runs an independent RTOS.
RIL/Radio Interface Layer
This is not a separate partition, but a part of the ROM and is like a driver for the Radio. RIL daemons provides telephony and cellular data i.e. adds phone to smartphone. There is a matching RIL for each Baseband version and you can flash it to match your Baseband after flashing a ROM. Having mismatched RIL and Baseband can range from having no effect at all, slight battery drain, loss of roaming, or even no connection to the cell network. Many ROMs keep their RIL updated to the latest. Job of the RIL is to translate all the telephony requests from the Android telephony framework and map them to the corresponding AT commands to the modem, and back again. AT set of commands is used to communicate with modem i.e. baseband processor (BP) which is a must have processor on Android devices in addition to normal CPU i.e. Application Processor (AP).
TZ (TrustZone) - used by ARM processors as an additional lock to security features. It combines user's encryption key with a hardware specific key generated by encryption processor (like TPM on Windows) to make security breaching more difficult. It can also be used to implement Trusted Execution Environment (TEE).
RPM (Resource/Power Management) which starts executing Primary/Primitive BootLoader (PBL) in BootROM - controls power to radio, modem etc.
DSP (Digital Signal Processor) - by Qualcomm to assist in things like smooth video playback (realtime media and sensors processor) as well as runs RTOS for modem
HYP (Hypervisor) - Virtual Machine Monitor, to enable Virtual Machine platform
4. BOOTLOADERS
Bootloaders - in many steps - hand over charge to kernel after loading in RAM. These are mostly standalone ELF executable files becuase at this stage no filesystem is loaded and only executable code may work. These are all closed source components on Android device, provided by SoC vendors - either built-in or as binary blobs.
SBL - Secondary bootloader loaded by SoC, loads ABOOT in memory, also provides (Emergency) Download Mode (EDL) on many devices, a Firmware Update Protocol.
ABOOT (bootloader.img or aboot.mbn file in Factory Firmware) - Applications Bootloader is the main bootloader responsible for loading kernel or recovey and fastboot - a Firmware Update Protocol - as well.
Kernelflinger is a similar bootloader on Intel devices.
Read ANDROID BOOT PROCESS to know more about bootloaders.
5. CORE AOSP PARTITIONS
BOOT - Kernel and initramfs (modern form of of ramdisk and ramfs/tmpfs)
A kernel is a layer of code that allows the OS and applications to interface with your phone's hardware. The degree to which you can access your phone's hardware features depends on the quality of code in the kernel. Several kernel code improvements give us additional features from our hardware that the stock kernel does not. When you flash a custom ROM, you automatically get a kernel. But you can also flash a standalone kernel on top of the existing one, effectively overwriting it. These days, the difference in custom kernels is less about new features and more about alternate configurations. Choosing a custom kernel is basically choosing one that works best with your ROM.
Device Tree Blob (DTB), along with hardware drivers, are baked with kernel source in boot.img. DTB is loaded by bootloader at boot time and passed to kernel so that it can discover hardware and create node points accordingly.
On a Linux system init along with scripts, binaries kernel drivers and modules (in initrd.img), kernel (vmlinuz executable) and bootloader configuration along with modules, they all reside on root or a separate partition (mounted) at /boot. While on Android, init along with a few binaries and configuration files and kernel reside in a separate partition named "boot" with a special filesystem. Boot.img is created using tools like mkbootimg after building kernel.
This is how kenrel and DTB are built:
vmlinux > Image > zImage / Image.gz > Image.gz-dtb
vmlinux: Large sized non-bootable Linux kernel (executable) with debug symbols, just an intermediate step to producing vmlinuz
vmlinux.bin: Same as vmlinux binary but with removed symbols, produced by 'objcopy'
vmlinuz: Compressed and bootable Linux kernel file; one of zImage or bzImage formats; compressed using zlib, LZMA, gzip or bzip2 etc.
zImage: Smaller format, for old kernels
bzImage: Big zImage
Image: vmlinux.bin of embedded devices
Image.gz: zImage or bzImage of embedded devices
.dts (multiple) < > .dtb (1 or more)
Converted using dtc (device tree compiler)
.dtb is appended to zImage / Image.gz i.e. zImage-dtb / Image.gz-dtb (simply concatenate)
zImage-dtb > dtb Can be extracted using split-appended-dtb
Packed as a part of kernel, "--dt" option is not needed when creating boot.img
mkbootimg --kernel *.Image.gz-dtb --ramdisk *.cpio.gz --base . . . --offset . . . --tag-address . . . --cmdline . . .
.dtb is extracted as a part of kernel by unpackbootimg
.dtb < > dtb.img
Converted using mkdtimg
dtb.img is for dtb partition or second stage of boot.img
boot.img is created by using --dt option:
mkbootimg --dt dt.img --kernel *.Image.gz --ramdisk *.cpio.gz --base . . . --offset . . . --tag-address . . . --cmdline . . .
dtb.img is extracted separately by unpackbootimg
Further Reading: Device Tree Overlays and Android Boot and Recovery Images
SYSTEM - ROM / OS
Contains system applications and libraries that have AOSP source code. During normal operation, this partition is mounted read-only; its contents change only during an OTA update or when flashing a new OS. Most ROM's don't allow root level (Admin rights in Windows) access by default. So, "rooting" is required to modify the contents of this partition. This is the actual User Interface we use on our phone i.e. system apps are installed on this partition on /system/app directory. Another important directory is /system/bin which contains executable binaries to perform each and every action by OS in background (as daemons) or by user in shell (bash) scripts or CLI (command line interface). These are native binaries (developed in C / C++ mostly) as opposed to Android apps which are developed in Java. A minimal form of Linux commands is also included in AOSP as toolbox or toybox (or user can add busybox or individual static binaries). /system/lib directory contains native libraries (shared by applications commonly) with .so extensions just like .dll on Windows.
VENDOR
This partition is replaced with a shortcut (symbolic link in fact) to /system/vendor directory. It contains system applications and libraries that do not have source code available on AOSP but added by vendors (OEM's). During normal operation, this partition is mounted read-only; its contents change only during an OTA update. It also contains SoC firmware images i.e. hardware specific libraries and binaries (OpenGL, ISP...).
Proprietary blobs (HALs) usually live in (/system)/vendor as shared libraries (.so files) which are loaded by Android binders when processes call a hardware component. HAL (hardware abstraction layer) is userspace alternative to traditional Linux's system calls for drivers and is a kind of Google's standardization for OEMs/hardware vendors, though being abandoned by mainstream Linux.
PROJECT TREBLE
In an ideal world, there should be a generic AOSP OS and a single kernel for all Android devices, not tied to hardware and vendors. But unfortunately it isn't so because unlike PC world, there is no standardization in mobile world. AOSP is heavily modified on silicon vendor (SoC) as well as phone vendor level. One of the worst outcome of this situation is almost no Long Term Support (LTS). There are delayed or none updates once the consumers have phone, making it vulnerable to security issues and missing new features. Project Treble (starting from Android-8) addresses this issue somewhat by creating a separation between hardware specific code and generic AOSP code.
Previously, phone vendors used to get AOSP code from Google, mixing it with their own cutomizations (UI, apps etc.) and the hardware specific code from SoC vendor. If a minor fix needed to be applied to AOSP code, the whole process had to be repeated because code was intermingled and fixing one thing broke the other. Google resolved this issue by specifying /vendor partition for hardware specific code, /system containing only generic code. Interaction with AOSP code will be through HIDL interfaces, thus making it possible to upgrade the both codes independently. /oem and /odm partitions were added previously for the same purpose.
USERDATA
User applications are installed in different folders under /data. Apps data (user and system) is stored in /data/data. User personal data and some apps data is stored in /data/media. /data/media is also emulated as internal SDCard at /storage/emulated and symlinked at /sdcard. Personalized and apps settings are also stored in this partition. A folder /data/dalvik contains, in simple words, extracted apps to boost loading process. Java bytecode of Android apps is converted to executable code (.odex) by Dalvik Virtual Machine, separate instance of which is launched by zygote (an Android init daemon) for every app.
This partition is not normally touched by the OTA update process. A Factory Reset wipes this partition, normally excluding /data/media i.e. personal data.
When you do a factory reset (AKA: wipe, hard reset, factory wipe, etc.), you are erasing the /data and /cache partitions. Note that a factory reset does NOT put your phone back to its factory state from an OS standpoint. OS upgrades will stay because the OS lives in /system, and that is not touched during a factory reset. So it's not a factory reset. It's a factory DATA reset actually.
RECOVERY
Holds alternate boot partition and the recovery program that lets the device boot into a recovery console for performing advanced recovery and maintenance operations. It contains a second complete Linux system i.e. independent OS, including a user-interface application, kernel and the special recovery binary that reads a package and uses its contents to update i.e. flash or wipe itself or any other partition particularly during OTA updates.
Recovery is also the most commonly used method to flash custom ROM's.
ADB sideload mode through PC is a replacement of flashing files (usually .zip) through Recovery. ADB works when phone is switched on in Recovery (or ROM). ADB/fastboot setup is to be made on PC to use this mode.
CACHE - cached (frequently accessed) data from OS usage and contains the firmware update package downloaded from server during OTA updates. Temporary holding area used by a few applications with the expectation that files can disappear at any time. Major use is by recovery and OTA updates. Recovery last_log is also written to this partition.
6. OTHER PARTITIONS
CUST - also CUSTOM or PRELOAD on some devices, it's used by stock ROM's, holding some preloaded system apps and regional settings which are installed on first use.
MISC - also FOTA on older devices
It's a tiny partition used by recovery to communicate with bootloader store away some information about what it's doing in case the device is restarted while the OTA package is being applied.
It is a boot mode selector used to pass data among various stages of the boot chain (boot into recovery mode, fastboot etc.). e.g. if it is empty (all zero), system boots normally. If it contains recovery mode selector, system boots into recovery mode.
It may also carry some necessarily required information in the form of switches to control hardware or settings related tasks such as CID (Carrier or Region ID) information and USB configurations etc.
PERSIST - contains data which shouldn't be changed after the device is shipped, e.g. DRM related files, sensor reg file (sns.reg) and calibration data of chips; wifi, bluetooth, camera etc.
Some package installers such as OpenGapps also make use of this partition to read configuration file.
EFS, MODEMST1, MODEMST2, FSG, BACKUP
These all are related to IMEI; a unique number used by GSM networks to identify and trace a mobile phone.
EFS may contain hardware info like configuration files, WiFi/BlueTooth MAC’s, IMEI (or ESN for a CDMA based device) etc.
EFS and MODEMST1 may be a single partition on some phones.
FSG (FileSystem Golden copy) and BACKUP are backups of MODEMST1 and MODEMST2 respectively. If MODEMST1 or MODEMST2 are erased (by wrong factory flashing say) and phone notices an invalid partition, FSG and BACKUP will be restored.
MODEMST1 and MODEMST2 also contains modem firmware files.
PARAM - stores a number of parameters, variables and settings of the hardware. It contains info whether MODEMST partitions are backed up or not. Also debug settings, custom ROMs flash count, current stage boot process etc.
OEM - like VENDOR, it incorporates OEM (Original Equipment Manufacturer i.e. hardware manufacturer or Mobile Phone brand) small customization (modifications) to original Android (AOSP) during OTA updates such as customized system properties values etc.
PAD - related to OEM
OTA, FOTA - OTA updates
DDR - Double Data Rate RAM
FSC - Modem FileSystem Cookies
SSD - Secure Software Download, a memory based file system for secure storage, stores some encrypted RSA keys
DEVINFO - device information including: is_unlocked (aboot), is_tampered, is_verified, charger_screen_enabled, display_panel, bootloader_version, radio_version etc. Contents of this partition are displayed by "fastboot oem device-info" command in human readable format. Before loading boot.img or recovery.img, bootloader verifies the locked state from this partition.
CONFIG/FRP/PDB - saves state of Factory Reset Protection (FRP), "Allow bootloader (OEM) unlocking" . (Developer Options), asks already associated account info. This partition is erased/reset if Factory Reset done from Settings.
DEVCFG - used by TZ for upgrades
LKSECAPP - "LK (Little Kernel) Security App", related to RPM, TZ online verification / update
LIMITS - Qualcomm Limits Management Hardware (LMh) driver in SBL writes the data in this partition to use for later reboots
SYSCFG - Qualcomm CPR (Core Power Reduction) Regulator for better performance and power saving of application processor by voltage control
DIP, MDTP - boot verification, use Qualcomm SafeSwitch technology to lock and track theft phones
CMNLIB, KEYMASTER - verified boot
SEC - contains fuse settings, mainly for secure boot (signing bootloaders for chain of trust) and oem setting
KEYSTORE - related to /data Full Disc Encryption (FDE)
MCFG - (Modem Configuration Framework) - on dual SIM devices, loads MBN (modem binary) files depending on SIM/carrier
SPLASH - splash image or boot logo which appears when device boots (at ABOOT stage).
CHGLOGO - charging screen that appears when charger is connected to powered off device.
MSADP, APDP, DPO - related to debug policies
GROW - empty for future expansion
7. FILESYSTEMS
Supported filesystems by your kernel can be viwewd by:
Code:
~# cat /proc/filesystems
Partitions with Mountable Filesystems
Following partitions are mounted during boot process:
system, vendor, odm, userdata (mounted at /data), cache, cust, persist (mounted at /persist or /mnt/vendor/persist), modem (mounted at /firmware or /vendor/firmware_mnt), dsp (mounted at /dsp or /vendor/dsp)
Modem is formatted as vfat while all others are usually ext4 or f2fs on newer devices.
All of these are listed in /fstab.* file which is processes by init. Starting with Android 8.0 (Treble release), fstab.* is moved to /vendor/etc/ and system, vendor and odm entries are included in dtb.
Other partitions don't contain a mountable filesystem. However, we may try to get an idea of the contents by reading smaller partitions e.g.:
Code:
~# cat /dev/block/bootdevice/by-name/config | strings
~# cat /dev/block/bootdevice/by-name/misc | strings
Pseudo / Virtual / in-Memory Filesystems (Kernel space)
These filesystems don't rely on a physical persistent storage but just live in RAM, to provide kernel services interfaces in user space.
rootfs (/) - mounted by kernel before calling init. More details here
sysfs (/sys) - information related to devices, populated by kernel
devpts (/dev/pts) - character device files representing slave side of pseudo terminal pairs
proc (/proc) - information related to all processes, updated as processes are started / killed
tmpfs (/dev) - all device nodes updated from sysfs, accessible from user space
configfs (/config) - intergrated with userspace sdcardfs, controls apps permissions to directories on internal/external sdcard by VOLume Daeomon, a replacement of fusefs
pstore (/sys/fs/pstore) - persistent storage, a replacement of /proc/last_kmsg, saves last kernel console messages on panic / crashes / sudden reboots, solution to volatile nature of pseudo filesystems
cgroup - cgroups manage hardware resources allocation to processes as per load
selinuxfs (/sys/fs/selinux) - implementation of Security-Enahanced Linux, a mandatory access controls (MAC) to manage file permissions, better than traditional Discretionary Access Control (DAC) mechanism (Read-Write-eXecute) of Linux
debugfs (/sys/kernel/debug) - to monitor and debug kernel space implementations from user space
tracefs (/sys/kernel/debug/tracing) - debugfs with better security
functionfs (/dev/usb-ffs/adb) - integrated with configfs, manages USB gadgets, ADB is implemented through functionfs on Android
FILESYSTEM TREE MOUNTED BY INIT: ANDROID vs. LINUX
8. Factory Firmware and Flashable ROMs:
When you flash a custom ROM, that ROM typically includes a kernel and an OS. That means the /boot and /system partitions will be modified at a minimum. Some ROMs require a clean install, so a format of the /data and /cache partitions is sometimes built into the .zip that you flash. This is essentially doing a Factory Reset.
Read here to know more about flashing partitions.
Factory Firmware contains original iamge files of almsot all important partitions. It's provided by OEM's, usually as a package which also incude a flasher software for PC. Or a general flasher software may be uses such as QFIL.
ROM Development
A ROM developer downloads AOSP source code from Google while device tree, driver binaries and kernel source code is provided by (ODM's through) OEM's, if they are generous enough. OEM's manufacture and sell devices themselves while ODM's sell to white-labelers who brand them under their own names. Original Android kernel tree is provided by Google which in turn is taken from Linux and then modified by Google for Android-specific needs.
RELATED:
An Introduction to Android Firmware
First off, don't need be like your never be a dev, lol you never know. Secondly it's a good share. Appreciated
Drivers Partition
What are partitions responsible on drivers like sound and camera,
I restored ROM using TWRP but now, Sound and Camera don't work,
any help?
saprey said:
What are partitions responsible on drivers like sound and camera,
I restored ROM using TWRP but now, Sound and Camera don't work,
any help?
Click to expand...
Click to collapse
Camera and sound are related to your rom i.e. system partition. Do factory data reset or clean install rom
Thanks, but why is my phone talking about a primary partition and a secondary partition?
Tia,
A real newbie
TommyWhite said:
Thanks, but why is my phone talking about a primary partition and a secondary partition?
Tia,
A real newbie
Click to expand...
Click to collapse
At what point talking about primary / secondary partitions? Are you creating new partitions or using some tool / app to view partitions?
Oh, I misunderstood.
It was about public storages (so whats accessible without root, right??).
It said
Public storage (primaire): /storage/emulated/0
Public storage (secondaire): /storage/94F1-34D8 (I didnt realise that was my sd card ...)
RootFs: /
System: /system
Like a said 'a real newbie'
TommyWhite said:
Oh, I misunderstood.
It was about public storages (so whats accessible without root, right??).
It said
Public storage (primaire): /storage/emulated/0
Public storage (secondaire): /storage/94F1-34D8 (I didnt realise that was my sd card ...)
RootFs: /
System: /system
Like a said 'a real newbie'
Click to expand...
Click to collapse
Something like this attachment?
mirfatif said:
Something like this attachment?
Click to expand...
Click to collapse
yes, sorry for the very late response.
While on some devices there is no bootloader partition at all and bootloader(s) resides on SoC.
Click to expand...
Click to collapse
Great post btw! With the bootloader section mentioning like the above, I have a question: I'm having a device with Snapdragon 810 SoC and wasn't able to find the bootloader partition (or at least I didn't know it has because I couldn't get it to boot into that mode). So does that mean the bootloader is on the SoC? How do I figure it out if it exists on the chip?
Hi @mirfatif , what a post! Hats off to you. By the way, where does the blobs/ HALs go when we flash a new ROM zip?
argon9898 said:
Great post btw! With the bootloader section mentioning like the above, I have a question: I'm having a device with Snapdragon 810 SoC and wasn't able to find the bootloader partition (or at least I didn't know it has because I couldn't get it to boot into that mode). So does that mean the bootloader is on the SoC? How do I figure it out if it exists on the chip?
Click to expand...
Click to collapse
Booting in bootloader (or it's equivalent; like fastboot) mode is dependent on the phone manufacturer. Though most of the hardware manufacturers allow users to access bootloader for repair/maintenance or modified boot chain, some may restrict this for Digital Rights Management or to gain forced customer loyalty , irrespective of where bootloader resides. On most phones it's a partition. You may check your partition table to know about all partitions.
azoksky said:
Hi @mirfatif , what a post! Hats off to you. By the way, where does the blobs/ HALs go when we flash a new ROM zip?
Click to expand...
Click to collapse
Thanks for mentioning. I have added this to my post. By "blolbs" you mean DTB or hardware drivers? Well AFAIK, the blobs are included in every ROM where "ROM" is boot.img and system.img at least.
A ROM developer downloads AOSP source code from Google while device tree (map of hardware components), driver binaries and kernel source code is provided by (ODM's through) OEM's, if they are generous enough. OEM's manufacture and sell devices themselves while ODM's sell to white-labelers who brand them under their own names. Original Android kernel tree is provided by Google which in turn is taken from Linux and then modified by Google for Android-specific needs. DTB and drivers are baked with kernel source in boot.img though DTB may live on a separate dtb partition as specified by AOSP (and was the proposed solution for ARM based embedded Linux devices before Android's birth) but I don't think that is widely practiced. DTB is loaded by bootloader at boot time and passed to kernel so that it can discover hardware and create node points accordingly. Proprietary blobs (HALs) usually live in (/system)/vendor as shared libraries (.so files) which are loaded by Android binders when processes call a hardware component. HAL is userspace alternative to traditional Linux's system calls for drivers and is a kind of Google's standardization for OEMs/hardware vendors.
Click to expand...
Click to collapse
Hello everyone. I tell you that one day flashing my oneplus 5 lost the wifi. The MAC address shows me the typical 02: 00: 00: 00: 00: 00 address. The way to fix it is updating the Oreo but I could never do it, it is always in bootloop, I read all the forums and there is no case, do what I always do the same. It happens in many oneplus 5. So I forgot to fix it in that way. The other thing I saw is hundreds of forums with that problem but I could not fix it either, I've been doing it for three months now. What I am trying now is to erase all the partitions except recovery or bootloader but the phone does not start anymore. What I want is to delete all the partitions associated with wifi, delete modem1, modem2, persist, fsg but nothing, I just managed to lose the imei that does not matter to me because I have back up of the efs folder and even the qcn file of the phone. I know it's a lot of work but if someone tells me that they control each partition, I could erase it, load everything from scratch and that's it. Would someone give me a hand so I can fix that damn wifi on the phone ?. Thank you.
--------------------------------------------------------------------------------------------------------------------------------------
drwxr-xr-x 2 root root 1440 1970-05-03 14:23 .
drwxr-xr-x 4 root root 1600 1970-05-03 14:23 ..
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 LOGO -> /dev/block/sde18
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 abl -> /dev/block/sde16
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 ablbak -> /dev/block/sde17
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 apdp -> /dev/block/sde31
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 bluetooth -> /dev/block/sde24
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 boot -> /dev/block/sde19
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 boot_aging -> /dev/block/sde20
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 cache -> /dev/block/sda3
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 cdt -> /dev/block/sdd2
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 cmnlib -> /dev/block/sde27
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 cmnlib64 -> /dev/block/sde29
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 cmnlib64bak -> /dev/block/sde30
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 cmnlibbak -> /dev/block/sde28
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 config -> /dev/block/sda12
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 ddr -> /dev/block/sdd3
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 devcfg -> /dev/block/sde39
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 devinfo -> /dev/block/sde23
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 dip -> /dev/block/sde14
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 dpo -> /dev/block/sde33
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 dsp -> /dev/block/sde11
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 frp -> /dev/block/sda6
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 fsc -> /dev/block/sdf4
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 fsg -> /dev/block/sdf3
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 fw_4g9n4 -> /dev/block/sde45
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 fw_4j1ed -> /dev/block/sde43
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 fw_4t0n8 -> /dev/block/sde46
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 fw_8v1ee -> /dev/block/sde44
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 hyp -> /dev/block/sde5
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 hypbak -> /dev/block/sde6
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 keymaster -> /dev/block/sde25
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 keymasterbak -> /dev/block/sde26
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 keystore -> /dev/block/sda5
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 limits -> /dev/block/sde35
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 logdump -> /dev/block/sde40
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 logfs -> /dev/block/sde37
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 md5 -> /dev/block/sdf5
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 mdtp -> /dev/block/sde15
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 mdtpsecapp -> /dev/block/sde12
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 mdtpsecappbak -> /dev/block/sde13
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 minidump -> /dev/block/sde47
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 misc -> /dev/block/sda4
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 modem -> /dev/block/sde10
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 modemst1 -> /dev/block/sdf1
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 modemst2 -> /dev/block/sdf2
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 msadp -> /dev/block/sde32
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 oem_dycnvbk -> /dev/block/sda7
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 oem_stanvbk -> /dev/block/sda8
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 param -> /dev/block/sda9
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 persist -> /dev/block/sda2
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 pmic -> /dev/block/sde8
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 pmicbak -> /dev/block/sde9
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 recovery -> /dev/block/sde22
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 reserve -> /dev/block/sdd1
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 reserve1 -> /dev/block/sda10
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 reserve2 -> /dev/block/sda11
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 rpm -> /dev/block/sde1
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 rpmbak -> /dev/block/sde2
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 sec -> /dev/block/sde7
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 splash -> /dev/block/sde34
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 ssd -> /dev/block/sda1
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 sti -> /dev/block/sde38
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 storsec -> /dev/block/sde41
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 storsecbak -> /dev/block/sde42
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 system -> /dev/block/sde21
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 toolsfv -> /dev/block/sde36
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 tz -> /dev/block/sde3
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 tzbak -> /dev/block/sde4
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 userdata -> /dev/block/sda13
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 xbl -> /dev/block/sdb1
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 xblbak -> /dev/block/sdc1
thank you
This is one of the best posts that I've ever read. I'm a hobbyist and reverse engineer learn. My primary phones are Samsung S 6 7 and 8 and I've soft bricked phones them more times than I can count (but recovered) justifying it as a learning experience. Sort of like putting your hand in the fire several times and calling it a learning experience. your post opens up more questions which are great. I root all my phones and I have a fear of new security patches disguised as updates disabling what methods work last week so to speak
So if I understand finally there is a section in bootloaders which is the first bootloader that is static yet upgradable but not downgradable as you referred to like the BIOS on PCs which acts as a verification process so you can't flash downgradable security patches. Much like I've encountered with partcyborg great work on rooting the S8 snapdragon however once you upgraded to the bootloader 2 you couldn't go back to the bootloader one. This is in reference to the build, not the partition.
If someone does reply, I'd like to know can you mod a certain file and Odin in the bootloader section when flashing an update to ensure that you stay at a certain bootloader level while the other files such as AP CP and CSC remain intact from the sam mobile stock firmware.(which I assume the term combo firmware file originates)
My most recent encounters are the device and binary are not the same which I attribute to this problem.
In theory from what I understand the phone has a section that is not Factory resettable which is the NAND that contains read-only but system upgrade information? However, it can be modified by a power Superuser rooted? This obviously risking hard bricking a phone
When upgrading firmware specifically the bootloader file in Odin what file(s) {bin} are essential to the new modification patches and can those files be substituted?
Any comment is considered very helpful. Odin itself is coming out with different versions for structures (prince cosmey) for example.
I explore the system file structure often wondering what I could change or alter as simple as a 0 or 1 or a true or a false to enable or disable my ability to access what I feel I need to access.
I could buy the z3x Samprotools but it defeats my intentions to learn the details.
If you do have a suggestion on a GUI Windows-based tool it would be great. Don't know Linux just as a footnote
Once again what a great post and definition of the different sections of terminology it's just enough to educate me and confuse me at the same time keep doing what you're doing. Any tricks or tips will be very appreciated.
partitions
What are partitions responsible on drivers like sound and camera,
Curious Q.!
what about these two ?
Code:
rpm -> /dev/block/mmcblk0p2
rpmbak -> /dev/block/mmcblk0p11
my phone is MOTO-G5-PLUS (potter)
whole partition table is here:
Code:
←7←[r←[999;999H←[6n←8potter:/ # ls -l /dev/block/bootdevice/by-name
total 0
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 DDR -> /dev/block/mmcblk0p23
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 aboot -> /dev/block/mmcblk0p5
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 abootbak -> /dev/block/mmcblk0p14
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 apdp -> /dev/block/mmcblk0p45
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 boot -> /dev/block/mmcblk0p37
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 cache -> /dev/block/mmcblk0p52
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 carrier -> /dev/block/mmcblk0p34
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 cid -> /dev/block/mmcblk0p32
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 cmnlib -> /dev/block/mmcblk0p6
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 cmnlib64 -> /dev/block/mmcblk0p7
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 cmnlib64bak -> /dev/block/mmcblk0p16
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 cmnlibbak -> /dev/block/mmcblk0p15
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 devcfg -> /dev/block/mmcblk0p4
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 devcfgbak -> /dev/block/mmcblk0p13
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 dip -> /dev/block/mmcblk0p42
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 dpo -> /dev/block/mmcblk0p47
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 dsp -> /dev/block/mmcblk0p22
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 frp -> /dev/block/mmcblk0p31
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 fsc -> /dev/block/mmcblk0p20
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 fsg -> /dev/block/mmcblk0p29
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 hw -> /dev/block/mmcblk0p50
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 keymaster -> /dev/block/mmcblk0p8
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 keymasterbak -> /dev/block/mmcblk0p17
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 kpan -> /dev/block/mmcblk0p36
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 limits -> /dev/block/mmcblk0p40
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 logo -> /dev/block/mmcblk0p33
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 logs -> /dev/block/mmcblk0p44
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 metadata -> /dev/block/mmcblk0p35
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 misc -> /dev/block/mmcblk0p39
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 modem -> /dev/block/mmcblk0p19
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 modemst1 -> /dev/block/mmcblk0p27
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 modemst2 -> /dev/block/mmcblk0p28
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 mota -> /dev/block/mmcblk0p41
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 msadp -> /dev/block/mmcblk0p46
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 oem -> /dev/block/mmcblk0p51
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 padA -> /dev/block/mmcblk0p48
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 persist -> /dev/block/mmcblk0p30
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 prov -> /dev/block/mmcblk0p9
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 provbak -> /dev/block/mmcblk0p18
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 recovery -> /dev/block/mmcblk0p38
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 rpm -> /dev/block/mmcblk0p2
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 rpmbak -> /dev/block/mmcblk0p11
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 sbl1 -> /dev/block/mmcblk0p1
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 sbl1bak -> /dev/block/mmcblk0p10
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 sec -> /dev/block/mmcblk0p24
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 sp -> /dev/block/mmcblk0p49
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 ssd -> /dev/block/mmcblk0p21
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 syscfg -> /dev/block/mmcblk0p43
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 system -> /dev/block/mmcblk0p53
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 tz -> /dev/block/mmcblk0p3
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 tzbak -> /dev/block/mmcblk0p12
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 userdata -> /dev/block/mmcblk0p54
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 utags -> /dev/block/mmcblk0p25
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 utagsBackup -> /dev/block/mmcblk0p26
potter:/ #
GEEKOFIA said:
what about these two ?
Code:
rpm -> /dev/block/mmcblk0p2
rpmbak -> /dev/block/mmcblk0p11
my phone is MOTO-G5-PLUS (potter)
Click to expand...
Click to collapse
RPM (Resource/Power Management) or Primary BootLoader (PBL); controls power to radio, modem etc.
koler386 said:
What are partitions responsible on drivers like sound and camera,
Click to expand...
Click to collapse
Kernel and system
mirfatif said:
what about these two ?
RPM (Resource/Power Management) or Primary BootLoader (PBL); controls power to radio, modem etc.
Click to expand...
Click to collapse
I got a script from a xda thread in which OP mentioned that this script is for wiping dalvik/ART cache.
Before flashing it i decided to analyse it,what i found that it was erasing my RPM partition on mmcblk0p2.
Is it really for dalvik cache ?
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
TWRP 3.1.x - Based upon Android 7.1 :
* Whole new TWRP 3 interface
* Flashable to FOTA for permanent recovery
* Bootable recovery image if required
OFFICIAL DOWNLOADS FOR TAOSHAN :
https://twrp.me/sony/sonyxperial.html
twrp-3.x.x-x-taoshan.img : Official TWRP image
How to install : All informations available on TWRP.me
You can download the recovery via Official TWRP App as well :
https://play.google.com/store/apps/details?id=me.twrp.twrpapp&hl=en
DEVELOPMENT DOWNLOADS FOR TAOSHAN :
https://mega.nz/#F!vYwXRRRa!PQgFIpUqjEjJoHVkwTWe0w
twrp-3.x.x-x-fota-taoshan.zip : Flashable TWRP 3 to FOTA installer [Flash this zip if you already have older TWRP installed]
twrp-3.x.x-x-boot-taoshan.img : Fastboot bootable TWRP 3 image
twrp-3.x.x-x-secondary-multirom-taoshan.zip : As secondary MultiROM (optional)
cleaner-fota-taoshan.zip : Flashable FOTA formatter (optional)
HOW TO INSTALL EASILY TO FOTA :
* Boot to recovery : Enter the existing recovery as usual
* Flash to FOTA : Install the TWRP FOTA zip to upgrade to latest TWRP
* (Optional) : Flash the ROM you want
HOW TO INSTALL MANUALLY TO FOTA :
* Bootimage : Download the TWRP bootimage you want to flash
* File storage : Adapt the path and push the file to the device this way :
Code:
adb root
adb wait-for-device
adb push FullPathToTheRecovery.img /tmp/twrp.img
* Flash : Extract the TWRP image to the FOTA partition
Code:
adb shell dd if=/tmp/twrp.img of=/dev/block/platform/msm_sdcc.1/by-name/FOTAKernel
* Reboot to recovery : adb reboot recovery
INFORMATIONS ABOUT TWRP 3 :
* Installation : Simply flash the zip with a working TWRP or CyanogenRecovery
* Known issues : No major issue remaining, but sources open to improvements
* Usage : Built for Nougat, works for Marshmallow, Lollipop based ROMs too
* More here : http://www.xda-developers.com/twrp-3-0-0-has-arrived/
ADDITIONAL LINKS :
* Easy ADB and Fastboot for unexperienced users :
http://forum.xda-developers.com/showthread.php?p=48915118
Thanks to @AdrianDC for big help in bring-up and thread template
Thanks to the TWRP Team for sources
Current local manifest of the TWRP build
Code:
<?xml version="1.0" encoding="UTF-8"?>
<!-- https://github.com/STRYDER-007/twrp_development_sony -->
XDA:DevDB Information
[Recovery][OFFICIAL][UBL] TWRP 3.1.1 Touch Recovery for Xperia L, Tool/Utility for the Sony Xperia L
Contributors
STRYDER~007
Version Information
Status: Stable
Created 2017-10-02
Last Updated 2017-10-05
Nice work, but where can I download the zip file. Ready for testing. But I mis the link.
Btw nice work.
I was to early. They are here now
paul.coster said:
Nice work, but where can I download the zip file. Ready for testing. But I mis the link.
Btw nice work.
I was to early. They are here now
Click to expand...
Click to collapse
The link is up! Enjoy!
Is it just me, or does this recovery not work? Holding volUp to enter the recovery just turns the screen black; the screen flashes between the sony logo and the said black screen after that, and I have to remove the battery to get the phone working again.
I used both your method of installation, as well as mine, and none of them worked. The older official TWRP recovery (3.0.2-0) works just fine, though.
stuckbootloader said:
Is it just me, or does this recovery not work? Holding volUp to enter the recovery just turns the screen black; the screen flashes between the sony logo and the said black screen after that, and I have to remove the battery to get the phone working again.
I used both your method of installation, as well as mine, and none of them worked. The older official TWRP recovery (3.0.2-0) works just fine, though.
Click to expand...
Click to collapse
Can you mention the steps you performed as well as the scenario in which you're trying to flash it?
Btw you can simply flash twrp-3.x.x-x-fota-taoshan.zip from existing recovery to upgrade TWRP.
STRYDER~007 said:
Can you mention the steps you performed as well as the scenario in which you're trying to flash it?
Btw you can simply flash twrp-3.x.x-x-fota-taoshan.zip from existing recovery to upgrade TWRP.
Click to expand...
Click to collapse
Sorry for the late reply.
I transferred the twrp.img file to the root of the SD card, and ran this command through adb shell
dd if=/storage/36BD-1A02/twrp.img of=/dev/block/platform/msm_sdcc.1/by-name/FOTAKernel.
That worked with the older releases.
I also tried the commands in the description (pushing twrp.img /tmp/ and then moving it to FOTAKernel), and there was no difference.
Weirdly enough, flashing the .zip worked.
stuckbootloader said:
Sorry for the late reply.
I transferred the twrp.img file to the root of the SD card, and ran this command through adb shell
dd if=/storage/36BD-1A02/twrp.img of=/dev/block/platform/msm_sdcc.1/by-name/FOTAKernel.
That worked with the older releases.
I also tried the commands in the description (pushing twrp.img /tmp/ and then moving it to FOTAKernel), and there was no difference.
Weirdly enough, flashing the .zip worked.
Click to expand...
Click to collapse
Well there you go! IMO flashing zip to upgrade TWRP is the simplest so I'd always prefer that. Enjoy the new recovery! :highfive:
STRYDER~007 said:
Can you mention the steps you performed as well as the scenario in which you're trying to flash it?
Btw you can simply flash twrp-3.x.x-x-fota-taoshan.zip from existing recovery to upgrade TWRP.
Click to expand...
Click to collapse
Hi,
I have the same issue, on a Xperia L (white, C2105), tried with two possibilities now, using recovery image twrp.3.1.1-0-taoshan.img, two methods:
1) flashing via existing TWRP recovery (v 2.8.7.0): according to your description I selected install, image, with the aforementioned TWRP recovery image.
2) using the recovery installer app from corphish/StdBarbarossa (version 1.4 - dated 18 May 2016): selecting the menu option to install a custom recovery, to install the aforementioned TWRP recovery image.
Please note that the same recovery installer app from corphish/StdBarbarossa works perfectly to install the TWRP 2.8.7.0.
Therefore I would suggest that the latest TWRP image might need to be reviewed for side-effects by implemented changes. I will try with older versions, to identify if it works with older versions.
Please let me know in case you need any further details, either of the device or of the steps that I performed.
Cheers, Henning
---------- Post added at 10:39 PM ---------- Previous post was at 10:30 PM ----------
xleng said:
Hi,
I have the same issue, on a Xperia L (white, C2105), tried with two possibilities now, using recovery image twrp.3.1.1-0-taoshan.img, two methods:
1) flashing via existing TWRP recovery (v 2.8.7.0): according to your description I selected install, image, with the aforementioned TWRP recovery image.
2) using the recovery installer app from corphish/StdBarbarossa (version 1.4 - dated 18 May 2016): selecting the menu option to install a custom recovery, to install the aforementioned TWRP recovery image.
Please note that the same recovery installer app from corphish/StdBarbarossa works perfectly to install the TWRP 2.8.7.0.
Therefore I would suggest that the latest TWRP image might need to be reviewed for side-effects by implemented changes. I will try with older versions, to identify if it works with older versions.
Please let me know in case you need any further details, either of the device or of the steps that I performed.
Cheers, Henning
Click to expand...
Click to collapse
OK
Using the method to install TWRP v3 via the existing TWRP recovery version 2.8.7.0 (actually I'm not quite sure about the version, since the splash screen reported version 2.8.7.2, but the main application header reports 2.8.7.0, probably the latter version number was just not updated), finally was SUCCESSFUL with twrp-3.0.2-0-taoshan.img!
I didn't try the earlier ones, since I identified a TWRP version which should be functional.
I think probably something went wrong with the most recent update!?
Please let me know in case I could support troubleshooting somehow.
I have actually two Xperia L's, one as my primary smartphone, the second as spare, which I typically use to try out new things prior to messing around with the primary one.
Cheers
---------- Post added at 10:50 PM ---------- Previous post was at 10:39 PM ----------
STRYDER~007 said:
Well there you go! IMO flashing zip to upgrade TWRP is the simplest so I'd always prefer that. Enjoy the new recovery! :highfive:
Click to expand...
Click to collapse
Just noted that I should have read the thread more carefully first .... *doh*
Actually, where can I get the zip file? I only could download the img from the TWRP website.
Eventually I would also be interested to take a look to the sources, if possible (just out of curiosity).
Thanks in advance!
---------- Post added at 11:15 PM ---------- Previous post was at 10:50 PM ----------
xleng said:
Hi,
I have the same issue, on a Xperia L (white, C2105), tried with two possibilities now, using recovery image twrp.3.1.1-0-taoshan.img, two methods:
1) flashing via existing TWRP recovery (v 2.8.7.0): according to your description I selected install, image, with the aforementioned TWRP recovery image.
2) using the recovery installer app from corphish/StdBarbarossa (version 1.4 - dated 18 May 2016): selecting the menu option to install a custom recovery, to install the aforementioned TWRP recovery image.
Please note that the same recovery installer app from corphish/StdBarbarossa works perfectly to install the TWRP 2.8.7.0.
Therefore I would suggest that the latest TWRP image might need to be reviewed for side-effects by implemented changes. I will try with older versions, to identify if it works with older versions.
Please let me know in case you need any further details, either of the device or of the steps that I performed.
Cheers, Henning
---------- Post added at 10:39 PM ---------- Previous post was at 10:30 PM ----------
OK
Using the method to install TWRP v3 via the existing TWRP recovery version 2.8.7.0 (actually I'm not quite sure about the version, since the splash screen reported version 2.8.7.2, but the main application header reports 2.8.7.0, probably the latter version number was just not updated), finally was SUCCESSFUL with twrp-3.0.2-0-taoshan.img!
I didn't try the earlier ones, since I identified a TWRP version which should be functional.
I think probably something went wrong with the most recent update!?
Please let me know in case I could support troubleshooting somehow.
I have actually two Xperia L's, one as my primary smartphone, the second as spare, which I typically use to try out new things prior to messing around with the primary one.
Cheers
---------- Post added at 10:50 PM ---------- Previous post was at 10:39 PM ----------
Just noted that I should have read the thread more carefully first .... *doh*
Actually, where can I get the zip file? I only could download the img from the TWRP website.
Eventually I would also be interested to take a look to the sources, if possible (just out of curiosity).
Thanks in advance!
Click to expand...
Click to collapse
I found the zip file now. But actually it didn't work either.
I extracted the twrp.img from the twrp-3.1.1-20171005-fota-taoshan.zip.
Then I applied the following commands :
adb root
adb push twrp.img /tmp/twrp.img
adb shell dd if=/tmp/twrp.img of=/dev/block/platform/msm_sdcc.1/by-name/FOTAKernel
The result is a boot loop, looping between the SONY logo and a black screen.
Afterwards I successfully installed back TWRP-3.0.2-0 using the recovery installer app from corphish.
Cheers
xleng said:
The result is a boot loop, looping between the SONY logo and a black screen.
Afterwards I successfully installed back TWRP-3.0.2-0 using the recovery installer app from corphish.
Cheers
Click to expand...
Click to collapse
Flash that .zip through the 3.0.2-0 recovery now, it ought to work. I had the same flashing issue. Both the app and the .zip should work now, so it doesn't really matter which method you use.
xleng said:
Hi,
I have the same issue, on a Xperia L (white, C2105), tried with two possibilities now, using recovery image twrp.3.1.1-0-taoshan.img, two methods:
1) flashing via existing TWRP recovery (v 2.8.7.0): according to your description I selected install, image, with the aforementioned TWRP recovery image.
2) using the recovery installer app from corphish/StdBarbarossa (version 1.4 - dated 18 May 2016): selecting the menu option to install a custom recovery, to install the aforementioned TWRP recovery image.
Please note that the same recovery installer app from corphish/StdBarbarossa works perfectly to install the TWRP 2.8.7.0.
Therefore I would suggest that the latest TWRP image might need to be reviewed for side-effects by implemented changes. I will try with older versions, to identify if it works with older versions.
Please let me know in case you need any further details, either of the device or of the steps that I performed.
Cheers, Henning
---------- Post added at 10:39 PM ---------- Previous post was at 10:30 PM ----------
OK
Using the method to install TWRP v3 via the existing TWRP recovery version 2.8.7.0 (actually I'm not quite sure about the version, since the splash screen reported version 2.8.7.2, but the main application header reports 2.8.7.0, probably the latter version number was just not updated), finally was SUCCESSFUL with twrp-3.0.2-0-taoshan.img!
I didn't try the earlier ones, since I identified a TWRP version which should be functional.
I think probably something went wrong with the most recent update!?
Please let me know in case I could support troubleshooting somehow.
I have actually two Xperia L's, one as my primary smartphone, the second as spare, which I typically use to try out new things prior to messing around with the primary one.
Cheers
---------- Post added at 10:50 PM ---------- Previous post was at 10:39 PM ----------
Just noted that I should have read the thread more carefully first .... *doh*
Actually, where can I get the zip file? I only could download the img from the TWRP website.
Eventually I would also be interested to take a look to the sources, if possible (just out of curiosity).
Thanks in advance!
---------- Post added at 11:15 PM ---------- Previous post was at 10:50 PM ----------
I found the zip file now. But actually it didn't work either.
I extracted the twrp.img from the twrp-3.1.1-20171005-fota-taoshan.zip.
Then I applied the following commands :
adb root
adb push twrp.img /tmp/twrp.img
adb shell dd if=/tmp/twrp.img of=/dev/block/platform/msm_sdcc.1/by-name/FOTAKernel
The result is a boot loop, looping between the SONY logo and a black screen.
Afterwards I successfully installed back TWRP-3.0.2-0 using the recovery installer app from corphish.
Cheers
Click to expand...
Click to collapse
You can use official TWRP app from play store OR simply flash the twrp-3.1.1-DATE-fota-taoshan.zip using any existing recovery from HERE. That's all, simple!
stuckbootloader said:
Flash that .zip through the 3.0.2-0 recovery now, it ought to work. I had the same flashing issue. Both the app and the .zip should work now, so it doesn't really matter which method you use.
Click to expand...
Click to collapse
Hi!
Unfortunately it doesn't work for me.
I tried to flash the zip via the recovery, but ended in another boot loop after reboot with attempt to enter the recovery again.
Sent from my Xperia L using XDA-Developers Legacy app
Hi again,
I just installed the official twrp app (version 1.15, build 28) and tried to flash the twrp image 3.1.1-0.
Twrp reported successful flashing, butafter reboot the recovery was not entered, but instead I had a bootloop again.
Prior to flashing, I did a backup of the existing recovery (containing twrp-3.0.2), after re-flashing the recovery backup resulted in a functional installation of twrp3.0.2 again.
Any recommendation? I'm using the XperiaL, C2105, white version.
The device actually was returned from Sony, eg was shipped without any provider branding, because the initial phone (which did have provider branding) had issues with the camera, which therefore has been sent to Sony within the guarantee period. Sony however did not repair the phone, but rather sent back a new and original Sony device.
In case any other information might be of interest, please let me know.
Would be great to be able to install twrp3.1.1 + LineageOS 14.1!
Actually it's not clear to me if LOS14.1 could be flashed with twrp3.0.2, since errors have been reported?
Sent from my Xperia L using XDA-Developers Legacy app
xleng said:
Actually it's not clear to me if LOS14.1 could be flashed with twrp3.0.2, since errors have been reported?
Click to expand...
Click to collapse
I am not sure about your device, in my Xperia M, I use lineage 14.1 with twrp 3.0.2 with no problems. Even I tried cwm recovery, there was no problem again. So yeah you can try it.
xleng said:
Hi!
Unfortunately it doesn't work for me.
I tried to flash the zip via the recovery, but ended in another boot loop after reboot with attempt to enter the recovery again.
Sent from my Xperia L using XDA-Developers Legacy app
Click to expand...
Click to collapse
Make sure you're following the steps properly.
xleng said:
Hi again,
I just installed the official twrp app (version 1.15, build 28) and tried to flash the twrp image 3.1.1-0.
Twrp reported successful flashing, butafter reboot the recovery was not entered, but instead I had a bootloop again.
Prior to flashing, I did a backup of the existing recovery (containing twrp-3.0.2), after re-flashing the recovery backup resulted in a functional installation of twrp3.0.2 again.
Any recommendation? I'm using the XperiaL, C2105, white version.
The device actually was returned from Sony, eg was shipped without any provider branding, because the initial phone (which did have provider branding) had issues with the camera, which therefore has been sent to Sony within the guarantee period. Sony however did not repair the phone, but rather sent back a new and original Sony device.
In case any other information might be of interest, please let me know.
Would be great to be able to install twrp3.1.1 + LineageOS 14.1!
Actually it's not clear to me if LOS14.1 could be flashed with twrp3.0.2, since errors have been reported?
Sent from my Xperia L using XDA-Developers Legacy app
Click to expand...
Click to collapse
If you have working TWRP 3.0.2, you can simply flash the twrp-3.1.1-20171005-fota-taoshan.zip from HERE.
Hi again,
I try now another attempt. I take the "twrp-3.1.1-20171005-fota-taoshan.zip", saved in the SD card of the phone, which contains two items:
- folder "META-INF"
- file "twrp.img"
Using TWRP, version 3.0.2-0:
1) Menu Install
2) Select Storage -> Micro SDCard
3) Select twrp-3.1.1-20171005-fota-taoshan.zip
4) Swipe to confirm Flash
5) Adrian DC - TWRP Installer reports the following : "Flashing TWRP Recovery to FOTA... Done. Update Completed. script succeeded: result was [1.000000]; Update partition details...done"
6) Reboot system
7) Hit the vol-up during boot (especially during SONY logo)
8) Boot loop is entered.
I don't think that I have missed anything, did I?
Sorry to be a pain ....
xleng said:
Hi again,
I try now another attempt. I take the "twrp-3.1.1-20171005-fota-taoshan.zip", saved in the SD card of the phone, which contains two items:
- folder "META-INF"
- file "twrp.img"
Using TWRP, version 3.0.2-0:
1) Menu Install
2) Select Storage -> Micro SDCard
3) Select twrp-3.1.1-20171005-fota-taoshan.zip
4) Swipe to confirm Flash
5) Adrian DC - TWRP Installer reports the following : "Flashing TWRP Recovery to FOTA... Done. Update Completed. script succeeded: result was [1.000000]; Update partition details...done"
6) Reboot system
7) Hit the vol-up during boot (especially during SONY logo)
8) Boot loop is entered.
I don't think that I have missed anything, did I?
Sorry to be a pain ....
Click to expand...
Click to collapse
When you flash the zip, recovery log is generated. Can you give me that log? You can find it in "Advanced" tab.
If I read the log correctly, the dd command fails, because the ZIP is by 1 record too long for the partition.
At least the input record count is different than the output record count, which is strange.
I'm just thinking aloud if there could be a dependency with the host Maschine (at least with the ZIP file), so that the bit pattern might slightly differ due to differences in the file system types?
I believe this is the relevant part oft the log, though I can also send the complete log by PM:
==============================
==============================
| Adrian DC - TWRP Installer |
| Adrian DC - TWRP Installer |
==============================
==============================
- Flashing TWRP Recovery to FOTA...
- Flashing TWRP Recovery to FOTA...
about to run program [/sbin/dd] with 3 args
dd: writing '/dev/block/platform/msm_sdcc.1/by-name/FOTAKernel': No space left on device
32769+0 records in
32768+0 records out
16777216 bytes (16.0MB) copied, 2.417855 seconds, 6.6MB/s
run_program: child exited with status 1
Done.
Done.
Update Completed.
Update Completed.
script succeeded: result was [1.000000]I:Updater process ended with RC=0
I:Legacy property environment disabled.
Updating partition details...
...done
I:Set page: 'flash_done'
Iperation_end - status=0
I:Set page: 'clear_vars'
I:Set page: 'install'
I:Set page: 'main'
I:Set page: 'clear_vars'
I:Set page: 'main2'
I:Set page: 'advanced'
I:Set page: 'confirm_action'
I:Set page: 'action_page'
Iperation_start: 'Copy Log'
I:Copying file /tmp/recovery.log to /external_sd/recovery.log
xleng said:
If I read the log correctly, the dd command fails, because the ZIP is by 1 record too long for the partition.
At least the input record count is different than the output record count, which is strange.
I'm just thinking aloud if there could be a dependency with the host Maschine (at least with the ZIP file), so that the bit pattern might slightly differ due to differences in the file system types?
I believe this is the relevant part oft the log, though I can also send the complete log by PM:
==============================
==============================
| Adrian DC - TWRP Installer |
| Adrian DC - TWRP Installer |
==============================
==============================
- Flashing TWRP Recovery to FOTA...
- Flashing TWRP Recovery to FOTA...
about to run program [/sbin/dd] with 3 args
dd: writing '/dev/block/platform/msm_sdcc.1/by-name/FOTAKernel': No space left on device
32769+0 records in
32768+0 records out
16777216 bytes (16.0MB) copied, 2.417855 seconds, 6.6MB/s
run_program: child exited with status 1
Done.
Done.
Update Completed.
Update Completed.
script succeeded: result was [1.000000]I:Updater process ended with RC=0
I:Legacy property environment disabled.
Updating partition details...
...done
I:Set page: 'flash_done'
Iperation_end - status=0
I:Set page: 'clear_vars'
I:Set page: 'install'
I:Set page: 'main'
I:Set page: 'clear_vars'
I:Set page: 'main2'
I:Set page: 'advanced'
I:Set page: 'confirm_action'
I:Set page: 'action_page'
Iperation_start: 'Copy Log'
I:Copying file /tmp/recovery.log to /external_sd/recovery.log
Click to expand...
Click to collapse
Hi,
Thanks for the logs.
Something is not right here..
PHP:
16777216 bytes (16.0MB) copied, 2.417855 seconds, 6.6MB/s
Why 16 MB is getting copied while the recovery size is just 11.5-12 MB? This doesn't seem right.
If possible, can you run these command in device terminal? I need the output of these-
Code:
cat /proc/partitions
Code:
ls -al /dev/block/platform/msm_sdcc.1/by-name
You can upload the output on hastebin.com
Thanks and regards,
STRYDER~007
cat /proc/partitions:
[email protected]:/ # cat /proc/partitions
major minor #blocks name
254 0 262144 zram0
179 0 7634944 mmcblk0
179 1 2048 mmcblk0p1
179 2 256 mmcblk0p2
179 3 512 mmcblk0p3
179 4 512 mmcblk0p4
179 5 1024 mmcblk0p5
179 6 1024 mmcblk0p6
179 7 1024 mmcblk0p7
179 8 256 mmcblk0p8
179 9 512 mmcblk0p9
179 10 512 mmcblk0p10
179 11 1024 mmcblk0p11
179 12 1024 mmcblk0p12
179 13 1024 mmcblk0p13
179 14 1024 mmcblk0p14
179 15 1024 mmcblk0p15
179 16 3456 mmcblk0p16
179 17 16384 mmcblk0p17
179 18 8192 mmcblk0p18
179 19 8192 mmcblk0p19
179 20 16384 mmcblk0p20
179 21 8192 mmcblk0p21
179 22 8192 mmcblk0p22
179 23 65536 mmcblk0p23
179 24 19456 mmcblk0p24
179 25 5120 mmcblk0p25
179 26 8192 mmcblk0p26
179 27 16384 mmcblk0p27
179 28 1228800 mmcblk0p28
179 29 65536 mmcblk0p29
179 30 262144 mmcblk0p30
179 31 1671168 mmcblk0p31
179 32 4210671 mmcblk0p32
179 64 31472640 mmcblk1
179 65 31471616 mmcblk1p1
ls -al /dev/block/platform/msm_sdcc.1/by-name:
[email protected]:/ # ls -al /dev/block/platform/msm_sdcc.1/by-name
total 0
drwxr-xr-x 2 system root 680 2017-11-12 00:46 .
drwxr-xr-x 4 root root 740 2017-11-12 00:46 ..
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 FOTAKernel -> /dev/block/mmcblk0p27
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 LTALabel -> /dev/block/mmcblk0p20
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 TA -> /dev/block/mmcblk0p1
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 aboot -> /dev/block/mmcblk0p6
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 alt_aboot -> /dev/block/mmcblk0p12
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 alt_rpm -> /dev/block/mmcblk0p15
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 alt_s1sbl2 -> /dev/block/mmcblk0p10
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 alt_sbl1 -> /dev/block/mmcblk0p8
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 alt_sbl2 -> /dev/block/mmcblk0p9
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 alt_sbl3 -> /dev/block/mmcblk0p11
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 alt_tz -> /dev/block/mmcblk0p13
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 apps_log -> /dev/block/mmcblk0p26
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 boot -> /dev/block/mmcblk0p24
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 cache -> /dev/block/mmcblk0p30
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 fsg -> /dev/block/mmcblk0p19
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 ftma -> /dev/block/mmcblk0p29
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 ftmd -> /dev/block/mmcblk0p18
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 modem -> /dev/block/mmcblk0p23
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 modemst1 -> /dev/block/mmcblk0p21
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 modemst2 -> /dev/block/mmcblk0p22
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 persist -> /dev/block/mmcblk0p17
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 ramdump -> /dev/block/mmcblk0p25
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 rpm -> /dev/block/mmcblk0p14
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 rsv -> /dev/block/mmcblk0p16
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 s1sbl2 -> /dev/block/mmcblk0p4
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 sbl1 -> /dev/block/mmcblk0p2
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 sbl2 -> /dev/block/mmcblk0p3
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 sbl3 -> /dev/block/mmcblk0p5
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 sdcard -> /dev/block/mmcblk0p32
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 system -> /dev/block/mmcblk0p28
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 tz -> /dev/block/mmcblk0p7
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 userdata -> /dev/block/mmcblk0p31
I think the partition layout is normal. I did not previously try any modifications to the partition scheme, e.g. as suggested by some "hacks" to provide more storage to user data. I consider these as high risk (also many hard bricks have ben reported), and modify "only" the recovery and ROM area.
Best regards
xleng said:
cat /proc/partitions:
[email protected]:/ # cat /proc/partitions
major minor #blocks name
254 0 262144 zram0
179 0 7634944 mmcblk0
179 1 2048 mmcblk0p1
179 2 256 mmcblk0p2
179 3 512 mmcblk0p3
179 4 512 mmcblk0p4
179 5 1024 mmcblk0p5
179 6 1024 mmcblk0p6
179 7 1024 mmcblk0p7
179 8 256 mmcblk0p8
179 9 512 mmcblk0p9
179 10 512 mmcblk0p10
179 11 1024 mmcblk0p11
179 12 1024 mmcblk0p12
179 13 1024 mmcblk0p13
179 14 1024 mmcblk0p14
179 15 1024 mmcblk0p15
179 16 3456 mmcblk0p16
179 17 16384 mmcblk0p17
179 18 8192 mmcblk0p18
179 19 8192 mmcblk0p19
179 20 16384 mmcblk0p20
179 21 8192 mmcblk0p21
179 22 8192 mmcblk0p22
179 23 65536 mmcblk0p23
179 24 19456 mmcblk0p24
179 25 5120 mmcblk0p25
179 26 8192 mmcblk0p26
179 27 16384 mmcblk0p27
179 28 1228800 mmcblk0p28
179 29 65536 mmcblk0p29
179 30 262144 mmcblk0p30
179 31 1671168 mmcblk0p31
179 32 4210671 mmcblk0p32
179 64 31472640 mmcblk1
179 65 31471616 mmcblk1p1
ls -al /dev/block/platform/msm_sdcc.1/by-name:
[email protected]:/ # ls -al /dev/block/platform/msm_sdcc.1/by-name
total 0
drwxr-xr-x 2 system root 680 2017-11-12 00:46 .
drwxr-xr-x 4 root root 740 2017-11-12 00:46 ..
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 FOTAKernel -> /dev/block/mmcblk0p27
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 LTALabel -> /dev/block/mmcblk0p20
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 TA -> /dev/block/mmcblk0p1
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 aboot -> /dev/block/mmcblk0p6
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 alt_aboot -> /dev/block/mmcblk0p12
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 alt_rpm -> /dev/block/mmcblk0p15
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 alt_s1sbl2 -> /dev/block/mmcblk0p10
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 alt_sbl1 -> /dev/block/mmcblk0p8
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 alt_sbl2 -> /dev/block/mmcblk0p9
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 alt_sbl3 -> /dev/block/mmcblk0p11
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 alt_tz -> /dev/block/mmcblk0p13
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 apps_log -> /dev/block/mmcblk0p26
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 boot -> /dev/block/mmcblk0p24
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 cache -> /dev/block/mmcblk0p30
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 fsg -> /dev/block/mmcblk0p19
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 ftma -> /dev/block/mmcblk0p29
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 ftmd -> /dev/block/mmcblk0p18
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 modem -> /dev/block/mmcblk0p23
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 modemst1 -> /dev/block/mmcblk0p21
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 modemst2 -> /dev/block/mmcblk0p22
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 persist -> /dev/block/mmcblk0p17
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 ramdump -> /dev/block/mmcblk0p25
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 rpm -> /dev/block/mmcblk0p14
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 rsv -> /dev/block/mmcblk0p16
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 s1sbl2 -> /dev/block/mmcblk0p4
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 sbl1 -> /dev/block/mmcblk0p2
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 sbl2 -> /dev/block/mmcblk0p3
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 sbl3 -> /dev/block/mmcblk0p5
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 sdcard -> /dev/block/mmcblk0p32
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 system -> /dev/block/mmcblk0p28
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 tz -> /dev/block/mmcblk0p7
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 userdata -> /dev/block/mmcblk0p31
I think the partition layout is normal. I did not previously try any modifications to the partition scheme, e.g. as suggested by some "hacks" to provide more storage to user data. I consider these as high risk (also many hard bricks have ben reported), and modify "only" the recovery and ROM area.
Best regards
Click to expand...
Click to collapse
Yes I was suspicious about that. It seems partitions are all fine. Okay, one last thing, can you follow these steps mentioned on official TWRP site and see if recovery installs properly?
https://dl.twrp.me/taoshan/twrp-3.1.1-0-taoshan.img.html
dd Install Method (Requires Root):
Download the latest image file (.img) from the download link above. Place it in the root of your /sdcard folder and rename it to twrp.img. Run the following commands via adb shell or a terminal emulator app:
su
dd if=/sdcard/twrp.img of=/dev/block/platform/msm_sdcc.1/by-name/FOTAKernel
Click to expand...
Click to collapse
[RADIO] Cellular Radio Communication -\/ Modem | IMEI \/- Related Security Discussion!
I hope this Thread Section is A-Ok for the following. @MikeChanning i see this is one of which you are in control of. If not suitable please move it to where you see it is best fit for its final resting place. If you see this and i am sure i have the correct Mike from XDA..... Hey there guy.. =] been a while since we have spoke about the good ol days of the 90's and 00's internet. We will have to have another chat when time permits. Curious to hear more stories about my ex marketing associates and other mutual walks of underground life we ran around with.
Alright now to what I wanted to get a good discussion going on...
This whole discussion you are about to get into is spawned from my extended thirst for knowledge and related comment from @tecknight i just so happened to see moments ago. It is something that could use more educated discussion here as for one it's important to watch what you include in your EDL dumps or file pulls you provide to others. Secondly the more you know the better... The easier it is to *repair* loss of International Mobile Equipment Identity of your device without blowing a gasket!
tecknight said:
I will need all partitions except for:
fsg
modemst1
modemst2
Which contain unique information tied to your phone (IMEI, serial,etc)
I would recommend that you zip the partition images into an archive and upload them to Google drive on some other file sharing service, then PM the URL to me.
Click to expand...
Click to collapse
I too used to think that these partitions carried valuable information however after dealing with Android second operating system aka the RIL and reading various informative articles I have found out that only 2 of those are actually ones to really worry about except for [fsg] and some other partitions.
From what I understand and I have seen modem ST1 and modem st2 do you contain sensitive data however are encrypted and unreadable until you erase them and they get restored on the next reboot which I'm sure you already know. Now [modem] is just an ext4 partition containing nothing but radio firmware binaries themselves. As for [fsg] partition it's still doesn't contain all the NV items for instance and you won't find any IMEI there. Now [/dev/block/boot/device/by-name] directory however does have some interesting information according to articles and more I have recently read. Apparently according to the author of one part of where some of your information is coming from is the [tunning] partition which contained some references to NV items as well but totally different than the ones in [fsg]. Including [/nv/num/550 and [/nvm/context1/550]. When looking at the familiar patterns read from partitions [nvdiag_client -r -p /nvm/num/550] they showed up there more just as well.
This information is coming from a new 2019 Nokia model phone from what I'm Gathering but the bulk of it is common and applies to most all Qualcomm. Defile looked into was a raw binary on an EMMC partition but had some interesting regular structure despite having no file system it appeared as one. This my friends would be the second operating system on Android the RIL. This is where all the complicated work goes on when it comes to programming anything radio related. I am very limited and have unlock numerous phones in my time. Really the most experience I have is with CDMA going back to early days of last decade. So this is all still interesting information I am glad to have came across and share to everyone here. Ok.. Back to this strange amazing structure it appears to contain name-contents and also some o d d ustar references. to some when seeing this you might realize where you have seen them before.. Think and try applying tar xf ... ? With me?
[fsg] and [tunning] partitions are just TAR archives with logic structured EFS items critical for the handsets radiomodule functionality. They are apparently also TOTALLY unencrypted unlike modemst1 and modemst2 partitions that get restored from these. .... So now down to the obvious reason you would do this.. to repair and more by modifying their TAR contents and erasing the modesmst1 and modemst2 partitions that, again, get restored from these you can either repair or run game on the EFS and for example have complete total File System control in a "custom rom" and could create whats been done already but not so advanced as the ideas I have in my mind which would be randomization of these very important sacred identifier numbers 14 numbers long with a luhn check digit. The author i gathered some of this information from has already created a very small self spawning shell script running in busybox of a certain rooted Custom ROM. I don't want to lead this down the negative road and get this convo banned with those of us choosing to discuss how everything works warned/banned so i will end this here.
However if mods do not mind us discussing this in detail simply as protection measures to be watched and or protected by means of hardening security in this area that would be great and I could show an example of a simple small script that does would do the imei repair or worse with ease in a matter of seconds ...
I see positive and negative out of this and already have a load of PoC's that will work. This which people more dedicated than myself these days to research leading to action in the pentesting field might find interesting not to mention including all HATS, cellular manafacturers, ROM programmers, companies both large and small and so many more...
I would love those more experienced in this disucssion to chime in with their comments and correct me / update me if and where I am off and of course make it easier for XDA members to understand what gives so many trouble and renders devices useless unless fixed.. -=]
.
.
.
/me inserts Lamar Burks photo and whispers "this has been a reading rainbow moment" ha ha..
q=]
-noidodroid
RESERVED ..
(off to count sheep for a while - ZZZzz..)
Bump.. nobody?
Anyone ?? Surprised nobody has researched this
I would be interested to know more specific information about the topics you would like to discuss. I can see you have given thoughtful consideration to forum choice and posting guidelines, however the original message is just a little TOO circumspect and vague for me to follow. I am particularly interested to hear about your observations of the RIL and file system in this recent Nokia release, and where you see the vulnerabilities lie. If you could maybe also give some hypothetical scenarios as to how exploitations of your observations might look IRL (yes... IRL, not RIL, lol!). I am at a stage where I'm still learning about the enormous amount of unseen stuff on Android (filesystems, partitions, libraries, APIs, the nuts and bolts of the OS, all the mysterious looking stuff, and of course, the radio interface layer and all its constituents - which, I believe, are STILL relatively insecure - which I think it's also the point of your discussion...).
So... Yes... If you could perhaps give a more concise account of your observations, and perhaps a few starter questions, hopefully those with more knowledge than us might deign to lower themselves to our sordid little level, and get a little dirt on their polished fingernails sharing that sweet sweet knowledge...
With the correct information about this could u technically get any phone from the past working on any carrier or cdma /gsm and then lte (or is that hardware capabilities ) . I'm off topic slightly but not really
thorax.x said:
I would be interested to know more specific information about the topics you would like to discuss. I can see you have given thoughtful consideration to forum choice and posting guidelines, however the original message is just a little TOO circumspect and vague for me to follow. I am particularly interested to hear about your observations of the RIL and file system in this recent Nokia release, and where you see the vulnerabilities lie. If you could maybe also give some hypothetical scenarios as to how exploitations of your observations might look IRL (yes... IRL, not RIL, lol!). I am at a stage where I'm still learning about the enormous amount of unseen stuff on Android (filesystems, partitions, libraries, APIs, the nuts and bolts of the OS, all the mysterious looking stuff, and of course, the radio interface layer and all its constituents - which, I believe, are STILL relatively insecure - which I think it's also the point of your discussion...).
So... Yes... If you could perhaps give a more concise account of your observations, and perhaps a few starter questions, hopefully those with more knowledge than us might deign to lower themselves to our sordid little level, and get a little dirt on their polished fingernails sharing that sweet sweet knowledge...
Click to expand...
Click to collapse
Thanks for replying. Basically what I am trying to get discussion on here is where critical modem related files and RIL files (imei, esn, etc) reside within the files listed and whether or not one can trully gain enough information from said files to find that information. I already know the answer and also wanted to make it a point to others on what not to include in your EDL / Firmware dumps as it could be used by the wrong hands. I also had a bunch of other information more detailed but it looks like its been edited out by someone... Maybe a bit TOO detailed. ha
I will come up with some more direct questions sometime when i get a few minutes free.
.......
camm44 said:
With the correct information about this could u technically get any phone from the past working on any carrier or cdma /gsm and then lte (or is that hardware capabilities ) . I'm off topic slightly but not really
Click to expand...
Click to collapse
Technically yes and no. If the idea i mentioned will write out through serial to RIL and all security is saved or updated then yes but the other methods would be a soft IME! spoof so to speak and the other advanced methods well i cant discuss these as yeah they really could be something new not ever explored. Simply ideas for exploring to help security improve NOT to defraud or do anything illegal... -=]
What programs can be used to read binary code from phone partitions ?
OP topic is not clear...
:good:
thorax.x said:
I would be interested to know more specific information about the topics you would like to discuss. I can see you have given thoughtful consideration to forum choice and posting guidelines, however the original message is just a little TOO circumspect and vague for me to follow. I am particularly interested to hear about your observations of the RIL and file system in this recent Nokia release, and where you see the vulnerabilities lie. If you could maybe also give some hypothetical scenarios as to how exploitations of your observations might look IRL (yes... IRL, not RIL, lol!). I am at a stage where I'm still learning about the enormous amount of unseen stuff on Android (filesystems, partitions, libraries, APIs, the nuts and bolts of the OS, all the mysterious looking stuff, and of course, the radio interface layer and all its constituents - which, I believe, are STILL relatively insecure - which I think it's also the point of your discussion...).
So... Yes... If you could perhaps give a more concise account of your observations, and perhaps a few starter questions, hopefully those with more knowledge than us might deign to lower themselves to our sordid little level, and get a little dirt on their polished fingernails sharing that sweet sweet knowledge...
Click to expand...
Click to collapse
The nature of the discussion here is very unclear to say the least, does the OP have information to share with the community or it is looking for information? Seems like others are interested in the VERY BROAD topic but does not even know where to start a real discussion here. If the OP has valuable info please start by sharing that first and then the community can build on that, thanks
Excellent thread. One of the reasons I no longer use SIM cards is to avoid IMSI catcher detection by bad players. However, even when my Pixel wasn't rooted, a simple PlayStore App showed me local cell towers and they easily detected by IMEI number. I don't even know if Airplane mode does anything. Airplane mode prevents mobile data and telephony Apps from working, but does it prevent leakage of IMEI?
camm44 said:
What programs can be used to read binary code from phone partitions ?
Click to expand...
Click to collapse
What exactly are you trying to read? Which sections of the phone?
alipendier said:
:good:
The nature of the discussion here is very unclear to say the least, does the OP have information to share with the community or it is looking for information? Seems like others are interested in the VERY BROAD topic but does not even know where to start a real discussion here. If the OP has valuable info please start by sharing that first and then the community can build on that, thanks
Click to expand...
Click to collapse
DirtyAngelicaSecured said:
Excellent thread. One of the reasons I no longer use SIM cards is to avoid IMSI catcher detection by bad players. However, even when my Pixel wasn't rooted, a simple PlayStore App showed me local cell towers and they easily detected by IMEI number. I don't even know if Airplane mode does anything. Airplane mode prevents mobile data and telephony Apps from working, but does it prevent leakage of IMEI?
Click to expand...
Click to collapse
Thanks for replying guys. Basically I wanted more discussion on what crucial modem related details such as your IMEI for example reside within modemst1, modemst2, and FSG. This is with the Android operating system and is not only limited to the Nokia that I mentioned. Pretty much should be the same for Qualcomm phones but others I am not so certain. It would be interesting to know across all types of chipsets what we should protect and what is really not a big of a concern as we have always thought. There are already some discussions fear that are great that deal with unlocking T-Mobile and some other carriers but I don't really want to get into that kind of discussion as moderators will can our posts quick. These are some of my ideas in addition to the things I mentioned in the lengthy OP. Would be great to see what we really do need to be careful about and this is also can be a primer for how to repair our lost numbers if need be. Encourage any chat related to the RIL underbelly, modem files, sensitive related files and do hope some of you with greater knowledge then I and others will chime in.
RE: IMSI CATCHERS - I don't worry so much about these. I have monitored Towers for years everywhere I went as a hobby. If you are some kind of person caught in a large group of people such as a rally these are the type of places you really want to be sure to secure your phone. You can buy some material and make a ESD jamming protectant bag to conceal your phone. I just actually bought a roll for the heck of it so I could line my wallets and also a safe box and safe pouch. Again saying I don't worry kind of I guess you could say would be an understatement but I did all of this for sport as I like to put it. Perhaps one day I really will have to use it. Walking to almost any T-Mobile store for example with a booster and you've already connected to an imsi.
Downgrade modem
Hello guys, I currently have an S10e and I have the imei at 0 and that is why I am investigating since the binary 6 is very new and they have not yet launched the exploid to violate this security ... But the issue of radios, modems, ril and baseband have always interested me
noidodroid said:
Thanks for replying guys. Basically I wanted more discussion on what crucial modem related details such as your IMEI for example reside within modemst1, modemst2, and FSG. This is with the Android operating system and is not only limited to the Nokia that I mentioned. Pretty much should be the same for Qualcomm phones but others I am not so certain. It would be interesting to know across all types of chipsets what we should protect and what is really not a big of a concern as we have always thought. There are already some discussions fear that are great that deal with unlocking T-Mobile and some other carriers but I don't really want to get into that kind of discussion as moderators will can our posts quick. These are some of my ideas in addition to the things I mentioned in the lengthy OP. Would be great to see what we really do need to be careful about and this is also can be a primer for how to repair our lost numbers if need be. Encourage any chat related to the RIL underbelly, modem files, sensitive related files and do hope some of you with greater knowledge then I and others will chime in.
RE: IMSI CATCHERS - I don't worry so much about these. I have monitored Towers for years everywhere I went as a hobby. If you are some kind of person caught in a large group of people such as a rally these are the type of places you really want to be sure to secure your phone. You can buy some material and make a ESD jamming protectant bag to conceal your phone. I just actually bought a roll for the heck of it so I could line my wallets and also a safe box and safe pouch. Again saying I don't worry kind of I guess you could say would be an understatement but I did all of this for sport as I like to put it. Perhaps one day I really will have to use it. Walking to almost any T-Mobile store for example with a booster and you've already connected to an imsi.
Click to expand...
Click to collapse
vodoque said:
Hello guys, I currently have an S10e and I have the imei at 0 and that is why I am investigating since the binary 6 is very new and they have not yet launched the exploid to violate this security ... But the issue of radios, modems, ril and baseband have always interested me
Click to expand...
Click to collapse
Keep this "But the issue of radios, modems, ril and baseband have always interested me" kind of talk here and move the s10e talk to their forums. Much cleaner this way. Plus better answers for you. =]
Hi,
1-Firstly I want to ask something are you chronovir. ? if you are the one can you give me your mail adress I want to contact with you
2-When I started to research the android phone in my hand and to examine its partition, I realized that there is no source on the internet.The phone I am currently using is xiaomi mi note 10 lite.Information is usually removed because the illegal part is used some people for bad purposes.No one know anyting about what quallcom partitions do in phone. In the sources I have found now, in addition to modemst1, modemst2 and fsg, some of them also say fsc partition also related to imei.In my phone there is no tunning partition maybe in my phone name is fsc. in my phone there is quallcom chipset.I can backup my nvdata via qualcomm qpst software and it takes backup filename extension qcn or xqcn type.In my phone, when I tried to change imei numbers just beacuse out of curiosity (not illegal purposes) first I delete modemst1, modemst2 and fsg partition after that I edit qcn file and change both imei. after flashed phone detect to imei change and reboot phone in recovery mode and show nv data is corrupted writing . the only fix is the wipe data and after that when my phone open there is no signal or change.If I change only imei2 and delete imei1 . There is no security phone works correctly but only sim2 have signal sim1 cant work anymore.I think inside to rom there is protection. When I searched to rom. I find 2 things. in build.prop there is one sting name is ro.miui.restrict_imei=1 I think this one related to protection but in the internet noting found.Also I find another file but I dont want to say in this forum because of the illegal usage.I dont like apple because of the reason is apple is black box.Do you know.I pull my phone modemst1,modemst2,fsg partition in .img format.I want to edit in my pc but I cant find any method.
2-if you have any android phone can you look at the bk51 and bk52 partition.I suspect those partition but I cannot understand what happened because my knowledge is limited.
Sorry my bad english
I am sharing my phone partition name and list:
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 abl -> /dev/block/sde36
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 ablbak -> /dev/block/sde37
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 aop -> /dev/block/sde16
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 aopbak -> /dev/block/sde17
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 apdp -> /dev/block/sde8
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 bk01 -> /dev/block/sda4
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 bk02 -> /dev/block/sda5
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 bk03 -> /dev/block/sda6
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 bk04 -> /dev/block/sda7
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 bk05 -> /dev/block/sda10
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 bk06 -> /dev/block/sda13
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 bk07 -> /dev/block/sda15
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 bk08 -> /dev/block/sda20
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 bk09 -> /dev/block/sda22
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 bk31 -> /dev/block/sdd1
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 bk32 -> /dev/block/sdd3
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 bk33 -> /dev/block/sdd5
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 bk41 -> /dev/block/sde5
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 bk43 -> /dev/block/sde24
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 bk44 -> /dev/block/sde30
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 bk45 -> /dev/block/sde40
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 bk47 -> /dev/block/sde50
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 bk51 -> /dev/block/sdf3
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 bk52 -> /dev/block/sdf4
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 bluetooth -> /dev/block/sde27
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 boot -> /dev/block/sde49
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 cache -> /dev/block/sda29
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 catecontentfv -> /dev/block/sde29
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 catefv -> /dev/block/sde19
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 cateloader -> /dev/block/sde32
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 cdt -> /dev/block/sdd2
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 cmnlib -> /dev/block/sde20
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 cmnlib64 -> /dev/block/sde22
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 cmnlib64bak -> /dev/block/sde23
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 cmnlibbak -> /dev/block/sde21
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 core_nhlos -> /dev/block/sde51
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 cust -> /dev/block/sda31
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 dbg -> /dev/block/sda3
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 ddr -> /dev/block/sdd4
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 devcfg -> /dev/block/sde14
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 devcfgbak -> /dev/block/sde15
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 devinfo -> /dev/block/sda17
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 dip -> /dev/block/sde28
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 dsp -> /dev/block/sde48
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 dtbo -> /dev/block/sde45
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 exaid -> /dev/block/sda30
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 frp -> /dev/block/sda9
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 fsc -> /dev/block/sdf2
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 fsg -> /dev/block/sdf1
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 gsort -> /dev/block/sde44
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 hyp -> /dev/block/sde42
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 hypbak -> /dev/block/sde43
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 ifaa -> /dev/block/sde46
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 imagefv -> /dev/block/sda27
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 keymaster -> /dev/block/sde25
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 keymasterbak -> /dev/block/sde26
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 keystore -> /dev/block/sda8
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 limits -> /dev/block/sde4
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 logdump -> /dev/block/sda24
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 logfs -> /dev/block/sda14
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 logo -> /dev/block/sde47
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 metadata -> /dev/block/sda19
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 minidump -> /dev/block/sda25
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 misc -> /dev/block/sda11
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 modem -> /dev/block/sde52
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 modemst1 -> /dev/block/sdf5
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 modemst2 -> /dev/block/sdf6
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 msadp -> /dev/block/sde9
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 multiimgoem -> /dev/block/sde1
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 multiimgqti -> /dev/block/sde2
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 oem_misc1 -> /dev/block/sda18
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 oops -> /dev/block/sda16
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 persist -> /dev/block/sdf7
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 persistbak -> /dev/block/sdf8
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 qupfw -> /dev/block/sde6
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 qupfwbak -> /dev/block/sde7
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 rawdump -> /dev/block/sda26
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 recovery -> /dev/block/sda28
lrwxrwxrwx 1 root root 14 1970-03-22 19:02 sda -> /dev/block/sda
lrwxrwxrwx 1 root root 14 1970-03-22 19:02 sdb -> /dev/block/sdb
lrwxrwxrwx 1 root root 14 1970-03-22 19:02 sdc -> /dev/block/sdc
lrwxrwxrwx 1 root root 14 1970-03-22 19:02 sdd -> /dev/block/sdd
lrwxrwxrwx 1 root root 14 1970-03-22 19:02 sde -> /dev/block/sde
lrwxrwxrwx 1 root root 14 1970-03-22 19:02 sdf -> /dev/block/sdf
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 secdata -> /dev/block/sde3
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 splash -> /dev/block/sda21
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 spunvm -> /dev/block/sde41
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 ssd -> /dev/block/sda2
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 storsec -> /dev/block/sde11
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 super -> /dev/block/sda23
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 switch -> /dev/block/sda1
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 toolsfv -> /dev/block/sde35
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 tz -> /dev/block/sde38
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 tzbak -> /dev/block/sde39
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 uefisecapp -> /dev/block/sde33
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 uefisecappbak -> /dev/block/sde34
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 uefivarstore -> /dev/block/sde18
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 userdata -> /dev/block/sda32
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 vbmeta -> /dev/block/sde10
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 vbmeta_system -> /dev/block/sde12
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 vbmeta_vendor -> /dev/block/sde13
lrwxrwxrwx 1 root root 16 1970-03-22 19:02 vm-data -> /dev/block/sda12
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 xbl -> /dev/block/sdb2
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 xbl_config -> /dev/block/sdb1
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 xbl_configbak -> /dev/block/sdc1
lrwxrwxrwx 1 root root 15 1970-03-22 19:02 xblbak -> /dev/block/sdc2