Page 2 of 19 FirstFirst 123456712 ... LastLast
Results 21 to 40 of 363
  1. #21  
    Originally posted by frenchfries
    In the PRC you have two calls : SimLockSaveDBToSD and SimLockRestoreDBFromSD, without parameters. They perform a save of the SIMLockDB in a file on the SD before the flash operation and restore it from this file after the flash operation (look at the disassembly of the code).

    Next step is to make a small prog that will embed SimLockSaveDBfromSD like code and ask people to send the resulting file and try to understand the SimLock database format.
    Yes, I've played a bit with DeviceCustomizer today... but with nothing much interesting as a result.

    When you launch DeviceCustomizer, if you cancel the script (or if you don't install it at all), you can get to the advanced mode, where you can issue text commands directly to the interpreter. Try typing "help", for instance.

    I've typed "savesimlock", and the program then displays "Saving SIM Lock Database..." then "Succes!", but there's no file created on my SD card. I tried this with or without activating the phone, same result.

    My phone is already unlocked, though. Can anyone with a locked phone try that too?

    The question is: what happens if this info is not restored / badly restored ? Does this leave the phone in a instable state ? Is this info encrypted with the IMEI etc etc ...
    I'd guess that messing with the simlock status area would probably render the phone unusable or instable at best. And I wouldn't be surprised if this part was IMEI-encrypted to avoid the kind of stuff we're looking for!
  2. #22  
    Originally posted by frenchfries
    <SNIPPED plotting and intrigue>

    FrenchFries
    I doubt AT&T would be dumb enough to just have the phone look for a generic lock vs. unlock flag. You would need to know the algorithm for generating the unlock code for the particular phone's serial. Also, if the carrier was smart, they could easily have stipulated that Handspring customize their software so that the lock status be immutable.

    You're opening up a Pandora's box for Handspring et. al. Eventually the h@x0rz may hack apps like Brayder's ROM Crafter™ or JackFlash (remember EditROM?) and re-flash to generic unlocked status. The next step would be creating a program to spoof real phone numbers within the networks. Imagine long distance anytime, anywhere for 0 ¢/minute? Just make sure GPS is off or else someone might get LoJacked!
  3. #23  
    Originally posted by The Chupacabra
    You're opening up a Pandora's box for Handspring et. al. Eventually the h@x0rz may hack apps like Brayder's ROM Crafter™ or JackFlash (remember EditROM?) and re-flash to generic unlocked status.
    I don't think this would be very easy to do... And Brayder tools wouldn't be appropriate anyway, since they do not support the Treo 600!


    The next step would be creating a program to spoof real phone numbers within the networks. Imagine long distance anytime, anywhere for 0 ¢/minute? Just make sure GPS is off or else someone might get LoJacked!
    For security's sake I hope that Handspring did not put the IMEI number in a reflashable ROM area! On any PalmOS device, the serial number is located in a part of the FlashROM that is hardware-protected, i.e. you can't reflash that part of the chip. They certainly have done the same for the IMEI number and other device identification numbers!

    But I agree with you: messing with the unlock status is opening the Pandora box. IMHO the most violent reaction would come from the carrier themselves, not from Handspring (I think that they couldn't care less about which provider you use, as long as you're buying their devices). The mobile phone operators, on the other hand, offer you substancial discount to lure you to subscribe to their services, so if they have set a sim-lock, then they'll certainly frown to any attempt to get rid of it! That being said, the world is full of places/websites where you can find material helping you to unlock the sim-locked phones, so they might not sue everyone invloved in that thread... yet!
  4. #24  
    The mobile phone operators, on the other hand, offer you substancial discount to lure you to subscribe to their services, so if they have set a sim-lock, then they'll certainly frown to any attempt to get rid of it! That being said, the world is full of places/websites where you can find material helping you to unlock the sim-locked phones, so they might not sue everyone invloved in that thread... yet!
    A judge in The Netherlands has declared that unlocking a phone is LEGAL AT ANY TIME....that is in The Netherlands.
  5.    #25  
    We're getting closer.

    Sounds like we need to look at the simlockdb write location, and look specifically for things like the carrier code (AT&Ts in 310380 iirc). Perhaps the carrier code is not so closely hidden, if we can overwrite that we could possibly write our own carriers code in. Not unlocking, but giving us the ability to change carriers.
  6. #26  
    Originally posted by euroclie

    I don't think this would be very easy to do... And Brayder tools wouldn't be appropriate anyway, since they do not support the Treo 600!
    Brayder already has the tools to strip the Treo 600 OS. Handspring would have advised them not to release a PhoneOS-compatible version, as this would risk offending the carriers Handspring is so dependent on. (No doubt Sprint isn't amused at how easy it was to recover the hidden call duration info from their phones!) Brayder would also have created problems for itself by allowing newbies to remove crucial files.

    I've been using custom PalmOSes for four years and it's the best way to go. The PhoneOS can and will be hacked, just as every other version of PalmOS has been hacked. The only question is will the hackers be made to "disappear" like what happened to EditROM's developer, Lars?

    Just don't answer when the Men In Black ring your doorbell...
  7. #27  
    Originally posted by The Chupacabra
    Brayder already has the tools to strip the Treo 600 OS. Handspring would have advised them not to release a PhoneOS-compatible version, as this would risk offending the carriers Handspring is so dependent on.
    Good news... even if they do not publicly release their Treo 600-compatible version!

    Brayder would also have created problems for itself by allowing newbies to remove crucial files.
    That is one of their main concerns, I know, but this hasn't prevented them to release JackFlash/JackSprat for other devices in the past...

    The funny thing is that last time I inquired about the Treo 600 support, they replied that the Treo 600 had no empty space in ROM and that as such they wouldn't bother adding Treo 600 support to their software. The same bogus reason was given in the past for devices which have been since suported, so nothing is set in stone! And this is bogus indeed, since the aim of JackSprat is exactly that: create some empty space in ROM by removing at least the unused language overlays!


    The PhoneOS can and will be hacked, just as every other version of PalmOS has been hacked.
    If you're thinking about the Firmware part, this isn't going to be trivial, and I'm not sure why anyone would want to do that, or if that can be done by non-professional guys.

    If you're thinking about the PalmOS stuff, then yes indeed this is going to be hacked sooner or later. But then you don't even need to reflash anything, a cleverly written program in RAM might be more interesting for hackers because you can update it very easily!

    The only question is will the hackers be made to "disappear" like what happened to EditROM's developer, Lars?

    Just don't answer when the Men In Black ring your doorbell...
    Well, I can remember Lars "disappearance". It's a pity we don't know what happened to him actually. My guess is that it wasn't EditROM-related. I've been working at a ROM Editor (do a google search with "Chromed" and "ROM"), and nothing bad ever happened to me since I released the first beta versions!

    The trick is, like Lars, I thought I'd release it as a shareware (my initial goal was to be able to purchase a few test devices so that I don't "fry" my main device during the tests), and to be honnest that has been a complete failure: first of all, because I didn't get more than a dozen of registration (and the US$ 5 price shouldn't have been that much a deterrent), and then because PalmGear screwed up and didn't give me my money (they had financial problems, I know, but they sent me a US$ 15 check once, then an incorrectly ordered US$30, which I had to send back, which came back unsigned, was sent back again, came back signed at last but it was outdated by the time I tried to send it to my bank, so I've never been able to get those $30! )

    All in all, I've had maybe 30 or 40 guys contact me about Chromed, so the "market" for such "pro" tool is very limited. Brayder made a fine move when they designed their ROM-related tools to be usable by newbies, but then this wasn't the goal for my ROM editor anyway!

    I've started working again on it to update it for OS5, but it's not trivial due to the lack of documentation for OS ROMs. There's at least one bug in the current version that I'll be able to remove anyway for OS4 ROMs...

    My initial thought was to provide a tool to play with the various languages overlays, and be able to create a "custom" ROM in unsupported languages...
  8. #28  
    While we're talking about hackers, for those who are curious enough to get a ROM dump of their Treo 600 (using the ROM Transfer Extension program, for instance, or SyncWizard...), have a look at the 0x0001c2f0h offset (in the 1.0 Orange FR ROM) or 0x0001c3f0h (in the 2.09 INT ROM), starting at the beginning of the ROM (you need the full ROM, including the Small ROM, otherwise just substract 0x8000h to those offsets).

    Guess what we find there: a text string which says "Hackers Rule!!!!".

    There are abviously guys at Handspring who have a sense of humor!
  9. #29  
    how about trying to get a ROM copy from the orange users that applied the firmware upgrade and had to re-enter the unlock code? if you have a copy before and after entering the code then it should be easy to find the file that got changed.

    they can apply the firmware upgrade a second time to get it to the locked state again in order to make the first ROM dump.
  10. #30  
    Originally posted by euroclie
    If you're thinking about the Firmware part, this isn't going to be trivial, and I'm not sure why anyone would want to do that, or if that can be done by non-professional guys.

    If you're thinking about the PalmOS stuff, then yes indeed this is going to be hacked sooner or later. But then you don't even need to reflash anything, a cleverly written program in RAM might be more interesting for hackers because you can update it very easily!


    Well, I can remember Lars "disappearance". It's a pity we don't know what happened to him actually. My guess is that it wasn't EditROM-related. I've been working at a ROM Editor (do a google search with "Chromed" and "ROM"), and nothing bad ever happened to me since I released the first beta versions!

    The trick is, like Lars, I thought I'd release it as a shareware (my initial goal was to be able to purchase a few test devices so that I don't "fry" my main device during the tests), and to be honnest that has been a complete failure: first of all, because I didn't get more than a dozen of registration (and the US$ 5 price shouldn't have been that much a deterrent), and then because PalmGear screwed up and didn't give me my money (they had financial problems, I know, but they sent me a US$ 15 check once, then an incorrectly ordered US$30, which I had to send back, which came back unsigned, was sent back again, came back signed at last but it was outdated by the time I tried to send it to my bank, so I've never been able to get those $30! )

    All in all, I've had maybe 30 or 40 guys contact me about Chromed, so the "market" for such "pro" tool is very limited. Brayder made a fine move when they designed their ROM-related tools to be usable by newbies, but then this wasn't the goal for my ROM editor anyway!

    I've started working again on it to update it for OS5, but it's not trivial due to the lack of documentation for OS ROMs. There's at least one bug in the current version that I'll be able to remove anyway for OS4 ROMs...

    My initial thought was to provide a tool to play with the various languages overlays, and be able to create a "custom" ROM in unsupported languages...
    I'd like to know what area of the ROM chip Handspring stored device serial +/- hardware lock flag (If the AT&T version even has one). Why would they have left it exposed and risk an easy hack? It's funny but don't you find it strange how no one has even admitted how much memory is left over in the various PhoneOS ROMs? But now that Brayder and HandEra are paired up, maybe you should email Kit McDowall (kit.mcdowall at handera.com) and ask for some pointers. (Hint)

    I believe Lars became a permanent part of the cement foundation in Palm's new offices a few years ago.

    Does your ROM app generate stubs for deleted core apps?

    Too bad about you getting ripped off by Palmgear. I read they recently went on a boat cruise - looks like that's where all the developers' money was blown...

    The PhoneOS has a lot more files (dozens) than the regular PalmOS and Brayder would have had to really limit choices to prevent newbies from turning their Treo 600 into paperweights. At least being able to remove extra language files would have been nice, though. But the day after they released JackSprat for Treo 600 it would be modified to parse any file.

    What ever happened to development of Romeo? External storage (and Palm hitmen) seems to have killed off hardcore inventiveness over the past three years. Maybe it's time the boys maintaining PW-Patcher turned their sights on a bit more constructive challenge.
  11. #31  
    Originally posted by Mol
    how about trying to get a ROM copy from the orange users that applied the firmware upgrade and had to re-enter the unlock code? if you have a copy before and after entering the code then it should be easy to find the file that got changed.

    they can apply the firmware upgrade a second time to get it to the locked state again in order to make the first ROM dump.

    The firmware upgrade re-locks the phones? Are you sure about that? If that's true, it's actually a very good sign.
  12. #32  
    I've seen at least two posts in the firmware upgrade threads about the phone being locked again. One of them didn't have the unlock code anymore...
  13. #33  
    Originally posted by Mol
    I've seen at least two posts in the firmware upgrade threads about the phone being locked again. One of them didn't have the unlock code anymore...
    A good question to ask now is: did those two users use the SD card to upgrade, or did they do that from RAM directly?

    I suspect that since the savesimlock and restoresimlock functions actually use the SD card to store the simlockDB, maybe performing the upgrade without a SD card inserted leads to the loss of the unlocking, i.e. the unlocked status isn't saved and then cannot be restored.

    It might have been the case for many more users, except that if they are using simlocked devices, they wouldn't notice anyway...
  14. #34  
    > ...Guess what we find there: a text string which says
    > "Hackers Rule!!!!"....

    In the Good Old Days an el-cheapo encryption/decryption technique for multi-byte data was to simply XOR in another fixed set of multi-byte data (with perhaps some other reversable math added for slightly more obfuscation).

    The string above is an interesting 16 bytes long.

    Hint?
    Last edited by SeldomVisitor; 01/06/2004 at 05:22 AM.
  15. #35  
    Originally posted by The Chupacabra
    I'd like to know what area of the ROM chip Handspring stored device serial +/- hardware lock flag (If the AT&T version even has one). Why would they have left it exposed and risk an easy hack?
    As for the serial number it is usually located between the Small ROM and the Big ROM. If you look at a Treo 600 ROM dump, the 0x6000 to 0x7FFF area is filled by 0xFF bytes whereas the empty spaces normally contain 0x00, so this area of the FlashROM is probably locked. That's where I would have expected the serial number to be located (not the simlock status, though). But it's not there...

    On a Tunsgten T device, for instance, the 0x8000 to 0x20000 area is filled with 0xFF bytes, but at 0x10000 you find a small area which contain the serial number of the device...

    I didn't find the IMEI number nor the HS serial number in the ROM dump I have...

    [QUOTE][B]It's funny but don't you find it strange how no one has even admitted how much memory is left over in the various PhoneOS ROMs?
    IMHO, given that the ROM is in the 8 to 10Mb range, I'd guess that the ROM chipset is 16Mb. I think I have seen somewhere a page with some photos of the inside of a Treo 600, maybe if we can find it again we might know what brand and size of FlashROM chip they used?

    But now that Brayder and HandEra are paired up, maybe you should email Kit McDowall (kit.mcdowall at handera.com) and ask for some pointers. (Hint)
    OK, I'll try to email Brad again, and this Kit McDowall as well... I'm in good terms with Brad, so maybe I can learn some useful stuff.

    Does your ROM app generate stubs for deleted core apps?
    No, the goal is more language/overlay related, so I didn't bother with those stubs... They can be in RAM, anyway. My objective was not to compete with JackSprat/JackFlash (at a point in past, Brad was almost ready to create a Chromed-specific version of FlashWrite, but then he backed up, logically enough, because he feared having too much tech support to provide with newbies frying their devices!)

    Too bad about you getting ripped off by Palmgear. I read they recently went on a boat cruise - looks like that's where all the developers' money was blown...
    Yes, I heard about the cruise (from PalmGear themselves), it was a reward for those big developpers which provided most of the cash that PalmGears receives for the software sales! Definitely not my league...

    What ever happened to development of Romeo?
    Back when I started working on Chromed, I exchanged a fiew friendly messages with Monica Chew (one of the two authors of Romeo), and I told her that the Sony Clie ROM offset was different from the typical Palm devices ROM offset, so with a one byte patch in the sources I was able to make Romeo handle the Clie ROM as well (though the Japanese stuff was harder to deal with). I even used Romeo to create an English Sony Clie S500C ROM (unique in the world, as this device wasn't released outside of Japan... Although there's at least a second one now, a Brazilian guy I helped reflash his own S500C in English! )

    Otherwise, it's true that the PalmOS world seems to have lost part of its innovative spirit (is it just me or are PalmGear "new software" and "updated software" pages literally full of useless and barely updated databases or launcher themes? )

    Maybe it's time the boys maintaining PW-Patcher turned their sights on a bit more constructive challenge.
    Yep, that would definitely be a big plus for us!

    One problem that has appeared last year was the arrival of the OS5 and the ARM architecture, so it's back to square one for people who need to learn a new assembler language, architecture, and build a new set of tools...
  16. #36  
    Originally posted by SeldomVisitor
    > ...Guess what we find there: a text string which says
    > "Hackers Rule!!!!"....

    In the Good Old Days an el-cheapo encryption/decryption technique for multi-byte data was to simply XOR in another fixed set of multi-byte data (with perhaps some other reversable math added for slightly more obfuscation).

    The string above is an interesting 16 bytes long.

    Hint?
    Well, the string is a part of the "Boot" file in the ROM, so probably not something we can use for anything GSM-related, unfortunately... But that would have been funny!
  17. #37  
    Originally posted by Mol
    how about trying to get a ROM copy from the orange users that applied the firmware upgrade and had to re-enter the unlock code? if you have a copy before and after entering the code then it should be easy to find the file that got changed.

    they can apply the firmware upgrade a second time to get it to the locked state again in order to make the first ROM dump.
    I've just received a reply from the guy who sold my the Treo 600 (I bought it second hand after the initial owner had it unlocked by Orange France), and he gave me the unlock code, so I'll probably soon be applying the upgrade to my device, now that I can unlock it if it somehow loses its unlocked status. I'll perform a ROM dump after the upgrade, though, to see if I can do what you're describing here...

    By the way, did anyone have a look at the GSMActivation application in the ROM? It seems to ask a 3 digits country code, then a 2 digits network code, and the final alert message is something like "you've successfuly reprogrammed your Treo". Maybe there's something interesting in there as well...

    That being said, I'm pretty sure that the Phone and GSMLibrary files contain what we need. The GSMLibrary contains a "Farm" resource (F for flash, and arm for the ARM architecture... There's an explicit "FlashUtil" string in the code part of this resource)...

    On another topic, I think we need a good tool to get a complete ROM dump. I write that because "ROM Transfer Extension" seems to work more or less, but after the end of the actual ROM store, I get some data that obviously come from the RAM...
  18. #38  
    If you have a working unlock code for a particular phone that is still locked, and you have source code that suggests unlocking, and you have the "ROM" contents BEFORE the unlocking and will have the ROM contents AFTER the unlocking, then I'd humbly suggest you have 90+% of the entire unlocking problem solved...
  19. #39  
    OK, I successfuly applied the 2.09 upgrade. Of course, since I had an Orange ROM with the Zlib library built-in, I got the usual Zlib error message, otherwise everything went smoothly.

    Now I've performed a ROM dump with ROM Transfer Extension. For your information, I did get an error message (#10504) during the transfer on the SD card, but this was with the 32 Mb Hitachi SD card that comes bundled with the Treo 600, and when I used my 256 Mb Panasonic SD card I had no particular problem. So the bottom line is that if you get that error message, maybe you can try with another (faster?) card.

    After performing the ROM dump, I decided to swith the wireless on again... (suspense)... nice default screen by the way, better than the Orange one... enter the usual PIN code... (suspense) ... and get an error message telling me that the phone cannot be used with that SIM card!

    I had made sure that my SD card was freshly formatted by the Palm before transfering the updater on it, and the SD card was inserted during the update process, so I confirm that upgrading will probably make your phone return to the default simlock status...

    I'm glad I waited until I had received the unlock code before applying the upgrade!

    So I launch the phone application again, and of course I have a "No service" message at the top left of the screen, plus an orange blinking light. I pray that I can still dial the unlock code despite not having an Orange SIM card in the phone (mine is SFR, another French operator). I dial the unlock code *#*#[8 digit code]# + dial button, and it's suspense again for a few seconds, before the Treo finally displays a message that tells me that the sim locked has been removed. Sure enough, when I return to the phone main screen, the F-SRF at the top left confirm that the phone is indeed unlocked! Wow, that left me sweating for a few seconds/minutes, which seemed like an eternity!

    I've performed a second ROM dump again using ROM Transfer Extension, and will compare this one with the previous just after the upgrade. Of course, I'll let you all know if I find anything useful!

    So I now have the following setting:

    Firmware: 02.09
    Software: Treo600-1.09-INT
    Hardware: A

    I've yet to try the phone to test the quality, and test the GPRS speed as well, but things seem promising so far!
  20. #40  
    Originally posted by SeldomVisitor
    If you have a working unlock code for a particular phone that is still locked, and you have source code that suggests unlocking, and you have the "ROM" contents BEFORE the unlocking and will have the ROM contents AFTER the unlocking, then I'd humbly suggest you have 90+% of the entire unlocking problem solved...
    It seems so... but the question is: do I have in my ROM dump the part that gets changed during the unlocking process?

    Stay tuned...
Page 2 of 19 FirstFirst 123456712 ... LastLast

Posting Permissions