Difference between revisions of "Talk:Ultrasn0w"

From The iPhone Wiki
Jump to: navigation, search
(more info needed: new section)
(ultrasn0w payload)
 
(4 intermediate revisions by 2 users not shown)
Line 12: Line 12:
   
 
--[[User:ChronicDev|ChronicDev]] 12:05, 9 January 2009 (UTC)
 
--[[User:ChronicDev|ChronicDev]] 12:05, 9 January 2009 (UTC)
  +
  +
A full and correct hex dump is now available at [[At+stkprof]].
  +
  +
--[[User:Oranav|Oranav]] 23:02, 8 May 2009 (UTC)
   
 
== Geohot's commentary ==
 
== Geohot's commentary ==
Line 50: Line 54:
 
== more info needed ==
 
== more info needed ==
   
because of my inability to understand ARM, I have questions: what addresses are patched? how exactly does it patch? why is it calling NU_Receive_From_Mailbox()?
+
because of my inability to understand ARM, I have questions: what addresses are patched? how exactly does it patch? why is it calling NU_Receive_From_Mailbox()?--[[User:Paul0|paulzero]] 06:24, 13 March 2009 (UTC)
  +
  +
== ultrasn0w payload ==
  +
  +
Thanks Darkmen for the yellowsn0w payload analysis! Took a lot of comments from there. --[[User:Oranav|Oranav]] 09:39, 4 July 2009 (UTC)

Latest revision as of 19:09, 4 July 2009

Darkmen's analysis

This analysis is somewhat incomplete, as it leaves out stage 2 of the injector that performs the hex to binary conversion for the payload. As it stands, the comment for offset 4 of the "Code loader" (internally called "stage 1" of the injector), the one that says "at-handler buffer where StrToHex result of the at-command is" is incorrect. The reason for the error is probably that the reverse engineer used "strings" on the yellowsn0w executable to find the injected payload of yellowsn0w and since the injector's stage 2 is in binary (the contents of memory at 0x40159FBF is thus ready-to-execute binary code, albeit misaligned), "strings", therefore, would not have yielded the code for stage 2. Overall, though, my cursory examination seems to indicate that the rest of the analysis (of the "meat" of the thing) is fairly accurate and commendable. :)

--Planetbeing 23:12, 8 January 2009 (UTC)

Its true. I just took the at-string from the iphone wiki post ;) Anyway, my point was to get main idea

--Darkmen 07:31, 9 January 2009 (UTC)

My bad man, I copied and pasted it from IDA (along with converting what it converted to a string to hex). I didn't realize there was more :P

--ChronicDev 12:05, 9 January 2009 (UTC)

A full and correct hex dump is now available at At+stkprof.

--Oranav 23:02, 8 May 2009 (UTC)

Geohot's commentary

Thinking about this, I know how I could've done the unlock. I'm so lazy. This might be what yellowsn0w does already; theres a little object code in your source, so I don't know :-)

1. copy task_sim into memory
2. patch task_sim in the usual way(too bad i don't really understand the baseband at all)
3. modify the nucleus task struct to use the in memory task_sim(although idk why theres no execute on the stack, normal ram seems ok)
4. reset the sim card

no real reversing required. i could've had this in july dammit :-P

i also think this approach might solve some peoples problems with it dying after 10 minutes

~geohot

Payload vs injection vector

I edited the page in a way I felt was more accurate. Geohot deserves massive props for finding the vuln in 2.28, and maybe there should be a separate "iPhone 3G Unlock" page that notes that more prominently (noting the 2.2 unlock was dev team's payload with geohot's vuln), but yellowsn0w IS the payload and it doesn't make sense to give separate credits on this page for the injection vector.

I don't know much about how yellowsn0w works myself, but I understand it took a lot of careful reverse engineering of the Nucleus OS and baseband tasks in order to pull off, so the payload honestly doesn't take the backseat to the vuln in this case.

--Planetbeing 16:47, 3 January 2009 (UTC)

nx

heh, I think it is a standard thing for ARM for the stack to be nx. btw, of course there was reversing required, how else would you have found the injection hack itself x)

About AT+STKPROF exploit

Does only 2.28 vulnerable to at+stkprof exploit?

RE: About AT+STKPROF exploit

afaik all versions 1.45 through 2.28 are vulnerable, but devteam only designed a payload for 2.28. not 100% on that though.

more info needed

because of my inability to understand ARM, I have questions: what addresses are patched? how exactly does it patch? why is it calling NU_Receive_From_Mailbox()?--paulzero 06:24, 13 March 2009 (UTC)

ultrasn0w payload

Thanks Darkmen for the yellowsn0w payload analysis! Took a lot of comments from there. --Oranav 09:39, 4 July 2009 (UTC)