Lekensteyn
[linux][H815] LGLAF.py: WARNING: Command failed with error code 0x8000010a
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?
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
# 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....
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'
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
```
# ./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! :)
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'
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
# ./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
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
# ./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?
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.
# ./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
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
I've a .pcap file, but I'm not able to dissect it, Would you be so kind to give it a look?
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
Any news on this feature? This tool has distinctly lower value until this gets fixed/worked around.
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)
@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?
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
@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.
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.
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
@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.
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
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
@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....
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...
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?
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
