Well, all ROM is read only memory, but that's not the reason for No 3.
To execute it, the ROM must be read and written into RAM so the processor can deal with it. IF you can somehow exploit the copy which is in RAM then you can pwn it. It's just not as simple as it sounds, because that process is well protected at multiple levels within the architecture of the system. In over simplistic terms you need a flaw in the ROM which you can exploit, such as limera1n or SHAtter, in order to get your own code "into" the copy of the bootrom which is running in RAM. If the flaw is in the read-only area then it will always be copied into RAM and therefore you can always exploit it. That is why we say the A4 devices are pwnd for life. Apple can't fix it without revising the hardware.
@i0n1c posted details on how the untether was fixed when 4.3.4 was released. It relied on a vulnerability in the dynamic linker which Apple patched, but this was not part of the rom (otherwise they would not have been able to fix it).
The following is part of what he tweeted:
You are going to have to get to grips with understanding the assembly language commands I have highlighted in bold if you want a chance at becoming a JB developer (developing the JB, not the tweaks / apps). I highly recommend starting by reading "Hacking: The art of exploitation" by Jon Erickson, and also looking into disassembling. The tool of choice for iDevice jailbreakers is IDA Pro, but I warn you now, it isn't cheap. But if you are serious about it, it's the way to go IMHO.Quote:
The dynamic linker performs additional checks on the mach-o header to stop a class of attacks against the dynamic linker.
This is how Apple broke your hearts: ADD.W R3, R11, #0xFFFFFFFF – CMP R3, #9 – BHI get_out_of_here
It checks the demux_count in ndrv_setspec. Actually no. That code is the code that fixes the untether exploit.
Again, if anyone else knows better, feel free to chip in.