DataBridge

A command-line tool to visualise the flow of data through a computer system. Here is a breakdown of the data's journey:

Keyboard to RAM: The user enters a string, which is stored in the keyboard buffer and then written to RAM.
RAM to CPU: The string is processed by the CPU (converted to uppercase). This involves transferring the data to the CPU, where the ALU performs the transformation.
CPU to GPU: The uppercase string is then written to the GPU's VRAM and reversed using a custom OpenCL kernel.
GPU to RAM to SSD: The reversed string is sent back to RAM and then written to a file on the SSD.
SSD to RAM: The data is read from the SSD back into RAM. To simulate SSD "wear and tear", a random bit in the data may be flipped, introducing a data corruption that will be detected by the SHA256 hash check.
RAM to Environment Variable: The (potentially corrupted) data is then encoded in Base64 and stored in an environment variable.
Environment Variable to RAM: The data is read from the environment variable and decoded from Base64 back into its original form.
RAM to NIC: The data is then sent to the Network Interface Card (NIC). To simulate real-world network conditions, the data is split into packets, which are then randomly shuffled and may be "dropped".
NIC to RAM to Display: The packets are received from the NIC, reassembled (with placeholders for any missing packets), and then displayed as a QR code.

At each step, the tool prints a detailed log to the console, including the data, its memory address, and a SHA256 hash to verify its integrity.

Inspiration

We wanted to learn more about the freaky places data can be stored on a machine, to utilise the entire computer and bring it all together.

What it does

Shows the journey of data through all the hardware of a computer.

Challenges we ran into

Two of our team members had previously done a course on CUDA so expected the GPU reads and writes to be relatively simple but since none of our devices have an Nvidia GPU, we had to learn more about a different API to interface with the GPU. We painfully learnt how to set up OpenCL and then how to use it (which was nice to see how it fits in with paradigms from CUDA). We also explored Unix named pipes (FIFOs), which are often used for inter-process communication, but encountered blocking issues. We wanted to integrate tcpdump to show how the data went through the NIC buffer however due to firewall permissions we weren't able to do this.