Introduction#

A dealer tool has been leaked: dealer_unlock.pyc SecurityAccess guards the ECU’s secrets. Break in and read the flag.

Connection: ./connect.sh 20.18.209.122 13337 Diagnostic CAN IDs: tester 0x7E0 ↔ ECU 0x7E8

Note: This challenge requires a Linux environment with SocketCAN support. Please run the connection script on a Linux system where the vcan0 interface can be created. Sessions are terminated after 5 minutes, and reconnected automatically.

My first CAN challenge#

This is my first challenge with the CAN bus or automotive security. So please feel free to contact me if I’ve written anything that’s incorrect or unclear.

Info Gathering#

The file ./connect.sh create a container to run this challenge. After the container is ready, it shows a banner with information about command we can use:

1
=== NDIAS Automotive/IoT CTF Player ===
2
  candump vcan0                          # watch CAN traffic
3
  isotprecv -s <SRC> -d <DST> vcan0 &    # ISO-TP receiver
4
  printf <HEX> | isotpsend -s <SRC> -d <DST> vcan0   # ISO-TP send
5
  python3 -m caringcaribou --help        # UDS scanner (install: pip3 install git+https://github.com/CaringCaribou/caringcaribou.git)
6
=======================================

Each command has an explanation of its purpose. Let’s start to use candump vcan0.

Note: vcan0 is a virtual interface which is userful to communicate with the service.

The output:

1
root@9cd4b4f4f139:/# candump -a -l vcan0
2
Disabled standard output while logging.
3
Enabling Logfile 'candump-2026-05-16_072201.log'

We use -l flag to save candump’s output in a log file and filter its result:

1
root@9cd4b4f4f139:/# cat candump.log | grep -oP '.{3}#' | sort | uniq -c | sort -nr
2
     86 0C0#
3
     17 0D0#
4
      9 180#
5
      4 321#
6
      3 3B0#
7
      2 600#
8
      2 4F0#
9

10
root@9cd4b4f4f139:/# cat candump.log | grep "4F0"
11
(1778916121.704777) vcan0 4F0#0300000000000000
12
(1778916126.793852) vcan0 4F0#0300000000000000
13
root@9cd4b4f4f139:/# cat candump.log | grep "600"
14
(1778916121.705025) vcan0 600#4E44494153000000
15
(1778916126.794075) vcan0 600#4E44494153000000
16
root@9cd4b4f4f139:/# cat candump.log | grep "3B0"
17
(1778916122.716047) vcan0 3B0#0000000000000000
18
(1778916125.784145) vcan0 3B0#0000000000000000
19
(1778916128.813210) vcan0 3B0#0000000000000000
20
root@9cd4b4f4f139:/# cat candump.log | grep "321"
21
(1778916122.715577) vcan0 321#0322F19000000000
22
(1778916124.735584) vcan0 321#0322F19000000000
23
(1778916125.532145) vcan0 0C0#27B0000000000000
24
(1778916126.793806) vcan0 321#0322F19000000000
25
(1778916128.813173) vcan0 321#0322F19000000000
26
(1778916128.813210) vcan0 3B0#0000000000000000
27
root@9cd4b4f4f139:/# cat candump.log | grep "180"
28
(1778916121.704679) vcan0 180#7D00000000000000
29
(1778916122.715515) vcan0 180#7C00000000000000
30
(1778916123.725890) vcan0 180#7F00000000000000
31
(1778916124.735484) vcan0 180#7D00000000000000

As we can see, there are a lot of IDs, but not really userful because I couldn’t communicate with them with isotprecv and isotpsend and I don’t know why :(.

After getting stuck for a while, I realized that there’s a good description of the challenge; maybe I should read it more carefully:

1
Diagnostic CAN IDs: tester 0x7E0 ↔ ECU 0x7E8

OH YES! Maybe we can use CAN ID 0x7E0 and 0x7E8… But what are CAN IDs? IDs in the CAN bus are used for physical addressing during communication with the ECU.

Now we know how to comunicate with a ECU. Let’s use isotprecv:

1
root@c37f42bb4c89:/# isotprecv -s 7e0 -d 7e8 vcan0 &

The & is userful to run the bash command in background

But this command alone doesn’t provide any information, because we have to send a signal to the ECU and wait for a response. So we would use isotpsent:

1
root@c37f42bb4c89:/# echo "11" | isotpsend -s 7e0 -d 7e8 vcan0

But we receive:

1
7f 11 11

At least we got a response. But what are these hex values? I try to search it and I found these docs RAMN where is written:

1
- 0x11 - “Service not supported”.
2
- 0x7F - “Service not supported in active session”: same as above, but for services instead of sub-functions.

On the same page, you can see that these codes refer to the UDS protocol, which is used for diagnostics and employs a request-response mechanism to communicate with the ECU. The request begins with the first byte, which specifies the service to be used, followed by bytes representing a sub-function (if necessary).

Another useful information is that an ECU uses 0x7E0 to receive command and 0x7E8 to send response, this is the reason why we set with the flag -s the hex value 7e0 and with the flag -d 7e8.

Perhaps our hexadecimal value doesn’t correspond to an available service. We need to figure out which service we can use, and a UDS scanner might be just what we need. The same banner tell us about caringcaribou a tool for car security that integrates an UDS scanner. One way to search for services is to use this command: caringcaribou uds services 0x7E0 0x7E8. It found 0x22 (READ DATA BY IDENTIFIER)

We can now craft a payload with first byte 22, but what should we send next? Maybe we could ask about the Serial Hardware of ECUwith F1 8C?

F1 8C is a DID (Data Indentifier), which is used to request data from ECU in a vehicle. It’s like an address where are stored data

1
root@c37f42bb4c89:/# isotprecv -s 7e0 -d 7e8 vcan0 &
2

3
root@c37f42bb4c89:/# echo "22 F1 8C" | isotpsend -s 7e0 -d 7e8 vcan0
4
7f 11 33

Ok another negative response:

1
0x33 - “Security access denied”: this means that you need to unlock the service (see Security Access (0x27)) before using it.

That’s because the ECU is locked, so we need to find out how we can unlock it. In Security Access section of the documentation explains how to submit a request (with 27 01) to obtain a seed and calculate a key using a cryptographic algorithm. However, we do not know which algorithm is used for authentication… or maybe yes! The challenge give us another file called dealer_unlock.pyc that is a Byte-compiled Python module for CPython 3.12. This file need two arguments: a password and a seed. But we could only get a seed but the password? Maybe we need to reverse engineering the binary.

My solution#

From now we define our idea to solve this challenge:

1. Reverse the Python binary
2. Write a reverse cripto algorithm to compute a key
3. Send the key to the service

We can’t see the source code of the binary file, so we have to decompile it. There are many decompilers for Python bytecode, but not all of them are useful. I found a decompiler online that might make our job easier: Pylingual

The decompiled python code is the following:

1
# Decompiled with PyLingual (https://pylingual.io)
2
# Internal filename: '/tmp/dealer_unlock.py'
3
# Bytecode version: 3.12.0rc2 (3531)
4
# Source timestamp: 2026-05-13 02:13:16 UTC (1778638396)
5

6
"""\nLeaked Linux diagnostic helper.\n"""
7
def rol32(v, c):
8
    v &= 4294967295
9
    c &= 31
10
    return (v << c | v >> 32 - c) & 4294967295
11
def ror32(v, c):
12
    v &= 4294967295
13
    c &= 31
14
    return (v >> c | v << 32 - c) & 4294967295
15
def derive_key(seed):
16
    x = seed ^ 2781028135
17
    x = rol32(x, 3)
18
    x = x + 522125569 & 4294967295
19
    x ^= 3735928559
20
    x = ror32(x, 1)
21
    return x & 4294967295
22
if __name__ == '__main__':
23
    import sys
24
    import hashlib
25
    if len(sys.argv)!= 3:
26
        print('usage: dealer_unlock.py <password> <seed_hex>')
27
        raise SystemExit(1)
28
    else:
29
        hash = hashlib.sha1(sys.argv[1].encode()).hexdigest()
30
        if hash!= 'd5dcd954a0928a024f3cfe35da1d6469c19a170b':
31
            print('Incorrect password')
32
            raise SystemExit(1)
33
        else:
34
            seed = int(sys.argv[2], 16)
35
            print(f'{derive_key(seed):08X}')

By looking at this code, we can avoid bypassing the hash check since we only want to generate the key.

1
# Decompiled with PyLingual (https://pylingual.io)
2
# Internal filename: '/tmp/dealer_unlock.py'
3
# Bytecode version: 3.12.0rc2 (3531)
4
# Source timestamp: 2026-05-13 02:13:16 UTC (1778638396)
5

6
"""\nLeaked Linux diagnostic helper.\n"""
7
def rol32(v, c):
8
    v &= 4294967295
9
    c &= 31
10
    return (v << c | v >> 32 - c) & 4294967295
11
def ror32(v, c):
12
    v &= 4294967295
13
    c &= 31
14
    return (v >> c | v << 32 - c) & 4294967295
15
def derive_key(seed):
16
    x = seed ^ 2781028135
17
    x = rol32(x, 3)
18
    x = x + 522125569 & 4294967295
19
    x ^= 3735928559
20
    x = ror32(x, 1)
21
    return x & 4294967295
22
if __name__ == '__main__':
23
    import sys
24
    import hashlib
25

26
    seed = int(sys.argv[1], 16)  #set argv[1] for take the first argument
27
    print(f'{derive_key(seed):08X}')

Now we need to run the Python script, passing the seed as an argument, send the calculated key, and unlock the service.

We request the seed:

1
isotprecv -s 7e0 -d 7e8 vcan0 &
2
[1] 396
3
root@c37f42bb4c89:/# echo "27 01" | isotpsend -s 7e0 -d 7e8 vcan0
4
root@c37f42bb4c89:/# 67 01 46 2D 8C 6E

Just to clarify: we couldn’t send the 27 01 payload directly because the ECU is in a Default (10 01) or Programming (10 02) session, which are types of Diagnostic Session Controls, and might reject our authentication request. We need to switch it to an Extended Diagnostic Session (10 03) before we send 27 01 :

1
root@c37f42bb4c89:/# isotprecv -s 7e0 -d 7e8 vcan0 &
2
root@c37f42bb4c89:/# echo "10 03" | isotpsend -s 7e0 -d 7e8 vcan0
3
root@c37f42bb4c89:/# 50 03 00 32 01 F4

Using the seed in our python script:

1
[shackwove@pwned automotive]$ python3 exploit.py 462D8C6E
2
F01F12DF

Ok, we got the key, let’s send it:

1
root@c37f42bb4c89:/# isotprecv -s 7e0 -d 7e8 vcan0 &
2
[1] 404
3
root@c37f42bb4c89:/# echo "27 02 F0 1F 12 DF" | isotpsend -s 7e0 -d 7e8 vcan0
4
root@c37f42bb4c89:/# 67 02

The code 67 tell us that the service has been unlocked, now we are close to the flag :))))

We need to send a request to a valid DID to obtain the flag. After a few attempts (and so many re-connections that have undone all the work I’ve done so far), I wrote a simple script that performs a brute-force attack on DIDs and we found that DID 13 37 is the winner.

1
root@c37f42bb4c89:/# isotprecv -s 7e0 -d 7e8 vcan0 &
2
[1] 407
3
root@c37f42bb4c89:/# echo "22 13 37" | isotpsend -s 7e0 -d 7e8 vcan0
4
root@c37f42bb4c89:/# 62 13 37 66 6C 61 67 7B 73 33 33 64 6B 33 79 5F 72 33 76 33 72 73 33 64 7D

66 6C 61 67 7B 73 33 33 64 6B 33 79 5F 72 33 76 33 72 73 33 64 7D is our flag!

Flag: flag{s33dk3y_r3v3rs3d}