[linux][H815] LGLAF.py: WARNING: Command failed with error code 0x8000010a

[mocolini]

Hallo,
I'm trying to use your tool, but once I gained the root shell in download mode, each commant ends up with "LGLAF.py: WARNING: Command failed with error code 0x8000010a"

# python lglaf.py
LGLAF.py by Peter Wu (https://lekensteyn.nl/lglaf)
Type a shell command to execute or "exit" to leave.
# ls
LGLAF.py: WARNING: Command failed with error code 0x8000010a
# dir
LGLAF.py: WARNING: Command failed with error code 0x8000010a
# pwd
LGLAF.py: WARNING: Command failed with error code 0x8000010a

and the same if I pipe the command

# echo mount | python lglaf.py
LGLAF.py: WARNING: Command failed with error code 0x8000010a

System specs:
S.O.: Slackware linux "-current"
Python: 2.7.11
PyUsb: 1.0.0rc1
/etc/udev/rules.d/42-usb-lglaf.rules: 42-usb-lgaf.rules.txt
LG G4 (H815)

Any hint?

[Lekensteyn]

So your USB stack is working fine, but the device is somehow reporting an error in response to the command (on the LAF protocol level).

Do other operations work? For example:

lglaf.py -c '!INFO GPRO \x08\x0b\0\0' > props.bin
python scripts/parse-props.py props.bin

[mocolini]

# python lglaf.py -c '!INFO GPRO \x08\x0b\0\0' > props.bin
# python scripts/parse-props.py props.bin 
download cable             = '633A'
battery level              = 23
download type              = ' '
download speed             = 0
usb version                = 'UHS'
hardware revision          = 'rev_10'
download sw version        = ' '
device sw version          = 'H81520d'
secure device              = 'S'
laf sw version             = '1.1'
device factory version     = 'LGH815AT-00-V20d-EUR-XX-JAN-15-2016+0'
device factory out version = 'LGH815AT-00-V20d-OPT2-HQ-JAN-15-2016+0'
pid                        = 'HD56S160123002147'
imei                       = 'xxxxxxxxxxxxxxxxx'
model name                 = 'LG-H815'
device build type          = 'U'
chipset platform           = 'msm8992'
target_operator            = 'GLOBAL'
target_country             = 'COM'
ap_factory_reset_status    = 6
cp_factory_reset_status    = 0
isDownloadNotFinish        = 0
qem                        = 0
cupss swfv                 = 'A1452849951-M1452849951-C1452853727-U1439812579-1'
is one binary dual plan    = 0
memory size                = 61071360
memory_id                  = '032G74\n'
bootloader_ver             = 'MiniOS 3.0'

It seems working....

[mocolini]

Also reboot works

# ./lglaf.py  --debug -c '!CTRL RSET'
LGLAF.py: DEBUG: Using endpoints 83 (IN), 02 (OUT)
LGLAF.py: DEBUG: Hello done, proceeding with commands
LGLAF.py: DEBUG: Header: 'CTRL' 'RSET' '\0\0\0\0' '\0\0\0\0' '\0\0\0\0' '\0\0\0\0' '\xc7\xeb\0\0' 
'\xbc\xab\xad\xb3'

[Lekensteyn]

What about direct command invocation:

./lglaf.py --debug -c '!EXEC ls\0'

Aside, you can mark a whole block as code with this markup:

```
output here
```

[mocolini]

# ./lglaf.py --debug -c '!EXEC ls\0'
LGLAF.py: DEBUG: Using endpoints 83 (IN), 02 (OUT)
LGLAF.py: DEBUG: Hello done, proceeding with commands
LGLAF.py: WARNING: Header field requires a DWORD, got str 'ls\x00'
Traceback (most recent call last):
  File "./lglaf.py", line 390, in main
    payload = command_to_payload(command)
  File "./lglaf.py", line 360, in command_to_payload
    return make_request(command, args, body)
  File "./lglaf.py", line 101, in make_request
    set_header(4 * (i + 1), arg)
  File "./lglaf.py", line 95, in set_header
    (type(val).__name__, val)
AssertionError: Header field requires a DWORD, got str 'ls\x00'

Aside: thank you very much, I was trying to figure out the right way!
:)

[Lekensteyn]

Ooh, actually, try two spaces between EXEC and ls. Otherwise it is misinterpreted as argument (see https://github.com/Lekensteyn/lglaf#advanced-usage)

./lglaf.py --debug -c '!EXEC  ls\0'

[mocolini]

A more question: why "lsusb" give me different results when devices is in "download mode" or "mtp"

Download Mode

Bus 001 Device 021: ID 1004:633a LG Electronics, Inc. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0        64
  idVendor           0x1004 LG Electronics, Inc.
  idProduct          0x633a 
  bcdDevice            3.10
  iManufacturer           1 
  iProduct                2 
  iSerial                 3 
  bNumConfigurations      1

"MTP" mode

Bus 001 Device 024: ID 1004:633e LG Electronics, Inc. G2 Android Phone [MTP mode]
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x1004 LG Electronics, Inc.
  idProduct          0x633e G2 Android Phone [MTP mode]
  bcdDevice            3.10
  iManufacturer           1 LG Electronics Inc.
  iProduct                2 LGE Android Phone
  iSerial                 3 LGH815bb854bd5
  bNumConfigurations      2

[mocolini]

# ./lglaf.py --debug -c '!EXEC  ls\0'
LGLAF.py: DEBUG: Detaching kernel driver for intf 0
LGLAF.py: DEBUG: Using endpoints 83 (IN), 02 (OUT)
LGLAF.py: DEBUG: Hello done, proceeding with commands
LGLAF.py: WARNING: Command failed with error code 0x8000010a
Traceback (most recent call last):
  File "./lglaf.py", line 391, in main
    header, response = comm.call(payload)
  File "./lglaf.py", line 176, in call
    raise RuntimeError('Command failed with error code %#x' % errCode)
RuntimeError: Command failed with error code 0x8000010a

Same error code exit

[Lekensteyn]

Devices can advertise different interfaces as they like (after a reset that is).

Hmm, perhaps LG noticed about this loophole and patched it. Your firmware is from this January of this year while I tested it with firmware from last August. What you could try is to open /proc/kmsg and read parts out of it (since it has no end of file, you might have to reboot the device once it reaches the end of the file).

Commands (replace X by the file descriptor that is returned by OPEN):

./lglaf.py --skip-hello --debug -c '!OPEN  /proc/kmsg\0'
for i in {1..100};do ./lglaf.py --skip-hello -c '!READ X,1,128'; done

[mocolini]

# ./lglaf.py --skip-hello --debug -c '!OPEN  /proc/kmsg\0'
LGLAF.py: DEBUG: Using endpoints 83 (IN), 02 (OUT)
LGLAF.py: WARNING: Command failed with error code 0x8000010a
Traceback (most recent call last):
  File "./lglaf.py", line 391, in main
    header, response = comm.call(payload)
  File "./lglaf.py", line 176, in call
    raise RuntimeError('Command failed with error code %#x' % errCode)
RuntimeError: Command failed with error code 0x8000010a

No way

About different "lsusb" output, it's strange the the device has two different "idProduct", isn't it?

[Lekensteyn]

Devices can pretty much advertise anything, even different idProducts. Some modems (and the OnePlusX for example) appear as mass-storage device, offering drivers to the host. After installing those drivers, the "normal" functionality becomes available.

Maybe the device now needs a special greeting. What if you try an invalid command (such as !ABCD)? Will it still give the same or a different error code?

If you feel like getting your hands dirty, consider finding the support tools for your phone (I forgot their names), set up a QEMU VM with USB-passthrough and record the USB communication. Then use the lglaf.lua Wireshark dissector in this repo for analysis of that communication. Hopefully it reveals the missing message.

[mocolini]

# ./lglaf.py  --debug -c '!ABCD'
LGLAF.py: DEBUG: Using endpoints 83 (IN), 02 (OUT)
LGLAF.py: DEBUG: Hello done, proceeding with commands
LGLAF.py: WARNING: [Errno 110] Operation timed out
Traceback (most recent call last):
  File "./lglaf.py", line 391, in main
    header, response = comm.call(payload)
  File "./lglaf.py", line 168, in call
    header = self.read(0x20)
  File "./lglaf.py", line 148, in read
    buff = self._read(need, timeout=timeout)
  File "./lglaf.py", line 256, in _read
    array = self.usbdev.read(self.ep_in, 2**14, timeout=timeout)
  File "/usr/lib64/python2.7/site-packages/usb/core.py", line 988, in read
    self.__get_timeout(timeout))
  File "/usr/lib64/python2.7/site-packages/usb/backend/libusb1.py", line 833, in bulk_read
    timeout)
  File "/usr/lib64/python2.7/site-packages/usb/backend/libusb1.py", line 936, in __read
    _check(retval)
  File "/usr/lib64/python2.7/site-packages/usb/backend/libusb1.py", line 595, in _check
    raise USBError(_strerror(ret), ret, _libusb_errno[ret])
USBError: [Errno 110] Operation timed out

I'll try to set up a QEMU VM during the week

[mocolini]

I had set up quemu wm with USB-passthrough, and downloaded LG mobile support tool, the tool sees the device,and how can I record the USB communication?

EDIT: ok, I've "sniffed" it using USBPcap

[mocolini]

I've a .pcap file, but I'm not able to dissect it, Would you be so kind to give it a look?

[dmaiolo]

Just wanted to note, I am following this as well. I have an LGVS425PP (LG Optimus Zone 3) and I am also receiving:

C:\Users\i5\Desktop\LG Flash Tool 2014\lglaf-master\lglaf-master>lglaf.py --debug -c "!EXEC  ls\0"
LGLAF.py: DEBUG: Using serial port: COM5
LGLAF.py: DEBUG: Hello done, proceeding with commands
LGLAF.py: WARNING: Command failed with error code 0x8000010a
Traceback (most recent call last):
  File "C:\Users\i5\Desktop\LG Flash Tool 2014\lglaf-master\lglaf-master\lglaf.py", line 391, in main
    header, response = comm.call(payload)
  File "C:\Users\i5\Desktop\LG Flash Tool 2014\lglaf-master\lglaf-master\lglaf.py", line 176, in call
    raise RuntimeError('Command failed with error code %#x' % errCode)
RuntimeError: Command failed with error code 0x8000010a

[ehem]

Any news on this feature? This tool has distinctly lower value until this gets fixed/worked around.

[ehem]

mocolini, I disclaim particular knowledge of USB, but I suspect I may be able to make some sense of that capture. There any chance you could post it somewhere accessible so various eyes could examine the capture? (I hope @Lekensteyn will be able to attack this, but I can make an attempt)

[Lekensteyn]

@mocolini I cannot find your pcap from April on my system and cannot recall whether I received it or not, can you share it again (possibly with @ehem too)?

Btw, I also received a user report about the "KILO" command on a LG V10 6.0 which apparently appears before the "OPEN" command, perhaps there is some magic sequence needed to get allowance?

[mocolini]

That's it...hope it helps.
Thank you all!
lg.zip

[ledzepman71]

I would simply like to report that I am having the exact same problem as mocolini and dmaiolo. If it helps, here is my lsusb output and props.bin
lsusb.txt
props.bin.txt

[Lekensteyn]

@mocolini I took a brief look at it, but it does not look like LAF traffic at all. The protocol data is six bytes, starting with a NUL byte and ending with a NUL byte. There seems to be a pattern in that traffic though, the 5th byte in frame 3 is 53 and it increases over time.

@ehem Can you have a further look at it? If you use Wireshark, right-click on "Leftover Capture Data" and use "Apply as Column", that helps with pattern spotting when scrolling over the list.

@ledzepman71 Thanks, it might become useful for comparing versions.

[ehem]

Looks like USB device 1 is either a keyboard or mouse, while USB device 2 is @mocolini's H815, notice frame 720. There is some traffic from the H815 in frames 592-722, but not enough to analyze and get things done. 😦

@mocolini any chance you could do a capture which starts before you plug in the USB cable to your device and then get the LG support tool to do something interesting? (what we really need is to observe it successfully doing some restricted operation)

Just in case it wasn't obvious, I'm running into this as well and I'd like to get this fixed so I can do interesting things to my device. 😄 Problem is if they did it right this will be difficult or even impossible to break.

I should also add, I'm dealing with a H962, so I'm guessing this will be an issue for all recent LG devices.

[mocolini]

Hallo, I've tried to capture something , but "LG Bridge" does non connect to the device.
Anyway I don't know if attached file have some useful information.
g4.zip

[ledzepman71]

@mocolini have you tried the LGUP tool?

The LG Mobile Support Tool ("LG Bridge") Ver 1.8.5.0 (windows 10 Ver 1511 build 10586.138) does identify my device and firmware version; however, there aren't any 'updates' or a stock kdz
for my phone. I hit update just to see if it captures anything useful though. At risk of overwhelming you with new data to sift through, here is the pcap.
lg_support_tool_pcap.zip

Also @Lekensteyn and @ehem, using Wireshark to analyze the pcap yields absolute gibberish to me. Is there anything specific you are looking for? I would like to help, but fear I lack the skill to contribute.

[mocolini]

Ok, I managed to make LG Bridge (and LGUP) working, give a look at this new attachment.
My devices is recognized by both the apps, and I've tried to complete some task (read the status of the device in LGUP and find new upgrade in LG Bridge) but, obviously, I don't know if the information "sniffed" are useful.
Thanks for your patience.
LG.zip

[lafd1]

Bellow you will find log files from LGFlash tool which includes the whole LAF protocol communication.
For LG G3 MM I have the same error while trying to run the EXEC command.
Looks like the only difference is that in Marshmallow before running EXEC, KILO CENT and KILO METR commands must be called. Hope that this helps.

LGUserCSTool_log_KK.txt
LGUserCSTool_log_MM.txt

[julianscheel]

@Lekensteyn have you had a chance to look at the lofs from lafd1?
The kilo metr message seems to have some body. Any clues what this should be like?
I tried to replicate the exact command from the MM log, but receive a FAIL as answer. As the log is from a LG G3 and I am running a G4 (H815) I think it might be device specific....

[joeblowma]

WRTE when used in official methods uses compression to send the data (given the correct args, typically it just feeds the raw/compressed dz/tot data which I'd assume is just lz or similarly compressed), which probably speeds it up quite a lot over sending just plain raw data.

Keep in mind too, there is an additional CENT METR "mode" issued before closing the flash handles, though hopefully rebooting via the laf commands would clean up any outstanding handles and related flushes.

I did solve and implement (in C, my python-ability sucks) the challenge response method before posting here previously, with even a basic shell for interactive exec then left it at that as its useless to me with a locked bootloader. The only real challenge I found was that my implementation of the crypto method was broken for that bit size and it took me a while to realize it. I prefer not to hoard, but to me this seems to be a beehive I'd rather not kick... making a standalone exe that just does the unlock would be trivial for one off private uses, or if the project maintainers want more info...

snoremaster3000: the 8994 dll is using the same method/magic bytes as the others I looked at, making me think this method is currently even more universal than I thought it would be on MM LG devices.

[snoremaster3000]

@joeblowma Are you able to get execution of binaries or file writes in your shell? My stock version of lafd is only allowing ls, ps, grep, mkdir, fota, gota, unmount, and dmesg. Can you characterize the crypto? Is it roll-your-own or a well-known algorithm? When I looked over the dissassembly I didn't see api calls in the area responsible for the challenge-response just a ton of math opcodes which quickly made my eyes hurt even when using a debugger to follow along.

[shadabmozaffar]

@joeblowma Can you please share CENT METR Auth Challenge?

I have been digging into it, and interestingly they have around more than 10 xor functions inside. Not sure though they used only 4 byte received by CENT to generate Auth Data sent with METR.

I am using delphi, and porting all these C output to it is hectic. It will be really appreciated if you can share it.

Br,

[joeblowma]

@snoremaster3000 as I said, they have severely limited the shell in these newer ones, my guess its mostly to mitigate the previous send_command tool though I'd bet there are ways around it as the parser is fairly primitive. I never explored it very far as having root in recovery mode does not get me root on a locked bootloader device, not even enough to see if it filters things like backspace escape key codes.

Its nothing complicated, basically just enough they might get away with calling it DRM and feeding lawyers' boat collections while persecuting customers. As I've said elsewhere, I'll not "own" (if you can even call it that) another LG device in my lifetime - they not only suck at security but simply won't let us take it into our own hands if the "carrier" says so.

@shadabmozaffar see all my previous statements for a clue as to why I didn't just dump it here the second I figured it out. I certainly wanted to...

[shadabmozaffar]

@joeblowma, i can see you mentioned that you solved, not in python but in C, but whatever is the language, it will be far better than those decompiled codes in iDA (which is also very nested, and i am unable to give much time to it as i am working on FireHose implementation also).

I am just hoping to get any code which solves that challenge so i can convert later to delphi or python.

Btw, i have not yet checked shell limitation on LAF ver. 0x10000003, yet i have own shell console written in delphi.

Br,

[ehem]

If download mode is implemented via "laf" then that is interesting news to me. The "laf" diskslice is an Android boot image, which means it can readily be unpacked and some analysis is possible. I'd be very careful about trying to overwrite it with an earlier version since it is almost certainly verified by hash or signature... (one interesting piece of news, they use MD5 in their KDZ files which is short enough to almost break on modern hardware with modern cryptographic techniques)

[miclass]

I am experiencing the same error with D855: 0x8000010a. I would like to retrieve the userdata partition from a device in bootloop, therefore I would be very interested in a solution of this issue.
Thank you very much for your effort, I hope to hear good news soon!

[snoremaster3000]

@ehem Yes download mode is on the laf partition, the service that we are communicating with here is lafd. Yes, you can unpack the laf partition and find the binary for analysis at ramdisk/sbin/lafd. You can replace this binary with an older version however it will of course fail the boot hash check which unlike the KDZ file is not md5 (it's done by dm-verity which uses RSA). However, for every device I've seen with Marshmallow or earlier, this hasn't mattered even with a locked bootloader because verified boot was not set to enforcing. One should definatley backup their laf partition prior to overwriting so if nessessary they can simply reflash the original image.
For more info on enforcing vs warning-only verified boot specifications see https://source.android.com/security/verifiedboot/verified-boot.html#recovering_from_dm-verity_errors

[Lekensteyn]

Through what mechanism do you want to reflash if LAF mode is broken (e.g. by broken signature)?

[shadabmozaffar]

I think LAF Signature Verification and shutdown things restrict only normal use of device.
You can still repair or full flash phone.

[snoremaster3000]

@Lekensteyn Good point, I'm so used to fastboot being available but I forget that many vendors remove or break it on purpose. However if it has a Qualcomm snapdragon you should still be able to reflash using QDLoader/QPST Config but this is definatley getting a little too close to the edge...

[vkulpa]

Hi there.
The same error for me with H791 and H790 devices.
This # ./lglaf.py --debug -c '!CTRL RSET' should give a WARNING b/c it's not only reboot. It's reset and it locked my bootloader 😞 On the H791 I had unlocked bootloader, twrp as recovery, rooted system and encrypted userdata partion. Fortunately, TWRP helped me to wipe data, system then I applied OTA via sideload and booted my phone 😄
lglaf.py -c '!INFO GPRO \x08\x0b\0\0' works. Here are my props.

download cable             = 'USER'
battery level              = 100
download type              = ' '
download speed             = 0
usb version                = 'UHS'
hardware revision          = ' '
download sw version        = ' '
device sw version          = 'LGH791AT-00-V10f-NXS-XXX-OCT-03-2015-16G-MDA89E-US'
secure device              = 'S'
laf sw version             = '1.2'
device factory version     = 'LGH791AT-00-V10f-NXS-XXX-OCT-03-2015-16G-MDA89E-US'
device factory out version = 'LGH791AT-00-V10k-NXS-XXX-OCT-27-2015-16G-FACTORY+0'
pid                        = 'BS---'
imei                       = '---'
model name                 = 'LGH791'
device build type          = 'UD'
chipset platform           = 'msm8992'
target_operator            = 'GOOGLE'
target_country             = 'GLOBAL'
ap_factory_reset_status    = 0
cp_factory_reset_status    = 238
isDownloadNotFinish        = 0
qem                        = 0
cupss swfv                 = 'FFFFFFFFFFF-FFFFFFFFFFF-FFFFFFFFFFF-U1445925097+0'
is one binary dual plan    = 0
memory size                = 30777344
memory_id                  = '016G72\n'
bootloader_ver             = 'MiniOS 3.0'

download cable             = 'USER'
battery level              = 10
download type              = ' '
download speed             = 0
usb version                = 'UHS'
hardware revision          = ' '
download sw version        = ' '
device sw version          = 'LGH790AT-00-V10f-NXS-XXX-OCT-03-2015-32G-MDA89E-US'
secure device              = 'S'
laf sw version             = '1.2'
device factory version     = 'LGH790AT-00-V10f-NXS-XXX-OCT-03-2015-32G-MDA89E-US'
device factory out version = 'LGH790AT-00-V10a-NXS-XXX-SEP-15-2015+0'
pid                        = 'BS---'
imei                       = '---'
model name                 = 'LGH790'
device build type          = 'UD'
chipset platform           = 'msm8992'
target_operator            = 'GOOGLE'
target_country             = 'GLOBAL'
ap_factory_reset_status    = 5
cp_factory_reset_status    = 0
isDownloadNotFinish        = 0
qem                        = 0
cupss swfv                 = 'FFFFFFFFFFF-FFFFFFFFFFF-FFFFFFFFFFF-U1442345344+0'
is one binary dual plan    = 0
memory size                = 61071360
memory_id                  = '032G74\n'
bootloader_ver             = 'MiniOS 3.0'

Also, maybe it helps. H790 and H791 have diff info in lsusb than lglaf.py expects

      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol      0 
      iInterface              0

P.S.: anyway it's a great tool and work done here 👍

[vinecodes]

Hi! Even I get the same error as mocolini in Windows 10. Using Python 3.6.0. Any solution for this?

Even
lglaf.py -c '!INFO GPRO \x08\x0b\0\0'
doesn't work.

[vkulpa]

Most likely, you need to authorize before using the commands. Take a look at #12

[lafd2]

@snoremaster3000 Thanks for the PR! Could you make the required changes as requested by lekensteyn so that it will be merged ?

Also, can anyone help with this command?
[Warning: it writes directly to the block device, it could brick your device]

python lglaf.py --unlock -c '!EXEC ls @dd if=/storage/external_SD/twrp.img of=/dev/block/mmcblk0 bs=8192 seek=18432 count=2048\0'

It should overwrite the recovery partition, but it seems that it's not persisted

[joeblowma]

You sure its not just restoring recovery from recovery.img? Back when I had a rootable device I remember that being a thing. Provided your "abuse" of ls actually does anything on the newer laf, that is.

[wchriseg]

maybe this will get you in the right direction :D
http://forum.gsmhosting.com/vbb/f83/lg-laf-kilometer-command-encryption-2218328/

[joeblowma]

@wchriseg that forum thread is basically discussing converting the python from pull request #12 (also mentioned a few posts above) of this project to delphi... not sure how that would help?

[RenaKunisaki]

Is this script working for anyone? My devices don't accept the response. Testing the challenge/response data linked earlier with both qndi and lgow keys, the result doesn't match, so I think it's not encrypting correctly? I also found changing the first half of the key doesn't affect the output at all, which seems like a bug.

I looked at a newer lafd, it looks like those keys are still the same, and lgow is only used for target operator "TRF" (whomever that is).

[joeblowma]

@RenaKunisaki did you check the pull request? Specifically, I recall it saying something about not working correctly out of the box with newer python versions and thus wasn't merged; I did my own poc in C (I don't do python well) and that worked fine.

As far as I could tell the second key was for devices that would be in the manufacturing pipeline, rather than consumer.

[shadabmozaffar]

@RenaKunisaki
I have converted this code to Delphi as soon as it was posted here and it works just fine.

[RenaKunisaki]

Ah, I thought that just meant it didn't work in Python 3. @joeblowma are you willing to share your C port?

I'd really like to figure out how to get it working in Python, but first I need to get it working at all.

[RenaKunisaki]

Wow, nevermind, I goofed. It works. Even got it working in Python 3, will submit a pull request soon.

[MrNerd]

Having this same issue on my Lg G6

https://forum.xda-developers.com/showpost.php?p=73197564&postcount=4

IF someone could kindly look for me and tell me what im doing wrong... im on Linux Debian

if you dont wanna see the link heres a small example of what i mean

./lglaf.py -c '!EXEC lsmod' LGLAF.py: WARNING: Command failed with error code 0x8000010a

[segin]

Hey @Lekensteyn - I managed to use a patched LGUP tool to do partition dumping with my phone. I dumped the smallest selectable "partition" (the first "PrimaryGPT", I believe /dev/block/sda's partition table) with it and generated this .pcap file:

My device is the T-Mobile G5 (H830) running the 20i update.

laf-h83020i.zip

[Lekensteyn]

Hey @segin, thanks for the pcap. Unfortunately I don't have time to look into it now, but maybe others with interest can look at it?

[shadabmozaffar]

@segin , You have correctly dumped partition table and what i can see there is your device has UFS file system which has 4KB sector and only a few partitions are there:
persistent
grow
last_parti

As it is UFS Filesystem, your device may have multiple LUN and userdata should be at LUN 0 and system etc should be on LUN 4.

[SpaceCadet-Code]

By attaching a debugger to LGUP I found a couple of new commands

INFOSPRO is called 4 times which by reading is setting some sort of properties

SIGN

SIGN is called twice before anything begins to work such as the OPEN or WRTE command and the response should be something like success cmd SIGN

I think this is the missing link as after this all commands are given with 2 kilocent commands then 2 kilometr commands in that order so possibly the SIGN command is important but also the fact that the kilocent command is given twice then the 2 kilometr responses are sent but that's just speculation. Let me know what you guys think

also two other commands that were found are

OPCMCHEK

MISCWRTE

EDIT: disregard the SIGN part seems this is more important

CHCKCLER is given twice before the exec command works it seems so new command there as well

I think CHCKCLER is our missing link. Disclaimer I am on the LG G5 but it has the same issue.

Debugged application message: [00:23:187] usb speed is high speed.
.
Debugged application message: [00:23:187] Not Support Fail Safe
.
Debugged application message: [00:23:187] Progress sleep for 1000 9 11
.
Debugged application message: [00:23:203] Set Progress 9
.
Debugged application message: [00:23:703] Set Progress 10
.
Debugged application message: [00:24:203] [T0000032] 43 48 43 4B 43 4C 45 52 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8C BA 00 00 BC B7 BC B4 CHCKCLER........................
.
Debugged application message: [00:24:203] [R0000032] 43 48 43 4B 43 4C 45 52 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 BC B7 BC B4 CHCKCLER........................
.
Debugged application message: [00:24:203] LAF_CMD_SUB_CLER.

.
Debugged application message: [00:24:203] DATA CHECK SUM ERROR device = 0 tool = 0

.
Debugged application message: [00:24:203] ==============Start Direct Download 2485MB ==============
.
Debugged application message: [00:24:218] umount system (/system)
.
Debugged application message: [00:24:218] [T0000032] 4B 49 4C 4F 43 45 4E 54 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E3 7B 00 00 B4 B6 B3 B0 KILOCENT.................{......
.
Debugged application message: [00:24:218] [R0000032] 4B 49 4C 4F 43 45 4E 54 90 A9 25 4A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B4 B6 B3 B0 KILOCENT..%J....................
.
Debugged application message: [00:24:218] [T0000048] 4B 49 4C 4F 4D 45 54 52 00 00 00 00 02 00 00 00 00 00 00 00 10 00 00 00 A3 07 00 00 B4 B6 B3 B0 KILOMETR........................
F4 7C 31 45 4C FF 58 73 0A D6 CB 7D 23 7B F0 17 .|1EL.Xs...}#{..
.
Debugged application message: [00:24:218] [R0000032] 4B 49 4C 4F 4D 45 54 52 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B4 B6 B3 B0 KILOMETR........................
.
Debugged application message: [00:24:218] [T0000047] 45 58 45 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0F 00 00 00 57 EC 00 00 BA A7 BA BC EXEC....................W.......
75 6D 6F 75 6E 74 20 2F 73 79 73 74 65 6D 00 umount./system.
.
Debugged application message: [00:24:234] [R0000032] 45 58 45 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0F 00 00 00 00 00 00 00 BA A7 BA BC EXEC............................
.
Debugged application message: [00:24:234] [T0000032] 4B 49 4C 4F 43 45 4E 54 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E3 7B 00 00 B4 B6 B3 B0 KILOCENT.................{......
.
Debugged application message: [00:24:234] [R0000032] 4B 49 4C 4F 43 45 4E 54 CA DB 0F 21 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B4 B6 B3 B0 KILOCENT...!....................
.
Debugged application message: [00:24:234] [T0000048] 4B 49 4C 4F 4D 45 54 52 00 00 00 00 02 00 00 00 00 00 00 00 10 00 00 00 6D 6D 00 00 B4 B6 B3 B0 KILOMETR................mm......
CB 74 3A 1A 43 2F 7D F9 DF 11 42 DC 7E 09 0A 8C .t:.C/}...B.....
.
Debugged application message: [00:24:234] [R0000032] 4B 49 4C 4F 4D 45 54 52 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B4 B6 B3 B0 KILOMETR........................
.
Debugged application message: [00:24:234] [T0000060] 45 58 45 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1C 00 00 00 17 2E 00 00 BA A7 BA BC EXEC............................
6D 6F 75 6E 74 20 2D 6F 20 72 65 6D 6F 75 6E 74 2C 72 6F 20 2F 73 79 73 74 65 6D 00 mount.-o.remount,ro./system.
.
Debugged application message: [00:24:234] [R0000032] 45 58 45 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 23 00 00 00 00 00 00 00 BA A7 BA BC EXEC................#...........
.
Debugged application message: [00:24:234] /system Unmount Success.
.
Debugged application message: [00:24:234] Erase Partition name : system, sector addr : 0xE886, size(sector count) : 0x120000