<w__> the reason i dont think its in flash is i havnt been able to read it
<w__> directly from flash
<unim> so, know one knows physically (point to a chip) where this nck stuff is stored?
<unim> i understand w__
<NTT> w: How do you know what you're looking for?
<w__> NTT: how do u mean?
<NTT> w: ie how do you know it's not stored somewhere in the flash?
<w__> NTT because i've physically lifted the chip and read it
<w__> so either i missed some mode in the flash chip
<w__> or its in the bb
<NTT> Ok, but the question was "Is the NVRAM stored in the flash"... what signature from NVRAM were you looking for to see if it existed in the flash dump?
<w__> NTT we know the address nvram is located at
<w__> nordump etc doesnt read it
<w__> when i read the flash chip directly i see no extra data
<NTT> ah ok I see
<NTT> so that's a pretty solid indication that it's not on there :)
<w__> yes
<jparker2015> w__: so you did a phisical extraction ?
<w__> yes
<w__> thats what i been upto all this time
<jparker2015> so you did it to the bb chip ?
<w__> no not necesary really
<w__> the flash chip
<NTT> Why does it matter where it's stored? Presumably we can find the routine that actually writes to NVRAM so we don't care about the underlying mechanics of the write
<unim> there is an intel flash chip that the bb chip interfaces with
<unim> i posted a circuit diagram yesterday
<w__> NTT: it doesnt really matter.. only that if it were in the flash i could have read it
<unim> it is where the main mem is stored
<NTT> ok
<jparker2015> oh so its the flash chip we are extracting ?
<compuguy1088> and write to it
<unim> who wants a circuit diagram?
<w__> well ipsf can read nvram
<unim> lol
<unim> think it will help explain things
<NTT> well that code is in the IPSF that zibri was disassembling, so that's a non-issue
<w__> so we'll study the routine and modify it
<compuguy1088> ok
<w__> we should be looking at the nvram before and after ipsf
<compuguy1088> and that would be built upon to make an unlock
<jparker2015> w__: but how do we do that ?
<unim> wait w__.. so, you can read the nvram?
<unim> yeah.. lol what jparker2015 said
<NTT> jparker: we already have the code to read NVRAM
<NTT> it's in IPSF
<w__> i dont actually know if 'we' can read nvram
<unim> can i see it NTT?
<w__> i havnt been working on the flash in the iphone fimrware
<w__> but 'we' do know ipsf can read it
<w__> and we have their patch
<NTT> Well I don't have the code, but according to zirbi it reads NVRAM, sends it to the server and then writes back to it after.... so the read/write routines are in the code
<w__> zibri's done alot of work on ipsf
<w__> so i think he'll post the code once we have something usefull
<w__> i'm sure it wouldn't be nice if he did 99% of the work and posted it
<w__> and the dev team swanned in and did the last 1% and claimed it as their own
<NTT> well read/write routines would be useful :) Once you have read capability then you can do a pre/post comparison
<w__> someone answer RealBallchalk's question
<unim> NTT I understand the effort now
<w__> you should all understand now
<w__> *testing testing*
<NTT> it doesn't matter where the NVRAM is stored
<w__> hehe k cool
<w__> i wanted to see if these lot could answer it hehe
<w__> np
<unim> i understand w__
<unim> thank you all for the in depth info
<glaz> Yup, I got one.
<NTT> w: thanks alot for sharing all that info, I learned a LOT tonight!
<unim> wait NTT
<w__> k
<w__> NTT: np
<glaz> can I ? I feel like a complete noob here.
<unim> patch bb temporarily.. nvram to original state
<unim> something isn't jiving here
<w__> lol sure
<NTT> I came in knowing nothing :-) Now I need to get myself a phone and jump headlong into this effort
<unim> what is permanently changed?
<w__> heheh cool
<unim> nvram or bb?
<NTT> NVRAM
<w__> nvram
<w__> glaz?
<unim> k, then NTT .. "NVRAM is updated to original state"
<unim> that is not correct
<w__> missed a comma i think
<unim> i see
<NTT> sorry I meant BB is restored to original state
* Viper__ has quit ("")
<NTT> BB FW is restored
<unim> <- has complete understanding
<glaz> I bought an iphone that arrived with 1.1.1 already installed on it. I'm not that bad at modifying stuff. I familliar with shell and stuff. Where can I find an how to from scratch that will help me.
<unim> so this is a very clean/permanent hack?
<unim> unless apple goes tinkering w/ nvram?
<unim> but even then...
<w__> yes
<w__> but its very hard for apple to change the lock method now
<NTT> Well Apple could easily change the BB FW to check NVRAM in a different way
<unim> awesome
<NTT> w: why?
<unim> yeah, i understand it
<w__> they would need to have their server generate custom flashes per imei
<unim> yup w__
<unim> because the imei/sim data is per phone
<w__> yes
<unim> awesome
<NTT> w: No they wouldn't...
<NTT> w: if you think of it this way
<unim> looks at his itouch now in retail box contemplating a r
<unim> r= returnb
<NTT> (my understanding may be completely wrong)
<w__> ok
<NTT> the BB FW checks NVRAM to validate whether to unlock or not
<unim> k
<jparker2015> W__: where does the SIM play into all this ?
<w__> jparker2015: nowhere
<NTT> simply setting NVRAM to a value doesn't automatically trigger an unlock.. something down the pipe reads that value, right?
<jparker2015> ok
<w__> NTT lets assume method 1
<unim> k, before you get started w__
<w__> the nck is verified against a hash in nvram
<unim> simple ?
<w__> k
<NTT> if that's the case, then what prevengts Apple from changing the NVRAM value generation method completely?
<unim> sim card... what is on it that allows me to take my sim card and put it in another's phone
<glaz> Am I screwd if the iphone I bought has already 1.1.1 on it?
<unim> and it pulls my account?
<unim> what is read off it?
<w__> unim: not a simple ? i'll do it next!
<unim> k, continue. sorry
<w__> NTT: the point is that with method 1
<w__> the hash(nck) is in nvram
<RealBallchalk> w__: iUnlock changes the bb and ipsf changes the nvram...
<w__> we enter a nck and the bb hash's it
<w__> it compares that to whats in nvram
<w__> then jumps to the unlock routine that calculates the new nvram simlock and writes it
* illutionz_ has quit (Operation timed out)
<w__> RealBallchalk: both change the nvram
<RealBallchalk> glaz: not screwed u helpable
<NTT> w: Understood... but nothing prevents apple from changing their checking method entirely in the BB FW. For example they could switch from method 1 to method 3
<RealBallchalk> w__: oh
<w__> NTT no.. to do that they would need to generate AES(IMEI) and store it in each phone's nvram
<RealBallchalk> w__: and both leaves the BB in orginal state or no?
<w__> that would require a specific update per user
<glaz> anywhere I can find an How-to from scratch. I played with dishes before but not iphones :p
<w__> RealBallchalk: iunlock patch is flawed, and also it doesnt unpatch itself
<RealBallchalk> unpatch would be through reflashing with new flashfile then?
<glaz> I found couple of sites interresting, like yours. But it asks me to connect via ssh and do stuff. I don't even have ssh connection to my phone
<NTT> w: I see.. for backwards compatibility, they are screwed.... although they could do a temporary BB patch to write a bunch of stuff and then that code gets overwritten and is never referenced
<w__> unim.. your phone has an IMSI (unique identifier) and a coresponding secret key (ki)
<guz> sup everyone. Are any of you guys iPhone resellers?
<Viper___> what u need guz?
<w__> NTT, no they need to generate AES(IMEI) for every phone and write it into nvram.. they could do that with an update sure
<guz> I want to know how you walk into a store and buy 10+ phones
<Viper___> lol
<w__> but their server would need to read the imei, generate it and upload it to the phone
<w__> the ki is inside the sim
<w__> you cant read it
<w__> the network also knows IMSI and ki
<Viper___> no cdhance anything can read a ki from the sims today
<Viper___> 0%
<w__> when u plug the sim in, the phone sends to the network IMSI
<Viper___> especially remotely
<w__> the network sends back a random number
<w__> the sim encrypts(RND,ki)
<w__> it splits the number in half
<w__> and sends half back
<w__> the network does encrypt (RND,ki) and splits it in half
<glaz> guz: We did that already, my buddy said he was buying those as gifts for his employees.
<Viper___> all but the KI are gettable the KI isnt getting anywhere
<w__> it verifies the against the half that was sent back
<w__> if it verifies your allowed to make calls
<w__> the other half **** NEVER SENT OVER THE AIR!!! *
<w__> it used to encrypt your voice
<NTT> w: yeah you're right.. either do it on the server or use temporary code to generate it and then toss it, but that would be open to exploit from the hacker community
<w__> NTT yes entirely
<w__> NTT it would be really stupid.. cos one hacked update and we could generate nck's for everyone
<w__> feel free
<w__> pls remove my nick tho
<w__> otherwise we'll get people searching for me
<w__> and hounding me with ???'s
<w__> anyway
<w__> unim:
<w__> the IMSI encodes your netowrk and country
<w__> it is read by the phone
<w__> and used to lock
<w__> i.e. only an AT&T imsi will work