Originally Posted by aviegas

My hope is that the community can once again encourage the Dev/Elite guys to resume their work on JerrySIM, and the next exploit, and hope that this episode will soon be a page turned over.

My hope is that the exploit(s) in JerrySIM would be inherited into the "hard-code" type of the baseband CPU... My little hope


I assume (myself... so please don't flame me...) that any exploit in JerrySIM (that might be discovered more in the future...) cause the same symthom to what hardware unlock guys did -- like... when those guys physically tab to the test point... The exploit(s) should just be the other ways to "software tab" and make the chip run into the same state, so we can downgrade the BL thereafter...


If it is the case, it should be the behavior of the chip itself which I think cannot be fixed easily. Otherwise Apple have to chage to the new revision of the chip...

My $0.02...

Hello again...

I'm asking for some knowledge. Please teach me my master.

I see the gunlock.c code.

================================================== ====
//First exploit, the -0x20000 exploit
//This writes the firmware, in all its unsigned glory
//I guess Apple figured -0x400 was simple, -0x20000 is *much* harder
address(0xA0000000,0); //-0x20000, like i said
FILE *bb=fopen(argv[2],"rb");
fseek(bb,0x9a4,SEEK_SET); //skip bbupdater data and secpack
int a,rc=0;
do{
a=fread(data,1,0x800,bb);
if(rc<patchloc&&patchloc<(rc+a)) //patch the firmware
{
printf("Patching...\n");
data[patchloc-rc+3] = 0xe3;
data[patchloc-rc+2] = 0xa0;
data[patchloc-rc+1] = 0x00;
data[patchloc-rc] = 0x01;
}
if(rc%0x10000==0||a!=0x800) printf("Wrote: 0x%x 0x%x\n",a,rc);
if(a>0)
bbwrite(a,1); //write like hell
rc+=a;
}while(a>0);

================================================== ====

Usually when we log the FW <--> BB4.02.13 communication, we see something like

1271068 recv[call]: +XSIM: 2
1271070 send[call]: at+cpin?
1271076 recv[call]: +CPIN: READY
1271078 recv[call]: OK
1271079 send[call]: at+cimi
1272047 recv[call]: +XLOCK: "PN",1,0,"PU",5,0,"PP",5,0,"PC",5,0,"PS",5,0
1272159 recv[call]: 510011911xxxxxx
1272160 recv[call]: OK
1272162 send[call]: at+xsimstate=1
1272169 recv[call]: +XSIM: 2
1272172 recv[call]: +XLOCK: "PN",1,0,"PU",5,0,"PP",5,0,"PC",5,0,"PS",5,0
1272173 recv[call]: OK
1272175 send[call]: at+ccid
1272182 recv[call]: +CCID: 89014103113714zzzzzz
1272184 recv[call]: OK
1272184 sim: This is a new SIM
1272186 send[call]: at+xpincnt
1272193 recv[call]: +XPINCNT: 3,3,10,10
1272195 recv[call]: OK
1272197 send[call]: at+CLCK="FD",2
1272205 recv[call]: +CLCK: 0
1272206 recv[call]: OK
1272209 send[call]: at+cimi
1272216 recv[call]: 510011911xxxxxx
1272217 recv[call]: OK

Is it the same as what gunlock.c do to unlock 4.02.13 BB? It goes directly to the place where BB keeps the lock state and patches down the unlock state over it?

Please correct me.....

Now... I saw in some threads I lost it. SaLoR is trying to do the GeoHot's unlock method to 4.03.13. Someone mentioned that the different address has to be applied, and they said something about leaving last 4 bytes blank....

What is it?

oh people come on!
y'all say "Oh pity the community lost SO MUCH with that leak!", but what did we loose and what did we get?
1. WE LOST
We lost 1 exploit, that wasn't going to be published anyway and was such a source of moronic behaviour on the iPhone scene. We all remember how it was - when everyone was trying to get the solution out a.s.a.p, everyone but the DevTeam themselves! They've been spending the nights figuring out how to "beat the chinese" with *SIMs and make some money out of it at the same time while collecting the donations of people promising the unlock. They had the 3.9 1.1.3 unlock at the January 11th and when did they released it? Never! They had Jailbreak as well and when did they released it? Never! They kicked 2 talents out of the team, just because they shared something to the public.
2. WE GOT
Now, when the community has the soft unlock and the DevTeam's hole is gonna be closed what's left of them? Nothing! No more cause to feel supermen, no more plans to conquer the world, they are back to what they were - some unknown people with ambitions. And that IS the source of power, the only reason to move further. Nobody's gonna trust them like before, cause they didn't share till the end, Geo is on top and they have bitter feeling of defeat, the best taste. They either leave (np guys, it's just not yours), or come back with much better attitude towards hacking. And this time, I hope, they will learn the lesson - you better give what you get right now or it won't be needed.
As for Zibri and what he did - he did wrong of course releasing the code, but he didn't do it without the reason, right? If he was shown some respect and ex-team people would not make him a moron talking shit with his nick on the channels, compromising him, there wouldn't be any leak. Learn to respect and you will get the respect back. And don't give vital info to the people you are gonna kick out later, or don't kick out people with vital info... 8)

The 3rd string "let's try to make money off this" was maliciously added by Zibri and was not in the original code. Go and look at the svn history for that page, you'll see that Viper removed it because he knew it wasn't in the original. And yes, all 3 versions (malicious, fixed, and "deleted") of that page are still fully available in that googlecode project's svn.

Originally Posted by Zf_

JerrySIM will most likely be patched in the next version because of the Moron In Chief action.

Besides, work on JerrySIM is stopped. You know where to complain.

What i'm curious is why? Why leak something that isn't even stable? I just don't get it...

I understand the Dev team's stance is that development has been stopped, but I was wondering if the JerrySIM exploit was indeed patched (and therefore lost to the community through Zibre's leak) or whether it survived through to the expected 1.1.4 firmware release. Anyone know?

It would be cool to see it resurrected and for something to come out of of that intruiging piece of work.

None of the holes exposed since 1.1.3 have been explicitly closed in 1.1.4, including this one. But it seems the SDK hasn't shown up either. Still, it could be a good sign that they didn't close the holes with 1.1.4.