Every car hacking tool I have come across required expensive ECUs, adapters or even full test benches. Having worked with test cars before, I got an insight into how time consuming and expensive, if not difficult it is to set a working HIL (Hardware-In-Loop) setup. I didn’t want to wait for hardware to understand how automotive networks behave - I wanted to simulate it.

So, I built my own virtual car hacking network using Linux tools, a bit of Python, and some creative problem solving.

Background

Automotive Cybersecurity is fascinating. Being extremely niche, it isn’t the first thing that comes to mind when someone thinks of cybersecurity. They imagine computers, massive server farms and a network that connects them all. But what is a modern car, if not a network of highly powerful computers, on wheels.

Working with cars as a pentester has had me dealing with security at the intersection of software and hardware - but I wanted to explore the same logic on my own terms.

A vehicle’s network is split into three specific interfaces:

1. CAN (Controller Area Network) - the most widely used
2. LIN (Local Interconnect Network) - for low-speed/low-cost devices
3. Automotive Ethernet (100BASE-T1, 1000BASE-T1, etc.) - higher bandwidth, growing adoption

Infotainment Systems, Sensors, ECUs, they all talk over these buses. Setting these up requires a lot of specialized hardware and software. This includes purchasing an expensive license with the already expensive hardware which is designed to simulate and control such networks. (Yes Vector, I’m talking about you). These tools are brilliant, but they’re practically out of reach when you’re hacking solo and not backed by a corporation.

So: emulate it.

The Idea

If network penetration testers can simulate servers and routers, why can’t car hackers simulate ECUs? After all, ECUs are basically computers that run a specific piece of software or a specific operating system on them, designed to only perform specific tasks.

In a world where we have virtual machines helping us run multiple computers on one, I started brainstorming if it was possible to create ECUs digitally, without all the fancy expensive hardware. What would you possibly need? GPS? Wi-Fi? Bluetooth? A platform to run apps and scripts? A logger? All of this already exists on a standard laptop. The only thing that stood out to me was the communication interfaces. CAN is not used anywhere apart from automotive networks. Neither is LIN or 100Base-T1 (Automotive Ethernet for a reason). This made me research even more. What could possibly help me simulate CAN?

“If there’s a will, there is a way.” ~ some wise person

The Build

After a bit of research, I came across SocketCAN. It’s a Linux kernel subsystem that exposes CAN interfaces like any other network device. Think CAN, but now it runs pretty much anywhere. It allows us to create virtual CAN interfaces on Linux, or connect to physical CAN networks present on an actual car.

It doesn’t have anything to do with what flavour you choose as it is built into the kernel. It is only a matter flipping the switch and enabling it:

1

sudo modprobe vcan

This will help enable the vcan (virtual CAN) interface module.

After this, you can create the virtual CAN interface:

1

sudo ip link add dev vcan0 type vcan

1

sudo ip link set up vcan0

Run this to confirm if you’ve got it:

1

ifconfig

1
2
3
4
5
6

vcan0: flags=193<UP,RUNNING,NOARP>  mtu 72
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

And voila! You now have a virtual CAN interface, ready to read and transmit CAN frames.

Sending packets

What’s the point of creating an interface if you’re not going to use it? To send packets on this interface, we have a set of can tools that you can install on pretty much any Linux machine as well.

I use the Blackarch repository on my Arch Linux machine. If you’re on Debian, you can use Kali Linux’s repository for the same. Both of them contain the package we want to install.

Fedora users please don’t come after me

Arch Linux:

1
2

sudo pacman -Syu
sudo pacman -S can-utils # tools for working with CAN

Debian:

1
2

sudo apt-get update && apt-get upgrade
sudo apt-get install can-utils

This will give you access to these tools:

1. candump
2. cansend
3. canplayer
4. cansniffer

…and more.

To send packets on the virtual bus (vcan0), use this command:

1

cansend vcan0 123#AABBCCDDEEFF

If it doesn’t output anything, congratulations! You’ve sent your first CAN frame using Linux!

But… how do we know that it got sent? We can use candump, which continuously listens for any CAN messages being transmitted on the bus you specify to it as an argument.

1

candump vcan0

While this is running, send the example CAN frame with cansend from another terminal again. This time, you’ll see it pop up on the listener as a properly formatted CAN frame:

1

vcan0  123   [6]  AA BB CC DD EE FF

Brilliant. You’ve now mastered the art of sending CAN frames on a bus using Linux, and only Linux.

What makes this fun is you can also build your own custom logger and transmitter using Python, with the python-can library. It can both send and listen for CAN frames on any CAN interface.

Here’s one if you want to try it out:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

#!/usr/bin/env python3
import can
import time
import threading

def receiver(bus):
    """Receive and print CAN messages."""
    print("[Receiver] Listening for CAN messages...")
    for msg in bus:
        print(f"[Received] ID: {msg.arbitration_id:#04x}, Data: {msg.data.hex().upper()}")

def sender(bus):
    """Send CAN messages periodically."""
    print("[Sender] Starting message transmission...")
    msg = can.Message(arbitration_id=0x123, data=[0x11, 0x22, 0x33, 0x44], is_extended_id=False)
    while True:
        try:
            bus.send(msg)
            print(f"[Sent] ID: {msg.arbitration_id:#04x}, Data: {msg.data.hex().upper()}")
            time.sleep(1)
        except can.CanError:
            print("[Error] Message not sent")

def main():
    # Connect to virtual CAN interface
    bus = can.interface.Bus(channel="vcan0", bustype="socketcan")

    # Start receiver in background thread
    recv_thread = threading.Thread(target=receiver, args=(bus,), daemon=True)
    recv_thread.start()

    # Start sending messages
    sender(bus)

if __name__ == "__main__":
    main()

This simple program lets you prototype virtual ECUs that send/receive frames — perfect for building test scenarios.

Reflection

My reflection on this piece of work includes this:

1. If I create ECUs built on either C or C++, using the same logic that a standard ECU would, I could have it generate CAN frames for specific functions and accept CAN frames to perform specific functions. This completely virtualizes the test bench and makes it portable.
2. The presence of Python (python-can) allows us to craft custom CAN packets, which opens doors to creating a fuzzer that mutates CAN frames randomly.
3. All of this put together gives us a basic, but robust virtual car, which can be used to practice pentesting and diagnostics(Enter, UDS).
4. I can safely test security features without messing with actual hardware(did I tell you it was very expensive?).
5. I can practice IDS detection in Wazuh or Suricata by integrating the CAN logs.
6. Train myself and others without physical ECUs.

Hacking isn’t about fancy gear. It’s about creativity. By virtualizing this challenge, I learned more about CAN networks, Linux Networking, and the hacker mindset in itself.

If you are into automotive cybersecurity but don’t know where to start, start by simulating - the best labs are the ones you build yourself.

What’s Next?

1. Create an instrument cluster/infotainment system next and connect it to my virtual network to simulate a more complete in-vehicle setup.
2. Setup UDS (Unified Diagnostics Services) request/response handling in a virtual ECU

Thanks for reading — I’ll keep posting updates as I build the next pieces (infotainment mock, UDS handlers, and a tiny fuzzer). If you want the example scripts or a reproducible repo structure, tell me and I’ll publish them on GitHub.

My First Wi-Fi Pentest

There’s a massive difference between watching pentesting videos and actually doing it. This was my first time seriously trying Wi-Fi pentesting, and it was a mix of pure excitement, a bunch of silly mistakes, and that one moment of “YES! It finally worked.”

Disclaimer: This is just my story, not a tutorial. Everything I did was on my own network. Don’t go around trying this on random Wi-Fi unless you like the idea of explaining yourself to law enforcement.

Gearing Up

My setup was simple – my Arch Linux laptop, an Alfa adapter, and the Aircrack-ng suite.

At this point, I was overconfident. In my head, it was just: “Enable monitor mode, grab handshake, crack password. Done.”

Spoiler: life doesn’t work that way.

Where I Fell Flat

The very first thing I did? I forgot to disable all the services that fight you for control of the adapter.
Result: Warnings everywhere, services kept messing with monitor mode.

Once I figured that out, things finally started looking cool. My terminal was scrolling with access points like some cyberpunk movie scene.

The “Why Is Nothing Happening?” Phase

I locked onto my target, sat back, and… nothing. No handshake.

Turns out, distance does matter. I was sitting too far from the router like some wannabe hacker in a corner. Moving closer fixed everything, and that glorious “Handshake captured!” message finally appeared.

The Brutal Reality Check

Cracking it? Yeah, that part didn’t happen. My wordlist didn’t have the password (because of course it didn’t). Turns out a 14 million password wordlist doesn’t contain the password from all over the universe. (because of course it doesn’t).

But honestly, just getting that handshake felt like a small win. I’d done the whole process myself and figured out where I’d gone wrong.

Lessons Learned

• The tools are just tools. Knowing how to troubleshoot when things fail is the real skill.
• Proximity is underrated. Sitting 10 feet further might be the difference between success and nothing happening.
• Wordlists are everything. A bad one means hours of wasted time.
• There are certainly other methods of “getting passwords” from your target other than using wordlists *wink* (will cover this in the future)

Why I’m Glad I Did It Manually

I could’ve just used Airgeddon or some automated script, but figuring it out command by command taught me why things work, not just how to click buttons.

Next up? I’ll see if I can get Airgeddon to make my life easier without making me lazy.

This wasn’t some cinematic “Hollywood hacking” moment. It was messy, frustrating, and way less glamorous than it looks online. But that’s what made it fun.

The real flex isn’t showing commands – it’s showing that you understand what’s happening under the hood and can figure things out when they go wrong.