B2B engineering subcontractor
We solve the automotive electronics others hand back
A specialist engineering subcontractor for tuning studios, device manufacturers and OEM suppliers. 15+ years in automotive electronics, across ECU reverse engineering, firmware, hardware and security.
- 15+ years in automotive electronics
- 5 disciplines in-house
- NDA before the first file
Five disciplines in-house
Who actually does the work
BimmerExpert is an independent engineering team that has worked in automotive electronics for more than fifteen years. Five disciplines sit in-house: ECU software reverse engineers, embedded and firmware engineers, electronics hardware engineers, application developers, and automotive and IT security specialists. The person who answers your first message is an engineer from one of those five.
The work runs from reading and understanding an ECU binary to designing the board, writing the firmware and building the application that talks to it. BMW and European marques are where we go deepest, and the electronics and software work is not limited to any one make. Complexity defines the scope, not the badge on the car.
Most of what we build carries somebody else’s name. We work as a subcontractor under NDA, on hardware you own and with documented authorization, and we hand over sources, schematics, toolchain and documentation with the work — you own the result. There is no account manager between you and the engineer writing the firmware.
-
ECU software reverse engineers
Binary analysis, definitions, patched control logic
-
Embedded and firmware engineers
Bootloaders, drivers, RTOS, production firmware builds
-
Electronics hardware engineers
Schematic, PCB layout, bring-up, component-level repair
-
Application developers
Desktop, mobile and back-end device tooling
-
Automotive and IT security specialists
Threat modeling, penetration testing, audit-grade reporting
The interesting problems sit between these five. That is why they are in one team and not in five contracts.
-
15+
Years in automotive electronics
More than fifteen years of continuous work in the field. It is the only experience figure we publish.
-
8
Defined service directions
Eight directions of work, listed in full further down this page. We do not take work outside them.
-
5
Engineering disciplines in-house
Reverse engineering, firmware, electronics hardware, application development and security — staffed inside the team, not passed on to another contractor.
-
1 day
To a first technical reply
A first answer from an engineer, not an automated acknowledgment. Weekday hours; a bricked unit or a car on the ramp is treated as urgent.
Eight service directions
What we build, and what we take apart
Eight directions, one team, one point of contact. Work arrives after something routine failed: an unreadable unit, an orphaned firmware branch, no in-house software team.
BMW and the European marques are where we go deepest, not where we stop: the same methods apply to any make, and to hardware that never went into a vehicle.
-
01
Automotive electronics
Board-level diagnosis and repair for control units nobody else will open.
We work at component level on engine, transmission, body and comfort modules: fault tracing on the bench, power stage and driver replacement, memory and EEPROM recovery, corrected rework and recoating. Where a module is discontinued or beyond repair, we characterize the fault, adapt a donor unit, and align its software state to the vehicle the customer owns.
“The module is dead after water ingress, no comms on the bench, and no shop near us will take an automotive unit at component level.”
-
02
ECU reverse engineering
Understanding of a binary you cannot open, documented well enough to act on.
We recover structure from control-unit software: access by bench and boot-mode reads, JTAG or SWD where the target exposes it, then disassembly, function identification, map and axis location, and analysis of checksum, CVN and integrity routines. The output is a written description with definitions, a patch, or both, verified on the bench before anything goes near a vehicle.
“There is no definition for this unit and the tool does not list it, so can you find the maps in the binary and give us something we can work with?”
-
03
Feature activation and adaptation
Functions the hardware already supports, enabled correctly on units you own.
We research how a control unit holds and defends its own configuration: coding and variant data, option gating, parameter validation, and the integrity routines that decide whether a change is accepted. On that basis we implement what the customer specifies on hardware the customer owns — activating a function the hardware already supports, adapting factory parameters to a stated specification, aligning a donor or replacement unit — and verify the result on the bench before handover.
Customer-owned hardware, written specification, documented authorization, NDA. We confirm ownership before work starts, and we decline requests that do not meet that test.
“The hardware is fitted and the module will not accept the option, the vehicle belongs to our customer, and we need to know what is gating it.”
-
04
ECU firmware development
Production firmware for control units, written, documented, and handed over.
We develop and modify control-unit software: bootloaders and update paths, diagnostic services over UDS, CAN and CAN-FD communication, calibration structures, and measurement access over XCP where the platform supports it. Delivery includes sources, the build environment, the flashing procedure and the documentation, so the customer can maintain the result without us.
“We need the software for our own control unit: CAN-FD, UDS diagnostics, and a bootloader we can update in the field without a dealer tool.”
-
05
Embedded device development
One team from schematic to production firmware, on one contract.
We take a device from requirements to production: MCU and radio selection, schematic capture, PCB layout, board bring-up, drivers, RTOS or bare-metal firmware, and the update path — bootloader, DFU or OTA. Prototype, pilot and production run as separately scoped milestones, each ending in a review and a handover of sources, schematics and documentation.
“We have the hardware concept and no firmware team, so can you take it from schematic through to a production build we can certify?”
-
06
Application development
The software layer that makes your hardware usable, configurable, and serviceable.
We build the software around a device: desktop and mobile applications, configuration and diagnostic tools, end-of-line and service utilities, and the back end that stores and moves the data. Transport is whatever the device speaks — USB, BLE, CAN, Ethernet or a proprietary protocol — and the protocol specification is written down as a deliverable rather than held in one engineer’s head.
“Our device works, but the customer needs a configuration app, a way to pull logs off it, and something our service technicians can actually use.”
-
07
Hardware and software systems
Several units, one architecture, one supplier accountable for the whole system.
When the deliverable is more than one device we design the system: node responsibilities, bus architecture across CAN, CAN-FD, LIN, RS-485 or Ethernet, wiring and connectors, power budget, and the software that runs across all of it. That includes the parts around the product — test benches, end-of-line fixtures, production and service tooling — and that is usually where a multi-vendor project comes apart.
“We need the test bench and the control system that drives it, not just one board, and we need one company answerable for the whole thing.”
-
08
Automotive and IT security
Independent evidence of how a system fails, in a form auditors accept.
We assess automotive and embedded targets independently of whoever built them: threat analysis and risk assessment, ECU and bus-level penetration testing, CAN and UDS fuzzing, firmware and binary review, secure boot and key handling review, debug interface exposure, and hardware attack surface. The deliverable is structured for a process rather than for a headline: scope and rules of engagement, method and tooling, findings with severity, reproduction steps, evidence, remediation guidance and a retest.
Security work runs against written rules of engagement, on systems the customer owns or is documented as authorized to test. Scope is agreed before any hardware is powered.
“Our OEM customer wants an independent penetration test of this ECU and a report we can put into our evidence package.”
Send the unit, the read, or the brief. You get an engineering assessment first — whether it is solvable, by what route, and what it costs — before anyone commits to the work.
Work is performed on customer-owned hardware, with documented authorization, under NDA. Some requests we decline, and we say so on the first reply.
Protocols, architectures, toolchains
From bus traffic to production firmware
Five in-house disciplines, one bench, one contract. The hard problems sit on the seams between them, which is where we work.
-
Vehicle systems and protocols
- CAN, CAN FD, LIN and K-Line: tracing, decoding, message-level reverse engineering
- FlexRay, automotive Ethernet and DoIP
- UDS (ISO 14229), KWP2000 and OBD-II diagnostic services
- XCP and CCP calibration protocols, measurement and data logging
- Powertrain, transmission, chassis, body and gateway control units
- Bench and boot-mode access: bench harnesses, pinout identification, BDM, JTAG and SWD
- Residual-bus simulation and hardware-in-the-loop rigs for repeatable testing
- Coding and variant-data structures, including module-replacement cases
-
ECU software and reverse engineering
- Firmware extraction and binary analysis: disassembly, function identification, control-flow recovery
- Map and calibration structure recovery, A2L and definition-file construction
- Checksum, CVN and integrity-routine analysis and correction
- Bootloader work, flash-driver development, recovery of non-responding units
- Corrupted-flash restoration and donor-unit adaptation, on customer-owned hardware
- Protection and constraint routines: analysis, and adaptation on units the customer owns
- Architecture families: Infineon TriCore, Renesas RH850, NXP MPC5xxx PowerPC, ARM Cortex-M and Cortex-R
- Bench verification and logging before anything is written to a vehicle
-
Hardware, firmware and applications
- Schematic capture, multilayer PCB layout, EMC-aware design and design review
- Component and MCU selection, obsolescence handling, redesign and porting
- Prototype assembly, hardware bring-up, board-level fault finding
- Bare-metal and RTOS firmware, device drivers, bootloaders, OTA update
- Interfaces: CAN, CAN FD, LIN, RS-485, SPI, I2C, USB, BLE, Wi-Fi, cellular
- Applications and back ends: Windows, Linux, Android, service APIs, telemetry
- Test fixtures, production programming, end-of-line test
- Handover set: sources, toolchain, build instructions, schematics, BOM, board files
-
Security and research
- Threat modeling and TARA, structured to the vocabulary of ISO/SAE 21434 and UNECE R155
- Static and dynamic binary analysis; protocol, bus and interface fuzzing
- Secure boot, key management and secure-flashing review
- Debug and diagnostic exposure: JTAG/SWD lockdown, test modes, UDS service access
- Hardware-level work where the scope justifies it: fault injection, glitching, chip-off, direct memory access
- Firmware integrity verification and binary-level investigation of field failures
- Independent review of work delivered by another supplier
- Reporting: scope and rules of engagement, findings with severity, reproduction steps, evidence, remediation, retest
We are not certified against ISO/SAE 21434 or UNECE R155 and do not claim to be. We work to their structure and vocabulary so that what we hand over drops into a program that is.
The exact bench, programmers, analyzers and toolchain we run are shared on request under NDA. We do not publish the list, because a public tooling inventory tells a competitor more than it tells a client.
Anything outside these four groups is investigated before it is promised. We would rather tell you in a day that a job is not ours than find out a month in.
Six steps, one deliverable each
From first message to handover
No work starts without a written scope, and no step ends without something in your hands.
-
Request and triage
Whatever you already have is enough to start: a unit description, a read, a schematic, a failing binary, or two paragraphs about the product. Your message is read by an engineer who could do the work, and you get a yes, a no, or the one question that decides it.
- Time
- First reply within one working day, usually the same day
- You receive
- A written first response naming the route we would take, the one thing still missing, or a clear no
-
Technical analysis
We reproduce the problem on the bench, or on the data you supplied, and establish what is actually blocking it. Where hardware has to travel, the clock starts when it arrives, not when it ships.
- Time
- 1 to 5 working days for a single control unit. 1 to 3 weeks for a product-level assessment
- You receive
- A written assessment: what was reproduced, the access route, the risks, the estimate, and an explicit list of what cannot be known until the next step
-
Scope and proposal
The assessment becomes a fixed scope with named deliverables, milestone dates and a price. Anything that could move that price is written down as an assumption, so a change is visible rather than argued about later.
- Time
- 2 to 5 working days after the assessment
- You receive
- A fixed-scope proposal: deliverables, milestones, price, and the assumptions the price depends on
-
Engineering and verification
Work runs to the milestones in the proposal, with a written update at each one. If the planned route fails, you hear it at that milestone with the alternative already costed, not at the end.
- Time
- Days for a single control unit. 4 to 16 weeks for a hardware and firmware product, against the milestone dates fixed in the proposal
- You receive
- A milestone build, with the test and verification record behind it
-
Delivery and handover
You receive everything needed to build, flash, maintain and extend the work without us. Handover includes a walkthrough with the engineer who did it.
- Time
- 1 to 5 working days after the final milestone
- You receive
- The full package: sources, binaries, build instructions and toolchain, schematics, BOM and board files where hardware is in scope, and the documentation to maintain it
-
Ongoing support
Defects in delivered work are ours to fix, inside a support window agreed in the contract. After it, you can continue on a retainer or take the work in-house, and the handover package is written so that either is possible.
- Time
- A support window of 30 to 90 days after handover, set per project
- You receive
- A named engineering contact, and a written record of every change made during the support window
NDA, ownership and confidentiality
- What the NDA covers
- Signed before technical detail is exchanged, on your paper or ours. It covers files, reads, schematics, binaries and VINs, and the fact that you are a client at all.
- You own the output
- Everything created for your engagement is yours: sources, build environment, schematics, board files, calibrations, definitions and documentation. We keep no license back and reuse nothing for another client.
- Confidentiality about clients
- No client names, no logos, no VINs and no vehicle data anywhere in our marketing. Where the work needs to carry your name rather than ours, it does, and we do not appear in front of your customer.
- Data handling
- We tell you what we hold, where it is held and who has access to it. Material is destroyed on request at the close of a project.
- The legal frame
- We work on hardware the customer owns or is documented as authorized to work on, and security work runs against written rules of engagement. There is work we decline on that basis, and we say so early rather than late.
These are contract terms, not a promise on a web page. Ask for the standard NDA and the scope template before you send anything technical, and check them against your own.
Why us
Six reasons the difficult part lands here
Each of these answers a question we are asked before the first unit is sent. They are written as commitments rather than qualities, so you can hold us to them.
-
The jobs others refuse
Most work reaches us after someone has already said no, so the first thing we produce is an assessment: solvable or not, by what route, at what cost. Where a job is not feasible, or not something we take on, you hear that before you spend anything.
-
Engineers, not resellers
Five disciplines work in-house: ECU software reverse engineering, embedded and firmware engineering, electronics hardware, application development, and automotive and IT security. We do not resell another supplier’s file, and we do not pass your work to a third party you have never met.
-
Confidential by default
An NDA is signed before you send us anything, not after the first problem. Your reads, your customer’s data and your client relationships stay yours: we work behind your name, and we do not appear in front of your customer.
-
Scope first, then price
Every engagement opens with a fixed-scope assessment stating what is feasible, how it will be approached, what you receive and what it costs. You commit to a number and a named deliverable, never to an open count of hours.
-
Direct engineer contact
The engineer who reads your binary is the engineer who answers your message. There is no account manager translating between you and the work, and no ticket queue in front of it.
-
Support after handover
Sources, toolchain, build instructions and documentation are delivered at every milestone, and the resulting IP is yours. When the product needs changing two years from now, the people who built it are still the people who know it.
Before you write
What buyers ask before the first job
How does a first job start, and what does it cost to find out whether it is possible?
You describe the unit, the product or the problem in one message. An engineer replies with an assessment: whether it is solvable, by what route, and what it would take. For a single unit or a defined technical question, that assessment costs nothing. Product development starts with a paid, fixed-scope first phase — feasibility, architecture and a written deliverable at an agreed price and date — before anyone commits to a build.
Do you work on makes other than BMW?
Yes. BMW and the European marques are where we go deepest, and depth on one demanding platform is what makes a broader claim credible. We work on control units from any manufacturer, and a large part of the work is not automotive at all — custom hardware, firmware and applications built for device manufacturers. Name the unit, the MCU or the protocol and we will tell you plainly whether it sits inside our range.
Who owns the result, and how is confidentiality handled?
You own it. Source code, schematics, binaries, toolchain and build instructions are handed over at each milestone, and the result is yours to sell under your own name. We sign an NDA before any material changes hands, and we are content to sign yours rather than insist on our own. We do not approach your customers, we do not resell your files, and every public reference to work we have done is anonymized to the point where it identifies nobody.
Can this be done remotely, or do we have to ship hardware?
Most of it is remote. Reads, binaries, logs, schematics and bus traces travel over the network, and a large share of jobs never needs a physical unit. Hardware ships when the work needs a bench: bootloader and BDM or JTAG access, component-level repair, board bring-up, or hardware-level security testing. We tell you which of the two it is before you pack anything, and we say what has to travel with it — pinout, donor unit, harness, and the original read if you still have one.
How long does work take?
A technical question about a described unit is normally answered within one working day. A bench job on a unit already in our hands is measured in days. Firmware, hardware and security work is measured in weeks, and you get a date together with the scope, not before it. We would rather quote a longer date and hold it than win a job on a number we cannot meet.
What happens if the job turns out to be impossible, or is something you will not take on?
You hear it early and in plain terms, with the reason. When an assessment ends in “this is not recoverable” or “this route does not exist”, that finding is the deliverable and you are not billed for work we did not do. We also decline some requests on principle: emissions-related deletes, odometer changes, and any work on a vehicle or unit the requester does not own or is not authorized to modify. The work we do take on happens on customer-owned hardware, with documented authorization, under NDA.
Private owners and small independent shops: genuinely non-standard individual cases are reviewed one at a time. Routine servicing, consumer tuning and price lists are not what this team does.
Contact
Talk to an engineer
One message is enough to start. Describe the unit, the product or the problem, and an engineer answers with an assessment — not a sales reply.
The fastest route, and the one most of the shops we work with use.
For scopes, NDAs, purchase orders, and anything that has to pass through procurement.
A person reads every message. Telegram and email are both normally answered within one working day. If a car is on the ramp or a unit is down, say so in the first line and it goes to the front of the queue.
What to put in the first message
- The unit or the product. Manufacturer, model, generation, and the MCU or part number if you have it.
- What has already been tried, and by whom. A failed attempt tells us more than a clean description.
- What you need at the end. A working unit, a file, a firmware build, a report, or a finished product.
- Your deadline, and whether a vehicle or a production line is waiting on it.
Do not attach reads, binaries or schematics to a first message. We will tell you where to send them once an NDA is in place.
Send a brief
If you would rather not use chat, this reaches the same engineers. Four lines is enough to get a useful answer.
That did not send
The form failed, not your message. Copy the text and send it to @bimmerexpert on Telegram or to hello@bimmerexpert.com, and we will pick it up from there.
Message received
Your brief is with us. An engineer replies from hello@bimmerexpert.com, normally within one working day — not an automated acknowledgment. If it is urgent, message @bimmerexpert on Telegram and mention your name so we can match the two.