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? 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 13: | Line 13: | ||
=== Soldering with the board === | === Soldering with the board === | ||
On the SAA-001 motherboard, RX going to Aeolia is on side A and TX going to APU is on side B. They desoldered | On the SAA-001 motherboard, RX going to Aeolia is on side A and TX going to APU is on side B. They desoldered the decoupling caps on the PCIe x4 LVDS RX line between the Aeolia and APU. Then they also soldered into the PCIe clock, but this is a little trickier since I you need to match correct LVDS impedance and such while doing it in parallel. I will say that the DC offset in the LVDS signals might be negligible in this setup, but you also might want to make sure that there are 100 nF caps inline with the RX/TX signal pairs. I would use some thin high guage solid core copper wire and hot glue to solder to these pads. | ||
==== Setting up the FPGA ==== | ==== Setting up the FPGA ==== | ||
They used an ECP3 Versa Devkit from Lattice, but the newer ECP5 Versa Devkit would also work. Some good Virtex-7, from Xilinx, boards are out there but at the same time anyone can buy some a very expensive devkit that has a PCIe card slot. I presume they chose the ECP3 Versa Devkit because it has a nice very example for PCIe DMA. They hooked up one of the pairs of TX bus, so cutting it from x4 to x1, to the FPGA. I am not sure if this specific ECP3 kit has the 100 nF caps already, simply look and you will see - maybe only on RX. | They used an ECP3 Versa Devkit from Lattice, but the newer ECP5 Versa Devkit would also work. Some good Virtex-7, from Xilinx, boards are out there but at the same time anyone can buy some a very expensive devkit that has a PCIe card slot. I presume they chose the ECP3 Versa Devkit because it has a nice very example for PCIe DMA. They hooked up one of the pairs of TX bus, so cutting it from x4 to x1, to the FPGA. I am not sure if this specific ECP3 kit has the 100 nF caps already, simply look and you will see - maybe only on RX. Then hookup the PCIe clock. | ||
==== Setting up the computer ==== | ==== Setting up the computer ==== | ||
They then hooked up the RX line to some generic x86 | They then hooked up the RX line to some generic x86 board. 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]. The board they bought probably supported PCIe 2.0 and had a capable Serial/UART port. I will discuss more important factors in the software section, but they were vague on this part. Then hookup the PCIe clock. | ||
=== 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 27: | Line 27: | ||
The FPGA setup would look like this... | The FPGA setup would look like this... | ||
<br />[[File:PCIe_FPGA_Diagram.png]]<br /> | <br />[[File:PCIe_FPGA_Diagram.png]]<br /> | ||
I would look at the ECP3 setup for how to work with Lattice IP. This is really just about linking together IP blocks with a little glue logic. Go grab some random HDL UART implementation and set it up at the same baud as the PC. If you are dealing with Xilinx, then start reading documentation because you might need a completely scratch solution; I have no clue if examples exist. After this is all done, then I would look into different attack vectors by inserting or modifying transaction layer packets - but then specifically the wrapped protocols. | I would look at the ECP3 setup for how to work with Lattice IP. This is really just about linking together IP blocks with a little glue logic. Go grab some random HDL UART implementation and set it up at the same baud as the PC. If you are dealing with Xilinx, then start reading documentation because you might need a completely scratch solution; I have no clue if examples exist. | ||
After this is all done, then I would look into different attack vectors by inserting or modifying transaction layer packets - but then specifically the wrapped protocols. | |||
=== 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 are communicate with the Aeolia glue 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 | == PCI device list == | ||
<syntaxhighlight lang="text" enclose="div"> | <syntaxhighlight lang="text" enclose="div"> | ||
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0 | pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0 | ||