Help the dev team for the software unlock

When reading the FAQ posted by iphonesimfree it came to me that you definitely need to support the dev team to create a software unlock. I wrote a post earlier about the A17 trace and where it connects to on the pcb.

What I'm guessing the iphonesimfree people are doing is simply forcing the bit that enables the A17 trace through software. This software will be locked and will only work for this firmware. I believe they are using the reversing that Geo and his crew did. The problem is, without having an open documented system of how this unlock works, if the firmware is updated, you may have a locked phone again. You would most likely have to pay to get it unlocked again. Another issue is that if they are strictly using the information that Geo and his crew gathered they may not even have the capability of creating an unlock for the new firmware, unless Geo's crew reverses the newer firmware.

What is needed is to continue to document exactly what has been done with the Hardware hack. The reversing needs to be understood so it can be done in the future with firmware updates. The bit that enables the A17 trace must be found. With this information it would be nearly easy to create a software unlock and maintain it throughout firmware updates.

I hope this all makes some sense here. The point is to support the dev teams efforts, donate to them, keep the information about the iphone free and open so that everyone can keep an unlocked phone in the future :D

Absolutly, we need to support the Dev Team, but, before, we need some interesting news (and nothing like turboSim bla bla bla) !!!!!

Unfortunately that is impossible. A17 is an address line on the address bus of the baseband chip. It selects memory addresses the processing unit intends to read or write. By forcing it to be permanently high or low, a whole chunk in the memory map of the system is redirected to another physical area in the processing units address space (and another chunk is made inaccessible). The intended effect for the unlock hack is to make the baseband cpu see something at an otherwise inaccessible address that actually reasides in an accessible location elsewhere. Short of a hidden MMU in the system, there is no way to recreate the effect in Software.

IMHO there are 3-4 ways to achieve a software unlock:

A) Understand the algorithm that calculates the unlock key from personal phone data (such as IMEI or whatever it uses).
- Easy with a snitch, e.g. from Infineon
A1) Make the phone believe it operates with an IMEI (or whatever) for which an unlock key is known - for the time of the unlock check only.
B) Create outside events that trigger a state in which control can be taken away from the firmware and unsigned code can be executed elsewhere for the unlock check. E.g. stack manipulation, buffer overflows, corrupted interrupt handlers.
B1) As B, but with the intended effect of spoofing MCC and MNC at runtime.
C) Infuse a recovery image with manipulated but correctly signed firmware

If I would have to bet, I would go for a "B"ish scenario.

But alas, that's all speculation...

Hey Soopahfly,

So what you're saying is pulling that trace high basically allows the system to access another "part" of the memory that contains information that needs to be changed for the unlocking to work? If that's the case, wouldn't it be impossible for Apple to release an update that relocks the phone? At least something that couldn't be easily patched?

Because iphonesimfree's alleged solution requires software to be installed on the iphone, i was thinking along the lines of a simproxy running on the phone itself, but since it says it will survive a restore that might not be it..... maybe they found a way to patch the baseband firmware? (which we all know wasnt changed from 1.0.1 to x.x.2....

Quote:

---

Originally Posted by Soopahfly

Unfortunately that is impossible. A17 is an address line on the address bus of the baseband chip. It selects memory addresses the processing unit intends to read or write. By forcing it to be permanently high or low, a whole chunk in the memory map of the system is redirected to another physical area in the processing units address space (and another chunk is made inaccessible). The intended effect for the unlock hack is to make the baseband cpu see something at an otherwise inaccessible address that actually reasides in an accessible location elsewhere. Short of a hidden MMU in the system, there is no way to recreate the effect in Software.

IMHO there are 3-4 ways to achieve a software unlock:

A) Understand the algorithm that calculates the unlock key from personal phone data (such as IMEI or whatever it uses).
- Easy with a snitch, e.g. from Infineon
A1) Make the phone believe it operates with an IMEI (or whatever) for which an unlock key is known - for the time of the unlock check only.
B) Create outside events that trigger a state in which control can be taken away from the firmware and unsigned code can be executed elsewhere for the unlock check. E.g. stack manipulation, buffer overflows, corrupted interrupt handlers.
B1) As B, but with the intended effect of spoofing MCC and MNC at runtime.
C) Infuse a recovery image with manipulated but correctly signed firmware

If I would have to bet, I would go for a "B"ish scenario.

But alas, that's all speculation...

---

I don't think I quite understand B1. But what do you think about emulating what Turbo SIM does inside iPhone's OS? Clearly there's a software that reads the ICCID from the SIM card and sends it to the baseband. From what I understand, Turbo SIIM spoofs an ATT SIM card twice at initialization and then stops that and start supplying the correct number. Well, I'm not sure about all of this, but definately TurboSIM spoofs something at boot time that definately is not read directly by the BaseBand. So, there's a piece of software that can be reversed and patched so it does exactly what Turbo SIM does, maybe even better.

What do you think?

I'm not saying force A17 permanently. I'm saying toggle it as you would by using needles. The trace runs from the baseband chip to someplace (the cpu for address control) Changing the state on the CPU chip would create the intended effect of shorting the trace. I really don't understand how a hidden MMU would be of any assistance.