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
