https://www.theiphonewiki.com/w/api.php?action=feedcontributions&user=Vaumnou&feedformat=atomThe iPhone Wiki - User contributions [en]2024-03-28T15:43:20ZUser contributionsMediaWiki 1.31.14https://www.theiphonewiki.com/w/index.php?title=Talk:GID_Key&diff=1573Talk:GID Key2008-08-06T21:10:56Z<p>Vaumnou: /* Vaumnou */ new section</p>
<hr />
<div>== drg ==<br />
<br />
Would this be vulnerable to a [http://en.wikipedia.org/wiki/Cold_boot_attack cold boot attack]?<br />
<br />
== geohot ==<br />
<br />
I really doubt the AES key is ever in memory. This is an attack against drive encryption, not hardware coprocessors. Fault analysis or timing would be our best bet.<br />
<br />
== Vaumnou ==<br />
<br />
Unless you can cause read faults by browning out the chip or the ROM is external, you can't use fault analysis. And if the ROM is external, it would probably be easier to unsolder it and read it directly.<br />
<br />
== pumpkin ==<br />
<br />
it isn't external<br />
<br />
== Vaumnou ==<br />
<br />
Then the only way to do fault analysis would be to poke around on the chip directly. Is it known whether the die is face-down or face-up on the PCB?<br />
<br />
== ta ==<br />
<br />
this sounds like a job for leet hacking super hero TA Mobile!<br />
<br />
== geohot ==<br />
<br />
Hopefully the amount of time varies from encrypt to encrypt, although I believe most AES engines are fixed in time.<br />
<br />
Browning out the chip is more what I was thinking. Probing the chip is far beyond my abilities, but I could brown the chip out for a clock cycle or two and determine where in the pipeline I am. I would need to know a lot more about the coprocessor design. It is standard? HDL model out there?<br />
<br />
== Vaumnou ==<br />
<br />
According to [http://en.wikipedia.org/wiki/Advanced_Encryption_Standard Wikipedia], the known timing attacks for AES are *cache* timing attacks. This won't work if the hardware crypto engine has one-cycle read access to its ROM, and I know of no reason why it wouldn't.</div>Vaumnouhttps://www.theiphonewiki.com/w/index.php?title=Talk:GID_Key&diff=1503Talk:GID Key2008-08-05T19:09:33Z<p>Vaumnou: /* Vaumnou */ new section</p>
<hr />
<div>== drg ==<br />
<br />
Would this be vulnerable to a [http://en.wikipedia.org/wiki/Cold_boot_attack cold boot attack]?<br />
<br />
== geohot ==<br />
<br />
I really doubt the AES key is ever in memory. This is an attack against drive encryption, not hardware coprocessors. Fault analysis or timing would be our best bet.<br />
<br />
== Vaumnou ==<br />
<br />
Unless you can cause read faults by browning out the chip or the ROM is external, you can't use fault analysis. And if the ROM is external, it would probably be easier to unsolder it and read it directly.<br />
<br />
== pumpkin ==<br />
<br />
it isn't external<br />
<br />
== Vaumnou ==<br />
<br />
Then the only way to do fault analysis would be to poke around on the chip directly. Is it known whether the die is face-down or face-up on the PCB?</div>Vaumnouhttps://www.theiphonewiki.com/w/index.php?title=Research:_Pwnage_Patches&diff=1475Research: Pwnage Patches2008-08-05T04:35:23Z<p>Vaumnou: </p>
<hr />
<div>If you have IDA Pro and you are at least semi-handy with ARM please contribute :)<br />
<br />
Thanks to CPICH for helping out!<br />
<br />
== 2.0 (5A347) iBoot ==<br />
<br />
=== Patched Area ===<br />
There is only 1 patch made to the iBoot, iLLB, iBEC, iBSS, and WTF.n82ap. They are all iBoots, pretty much, and they all have the same opcodes to their patches, so I am going to assume that they all have this same patch for the same reason. Please feel free to correct this if this is not true.<br />
<br />
Here is a snippet of it from IDA:<br />
<br />
ROM:1800587C 01 20 MOVS R0, #1 ; R1 = 1<br />
ROM:1800587E 40 42 NEGS R0, R0 ; PWNAGE PATCH<br />
ROM:1800587E ; Change 40 42 > 00 20<br />
ROM:1800587E ; That will make it:<br />
ROM:1800587E ; MOVS R0 = #0<br />
ROM:1800587E ;<br />
ROM:1800587E ; R0 (unpatched) = -1<br />
ROM:1800587E ; R0 (patched) = 0<br />
<br />
=== Why does this help us? ===<br />
ROM:18005D72 FF F7 D2 FC BL sub_1800571A ; Branch with Link<br />
<br />
That jumps to 0x1800571A. Why does that matter? well, the above "Patched Area" is at the end of this routine, and then we come back with our modified R0. Right after this BL, we get this, which is where our new R0 comes into play:<br />
<br />
ROM:18005D76 00 28 CMP R0, #0 ; Set cond. codes on Op1 - Op2<br />
ROM:18005D78 00 D0 BEQ loc_18005D7C ; Branch<br />
ROM:18005D7A 8A E0 B loc_18005E92 ; Branch<br />
<br />
If R0 = 0, which is does, it will jump to 0x18005D7C. If not, it will go to 0x18005E92. I don't know the nitty gritty, but basically this is to make it so that we jump to an earlier part in the file that we were supposed to. A further analysis may be in order, I will definitely get to that later.<br />
<br />
== 2.0 (5A347) DeviceTree ==<br />
<br />
=== Patched Area ===<br />
Easy one. Just two string patches<br />
<br />
==== Patch One ====<br />
At offset 0x30, "secure-root-prefix" is patched to "xxxxxx-root-prefix"<br />
<br />
==== Patch Two ====<br />
At offset 0x3344, "function-disable_keys" is patched to "xxxxxxxx-disable_keys". <br />
This would presumably prevent the hardware keys from being disabled at boot.<br />
<br />
=== Wait what? ===<br />
It seems to be a file full of strings. Taking into account I am a noob that has been on Windows almost all of my life and just recently moved to Mac stuff, I really don't know what else to say :P<br />
<br />
I do know that if someone knows where DeviceTree is in memory, I can look through other files to see what exactly references these offsets in a way that they need patching. As I look more and more into them, these pwnage patches seem to be getting more and more complex :P<br />
<br />
== 2.0 (5A347) [[Lockdownd]] ==<br />
This may actually confuse some people. You see, there is 'technically' two patches, but in reality, there is only one. The second one is the rehashed signature done with ldid, because you must remember that this is a userland binary, not a lower level one like the [[iBoot]], which resides in the [[NOR]]. These files on the main filesystem must cohere to the demands of the [[kernel]], and according to a [[devteam]] member, the patches to not require this were to complex and it would just be much easier to use ldid to take care of it. So that is what they did here. They took the original file, then one with the one patch that they needed, rehashed the patched one, BsDiff'd them, and then as you can now tell, the .patch tile contains the actual patch + the new sig :)<br />
<br />
(Be back in a little bit with actual snippets from IDA showing the actual patch done, I want to go through the actual low level stuff first)<br />
<br />
I don't think the dev team is using ldid because ldid changes the file size (i.e. asr sig patch added 0x20 bytes using ldid). However the same ldid method may work as well.</div>Vaumnouhttps://www.theiphonewiki.com/w/index.php?title=Research:_Pwnage_Patches&diff=1474Research: Pwnage Patches2008-08-05T04:35:07Z<p>Vaumnou: </p>
<hr />
<div>If you have IDA Pro and you are at least semi-handy with ARM please contribute :)<br />
<br />
Thanks to CPICH for helping out!<br />
<br />
== 2.0 (5A347) iBoot ==<br />
<br />
=== Patched Area ===<br />
There is only 1 patch made to the iBoot, iLLB, iBEC, iBSS, and WTF.n82ap. They are all iBoots, pretty much, and they all have the same opcodes to their patches, so I am going to assume that they all have this same patch for the same reason. Please feel free to correct this if this is not true.<br />
<br />
Here is a snippet of it from IDA:<br />
<br />
ROM:1800587C 01 20 MOVS R0, #1 ; R1 = 1<br />
ROM:1800587E 40 42 NEGS R0, R0 ; PWNAGE PATCH<br />
ROM:1800587E ; Change 40 42 > 00 20<br />
ROM:1800587E ; That will make it:<br />
ROM:1800587E ; MOVS R0 = #0<br />
ROM:1800587E ;<br />
ROM:1800587E ; R0 (unpatched) = -1<br />
ROM:1800587E ; R0 (patched) = 0<br />
<br />
=== Why does this help us? ===<br />
ROM:18005D72 FF F7 D2 FC BL sub_1800571A ; Branch with Link<br />
<br />
That jumps to 0x1800571A. Why does that matter? well, the above "Patched Area" is at the end of this routine, and then we come back with our modified R0. Right after this BL, we get this, which is where our new R0 comes into play:<br />
<br />
ROM:18005D76 00 28 CMP R0, #0 ; Set cond. codes on Op1 - Op2<br />
ROM:18005D78 00 D0 BEQ loc_18005D7C ; Branch<br />
ROM:18005D7A 8A E0 B loc_18005E92 ; Branch<br />
<br />
If R0 = 0, which is does, it will jump to 0x18005D7C. If not, it will go to 0x18005E92. I don't know the nitty gritty, but basically this is to make it so that we jump to an earlier part in the file that we were supposed to. A further analysis may be in order, I will definitely get to that later.<br />
<br />
== 2.0 (5A347) DeviceTree ==<br />
<br />
=== Patched Area ===<br />
Easy one. Just two string patches<br />
<br />
==== Patch One ====<br />
At offset 0x30, "secure-root-prefix" is patched to "xxxxxx-root-prefix"<br />
<br />
==== Patch Two ====<br />
At offset 0x3344, "function-disable_keys" is patched to "xxxxxxxx-disable_keys"<br />
This would presumably prevent the hardware keys from being disabled at boot.<br />
<br />
=== Wait what? ===<br />
It seems to be a file full of strings. Taking into account I am a noob that has been on Windows almost all of my life and just recently moved to Mac stuff, I really don't know what else to say :P<br />
<br />
I do know that if someone knows where DeviceTree is in memory, I can look through other files to see what exactly references these offsets in a way that they need patching. As I look more and more into them, these pwnage patches seem to be getting more and more complex :P<br />
<br />
== 2.0 (5A347) [[Lockdownd]] ==<br />
This may actually confuse some people. You see, there is 'technically' two patches, but in reality, there is only one. The second one is the rehashed signature done with ldid, because you must remember that this is a userland binary, not a lower level one like the [[iBoot]], which resides in the [[NOR]]. These files on the main filesystem must cohere to the demands of the [[kernel]], and according to a [[devteam]] member, the patches to not require this were to complex and it would just be much easier to use ldid to take care of it. So that is what they did here. They took the original file, then one with the one patch that they needed, rehashed the patched one, BsDiff'd them, and then as you can now tell, the .patch tile contains the actual patch + the new sig :)<br />
<br />
(Be back in a little bit with actual snippets from IDA showing the actual patch done, I want to go through the actual low level stuff first)<br />
<br />
I don't think the dev team is using ldid because ldid changes the file size (i.e. asr sig patch added 0x20 bytes using ldid). However the same ldid method may work as well.</div>Vaumnouhttps://www.theiphonewiki.com/w/index.php?title=Talk:GID_Key&diff=1460Talk:GID Key2008-08-04T21:49:32Z<p>Vaumnou: /* Vaumnou */ new section</p>
<hr />
<div>== drg ==<br />
<br />
Would this be vulnerable to a [http://en.wikipedia.org/wiki/Cold_boot_attack cold boot attack]?<br />
<br />
== geohot ==<br />
<br />
I really doubt the AES key is ever in memory. This is an attack against drive encryption, not hardware coprocessors. Fault analysis or timing would be our best bet.<br />
<br />
== Vaumnou ==<br />
<br />
Unless you can cause read faults by browning out the chip or the ROM is external, you can't use fault analysis. And if the ROM is external, it would probably be easier to unsolder it and read it directly.</div>Vaumnouhttps://www.theiphonewiki.com/w/index.php?title=Talk:Baseband_Bootrom&diff=680Talk:Baseband Bootrom2008-07-30T00:39:26Z<p>Vaumnou: /* ROM location */ new section</p>
<hr />
<div>==Q/A==<br />
How would someone even go about dumping the bootrom?<br />
<br />
== hardware ==<br />
<br />
most deff a hardware method. unless we found an exploit to dump it, but that would totally defeat the purpose, because we need a dump to find an exploit, and because if we found an exploit we wouldn't need to dump it again.<br />
<br />
== ROM location ==<br />
<br />
Is the bootrom part of the XGOLD IC, or is it external?</div>Vaumnouhttps://www.theiphonewiki.com/w/index.php?title=Talk:M68AP&diff=550Talk:M68AP2008-07-29T02:42:10Z<p>Vaumnou: </p>
<hr />
<div>== Screenshot ==<br />
<br />
Isn't that screenshot from the wrong version? -Vaumnou</div>Vaumnouhttps://www.theiphonewiki.com/w/index.php?title=Talk:M68AP&diff=549Talk:M68AP2008-07-29T02:42:00Z<p>Vaumnou: Screenshot</p>
<hr />
<div>== Screenshot ==<br />
<br />
Isn't that screenshot from the wrong version?</div>Vaumnouhttps://www.theiphonewiki.com/w/index.php?title=Tutorial:Unlock_iPhone_3G_with_TurboSim&diff=546Tutorial:Unlock iPhone 3G with TurboSim2008-07-29T02:38:38Z<p>Vaumnou: </p>
<hr />
<div>{{disclaimer}}<br />
<br />
This article is a step by step instruction to use a net-locked iPhone-3G with your (different) contract provider. <br />
<br />
This example: official provider: Swisscom (prepaid), contract provider: O2 Germany<br />
<br />
[[Image:Ip terminal.png]]<br />
<br />
----<br />
<br />
=== Motivation ===<br />
<br />
Everyone who dislikes pink T's, over-priced unlocked iPhones and likes investigating exciting techniques ... (a.s.o.)<br />
<br />
=== Prerequisites ===<br />
<br />
You need:<br />
* your jailbroken iPhone-3G with openssh installed (from cydia) and WLAN connection to your PC<br />
* putty, winscp (or equivalent mac proggies)<br />
* turboSim programming sw (http://dl.free.fr/pzijbVjXl/turbo-cable-utils-iPhone-0.7.0-rev3-firmware-v2.tar.gz)<br />
* turboSim app zero-g (http://www.bladox.com/pub/zerog-0.95.tar.gz)<br />
<br />
----<br />
<br />
=== Installation ===<br />
<br />
1. Put your official provider card (prepaid) together with turboSim into the sim card slot of your iPhone-3G. Google a little bit how to do this. IMHO it's a good idea to (TESA-)tape turboSim and SIM-card together (on upper surface, tape needs to clasp around the chip to the connection's side of the card, so there is no tape edge on the surface in direction of tension), otherwise your SIM can get stuck in your phone and you have to open it.<br />
<br />
2. unpack turbo-cable-utils and use Win''Scp to copy the contents of bin-iphonev2 to folder /bin/ on your iphone (user root, pass alpine)<br />
<br />
[[Image:Winscp_turbo-utils.png]]<br />
<br />
3. connect with putty to your iPhone (user root, pass alpine) (btw, changing your password is a good idea: passwd)<br />
<br />
4. change permissions<br />
<br />
chmod 755 /bin/turbo-*<br />
<br />
5. run turbo-info<br />
<br />
iPhone:~ root# turbo-info<br />
initializing modem<br />
modem initiated<br />
Kernel Version 1.2.7.0<br />
Serial Number <...><br />
OK. No Error<br />
<br />
''If this does not end with "ok" you have connection problems:''<br />
<br />
localhost:~ root# turbo-info<br />
initializing modem<br />
AT+CPMS="SM","SM"<br />
ERROR<br />
AT+CPMS?<br />
ERROR<br />
modem initiated<br />
Mobile Phone/Serial Cable Communication Error<br />
<br />
''Check your turboSim-Sim-pack, sometimes there are some bumps from the cutting process which need to be removed. If all electrical contacts work well, this error will vanish.''<br />
<br />
6. use Win''Scp to copy unpacked zero-g-trb to folder /private/var/root<br />
<br />
[[Image:Winscp_zerog.png]]<br />
<br />
7. run turbo-reset and then turbo-app to programme your turboSim<br />
<br />
iPhone:~ root# turbo-app zerog095.trb<br />
SRC zerog095.trb<br />
SIZE 1023<br />
initializing modem<br />
modem initiated<br />
OK. No Error<br />
<br />
You now should see zero-g sim app in settings -> phone -> sim applications (ignore the carrier, I took screen shots later on)<br />
<br />
[[Image:Ip_simapp.png]]<br />
<br />
[[Image:Ip_zerog.png]]<br />
<br />
9. Remove official card + turboSim and replace it with your contract card + turboSim, turbo-info should end with okay<br />
<br />
10. reboot / switch on/off phone<br />
<br />
I have to type in my SIM-Pin first<br />
<br />
[[Image:Ip_unlocksim.png]]<br />
<br />
then: no service, okay...<br />
<br />
[[Image:Ip_noservice.png]]<br />
<br />
10. commit green button of zero-g application, which appears after some seconds<br />
<br />
[[Image:Ip_zerog2.png]]<br />
<br />
11. Some timing problems? Lost carrier? Just closing... <br />
<br />
[[Image:Ip_noservice2.png]]<br />
<br />
'cos it works at the end...<br />
<br />
[[Image:Ip_unlocked.png]]<br />
<br />
----<br />
<br />
=== Status ===<br />
<br />
* calls okay (incoming, outgoing)<br />
* SMS okay (incoming, outgoing)<br />
* Still no data, possibly due to old SIM card. Don't know if USIM works, will see it in some days.<br />
<br />
=== Remarks ===<br />
<br />
* Could be, you could do the programming with your contract card too, so you don't have to massacre your official provider card. I didn't, because incidentally my official card was the first not to have contact issues. So I don't know, at the end.<br />
* Important is you get zero-g into your turboSim. So you could also try with a first gen iphone, probably this needs the other version of turbo-cable-utils (bin-iphonev1)</div>Vaumnouhttps://www.theiphonewiki.com/w/index.php?title=Tutorial:Unlock_iPhone_3G_with_TurboSim&diff=545Tutorial:Unlock iPhone 3G with TurboSim2008-07-29T02:38:32Z<p>Vaumnou: </p>
<hr />
<div>{{disclaimer}<br />
<br />
This article is a step by step instruction to use a net-locked iPhone-3G with your (different) contract provider. <br />
<br />
This example: official provider: Swisscom (prepaid), contract provider: O2 Germany<br />
<br />
[[Image:Ip terminal.png]]<br />
<br />
----<br />
<br />
=== Motivation ===<br />
<br />
Everyone who dislikes pink T's, over-priced unlocked iPhones and likes investigating exciting techniques ... (a.s.o.)<br />
<br />
=== Prerequisites ===<br />
<br />
You need:<br />
* your jailbroken iPhone-3G with openssh installed (from cydia) and WLAN connection to your PC<br />
* putty, winscp (or equivalent mac proggies)<br />
* turboSim programming sw (http://dl.free.fr/pzijbVjXl/turbo-cable-utils-iPhone-0.7.0-rev3-firmware-v2.tar.gz)<br />
* turboSim app zero-g (http://www.bladox.com/pub/zerog-0.95.tar.gz)<br />
<br />
----<br />
<br />
=== Installation ===<br />
<br />
1. Put your official provider card (prepaid) together with turboSim into the sim card slot of your iPhone-3G. Google a little bit how to do this. IMHO it's a good idea to (TESA-)tape turboSim and SIM-card together (on upper surface, tape needs to clasp around the chip to the connection's side of the card, so there is no tape edge on the surface in direction of tension), otherwise your SIM can get stuck in your phone and you have to open it.<br />
<br />
2. unpack turbo-cable-utils and use Win''Scp to copy the contents of bin-iphonev2 to folder /bin/ on your iphone (user root, pass alpine)<br />
<br />
[[Image:Winscp_turbo-utils.png]]<br />
<br />
3. connect with putty to your iPhone (user root, pass alpine) (btw, changing your password is a good idea: passwd)<br />
<br />
4. change permissions<br />
<br />
chmod 755 /bin/turbo-*<br />
<br />
5. run turbo-info<br />
<br />
iPhone:~ root# turbo-info<br />
initializing modem<br />
modem initiated<br />
Kernel Version 1.2.7.0<br />
Serial Number <...><br />
OK. No Error<br />
<br />
''If this does not end with "ok" you have connection problems:''<br />
<br />
localhost:~ root# turbo-info<br />
initializing modem<br />
AT+CPMS="SM","SM"<br />
ERROR<br />
AT+CPMS?<br />
ERROR<br />
modem initiated<br />
Mobile Phone/Serial Cable Communication Error<br />
<br />
''Check your turboSim-Sim-pack, sometimes there are some bumps from the cutting process which need to be removed. If all electrical contacts work well, this error will vanish.''<br />
<br />
6. use Win''Scp to copy unpacked zero-g-trb to folder /private/var/root<br />
<br />
[[Image:Winscp_zerog.png]]<br />
<br />
7. run turbo-reset and then turbo-app to programme your turboSim<br />
<br />
iPhone:~ root# turbo-app zerog095.trb<br />
SRC zerog095.trb<br />
SIZE 1023<br />
initializing modem<br />
modem initiated<br />
OK. No Error<br />
<br />
You now should see zero-g sim app in settings -> phone -> sim applications (ignore the carrier, I took screen shots later on)<br />
<br />
[[Image:Ip_simapp.png]]<br />
<br />
[[Image:Ip_zerog.png]]<br />
<br />
9. Remove official card + turboSim and replace it with your contract card + turboSim, turbo-info should end with okay<br />
<br />
10. reboot / switch on/off phone<br />
<br />
I have to type in my SIM-Pin first<br />
<br />
[[Image:Ip_unlocksim.png]]<br />
<br />
then: no service, okay...<br />
<br />
[[Image:Ip_noservice.png]]<br />
<br />
10. commit green button of zero-g application, which appears after some seconds<br />
<br />
[[Image:Ip_zerog2.png]]<br />
<br />
11. Some timing problems? Lost carrier? Just closing... <br />
<br />
[[Image:Ip_noservice2.png]]<br />
<br />
'cos it works at the end...<br />
<br />
[[Image:Ip_unlocked.png]]<br />
<br />
----<br />
<br />
=== Status ===<br />
<br />
* calls okay (incoming, outgoing)<br />
* SMS okay (incoming, outgoing)<br />
* Still no data, possibly due to old SIM card. Don't know if USIM works, will see it in some days.<br />
<br />
=== Remarks ===<br />
<br />
* Could be, you could do the programming with your contract card too, so you don't have to massacre your official provider card. I didn't, because incidentally my official card was the first not to have contact issues. So I don't know, at the end.<br />
* Important is you get zero-g into your turboSim. So you could also try with a first gen iphone, probably this needs the other version of turbo-cable-utils (bin-iphonev1)</div>Vaumnouhttps://www.theiphonewiki.com/w/index.php?title=Template:Disclaimer&diff=544Template:Disclaimer2008-07-29T02:38:18Z<p>Vaumnou: New page: ''By following these instructions, you acknowledge your responsibility for any damage you cause to your device, and you recognize that you may void your iPhone's warranty.''</p>
<hr />
<div>''By following these instructions, you acknowledge your responsibility for any damage you cause to your device, and you recognize that you may void your iPhone's warranty.''</div>Vaumnouhttps://www.theiphonewiki.com/w/index.php?title=Tutorial:Unlock_iPhone_3G_with_TurboSim&diff=543Tutorial:Unlock iPhone 3G with TurboSim2008-07-29T02:36:40Z<p>Vaumnou: Cleaned up warning</p>
<hr />
<div>''By following these instructions, you acknowledge your responsibility for any damage you cause to your device, and you recognize that you will void your iPhone's warranty.''<br />
<br />
This article is a step by step instruction to use a net-locked iPhone-3G with your (different) contract provider. <br />
<br />
This example: official provider: Swisscom (prepaid), contract provider: O2 Germany<br />
<br />
[[Image:Ip terminal.png]]<br />
<br />
----<br />
<br />
=== Motivation ===<br />
<br />
Everyone who dislikes pink T's, over-priced unlocked iPhones and likes investigating exciting techniques ... (a.s.o.)<br />
<br />
=== Prerequisites ===<br />
<br />
You need:<br />
* your jailbroken iPhone-3G with openssh installed (from cydia) and WLAN connection to your PC<br />
* putty, winscp (or equivalent mac proggies)<br />
* turboSim programming sw (http://dl.free.fr/pzijbVjXl/turbo-cable-utils-iPhone-0.7.0-rev3-firmware-v2.tar.gz)<br />
* turboSim app zero-g (http://www.bladox.com/pub/zerog-0.95.tar.gz)<br />
<br />
----<br />
<br />
=== Installation ===<br />
<br />
1. Put your official provider card (prepaid) together with turboSim into the sim card slot of your iPhone-3G. Google a little bit how to do this. IMHO it's a good idea to (TESA-)tape turboSim and SIM-card together (on upper surface, tape needs to clasp around the chip to the connection's side of the card, so there is no tape edge on the surface in direction of tension), otherwise your SIM can get stuck in your phone and you have to open it.<br />
<br />
2. unpack turbo-cable-utils and use Win''Scp to copy the contents of bin-iphonev2 to folder /bin/ on your iphone (user root, pass alpine)<br />
<br />
[[Image:Winscp_turbo-utils.png]]<br />
<br />
3. connect with putty to your iPhone (user root, pass alpine) (btw, changing your password is a good idea: passwd)<br />
<br />
4. change permissions<br />
<br />
chmod 755 /bin/turbo-*<br />
<br />
5. run turbo-info<br />
<br />
iPhone:~ root# turbo-info<br />
initializing modem<br />
modem initiated<br />
Kernel Version 1.2.7.0<br />
Serial Number <...><br />
OK. No Error<br />
<br />
''If this does not end with "ok" you have connection problems:''<br />
<br />
localhost:~ root# turbo-info<br />
initializing modem<br />
AT+CPMS="SM","SM"<br />
ERROR<br />
AT+CPMS?<br />
ERROR<br />
modem initiated<br />
Mobile Phone/Serial Cable Communication Error<br />
<br />
''Check your turboSim-Sim-pack, sometimes there are some bumps from the cutting process which need to be removed. If all electrical contacts work well, this error will vanish.''<br />
<br />
6. use Win''Scp to copy unpacked zero-g-trb to folder /private/var/root<br />
<br />
[[Image:Winscp_zerog.png]]<br />
<br />
7. run turbo-reset and then turbo-app to programme your turboSim<br />
<br />
iPhone:~ root# turbo-app zerog095.trb<br />
SRC zerog095.trb<br />
SIZE 1023<br />
initializing modem<br />
modem initiated<br />
OK. No Error<br />
<br />
You now should see zero-g sim app in settings -> phone -> sim applications (ignore the carrier, I took screen shots later on)<br />
<br />
[[Image:Ip_simapp.png]]<br />
<br />
[[Image:Ip_zerog.png]]<br />
<br />
9. Remove official card + turboSim and replace it with your contract card + turboSim, turbo-info should end with okay<br />
<br />
10. reboot / switch on/off phone<br />
<br />
I have to type in my SIM-Pin first<br />
<br />
[[Image:Ip_unlocksim.png]]<br />
<br />
then: no service, okay...<br />
<br />
[[Image:Ip_noservice.png]]<br />
<br />
10. commit green button of zero-g application, which appears after some seconds<br />
<br />
[[Image:Ip_zerog2.png]]<br />
<br />
11. Some timing problems? Lost carrier? Just closing... <br />
<br />
[[Image:Ip_noservice2.png]]<br />
<br />
'cos it works at the end...<br />
<br />
[[Image:Ip_unlocked.png]]<br />
<br />
----<br />
<br />
=== Status ===<br />
<br />
* calls okay (incoming, outgoing)<br />
* SMS okay (incoming, outgoing)<br />
* Still no data, possibly due to old SIM card. Don't know if USIM works, will see it in some days.<br />
<br />
=== Remarks ===<br />
<br />
* Could be, you could do the programming with your contract card too, so you don't have to massacre your official provider card. I didn't, because incidentally my official card was the first not to have contact issues. So I don't know, at the end.<br />
* Important is you get zero-g into your turboSim. So you could also try with a first gen iphone, probably this needs the other version of turbo-cable-utils (bin-iphonev1)</div>Vaumnouhttps://www.theiphonewiki.com/w/index.php?title=Brick&diff=535Brick2008-07-29T01:38:58Z<p>Vaumnou: </p>
<hr />
<div>The term "bricked" refers to nonfunctional device states. Though nominally meaning that the device is permanently damaged, in practice it includes conditions which range from trivially recoverable (a failed update) to completely unrecoverable (in certain cases involving damaged baseband memory). A phone may be referred to as "bricked" if it will not boot, will not respond to input, will not make calls, etc. Early unlock solutions frequently resulted in partially-bricked phones after firmware updates were applied. Generally speaking, the iPhone is quite difficult to brick permanently via software methods, and in almost all cases the damage can be reversed. It is impossible to brick your phone by [[jailbreak|jailbreaking]] it, since the jailbreak does not affect the low-level recovery modes of the firmware, and hence it is always possible to un-jailbreak via iTunes. These safety factors do not necessarily apply if you modify your bootloader and/or baseband.</div>Vaumnouhttps://www.theiphonewiki.com/w/index.php?title=Brick&diff=534Brick2008-07-29T01:37:39Z<p>Vaumnou: </p>
<hr />
<div>The term "bricked" refers to nonfunctional device states. Though nominally meaning that the device is permanently damaged, in practice it includes conditions which range from trivially recoverable (a failed update) to completely unrecoverable (in certain cases involving damaged baseband memory). A phone may be referred to as "bricked" if it will not boot, will not respond to input, will not make calls, etc. Early unlock solutions frequently resulted in partially-bricked phones after firmware updates were applied. Generally speaking, the iPhone is quite difficult to brick permanently via software methods, and in almost all cases the damage can be reversed. It is impossible to brick your phone by [[jailbreak|jailbreaking]] it, since the jailbreak does not affect the low-level recovery modes of the firmware.</div>Vaumnouhttps://www.theiphonewiki.com/w/index.php?title=Brick&diff=533Brick2008-07-29T01:37:08Z<p>Vaumnou: </p>
<hr />
<div>The term "bricked" refers to nonfunctional device states. Though nominally meaning that the device is permanently damaged, in practice it includes conditions which range from trivially recoverable (a failed update) to completely unrecoverable (in certain cases involving damaged baseband memory). A phone may be referred to as "bricked" if it will not boot, will not respond to input, will not make calls, etc. Early unlock solutions frequently resulted in partially-bricked phones after firmware updates were applied. Generally speaking, the iPhone is quite difficult to brick permanently via software methods, and in almost all cases the damage can be reversed. It is impossible to brick your phone by [[jailbreaking]] it, since the jailbreak does not affect the low-level recovery features of the hardware.</div>Vaumnouhttps://www.theiphonewiki.com/w/index.php?title=Unlock&diff=532Unlock2008-07-29T01:35:15Z<p>Vaumnou: </p>
<hr />
<div>This is the process by which the iPhone baseband is modified to accept the SIM card of any GSM carrier. This is entirely different than a [[Jailbreak]]. Unlocked iPhones may be [[bricked]] by updating the baseband (and firmware) before waiting for a safe upgrade path. However, the brick state can generally be reversed, one way or another.</div>Vaumnouhttps://www.theiphonewiki.com/w/index.php?title=Brick&diff=531Brick2008-07-29T01:34:38Z<p>Vaumnou: </p>
<hr />
<div>The term "bricked" refers to nonfunctional device states. Though nominally meaning that the device is permanently damaged, in practice it includes conditions which range from trivially recoverable (a failed update) to completely unrecoverable (in certain cases involving damaged baseband memory). A phone may be referred to as "bricked" if it will not boot, will not respond to input, will not make calls, etc. Early unlock solutions frequently resulted in partially-bricked phones after firmware updates were applied. Generally speaking, the iPhone is quite difficult to brick permanently via software methods, and in almost all cases the damage can be reversed.</div>Vaumnouhttps://www.theiphonewiki.com/w/index.php?title=Brick&diff=530Brick2008-07-29T01:33:53Z<p>Vaumnou: New page: The term "bricked" refers to nonfunctional device conditions. Though nominally meaning that the device is permanently damaged, in practice it includes states which range from trivially re...</p>
<hr />
<div>The term "bricked" refers to nonfunctional device conditions. Though nominally meaning that the device is permanently damaged, in practice it includes states which range from trivially recoverable (a failed update) to completely unrecoverable (in certain cases involving damaged baseband memory). A phone may be referred to as "bricked" if it will not boot, will not respond to input, will not make calls, etc. Early unlock solutions frequently resulted in partially-bricked phones after firmware updates were applied. Generally speaking, the iPhone is quite difficult to brick permanently via software methods.</div>Vaumnouhttps://www.theiphonewiki.com/w/index.php?title=User_talk:Zibri&diff=477User talk:Zibri2008-07-28T21:15:10Z<p>Vaumnou: </p>
<hr />
<div>Let's keep things civilized ;) -drg<br />
<br />
He leaked it, not published it ;) -wEsTbAeR--<br />
<br />
I think we should create a policy right from the inception of this wiki regarding the balance of credit and blame, facts and history. There are many... *cough* strong personalities involved in various aspects of the iPhone homebrew scene, and due to the clashing of some of these personalities many enemies have been created and multiple interpretations of the timeline have been debated endlessly on forums and blogs. While historical, these events are somewhat less than relevant to the interests of wiki readers, and they have every possible chance of descending into edit-wars and flame-fests. I think we all feel that topics should be presented from a factual and neutral point-of-view. My recommendation is that the policy of the iPhone wiki should be to give credit where credit is due, but remove instances of blame and ill-will. Credit is great. Blame adds nothing useful to the discussion. With a constructive atmosphere built on credit, we will attract useful contributions from both sides of the issue. -Vaumnou</div>Vaumnouhttps://www.theiphonewiki.com/w/index.php?title=ZiPhone&diff=451ZiPhone2008-07-28T19:51:42Z<p>Vaumnou: Neutral POV</p>
<hr />
<div>[[Zibri]]'s tool to unlock, jailbreak, and activate.<br />
<br />
It makes use of the [[Ramdisk Hack]] and uses geohot's BL4.6 exploit to unlock the baseband.<br />
<br />
While the tool was popular, accusations of plagiarism and worse were leveled at Zibri. His name, and that of the program, have become mired in controversy.</div>Vaumnou