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
