I Like Hacking Computers
Computers these days are too restricted. I understand that a lot of this is security through obscurity, but that doesn't work as well as people think. I've come to have trust issues with a lot of closed source software.
For those who do not know what closed and open source are, an open source program has all of their code available to the public. This code can then be compiled and run. A closed source program does not have the source code available and is distributed as a neat little package. The problem with this is that you can never really know what it's doing unless you were to do reverse engineering. That's when you take a compiled program and sort through all of the gibberish and turn it back into readable code. Reverse engineering can take years, or even decades depending on the size and complexity of whatever you're getting into.
I really enjoy hacking closed source systems to prove my point about closed source having flaws. I've mostly focused on really low level stuff in mobile devices, because it's simple. I love bootROMs. Think of them as a computer BIOS, but it's a little different. The bootROM is a little piece of flash memory that's usually write protected and it holds a little bit of code written in Assembly. This code is used to start the SoC (processor) and then start a very small and stripped down bootloader. This bootloader just initializes other hardware, but the main job is to jump the secondary (main) bootloader. The secondary bootloader starts the kernel and OS. So back to the bootROM, these are usually accessible via a serial connection which it sets up within itself on boot. I personally think this is retarded, but I think it's how they're flashed during production (would anyone care to disprove that?). The iOS devices call the bootROM a SecureROM. I've found in my studies of them that only a very small segment is read only, and that the rest is simply write protected. So I wrote a USB fuzzer and started feeding packets into it. I found that there were several areas of memory that go unchecked in the main stack. There's also ways to attack the heap if I so choose, but I see little value in that at such a time. The most interesting thing I have found is that I can shift some data (I say data because I don't know what it does) over a few bytes, and the index won't reset on a reboot. This is a huge vulnerability, since I can basically customize this little area and have it stick through two or three full reboots. However, the SecureROM crashes when I try to manipulate the index in any way after a reboot. I can't dump the SecureROM from that low of a level (need iBoot or above at the moment), so I can't analyze the crashes. I've been doing this testing on an iPhone SE, but the SecureROM is the same across all A9 devices.
Protip: In an Apple Lightning cable, the last 5/8 pins on the top are dynamic, as are the fist 5 on the bottom. It took me way too long to figure that out.
For those who do not know what closed and open source are, an open source program has all of their code available to the public. This code can then be compiled and run. A closed source program does not have the source code available and is distributed as a neat little package. The problem with this is that you can never really know what it's doing unless you were to do reverse engineering. That's when you take a compiled program and sort through all of the gibberish and turn it back into readable code. Reverse engineering can take years, or even decades depending on the size and complexity of whatever you're getting into.
I really enjoy hacking closed source systems to prove my point about closed source having flaws. I've mostly focused on really low level stuff in mobile devices, because it's simple. I love bootROMs. Think of them as a computer BIOS, but it's a little different. The bootROM is a little piece of flash memory that's usually write protected and it holds a little bit of code written in Assembly. This code is used to start the SoC (processor) and then start a very small and stripped down bootloader. This bootloader just initializes other hardware, but the main job is to jump the secondary (main) bootloader. The secondary bootloader starts the kernel and OS. So back to the bootROM, these are usually accessible via a serial connection which it sets up within itself on boot. I personally think this is retarded, but I think it's how they're flashed during production (would anyone care to disprove that?). The iOS devices call the bootROM a SecureROM. I've found in my studies of them that only a very small segment is read only, and that the rest is simply write protected. So I wrote a USB fuzzer and started feeding packets into it. I found that there were several areas of memory that go unchecked in the main stack. There's also ways to attack the heap if I so choose, but I see little value in that at such a time. The most interesting thing I have found is that I can shift some data (I say data because I don't know what it does) over a few bytes, and the index won't reset on a reboot. This is a huge vulnerability, since I can basically customize this little area and have it stick through two or three full reboots. However, the SecureROM crashes when I try to manipulate the index in any way after a reboot. I can't dump the SecureROM from that low of a level (need iBoot or above at the moment), so I can't analyze the crashes. I've been doing this testing on an iPhone SE, but the SecureROM is the same across all A9 devices.
Protip: In an Apple Lightning cable, the last 5/8 pins on the top are dynamic, as are the fist 5 on the bottom. It took me way too long to figure that out.
