First we need to find the code in the firmware where this occurs. This might end up being a non-executable stack. Then we need to make sure that the ipod is little endian before inputting any code.
On Tue, Feb 17, 2009 at 1:12 PM, Taylor Gordon <[email protected]>wrote: > I don't believe the ipod has an MMU, at least the older ones up to 5.5G > didn't(davidc__ told me this) > > > On Tue, Feb 17, 2009 at 1:05 PM, The Seven <[email protected]> wrote: > >> I haven't heard yet that this ARM even has a MMU... >> Do you know some details about whether it exists and how it does work? >> >> Fabrice Desclaux schrieb: >> > just a question: >> > >> > It seems ipodlinux doesn't use ARM mmu capabilities. >> > but are you sure the default apple OS does same? >> > >> > because if it uses MMU, your address (0x22000XXX) seems to be PHYSICAL >> address, and not LINEAR address. >> > the code (and shell code) will manipulate linear addresses if it is the >> case. >> > >> > >> > >> > >> > + >> > serpilliere >> > >> > >> > >> > On Tue, Feb 17, 2009 at 06:25:01PM +0100, 3mpty wrote: >> >> 2009/2/17, Bahattin TOZYILMAZ <[email protected]>: >> >>> Can we code addresses indirectly, create it on a register then use it? >> >>> It is easy on an x86 but, can it be done on an ARM? >> >> Yes we can, but not to redirect the flow execution to the shellcode. >> >> >> >>> And another question, how will we trigger the shell code? >> >> If it is a stack based overflow and if the stack isn't marked as non >> >> exec, we write the shellcode address (more or less, but we have a >> >> small range of valid addresses (the NOPs)) on the stack, overwriting >> >> some return address of some function with it. >> >> (At least this is what I understand from the info given by The Seven >> >> in the previous email). In this way, after a LDR of PC from the stack, >> >> instead of the instruction after the function call we'll have our >> >> shellcode. >> >> >> >> Also, things like return-to-libc doesn't seem to be feasible on >> >> iPod... at least with a black box approach. >> >> But we should just try. >> >> >> >> _______________________________________________ >> >> 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
