[T-Mobile LG G6 Guides, News, & Discussion] Rollerz70:
So here's what I now as of now regarding "firmware update mode" / lglaf / lafd. This is mostly confirmation of what many of you already know or suspect.

First, bear in mind the goal is to get around dm-verity with an unlocked bootloader and no fastboot commands. In other words, exploit a backdoor somehow, as originally stated in the first post of this thread.

The premise of my meanderings revolve around the lglaf tool, which communicates with /sbin/lafd when the phone is booted into "firmware update mode."

Getting lglaf to work with the G6

See the earlier post in this thread by [MENTION=2212173]hendusoone[/MENTION] where he was kind enough to update the tool with a python3-friendly version of the --unlock switch. For this work on the G6, you need to use the key provided by [MENTION=7479791]Honestly Annoying[/MENTION]. You'll want to make this change to use the key:

Comment out line 403 of the [MENTION=2212173]hendusoone[/MENTION] modified lglaf script and replace it as such:

Code:

403:	# key2 = 'qndiakxxuiemdklseqid~a~niq,zjuxl' # if this doesnt work try 'lgowvqnltpvtgogwswqn~n~mtjjjqxro'

404:	key2 = 'dqoev)ohnsWu\\bk`oiicmZ_lpqe\\ealp'

What you can do

You can then, from what I can tell, issue only some EXEC commands. The only commands I successfully executed were:

ps

/system/bin/ls

/system/bin/lsof

Note that ls and lsof did require the path to the executable.

As an example of how to execute commands, check out a couple of lines of output from a "ps":

Code:

# python lglaf.py --skip-hello --unlock -c "!EXEC psl\0"

USER PID PPID VSIZE RSS WCHAN PC NAME

...

root 449 1 911328 46752 hrtimer_na 00004fbef4 S /sbin/lafd

...

root 592 449 9220 1852 0 72c7dc2f28 R ps

It appears that the "shell" is via /sbin/lafd.

I did not attempt, but apparently it is still possible to use the WRTE command. However, without having the bootloader unlocked, this could spell disaster.

The hunt for /sbin/lafd

As I mentioned above, your "shell" is /sbin/lafd. So I followed that lead... A bit.

Grab the partition img files provided in another thread by [MENTION=2684188]autoprime[/MENTION] and make sure you have bootimg tools as well.

When you split out the boot.img and extract the ramdisk, you will notice that what you see is quite different from what you see in firmware upgrade mode. You will also not find the /sbin/lafd executable.

For those who weren't aware, the laf.img file is a boot img that is used instead of boot.img when booting in firmware upgrade mode. Split that file and extract that ramdisk, and you will then see the same root partition as you see when using lglaf.

Code:

# split_boot laf.img

Page size: 4096 (0x00001000)

Kernel size: 15014428 (0x00e51a1c)

Ramdisk size: 14262347 (0x00d9a04b)

Second size: 0 (0x00000000)

Board name:

Command line: 'console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 user_debug=31 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 cma=32M@0-0xffffffff androidboot.hardware=lucye'

Base address: (0x81ffff00)

Writing laf/laf.img-kernel ... complete.

Writing laf/laf.img-ramdisk.cpio.gz ... complete.

Unpacking ramdisk... complete.

Inside your partition, which is probably now in laf/ramdisk/, you will find /sbin/lafd (I am referring to / as the root of your extracted ramdisk).

My Dead End?

I should say that I'm a networking guy. So everything I'm doing here can all be relegated to the domain of a hobby. I could very well have been looking right at the golden key and not realized it. So I will leave the really deep-dive analysis to the experts.

So you now have the ability to mess with the various files of interest in /sbin in the laf.img. You will also find equally interesting kernel modules in /vendor/modules. Particularly interesting is /vendor/modules/g_laf.ko.

You'll know you're in the right place when you find your frustrating "error message":

Code:

# strings sbin/lafd | grep 'Nice to meet you'

Hello, I am LAF. Nice to meet you.

I had more success using lldb and its various tools than I did with gdb, objdump, etc.

All this being said, I pretty much ran into a dead end. It seems there are very few commands:

Code:

# llvm-objdump -t vendor/modules/g_laf.ko | grep 'l F'

0000000000000000 l F .text 00000080 laf_release

0000000000000098 l F .text 000000a4 laf_open

0000000000000000 l F .exit.text 00000050 laf_unbind

0000000000000158 l F .text 00000298 laf_read

0000000000000000 l F .init.text 000000e0 laf_bind

0000000000000118 l F .init.text 00000194 laf_do_config

00000000000003f8 l F .text 00000064 laf_function_disable

000000000000045c l F .text 00000048 laf_complete_out

00000000000004b0 l F .text 000000d4 laf_function_set_alt

00000000000006a0 l F .text 00000150 laf_function_bind

0000000000000ac8 l F .text 000000c0 laf_function_unbind

0000000000000584 l F .text 00000068 laf_request_new.constprop.6

0000000000000640 l F .text 00000054 laf_complete_in

0000000000000894 l F .text 00000228 laf_write

0000000000000330 l F .init.text 00000028 laf_mod_init

0000000000000070 l F .exit.text 00000028 laf_mod_cleanup

And the "strings" are generally uninteresting except for maybe:

Code:

# strings sbin/lafd | grep ^laf_cmd

laf_cmd_find

laf_cmd_process

laf_cmd_hello_proc

laf_cmd_fail_proc

laf_cmd_close_proc

laf_cmd_write_proc

laf_cmd_checksum_proc

laf_cmd_execute_proc

laf_cmd_reserved_proc

laf_cmd_erase_proc

laf_cmd_info_proc

laf_cmd_control_proc

laf_cmd_misc_proc

laf_cmd_kilo_proc

laf_cmd_diff_proc

laf_cmd_crc_proc

laf_cmd_thermal_engine_proc

laf_cmd_copy_proc

laf_cmd_opcommand_proc

laf_cmd_sniff_proc

laf_cmd_set_ufs_boot_lun_proc : Is Not UFS

laf_cmd_set_ufs_boot_lun_proc

laf_cmd_sign_proc

laf_cmd_write_zero_proc

laf_cmd_manipulateBootPT_proc - Failed to set PTEList

laf_cmd_manipulateBootPT_proc

laf_cmd_rollbackGPT_proc

laf_cmd_rollbackGPT_proc

laf_cmd_rollbackGPT_proc - Failed to set PTEList

laf_cmd_rollbackGPT_proc Fail

laf_cmd_write_mtk_boot_unlock_proc

laf_cmd_webdload_proc

laf_cmd_testmode_proc

I hope this was enough to maybe spark some ideas and someone can pick up where I left off.

----------------------------------------------------------'-------

Ok this was originally posted on the 2nd page of this thread. I started a new thread the other day that was talking about using ADB as a possible way to gain root by diasbling dm-verify. The info that I posted in my thread was not my work as I put a link in my thread but will just put a link to my thread in here.

https://xdaforums.com/tmobile-g6/how-to/to-make-adb-root-t3763013

---------- Post added at 01:17 AM ---------- Previous post was at 01:16 AM ----------

So here's what I now as of now regarding "firmware update mode" / lglaf / lafd. This is mostly confirmation of what many of you already know or suspect.

First, bear in mind the goal is to get around dm-verity with an unlocked bootloader and no fastboot commands. In other words, exploit a backdoor somehow, as originally stated in the first post of this thread.

The premise of my meanderings revolve around the lglaf tool, which communicates with /sbin/lafd when the phone is booted into "firmware update mode."

Getting lglaf to work with the G6

See the earlier post in this thread by [MENTION=2212173]hendusoone[/MENTION] where he was kind enough to update the tool with a python3-friendly version of the --unlock switch. For this work on the G6, you need to use the key provided by [MENTION=7479791]Honestly Annoying[/MENTION]. You'll want to make this change to use the key:

Comment out line 403 of the [MENTION=2212173]hendusoone[/MENTION] modified lglaf script and replace it as such:

Code:

403:	# key2 = 'qndiakxxuiemdklseqid~a~niq,zjuxl' # if this doesnt work try 'lgowvqnltpvtgogwswqn~n~mtjjjqxro'

404:	key2 = 'dqoev)ohnsWu\\bk`oiicmZ_lpqe\\ealp'

What you can do

You can then, from what I can tell, issue only some EXEC commands. The only commands I successfully executed were:

ps

/system/bin/ls

/system/bin/lsof

Note that ls and lsof did require the path to the executable.

As an example of how to execute commands, check out a couple of lines of output from a "ps":

Code:

# python lglaf.py --skip-hello --unlock -c "!EXEC psl\0"

USER PID PPID VSIZE RSS WCHAN PC NAME

...

root 449 1 911328 46752 hrtimer_na 00004fbef4 S /sbin/lafd

...

root 592 449 9220 1852 0 72c7dc2f28 R ps

It appears that the "shell" is via /sbin/lafd.

I did not attempt, but apparently it is still possible to use the WRTE command. However, without having the bootloader unlocked, this could spell disaster.

The hunt for /sbin/lafd

As I mentioned above, your "shell" is /sbin/lafd. So I followed that lead... A bit.

Grab the partition img files provided in another thread by [MENTION=2684188]autoprime[/MENTION] and make sure you have bootimg tools as well.

When you split out the boot.img and extract the ramdisk, you will notice that what you see is quite different from what you see in firmware upgrade mode. You will also not find the /sbin/lafd executable.

For those who weren't aware, the laf.img file is a boot img that is used instead of boot.img when booting in firmware upgrade mode. Split that file and extract that ramdisk, and you will then see the same root partition as you see when using lglaf.

Code:

# split_boot laf.img

Page size: 4096 (0x00001000)

Kernel size: 15014428 (0x00e51a1c)

Ramdisk size: 14262347 (0x00d9a04b)

Second size: 0 (0x00000000)

Board name:

Command line: 'console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 user_debug=31 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 cma=32M@0-0xffffffff androidboot.hardware=lucye'

Base address: (0x81ffff00)

Writing laf/laf.img-kernel ... complete.

Writing laf/laf.img-ramdisk.cpio.gz ... complete.

Unpacking ramdisk... complete.

Inside your partition, which is probably now in laf/ramdisk/, you will find /sbin/lafd (I am referring to / as the root of your extracted ramdisk).

My Dead End?

I should say that I'm a networking guy. So everything I'm doing here can all be relegated to the domain of a hobby. I could very well have been looking right at the golden key and not realized it. So I will leave the really deep-dive analysis to the experts.

So you now have the ability to mess with the various files of interest in /sbin in the laf.img. You will also find equally interesting kernel modules in /vendor/modules. Particularly interesting is /vendor/modules/g_laf.ko.

You'll know you're in the right place when you find your frustrating "error message":

Code:

# strings sbin/lafd | grep 'Nice to meet you'

Hello, I am LAF. Nice to meet you.

I had more success using lldb and its various tools than I did with gdb, objdump, etc.

All this being said, I pretty much ran into a dead end. It seems there are very few commands:

Code:

# llvm-objdump -t vendor/modules/g_laf.ko | grep 'l F'

0000000000000000 l F .text 00000080 laf_release

0000000000000098 l F .text 000000a4 laf_open

0000000000000000 l F .exit.text 00000050 laf_unbind

0000000000000158 l F .text 00000298 laf_read

0000000000000000 l F .init.text 000000e0 laf_bind

0000000000000118 l F .init.text 00000194 laf_do_config

00000000000003f8 l F .text 00000064 laf_function_disable

000000000000045c l F .text 00000048 laf_complete_out

00000000000004b0 l F .text 000000d4 laf_function_set_alt

00000000000006a0 l F .text 00000150 laf_function_bind

0000000000000ac8 l F .text 000000c0 laf_function_unbind

0000000000000584 l F .text 00000068 laf_request_new.constprop.6

0000000000000640 l F .text 00000054 laf_complete_in

0000000000000894 l F .text 00000228 laf_write

0000000000000330 l F .init.text 00000028 laf_mod_init

0000000000000070 l F .exit.text 00000028 laf_mod_cleanup

And the "strings" are generally uninteresting except for maybe:

Code:

# strings sbin/lafd | grep ^laf_cmd

laf_cmd_find

laf_cmd_process

laf_cmd_hello_proc

laf_cmd_fail_proc

laf_cmd_close_proc

laf_cmd_write_proc

laf_cmd_checksum_proc

laf_cmd_execute_proc

laf_cmd_reserved_proc

laf_cmd_erase_proc

laf_cmd_info_proc

laf_cmd_control_proc

laf_cmd_misc_proc

laf_cmd_kilo_proc

laf_cmd_diff_proc

laf_cmd_crc_proc

laf_cmd_thermal_engine_proc

laf_cmd_copy_proc

laf_cmd_opcommand_proc

laf_cmd_sniff_proc

laf_cmd_set_ufs_boot_lun_proc : Is Not UFS

laf_cmd_set_ufs_boot_lun_proc

laf_cmd_sign_proc

laf_cmd_write_zero_proc

laf_cmd_manipulateBootPT_proc - Failed to set PTEList

laf_cmd_manipulateBootPT_proc

laf_cmd_rollbackGPT_proc

laf_cmd_rollbackGPT_proc

laf_cmd_rollbackGPT_proc - Failed to set PTEList

laf_cmd_rollbackGPT_proc Fail

laf_cmd_write_mtk_boot_unlock_proc

laf_cmd_webdload_proc

laf_cmd_testmode_proc

I hope this was enough to maybe spark some ideas and someone can pick up where I left off.

----------------------------------------------------------'-------

Ok this was originally posted on the 2nd page of this thread. I started a new thread the other day that was talking about using ADB as a possible way to gain root by diasbling dm-verify. The info that I posted in my thread was not my work as I put a link in my thread but will just put a link to my thread in here.

https://xdaforums.com/tmobile-g6/how-to/to-make-adb-root-t3763013