Page 1 of 1

Why is yalu102 an armv7 binary?

PostPosted: Thu Feb 02, 2017 4:05 pm
by scknight
Out of curiosity, does anyone know why yalu102 is a 32bit armv7 binary? Was this just done to make the embedded assembly smaller and easier to write? I just started taking a look at it and was surprised to get the "this app might slow down your iphone" message from iOS on first start.

Re: Why is yalu102 an armv7 binary?

PostPosted: Thu Feb 02, 2017 4:45 pm
by morpheus
because Luca needed an address that was both valid and also < 400MB, in order to exploit the mach voucher bug ( ... il?id=1004). You can compile for ARMv8 if you set pagezero size to 0x16000

Re: Why is yalu102 an armv7 binary?

PostPosted: Thu Feb 02, 2017 8:10 pm
by scknight
Ahh I see now. Looking at pagezero on yalu102, Ian's example and a normal app produces the following:

Code: Select all
LC 00: LC_SEGMENT_64          Mem: 0x000000000-0x100000000   __PAGEZERO (Normal 64 bit app)
LC 00: LC_SEGMENT             Mem:  0x00000000- 0x00004000   __PAGEZERO (yalu102 32 bit app)
LC 00: LC_SEGMENT_64          Mem: 0x000000000-    0x18000   __PAGEZERO (Ian Beer's with -pagezero_size 0x16000)

So is it normal for 32bit apps to have a 16k PAGEZERO? I tried to do some googling and it seemed like most of what I could find suggested on 32bit apps PAGEZERO was 4k. Maybe that's what it used to be. Also interesting to note in Ian's example he specifies 0x16000 but at least when I compiled it it was set to 0x18000.

Thanks for the info!

Re: Why is yalu102 an armv7 binary?

PostPosted: Sat Feb 04, 2017 7:11 pm
by morpheus
- 64-bit apps' PAGEZERO covers the entire 32-bit address space, doubling both as a NULL trap as well as ensuring that no 32-bit code accidentally gets mapped in, or 32 bit pointers get dereferenced.
- 32-bit apps' PAGEZERO is exactly one page, but per the underlying architecture pagesize. On ARMv7 or i386 it's indeed 4k, as you say. But on ARMv8, that's 16k (0x4000)
- Ian Beer (and Yalu, if you port it to full 64) set a larger page zero size so that they can pull of their trick. That it gets to be 0x18000 is peculiar, but insignificant - so long as the memory can be derefed.