BitPim 1.0.5 & LG vx9100 - Failed to transition to DM

Hello.

There are a whole bunch of people on HowardForums that would like to use 
BitPim with the new LG vx9100 (aka enV2). Unfortunately, BitPim 
complains that "Access to the file/directory has been blocked on this 
phone by the phone provider". This is the primary problem.

Now, I'm *assuming* that this problem would not arise if the phone could 
be placed in DM (diagnostic mode?). And it's evident from the logs, that 
this isn't happening:

14:10:58.539 COM10: USB support is not available
14:10:58.540 COM10: Opening port COM10, 115200 baud, timeout 3.000000, 
hardwareflow 0, softwareflow 0
14:11:00.364 COM10: Open of comm port suceeded
14:11:00.367 LG-VX10000: Attempting to contact phone
14:11:00.368 LG-VX10000: Retrieving fundamental phone information
14:11:00.368 LG-VX10000: Phone serial number
14:11:00.450 LG-VX10000: Now in brew mode
14:11:00.493 LG-VX10000: Reading group information
14:11:00.640 LG-VX10000: Failed to transition to DM
14:11:00.641 LG-VX10000: stat file pim/pbgroup.dat
14:11:00.684 Error: Access Denied
Access to the file/directory has been blocked on this phone by the phone 
provider

(BTW, the consensus on the forum is that the vx10000 is close enough, 
but other LG model choices do the same thing.)

I looked at the source code and found the bit responsible for the DM 
transition in com_lg.py. From this, I think this is the relevant portion 
of the protocol log:

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

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone