[BitPim-devel] BitPim 1.0.5 & LG vx9100 - Failed to transition to DM

[Eric Dickinson]

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.

[MrPib]

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'm itching for a 9100, but I don't want one if bitpim doesn't work with it.
I'd be willing to order one via mail order, and play around with it before
activating it, up to the 30-day return cutoff. Please let me know if I can
help out this way.

Thanks!
Pib

[Nathan Hjelm]

There is no need to have filesystem access to reverse-engineer the hash. I reverse-engineered the VX-8700 hash by looking at the assembly of the VX-8700 DLL. I will take a look at the 9100 DLL this evening and see what could have changed.

-Nathan Hjelm

Post by MrPib

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'm itching for a 9100, but I don't want one if bitpim doesn't work with it.
I'd be willing to order one via mail order, and play around with it before
activating it, up to the 30-day return cutoff. Please let me know if I can
help out this way.
Thanks!
Pib
--
View this message in context: http://www.nabble.com/BitPim-1.0.5---LG-vx9100---Failed-to-transition-to-DM-tp17093100p17125068.html
Sent from the Bitpim - Dev mailing list archive at Nabble.com.
-------------------------------------------------------------------------
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
_______________________________________________
BitPim-devel mailing list
https://lists.sourceforge.net/lists/listinfo/bitpim-devel

[agstemen]

Hello, I was wondering what the result of this was? I recently got the
VX-9100, and I'm pretty eager to get write access to it!

Thanks!

-Aaron

Post by Nathan Hjelm
There is no need to have filesystem access to reverse-engineer the hash. I
reverse-engineered the VX-8700 hash by looking at the assembly of the
VX-8700 DLL. I will take a look at the 9100 DLL this evening and see what
could have changed.
-Nathan Hjelm

[Nathan Hjelm]

No progress has been made so far as I am still trying to get a copy of
the vx9100 lgdownload dll. Once I have the dll I will be able to
reverse engineer the new dm mode challenge.

-Nathan

Post by agstemen
Hello, I was wondering what the result of this was? I recently got the
VX-9100, and I'm pretty eager to get write access to it!
Thanks!
-Aaron

Post by Nathan Hjelm
There is no need to have filesystem access to reverse-engineer the hash. I
reverse-engineered the VX-8700 hash by looking at the assembly of the
VX-8700 DLL. I will take a look at the 9100 DLL this evening and see what
could have changed.
-Nathan Hjelm

--
View this message in context: http://www.nabble.com/BitPim-1.0.5---LG-vx9100---Failed-to-transition-to-DM-tp17093100p17303349.html
Sent from the Bitpim - Dev mailing list archive at Nabble.com.
---
----------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
BitPim-devel mailing list
https://lists.sourceforge.net/lists/listinfo/bitpim-devel

[arthurmullard]

I note that in the VX8700, the key is clearly visible in the hex of both the
DLL and the device firmware image.

0x67452301L, 0xefcdab89L, 0x98badcfeL, 0x10325476L, 0xc3d2e1f0L

T87V01.bin contains it at offset : 0xe83534
VX8700.dll contains it at offset 0xb8db8

I'm curious, does anyone have the current VX910V3.bin firmware file?
There's no obvious way to guess where the key lives in that file, but
interesting anyway.
I guess if the file leaked, the dll would too..
Art

Post by Nathan Hjelm
No progress has been made so far as I am still trying to get a copy of
the vx9100 lgdownload dll. Once I have the dll I will be able to
reverse engineer the new dm mode challenge.
-Nathan

Post by agstemen
Hello, I was wondering what the result of this was? I recently got the
VX-9100, and I'm pretty eager to get write access to it!
Thanks!
-Aaron

Post by Nathan Hjelm
There is no need to have filesystem access to reverse-engineer the hash. I
reverse-engineered the VX-8700 hash by looking at the assembly of the
VX-8700 DLL. I will take a look at the 9100 DLL this evening and see what
could have changed.
-Nathan Hjelm

--
http://www.nabble.com/BitPim-1.0.5---LG-vx9100---Failed-to-transition-to-DM-tp17093100p17303349.html
Sent from the Bitpim - Dev mailing list archive at Nabble.com.
---
----------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
BitPim-devel mailing list
https://lists.sourceforge.net/lists/listinfo/bitpim-devel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
BitPim-devel mailing list
https://lists.sourceforge.net/lists/listinfo/bitpim-devel

[agstemen]

I'm assuming not, but is it something that easily viewable in the filesystem?

-Aaron

Post by arthurmullard
I note that in the VX8700, the key is clearly visible in the hex of both
the DLL and the device firmware image.
0x67452301L, 0xefcdab89L, 0x98badcfeL, 0x10325476L, 0xc3d2e1f0L
T87V01.bin contains it at offset : 0xe83534
VX8700.dll contains it at offset 0xb8db8
I'm curious, does anyone have the current VX910V3.bin firmware file?
There's no obvious way to guess where the key lives in that file, but
interesting anyway.
I guess if the file leaked, the dll would too..
Art

[mchanna]

Saw this on another board, not sure if its of any use...

"Well, I just put ringtones on an activated ENV2 using the Voyager settings
on bitpim.

The secret?

I used a Cellebrite transfer machine to put the phone into a "service
required" mode to transfer pix and videos, and before it rebooted, I yanked
it off the cellebrite and plugged it into the computer running bitpim.

So the trick will be now, is how to put the 9100 into this "service
required" mode without the $800 celebrite machine.

EDIT: Its a little harder than that is seems, I tried it again, and it
wouldn't work. I had to pull the 9100 off the celebrite at precisely the
right time for bitpim to be able to write to it, and it seems like if its
off too long, the phone re-locks the filesystem again.

Weird."

Post by agstemen
I'm assuming not, but is it something that easily viewable in the filesystem?
-Aaron

Post by arthurmullard
I note that in the VX8700, the key is clearly visible in the hex of both
the DLL and the device firmware image.
0x67452301L, 0xefcdab89L, 0x98badcfeL, 0x10325476L, 0xc3d2e1f0L
T87V01.bin contains it at offset : 0xe83534
VX8700.dll contains it at offset 0xb8db8
I'm curious, does anyone have the current VX910V3.bin firmware file?
There's no obvious way to guess where the key lives in that file, but
interesting anyway.
I guess if the file leaked, the dll would too..
Art

[agstemen]

I'm finding the same key in the VX9100 DLL at address 0xC3090. The DLL works
in LGDownload. I'm not sure how to watch the communication activity between
the app and the phone. If I knew that, i could try to reproduce it in
BitPim.

[MrPib]

Saw in a HoFo thread that the 9100 DLL is available!!
http://www.mobile - files.com/forum/showthread.php?t=14889&page=26

[Nathan Hjelm]

I have attached experimental VX-9100 support. I need someone to help
me test this code to see if it works.

[Aaron G. Stemen]

It doesn't work. there was a syntactical error that I corrected
(changed "else if" to "elif" on line 1599 of com_lg.py), but it doesn't
fall into the DMv6 code you have set up. The response unlock code is
still 0x00 instead of 0x02. I forced it into the DMv6 unlock method,
and it still doesn't work.

I'm attaching the text from exception window when it falls into the DMv5
code, the log from said exception, and the log from forcing it into the
DMv6 code (which doesn't cause an exception).

Let me know if there's anything else that I can do to help.

-Aaron

Post by Nathan Hjelm
I have attached experimental VX-9100 support. I need someone to help
me test this code to see if it works.
-Nathan
------------------------------------------------------------------------
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
------------------------------------------------------------------------
_______________________________________________
BitPim-devel mailing list
https://lists.sourceforge.net/lists/listinfo/bitpim-devel

[Nathan Hjelm]

Hmm, can you send me the protocol log? I have only seen the VX-9100
respond to
fe 00 00 00 00 00 00
with
fe 02 XX XX XX XX 01 where X is any hex number

-Nathan

Post by Aaron G. Stemen
It doesn't work. there was a syntactical error that I corrected
(changed "else if" to "elif" on line 1599 of com_lg.py), but it
doesn't fall into the DMv6 code you have set up. The response
unlock code is still 0x00 instead of 0x02. I forced it into the
DMv6 unlock method, and it still doesn't work.
I'm attaching the text from exception window when it falls into the
DMv5 code, the log from said exception, and the log from forcing it
into the DMv6 code (which doesn't cause an exception).
Let me know if there's anything else that I can do to help.
-Aaron

[Aaron G. Stemen]

Absolutely. Here is one from your code where it falls into the DMv5
unlock, and one from me forcing it into the DMv6 unlock.

The file is a ZIP file, so you'll have to change the extension from BAK
to ZIP.

-A

Post by Nathan Hjelm
Hmm, can you send me the protocol log? I have only seen the VX-9100
respond to
fe 00 00 00 00 00 00
with
fe 02 XX XX XX XX 01 where X is any hex number
-Nathan

Post by Aaron G. Stemen
It doesn't work. there was a syntactical error that I corrected
(changed "else if" to "elif" on line 1599 of com_lg.py), but it
doesn't fall into the DMv6 code you have set up. The response
unlock code is still 0x00 instead of 0x02. I forced it into the
DMv6 unlock method, and it still doesn't work.
I'm attaching the text from exception window when it falls into the
DMv5 code, the log from said exception, and the log from forcing it
into the DMv6 code (which doesn't cause an exception).
Let me know if there's anything else that I can do to help.
-Aaron

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
BitPim-devel mailing list
https://lists.sourceforge.net/lists/listinfo/bitpim-devel

[mchanna]

Saw this on another board, not sure if its of any use...

"Well, I just put ringtones on an activated ENV2 using the Voyager settings
on bitpim.

The secret?

I used a Cellebrite transfer machine to put the phone into a "service
required" mode to transfer pix and videos, and before it rebooted, I yanked
it off the cellebrite and plugged it into the computer running bitpim.

So the trick will be now, is how to put the 9100 into this "service
required" mode without the $800 celebrite machine.

EDIT: Its a little harder than that is seems, I tried it again, and it
wouldn't work. I had to pull the 9100 off the celebrite at precisely the
right time for bitpim to be able to write to it, and it seems like if its
off too long, the phone re-locks the filesystem again.

Weird."

Post by arthurmullard
I note that in the VX8700, the key is clearly visible in the hex of both
the DLL and the device firmware image.
0x67452301L, 0xefcdab89L, 0x98badcfeL, 0x10325476L, 0xc3d2e1f0L
T87V01.bin contains it at offset : 0xe83534
VX8700.dll contains it at offset 0xb8db8
I'm curious, does anyone have the current VX910V3.bin firmware file?
There's no obvious way to guess where the key lives in that file, but
interesting anyway.
I guess if the file leaked, the dll would too..
Art