First we need to find out if this is even exploitable. We really need people who are good at reverse engineering. If you have any ideas - head over to irc.freenode.net #linux4nano-dev
On Mon, Feb 16, 2009 at 11:24 AM, 3mpty <[email protected]> wrote: > Maybe this can be avoided with some kind of payload encoding. > > Another problem is that AFAIK the stack on the ARM architecture is > marked by default as non executable. So if this is a stack overflow it > is even more difficult to exploit. > > (HD Moore has written a very good "tutorial" on metasploit blog, if I > remember right) > > Oh, if someone is interested in other bug prone features of the Note > Channel, have a look at this > images.apple.com/ipod/ipodtours/pdf/iPodNoteReaderGuide.pdf > > 2009/2/16, Bahattin TOZYILMAZ <[email protected]>: > > Executing machine code this way would be pretty hard. iPod will stop > > reading on a non ascii(actually non UTF) char. Is it same with href > > attribute. And is there any ARM code that can be written binary in > > UTF. A 0x00 would stop note reader. And it is too hard not to use 0x00 > > on a RISC CPU. > > > > On 16/02/2009, Taylor Gordon <[email protected]> wrote: > >> Yes, this is correct. > >> > >> On Mon, Feb 16, 2009 at 10:25 AM, 3mpty <[email protected]> wrote: > >> > >>> I think he is the same guy that explained it to me... > >>> It is very simple: > >>> create a text file with this content: > >>> <a href="XXX.....XXX">blablabla</a> > >>> > >>> (Put a huge number of X) > >>> The file can be long 4096 (0x1000) chars at most, because otherwise > >>> the iPod will truncate it and won't recognise it as a correct link > >>> (the missing end TAG)... At least this is the situation on my 6G. > >>> > >>> 2009/2/16, Emmanuel Fleury <[email protected]>: > >>> > Manuel Naranjo wrote: > >>> >> > >>> >> Hello guys, I'm trying to reproduce on my 2G A1199 but I couldn't, > can > >>> >> anyone send me a text file privately that does the overflow so I can > >>> >> confirm if the bug is occurring or not. > >>> > > >>> > Maybe Taylor can provide a better (i.e. more detailled) explanation > on > >>> > how to reproduce the bug (with a sample file, etc) ? > >>> > > >>> > The procedure given is quite loose and miss some details. > >>> > > >>> > Regards > >>> > -- > >>> > Emmanuel Fleury > >>> > > >>> > ANYBODY who does driver development without taking the real world > into > >>> > account is a dangerous person. Stacks of papers, diagrams and rules > are > >>> > absolutely WORTHLESS if you can't just understand the fact that > >>> > documentation is nothing more than a guideline. > >>> > > >>> > Once you realize that documentation should be laughed at, peed upon, > >>> > put > >>> > on fire, and just ridiculed in general, THEN, and only then, have you > >>> > reached the level where you can safely read it and try to use it to > >>> > actually implement a driver. > >>> > -- Linus Torvalds > >>> > > >>> > _______________________________________________ > >>> > 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 > > > > _______________________________________________ > 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
