IPSF reversing started any help ;)

[deepdark]

so this is a little info about the executable inside:

seg000:00010930 41 70 70 6C 65 42 61 73 65 62 61 6E 64 00 00 00 AppleBaseband...
seg000:00010940 25 64 2E 25 64 2E 25 64 00 00 00 00 00 00 00 00 %d.%d.%d........
seg000:00010950 4C 61 75 6E 63 68 43 46 4D 41 70 70 00 00 00 00 LaunchCFMApp....

so they are basicly uploading the baseband form DEvteam and ... lets see whats inside

[pendalf]

do you thing, they just compare the imei from the iphone to the imei list on the server and stop the soft till it is confirmed.

or does they send some stuff to the iphone to continue...???

[deepdark]

i think that this is the procesure of taking the Phone IMEI and SERIAL

seg000:000128B0 2F 62 69 6E 2F 6C 61 75 6E 63 68 63 74 6C 20 6C /bin/launchctl l
seg000:000128C0 6F 61 64 20 2F 53 79 73 74 65 6D 2F 4C 69 62 72 oad /System/Libr
seg000:000128D0 61 72 79 2F 4C 61 75 6E 63 68 44 61 65 6D 6F 6E ary/LaunchDaemon
seg000:000128E0 73 2F 63 6F 6D 2E 61 70 70 6C 65 2E 43 6F 6D 6D s/com.apple.Comm
seg000:000128F0 43 65 6E 74 65 72 2E 70 6C 69 73 74 00 00 00 00 Center.plist....
seg000:00012900 44 45 56 5F 49 43 45 5F 4D 4F 44 45 4D 5F 30 33 DEV_ICE_MODEM_03
seg000:00012910 2E 31 34 2E 30 38 5F 47 00 00 00 00 00 00 00 00 .14.08_G........
seg000:00012920 44 45 56 5F 49 43 45 5F 4D 4F 44 45 4D 5F 30 33 DEV_ICE_MODEM_03
seg000:00012930 2E 31 32 2E 30 36 5F 47 00 00 00 00 00 00 00 00 .12.06_G........

[deepdark]

and the App is connection to the unlock server :

seg000:00012A60 62 79 74 65 73 00 00 00 00 00 00 00 00 00 00 00 bytes...........
seg000:00012A70 6C 65 6E 67 74 68 00 00 00 00 00 00 00 00 00 00 length..........
seg000:00012A80 69 6E 69 74 57 69 74 68 42 79 74 65 73 3A 6C 65 initWithBytes:le
seg000:00012A90 6E 67 74 68 3A 00 00 00 00 00 00 00 00 00 00 00 ngth:...........
seg000:00012AA0 73 65 74 48 54 54 50 4D 65 74 68 6F 64 3A 00 00 setHTTPMethod:..
seg000:00012AB0 55 52 4C 57 69 74 68 53 74 72 69 6E 67 3A 00 00 URLWithString:..
seg000:00012AC0 73 65 74 55 52 4C 3A 00 00 00 00 00 00 00 00 00 setURL:.........
seg000:00012AD0 73 65 74 43 61 63 68 65 50 6F 6C 69 63 79 3A 00 setCachePolicy:.
seg000:00012AE0 73 65 74 54 69 6D 65 6F 75 74 49 6E 74 65 72 76 setTimeoutInterv
seg000:00012AF0 61 6C 3A 00 00 00 00 00 00 00 00 00 00 00 00 00 al:.............
seg000:00012B00 73 65 74 56 61 6C 75 65 3A 66 6F 72 48 54 54 50 setValue:forHTTP
seg000:00012B10 48 65 61 64 65 72 46 69 65 6C 64 3A 00 00 00 00 HeaderField:....
seg000:00012B20 73 65 74 48 54 54 50 42 6F 64 79 3A 00 00 00 00 setHTTPBody:....
seg000:00012B30 73 65 6E 64 53 79 6E 63 68 72 6F 6E 6F 75 73 52 sendSynchronousR
seg000:00012B40 65 71 75 65 73 74 3A 72 65 74 75 72 6E 69 6E 67 equest:returning
seg000:00012B50 52 65 73 70 6F 6E 73 65 3A 65 72 72 6F 72 3A 00 Response:error:.
seg000:00012B60 73 74 61 74 75 73 43 6F 64 65 00 00 00 00 00 00 statusCode......
seg000:00012B70 64 6F 6D 61 69 6E 00 00 00 00 00 00 00 00 00 00 domain..........
seg000:00012B80 63 6F 64 65 00 00 00 00 00 00 00 00 00 00 00 00 code............
seg000:00012B90 6C 6F 63 61 6C 69 7A 65 64 44 65 73 63 72 69 70 localizedDescrip
seg000:00012BA0 74 69 6F 6E 00 00 00 00 00 00 00 00 00 00 00 00 tion............
seg000:00012BB0 71 34 38 31 33 36 32 30 36 32 30 34 38 32 34 32 q481362062048242
seg000:00012BC0 31 34 31 33 35 32 31 39 32 31 32 31 38 33 32 31 1413521921218321
seg000:00012BD0 39 33 31 38 36 31 30 38 31 37 37 39 33 34 31 31 9318610817793411
seg000:00012BE0 32 39 31 34 30 3A 00 00 00 00 00 00 00 00 00 00 29140:..........
seg000:00012BF0 71 31 38 33 32 34 37 32 35 30 31 33 39 31 35 33 q183247250139153
seg000:00012C00 32 31 39 32 34 39 32 33 31 37 38 32 34 33 38 31 2192492317824381
seg000:00012C10 38 32 31 38 39 31 35 39 39 33 33 38 33 34 39 31 8218915993383491
seg000:00012C20 39 30 32 31 33 3A 00 00 00 00 00 00 00 00 00 00 90213:..........

etc .. ect

and communication

seg000:00013240 32 39 30 33 35 39 33 35 31 32 30 30 31 34 39 31 2903593512001491
seg000:00013250 30 31 37 31 37 00 00 00 00 00 00 00 00 00 00 00 01717...........
seg000:00013260 76 31 36 40 30 3A 34 72 2A 38 72 2A 31 32 00 00 v16@0:4r*8r*12..
seg000:00013270 69 31 36 40 30 3A 34 2A 38 49 31 32 00 00 00 00 i16@0:4*8I12....
seg000:00013280 63 31 32 40 30 3A 34 72 2A 38 00 00 00 00 00 00 c12@0:4r*8......
seg000:00013290 69 32 34 40 30 3A 34 49 38 2A 31 32 49 31 36 2A i24@0:4I8*12I16*
seg000:000132A0 32 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20..............
seg000:000132B0 69 31 32 40 30 3A 34 49 38 00 00 00 00 00 00 00 i12@0:4I8.......
seg000:000132C0 2A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *...............
seg000:000132D0 40 22 4E 53 44 61 74 61 22 00 00 00 00 00 00 00 @"NSData".......
seg000:000132E0 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 @...............
seg000:000132F0 5B 32 35 36 43 5D 00 00 00 00 00 00 00 00 00 00 [256C]..........
seg000:00013300 69 70 68 6F 6E 65 73 69 6D 66 72 65 65 2E 63 6F iphonesimfree.co
seg000:00013310 6D 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 m...............




come on some TCP dump anybody....

[Diet]

so they are basicly uploading the baseband form DEvteam and ... lets see whats inside
I think the much more interesting question is how they do the upload without using the testpoint method of geohot ...
And probably they do not upload the complete baseband firmware since this would take much longer than the time the unlocking application is actually running. So I assume they only patch the necessary bytes in the baseband firmware (provided that is possible without deleting/reflashing).

[deepdark]

t think that they know exactly yhe adress of the baseband where to attack on him so we shuld find the TRACE from which part of baseband they are putting???

here is the IDA-View-A and HEx View-A use IDA 5 ;)

http://rapidshare.com/files/54907656/bbsimfree.idb

cheers

[deepdark]

Like i analayzed the application is standalone he hase no LINKS to other applications NO IMPORTS and EXPORTS strange ???

[rockgyeon]

maybe compare the original Firmware with Patched Firmware with IPSF ,could find something useful

[Diet]

As I wrote in this post (http://www.hackint0sh.org/forum/showthread.php?p=43023#post43023):
Its working! But for my IPhone it said, that the IPhone already unlocked... (I made HW unlock week ago)
Hey - that's very interesting indeed! That means that they use the same unlock procedure as geohot, i.e. patching the two bytes in the baseband firmware ...
So the only thing we have to find out is how they manage to update these bytes without the testpoint method geohot used.

[Snowbird]

come on some TCP dump anybody....

Have asked already, no one seems to have done one....

[deepdark]

As I wrote in this post (http://www.hackint0sh.org/forum/showthread.php?p=43023#post43023):

Hey - that's very interesting indeed! That means that they use the same unlock procedure as geohot, i.e. patching the two bytes in the baseband firmware ...
So the only thing we have to find out is how they manage to update these bytes without the testpoint method geohot used.



maybe this is that location:


seg000:0001EEF0 00 5F 76 6D 5F 64 65 61 6C 6C 6F 63 61 74 65 00 ._vm_deallocate.
seg000:0001EF00 5F 76 6D 5F 72 65 67 69 6F 6E 5F 36 34 00 5F 77 _vm_region_64._w
seg000:0001EF10 72 69 74 65 00 00 00 00 rite....

[Children Of Doom]

edit sorry double post!

[Children Of Doom]

As I wrote in this post (http://www.hackint0sh.org/forum/showthread.php?p=43023#post43023):

Hey - that's very interesting indeed! That means that they use the same unlock procedure as geohot, i.e. patching the two bytes in the baseband firmware ...
So the only thing we have to find out is how they manage to update these bytes without the testpoint method geohot used.

yep....
they've used much part of the work of the dev taem... :mad:

[Cracker]

Ofcourse the baseband is being patched. This is back to square one. The problem to solve has always been how to patch the baseband without physically touching the test point.

I am all for reversing the software, but we really need people out there who know their stuff.

All you guys are helping and it is great. I have a locked iphone, I have iphone sim free app but no license yet...

[orre]

This maybe no help at all, but I have an 4GB iPhone and get the error:
"Unlock failed. Error unlock currently unauthorized or unavailable for this phone. Please contact your retailer".

[mtheojg]

As I wrote in this post (http://www.hackint0sh.org/forum/showthread.php?p=43023#post43023):

Hey - that's very interesting indeed! That means that they use the same unlock procedure as geohot, i.e. patching the two bytes in the baseband firmware ...
So the only thing we have to find out is how they manage to update these bytes without the testpoint method geohot used.

No. It may just mean that they query the modem with AT commands and he says it's unlocked already. That's what AT+CLCK="PN",2 is for.

[Diet]

No. It may just mean that they query the modem with AT commands and he says it's unlocked already. That's what AT+CLCK="PN",2 is for.
sad but true :( So my idea seems to be useless ...

[teamare2006]

can we use the same technique that DVDJONE has used to activate the phone (Activation Server) here in software unlocking if it goes to their server for authentication of the phone

[deepdark]

i think that we must jump the Server authentification process? but the QUESTION is about Do the software is downloading something from server or is exchanging just informations?

[Snowbird]

maybe this is that location:


seg000:0001EEF0 00 5F 76 6D 5F 64 65 61 6C 6C 6F 63 61 74 65 00 ._vm_deallocate.
seg000:0001EF00 5F 76 6D 5F 72 65 67 69 6F 6E 5F 36 34 00 5F 77 _vm_region_64._w
seg000:0001EF10 72 69 74 65 00 00 00 00 rite....


Indeed. Re: vm_region_64. Common Apple routine in MacOS. Here's what it does.

routine vm_region_64(
#endif
target_task : vm_map_t;
inout address : mach_vm_address_t;
out size : mach_vm_size_t;
flavor : vm_region_flavor_t;
out info : vm_region_info_t, CountInOut;
out object_name : memory_object_name_t =
MACH_MSG_TYPE_MOVE_SEND
ctype: mach_port_t);

/*
* Allow application level processes to create named entries which
* correspond to mapped portions of their address space. These named
* entries can then be manipulated, shared with other processes in
* other address spaces and ultimately mapped in other address spaces


vm_deallocate set's the maximum protection attribute for the specified range of the virtual address space of the target virtual memory map.

[dazzled]

that means that your IMEI and Serial NO are not in the IPSF database so the app can't begin unlocking your iphone

[Snowbird]

re: does it download something? Yes. More than just 1 file. No doubt, this is the patch...that it copies to a working tmp directory during the unlock and this is were it does the patching I assume and then copies the patched files to the correct places, tests them and then cleans up after itself.

Would be nice to fugu or WinSCP to the iphone during the patching to see what it's coping before the cleanup.

[Draken]

or even better, turn the wifi off before clean up. SSH in, check for new stuff, and do a memory dump ?

[Cracker]

I think the cleanup will just run even if wifi is off.

You could hard reset your phone before it's cleaning up or just log in while it is doing everything and capture it that way.

If indeed it is a file/s copied to the phone then these may be all we need. Then again it still may have some code in the simfree app itself that triggers the hole to be able to update the baseband.

[MetalRat]

or simply copy the files out of the way after killing the process...
or just kill the process once the download has been completed...

There are hundreds of ways to do this.... the question really is are they even writing stuff to disk....? They may just be keeping it in memory.

[Diet]

I think the cleanup will just run even if wifi is off.
You could hard reset your phone before it's cleaning up or just log in while it is doing everything and capture it that way.
If indeed it is a file/s copied to the phone then these may be all we need. Then again it still may have some code in the simfree app itself that triggers the hole to be able to update the baseband.
perhaps we should also have a look at the other applications in the simfree.app directory: kill, rm and - most interesting - sh! if we just delete the rm application (in the app directory and in the appropriate system folder(s) of the iPhone), a cleanup should be impossible after unlock ;) and we should investigate the sh executable if that's something special or the standard sh command.

[pendalf]

i found this, could be easier way:

There is a few simple steps we have to do to get this working.

Step by step
1. Someone has to buy the software form iphonesimfree.

2. Setup wifi ad-hoc connection between a PC and iPhone.
2.1 Let's say PC has xDSL connection and its routed to iPhone using wifi ad-hoc
2.2 Install wireshark or any other software to capture all the network packages.

3. Make sure that all other application that can/are/etc using internet connection on PC are disabled.
3.1 Check in wireshark that "nothing" happens on network at all.
3.2 Visit a very simple page on iphone using wifi ad-hoc connection and make sure that package are captured in wireshark.

4. Start the unlocking process and hopefully capturing what the iphonesimfree software does on the internet.
4.1 Here we are specially looking for:
4.1.1 Authorization server.
4.1.2 Package to the server with authorization request
4.1.3 Response from the main server to the request

5. Isolate request/respond packages
5.1 Repeat steps on serveral phones in order determ if there is any calculations on the auth server. If so find way to replicate it.

6. Setup "fake" apache/IIS/etc server to replicate request/respond packages
6.1. Here use of PHP/Perl would be great if calculations are needed or even a java application,

7. Redirecting from real server to fake one by editing x:\WINDOWS\system32\drivers\etc\hosts

8. Posting the solution here for everyone to see :)

[jacoch]

Your steps suppose that there are no additional files uploaded to the phone. In such case, you should add a step to get that files and keep them safe.

Once the whole process is understood, 2 options are available. Mimick IPSF server like dvd jone as you suggest, or reverse the code to know how put bb firmware in rw state so a new app can be written.

[pendalf]

Your steps suppose that there are no additional files uploaded to the phone. In such case, you should add a step to get that files and keep them safe.

Once the whole process is understood, 2 options are available. Mimick IPSF server like dvd jone as you suggest, or reverse the code to know how put bb firmware in rw state so a new app can be written.

this aren´t my steps!

but anyway he was assuming,
that ipsf does not send any files,
this has been just confrmed,
that they does...

[eduz]

If the phone app really download some files it will be necessary another step after 6.1 on the procedure above, to put the files downloaded in the IPSF temp dir.

[fgrep]

A better IDA database if someone want.

http://r****share.com/files/54930487/bbsimfree.rar.html

[Snowbird]

I think the cleanup will just run even if wifi is off.

You could hard reset your phone before it's cleaning up or just log in while it is doing everything and capture it that way.

If indeed it is a file/s copied to the phone then these may be all we need. Then again it still may have some code in the simfree app itself that triggers the hole to be able to update the baseband.

This could be dangerous to do though, since 1) it could result in IPSF's server thinking that you've already activated your iPhone and refuse to re-run the unlock or 2) that the phone would no longer work because the entire procedure did not complete and the end result being that of a unsuccessful HW unlock that went wrong.

[haldor64]

pcap dump, anyone?

Any additional files downloaded by Simfree.app can be extracted in Wireshark by the "follow stream" option.
You can also extract files with Honeysnap.
http://www.honeynet.org/tools/honeysnap/

Anyone using the debugger?
http://iphone.fiveforty.net/wiki/index.php/Toolchain_Project#weasel

[gcardinal]

Downloading files or not, the main point here that we can mimic the main server.
Those lines was more a general how-to create a dump for users.

I just cant wait to see that complete dump!:)

Even I dont have iPhone I find this quite excited. (getting one in 1 week)...

[Azurael]

All we'd need to do is to write a server that gives the app the answers it wants and re-write the request in the hosts file on the iPhone... It would give people a working, free unlock, albeit illegally (the morality of which is down to the individual, I think, but you'd have to be using [I presume] an illegally-obtained copy of the IPSF app, which regardless of the legality of 'fooling' it using a fake server, is out. However, the morality of IPSF 'stealing' Geohot's unlock method if they did is also questionable.)

Ultimately though, we need to work out how it gets round the requirement for testpoint activation to write into the baseband firmware.

[Cracker]

It's late here but I have everything needed besides a locked iphone. I have this at work, still in it's plastic factory seal.

If no one has done the required steps by the morning, and I manage to get my license then we may be in business.

[haldor64]

http://johnspornreviews.com/iphone.html

[GPUnique]

http://johnspornreviews.com/iphone.html

Call me crazy but I'm a little skeptical downloading from such a wholesome site. But I hope it works all the same.

[waydownwear]

http://johnspornreviews.com/iphone.html

WTF is this??? :confused:

[hordur]

I think the cleanup will just run even if wifi is off.

You could hard reset your phone before it's cleaning up or just log in while it is doing everything and capture it that way.

If indeed it is a file/s copied to the phone then these may be all we need. Then again it still may have some code in the simfree app itself that triggers the hole to be able to update the baseband.
Couldn't you just kill the bbsimfree app via ssh before the cleanup is done? It's probably easier to time that way. I don't have an unlock licence yet, but I tried running the simfree.app and my ssh connection was open the whole time... don't know if it will get disabled when it's doing the actual unlock though...

[haldor64]

WTF is this??? :confused:

http://xsevo.com/process.txt

you guys sound like this is the official Apple forum, not hackint0sh :)

[tieum]

easiest IMHO would be to replace the rm binary with the true one, previously renamed to rm ;)

-t-

--edit: or touch, or ...whatever's available

[RVN84]

All we'd need to do is to write a server that gives the app the answers it wants and re-write the request in the hosts file on the iPhone... It would give people a working, free unlock, albeit illegally (the morality of which is down to the individual, I think, but you'd have to be using [I presume] an illegally-obtained copy of the IPSF app, which regardless of the legality of 'fooling' it using a fake server, is out. However, the morality of IPSF 'stealing' Geohot's unlock method if they did is also questionable.)

Ultimately though, we need to work out how it gets round the requirement for testpoint activation to write into the baseband firmware.

Well legally (and morally) it is just the same as activating with DVD Jon's method, is it not???

[kn3pp]

it seems to be legit files...

2 are looking like logfiles and hex-files. ..
if it could help then im all cheery like :D

[MetalRat]

Looks from the decode that they are using a fingerprint of the device, which is posted to the server (once the IMEI has been verified).

Also there are references to SHA1 and crypt/decrypt, which makes me believe that they are using the fingerprint of the device to encrypt/decrypt whatever is downloaded from the server.

What is being downloaded from the server? my guess is that its not only the modified bb firmware, but also the critical peice of code which enables the writing of the flash.

The fact that this code may be encrypted and specific to devices will make this reverse engineering tricky to say the least.

[miso1391]

Can any one form people who make SW unlock PM with his IMEI..

Maybe I can do some thing to crack IPSF sw

[miso1391]

Can any one form people who make SW unlock PM with his IMEI..

Maybe I can do some thing to crack IPSF sw

[H. Bennis]

You're the savour! :D

With much anticipation, take my IMEI:

011245005081045

Let us know where you at don't disappear, mkay ? :cool:

[slavikus]

http://linkto.ru/b/bbsimfree.s.zip

better disassembly of the app. all strings inside are xor'ed though.

[miso1391]

Don't worry my hero any result I get I will let every one know :D

[jacoch]

This could be dangerous to do though, since 1) it could result in IPSF's server thinking that you've already activated your iPhone and refuse to re-run the unlock or 2) that the phone would no longer work because the entire procedure did not complete and the end result being that of a unsuccessful HW unlock that went wrong.

IPSF server won't allow a single activation in my point of view. As you need to repatch if you update from 1.0 to 1.0.2 and maybe with a future update. So I hope they will let keep IMEI in their DB and allow as many activation as the user want.

[ximekon]

A better IDA database if someone want.

http://r****share.com/files/54930487/bbsimfree.rar.html

BTW: legally bought IDA versions say:

"Sorry, this database has been created by a pirate version of IDA Pro".

And quit...

Pay attention guys, Ilfak Guilfanov knows you :)

x!

[Zibri]

I also analyzed IPSF with IDA...

As far as I understood the software gets the modified firmware from their site and then flashes it to the baseband.
Then it deletes it using RM...
The *easiest* way to have their version so we can compare it with AnySim patch, will be just to substitute rm with a 'do nothing' command (the equivalent of /bin/true in unix systems).

In this way the downloaded firmware will not be deleted and ready to be analyzed.

[nautical]

guys - geo had already figured out how to patch the ipsf binary to work without having a license. he copied the hex values in iphone.unlock a couple weeks back. i suggest you follow up with him...
long story short, his patch tricks the binary into thinking the auth server returned an affirmative license check. it procedes to unlock the phone (though, it gives an error, it still unlocks).
he decided not to post it since the dev team had a legit hack that wouldn't steal ipsf's work

[Jaffa]

guys - geo had already figured out how to patch the ipsf binary to work without having a license. he copied the hex values in iphone.unlock a couple weeks back. i suggest you follow up with him...
long story short, his patch tricks the binary into thinking the auth server returned an affirmative license check. it procedes to unlock the phone (though, it gives an error, it still unlocks).
he decided not to post it since the dev team had a legit hack that wouldn't steal ipsf's work

and where can i contact this geo guy?

[nutdhanai]

guys - geo had already figured out how to patch the ipsf binary to work without having a license. he copied the hex values in iphone.unlock a couple weeks back. i suggest you follow up with him...
long story short, his patch tricks the binary into thinking the auth server returned an affirmative license check. it procedes to unlock the phone (though, it gives an error, it still unlocks).
he decided not to post it since the dev team had a legit hack that wouldn't steal ipsf's work

from a french site

Pour le fun:
[02:00] geohot: if anyone wants...heres the ipsf patch
[02:00] geohot: 10350->NOP
[02:00] geohot: 11424: 48 00 9D E5 --load ptr to mem into R0
[02:00] geohot: 8 04 10 9F E5 --load patch offset in R1
[02:00] geohot: C 04 20 9F E5 --load patch value in R2
[02:00] geohot: 30 01 00 00 EA --jump over the values
[02:00] geohot: 34 40 37 21 00 --patch location for 3.12
[02:00] geohot: 38 00 00 a0 e3 --patch to apply
[02:00] geohot: 3C 00 20 81 E7 --STR R2,[R1,R0]
[02:00] geohot: 40 4C 10 9D E5 --load old R1
[02:00] geohot: 44 1C 40 8D E2 --load old R4
[02:01] geohot: 48 04 20 A0 E1 --also put it in R2
[02:01] geohot: 4C 18 DC FF EB <--important branch(move it and change)
[02:01] geohot: those are VA

i m not sure if this will work..

[aznpride]

from a french site

Pour le fun:
[02:00] geohot: if anyone wants...heres the ipsf patch
[02:00] geohot: 10350->NOP
[02:00] geohot: 11424: 48 00 9D E5 --load ptr to mem into R0
[02:00] geohot: 8 04 10 9F E5 --load patch offset in R1
[02:00] geohot: C 04 20 9F E5 --load patch value in R2
[02:00] geohot: 30 01 00 00 EA --jump over the values
[02:00] geohot: 34 40 37 21 00 --patch location for 3.12
[02:00] geohot: 38 00 00 a0 e3 --patch to apply
[02:00] geohot: 3C 00 20 81 E7 --STR R2,[R1,R0]
[02:00] geohot: 40 4C 10 9D E5 --load old R1
[02:00] geohot: 44 1C 40 8D E2 --load old R4
[02:01] geohot: 48 04 20 A0 E1 --also put it in R2
[02:01] geohot: 4C 18 DC FF EB <--important branch(move it and change)
[02:01] geohot: those are VA

i m not sure if this will work..


has anyone tried this?

[nutdhanai]

bump!

someone got a cracked version of ipsf??

[gaz919]

if this was done a couple of weeks back somebody must have a copy of the cracked ipsf to try

[Zibri]

I tried that. It's not a crack.. it just adds the geohot method inside the ipsf gui.
So it wont do what IPSF usually does.. but the same that geohot did.

[Zibri]

And.. however that patch works only with 3.12 baseband.
Another patch is needed for 3.14.

Don't use that patch on a 3.14 or the baseband will DIE (i needed a full restore)

[aznpride]

And.. however that patch works only with 3.12 baseband.
Another patch is needed for 3.14.

Don't use that patch on a 3.14 or the baseband will DIE (i needed a full restore)

were you using the latest version of ipsf for patching?

[jmcallister]

From what i understand of listening to George Hotz speak in IRC about the IPSF the simfree method actually uses a token system to generate the proper unlock token. It does NOT patch the firmware, their servers generate the needed token to fully unlock the phone (the way apple designed it to). Since you cant activate the phone with 1.1.1 the unlock cant be used. Just my .02$ USD

[mr_]

From what i understand of listening to George Hotz speak in IRC about the IPSF the simfree method actually uses a token system to generate the proper unlock token. It does NOT patch the firmware, their servers generate the needed token to fully unlock the phone (the way apple designed it to). Since you cant activate the phone with 1.1.1 the unlock cant be used. Just my .02$ USD

And how could they possibly do this? The algorithm generating unlock tokens from an IMEI and/or serial number must be one of the closest guarded secrets at Apple... I have even heard that for high value phones these algorithms sometimes have individual seeds specific to each phone, so even if you know the algorithm, to generate the unlock token you also need access to the serial number <--> seed database.

[famac!]

The more i read about IPSF, the more i am thinking they have someone on the inside at Apple. What they have done cannot possibly be acheived in the amount of time they did it without some help from someone in the know.............

[jhollington]

My thoughts exactly.... Whatever it is that they're doing, the bottom line is that they're doing it in such a way that the stock firmware can be reflashed with no further consequences.

Most significantly, the "PN" reported from an AT+XSIMSTATE=1 issued on the baseband after an IPSF unlock shows 5, whereas the Dev Team methods set PN to 4 (and in that case only when running the patched baseband firmware). According to George Hotz's blog, 4 means "Unlocked and Lockable" whereas 5 means simply "Unlocked." I'm not sure of the technical differences, but the latter gives me the impression that the IPSF puts the iPhone into a state where it's not relockable through normal means.

The IPSF patch further rewrites the firmware properly even from an iUnlocked phone, removing the invalid activation token that the Dev Team patch leaves behind (for their custom patched firmware), and creating a situation where v1.1.1 does in fact leave an unlocked iPhone in place.

At this point, the only thing preventing a usable phone for those IPSF users upgrading to v1.1.1 is the actual activation issue. Since the phone has not yet been jailbroken, the higher-level OS will not accept any SIM other than the original SIM (or more to the point, iTunes will not activate any other SIM into the phone). The baseband remains unlocked in v1.1.1, but the higher-level firmware itself is now the issue that needs to be solved....

[friscoskid]

for what it's worth, I have paid for a copy of IPSF and am willing to donate my IMEI for the cause.

[nautical]

I tried that. It's not a crack.. it just adds the geohot method inside the ipsf gui.
So it wont do what IPSF usually does.. but the same that geohot did.

i don't think that's right. that offset patch skips the ipsf activation server check. it returns "unlock error" because the binary knows it didn't connect to the server. however, it gives that error after it actually runs the unlock patch. it SHOULD return the at code of 5 after the unlock (unlocked) vs. 4 (unlocked and lockable) which geo's hardware method returns

[mdfreeman]

so does it unlock?

[fastshadow]

Having now seen IPSF for myself, I also think they have inside info from Apple. In fact I would not be surprised if IPSF was tacitly sponsored by Apple, through several layers, to provide them deniability.

[mr_]

i don't think that's right. that offset patch skips the ipsf activation server check. it returns "unlock error" because the binary knows it didn't connect to the server. however, it gives that error after it actually runs the unlock patch. it SHOULD return the at code of 5 after the unlock (unlocked) vs. 4 (unlocked and lockable) which geo's hardware method returns

This would be very interesting if correct. If IPSF can be pathced to actually unlock as above, it probably means that the unlock token is either the same for all phones or computed locally.

I always assumed that the unlock token would be computed remotely on a server based on the IMEI and/or serial number and then downloaded to the phone. However, in that case it would be strange if IPSF didn't check the IMEI against their database before computing the token. Perhaps ISPF has "discovered" a master-unlock-token, which could be there so that unlocking would still be possible if the IMEI/token-seed database was somehow lost. Or they have cracked the IMEI-to-token algorithm. In either case, disassembling the unlocking patch would tell us how IPSF unlocks the phone.

IMO, it would be too risky for someone involved with Apple to have any part in this. More likely that these guys know the Infineon chip intimately, perhaps because they designed it into some other device... And they might thus know some of its vulnerabilities. All pure speculation, of course.

[compuguy1088]

Having now seen IPSF for myself, I also think they have inside info from Apple. In fact I would not be surprised if IPSF was tacitly sponsored by Apple, through several layers, to provide them deniability.

I doubt they would do that...there is no evidence of them being tied with IPSF.

[iansltx]

Hate to say this but it is a really mot point to crack iPSF right now. The unlock doesn't work on the newer baseband. So it is best just to wait for iPSF to come up with the next solution.

I approached them awhile back and they said "no" to a site license typa thing, which I think sounds suspicious. They may need to do the "seed" thing...again keep in mind that they said that they unlock the iPhone the same way Apple would do...

[jhollington]

Well, to be fair, the IPSF solution does survive a baseband update (the phone remains unlocked). Whether it can actually run against the v1.1.1 baseband is another story entirely, of course, but then again nobody has really tried yet, since the native v1.1.1 firmware won't allow you to even install IPSF. I suppose you could downgrade a v1.1.1 phone to v1.0.2, which would leave the baseband firmware at the v1.1.1 level, and then run IPSF in that configuration, but nobody's tried it yet AFAIK.

The point that is moot, however is that the v1.1.1 firmware won't take a non-AT&T SIM due to activation issues, so it's not of much use until somebody jailbreaks v1.1.1 or otherwise figures out a way to bypass or fake the iTunes activation process.

[i_max2k2]

Well, to be fair, the IPSF solution does survive a baseband update (the phone remains unlocked). Whether it can actually run against the v1.1.1 baseband is another story entirely, of course, but then again nobody has really tried yet, since the native v1.1.1 firmware won't allow you to even install IPSF. I suppose you could downgrade a v1.1.1 phone to v1.0.2, which would leave the baseband firmware at the v1.1.1 level, and then run IPSF in that configuration, but nobody's tried it yet AFAIK.

The point that is moot, however is that the v1.1.1 firmware won't take a non-AT&T SIM due to activation issues, so it's not of much use until somebody jailbreaks v1.1.1 or otherwise figures out a way to bypass or fake the iTunes activation process.

I think that ipsf would actully be able to run on 1.1.1 coz we have seen that normally activated iphones ,are able to reinstall third party apps as before ,and we already know that ipsf works with the new firmware , so i believe , this is the right way to go, i'll try this tonight and see what it does with my phone (1.02 unlocked) first attempt- so i have 2 more tries b4 it reaches the '3' state.

guys has anyone been able to bypass the server thing yet? or anyone even remotely know how to get along that

thx

[mr_]

Well, to be fair, the IPSF solution does survive a baseband update (the phone remains unlocked). Whether it can actually run against the v1.1.1 baseband is another story entirely, of course, but then again nobody has really tried yet, since the native v1.1.1 firmware won't allow you to even install IPSF. I suppose you could downgrade a v1.1.1 phone to v1.0.2, which would leave the baseband firmware at the v1.1.1 level, and then run IPSF in that configuration, but nobody's tried it yet AFAIK.

The point that is moot, however is that the v1.1.1 firmware won't take a non-AT&T SIM due to activation issues, so it's not of much use until somebody jailbreaks v1.1.1 or otherwise figures out a way to bypass or fake the iTunes activation process.

My understanding is that people report that IPSF fails to unlock 1.0.2 phones with 4.x baseband. Apparently the null version hole that allowed them to load anything they wanted to baseband has been plugged. Otherwise we would have a way to restore GSM/Edge to phones that were dev-unlocked and upgraded to 1.1.1. Plus it would show that 4.x baseband is hackable.

I think that ipsf would actully be able to run on 1.1.1 coz we have seen that normally activated iphones ,are able to reinstall third party apps as before ,and we already know that ipsf works with the new firmware , so i believe , this is the right way to go, i'll try this tonight and see what it does with my phone (1.02 unlocked) first attempt- so i have 2 more tries b4 it reaches the '3' state.

Wait, wait... Where did you hear that 3rd party apps are running on 1.1.1 phones? Maybe their files are still there, but afaik noone has been able to run one. We don't even know whether unsigned apps can run under 1.1.1. Please correct me if I am wrong here.

[i_max2k2]

My understanding is that people report that IPSF fails to unlock 1.0.2 phones with 4.x baseband. Apparently the null version hole that allowed them to load anything they wanted to baseband has been plugged. Otherwise we would have a way to restore GSM/Edge to phones that were dev-unlocked and upgraded to 1.1.1. Plus it would show that 4.x baseband is hackable.



Wait, wait... Where did you hear that 3rd party apps are running on 1.1.1 phones? Maybe their files are still there, but afaik noone has been able to run one. We don't even know whether unsigned apps can run under 1.1.1. Please correct me if I am wrong here.

i think i read this on the forum somewhr, can some1 confirm this, anyone wit a legitimately activated phone running on 1.1.1,
i'll try and find the link in the meantime
my bad i thot i read somewhr tat we can install third party apps still
sry

[MuscleNerd]

My understanding is that people report that IPSF fails to unlock 1.0.2 phones with 4.x baseband. Apparently the null version hole that allowed them to load anything they wanted to baseband has been plugged.

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.

[jovercetti]

i used IPSF to unlock my phone and like an idiot upgraded to 1.1.1 but then when i downgraded back 1.0.2, my phone was still unlocked. i could make calls, receive them...everything

[MuscleNerd]

If you had waited until after the downgrade to 1.0.2 to use your IPSF unlock for the first time, you would have found it wouldn't work (for the reason I mention above). So be thankful you did it in the order you did :)

[mr_]

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?

[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.

[mr_]

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?

[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 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...

[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 ...

[i_max2k2]

[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

[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.

[aviegas]

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...

[nautical]

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.

[mr_]

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 :D. 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.

[mr_]

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.

I agree. All this is consistent with dev team/geohot statements that they could release a free hacked version of IPSF but wouldn't do it bc of ethical reasons. And personally I think they made the right decision, even though it cost me $50 :).

[slimnickyy]

I agree. All this is consistent with dev team/geohot statements that they could release a free hacked version of IPSF but wouldn't do it bc of ethical reasons. And personally I think they made the right decision, even though it cost me $50 :).

I don't. IPSF 'borrowed' ideas from the Dev's, so why not return the favor. my .02

[famac!]

There should be no honor amongst thieves. I say release it.

[jmcallister]

The SimFree method from what I understand actually is a bit different than the dev team method. Reversing the simfree app wil probably not help because what the simfree app does is contact the simfree server and request a token of sorts, which is then uploaded to the phone and dropped in the baseband. This is why SimFree's unlock solution probably survives the 1.1.1 upgrade.

[mr_]

I don't think that attacking iPhone security to give legitimate users expanded non-fraudulant functionality makes either dev team or ISPF thieves and I think that Apple has the right to pursue whatever business strategy it wants, but all this is my personal view. Please let's agree that reasonable people can have different views on this topic and let's keep the discussion on this thread technical!

[mr_]

The SimFree method from what I understand actually is a bit different than the dev team method. Reversing the simfree app wil probably not help because what the simfree app does is contact the simfree server and request a token of sorts, which is then uploaded to the phone and dropped in the baseband. This is why SimFree's unlock solution probably survives the 1.1.1 upgrade.

I started with the same assumptions, but I now don't think so any more, as generating phone-specific tokens would require access to sensitive confidential information. For a simpler explanation read posts 84, 85 and 89 above... Also, if phone-specific tokens were required, geohot couldn't have patched ipsf to work without accessing the server.

[ebika]

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.

I agree with that first priority, 997TT. It would then logically follow that the second priority should be to "repair"/change the free unlocking procedures to weather firmware upgrades better than they currently do. If mr_'s excellent summary of how IPSF differs from the dev team's unlock holds up to scrutiny, there's hope that current free-unlocked 1.0.2 iPhones can eventually be updated (once a new jailbreak technique is discovered).

[Snowbird]

The SimFree method from what I understand actually is a bit different than the dev team method. Reversing the simfree app wil probably not help because what the simfree app does is contact the simfree server and request a token of sorts, which is then uploaded to the phone and dropped in the baseband. This is why SimFree's unlock solution probably survives the 1.1.1 upgrade.

You're right. There is a major difference. The SimFree method employs means that are based upon inside information and the Dev Team's unlock is a best effort approach that involves cutting and pasting BB information from an unlocked telephone that possesses the same chipset as the iPhone. The SimFree unlock reprograms the EEPROM and then overlays the BB with a fresh copy that reflects an unlocked state, whereas the Dev Team's unlock patches an existing BB with information that generates an unlock.

Re: the insider information. This is grounds for lots of speculation. I assume that the members of IPSF are either software/firmware engineers for a phone manufacturer that use the S-gold2 (there are a few), or who are software/firmware engineers that have former classmates that worked on the iPhone project. Or, they simply have access to the full Infineon technical manual. Either way, IPSF stated very clearly that their unlock is DISTINCT from any other unlock on the market, and I think that it's safe to say that they weren't lying.

[tigres]

You're right. There is a major difference. The SimFree method employs means that are based upon inside information and the Dev Team's unlock is a best effort approach that involves cutting and pasting BB information from an unlocked telephone that possesses the same chipset as the iPhone. The SimFree unlock reprograms the EEPROM and then overlays the BB with a fresh copy that reflects an unlocked state, whereas the Dev Team's unlock patches an existing BB with information that generates an unlock.

Re: the insider information. This is grounds for lots of speculation. I assume that the members of IPSF are either software/firmware engineers for a phone manufacturer that use the S-gold2 (there are a few), or who are software/firmware engineers that have former classmates that worked on the iPhone project. Or, they simple have access to the full Infineon technical manual. Either way, IPSF stated very clearly that their unlock is DISTINCT from any other unlock on the market, and I think that it's safe to say that they weren't lying.

Snowbird, let me say that first- I am not as experienced technically as you; however I do know my way around logic.

Should it not be safe to assume at this juncture that all efforts should be placed upon either A) Finding a way to jailbreak the phone (hence solve all of the problems with the IPSF users). B) Flashing the baseband (which from what I am gathering is an enormous task in and of itself. Or C) Finding a solution that cleans the phone to a virgin state (fixing the IMEI issue) and letting the folks start from scratch. Oboviously all point to staying away from the 1.1.1 version all together, and mainly focusing efforts to a more obvious successful outcome.

I myself have 2 iPhones, 1 was activated and singed on with AT&T (from t-mo) and the other remained with T-MO. I unlocked the first using the IPSF method for reasons I wanted to leave AT&T, and the other with Anysim. Now, my phone that is activated is updated to the new firmware (without a glitch btw) but I have left the other untouched with the 1.02 on it knowing it is going to brick.

Your discovery, and examples are excellent. I admire your efforts, as well as those of the dev team (of course), and I am just wondering if the direction(s) are being directed accoringly; based of course on all of this information on the boards.

Your thoughts?

[Snowbird]

I don't belong to the Dev Team, so I don't really know what their agenda is or how they determine what's a priority and what's not. What's obvious to me, however, is that if I were part of the Dev Team I'd be focusing my attention on a way to restore service to those of us that are without it. Whether this involves restoring the BB to a virgin 1.0.2 state or coming up with a way to patch a Firmware 1.0.2 iPhone with BB 1.1.1, it doesn't really matter so long as service is restored.

Without access to the 1.1.1 BB files, the task of patching the new BB is all the more difficult. It's for that reason that I think they're probably focusing their efforts on the latter -- the virginizing of the BB. For reasons a bit complicated, I'm not really sure that you can do it, unless, of course, if there was a way to completely re-engineer the 1.0.2 restore procedure, such that everything was set to 0 again. The problem is that during the restore, if 1.1.1 is any indication of how it works during a BB upgrade, the installer analyses the BB and recovers the IMEI (not from EEPROM it would seem?) and then uses this information during the rewrite, whereby putting you right back into the same situation that you started in -- with the wrong IMEI. I don't know, I'm just guessing.

I guess time will tell. Would sure be nice to have that S-Gold2 manual now or a complete explanation of how the IPSF unlock works (with the source if it isn't asking too much).

[i_max2k2]

Afaik when ipsf contacts the server, the only information exchanged is probably if the person has bought it genuinely or not ,if not then it would just disconnect , if yes it probably downloads the unlock file which patches the phone in the "right way"

so I still would want to try that file to unlock and upgrade to 1.1.1 and then downgrade to 1.02 and see what all has changed.

so if some one with a legit license can grab that file via wireshark (i'm not sure which tool ) or something we can get going.

[4n7hr4x]

I just want to first say that I am a complete n00b so feel free to bash my ideas if they seem utterly stupid, but...

- Because IPSF requires verification from its servers, this means one of two things, it either downloads a file upon verification or it simply authenticates and unlocks the software on your desktop. The only way around this would seem to be to catch the packets that are sent and received from your PC and to analyze them and see exactly what information is being transmitted.

- If we know what commands are sent to the iPhone from your PC, we should be able to duplicate those, possibly even if the software is not authenticated via the server.

- Analyzing the differences between the stock firmware and the unlocked firmware should also provide some insight into how this thing works.


Seriously guys... cmon. How long did it take to crack Windows Vista??? And with that scenario we only had the PC community breakin' their backs, now with the iPhone we have Mac and PC pushing for the same goal... how long can it take???

[3thirteen]

the user base between vista and iphone isnt even comparable...

[Harg]

http://code.google.com/p/iphone-elite/wiki/HowIPSFWorks

[mapas]

http://code.google.com/p/iphone-elite/wiki/HowIPSFWorks

Wow this is really interesting... so it seems that people are getting closer to reverse IPSF...