Yes, just about all ipods capable of viewing notes is affected. I use the 5G firmware to disassemble since it crashes instantly just like the 3g/4g nano and 6g classic. Do you have a disassembler like IDA pro?
On Thu, Apr 9, 2009 at 9:33 AM, A W <[email protected]> wrote: > Not really, but asm is pretty much the same for all platforms, and ARM is > one well documented. Does any of hacked pods have Notes feature? Having its > code would really help. > > Here some guesses, which makes me think it is exploitable: > > 1. Fixed overflow lenght. String is copied into array of fixed size. > > 2. Allocating fixed-size array on the heap does not makes much sense, so it > must be somewhere on the stack. > > 3. Typical stack frame layout assumes return address to be right above > procedure local variables. > > 4. There may be few other variables between buffer and address, but none of > them, if corrupted, should cause instant reboot. > 2009/4/9 Taylor Gordon <[email protected]> > > > You found the same exact vulnerability that I did. > > > > However; its pretty much useless unless we obtained a memory dump (from a > > hackable ipod like 5G) to know what it its (like a buffer overflow), or > > looked at the assembly in the firmware to see where the bug occurs. Which > > would still be a TON of work. Do you have experience in ARM programming? > > > > Taylor > > > > On Wed, Apr 8, 2009 at 7:23 PM, A W <[email protected]> wrote: > > > > > I have stuck. Must be a lack of experience on exploiting things. > > > Most important question: what kind of code can be used to understand > when > > > this code is actually executed? There is no point on wasting time > > searching > > > exploit entry address, unless you shure you'll notice the hit. I were > > > thinkin of some kind of dead loop, but my iPod freezed few times just > at > > > overflow, so its probably not the best way. > > > And what kind of data one must corrupt to completely freeze iPod? > > > > > > The overflow I'm tryin to exploit is at A tag: [a href="here"]; iPod > goes > > > reboot when target file name is longer than 266 bytes. And Notes does > > > handle > > > such names with out any problems, so I think its goes out of bounds > > > somewhere at file existance check (inside interrupt handler?). > > > Notes apply some restrictions to exploit code: it turns bytes with > > > value>127 > > > to two-byte (UTF?) sequences and, probably, converts lowercase latin > > > chars(0x61-0x7A) to uppercase. This makes unusable some conditional > codes > > > (including ALWAYS), branches to negative offset, few ALU instructions, > > and > > > some other, less useful things. Still I think there is enough freedom > to > > > code something interesting, and its always possible to generate > necessary > > > instructions in-place. > > > _______________________________________________ > > > Linux4nano-dev mailing list > > > [email protected] > > > https://mail.gna.org/listinfo/linux4nano-dev > > > http://www.linux4nano.org > > > > > _______________________________________________ > > Linux4nano-dev mailing list > > [email protected] > > https://mail.gna.org/listinfo/linux4nano-dev > > http://www.linux4nano.org > > > _______________________________________________ > Linux4nano-dev mailing list > [email protected] > https://mail.gna.org/listinfo/linux4nano-dev > http://www.linux4nano.org > _______________________________________________ Linux4nano-dev mailing list [email protected] https://mail.gna.org/listinfo/linux4nano-dev http://www.linux4nano.org
