Difference between revisions of "Talk:Ultrasn0w"

From The iPhone Wiki
Jump to: navigation, search
m (Payload vs injection vector)
Line 1: Line 1:
  +
== 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. :)
  +
  +
--[[User:Planetbeing|Planetbeing]] 23:12, 8 January 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 :-)
 
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 :-)
   

Revision as of 23:12, 8 January 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)

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.