Database Info

[ROOT] [REF] LG K7 install SuperSU without Kingroot (lgms330 and lgk330)

***It worked for me, but I make no guarantee of invariable results. I therefore, claim no responsibility and offer no warranty. If it does brick your phone, please pm me with the subject "SuperSU without Kingroot" so we can figure out where we went wrong.***
MetroPCS (lgms330) and the T-Mobile (lgk330) models.​
The TWRP method: It's easier than the old method in post 3 which did mess up a couple of peoples phones for some reason. The method in post 3 is still relevant for those who don't want to use TWRP for whatever reason.
You will need:
computer, usb cord, and *adb/fastboot installed
*A note to those who don't know what adb or fastboot is:
There are plenty of tutorials out there explaining how to install and use adb and fastboot.
If you are unfamiliar with these tools you may want to check out this forum.
Part 1: enable developer mode / unlock boot loader
Developer options
On your phone, open settings do the following
Enable Developer mode
{
"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"
}
Enable oem unlock (LG was nice enough to enable us to unlock our bootloader from the "developer options")
Enable adb debug
Plug your phone into your computer and run
Code:
adb devices
you will be prompted to Allow USB debugging?
​
Part 2: installing the Team Win Recovery Project.
I can confirm that the following technique works for the T-Mobile k330 too.
Abridged quoted instructions from this thread / partial copy from post #42 Senior Member: starkly_raving
Prerequisites:
1. unlocked bootloader
2. knowledge of fastboot commands.
First, connect your phone to the computer and run
Code:
adb reboot bootloader
Next, if you want to test but not replace your recovery
Code:
fastboot boot Twrp_m1_v2.img
Instead, if you want to replace your recovery partition with TWRP
Code:
fastboot flash recovery twrp-image-3.img
DOWNLOADS:
New forum has a version of TWRP with a button combination to boot into recovery.
Beta1:
twrp-image-3.img I hope you don't mind me mirroring [MENTION=805681]reemobeens19
Part 3: Installing SuperSu, Xposed framework, and Xposed installer
At the time of this writing these are the latest versions:
Xposed framework: sdk22/arm/xposed-v86-sdk22-arm.zip
Xposed installer: XposedInstaller_3.0-alpha4.apk
SuperSU: Version 2.76
Xposed uninstaller <- You need to flash this in order to completely uninstall the Xposed framework if you don't want it anymore or you want to upgrade with a newer version.
On our phone booting into TWRP can be done with the physical button combinations. If you don't feel like doing finger gymnastics you can use
Code:
adb reboot recovery
Tap install, choose the zip file(s) you downloaded, and the rest is fairly self explanatory.
If I made any errors or omissions feel free to mention it. I really hope this helps.

Xposed Follow up
Now that you have the Xposed Framework installed, you need to install the "Xposed installer" app in order to use it.
You need to go into settings -> security -> and check the box that says "Unknown sources"
If you have downloaded the XposedInstaller_3.0_alpha4.apk onto you phone, then you can use the "File Manager" app already installed on the phone; navigate to the XposedInstaller_3.0_alpha4.apk (probably in your "Download" folder); and tap on it. It will ask if you want to install it so tap install.
Xposed installer needs root access so grant it when prompted. The first time I ran the actual app it threw an error message. Either restart your phone or restart the app (I cannot remember which I did) then it should work.

OBSOLETE
Here are the old instructions for postarity. It worked for quite a few people
***I have followed this exact procedure with a 100% success rate in linux; however, I make no guarantee invariable results. I therefore, claim no responsibility and offer no warranty. If it does brick your phone, please pm me with the subject "SuperSU without Kingroot" so we can figure out where we went wrong.***​
These custom system images come with SuperSu and the appropriate Xposed framework (sdk22/arm/xposed-v86-sdk22-arm.zip) baked right in.
So many people have bricked their LG K7's trying to replace kingroot with the superb SuperSu by chainfire. I have seen many that have bricked their phones trying to flash the latest Xposed framework as well. This method will hopefully be easy enough to deter people relying on kingroot all together. (Feel free to leave feedback in the comments if there is a step that need further elaboration or isn't working)
This tutorial will work for both the MetroPCS (lgms330) and the T-Mobile (lgk330) models.​***This will wipe your device***
​You will need:
computer, usb cord, *adb/fastboot installed, the appropriate system image, and serious patience.
MetroPCS Download:
ms330_root_system.img
T-Mobile Download:
k330_root_system.img
*A note to those who don't know what adb or fastboot is:
There are plenty of tutorials out there explaining how to install and use adb and fastboot.
If you are unfamiliar with these tools you may want to check out this forum.
Developer options
On your phone, open settings do the following
Enable Developer mode
Enable oem unlock (LG was nice enough to enable us to unlock our bootloader from the "developer options")
Enable adb debug
Plug your phone into your computer and run
Code:
adb devices
you will be prompted to Allow USB debugging?
​
Someone who is proficient in Windows please verify that fastboot "sees" the device. I was having trouble getting my Windows 7 64bit machine to recognize it. It worked every time in linux though. Thanks.
ADB/Fastboot commnads
On the computer (in windows you may have to replace adb with adb.exe and fastboot with fastboot.exe)
Code:
adb reboot bootloader
Code:
fastboot oem unlock
Don’t worry about the message it returns:
Code:
FAILED (remote: Already unlocked)
or
Code:
OKAY [ 0.040s]
Let's be OCD and make certain the bootloader is unlock.
Code:
fastboot getvar unlocked
The result should be
Code:
unlocked: yes
finished. total time: 0.001s
Get ready to wait a loooooong time. Flash the correct system image for your device carrier.
DON’T PANIC!!! When you run the fastboot command to flash the system image, it will return something like “Invalid sparse file format at header magi” and hangs for what seems like an eternity. This is normal. The next message it returns is “erasing 'system'...” and then you wait another eternity for the system to be overwritten. Mine took over 6 minutes to complete.
MetroPCS
Code:
fastboot flash system ms330_root_system.img
T-Mobile
Code:
fastboot flash system k330_root_system.img
​
Wait forever for it to get to the “Android is starting…” screen by running
Code:
fastboot reboot
I have no problem with kingroot as a concept. I just want to help people avoid bricking their phones.

It says cannot load 'ms330_root_system.img'
When I did the fastboot getvar unlocked it showed, "unlocked: yes; finished total time 0.000"

IEatFood said:
It says cannot load 'ms330_root_system.img'
When I did the fastboot getvar unlocked it showed, "unlocked: yes; finished total time 0.000"
Click to expand...
Click to collapse
I assume you are on the step where you issue the fastboot command to flash the system image. I'm guessing you don't have the system image in the same directory as you are executing the fastboot command. i.e. If you downloaded the 'ms330_root_system.img' into your Downloads folder you need to change into that directory in the command prompt
Windows cmd
Code:
C:\Windows\system32>
C:\Windows\system32> cd C:\Users\IEatFood\Downloads
C:\Users\IEatFood\Downloads> fastboot flash system ms330_root_system.img
Alternitavly, you could copy/paste the 'ms330_root_system.img' into the same directory as the fastboot.exe
Linux terminal
Code:
~/ $
~/ $ cd Downloads/
~/Downloads $ fastboot flash system ms330_root_system.img

ledzepman71 said:
I assume you are on the step where you issue the fastboot command to flash the system image. I'm guessing you don't have the system image in the same directory as you are executing the fastboot command. i.e. If you downloaded the 'ms330_root_system.img' into your Downloads folder you need to change into that directory in the command prompt
Windows cmd
Code:
C:\Windows\system32>
C:\Windows\system32> cd C:\Users\IEatFood\Downloads
C:\Users\IEatFood\Downloads> fastboot flash system ms330_root_system.img
Alternitavly, you could copy/paste the 'ms330_root_system.img' into the same directory as the fastboot.exe
Linux terminal
Code:
~/ $
~/ $ cd Downloads/
~/Downloads $ fastboot flash system ms330_root_system.img
Click to expand...
Click to collapse
Alright, 'I got the invalid sparse file format at header magi'
finished. total time: 0.002s
C:\Program Files (x86)\Minimal ADB and Fastboot>fastboot flash system ms330_root
_system.img
target reported max download size of 268435456 bytes
Invalid sparse file format at header magi
erasing 'system'...
OKAY [ 0.034s]
sending sparse 'system' 1/9 (257070 KB)...
OKAY [ 8.874s]
writing 'system' 1/9...
FAILED (remote: size too large)
finished. total time: 8.915s

Now it bricked my phone.
It keeps loading Bootloader STATE: Bootloader Unlock!!

IEatFood said:
Now it bricked my phone.
It keeps loading Bootloader STATE: Bootloader Unlock!!
Click to expand...
Click to collapse
My phone is doing the exact same thing after following the tutorial

CompFreak89 said:
My phone is doing the exact same thing after following the tutorial
Click to expand...
Click to collapse
Did it run successfully? If so sometimes you have to do the factory restet. Power off. Hold Vol down and power button. When the screen comes on keep holding down the vol down button let go of the power button and then push the power button again.
If it didn't run successfully please pm be with all the details including your phone model and all the output from the command line. Don't worry we'll get you squared away.

I updated the op to use an easier more standard way with TWRP.

tried it!
can't get past the step where you fastboot it, it get's stuck on the LG logo with small letters at the top
any ideas why?
I am on K330 by the way

To everyone. Please do research before flashing anything. Somebody had an lg Stylo tot. Trying to pass it off as a MS330! Wrong. Please research.
https://www.facebook.com/Czarsuperstar/

azureee said:
can't get past the step where you fastboot it, it get's stuck on the LG logo with small letters at the top
any ideas why?
I am on K330 by the way
Click to expand...
Click to collapse
If your problem hasn't been resolved, can you please describe in further detail what happened. Were you using the obsolete instructions in post 3? Were you on the step where you reboot into the bootloader? If you're really stuck please feel free to pm me.

[email protected] said:
To everyone. Please do research before flashing anything. Somebody had an lg Stylo tot. Trying to pass it off as a MS330! Wrong. Please research.
https://www.facebook.com/Czarsuperstar/
Click to expand...
Click to collapse
Hello, I appreciate your concern. On the topic of research, I was once told "a week in the lab can save you an hour in the library." I absolutely agree and would also encourage everyone to look deeper before plunging in head first.
If you are doubting the authenticity of my efforts and files allow me to elaborate on my method. As you will see, all the files were pulled directly off my personal phone and are not second hand impostors.
First, I looked up the partition table in adb using
Code:
ls -al /dev/block/platform/*/by-name
which output:
Code:
lrwxrwxrwx root root 1970-01-10 18:59 DDR -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 1970-01-10 18:59 aboot -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 1970-01-10 18:59 abootbak -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 1970-01-10 18:59 boot -> /dev/block/mmcblk0p33
lrwxrwxrwx root root 1970-01-10 18:59 cache -> /dev/block/mmcblk0p38
lrwxrwxrwx root root 1970-01-10 18:59 config -> /dev/block/mmcblk0p21
lrwxrwxrwx root root 1970-01-10 18:59 devinfo -> /dev/block/mmcblk0p20
lrwxrwxrwx root root 1970-01-10 18:59 drm -> /dev/block/mmcblk0p28
lrwxrwxrwx root root 1970-01-10 18:59 eksst -> /dev/block/mmcblk0p19
lrwxrwxrwx root root 1970-01-10 18:59 encrypt -> /dev/block/mmcblk0p18
lrwxrwxrwx root root 1970-01-10 18:59 factory -> /dev/block/mmcblk0p35
lrwxrwxrwx root root 1970-01-10 18:59 fota -> /dev/block/mmcblk0p23
lrwxrwxrwx root root 1970-01-10 18:59 fsc -> /dev/block/mmcblk0p15
lrwxrwxrwx root root 1970-01-10 18:59 fsg -> /dev/block/mmcblk0p14
lrwxrwxrwx root root 1970-01-10 18:59 grow -> /dev/block/mmcblk0p40
lrwxrwxrwx root root 1970-01-10 18:59 keystore -> /dev/block/mmcblk0p17
lrwxrwxrwx root root 1970-01-10 18:59 laf -> /dev/block/mmcblk0p32
lrwxrwxrwx root root 1970-01-10 18:59 misc -> /dev/block/mmcblk0p30
lrwxrwxrwx root root 1970-01-10 18:59 modem -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 1970-01-10 18:59 modemst1 -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 1970-01-10 18:59 modemst2 -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 1970-01-10 18:59 mpt -> /dev/block/mmcblk0p36
lrwxrwxrwx root root 1970-01-10 18:59 persist -> /dev/block/mmcblk0p31
lrwxrwxrwx root root 1970-01-10 18:59 raw_resources -> /dev/block/mmcblk0p26
lrwxrwxrwx root root 1970-01-10 18:59 raw_resourcesbak -> /dev/block/mmcblk0p27
lrwxrwxrwx root root 1970-01-10 18:59 rct -> /dev/block/mmcblk0p24
lrwxrwxrwx root root 1970-01-10 18:59 recovery -> /dev/block/mmcblk0p34
lrwxrwxrwx root root 1970-01-10 18:59 rpm -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 1970-01-10 18:59 rpmbak -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 1970-01-10 18:59 sbl1 -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 1970-01-10 18:59 sbl1bak -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 1970-01-10 18:59 sec -> /dev/block/mmcblk0p16
lrwxrwxrwx root root 1970-01-10 18:59 sns -> /dev/block/mmcblk0p29
lrwxrwxrwx root root 1970-01-10 18:59 spare1 -> /dev/block/mmcblk0p22
lrwxrwxrwx root root 1970-01-10 18:59 spare2 -> /dev/block/mmcblk0p25
lrwxrwxrwx root root 1970-01-10 18:59 ssd -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 1970-01-10 18:59 system -> /dev/block/mmcblk0p37
lrwxrwxrwx root root 1970-01-10 18:59 tz -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 1970-01-10 18:59 tzbak -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 1970-01-10 18:59 userdata -> /dev/block/mmcblk0p39
As you can see, "/dev/block/mmcblk0p37" is the block device for the system partition. From there you simply duplicate the data into a raw image by doing
Code:
dd if=/dev/block/mmcblk0p37 bs=2048 of=/storage/external_SD/system.img
To elaborate on what the command does, the input file is the system block mmcblk0p37 and the output file is created as "system.img" on the external sd card. From the man page, "bs=BYTES read and write up to BYTES bytes at a time." So it just means that the dd operation can read and write up to 2048 bytes at a time.
This process was simply repeated using a stock k330, rooted k330, stock ms330, and rooted ms330. After all the raw images were created I systematically flashed them to my personal phone using the instructions verbatim from my op to ensure that they indeed work.
I hope explaining my process sheds further light on the matter. If you want to investigate further on your own you can mount the raw image in linux. Assuming that the system.img file is in your home directory and you have the directory /mnt/tmp , simply run as root
Code:
mount -o ro ~/system.img /mnt/tmp
and you will then be able to see the contents of the image (build prop, preinstalled apps, and the like) in the /mnt/tmp folder.
If you have any further comments or questions I will happily oblige.
The whole point of my effort was to aid people in rooting there phones while mitigating the risk of bricking. I want to make the process as bullet proof as possible so all feedback is welcome. This includes testimonials from those whom this process worked. I guess the next step would be to post the TWRP backup zips to further automate of the process.

unbrick method
@azureee, I am so happy to hear that you found a solution to your problem. Thank you for sharing that link as well. I am sure it will help many people here. If you need any further explanation on installing xposed I would be happy to help.

Please update this forum to have lg-k7 tag and to have newest twrp with button combo. That way this will be on the LG K7 forum and have best TWRP. Also "fastboot boot" is only way it works, flashing will get overwritten by system. And then when you want to get to recovery it will factory reset phone. You can flash after you root.

Billybobjoe13245 said:
Please update this forum to have lg-k7 tag and to have newest twrp with button combo. That way this will be on the LG K7 forum and have best TWRP. Also "fastboot boot" is only way it works, flashing will get overwritten by system. And then when you want to get to recovery it will factory reset phone. You can flash after you root.
Click to expand...
Click to collapse
Thank you for the heads up about TWRP. I keep trying to add that tag, but it refuses to stick.
Edit: I had to delete the tag that wasn't showing up and readd it.

ledzepman71 said:
I updated the op to use an easier more standard way with TWRP.
Click to expand...
Click to collapse
Hi, thank you for the tutorial.
I do have a noob question: After unlocking the bootloader, flashing twrp and flashing supersu from within twrp will the phone be rooted? No need to install Kingroot or similar?
Thanks!

101...
saphta said:
Hi, thank you for the tutorial.
noob question: After unlocking the bootloader, flashing twrp and flashing supersu from within twrp will the phone be rooted?
Click to expand...
Click to collapse
Just go to the Play Store and download a "Root Checker" to get your answer...
Time To Learn How To Run With The *Big Dogs* if you are going to Root..

RaiderWill said:
Just go to the Play Store and download a "Root Checker" to get your answer...
Time To Learn How To Run With The *Big Dogs* if you are going to Root..
Click to expand...
Click to collapse
Thanks! I'll do that!

[INFO] ANDROID DEVICE PARTITIONS and FILESYSTEMS

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 ?

[ROOT] - lafsploit - H918 (any version up to and including 20h) - now n00b friendly

WARNING​
This should go without saying, but you MUST have your bootloader unlocked (check OEM UNLOCK in developer options AND fastboot oem unlock).
If you don't, you WILL brick your phone.
If you don't know how to FULLY unlock your bootloader -- search. This thread is not here to educate you on unlocking your bootloader.
If your bootloader isn't unlocked, you will get a RED warning that your phone has been modified, and will refuse to boot.
If your bootloader IS unlocked, your will have a YELLOW warning even if you haven't modified your phone yet, and your phone will still boot. This is normal!
If you use this on any model V20 besides the H918, you will be stuck in a bootloop, and you will not be able to fix it since you will have wiped out download mode!
There is NO fixing this!
You must be on version H91810p or H91810q
This is now completely safe. It will either work or it won't, but it can NOT brick your phone if you meet the requirements listed above, and you follow the procedure exactly.
If it DOES brick your phone, I am not responsible.
If you deviate from this procedure, and think: "I can just skip a step, or I can do this on my own Linux install". Don't complain if you brick your phone.
This ONLY replaces download mode with TWRP. If you want to root, you can search for how to root. If you don't know how to use TWRP -- search.
PREREQUISITES:
If you aren't on 10p or 10q, grab the H918 10p KDZ: here.
This is NOT a guide for flashing KDZs -- there are plenty of those out there -- search.
You need to grab FWUL (version 2.7 or later) and burn it to a USB stick: link
Even if you have Linux, and you think you can install the dependencies, don't. I know this works from FWUL.
If you choose to press on in expert mode (using FWUL in a VM, using your own Linux install, using WSL, etc), don't get upset if I don't answer your questions.
For Windows you will need Rufus to burn FWUL onto a USB stick.
If you have questions about FWUL, please ask in the FWUL thread.
Installing TWRP
Again, this will ONLY install TWRP onto download mode. What you do with TWRP when it is done is up to you. Flash Magisk or SuperSU. Flash a ROM, or just make a backup of your phone. It is up to you.
I would suggest flashing TWRP onto recovery as well, otherwise you will need to use the vol up + USB cable method to get to TWRP. There is no key combination to get to download mode.
Boot from your FWUL USB stick.
Put your phone into download mode. With the phone powered off, hold vol up and plug in the USB cable. You do not need to touch the power button -- the phone will power on and enter download mode.
Once booted, login. The password is: linux
Double click the LG folder that is on the desktop
Double click on LG LAF (runningnak3d) icon and you will be at a terminal prompt.
The following are the commands that you enter into that terminal. You can copy / paste them if you like.
Code:
git pull
git checkout h918-miscwrte
./step1.sh
When you are told to, pull the USB cable, and the phone will power off. You now have TWRP on your laf partition.
It must be said again, flash TWRP onto recovery so you can easily get to TWRP.
OPTIONAL
If you would like to restore download mode onto your laf partition AFTER you have installed TWRP onto recovery:
Boot to TWRP that is on recovery
Flash this zip: laf_restore.zip
This can be done at any time after you are rooted. About the only reason you would want to flash laf back is if you use LG Backup.
TWRP has the ability to backup your phone, so I am not sure why someone would want this (maybe you are more comfortable with it?).
Also, flashing back to 100% unrooted stock can be accomplished by flashing a zip in TWRP, you don't NEED to flash a KDZ, but again, maybe you are more comfortable doing it that way.
The bottom line is TWRP on both laf and recovery is FAR FAR more useful than flashing laf back. You can test new versions of TWRP while keeping your old known working version (for example).
If you are having problems flashing a ROM, ask in the appropriate ROM thread.
If you are having problems with Magisk, ask in the Magisk thread.
If you are having problems with SuperSU, Lineage, or even TWRP itself, ask in the appropriate thread.
This thread is ONLY for problems if TWRP doesn't boot when you are done.
CREDITS:
Lekensteyn -- His base work on the G2 / G3 gave me a GREAT headstart!
@steadfasterX - He added some real nice features, great guy to bounce ideas off, and just testing crazy ideas because he wasn't afraid to brick his phone Also, for FWUL
tuxuser - Helping with my lacking in Python
@smitel - His original reverse engineering of LG UP. Great inspiration!
@me2151 - His original DirtySanta exploit. Without it, the V20 would probably still not be rooted.
-- Brian
XDA:DevDB Information
lafsploit, Tool/Utility for the LG V20
Contributors
runningnak3d
Source Code: https://gitlab.com/runningnak3d/lglaf
Version Information
Status: Stable
Current Stable Version: 1.1
Stable Release Date: 2018-07-15
Created 2018-04-05
Last Updated 2018-07-16

Congratulations for this amazing work I been follow your work on your original tread it's amazing !!! I current have the note 8 but I still have a v20 (from what i posting right now lol ) the first was. TMobile and right now I have a Verizon unlock v20 Wich I really enjoying Whit Xposed mode well anyway what I trying to said is you work make me pick up my v20 again and give me some inspiration to learn ... Keep going
UPDATE: I GET A TMOBILE V20 now I have root again, thanks again ?

Congrats been following your work since day 1 man the effort paid off. Thanks one man that took on the whole lg dev team.

Will there ever be a chance for the US998 (US Cellular) ?

Awesome can't wait to build lineage for the v20! Now that I have a spare device it'll make learning a lot easier. So now I can test on my current daily driver before adding the mods to my v20 builds. I can't even begin to describe how much this means to so many of us in the community! Especially myself.
That said I'll give it a try tomorrow after work assuming I have friday off & l'll report back asap.
If installing python 3 on windows 10 will the default install settings work? Just wanted to double check. & thanks again man. Amazingly awesome work!
Sent from my LG-D851 using XDA Labs
---------- Post added at 01:35 AM ---------- Previous post was at 01:32 AM ----------
KanBorges said:
Will there ever be a chance for the US998 (US Cellular) ?
Click to expand...
Click to collapse
He is also working on the locked bootloader devices. I'll let him explain most of the details if he has the time. However if you want to read up on the progress check this thread:
https://forum.xda-developers.com/v20/how-to/laf-download-mode-how-root-t3676011/page92
Sent from my LG-D851 using XDA Labs

omg, you sir are a God! [emoji122] [emoji122]
Sent from my LG-H918 using XDA-Developers Legacy app

KanBorges said:
Will there ever be a chance for the US998 (US Cellular) ?
Click to expand...
Click to collapse
Even though the US998 isn't officially unlockable yet, you can follow this: https://forum.xda-developers.com/lg-v30/how-to/us998-bootloader-unlock-achieved-t3743359

https://gist.github.com/zacharee/6aa5fcb56d0a42937869494b12d77da2
working link

Thanks @dudeawsome and @Zacharee1 I fixed the link.

using the instructions provided, I'm consistently getting a usb device not found runtime error, any advice?

If you are on Windows, did you install the LG drivers?
-- Brian

runningnak3d said:
WARNING to G5 and G6 users. I need a partition listing before you try this to make sure misc is in the same location. You can brick your phone if misc is in a different location than the V20.
I am splitting this off from the main laf thread because that thread really needs to be cleaned. It was supposed to just be for development, and now it is impossible to find some valuable info
I say this is for the H918 only, but it should work on the H830 (G5) and H872 (G6) as well. I don't have those devices, so I can't test it. The H830 has a TWRP build, but the H872 doesn't -- so someone would have to risk using the US997 build.
Anyway, if you aren't feint at heart....
Here is a much more detailed guide that @Zacharee1 put together: link.
Enjoy your now rooted H918...
If this scares anyone, I will make it easier, but for the hardcore people, I wanted to get it out there.
I will clean this up and make it prettier when I have the chance.
-- Brian
Click to expand...
Click to collapse
Code:
1|lucye:/ $ ls -l /dev/block/platform/soc/624000.ufshc/by-name/
total 0
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 aboot -> /dev/block/sde6
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 abootbak -> /dev/block/sde7
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 apdp -> /dev/block/sde26
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 boot -> /dev/block/sde1
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 cache -> /dev/block/sda17
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 cdt -> /dev/block/sdd3
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 cmnlib -> /dev/block/sde22
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 cmnlib64 -> /dev/block/sde24
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 cmnlib64bak -> /dev/block/sde25
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 cmnlibbak -> /dev/block/sde23
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 ddr -> /dev/block/sdd1
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 devcfg -> /dev/block/sde16
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 devcfgbak -> /dev/block/sde17
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 devinfo -> /dev/block/sdb6
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 dip -> /dev/block/sdb5
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 dpo -> /dev/block/sde28
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 drm -> /dev/block/sda4
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 eksst -> /dev/block/sda11
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 encrypt -> /dev/block/sda10
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 eri -> /dev/block/sda7
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 factory -> /dev/block/sda9
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 fota -> /dev/block/sdb3
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 fsc -> /dev/block/sdf3
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 fsg -> /dev/block/sdb4
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 grow -> /dev/block/sda19
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 grow2 -> /dev/block/sdb7
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 grow3 -> /dev/block/sdc3
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 grow4 -> /dev/block/sdd4
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 grow5 -> /dev/block/sde29
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 grow6 -> /dev/block/sdf4
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 grow7 -> /dev/block/sdg2
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 hyp -> /dev/block/sde12
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 hypbak -> /dev/block/sde13
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 keymaster -> /dev/block/sde20
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 keymasterbak -> /dev/block/sde21
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 keystore -> /dev/block/sda14
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 laf -> /dev/block/sda1
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 lafbak -> /dev/block/sda2
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 misc -> /dev/block/sda8
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 modem -> /dev/block/sde18
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 modemst1 -> /dev/block/sdf1
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 modemst2 -> /dev/block/sdf2
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 mpt -> /dev/block/sda3
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 msadp -> /dev/block/sde27
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 operatorlogging -> /dev/block/sda6
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 persist -> /dev/block/sda15
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 persistent -> /dev/block/sdg1
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 pmic -> /dev/block/sde14
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 pmicbak -> /dev/block/sde15
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 raw_resources -> /dev/block/sde8
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 raw_resourcesbak -> /dev/block/sde9
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 rct -> /dev/block/sda12
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 recovery -> /dev/block/sde2
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 recoverybak -> /dev/block/sde3
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 reserve -> /dev/block/sdd2
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 rpm -> /dev/block/sde10
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 rpmbak -> /dev/block/sde11
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 sec -> /dev/block/sde19
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 sns -> /dev/block/sda5
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 ssd -> /dev/block/sda13
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 system -> /dev/block/sda16
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 tz -> /dev/block/sde4
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 tzbak -> /dev/block/sde5
lrwxrwxrwx 1 root root 16 2018-01-16 19:40 userdata -> /dev/block/sda18
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 xbl -> /dev/block/sdb1
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 xbl2 -> /dev/block/sdc1
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 xbl2bak -> /dev/block/sdc2
lrwxrwxrwx 1 root root 15 2018-01-16 19:40 xblbak -> /dev/block/sdb2
I am trying to download source to build twrp for the g6 but I am on my backup dsl (762kb/s) which sucks majorly.
If you are in an IRC chan I will be more then happy to join and give you access to my device remotely if need be.

on windows 10, latest insider build, all drivers installed, v20 detected in normal boot, download and fastboot modes. I'm reinstalling ubuntu just in case something weird happened with it..

@KAsp3rd Join #lglaf on irc.freenode.net
What I need is the GPT -- start LBA / end LBA of misc.
You can get that by running ./partitions.py --list
-- Brian

So after entering Download/LAF Mode and plugging in to computer, I get the following error when running the first command in step 6 of @Zacharee1's guide:
Code:
C:\lglaf>partitions.py --dump laf.img laf
LAF Crypto failed to import!
Traceback (most recent call last):
File "C:\lglaf\partitions.py", line 459, in <module>
main()
File "C:\lglaf\partitions.py", line 406, in main
comm = lglaf.autodetect_device()
File "C:\lglaf\lglaf.py", line 441, in autodetect_device
return USBCommunication()
File "C:\lglaf\lglaf.py", line 297, in __init__
custom_match = self._match_device)
File "C:\Users\SMTB\AppData\Local\Programs\Python\Python36-32\lib\site-packages\usb\core.py", line 1263, in find
raise NoBackendError('No backend available')
usb.core.NoBackendError: No backend available
As I am a total n00b, I have no idea what this means. Any help appreciated!
(using Windows Python install)

You didn't pip install cryptography or PyUSB
-- Brian

Getting the same backend error. Trying to reinstall just throws up an already installed reply. Windows 8.1
That is, trying to run the ./ cmds and the already installed elements are pyusb and crypt

runningnak3d said:
You didn't pip install cryptography or PyUSB
-- Brian
Click to expand...
Click to collapse
Well I did install those. When I try running pip install cryptography/PyUSB again, I get:
Code:
C:\lglaf>pip install cryptography
Requirement already satisfied: cryptography in c:\users\smtb\appdata\local\programs\python\python36-32\lib\site-packages
Requirement already satisfied: idna>=2.1 in c:\users\smtb\appdata\local\programs\python\python36-32\lib\site-packages (from cryptography)
Requirement already satisfied: six>=1.4.1 in c:\users\smtb\appdata\local\programs\python\python36-32\lib\site-packages (from cryptography)
Requirement already satisfied: asn1crypto>=0.21.0 in c:\users\smtb\appdata\local\programs\python\python36-32\lib\site-packages (from cryptography)
Requirement already satisfied: cffi>=1.7; platform_python_implementation != "PyPy" in c:\users\smtb\appdata\local\programs\python\python36-32\lib\site-packages (from cryptography)
Requirement already satisfied: pycparser in c:\users\smtb\appdata\local\programs\python\python36-32\lib\site-packages (from cffi>=1.7; platform_python_implementation != "PyPy"->cryptography)
C:\lglaf>pip install PyUSB
Requirement already satisfied: PyUSB in c:\users\smtb\appdata\local\programs\python\python36-32\lib\site-packages

I take it you aren't on Windows 10 so you can't install Ubuntu from the app store?
I can see now why @steadfasterX pushes FWUL (a Linux VM) for things like this. WIndows is such a freaking PITA
Hopefully someone that has Windows can help you, otherwise I am going to grab FWUL tomorrow and maybe change the procedure for people that aren't on WIndows 10.
-- Brian

ok, just tried the whole procedure from start to finish exactly for the second time and am getting the same "usb device not found"
I also tried the non windows 10 method and ended up having the same issue that smtb1963 has, including the laf crypto failed to import message at the top and I do believe that when it says no backend available under usb lib, that these ar basically the same error, no usb communication. I think i am going to try this on a unbuntu virtual box install and see if I get the same error

Verizon Pixel 2, assistance needed

Yes, there is a thread for unlocking the bootloader but that is for a previous version. If anyone with root is running the factory image for Android 9.0, we are in need of a bit image dump. If you can follow the link below and just provide the dump, I am more than happy to do the rest.
From what I have been noticing, there may be a hidden command that is preventing us from getting further in unlocking the bootloader. Any help to either prove or disprove this theory would be greatly appreciated. In the meantime, I am syncing with the aosp repo provided by Google.
Your help could greatly speed up the process ?
https://www.xda-developers.com/how-to-discover-hidden-fastboot-commands
Thank you

I've tried everything as far as decompiling system apks. Someone doing this would really really help out.

there is not one called aboot, here is a print out of what it shows. I did get the aboot1 and aboot2I uploaded them to my google drive.
walleye:/ $ su
walleye:/ # cd /dev/block/bootdevice/by-name
walleye:/dev/block/bootdevice/by-name # ls -all
total 0
drwxr-xr-x 2 root root 1540 1970-12-11 22:15:39.436666759 -0500 .
drwxr-xr-x 3 root root 1680 1970-12-11 22:15:39.436666759 -0500 ..
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.410000090 -0500 abl_a -> /dev/block/sda8
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.403333423 -0500 abl_b -> /dev/block/sda29
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.406666756 -0500 apdp_a -> /dev/block/sda14
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.426666758 -0500 apdp_b -> /dev/block/sda35
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.423333425 -0500 board_info -> /dev/block/sdf1
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:38.666666683 -0500 boot_a -> /dev/block/sda9
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.410000090 -0500 boot_b -> /dev/block/sda30
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.433333426 -0500 cdt -> /dev/block/sdd5
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.400000089 -0500 cmnlib64_a -> /dev/block/sda13
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.423333425 -0500 cmnlib64_b -> /dev/block/sda34
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.420000091 -0500 cmnlib_a -> /dev/block/sda12
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.416666757 -0500 cmnlib_b -> /dev/block/sda33
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.426666758 -0500 ddr -> /dev/block/sdd6
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.413333424 -0500 devcfg_a -> /dev/block/sda16
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.403333423 -0500 devcfg_b -> /dev/block/sda37
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.436666759 -0500 devinfo -> /dev/block/sdf4
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.416666757 -0500 dip -> /dev/block/sdd8
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.430000092 -0500 dpo -> /dev/block/sdd9
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:38.670000016 -0500 dtbo_a -> /dev/block/sda21
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.426666758 -0500 dtbo_b -> /dev/block/sda42
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.430000092 -0500 frp -> /dev/block/sdd4
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.430000092 -0500 fsc -> /dev/block/sdd17
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.433333426 -0500 fsg -> /dev/block/sdf3
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.413333424 -0500 hosd_a -> /dev/block/sda10
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.420000091 -0500 hosd_b -> /dev/block/sda31
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.400000089 -0500 hyp_a -> /dev/block/sda5
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.420000091 -0500 hyp_b -> /dev/block/sda26
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.423333425 -0500 keymaster_a -> /dev/block/sda11
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.413333424 -0500 keymaster_b -> /dev/block/sda32
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.420000091 -0500 limits -> /dev/block/sdd11
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.410000090 -0500 lockbooter_a -> /dev/block/sda2
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.420000091 -0500 lockbooter_b -> /dev/block/sda23
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.433333426 -0500 logfs -> /dev/block/sdd13
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.420000091 -0500 metadata -> /dev/block/sde4
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.420000091 -0500 mfg -> /dev/block/sdf2
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.426666758 -0500 misc -> /dev/block/sdd1
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.413333424 -0500 modem_a -> /dev/block/sda7
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.423333425 -0500 modem_b -> /dev/block/sda28
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.413333424 -0500 modemst1 -> /dev/block/sdd15
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.416666757 -0500 modemst2 -> /dev/block/sdd16
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.416666757 -0500 msadp_a -> /dev/block/sda15
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.426666758 -0500 msadp_b -> /dev/block/sda36
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.410000090 -0500 padding0 -> /dev/block/sda1
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.426666758 -0500 padding1 -> /dev/block/sda44
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:38.673333350 -0500 persist -> /dev/block/sdd3
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.430000092 -0500 pg1fs -> /dev/block/sde2
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.420000091 -0500 pg2fs -> /dev/block/sde3
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.406666756 -0500 pmic_a -> /dev/block/sda6
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.426666758 -0500 pmic_b -> /dev/block/sda27
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.416666757 -0500 ramdump -> /dev/block/sde1
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.420000091 -0500 reserve3 -> /dev/block/sdd18
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.433333426 -0500 reserve4 -> /dev/block/sde5
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.430000092 -0500 reserve5 -> /dev/block/sdf5
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.420000091 -0500 rpm_a -> /dev/block/sda3
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.413333424 -0500 rpm_b -> /dev/block/sda24
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.413333424 -0500 sec -> /dev/block/sdd7
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.420000091 -0500 splash -> /dev/block/sdd10
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.416666757 -0500 ssd -> /dev/block/sdd2
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.430000092 -0500 sti -> /dev/block/sdd14
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.413333424 -0500 storsec_a -> /dev/block/sda17
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.410000090 -0500 storsec_b -> /dev/block/sda38
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:38.670000016 -0500 system_a -> /dev/block/sda22
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.430000092 -0500 system_b -> /dev/block/sda43
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.430000092 -0500 toolsfv -> /dev/block/sdd12
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.423333425 -0500 trusty_a -> /dev/block/sda19
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.416666757 -0500 trusty_b -> /dev/block/sda40
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.420000091 -0500 tz_a -> /dev/block/sda4
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.416666757 -0500 tz_b -> /dev/block/sda25
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.403333423 -0500 userdata -> /dev/block/sda45
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:38.670000016 -0500 vbmeta_a -> /dev/block/sda18
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.426666758 -0500 vbmeta_b -> /dev/block/sda39
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:38.670000016 -0500 vendor_a -> /dev/block/sda20
lrwxrwxrwx 1 root root 16 1970-12-11 22:15:39.416666757 -0500 vendor_b -> /dev/block/sda41
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.430000092 -0500 xbl_a -> /dev/block/sdb1
lrwxrwxrwx 1 root root 15 1970-12-11 22:15:39.416666757 -0500 xbl_b -> /dev/block/sdc1
<
the.puppet.master said:
Yes, there is a thread for unlocking the bootloader but that is for a previous version. If anyone with root is running the factory image for Android 9.0, we are in need of a bit image dump. If you can follow the link below and just provide the dump, I am more than happy to do the rest.
From what I have been noticing, there may be a hidden command that is preventing us from getting further in unlocking the bootloader. Any help to either prove or disprove this theory would be greatly appreciated. In the meantime, I am syncing with the aosp repo provided by Google.
Your help could greatly speed up the process
https://www.xda-developers.com/how-to-discover-hidden-fastboot-commands
Thank you
Click to expand...
Click to collapse

I'm using the pixel 2 and have factory Android 9 /P . Unrooted and waiting for a way to unlock. What is it you need. And they were saying in the other thread if you took the ota to latest Android 9 there is no way it can be done. There will be a way and I know this ,maybe just a matter of time.

mattie_49 said:
I'm using the pixel 2 and have factory Android 9 /P . Unrooted and waiting for a way to unlock. What is it you need. And they were saying in the other thread if you took the ota to latest Android 9 there is no way it can be done. There will be a way and I know this ,maybe just a matter of time.
Click to expand...
Click to collapse
Sorry boss what he's looking for you can't offer, as you're not rooted. "If anyone with root is running the factory image for Android 9.0"
---------- Post added at 01:57 PM ---------- Previous post was at 01:54 PM ----------
@the.puppet.master did you get everything you needed? I'd be willing to update my Pix2 to 9.0 on stock to get what you need. I'm running an unlocked BL Pix2 on the July security patch. Since I mostly run stock, I'd be happy to assist... Just let me know...

b00ster23 said:
Sorry boss what he's looking for you can't offer, as you're not rooted. "If anyone with root is running the factory image for Android 9.0"
---------- Post added at 01:57 PM ---------- Previous post was at 01:54 PM ----------
@the.puppet.master did you get everything you needed? I'd be willing to update my Pix2 to 9.0 on stock to get what you need. I'm running an unlocked BL Pix2 on the July security patch. Since I mostly run stock, I'd be happy to assist... Just let me know...
Click to expand...
Click to collapse
We will surely have an unlock method before long correct? Since it's actually based off Htc I wonder if sunshine might be a route to unlock bootloader ? Actually just looked sunshine released a free tool for pixel /pixel XL called depixel8. Hopefully they will update for pixel 2. Wonder if it would even be worth a try on the 2. I don't think it would hurt anything . I'm almost willing to give it a go.

mattie_49 said:
We will surely have an unlock method before long correct? Since it's actually based off Htc I wonder if sunshine might be a route to unlock bootloader ? Actually just looked sunshine released a free tool for pixel /pixel XL called depixel8. Hopefully they will update for pixel 2. Wonder if it would even be worth a try on the 2. I don't think it would hurt anything . I'm almost willing to give it a go.
Click to expand...
Click to collapse
That exploit was patched in Android 7.1. You can try it, but it simply won't do anything at all. It will eventually happen, but at a standstill right now. I decompiled everything I could to find any other OEM fastboot commands, dialer codes, etc... Found a few unrelated things that, although still cool, did not aid in my quest to unlock the bootloader any.

crixley said:
That exploit was patched in Android 7.1. You can try it, but it simply won't do anything at all. It will eventually happen, but at a standstill right now. I decompiled everything I could to find any other OEM fastboot commands, dialer codes, etc... Found a few unrelated things that, although still cool, did not aid in my quest to unlock the bootloader any.
Click to expand...
Click to collapse
I've always needed to work on my patience anyway. Device is still amazing stock. Getting close to 2 days off charger and nearing 8 hours on screen. No complaints. Thanks for your response.

b00ster23 said:
Sorry boss what he's looking for you can't offer, as you're not rooted. "If anyone with root is running the factory image for Android 9.0"
---------- Post added at 01:57 PM ---------- Previous post was at 01:54 PM ----------
@the.puppet.master did you get everything you needed? I'd be willing to update my Pix2 to 9.0 on stock to get what you need. I'm running an unlocked BL Pix2 on the July security patch. Since I mostly run stock, I'd be happy to assist... Just let me know...
Click to expand...
Click to collapse
I haven't had time to do much of anything since posting this. I got hit with a heavy workload but I should be back on it the next few days. I'll post any findings I come across.
Thanks

the.puppet.master said:
I haven't had time to do much of anything since posting this. I got hit with a heavy workload but I should be back on it the next few days. I'll post any findings I come across.
Thanks
Click to expand...
Click to collapse
Pixel3 about to drop. Surely you guys will find the solution. Wish I knew more about it
So as to I could help.

Sorry to jump in the middle of the conversation. But if your looking for fastboot commands , there's plenty not mentioned anywhere. Using Linux I ran strings laf.img | grep OEM ,oem, etc. There's several lg commands. I even saw a command that , memory might be off, but it basically said skip check. May have printed it out. I'll post if so. Since there's no aboot.img as in previous Google phones I can only guess laf if the beholder now. It certainly hold a lot of info. Oddly I was able to extract it like a zip using 7z.
Sent from my Pixel 2 XL using Tapatalk

blueyes said:
Sorry to jump in the middle of the conversation. But if your looking for fastboot commands , there's plenty not mentioned anywhere. Using Linux I ran strings laf.img | grep OEM ,oem, etc. There's several lg commands. I even saw a command that , memory might be off, but it basically said skip check. May have printed it out. I'll post if so. Since there's no aboot.img as in previous Google phones I can only guess laf if the beholder now. It certainly hold a lot of info. Oddly I was able to extract it like a zip using 7z.
Click to expand...
Click to collapse
Your not interrupting anything . The op doesn't respond to anything. Oh well . It will be figured out. The matter is when

I'm surprised a year into this device none of the dozens of software masterminds haven't unlocked it. Every other Verizon phone seems to be getting unlocked, Samsung, LG. There's a couple sites saying that they can but using a drastic (might not get it back) system by essentially repartitioning it.
mattie_49 said:
Your not interrupting anything . The op doesn't respond to anything. Oh well . It will be figured out. The matter is when
Click to expand...
Click to collapse
Sent from my Pixel 2 XL using Tapatalk

blueyes said:
Sorry to jump in the middle of the conversation. But if your looking for fastboot commands , there's plenty not mentioned anywhere. Using Linux I ran strings laf.img | grep OEM ,oem, etc. There's several lg commands. I even saw a command that , memory might be off, but it basically said skip check. May have printed it out. I'll post if so. Since there's no aboot.img as in previous Google phones I can only guess laf if the beholder now. It certainly hold a lot of info. Oddly I was able to extract it like a zip using 7z.
Click to expand...
Click to collapse
You're on the xl and not regular pixel correct? I found a list of OEM fastboot commands for standard pixel, however a large portion did not work. I also researched and tried old HTC codes to see if perhaps they rehashed some. There was a fastboot command to get your unlock code, however entering it at htcdev does not work.

There's actually the same cmd to get pxl2s unlock code. Only useful after it's unlocked, same as the HTC. I have a OG xl, bought a Verizon 2xl thinking it'll be hacked as quickly as the OG. Just sold it on eBay, turned around and bought a Google version and didn't lose a dime.
crixley said:
You're on the xl and not regular pixel correct? I found a list of OEM fastboot commands for standard pixel, however a large portion did not work. I also researched and tried old HTC codes to see if perhaps they rehashed some. There was a fastboot command to get your unlock code, however entering it at htcdev does not work.
Click to expand...
Click to collapse
Sent from my Pixel 2 XL using Tapatalk
https://drive.google.com/file/d/1mE2IgQ8_Gc4HdyeJjHQDuLTtEZxHkJWf/view?usp=drivesdk
Printed up some of the cmds
---------- Post added at 03:13 PM ---------- Previous post was at 02:52 PM ----------
I think these guys could do it , if you read their posts. True hackers, borderline criminals. Lol
https://sinister.ly/Thread-Google-Pixel-2-XL-IMEIs-Verizon-GS

blueyes said:
There's actually the same cmd to get pxl2s unlock code. Only useful after it's unlocked, same as the HTC. I have a OG xl, bought a Verizon 2xl thinking it'll be hacked as quickly as the OG. Just sold it on eBay, turned around and bought a Google version and didn't lose a dime.
Sent from my Pixel 2 XL using Tapatalk
https://drive.google.com/file/d/1mE2IgQ8_Gc4HdyeJjHQDuLTtEZxHkJWf/view?usp=drivesdk
Printed up some of the cmds
---------- Post added at 03:13 PM ---------- Previous post was at 02:52 PM ----------
I think these guys could do it , if you read their posts. True hackers, borderline criminals. Lol
https://sinister.ly/Thread-Google-Pixel-2-XL-IMEIs-Verizon-GS
Click to expand...
Click to collapse
**SCRATCH MY ORIGINAL RESPONSE, I TOOK A CLOSER LOOK WHILE I'M AT WORK**
I see what you mean, those are not commands however in the sense that we can enter them ourselves. We need to find a way to spoof the initial check that starts the provision, or use one of these ideas:
1.) fastboot oem get_identifier_token - this would be hard as it would require either breaking htcs method of creating unlock.bin files, or finding a way to sign them after tampering.
2.)fastboot oem readconfig/writeconfig. In order to use this we would need to figure out which bit is the "secure" bit. I believe writeconfig actually works on our device

crixley said:
Are you referring to "Bootloader OEM.txt"? That has nothing to do with the bootloader at all and is actually referencing wifi from what I can see. "OEM" does not necessarily refer to the bootloader, but qualcomm, etc.. as well.
Click to expand...
Click to collapse
Can't believe it's been like this since March. Maybe the sunshine people will find a new way

mattie_49 said:
Can't believe it's been like this since March. Maybe the sunshine people will find a new way
Click to expand...
Click to collapse
Feel free to help out. I've spent hours and hours on top of late nights at a busy engineering firm and two children. A lot of the exploits have been figured out by near luck. It takes a lot of time and effort, and unfortunately pixel devices are not as developer supported as nexus ones were.
The fact that we are even in this situation and that google even allows verizon to run the show is frustrating enough.

crixley said:
Feel free to help out. I've spent hours and hours on top of late nights at a busy engineering firm and two children. A lot of the exploits have been figured out by near luck. It takes a lot of time and effort, and unfortunately pixel devices are not as developer supported as nexus ones were.
The fact that we are even in this situation and that google even allows verizon to run the show is frustrating enough.
Click to expand...
Click to collapse
I wish I knew where to even begin helping. I know quite a bit but my knowledge is all about after the bootloader is already unlocked. Sorry didn't mean for it to sound pushy. Didn't mean it like that. I have a new baby as well. Life comes first for sure

mattie_49 said:
I wish I knew where to even begin helping. I know quite a bit but my knowledge is all about after the bootloader is already unlocked. Sorry didn't mean for it to sound pushy. Didn't mean it like that. I have a new baby as well. Life comes first for sure
Click to expand...
Click to collapse
I didn't mean to be rude either, you seem like a nice guy it is just that honestly it is the best way to get something done. I have been using android a long time and learned through practice and a ton of reading. Sometimes it is the only way you'll see any results.
I thought of something else as well as a possible solution:
Since our chips are qualcomm, we could try finding the firehose files for our device and use qloader/qpst to write directly to the partition, or even just as an easy method to provide folks on here to flash android version back to when lock_critical worked (some sort of a command line tool perhaps?)

MAGISK - How do i proceed in this situation?

Phone: TCL C5 with Android 8.1
i have tested mtk-su and it works
i can make a copy of the boot partition and everything
i have unlocked the bootloader
for some reason i have 2 boot files ( or more )
lrwxrwxrwx 1 root root 21 2020-12-03 16:24 boot -> /dev/block/mmcblk0p31
lrwxrwxrwx 1 root root 21 2020-12-03 16:24 boot2 -> /dev/block/mmcblk0p32
lrwxrwxrwx 1 root root 20 2020-12-03 16:24 boot_para -> /dev/block/mmcblk0p3
lrwxrwxrwx 1 root root 23 2020-12-03 16:24 preloader_a -> /dev/block/mmcblk0boot0
lrwxrwxrwx 1 root root 23 2020-12-03 16:24 preloader_b -> /dev/block/mmcblk0boot1
i don't know what is going on here but i can patch boot and boot2 with magisk
the files goes from 24 MB to 7.7 MB so i think this is kinda weird
i want to know how i can make a good backup of everything before trying to flash anything
so i can prevent bootloop
and i want to know if there is any way to test the boot.img before flashing it
if not i would like some help to backup everything before flashing it
i patch the boot.img and try doing "fastboot boot boot.img"
but the magisk manager doesn't show installed or anything so i don't think "fastboot boot" works in this situation
is there anything i can do to be sure before flashing?
Update: seems like i only need boot and boot2
maybe patching both and flashing it?
seems a little risky, they both are the same file with the same md5sum hash