Originally Posted by MuscleNerd

IPSF still needs to write to the baseband address space (to do the version nullify), which requires a valid secpack. Their current bbsimfree program naively sends the 3.x secpack, which won't grant write access to the 4.x baseband address space. That's why IPSF fails in the situation you described.

So if we know the secpack that grants access to 3.14 baseband memory space, why is it taking so long for the dev team to come up with a virginizing tool for 3.14 baseband phones? Can't they just read the memory off a stock phone, and lock the phone to see exactly what changes were made? Or do they not want to use the secpack discovered by IPSF on principle?

Could IPSF read the version 4.x secpack from a 1.0.2/4.x phone firmware dump? And then have Simfree restore GSM service to 4.x phones with invalid tokens, as well as unlock stock 1.1.1 phones by downgrading to 1.0.2? Or is the secpack like a key and somehow IPSF got it for 3.x but may not have it for 4.x?

The 0x800 byte "secpack" that you send with the 0x204 packet isn't contained in the NOR dump, unfortunately.

Both IPSF and the devteam had access to the same secpack for 3.x by virtue of the ICE*.fls file in the unencrypted ramdisk dmg. But IPSF used it for a different purpose than the devteam.

Originally Posted by MuscleNerd

The 0x800 byte "secpack" that you send with the 0x204 packet isn't contained in the NOR dump, unfortunately.

Both IPSF and the devteam had access to the same secpack for 3.x by virtue of the ICE*.fls file in the unencrypted ramdisk dmg. But IPSF used it for a different purpose than the devteam.

thanks... I understand that the .fls file must begin with the secpack which makes the nor bootloader accept the rest of the flashing. So if I understood what you said earlier, ipsf exploited a bug in the 3.x booloader that wouldn't check the fingerprint of the flash file when the version info was nulled. Thus ispf could run any code they wanted in the baseband and create their unlock token and subsequently reflash with stock .fls file, while the dev team exploited a buffer overflow bug to patch the same two bytes as Geohot's hardware unlock...

But then other than not wanting to use the approach discovered by ispf, what is preventing the dev team from restoring the nor to its virgin state?

[baseband: for the iphone, the Infineon SGold2 chip that is responsible for GSM/GPRS/Edge communications, among other things.
seczone: an area in the baseband's memory where important information like the lock status is stored.
IPSF: iphonesimfree, the makers of Simfree unlock software
bootloader: the "bootstrapping" program that is first loaded in a device's memory, and then loads the rest of the stuff that needs to go into the memory]

After lots of digging around what is known about the IPSF unlock, my best guess at this point is that the unlock system for the iPhone depends on the assumption that the baseband firmware would not be compromised. There seems to be no unit-specific unlock token in the seczone, just some status info that tells the baseband whether the phone is unlocked. A unit-specific unlock token is probably generated during legitimate unlocking from the unlock code and the IMEI (and perhaps a unique random seed for each unit kept in some well guarded database). However instead of storing this token in the security zone and have it verified each time the baseband wants to check the lock status of the phone, an unencrypted status code is stored in the seczone after each unlock attempt, which is what the baseband uses to determine the unlock status. The defense against unauthorized unlock is that only the baseband can write in the seczone, and the baseband is only supposed to execute authorized (Apple) code. IMO sloppy design, if that's what it is.

IPSF exploits a bug in the 3.x baseband bootloader that allows it to run any program it wants on the baseband, and thus can modify the seczone and set the status of the phone to "fully unlocked". If I am correct about the way iphone unlocking works, this is indeed indistinguishable from an authorized Apple unlock, in which the correct unlock code is entered, a token is generated, verified and discarded, and the same status code is written in the seczone.

Dev team, by contrast, exploits a different bug in the 3.x bootloader and patches the baseband firmware to change the way it behaves, in the same way as Geohot's famous hardware unlock. It then performs an unlock attempt with unlock code 0, which generates an invalid token, results in writing something invalid in the seczone, but as long as the baseband is patched, it treats the phone as "unlocked but lockable". This stops working if the baseband is subsequently flashed with stock (unpatched) firmware, either 3.x or 4.x, and when a SIM check is performed, the phone detects the invalid seczone info and enters a diagnostic mode with the 0049 IMEI... If the phone is rebooted with no SIM there is no SIM check, and thus no invalid IMEI.

I wonder whether skipping the unlock attempt with code 0 would avoid the invalid seczone information while still unlocking the phone as long as the firmware is patched. Perhaps the dev team can change the unlock process or patch the firmware a bit more, and avoid creating the invalid seczone information while still unlocking the phone.

I do not think IPSF necessarily had access to confidential Apple info. They may have been familiar with the Sgold2 (the baseband chip) as it is used in lots of other phones. I don't think that they needed access to the unlock code algorithm or database once they figured how to gain full control of the baseband. Perhaps Apple based the 3.x bootloader on code supplied by Infineon with the chip, so the IPSF exploit could be known to people involved with other Sgold2 devices. Looking forward, I do not think Apple bricked dev team unlocked phones on purpose. The stock 3.x firmware has the same effect on them as the stock 4.x firmware. Also I do not think they are likely to "break" the IPSF unlock, as it probably is just like a legitimate unlock. Unlocking 4.x baseband, especially the IPSF way that requires full access, will be challenging, as the known bugs seem to have been fixed. Dev team and ISPF seem to have their work cut out for them!

The above is pure speculation, so if you know better please correct me...

Hi,

Very good info, i can just add that there are 3 distinct pieces of code in the baseband:
bootcore, bootloader and image. In my view the biggest vulnerability is the fact
that the bootcore will not check the image integrity before passing execution to it
on every reset, but rather check it during the flashing process. This doesn't make
sense, but probably whoever coded it thought the security is overkill anyway and
shouldn't bother more. But both methods exploit same bootcore bug - either install
application at 0x20000 and update eeprom, or just flash patched nor image.

Still though the biggest protection is the activation. As we know now, even if we
have unlocked baseband, there is no way to unlock the samsung, because the
restore process kills the nand flash completly, no permanent data is left intact.
(Well i might be wrong here)

So dev team, prepare to be employed full time here ...

Originally Posted by mr_

[baseband: for the iphone, the Infineon SGold2 chip that is responsible for GSM/GPRS/Edge communications, among other things.
seczone: an area in the baseband's memory where important information like the lock status is stored.
IPSF: iphonesimfree, the makers of Simfree unlock software
bootloader: the "bootstrapping" program that is first loaded in a device's memory, and then loads the rest of the stuff that needs to go into the memory]

After lots of digging around what is known about the IPSF unlock, my best guess at this point is that the unlock system for the iPhone depends on the assumption that the baseband firmware would not be compromised. There seems to be no unit-specific unlock token in the seczone, just some status info that tells the baseband whether the phone is unlocked. A unit-specific unlock token is probably generated during legitimate unlocking from the unlock code and the IMEI (and perhaps a unique random seed for each unit kept in some well guarded database). However instead of storing this token in the security zone and have it verified each time the baseband wants to check the lock status of the phone, an unencrypted status code is stored in the seczone after each unlock attempt, which is what the baseband uses to determine the unlock status. The defense against unauthorized unlock is that only the baseband can write in the seczone, and the baseband is only supposed to execute authorized (Apple) code. IMO sloppy design, if that's what it is.

IPSF exploits a bug in the 3.x baseband bootloader that allows it to run any program it wants on the baseband, and thus can modify the seczone and set the status of the phone to "fully unlocked". If I am correct about the way iphone unlocking works, this is indeed indistinguishable from an authorized Apple unlock, in which the correct unlock code is entered, a token is generated, verified and discarded, and the same status code is written in the seczone.

Dev team, by contrast, exploits a different bug in the 3.x bootloader and patched the baseband software in the same way as Geohot's famous hardware unlock. Instead of running a program to change data in the seczone, it changes the way the baseband behaves by patching the 3.x firmware. It then performs an unlock attempt with unlock code 0, which generates an invalid token, results in writing something invalid in the seczone, but as long as the baseband is patched, it treats the phone as "unlocked but lockable". We know what happens if the baseband is subsequently flashed with stock (unpatched) firmware...

I do not know whether skipping the unlock attempt with code 0 would avoid the invalid seczone information. Perhaps the dev team can change the unlock process or patch the firmware a bit more, and avoid creating the invalid seczone information.

I do not think IPSF necessarily had inside Apple info. They may have been familiar with the Sgold2 (the baseband chip) as it is used in lots of other phones. It doesn't seem they needed access to the unlock code algorithm or database once they figured how to gain full control of the baseband. Perhaps Apple based the 3.x bootloader on code supplied by Infineon with the chip, so the IPSF exploit could be known to people involved with other Sgold2 devices. Looking forward, I do not think Apple bricked dev team unlocked phones on purpose. The stock 3.x firmware has the same effect on them as the stock 4.x firmware. Also I do not think they are likely to "break" the IPSF unlock, as it probably is just like a legitimate unlock. Unlocking 4.x baseband, especially the IPSF way that requires full access, will be challenging, as the known bugs seem to have been fixed. Dev team and ISPF seem to have their work cut out for them!

The above is pure speculation, so if you know better please correct me...

i kind of agree wit u and i feel ,if we can patch our phones ones with these , we should never have problems with newer updates, meanin after this we only need some mechanism to activate the phone each time ,

this would save everyone time, now i was wondering if some one can get the file that is being downloaded from the ipsf server ( again a speculation - but it seems to be the best guess) I have been tryin that ,

so far i have set up a ad hoc server of my iphone with my laptop ,and i can successfully access internet on my iphone using my laptop's wifi ,laptop intern is connected with lan, now i can log info using wireshark , i have also installed iphonesimfree (i havent bought a license yet),btw i have never used apache/ wireshark b4 , so now
1> i want info on how to make use of the data being logged by wireshark
2> create a fake server for iphonesimfree by using apache
and if we come this far then yes capture that file.

this method was posted by posted gcardinal
can anyone help me here?

tx

I think that the Dev Team and anybody involved in Unlock development should concentrate mainly on a process to allow a baseband fw 4.x downgrade to 3.x baseband fw. Such a solution would take a lot of "pressure" from FW 1.1.1 unlock solution development because people could enjoy their FW 1.0.2 unlocked phones, maybe even adding some of the FW 1.1.1 features sooner or later as soon as file system write access will be achieved after decrypting this FW version.
Just my personal opinion.

Originally Posted by 997TT

I think that the Dev Team and anybody involved in Unlock development should concentrate mainly on a process to allow a baseband fw 4.x downgrade to 3.x baseband fw. Such a solution would take a lot of "pressure" from FW 1.1.1 unlock solution development because people could enjoy their FW 1.0.2 unlocked phones, maybe even adding some of the FW 1.1.1 features sooner or later as soon as file system write access will be achieved after decrypting this FW version.
Just my personal opinion.

Couldn't agree more. Even syncing these days is dangerous. Once I almost flashed 1.1.1 by accident because iTunes froze the keyboard and processed the mouse clicks with the default action, that is to update the FW (very wierd approach: the default action on the update sequence dialogs is to do it!)

Enabling a full baseband downgrade will the user base to increase once again, and that's good and soon there will be some many nice apps that even the plain AT&T user will start to look into into, and maybe then Apple will see things differently.... who knows...

yeah, there was some talk last night about the packet dump containing the nck... it's highly unlikely. it's more likely that those large packets are just zipped hlloader and seczone files - ipsf contained them on their servers so people couldn't just pass a faked "go" command.

when geo patched the server check, he still had included the modded hlloader and seczone in the folder. thus, the ipsf binary didn't get the "go" command bc he patched it, but the bug in their program is that it still executes their code.

Originally Posted by JuniorJack

Hi,

Very good info, i can just add that there are 3 distinct pieces of code in the baseband:
bootcore, bootloader and image. In my view the biggest vulnerability is the fact
that the bootcore will not check the image integrity before passing execution to it
on every reset, but rather check it during the flashing process. This doesn't make
sense, but probably whoever coded it thought the security is overkill anyway and
shouldn't bother more. But both methods exploit same bootcore bug - either install
application at 0x20000 and update eeprom, or just flash patched nor image.

Still though the biggest protection is the activation. As we know now, even if we
have unlocked baseband, there is no way to unlock the samsung, because the
restore process kills the nand flash completly, no permanent data is left intact.
(Well i might be wrong here)

So dev team, prepare to be employed full time here ...

Nice info. Maybe someone should incorporate all this stuff into a wiki? We seem to have lots of people in this thread that have good info.

Todays security systems can't be broken by "direct" attacks. They are broken because of design flaws, like keys and root passwords in plaintext . And these flaws can be corrected in the next version. The first version iphone clearly underestimated the sophistication of the attacks and reflects an attitude that a lot of the security is an overkill anyway. But this seems to have changed with 1.1.1. With plans for the iphone to go on sale in Europe, there must have been an official unlock mechanism designed in it (as this is required by several EU countries), and it is possible that this mechanism was not designed with strong security (e.g., there may be no encrypted phone-specific unlock token).

Apple could change its phone unlocking mechanism in the future, but it is unlikely that would include erasing all permanent data in the baseband (unless that would somehow only affect IPSF unlocked phones and not legitimately unlocked ones). What if you have legitimately unlocked your phone, leave your provider, and years later you update to a baseband version that relocks your phone and you can't find a way to get in touch with anyone to give you new unlock code? That could be bad PR and/or liability, so Apple will probably shy away from this approach and focus on plugging the known vulnerabilities, as they seem to have done with 1.1.1 and 4.x. Their priority is to stop future exploits rather than punish its customers who already exploited past ones. As I said in other places, I don't believe the 4.x bricking of dev unlocked phones was intentional (although Apple obviously didn't design around it). Stock 3.x firmware bricks a dev unlocked phone the same way.