June 05, 2026 / by Dave L - Fortify Labs / In teardown, technical, Hino, Freightliner, Bosch, Telematics, UBIFS, Filesystem Analysis, Embedded Linux, Reverse Engineering, Transport & Logistics, Heavy Equipment

Teardown: Hino & Freightliner
Telematics Module - Part 3

Thanks for re-joining me on the journey of figuring out whether telematics modules (Tboxes) in heavy transport trucks operate the same way as those in passenger cars.

In Part 1, I tore down the Tboxes, characterised the boards, hunted (unsuccessfully) for debug interfaces, and eventually performed a chip-off extraction of the Freightliner’s NAND flash.

In Part 2, I worked through the encoding applied by the NXP processor’s NAND controller, wrote a script to strip it out, and successfully mounted the Tbox’s five internal partitions (system0, system1, data, data_unsigned, and log) on my Ubuntu workstation.

This post is the payoff for all that effort. With the partitions mounted and readable, I could finally start digging into what these Tboxes actually do, what they store, and how they communicate data back to the manufacturer.

Here, I’ll walk through what I found, what stood out, and what questions still remain.

Note: This post doesn’t represent a full analysis, its a collection of interesting findings from my initial exploration to keep things concise.

As always, if you have questions, feel free to reach out. We’d be happy to have a chat.

Hino & Freightliner Blog Series

• Part 1: Initial Examination
  • Teardown
  • PCB Characterization
  • Searching for UART, JTAG, and WiFi
  • Chip-Off Data Extraction
• Part 2: Obtaining a Useable Image
  • Confirming NAND Controller Encoding
  • Removing NAND Controller Encoding
  • Mounting UBIFS Volumes in Linux
• Part 3: Data Analysis - This Post
  • Where to Start
  • Identifiers
  • Accounts
  • Credentials and Network Configuration
  • GPS Info - Or the lack thereof
  • A Quick Tour of What Else Is on the Chip

Where to Start

After Part 2, I had five partitions extracted from the flash and mounted locally on my Ubuntu workstation. The first step was getting a high-level understanding of what each partition contained and how they were used.

Right away I saw system0 and system1. This looks like a classic A/B (dual-partition) setup: one partition serves as the active system, while the other acts as the target for updates. This provides a safe fallback if an OTA (over-the-air) update fails.

The other three partitions (log, data, data_unsigned) likely persist across firmware updates and are a good place to look for historical records and configuration data.

Active Operating System

My first step was to determine which of the two operating system partitions was active (i.e., which one the device actually boots from). This is important because it tells us what is running during normal operation and, by extension, where to focus when testing for vulnerabilities.

For example, if I were to find credentials in the inactive slot but not the active one, those credentials wouldn’t be useful against a running Tbox. In that case, it might make sense to prioritise finding a way to force the device to boot from the inactive slot to take advantage of them.

Looking through system0 and system1, I found the following:

Based on this, system0 appears to be the newer of the two and is the likely candidate for the active partition. To confirm this, I looked for evidence of update history.

Searching for files containing “update” turned up several hits, including one that looked particularly interesting:

  $ find . -name "*update*" 2>/dev/null 
  ...
  ./mountpoints/data/signed/topas/software_update           
  ...
  $ ls -al ./mountpoints/data/signed/topas/software_update
  ...
  -rw-r--r-- 1 root root 4595 Dec 10  2021 update_history.csv

Opening it up, revealed a clear upgrade path for the device:

  DAIMLER.CTP.18.01.S.025.DTNA.RELEASE
    -> DAIMLER.CTP.18.02.S.038.DTNA.RELEASE
      -> DAIMLER.CTP.20.01.S.043.DTNA.RELEASE

The latest version (20.01.S.043) corresponds to what’s installed on system0, while the previous version (18.02.S.038) matches system1. This lines up with how a dual A/B system is typically implemented, where the inactive partition holds the previous firmware as a fallback.

Another interesting detail was the installation source. Based on the recorded paths:

• The initial version appears to have been installed via USB (usb_upd)
• The subsequent updates were delivered OTA (oda_upd)

This suggests there may be a USB-based update mechanism available. It’s something I flagged for further investigation.

To further validate that system0 was the slot being booted, I searched across the partitions for keywords that have been useful in past analyses, such as “active=system”.

We can see above that this turned up log file entries indicating that system0 was indeed the partition being booted. I didn’t find any evidence pointing to system1 as active.

Taken together, the versioning, update history, and log file evidence all aligning, it’s a safe assumption that system0 is the active firmware.

With that established, I moved on to identifying artefacts that might reveal information about the truck itself or the specific Tbox.

Identifiers

I always find an analysis more interesting when I can tie the data back to something tangible. Whether that’s the vehicle itself, real-world events, or unique characteristics of the specific truck or its equipment, being able to connect filesystem artefacts to a real asset makes everything feel a lot less abstract.

With that in mind, the first thing I went looking for was a VIN (Vehicle Identification Number).

The most successful result came from simply looking for the keyword “vin”. This produced hits in both the data and data_unsigned partitions.

As shown below, I found two files named VIN. One was filled entirely with “A” characters, while the other looked to contain a valid VIN, although it appeared duplicated:

• VIN = 3AKJHPDVXLSLM6780

  $ find . -iname "vin" 2>/dev/null
  ./data/unsigned/topas/FFS2/VIN
  ./data_unsigned/topas/FFS2/VIN

  $ cat data/unsigned/topas/FFS2/VIN 
  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA�	�
  $ cat data_unsigned/topas/FFS2/VIN 
  3AKJHPDVXLSLM67803AKJHPDVXLSLM6780��

Since a VIN is unique to a specific vehicle, the next logical step was to look it up and see if I could learn anything about the truck it belonged to.

Identifying the Truck

A quick Google search confirmed that this VIN corresponds to a real vehicle. Using public VIN decoding tools, it came back as a 2020 Freightliner Cascadia tractor (semi‑truck).

Digging a bit deeper, I found the same VIN listed in salvage auction records for a truck matching that exact year, make, and model. That was an awesome find! It tied the Tbox directly to a real-world vehicle.

Continuing the search turned up even more context, including what appears to be the incident that likely led to the truck being salvaged.

Beyond just identifying the vehicle, these searches also helped me better understand how this Tbox fits into the broader Daimler ecosystem.

For example, I came across references to “dtnacontent-dtna-test.qa.freightliner.com” which appear related to Daimler’s diagnostic and subscription-based tooling. I also found a features brochure for DiagnosticLink, Freightliner’s diagnostic software platform.

These findings helped make sense of several terms and acronyms that showed up later in the filesystem. For instance:

• “DTNA” clearly refers to Daimler Trucks North America
• Documentation from the DiagnosticLink 8.12 Features Brochure confirms support for CTP (Connected Truck Platform) updates (Flash Over-The-Air)
• Additional references pointed to “CTP” meaning Connected Truck Platform, aligning with mentions from third-party integrations like Geotab

Each of these pieces helped fill in gaps and build a clearer picture of the overall ecosystem—who’s involved, how components interact, and what role the Tbox plays within it.

Putting it all together, identifying real world information tied to the VIN ended up being more than just a curiosity, it provided concrete benefits:

• It established real timelines that can be correlated with logs and events in the data
• It added useful context around Freightliner’s connected telematics and diagnostic ecosystem
• It clarified terminology, acronyms, and vendor relationships found throughout the filesystem
• It helped build a broader mental model of how the Tbox fits into Freightliner’s infrastructure (e.g., interacting with tools like DiagnosticLink)

With a clearer understanding of the truck and its place in the connected Freightliner ecosystem, I moved on to searching for clues about what the Tbox is actually doing.

To do that, I started digging into the logpartition since logs are often one of the best places to understand system behaviour, so it felt like the natural next step.

Looking at Logs

When I started exploring the log partition, one of the first things that stood out was a large collection of “.log” files in the root directory, all following a consistent naming convention:

• CTP-<YYYYMMDD>-<HHMMSSmmmm>-<seq>.log

Because the timestamp is embedded directly in the filename, I could get a quick sense of when the Tbox was active without even opening the files.

  $ ls -al log/
  total 12692
  drwxr-xr-x 8 root root   93976 Jan  1  2016 .
  drwxrwxr-x 7 user user    4096 May 25 19:41 ..
  -rw------- 1 root utmp       0 Jan  1  2016 btmp
  -rw-rw-rw- 1 root root    6805 Apr  7  2022 CTP-20220406-165323224-9222.log
  -rw-rw-rw- 1 root root   12103 Apr  7  2022 CTP-20220406-170845218-9223.log
  ...
  -rw-rw-rw- 1 root root    3200 Apr  8 09:44 CTP-20260407-234412442-10241.log
  -rw-rw-rw- 1 root root    1494 Apr  8 09:44 CTP-20260407-234447179-10242.log
  -rw-rw-rw- 1 root root    3223 Apr  8 09:47 CTP-20260407-234628435-10243.log
  -rw-rw-rw- 1 root root    2319 Apr  8 09:48 CTP-20260407-234849303-10244.log
  -rw-rw-rw- 1 root root    1674 Apr  8 09:51 CTP-20260407-235124198-10245.log

There were over 1,000 log files in total. The majority were created between April and June 2022 (particularly in April and May) with only a handful appearing in 2024 (post-auction), and a small burst in April 2026 corresponding to lab testing.

This lined up nicely with what I found during earlier OSINT work:

• The high density of logs in April to May 2022 suggests the truck was heavily in use during that period
• Activity drops off sharply in June 2022, which aligns with the incident timeframe identified online (May 2022)
• A long period of inactivity follows until early 2024, where a small number of logs appear shortly after the vehicle auction
• The final 27 boot events correspond to my lab testing.

I also took a closer look at the “seq” portion of the filename. At first glance, it looked like it might represent a boot counter. However, after comparing timestamps, the files appear to be generated at relatively consistent intervals and in some cases roughly every 50 minutes.

That pattern doesn’t really match what you’d expect from a boot counter, so it’s more likely that seq is simply an increasing log index.

Also, the sequence numbers I observed ranged from 9,222 to 10,245 with no gaps, which strongly suggests that earlier logs were rolled over and overwritten.

By this point, I had a good sense of when the device was active and where this activity was recorded, and that the activity matched what I found online

With that established, I shifted focus. Rather than just observing behaviour through logs, I started looking at how I might interact with the Tbox itself, specifically looking for:

• Who can log in
• What privileges they have
• Whether any credentials can be recovered

That’s where I headed next.

Users and Passwords

The first place to look for accounts and credentials in any Linux system are the classic /etc/passwd and /etc/shadow files. That’s where I started.

Digging into these files turned out to be surprisingly insightful, not just for identifying accounts, but also for understanding how Bosch’s security posture has evolved over time. By comparing system0 (the active OS) with system1 (the older OS), there’s a clear shift toward hardening.

For example, it appears that earlier firmware allowed root and developer SSH access, while the newer firmware has removed or disabled these capabilities entirely.

Note: It is also possible that the configuration in system1 reflects a test or pre-production environment rather than an earlier production security model.

Shadow File Comparison

Looking more closely at the /etc/shadow files:

Key observations:

• In system0 (active OS):
  • The root account is set to *, meaning password-based login is disable
  • All other accounts are similarly disabled
  • There are no usable password hashes present
• In system1 (older OS):
  • The root account has a valid SHA-512 crypt hash, indicating a working password
  • The last password change date (16602) corresponds to June 9, 2015, which may reflect a factory default
  • All other accounts remain disabled, similar to system0

This leads to a few important takeaways:

• The older system allowed interactive root login, while the newer one explicitly prevents it
• The hash in system1, while using a relatively strong algorithm (SHA-512 crypt), is still offline crackable given enough time
• If that hash were cracked, there’s a reasonable chance the plaintext password could be reused across devices running the same firmware, since factory images are often identical

Overall, system0 shows a clear move toward disabling password based access entirely, while system1 looks more like an engineering or recovery environment with retained credentials.

Passwd File Comparison

Moving on to /etc/passwd files, the differences are just as telling.

Notable changes:

• In system0:
  • root uses /bin/false, effectively disabling interactive login
  • Most accounts are also set to /bin/false
  • Developer SSH accounts have been removed entirely
• In system1:
  • root uses /bin/sh, allowing interactive login
  • Several developer-oriented accounts exist (ssh_dev, ssh_sa, ssh_sup), all with shell access

This reinforces the idea that the older system supported engineering access, while the newer one has been deliberately locked down.

Note: None of the accounts in these files had home directories in /home/ for either the system0 or system1 partitions.

Accounts found

Beyond the security differences, the account list itself was interesting.

There’s a mix of standard Linux roles and more specialised accounts:

• Typical system accounts:
  • root
  • Service daemons like rda, ctm, cdl, cls
  • tss, likely tied to the Infineon TPM
• Platform and “tenant-style” accounts:
  • fb, dtna, zonar, bluedot
  • 32 generic slots: sdk01–sdk32, all mapped to /data/signed/home/

I already knew that “DTNA” stands for Daimler Trucks North America, but the others weren’t immediately clear. A bit of digging showed that these correspond to 3rd party fleet management and telematics providers:

• fb → FleetBoard
• zonar → Zonar Systems
• bluedot → BlueDot
• dtna → Daimler Trucks North America

Note: The account names were searched and the following companies came up: fb - FleetBoard, dtna - Daimler Trucks North America, zonar and bluedot.

A Different Model Than Passenger Vehicles

This is where things started to diverge from what I’d seen in passenger vehicle Tboxes.

The presence of multiple third-party accounts strongly suggests that this Tbox is designed to integrate with external fleet management providers and appears to support a multi-tenant model.

In other words, the device may be structured to allow different services (or different companies) to operate within isolated account contexts on the same hardware.

I found that to be a pretty significant architectural difference. It hints that the Tbox isn’t just a passive data collector, but potentially a shared platform for multiple telematics and fleet services.

As I dug further into the filesystem, this started to look less like a simple embedded device and more like a service oriented system with clearly defined tenants.

What are “Tenant” Accounts

The term tenant comes from cloud architecture, where a single platform serves multiple independent parties while keeping them logically isolated.

AWS is a good example, the infrastructure (data centres, servers, networking) is owned by Amazon, but customers are given isolated environments to run their own workloads alongside others on the same physical hardware.

What I’m seeing on the Tbox feels similar to that, where Daimler owns the underlying platform and other companies build and sell their telematics services on top of it. This would be a huge benefit to those 3rd party companies as they could tie directly into the existing hardware rather than have to design, build, and retrofit equipment to existing trucks.

For example, a trucking company might choose between different service providers (e.g. “Zonar” or “BlueDot”). Whichever provider they subscribe to could be enabled on the Tbox under its corresponding tenant account.

Each tenant would presumably have an agreement with DTNA to deploy code onto the device. The /data/signed/home/ path strongly suggests that tenant code is signed and controlled, which adds a layer of trust and integrity to the system.

In addition to the named tenants, there are also 32 generic “sdkXX” accounts. This suggests that DTNA has reserved capacity for future expansion, either for onboarding new partners or supporting additional applications. Each account could be granted a specific set of permissions (e.g. CAN bus access, GPS data, modem connectivity, or file transfer capabilities), and importantly, each tenant could be managed independently. For example, removing “Zonar” wouldn’t impact “BlueDot”.

Tenant accounts on the Tbox

Note: OSGi is a Java framework that splits an application into small modules called “bundles” which can be installed, updated, or removed without restarting the JVM.

What tenants have code on our Tbox?

To see which tenants are actually in use, I went digging through the /data/signed/home/ directory.

  $ ls -al data/signed/home/
  ...
  drwxr-xr-x 2 11001 11001 384 Jan  9  2022 dtna
  drwxr-xr-x 2 root  root  160 Jan  1  2016 udplogger

At first glance, only one tenant account appears to be active on this device, dtna.

The udplogger directory exists but is empty, and interestingly, doesn’t correspond to a user account in /etc/passwd. In contrast, dtna does map directly to a valid system account.

Looking inside the dtna directory:

  $ ls -al data/signed/home/dtna/
  ...
  -rw-r--r-- 1 11001 11001 17229 Jan  9  2022 DTNAAnalytics.config
  -rw-r--r-- 1 11001 11001  2048 Dec 28  2019 dtna.db
  -rw-r--r-- 1 11001 11001     0 Dec 10  2021 PltSciAnalytics.config

  $ head DTNAAnalytics.config
  "uuid": "StandardSafetyEventViewer_Detroit_v2",
  ...
  "name": "destination",
  "value": "dtna"
  ...

This was a great find. For the first time, I could look directly at how at least one tenant’s software is configured on the device.

The presence of structured configuration files (and even a small database) suggests that tenant functionality isn’t just conceptual, it’s actively deployed and driven by configuration on the Tbox itself.

Naturally, my next step was to take a closer look at DTNAAnalytics.config to understand what kind of data is being collected, how it’s processed, and where it’s being sent.

The DTNAAnalytics.config file

Opening up DTNAAnalytics.config, I found what looks like a collection of reporting parameters and telemetry settings for the truck.

Scrolling through it, a few interesting things jumped out. For example:

• The config includes a unique identifier (uuid) of StandardSafetyEventViewer_Detroit_v2 (this comes into play in the next section)

  "uuid": "StandardSafetyEventViewer_Detroit_v2",

As I kept going through config file, there were 3 separate “module” entries (each designated by the keyword “service”), two of which were named “summary” and the last one “event”. The two “summary” modules appear to contain the engine-on and engine-off profiles and the “event” module contained trigger events for capturing safety events.

The file contents can be seen here, but a snippet of some relevant bits is below:

  "service": "summary",           <-- The first entry
  ...
  {
      "name": "trigger",
      "value": "VehicleState<2",
      "triggername": "keyOn"
  }
  ...

  "service": "summary",           <-- The second entry
  ...
  {
      "name": "trigger",
      "value": "VehicleState=2",
      "triggername": "keyOff"
  }
  ...
  "service": "event",
  ...
  {
      "name": "trigger",
      "value": "ExtBrkStat_Rq_VRDU=4",
      "triggername": "Forward Collision Warning"
  },

Based on what I saw, the config seems to be setting up the following:

• The truck reports its GPS position to Daimler (dtna) every 5 minutes, 24/7, regardless of whether the engine is on or off
• Safety events trigger the capture of 31 second data snapshots (15 seconds before and 16 seconds after the event)
• These safety events appear to include:
  • Forward Collision Warning events
  • Electronic Stability Control events
  • Roll Stability Control events
  • Collision Mitigation Braking events
  • Hands Off The Wheel Alert 30s events
  • Hands Off The Wheel Alert 60s events
  • …and others…
• The destination for this data is set to “dtna” (though exactly how this value is resolved or routed is still unclear)

At this point, I started to get a much clearer picture of how the Tbox is actually using the data it collects. More importantly, it began linking the software artefacts back to the physical components observed during the teardown in Part 1.

For example:

• The presence of vehicle event data strongly suggests integration with the truck’s CAN bus, which lines up with the CAN transceiver chips identified on the PCB
• The use of GPS telemetry confirms that the onboard GNSS hardware is actively used, not just present

This is where the analysis starts to come together. The configuration isn’t just abstract data, it directly reflects how the hardware and software interact in the real system.

The next logical step was to determine how this configuration file is actually used by the system. Specifically, I wanted to know whether it’s referenced by any running services or applications, and how it fits into the execution flow of the Tbox.

Following the config breadcrumbs

Although I had the configuration file, I wanted to go a step further and show how it was being used by the system.

Since the DTNAAnalytics.config file contained the uuid of StandardSafetyEventViewer_Detroit_v2, I searched for that string across the filesystem. That led me to a set of files in a directory that appears to store outgoing MQTT messages:

  ./data/signed/fbs/storage/mqtt-client-ctp-3530022915-outgoing-messages/

  user@host:/data/signed/fbs/storage/mqtt-client-ctp-3530022915-outgoing-messages$ ls -al
  total 620
  drwxr-xr-x 2 root root 9952 Jan  1  2016 .
  drwxr-xr-x 5 root root 6592 Jan  1  2016 ..
  -rw-r--r-- 1 root root  108 Feb 17  2024 33616n
  -rw-r--r-- 1 root root  128 Feb 17  2024 33617n
  ...
  -rw-r--r-- 1 root root 2725 Jan  1  2016 33766n
  -rw-r--r-- 1 root root  271 Jan  1  2016 33767n
  -rw-r--r-- 1 root root  362 Jan  1  2016 33768h

At a glance, these files appear to contain data being transmitted back to the backend (likely FleetBoard/DTNA infrastructure) via MQTT. Some fields are visible in plaintext, but most of the payload appears to be encoded or serialised.

Note: MQTT is a lightweight messaging protocol designed for low-bandwidth, unreliable networks, which makes it well suited to vehicle telematics. It’s anticipated that the Tbox would publish telemetry (GPS, speed, fault codes) to a broker (backend server) over the cellular link, keeping data flowing efficiently even on patchy mobile connections.

For example:

• File 33616n contains a reference to our UUID from the DTNAAnalytics.config file:

    === 33616n ===
    00000000: 326a 0007 2f74 702f 4147 5783 5042 ffff  2j../tp/AGW.PB..
    00000010: ffff 7000 0001 8db2 872b 54e0 108d d59c  ..p......+T.....
    00000020: 94db 311a 2f08 c0b1 9f05 1005 2226 0a24  ..1./......."&.$
    00000030: 5374 616e 6461 7264 5361 6665 7479 4576  StandardSafetyEv
    00000040: 656e 7456 6965 7765 725f 4465 7472 6f69  entViewer_Detroi
    00000050: 745f 7632 2206 0802 100b 182f 420e 0a0a  t_v2"....../B...
    00000060: 3335 3330 3032 3239 3135 1801            3530022915..
  

• File 33766n appears to contain more general system telemetry, including the VIN and what looks like vehicle metrics:

    cat data/signed/fbs/storage/mqtt-client-ctp-3530022915-outgoing-messages/33766n 
    2�/tp/AGW��B����pQ����͒ן*�"�
    �
    'Health_Monitoring_Default_Cyclic_Config#
    VehicleDistance��ן*�	408975735
    ...
    EngineHours��ן*20139300&
    CPUCurrentClassification80�͒ן*�0'
    ...
    PUCurrentClassification100�͒ן*�1!
    FlashClassification20�͒ן*�0"
    ...
    ...
    MemoryAvailableClassification10�͒ן*�0&
    �CPUAverageClassification10�͒ן*�0&
    ...
    JavaHeapFreeMemClassification40�͒ן*�0+
    ,,,
    SoftwareVersion 169.413.907"
    VIN3AKJHPDVXLSLM6780"
    ...
  

This was a key moment in the analysis. I now had a clear link between configuration → runtime artefacts → outbound data, showing that:

• The DTNAAnalytics.config file is not just static, it directly influences what gets transmitted
• The Tbox is actively collecting and packaging vehicle telemetry, system health metrics, and identifiers
• Data is being prepared for transmission using a structured (likely binary) format

Following It Into the Code

Some of these search hits also led me to two Java archive files in the system0 partition:

  /opt/linux-armhf/jars/dtna/
    ├── DTNAAnalytics.jar
    └── DTNAConfigurator.jar

After unpacking and skimming the class listings:

• DTNAAnalytics.jar
  • Appears responsible for processing vehicle signals and telemetry
  • Includes references to “pltsci” (likely Platform Science, a fleet software provider)
  • Contains references to Google Protocol Buffers (protobuf), suggesting the system uses a binary serialisation format rather than JSON or XML
• DTNAConfigurator.jar
  • Appears to handle configuration management rather than data collection

At this point, it was clear that there’s a much deeper rabbit hole here. With enough time, the next step would be to fully reverse engineer the DTNA application, trace its execution flow, and understand exactly how data moves from hardware inputs (CAN, GPS) through to outbound telemetry.

That said, this is a time intensive process, so for now I made note of these findings and left that path for future work. Instead, I shifted focus again, this time looking for something more immediately actionable: credentials.

WiFi Access Point

When searching for credentials, I typically start with a standard set of keywords, such as pass, passphrase, secret, and keys. These tend to surface anything from authentication material to configuration files that may contain sensitive information.

This approach paid off here, leading me to two different versions of hostapd.conf (Wi‑Fi configuration files). Once again, this tied the filesystem back to physical hardware (the WiFi/Bluetooth chipset identified in Part 1). More importantly, it suggested that the Tbox is capable of acting as a wireless access point.

The first configuration was located in the data_unsigned partition at

• ./topas/areanetwork/hostapd/hostapd.conf

The passphrase appears random and relatively long, so it would likely hold up well against brute-force cracking attempts Of course, that protection doesn’t help much when the password is stored in plaintext on the device.

The second configuration was found in both system0 and system1:

• ./home/topas/areanetwork/hostapd/hostapd.conf

This version contains a significantly weaker passphrase. However, it may no longer be in use. Both system0 and system1 contain symlinks at /etc/hostapd/hostapd.conf that point to the stronger configuration in data_unsigned, suggesting the weaker configuration might be a leftover from an earlier setup.

It’s not immediately clear how or when WiFi is intended to be used on these devices. Still, having valid credentials is valuable, it provides a potential entry point if WiFi can be enabled, and it reveals useful patterns around password generation and security hardening over time.

Another open question is whether this password is unique per vehicle or shared across the fleet. If it’s the latter, this could represent a much broader risk.

At the same time, it’s not obvious that this WiFi interface is meant for end users. The SSID “TCU” is generic and doesn’t suggest a driver facing feature. It seems more likely that this interface is intended for dealer diagnostics, provisioning, or internal DTNA workflows.

Note: During testing in Part 2, I wasn’t able to observe the Tbox broadcasting WiFi during boot. It may only be enabled under specific conditions (e.g. service mode, dealer tooling, or certain runtime states).

With that possibility in mind, this finding represents a potential future access vector if those conditions can be replicated.

From there, I continued working through the results from my earlier credential keyword searches. This time, the trail led me to the cellular modem configuration.

Cellular Modem

Searching for secret turned up configuration files related to the u‑blox cellular modem, another link between software artefacts and physical hardware on the board.

From these files, it’s clear that the Tbox establishes connectivity using a PPP (Point‑to‑Point Protocol) connection. Several files under data_unsigned/ppp/ contain credentials in plaintext:

  ./data_unsigned/ppp$ ls -al
  total 12
  ...
  -rw-r--r-- 1 root root  10 Feb 17  2024 chap-secrets
  drwxr-xr-x 2 root root 232 Feb 17  2024 chats
  lrwxrwxrwx 1 root root  17 Jan  1  2016 ip-down -> /etc/ppp2/ip-down
  lrwxrwxrwx 1 root root  15 Jan  1  2016 ip-up -> /etc/ppp2/ip-up
  -rw-r--r-- 1 root root  10 Feb 17  2024 pap-secrets
  drwxr-xr-x 2 root root 296 Feb 17  2024 peers
  -rw-r--r-- 1 root root  38 Feb 17  2024 resolv.conf

  ./data_unsigned/ppp$ cat chap-secrets 
  fb * fb *

  ./data_unsigned/ppp$ cat pap-secrets 
  fb * fb *

  ./data_unsigned/ppp$ cat peers/ip-connect 
  connect '/bin/sh /etc/chatscripts/dial_in.sh apn1.dtna.com fb fb'
  name fb

  ./data_unsigned/ppp$ cat resolv.conf 
  nameserver 8.8.8.8
  nameserver 8.8.4.4

  $ cat data_unsigned/ppp/peers/ip-connect 
  connect '/bin/sh /etc/chatscripts/dial_in.sh apn1.dtna.com fb fb'
  name fb

The credentials are simply fb / fb, which ties back to FleetBoard. This isn’t a user facing credential, but rather a service level authentication used to connect to the backend via the cellular network.

The credentials are fb / fb, which also ties back to FleetBoard. So this isn’t a “user password” in the traditional sense, it is used by FleetBoard to authenticate to their cellular APN.

Other notable details:

• Name of APN: apn1.dtna.com (Daimler Trucks North America’s private cellular network).
• DNS servers: 8.8.8.8 and 8.8.4.4 (Google’s public DNS).

While none of this immediately exposes a direct attack vector, it does add important context:

• It confirms how the Tbox communicates externally
• It reinforces the FleetBoard integration
• It shows that some credentials are stored in plaintext, even if scoped to infrastructure rather than user access

At this point, I had built up a fairly complete picture of how the Tbox collects and transmits data. However, one thing stood out: despite all of this telemetry, I hadn’t yet found any clear, verifiable GPS data stored locally.

Some of the earlier findings started to hint at why that might be, which led me to form a theory I wanted to explore next.

GPS Info - Or the lack thereof

Despite everything I’d examined so far, I hadn’t come across any clear GPS log data.

I also performed targeted searches for GPS related artefacts, including anything resembling traditional NMEA logs, but came up empty.

That was pretty disappointing. Being able to reconstruct a vehicle’s movements is always one of the more interesting outcomes of this kind of analysis.

What makes this more puzzling is that I can be relatively certain that GPS data is present in the system:

• The hardware teardown confirmed a GPS chipset on the board
• The configuration files show GPS data is actively used and transmitted

So the data is almost certainly there, it’s just not showing up in an obvious or easily searchable form. Based on earlier findings, I have a couple of working theories as to why:

• The data is encoded or serialised. If GPS data is packaged into a binary format, it wouldn’t appear in plaintext logs or MQTT message dumps. The earlier discovery of Protocol Buffers (protobuf) references in the JAR files supports this theory.
• The data is stored in encrypted files. Some portions of the filesystem appear to contain encrypted content. It’s possible that location history is stored there, out of reach without further processing.

Whether it’s one of these reasons or something else entirely, the GPS data has remained elusive so far.

To continue digging, I have a couple of clear next steps:

• Reverse engineer the JAR files to trace how telemetry (including GPS) is handled
• Investigate whether the encrypted files can be decrypted or otherwise analysed

Which leads me into…

A Quick Tour of What Else Is on the Chip

There’s far more on these partitions than I can reasonably cover in a single post. That said, a few directories stood out as particularly interesting and worth calling out. Each of these is a strong candidate for a future deep dive:

The encrypted vault is an especially interesting target for follow up work, as is reversing the .jar and .bin files. Either path could provide deeper insights into:

• How data (GPS, events, CAN traffic, etc.) is stored and transformed
• How telemetry is packaged and transmitted off the device
• How the various applications and services on the Tbox actually operate

Those are exactly the areas I’d want to explore next, particularly from a vulnerability research perspective.

But for now, I’ll leave those threads here and call this one done.

Conclusion

When I started this series, the question I wanted to answer was fairly open:

• Do telematics modules in heavy transport trucks operate the same way as those in passenger cars?

After three parts, my answer is:

• Yes, but at a different scale and with a different commercial model behind them.

One of the most interesting takeaways is that, at a hardware level, these Tboxes aren’t drastically different from what you’d find in a passenger vehicle. Bosch hasn’t reinvented the wheel here. However, the way this embedded Linux platform is used in a commercial trucking context is where things really diverge.

In particular, the multi-tenant model (FleetBoard, Zonar, BlueDot, etc.) paints a clear picture of a platform designed to host code from multiple commercial providers on a single device. Rather than acting as a tightly controlled, OEM-only system, this Tbox feels more like a shared services platform, built from the ground up to support multiple stakeholders.

Looking back, getting to this point wasn’t straightforward.

Starting with the initial teardown, the lack of accessible UART or JTAG interfaces forced me down the path of a chip-off NAND extraction. From there, I had to process and reconstruct the raw memory before I could even begin analysing the filesystem.

And only then did the real work start with this post, trying to piece together how the system actually operates.

Even with all that effort, there are still plenty of unanswered questions and unexplored paths. Given more time, I’d focus on:

• Reverse engineering the embedded software (JAR files) to better understand application logic, data handling, and potential vulnerabilities
• Digging deeper into the TPM implementation With the goal of accessing the encrypted vault
• Analysing the older Linux kernel versions to identify any known vulnerabilities that may apply

There’s still a lot left to dig into…

But for now, I’m wrapping this series with:

• A working method for extracting and mounting firmware
• A reasonable map of the filesystem and components
• A set of promising avenues for deeper investigation

If you’ve made it through all three parts—thanks for reading along!

As always, if you’ve worked on similar systems or want to compare notes, feel free to reach out. I’d love to compare notes.

See you in the next post.

Disclaimer

This analysis is based on our professional experience and reflects our best interpretation at the time of examination.

Anyone choosing to replicate these procedures does so at their own risk.

Disassembling a vehicle (or equipment) and interacting directly with its electronic components carries an inherent risk of damage to the equipment. Fortify Labs does not guarantee that any procedure described will be free of risk, nor do we accept responsibility for any resulting damage.