Page 4 of 19 FirstFirst 12345678914 ... LastLast
Results 61 to 80 of 363
  1. #61  
    @Mol,

    I don't mind doing Patrick garden's job if you can provide a transport from my home to your house. I live in HK. :P

    @Patrick,

    I really appreciate your effort in unlocking the Treo 600. Many thanks.

    Pedro
  2. #62  
    Originally posted by euroclie

    Hard to tell... I'd have to have a 100% correct ROM dump to know which part are wrong when transferred with RTE 3.3.

    When I used the 3.3alpha version, I had some noticeable differences (i.e. when you browse the ROM with an hex editor, you see the "normal" content of a PalmOS ROM, then suddenly the content becomes completely "obfuscated" and doesn't look like PalmOS databases anymore, and later you again switch to normal PalmOS stuff...

    Here with the RTE 3.3 (slightly more recent than 3.3alpha), the result is still not correct, I fear:

    The bottom line is that I don't yet have a correct ROM dump...


    Didn't find the IMEI yet. As for the serial number, I'd says that it's in protected ROM, as the surrounding content is "0xFF" instead of "0x00" generally found in the non-protected sectors. But the memory offset (in the ROM dump) at which I find the snum is not constant! This means that it's not yet possible to give its exact address. If you want to have a look, I did find mine at offset 0x0052d244h in the "locked" ROM, and at offset 0x0052c230h in the "unlocked" ROM.
    The data there was basically the same, except for a "GoUc" field (9 bytes) which has appeared in the unlocked ROM...



    Right now, though, I'm afraid we're stuck again. I'll try to order a serial cable and play a bit with the PalmDebugger and the Treo in debug mode. It doesn't seem to accept to use my USB cable (but then I haven't read the Handspring developer's doc)

    If I was you I'd be VERY careful about more experimentation unless you can be sure you can obtain a true ROM copy. Without a pure dump you may be wasting your time (and also risking creating a paperweight). And I thought ROM transfers were supposed to only be done with serial (not USB) connections.

    Does the old ROM Transfer prc that comes with the Palm OS Emulator package work with the Treo 600? That prc from the POSE package dates back to around 2002, so I would imagine it might not work. I have also tried getting a ROM (not from a Treo 600) with SyncWizard's Retrieve ROM function, but it didn't work for me. (I left and came back 4 hours later and it was still going, so I cancelled it.) Were you able to use it?

    Did you try talking to the guys at Brayder or HandEra? They have the tools and the insider info that would make this all a lot easier. Right now, you're basically looking for a needle in a haystack, and the haystack is apparently getting blown around with each ROM dump...

    I expect the serial and IMEI will both be in sheltered ROM, but if it's true that the unlock doesn't survive re-flashing, it shouldn't matter.
  3. #63  
    Originally posted by euroclie
    Right now, though, I'm afraid we're stuck again. I'll try to order a serial cable and play a bit with the PalmDebugger and the Treo in debug mode. It doesn't seem to accept to use my USB cable (but then I haven't read the Handspring developer's doc)
    [/B]
    according to metrowerks and handspring, you can't use the USB to connect to palm in debug mode. Something about drivers not being set up properly.

    No problems debugging with the serial cable though.

    Keep up the good work!
  4.    #64  
    Guys I've downloaded the gsmunlocker software, browsed the stuff in it. I spotted some code referring to StarGSM, google turns it up as some sort of GSM phone hacking tool.

    Theres a pile of AT commands that appear to be for MS Smartphones (MPx200) I believe - none of these AT commands work on the Treo. At first I thought GSMLocker had tried to dupe us with a piece of software that won't work. However I found some extra stuff which looks to be ROM extracts, some refer to "Treo 600 Sprint", "Treo 600 GSM", "Treo 600 SFV" (off the top of my head).

    It looks like they've bundled two programs to one. The MS Smartphone software unlocks via AT commands that program registry locations directly (AT%UREG commands). And it looks to me the Treo side of it rewrites part of the flash using the serial based Debugger.

    Looks to me the solution is to reflash the critical part of the memory.
  5. #65  
    Originally posted by confusedvorlon
    according to metrowerks and handspring, you can't use the USB to connect to palm in debug mode. Something about drivers not being set up properly.
    Yeah, that's what I thought... I had a try yesterday nonetheless, but of course it didn't work!

    No problems debugging with the serial cable though.
    I'm ordering one today, hopefully I can get it before the end of the week... I hope that I can at last explore the ROM once I have it using the PalmDebugger on the PC!
  6. #66  
    Originally posted by vulcan
    Looks to me the solution is to reflash the critical part of the memory.
    Agreed... But then, where is that critical part located!

    Did your code inspection reveal anything which looks like a ROM offset?
  7. #67  
    Originally posted by The Chupacabra
    If I was you I'd be VERY careful about more experimentation unless you can be sure you can obtain a true ROM copy. Without a pure dump you may be wasting your time (and also risking creating a paperweight).
    Anyway, I'm not going to try to flash anything. Mostly I'd like to pinpoint the memory area that's involved for the sim-locking, and if I'm very lucky, I'd like to find out how they unlock the device. But remember that mine is already unlocked, so I don't need to try anything risky on my needed PDA!

    [QUOTE][B]And I thought ROM transfers were supposed to only be done with serial (not USB) connections.[B][QUOTE]
    It all depends which program you use, in fact. But most programs require the serial cable, indeed.

    Does the old ROM Transfer prc that comes with the Palm OS Emulator package work with the Treo 600? That prc from the POSE package dates back to around 2002, so I would imagine it might not work.
    Didn't even bother to try it. In fact, everything that relates to the Emulator is certainly OS4-specific, so I try to focus on OS5-compatible solutions. But maybe I'm wrong...

    I have also tried getting a ROM (not from a Treo 600) with SyncWizard's Retrieve ROM function, but it didn't work for me.
    <snip>
    Were you able to use it?
    Yes, I've used SyncWizard in the past to get ROM dumps, but not with the Treo 600 (tried again right now - program freezes before the trasnfer even begins. Bad luck...). And I've got 1.9.8 which is supposed to be the latest version, right?

    Did you try talking to the guys at Brayder or HandEra? They have the tools and the insider info that would make this all a lot easier. Right now, you're basically looking for a needle in a haystack, and the haystack is apparently getting blown around with each ROM dump...
    I've just emailed Brad Kish at Brayder, but honnestly I don't hold my breath, as they might logically enough not be willing to provide help on such a delicate subject, because of the legal implications...

    I expect the serial and IMEI will both be in sheltered ROM, but if it's true that the unlock doesn't survive re-flashing, it shouldn't matter.
    Yep. I don't care that I'm not able to alter my serial number or IMEI (in fact I hope no one can do that. Ever.) but it's a fact that the simlock status survives a hard reset (hence is not in RAM) but not a ROM/Firmware reflash (hence is certainly in user-accessible FlashROM)
  8. #68  
    Originally posted by euroclie
    ... but it's a fact that the simlock status survives a hard reset (hence is not in RAM) but not a ROM/Firmware reflash (hence is certainly in user-accessible FlashROM)
    Well, though that is the apparent case with the Orange branded phones, it does not appear to be the case with Cingular and International phones that were never SIM locked. When these are ROM/Firmware reflashed, they remain unlocked.

    There is still much we all don't understand about the T600 locking scheme.

    Bill S
  9. #69  
    Originally posted by tvBilly
    it does not appear to be the case with Cingular and International phones that were never SIM locked. When these are ROM/Firmware reflashed, they remain unlocked.
    I think that upon reflashing, the Treo revert to the original simlock status, i.e. if the device was factory-simlocked (Orange), then it is sim-locked again, otherwise it is still unlocked... Does this make sense?
  10. #70  
    OK, here's the scoop: I politely asked for help at Brayder, and they were kind enough to supply some details about the reasons why they will not support the Treo 600 with either their end-user products (JackFlash, JackSprat) or with their proffessional one (ROM Crafter):

    The Treo 600 only has 4M of physical ROM. The entire ROM
    area is used. They have a tool which takes their real ROM image
    and compresses it to fit into 4M. When the device is booted, the
    image is decompressed into RAM and then they use the MMU
    to map it and look like 8M of ROM.
    This makes sense: 4Mb ROM, and 32Mb RAM, of which 8Mb are used as an uncompressed ROM mirror image...

    So this explains why the ROM dump we get using traditionnal tools like ROM Transfer Extension is weird: ROM Transfer Extension is obviously confused by this ROM -> RAM expansion scheme. It also explains why there's so much unreadable stuff in the ROM dump: those are certainly the compressed areas.

    To say the least, it will make it almost impossible to "play" with the PalmOS ROM. Now my hope is that the simlock status isn't in the compressed part...
  11. #71  
    Originally posted by euroclie
    <snip> ...4Mb ROM, and 32Mb RAM, of which 8Mb are used as an uncompressed ROM mirror image...<snip>
    You've done more looking in the extracted files from an updater; are they in 4meg compressed format or 8meg uncompressed format?

    Has anyone disassembled the updater, or maybe figured out how to read/edit the script commands for the updater? Particularly the part that saves and restores the simlock section? If you could remove the script commands that delete the saved simlock database from the sd card, and you could actually find the simlock database afterwards , maybe you could see the difference between the the unlocked version and the locked version.

    Just a thought.

    Bill S
  12. #72  
    Originally posted by euroclie
    [This makes sense: 4Mb ROM, and 32Mb RAM, of which 8Mb are used as an uncompressed ROM mirror image...

    So this explains why the ROM dump we get using traditionnal tools like ROM Transfer Extension is weird: ROM Transfer Extension is obviously confused by this ROM -> RAM expansion scheme. It also explains why there's so much unreadable stuff in the ROM dump: those are certainly the compressed areas.

    To say the least, it will make it almost impossible to "play" with the PalmOS ROM. Now my hope is that the simlock status isn't in the compressed part... [/B]
    I might be missing something - but doesn't this mean that you can effectively change the ROM by changing RAM (as the 'ROM' that is used is actully unpacked into RAM)
  13. #73  
    >>To say the least, it will make it almost impossible to "play" with
    >>the PalmOS ROM. Now my hope is that the simlock status isn't
    >>in the compressed part...

    do you have unlock code for your treo? did you try to find it in ram?If it is hard cripted we can use script for devicecustomizer patching only.....
    Last edited by atari; 01/07/2004 at 06:18 PM.
  14. #74  
    Originally posted by euroclie
    OK, here's the scoop: I politely asked for help at Brayder, and they were kind enough to supply some details about the reasons why they will not support the Treo 600 with either their end-user products (JackFlash, JackSprat) or with their proffessional one (ROM Crafter):

    quote:
    --------------------------------------------------------------------------------
    The Treo 600 only has 4M of physical ROM. The entire ROM
    area is used. They have a tool which takes their real ROM image
    and compresses it to fit into 4M. When the device is booted, the
    image is decompressed into RAM and then they use the MMU
    to map it and look like 8M of ROM.
    --------------------------------------------------------------------------------


    This makes sense: 4Mb ROM, and 32Mb RAM, of which 8Mb are used as an uncompressed ROM mirror image...

    So this explains why the ROM dump we get using traditionnal tools like ROM Transfer Extension is weird: ROM Transfer Extension is obviously confused by this ROM -> RAM expansion scheme. It also explains why there's so much unreadable stuff in the ROM dump: those are certainly the compressed areas.

    To say the least, it will make it almost impossible to "play" with the PalmOS ROM. Now my hope is that the simlock status isn't in the compressed part...

    WTF??? That's unbelievable! I've been trying to get a straight answer about the memory size of the Treo 600 ROM chip for weeks and that's the LAST thing I expected to hear. I had assumed the chip was 16 MB and the ROM was between 8 - 10 MB (depending on localization). I had also assumed the 8 MB missing from RAM was reserved for dynamic heap. This makes no sense - what Brayder claims Handspring is doing with ROM compression/decompression sounds like a Rube Goldberg solution to a problem that doesn't exist. Something sounds fishy here. And would that mean there is no dynamic heap in the Treo 600? (Unless the compressed ROM is, say 3 MB -> decompresses to 6 MB -> and somehow Handspring releases the remaining "OS-reserved" 2 MB of RAM to programs as dynamic heap.) Did Brayder confirm something like the latter scenario, or did they just give you the vague explanation you quoted above? Why would Handspring do the Rube Goldberg solution when they could have just spent an extra $2 and sourced a ROM chip with more memory? Are they that geeky or are they really such cheap b@stards that they went the comp/decomp route? Or did they really do it to satisfy the demands of the carriers that Handspring prevent ROM hacking?

    Handspring's coders did a hell of a job hacking the ancient PalmOS into PhoneOS. And it appears they had even more clever tricks up their sleeves. Nice try, P.R., but I now REALLY doubt Handspring would have been dumb enough to expose the simlock to a software-only hack. If it's software-crackable, it will probably require insider info to achieve. (A new ROM Transfer Utility capable of doing a "pure" transfer of a non-decompressed ROM; the standalone version of the Handspring ROM Expander; the address of the "unlocked" flag.) More deviously, design a software solution to expose/read/write to the 8 MB of protected RAM -> change appropriate line to "Unlocked". The fact that a legitimate unlock code survives hard resets suggests there is a simple backdoor to this update and that it leads either to protected RAM or to Handspring's Shrunken Head Of A ROM Chip ("SHOARC").

    Can you get som more details from Monsieur B.? Merci bien.
  15. #75  
    Originally posted by confusedvorlon


    I might be missing something - but doesn't this mean that you can effectively change the ROM by changing RAM (as the 'ROM' that is used is actully unpacked into RAM)

    Almost. The RAM that the ROM is decompressed into is the 8 MB portion (of the Treo 600's 32 MB total RAM) that is not available to users. Find a way to access the protected RAM - using software - and you can apparently start hacking the OS.

    But the easiest method to unlock the phones (without the benefit of inside info from a disgruntled former Handspring employee) may be to hack Handspring's own firmware updater and change it's default from "simlock" to "unlock". (Assuming that unlock status is a simple device-independent line change that actually doesn't depend on a unique unlock code generated from IMEI/serial.)


    The plot thickens...
  16. #76  
    >>WTF??? That's unbelievable! I've been trying to get a straight
    >>answer about the memory size of the Treo 600 ROM chip for
    >>weeks and that's the LAST thing I expected to hear. I had
    >>assumed the chip was 16 MB and the ROM was between 8 -
    >>10 MB

    check:
    http://discussion.treocentral.com/tc...ht=i+open.html

    ......treo flash is k4s56163lc-rg75 samsung

    http://www.samsung.com/Products/Semi...s_k4s56163lc-r(b)g_s_r14.pdf

    I cant find any good reason for so small flash memory(battery waste only), even phones like simens a52,a55,c55,m55 have 8mb and new ones a60,c60,sl55 have 12mb....

    btw phones which where locked then unlocked(unlocked in ram),
    after firmware upgrade go beck to locked(they are locked in rom).
    Apparentiy in script file there is no command for checking if phone is locked or not, or command in DeviceCustomizer.prc not
    working (SimLockSaveDBToSD)
    Last edited by atari; 01/08/2004 at 03:54 AM.
  17. #77  
    The treo has at least two CPU :
    - the ARM inside the TI OMAP chip running the PALM OS. if it's a OMAP1510 you can add a DSP (TMS55xx type).
    - But mainly don't forget the ARM 7 inside the Broadcom chip (BCM2121) used for the GSM Wireless stuff (I don't know what they are using for the CDMA version).
    They probably use this CPU for the locking process, as the SIM card is connected to the BCM2121 not to the OMAP chip running the PALM OS.

    And I think there is no way to access the code memory of the BCM2121 (?).

    Just to help.
    (you can some info on the BCM2121, on the broadcom site)

    Denis.
  18. #78  
    k4s56163 is a 16Mx16 bits SDRAM (so 32MB)
  19. #79  
    Originally posted by tvBilly
    You've done more looking in the extracted files from an updater; are they in 4meg compressed format or 8meg uncompressed format?
    Well, there's a lot of things in the ROM update from the SIAM INTL upgrade. The part that gets reflashed is divided into small 16Kb chunks (RomI resources in the reflasher application).

    The first RomI resource contain a very small ROM Store (MicroRom) whose role is unkown to me.

    The second RomI resource contain a table, probably some memory offsets, I'll try to investigate the issue.

    The third and fourth RomI resources contain another uncompressed ROM Store (32Kb in all). This one includes clear text references to "RomDecompression", so we all know now more or less what it's used for!

    The Fifth RomI resource contain a very interesting thing: the first quarter of this resource contains only 0xFF bytes, except at the start where we find a (bogus) serial number, plus the various hardware model, serial (bogus again), etc...

    The rest of the fifth RomI resource is compressed, with some sort of directory of the compressed part at the beginning...

    The following RomI resources are compressed, until resource #157, which is compressed at the start and suddenly uncompressed at the end.

    The following resources are uncompressed PalmOS stuff, until resource number 263, which suddenly reverts to compressed stuff again.

    etc...

    so it's unclear at this time what the updater exactly contain! What is certain is that the RomI resources are 8Mb total size.

    Has anyone disassembled the updater, or maybe figured out how to read/edit the script commands for the updater? Particularly the part that saves and restores the simlock section? If you could remove the script commands that delete the saved simlock database from the sd card, and you could actually find the simlock database afterwards , maybe you could see the difference between the the unlocked version and the locked version.
    I'd love to do that, but it would require a lot of time, and I'd first have to learn dragonball assembler!
  20. #80  
    Originally posted by confusedvorlon
    I might be missing something - but doesn't this mean that you can effectively change the ROM by changing RAM (as the 'ROM' that is used is actully unpacked into RAM)
    Yes, that's an interesting prospect. Maybe we have a way to "update" some built-in applications without reflashing them and without eating some more precious RAM. But first we'd have to find how to write to that virtual ROM, if that's possible for end-users programs!
Page 4 of 19 FirstFirst 12345678914 ... LastLast

Posting Permissions