[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. :frowning:

@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. :smile: 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]

Its kind of like a challenge/response protocol with mode setting. CENT issues a 4 byte response in 'arg2' position from the device, then the PC sends METR with a body consisting of static 16 byte sequence encrypted by ^combining the CENT response with another static value for a key. KILO METR 'arg3' sets a 'mode', 0x2 before EXEC and OPEN, and 0x4 right before CLSE, presumably to auth the issuance of these commands to avoid the 0x8000010a path.

Doesn't seem to be device specific, at least not on the few devices I looked at provided devices have been updated somewhat recently - though if I understand what I've looked at correctly EXEC is meant to be more limited in the commands it can do these days. Early stopgap against send_command and the sh scripts they were using to root is documented in IJCSIS Vol. 14, No. 3, March 2016. Clearly solving this simple riddle will invite a response, possibly negative from both sides (plausibly increased security, people irked because they were holding onto this info hoping it to be useful later).

For what its worth, I was looking to corrupt my laf partition using this but have since found out that affected devices (locked bootloader) are locked in such a way that accessing the bootloader forcefully won't help any. The things we won't do to actually own the things we buy...

[ehem]

Should have commented explicitly, but I would have been very surprised if it wasn't challenge-response. Problem is we know very little about what algorithms are being used, nor what the secrets are. Depending upon the implementation there could be many flaws which can be attacked. I suspect the secret and algorithm are embedded inside the "LGUP_c" library included in KDZ files, but I've no idea what calls to make nor even how to load them. The modern ones include both a Windows DLL and MacOS dylib versions (no idea which is easier to load).

An alternative is it looks entirely possible to do a Man in the Middle attack on their update tool, run one of LG's tools inside a VM then forward commands until we've got full access to the phone. Anyone know how to interface with Qemu and fake access?

[snoremaster3000]

I have an LG Nexus 5X which has the challenge response requirement for laf. What I did as a temporary fix is download the flash tool for my phone here: http://forum.xda-developers.com/nexus-5x/help/req-help-to-unbrick-t3251740 and then ran the tool in a debugger setting a breakpoint right after the challenge-response code and then I simply hit "flash". Once I hit my breakpoint I just kill the process and I'm good to go. To figure out where the end of the challenge-response function is I had to do a bit of poking around with IDA (Hint: search for "push 544e4543h", bottom of that subroutine is where to stop) . For me it's in a dll called 8994_DLL.dll (here mega:#!h5oUmZiR!l-L3fhvVofiIanZODWSCvr7eUjhlbxBy9bbVvFVGu0A) which is used by the flash tool to generate all of the requests. I think 8994 refers to the chipset (as in msm8994 quaalcom snapdragon).

This of course only helps if you can find either find a working flash tool for their phone or else borrow someone's phone with a msm8994 chipset (you can use it to start the flash tool, set a break point at the beginning and end of the routine, hit "Flash", swap phones, Continue, exit..)

Anyways here's the dll, the routine in question starts at 0x10006890 (Set Content-Type to application/octet-stream in response headers, sorry filetype restrictions) or go here mega:#!h5oUmZiR!l-L3fhvVofiIanZODWSCvr7eUjhlbxBy9bbVvFVGu0A

[Lekensteyn]

Sorry for not replying earlier, stil haven't had the chance to look into detail with the provided information. Thanks for supplying the details folks!

@ehem For USB monitoring with QEMU, perhaps this (older) article can help: https://lekensteyn.nl/logitech-unifying.html#preparing-qemu

[marioemp2k7]

@snoremaster3000 I'm not quite sure what did you achieve by doing this. Were you succesfully able to gain root priviliges? Meaning, after the challenge response, were you able to use this tool? Thanks.

[snoremaster3000]

@marioemp2k7 Yes I can use the laf protocol after authenticating, but the EXEC command is now more limited. It only executes ls and ps commands. However you can still use WRTE and READ so these limitations don't do much for security since you can just overwrite the laf partition with a custom packed one with either an old laf binary or adb enabled, etc. Note WRTE using this tool was really slow. took about 8 hrs to overwrite the entire flash memory of my 16GB Nexus. READ is much faster not sure why this is.

[marioemp2k7]

@snoremaster3000 It seems that there are still things that I don't quite get. Would you mind taking this discussion in private? I'm currently locked because of an corrupt EFS restore coupled with a tot load which locked the bootloader. At this point I need either write the persistent partition in order to unlock the bootloader or to erase modemst1 and 2 partitions which in theory should get me past the boot loop. Thanks!

[snoremaster3000]

@marioemp2k7 Sure, I just published my email on my profile.

[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 :disappointed: 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 :smile: 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 :+1:

[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 https://github.com/Lekensteyn/lglaf/pull/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