Page 12 of 19 FirstFirst ... 27891011121314151617 ... LastLast
Results 221 to 240 of 363
  1. #221  
    I cannot find the post Ifly2 mentions, is it still on the discussion board?
  2. #222  
    OK, i've done it too!!

    Thanks to everyone but especially to frenchfries and ifly2

    Let me just reiterate what ifly2 said, to make it simpler for everyone else:

    1. upgrade your firmware using MOL's method
    2. open crashed.zip on your pc
    3. use a hex editor to modify FirmwareStackRel.pdb as follows:
    position 3a1130 (on UltraEdit it actually shows as 1a1130 ) reads:
    20 00 B0 03....
    Change that to
    20 01 ....
    and save the file
    4. sync all the files back to your SD card
    5. run FirmwareUpdater.prc from the card
    6. Treo resets, and is unlocked

    Good luck!
  3. cvt
    cvt is offline
    cvt's Avatar
    Posts
    32 Posts
    #223  
    Hi,
    quick question - you need to upgrade to 2.09 first (point 1 in your post?)

    thx
  4. #224  
    > ...3. use a hex editor to modify FirmwareStackRel.pdb as
    > follows:
    > position 3a1130 (on UltraEdit it actually shows as 1a1130 )
    > reads:
    >
    > 20 00 B0 03....
    >
    > Change that to
    >
    > 20 01 ....
    >
    > and save the file...

    Wait!

    Don't do that!

    No kiddng.

    The instructions for step 3 should say something like:

    == ...3. Go to position 3a1120 and confirm that the next N locations
    == contain the values:
    ==
    == XXXX
    == YYYY
    == ...
    == 20 00 B0 03 <== MUST BE AT position 3a1130
    == ...
    == ZZZZ
    ==
    == If the values ALL match then change the value(s) at position 3a1130...
    == etc etc etc

    Even a one byte difference between what others have and what you have could be a disaster.

    (what's the saying? Measure twice, cut once)
  5. #225  
    Many thanks to

    euroclie, mol, frechfries, ifly2 etc.
    now my T600 works with swisscom (switzerland)



    coaster
  6. #226  
    I have no more idea what to do than when I started reading through these threads. If anyone can explain how to do this to a simple Scotsman, I would be eternally grateful and you can have my first born...
  7. #227  
    > I have no more idea what to do than when I started reading
    > through these threads. If anyone can explain how to do this to
    > a simple Scotsman...

    A few posts above are explicit instructions on how to unlock a GSM TREO. It shouldn't take a rocket scientist to develop a very simple script that ANYONE can run that will automate the entire process (including verification BEFORE modification).

    Until then, however, you're up the creek - it is MUCH too hazardous for someone who does not understand what was said up above to do this themselves.
  8. #228  
    Here's the link to the patched with all the files that you need:

    removed

    I've used it to unlock my Orange Treo.

    Installing is actually quite simple:

    1. Unzip all the files and copy them to the /PALM/LAUNCHER folder on your SD card.

    2. Hard reset the Treo.

    3. Navigate to the card using the standard application launcher and run FirmwareUpdater.prc.

    4. Click OK, click the Update Now button (I may have forgotten one or two OK clicks here so don't hesitate to correct me here).

    5. Sit back and relax, it's going to take a good 10 minutes.

    6. The phone will automatically hard reset at the end of the process.

    That's all, really. Note that I think it does do the entire 2.09 firmware upgrade, so all this should even work when you're on an older firmware version. I recommend you do the regular upgrade first though.

    EDIT: I've updated the patched.zip. It no longer contains the rcp file that was causing a problem for some.

    EDIT 2: I decided to remove the file from the server. I'm not worried about the actual unlock, but I am worried about supplying modified software that is copyrighted. I don't want to get arrested the next time I travel to the US
    Last edited by Mol; 01/19/2004 at 03:09 AM.
  9. #229  
    Congratulations to Frenchfries and ifly2! Nice piece of reverse engineering! I wish I did understand ARM assembler as well as you do <sigh>

    Now the next question is: appart from this immediate and working (so it seems... Didn't try that myself, as my Treo is already unlocked) patch, the nice thing would be to pursue the matter a bit further: now that we know where the code is located, could you guys as well investigate the possibility of writing a piece of (assembler) code that would use the built-in encryption functions to generate the correct unlock number?

    I don't want to bash your satisfaction at having a working unlocking method, but sooner or later there may be an official Handspring update (remember reading something about a release in January), and if the firmware is updated we'll have to patch it all over again with any new release. Plus the fact that now that it's been "cracked", HS may possibly change something in there to try and obfuscate it a bit, so maybe getting the correct unlock code should still be considered an interesting goal.

    This board is just awesome for getting some actual results like with this great thread! Thanks to anyone who participated!
  10. #230  
    Originally posted by euroclie
    Congratulations to Frenchfries and ifly2! Nice piece of reverse engineering! I wish I did understand ARM assembler as well as you do <sigh>

    Now the next question is: appart from this immediate and working (so it seems... Didn't try that myself, as my Treo is already unlocked) patch, the nice thing would be to pursue the matter a bit further: now that we know where the code is located, could you guys as well investigate the possibility of writing a piece of (assembler) code that would use the built-in encryption functions to generate the correct unlock number?

    I don't want to bash your satisfaction at having a working unlocking method, but sooner or later there may be an official Handspring update (remember reading something about a release in January), and if the firmware is updated we'll have to patch it all over again with any new release. Plus the fact that now that it's been "cracked", HS may possibly change something in there to try and obfuscate it a bit, so maybe getting the correct unlock code should still be considered an interesting goal.

    This board is just awesome for getting some actual results like with this great thread! Thanks to anyone who participated!
    I believe the patch is setting the Treo to the default unlocked state, i.e. like the Cingular phones. So I doubt future upgrades will be able to determine the difference between a Cingular and a patched version.

    And yes, big thx to Frenchfries and ifly2! Awesome find.
  11. #231  
    Originally posted by Mol
    I believe the patch is setting the Treo to the default unlocked state, i.e. like the Cingular phones. So I doubt future upgrades will be able to determine the difference between a Cingular and a patched version.
    You mean that your phoneinfo program reports the device as unlocked, right?

    A good test would be to reflash the original 2.09 upgrade and see if the phone retains its unlocked status...

    That would certainly be a very good news indeed! If that's the case, it means that someone could reflash the patched firmware to unlock its Treo 600, then reflash some "official" upgrade from Handspring if/when it's released, and then the Treo would be a "clean" (i.e. not patched) but unlocked Treo ever after!
  12. #232  
    Any binary patch that fixes code to always return a '1' where before it returned the result of a test will almost certainly need to be updated each and every time palmOne releases an update for the TREO 600.

    ====

    BTW - the above is a VERY good reason to always confirm the code is correct BEFORE fixing it since each patch could EASILY minimally MOVE the unlocking code - don't want to patch the wrong location!
  13. #233  
    Thanks MOL
    One problem though and need clarified vefore I proceed. I got this message when I sent the files to the SD card. Is this file required and if so why wont it accept it on SD card?

    ERROR: The following file(s) could not be installed to the SecureDigital (SD) Card because there is no application on your handheld to open these files.
    If you have recently installed such an application, please run that application and then perform a HotSync operation.
    FirmwareUpdater.rcp
    Install To Card synchronization failed
  14. #234  
    I'll proclaim my ignorance right up front, but I have a bit of experience hacking other architectures in assembler...

    Seems to me a better way to do this via an assembler hack is to find the code that checks if an Unlock code entered by the user is valid or invalid. Make THAT function always return TRUE and it will then write to whatever special DB record stored in ROM that tells the Treo it's locked/unlocked.

    Then flash it, and try an unlock code. The system will say whatever it's going to say, but internally it thinks you entered a valid code and writes into ROM that it's unlocked.

    This, of course, fails if that special DB record is some hash of an actual unlock code, and that record is rehashed/checked on every attempt to use phone/data functions. In this case, the simplest fix is the one already proposed here (nice work btw!!)

    However, if you do it that way, it may not have to be rehacked every time there's a firmware update.

    Just a thought,

    Jeff

    PS - See 'ignorance' disclaimer above again before flaming :-)
  15. #235  
    Originally posted by scudder
    ERROR: The following file(s) could not be installed to the SecureDigital (SD) Card because there is no application on your handheld to open these files.
    If you have recently installed such an application, please run that application and then perform a HotSync operation.
    FirmwareUpdater.rcp
    Install To Card synchronization failed
    Just downloaded the .zip and had a look: the .rcp file is an empty file so you can safely ignore this error message.

    It wasn't in the original update, anyway, I suspect that it's a leftover from Mol's work, which he just forgot to erase when zipping the files...

    Hope this helps...
  16. #236  
    Correct. Apparently I forgot to delete the rcp file from the zip before posting it. I'm using a card reader so that's why I didn't get the error. You can ignore the error message.

    EDIT: I've updated the zip file and it no longer contains this rcp file.
    Last edited by Mol; 01/18/2004 at 01:44 PM.
  17. #237  
    OK, ran the programme but it only lasted a couple of seconds and reached 83% before going to hard reset.
    Second atempt at running brought up 'error' (app8007)
    Any thoughts?

    Used my card reader to transfer files, and it was successful this time Whhhoohoo!
    Last edited by scudder; 01/18/2004 at 08:56 AM.
  18. #238  
    >>Yes, the bear has been shot now!

    It was good hunting...
  19. #239  
    Originally posted by sysvr4
    This, of course, fails if that special DB record is some hash of an actual unlock code, and that record is rehashed/checked on every attempt to use phone/data functions. In this case, the simplest fix is the one already proposed here (nice work btw!!)
    I'm afraid that the DB record is some kind of hash of the unlock code (see my earlier post about the GoUc resource which is related to the unlock code). With Mol's program, we could guess that on locked devices, the GoUc resource isn't defined, and it's created when you unlock your device with the appropriate unlock code.

    I'd be curious to know where in memory the IMEI and simlock are stored. I think that the IMEI must be in a protected (i.e. non reflashable) part of the memory, which is fine, but I'd say that the simlock status is probably located there as well. This means that whenever you enter the unlock code, it probably creates this GoUc string that gets tested, and the device is unlocked, but if you reflash the ROM/Firmware, then the GoUc string is lost, your device is simlocked again until you re-enter the unlock code.

    With the current patch, if I understood correctly, the firmware will always answer that the phone is not locked. This is great (no need even for an unlock code), but as mentionned before, this means also that we'll have to "hack" again the firmware every time a new one is released...

    As you wrote, Jeff, patching the functions that check the validity of the unlock code might work (if the unlock DB doesn't require the actual code to be generated), so this might be a good way to follow.

    IMHO, if we can access to the firmware functions from a user-made assembler program (i.e. basically, what's the memory offset for the Firmware? Can we read it using the PalmDebugger?), we could try a brute-force attempt to get the code.

    Using assembler and the firmware functions directly instead of the PalmOS Phone API might save some precious time so that it doesn't require years to break the unlock code...
  20. #240  
    Hi,

    I got my Treo work now....

    Many Many Thanks every one help here



    GREAT JOBS

Posting Permissions