14:11:00.493 LG-VX10000: Reading group information
14:11:00.493 LG-VX10000: sendbrewcommand Data - 7 bytes
<#! phones.p_lg.ULReq !#>
00000000 fe 00 00 00 00 00 00 .......

14:11:00.529 LG-VX10000: brew response Data - 24 bytes
<#! phones.p_lg.ULRes !#>
00000000 fe 02 f3 b2 77 11 01 00 de 00 00 00 30 00 00 00
....w.......0...
00000010 c0 1f 00 00 ff ff 00 aa ........

14:11:00.540 LG-VX10000: sendbrewcommand Data - 7 bytes
<#! phones.p_lg.ULReq !#>
00000000 fe 01 6b 1f 05 80 00 ..k....

14:11:00.638 LG-VX10000: brew response Data - 24 bytes
<#! phones.p_lg.ULRes !#>
00000000 fe 01 f3 b2 77 11 00 5d de 00 00 00 30 00 00 00
....w..]....0...
00000010 c0 1f 00 00 ff ff 00 aa ........

I think this shows that the challenge response is failing. But there are
a few things I'm not clear on:
1. I found the format of these messages in the p_lg.p file, but I think
both of them should be 7 bytes long. Why are there 24 bytes in the
response? Do other LG phones return similarly long responses? Is it safe
for BitPim to ignore the "extra" 17 bytes or is this part of why this is
failing?

2. I don't know much about Python or SHA-1 but the comments in the
get_challenge_response() method in com_lg.py talk about operating on a
16-byte block. But the input seems to be 4 bytes, and the code seems to
construct an array of 16 longs (the first of which is the challenge). I
can't reconcile these different sizes. Are the comments wrong here?

My best guess on what's going on here is that the vx9100 uses a
different input vector for the hash. But this seems to be a 160-bit
value! The source code credits Nathan Hjelm for reverse engineering
this. Does anyone know how he did this? Can it be done with the vx9100?
A brute force attack here would be Herculean.

BTW, the consensus on HowardForums is that the vx9100 doesn't exhibit
any of the restricted filesystem behavior until the device has been
activated for the first time. I suspect (but don't really know) that the
DM transition fails in this state as well...but the phone is not
protected at all. BitPim is reported to work fine until the device is
activated. If access to the device's files is necessary to reverse
engineer the hash again, it might be necessary to get your hands on a
not-yet-activated vx9100.


I know this e-mail isn't exactly a discrete question. I guess I was just
hoping to get some confirmation from those-who-know-more-than-I that my
understanding of the problem is correct, and to share with the
developers what I know about this problem. I'll relay any information
gleaned here back to the HowardForums community.

Thanks,
Eric Dickinson