Editing PCIe
Jump to navigation
Jump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
| Latest revision | Your text | ||
| Line 1: | Line 1: | ||
== PCIe Hacks == | == PCIe Hacks == | ||
=== Introduction === | === Introduction === | ||
The fail0verflow group revealed at 33c3 ([https://fail0verflow.com/blog/2016/console-hacking-2016-postscript/ here]) how they initially hacked the PS4 kernel. I will speculate a little detail about how I think they did this? I recommend watching the presentation and reading the postscript. I am pretty sure this is still a promising hack, even though newer kernels will patch the slfash IOMMU stack exposure. It might be better to hack the Aeolia alone | The fail0verflow group revealed at 33c3 ([https://fail0verflow.com/blog/2016/console-hacking-2016-postscript/ here]) how they initially hacked the PS4 kernel. I will speculate a little detail about how I think they did this? I recommend watching the presentation and reading the postscript. I am pretty sure this is still a promising hack, even though newer kernels will patch the slfash IOMMU stack exposure. It might be better to hack the Aeolia alone; but this hack will also work on a PS4 Pro, which I hear is protected against differential power analysis for key recovery? I wrote this very late at night so there are probably typos and errors. If other people take interest in this, I might buy some equipment. | ||
=== Reading === | === Reading === | ||
| Line 21: | Line 21: | ||
They then hooked up the RX line to some generic x86 single board computer. I have no clue what they used here but it could be something as simple as [https://www.compulab.com/products/sbcs/ one of these] with a mini-pcie to pcie adapter and soldered right to the adapter. The board they bought probably supported PCIe 2.0 and had a capable Serial/UART port. They then hooked up wires for the PCIe clock from the Aeolia side to the x86 computer. I will discuss more important factors in the software section, but they were vague on this part. | They then hooked up the RX line to some generic x86 single board computer. I have no clue what they used here but it could be something as simple as [https://www.compulab.com/products/sbcs/ one of these] with a mini-pcie to pcie adapter and soldered right to the adapter. The board they bought probably supported PCIe 2.0 and had a capable Serial/UART port. They then hooked up wires for the PCIe clock from the Aeolia side to the x86 computer. I will discuss more important factors in the software section, but they were vague on this part. | ||
=== Software Overview === | ==== Software Overview ==== | ||
If you are working with Xilinx then have a field day. If you are working with Lattice then you have a nice example but annoying licensing. Contact me if you need help with Lattice licensing as I know its stupid. | If you are working with Xilinx then have a field day. If you are working with Lattice then you have a nice example but annoying licensing. Contact me if you need help with Lattice licensing as I know its stupid. | ||
On the generic x86 board, they have some custom ? Linux setup ? running with some sort of shim that takes in data from PCIe TLPs and queues them in a FIFO. Then they send this data out from the FIFO to the serial and FPGA to transmit to the APU. The shim seems to be a custom C Linux driver or something - no clue here but there might be a generic driver that can just take in the raw data from separate TLP types, try a tty configuration? The Linux kernel aspect would then send all this raw data to maybe a python program that handles the FIFO and inserting new TLPs to the FIFO. This management program would then send the data over to the Serial to the FPGA which would handle sending the TLP packet. Set the baud to 115200 of higher if you feel lucky on the UART. | On the generic x86 board, they have some custom ? Linux setup ? running with some sort of shim that takes in data from PCIe TLPs and queues them in a FIFO. Then they send this data out from the FIFO to the serial and FPGA to transmit to the APU. The shim seems to be a custom C Linux driver or something - no clue here but there might be a generic driver that can just take in the raw data from separate TLP types, try a tty configuration? The Linux kernel aspect would then send all this raw data to maybe a python program that handles the FIFO and inserting new TLPs to the FIFO. This management program would then send the data over to the Serial to the FPGA which would handle sending the TLP packet. Set the baud to 115200 of higher if you feel lucky on the UART. | ||
| Line 30: | Line 30: | ||
=== Other avenues of exploitation over PCIe === | === Other avenues of exploitation over PCIe === | ||
It would be interesting to write a [https://en.wikipedia.org/wiki/Fuzzing fuzzer] with this hack to look into other drivers and protocols. The Aeolia controls a lot of stuff, like Ethernet, Bluetooth, | It would be interesting to write a [https://en.wikipedia.org/wiki/Fuzzing fuzzer] with this hack to look into other drivers and protocols. The Aeolia controls a lot of stuff, like Ethernet, Bluetooth, WiFi, HDMI, Optical Drive, and other system components that have corresponding protocols and drivers in the APU's FreeBSD kernel that could be buggy - especially with the fail that Sony has brought us before. These protocols communicate with the Aeolia over PCIe. The USB stack also might hold some promise. Look at the kernel and see which drivers are tainted by Sony engineers and I will expect there to be exploitable bugs. But there could also be fail in common FreeBSD drivers! I have no clue what the IOMMU blocks and what it doesn't. | ||
== PCI Device List == | == PCI Device List == | ||