the unlock code on the LG GW620 Eve is EVE&ADAM&&620LOVE!
(
XDADeveloperWiki - LG Eve had lots of LG 620 Eve info )
Various parts of the codes that Heffe listed above and on the lgallyforums site do appear in the linux "strings" search ... "strings '/LG Droid Ally System Dump/app/Phone.odex' " ... but the storage arrangement of those strings (my amnesia is kicking in, but I remember that "#*#*" and "*#*#" were there) when viewed in their raw positions shows that they are often array elements to be referenced by array-position. The numbers or various pieces of them do not appear, nor do they appear in whole or in part when hex-converted and searched against the hex state of that same file. (ARGH ... just realized that I may or may not have an endian-ness problem ... I piped things into `hexdump` and there are issues of byte-order ... so ... does anyone know if the Ally is a big-endian or little-endian type?)
I am of the belief, possibly mistakenly, that this is the proper file to eyeball-search the strings output of, since as far as I can tell this is the only location where the dialer-access-codes are processed. [ Hmm ... as I'm writing all this and trying things, I've realized that I am mistaken at least as far as Eve evidence goes ]
/storage/Ally/Eve/LG_eve_backup_app_folder/backup# ( for file in `ls -1 *odex` ; do echo =-=-= $file =-=-= ; strings $file | egrep 620 | egrep -v bbd30e620c188ae ; done ) | less
=-=-= Contacts.odex =-=-=
*#620#
*748#620#
2945#*620#
3845#*620#
=-=-= Phone.odex =-=-=
2945#*620#
/storage/Ally/LG Droid Ally System Dump/app# strings Contacts.odex | egrep '[0-9]' | egrep \#
*#06#
(that's it ... the Ally Contacts.odex is distinctly under-populated)
*#06# just tells you your MEID number
/storage/Ally/LG Droid Ally System Dump/app# ( for file in `ls -1 *odex` ; do echo =-=-= $file =-=-= ; strings $file | egrep [0-9] | egrep \# ; done ) | less
=-=-= HiddenMenu.odex =-=-=
##2342#
##2539#
##33284#
##4773579#
##72786#
##786#
##8378#
This might be more interesting ...
##33284# is also another DEBUG ... brings up a service-code box = 000000 ... seems to do nothing obvious (maybe some input there will do something ... unclear as yet
##4773579# ... 000000
GPS CLRX
PDE Server URL
PDE server port
##72786#
SCRTN
MDN ... MDN will be changed back to factory default value
MSID ... MSID will be changed back to factory default value
Slot 1 NAI ... Slot 1 NAI will be changed back to factory default value
Slot 1 NAI Password ... Slot 1 NAI Password will be changed back to factory default value
##786#
RTN
RTN ... restore all preloaded applications to their factory default versions
##8378# ... 000000
Test
Test
I do wonder what *other* service codes there might be ... I only ever used 000000
Also, ##2539# and ##2342# acted as if I should have been making a call ... perhaps they chain with another number ... I've never done this before, so I have no idea what paradigms LG or others may follow here, I'm flying blind.
/storage/Ally/LG Droid Ally System Dump/app# ( for file in `ls -1 *odex` ; do echo =-=-= $file =-=-= ; strings $file | egrep -i super ; done ) | less
=-=-= CalendarWidget.odex =-=-=
ROOT_ACCESS
=-=-= CertInstaller.odex =-=-=
mRootMonitor
root
=-=-= LGHome.odex =-=-=
getSuperState
superState
=-=-= Launcher2.odex =-=-=
getSuperState
superState
=-=-= Settings.odex =-=-=
getSuperState
superState
There are too many things to eyeball search all at once, especially when I have little idea what keywords or paradigms to seek ...
if anyone knowledgable wants to give this a shot, probably it's best to start with
strings VerizonHiddenMenu.odex | less
strings HiddenMenu.odex | less
strings Phone.odex | less
strings Contacts.odex | less
~/Ally/LG Droid Ally System Dump/app# strings *odex | egrep 740
VS740AV5_2.1r2
vs740
VS740
LG VS740
access$7400
VS740MV5.5210.1011
~/Ally/LG Droid Ally System Dump/app# strings *odex | egrep -i ally
(nothing useful ... things like "setLoadsImagesAutomatically")
~/Ally/LG Droid Ally System Dump/app# strings *odex | egrep -i vzw
(human-filtered ... lots of other stuff)
X-VzW-MDN
!bluetooth_confirm_passkey_msg_vzw
vzw_service_number
-Lcom/lge/VerizonHiddenMenu/Vzw_hidden_main$1; (and about 50 more related lines)
VZW_MIP_SET
VZW_PROG_KEY
VzwFieldTestMain.java
Vzw_hidden_main.java (and another 10 or so relevant java file-names)
vzwServiceProg
#vzwServiceProg ====> vzwServiceProg
vzwService_Number
vzwSrvProgState
vzw_hidden_main_title
vzw_service_number
vzwgpsOne
vzwserviceprog
( for file in `ls -1 *odex` ; do echo =-=-= $file =-=-= ; strings $file | egrep -i stability ; done ) | less
( for file in `ls -1 *odex` ; do echo =-=-= $file =-=-= ; strings $file | egrep -i module ; done ) | less
... both came back blank
I also found references to the LG Eve service manual but as yet none for the Ally.
LG_GW620_SVC_ENG ...
http://csmg.lgmobile.com:9002/swdata/WEBSW/GW620/RUSCO/1203/EN_2)GW620_SVC_ENG_091203.zip
I apologize that this is a raw and somewhat jumbled mess ... it is quite late, and I'm suddenly called to head home by my wife who just got back from a performance ... I'll be around this weekend and will look in here for suggestions on what to hunt for ...
I can start to look at things on a raw-view or hex-view of the odex files from the system-dump once I have potential targets, but I've never done this before so I'm likely to look right at something interesting and miss it.
Annoyingly, I cannot find where the Eve EVE&ADAM code is hidden in the Eve system tree odex files, leading me to believe that it is embedded somewhere other than where i'm looking (I could not find a valid link to the entire Eve Source Tree and I'm too tired / overdue to hunt now)
If we can find the Eve code-location, we can check the same place in the Ally trees.
Seriously though, if this thing does get rooted, there will be a ton of people happy, as it would be like curing a paralized man, and allowing him to walk.