Can you protect a transmission controller’s firmware while keeping it usable for programming and diagnostics? In this DQ200 project, we blocked the tested bench access path and prevented useful firmware extraction through the tested OBD read method. OBD writing remained available, and the client confirmed that VCDS diagnostics worked correctly.
This case study explains how ReverseEngineer.net approached TCU read protection for a specific DQ200 software version, how the results were checked, and what businesses should establish before commissioning a similar solution.
Client identity, original files, software identifiers and implementation details have been omitted to protect confidentiality.
The brief: protect DQ200 firmware and preserve the working process
The project involved a VAG DQ200 PQ transmission control unit built around an Infineon TriCore TC1766 microcontroller. The controller was used in a professional bench test application. The work was completed remotely: we analysed the supplied firmware and communication recordings, prepared controlled modifications, and reviewed results from testing performed on the client’s hardware.
The requirements developed into a clear set of acceptance criteria:
- Prevent firmware extraction through the specified bench programming workflow.
- Block the identified OBD read method while retaining OBD programming.
- Keep the diagnostic functions needed for the application working.
- Leave EEPROM data unchanged.
Blocking both reading and writing through the tested bench path was acceptable for this application. Keeping OBD writing available was a separate requirement because the client needed to continue making calibration changes.
Why bench read protection and OBD read protection needed separate work
The first protection stage stopped the tested PCMflash bench workflow. Subsequent testing showed that the Kess OBD workflow could still read the application. That observation established the next task: identify and restrict the remaining read path while preserving the functions the client needed.
The connection label alone did not define the protection requirement. We needed to establish which software path handled each operation and what happened when the tool requested firmware data.
For a new ECU or TCU project, this means recording the exact controller version, programmer, protocol and connection method. A successful test with one combination establishes a result for that combination; coverage of another requires its own validation.
Our approach: firmware analysis, CAN recordings and controlled changes
Establish a verified baseline
We preserved the original firmware, recorded file hashes and checked the memory regions relevant to the work. EEPROM remained separate. This gave us a reliable baseline for comparing each revision and confirming that the delivered changes stayed within scope.
Identify the actual read and programming paths
Firmware reverse engineering was combined with CAN bus protocol analysis. Comparing the binary’s behaviour with recorded tool requests helped us distinguish firmware extraction from programming and routine diagnostics.
The objective was selective behaviour: prevent the specified read operation while keeping the required maintenance workflow available. Disabling an entire communication protocol would not have met the diagnostic requirement.
Check the modified file and test the result
We checked the changed regions, relevant checksums and targeted control flow before delivery. Hardware testing then addressed three separate questions: could the tool obtain usable firmware, could the client still write the intended file, and did the required diagnostics remain functional?
This work draws on our ECU reverse engineering services and embedded firmware analysis, applied to a defined protection requirement.
Results from the DQ200 protection project
| Function tested | Outcome | Verification |
|---|---|---|
| PCMflash bench reading and writing | Blocked through the tested path | Client hardware tests and supplied communication capture |
| Kess OBD reading over CAN | No usable application firmware recovered in the tested readback | CAN recording and returned-file analysis |
| Kess OBD writing | Retained | Successful verification response in the supplied write capture; client confirmed working programming |
| VCDS diagnostics | Client confirmed correct operation | Client functional testing |
| EEPROM | Unchanged | Excluded from the modifications |
The practical result was a protected firmware workflow that still supported the client’s calibration and diagnostic needs. These findings describe the tested configuration. They do not establish protection against every programmer or hardware access method.
A completed read did not mean usable firmware was recovered
One important finding concerned the programmer’s read result. Kess completed a read operation and saved a file, but analysis showed that the returned application data was not a valid copy of the firmware. The CAN recording also showed that the targeted read requests were being refused.
That distinction matters when evaluating firmware protection. A progress bar, a success message or an output file is only part of the evidence. The file’s contents must be checked to determine whether the protected software was actually recovered.
In this project, the unusable readback did not establish corruption inside the TCU. The client subsequently confirmed correct writing and diagnostic operation. Readout validation and functional testing answered different questions, and both were needed.
What this means for your ECU or TCU protection project
Custom firmware can represent substantial development work for a tuning business, specialist workshop or diagnostic equipment developer. Read protection needs to account for both the software you want to protect and the operations your business must continue performing.
Before implementation, we define the target hardware and software, the access methods to be evaluated, the functions to preserve, and the evidence required for acceptance. This makes the proposed work specific enough to test and quote.
For a project that retains programming, future maintenance files must also retain the protection changes. Writing an unprotected application can remove protection implemented in that application. The update process therefore belongs in the project scope from the beginning.
We assess similar ECU and TCU firmware protection requests individually. The DQ200 result provides a completed example of our approach; another controller or software revision needs its own feasibility assessment.
Frequently asked questions
Can OBD reading be blocked while OBD writing stays enabled?
Yes, that was the reported working outcome for the Kess workflow in this DQ200 project. The readback and CAN recording supported the read-protection result. Whether the same separation is possible on another controller depends on its firmware and the required programming method.
Does TCU read protection disable diagnostics?
The client confirmed working VCDS diagnostics with the completed modification. Preserving diagnostics was an explicit requirement. A new project should identify the diagnostic functions that matter and include them in functional testing.
Will this work on every DQ200 or with every flashing tool?
Coverage is specific to the software version and tested access paths. Other DQ200 variants, programmers and lower-level access methods require separate evaluation. We agree the intended coverage before implementation.
Can firmware protection work be completed remotely?
This project was completed remotely using supplied files, communication recordings and client-side hardware tests. A similar arrangement can be assessed when the necessary baseline files and test capability are available.
Discuss your firmware protection requirements
If you need to protect proprietary ECU or TCU software while retaining a practical programming and diagnostic workflow, contact ReverseEngineer.net about your firmware protection project.
For an initial assessment, include:
- The controller family and hardware/software references.
- The programmers and connection methods you need assessed.
- The read operations you want restricted.
- The writing, diagnostics and service functions that must remain available.
- Whether you have an original backup, communication logs and hardware available for testing.
We can then define the feasibility work, validation requirements and a project-specific proposal. Pricing follows the agreed controller versions, access methods and deliverables.
Let's Work Together
Working on an ECU, a firmware image, or a board? Send what you have.