406oc.co.uk

Hi, does anyone know if a bosch ECU can be reprogrammed to just ignore particular fault codes, if so how easy is this (I am an IT engineer and programmer so the technical side would be no prob if it's possible)??

You'd have to extract the ROM image with a reader, modify the assembler & burn it back to a fresh EEPROM.
Not something I'd fancy taking on!

That's what I thought would be involved, that's not an issue as such, not much difference to upgrading firmware on anything, (I assume you can take a copy to keep as a backup if the modified one goes wrong )

More wondering if the reprogramming to completely ignore certain sensors or at least not mind if they aren't working (that don't effect the cars running of course) is actually possible.

Well you'd need an understanding of the original programming, modifying that code could have disastrous consequences!
I would say it's not the sort of thing you should experiment with, imagine tweaking settings and suddenly the fuel cuts out while you're overtaking!

Edit: I should add that's just my opinion!

If you had anywhere near the skill to do it, you wouldn't be asking such questions.

Disassembling a complex system by hand is not at all easy, even if you have access to the multi-million pound facilities required to read the programming (I'm presuming it's going to be stored execute-only on-chip like most microcontrollers), which is in EEPROM, not NVRAM unlike say the timings/mappings. Maybe you could figure out a way to inject something like a buffer overflow over the CAN/VAN bus and use it to dump the code, I don't know but I wouldn't bother trying. Then you'd need to find a compatible microcontroller (including the minor point of pin compatibility), blow the image to it, then test the car in every conceivable condition to make sure the programming still works and can interface with things like the ABS relays (which are within the ECU unit itself)

Without the source code you'll be looking at months to years of work to disassemble the programming. That's providing of course you already know the target processor (hint: it's not an x86) like the back of your hand.

But you're an IT engineer and programmer, so that's no problem right?

Just fix the sensor.

mjb wrote:If you had anywhere near the skill to do it, you wouldn't be asking such questions.

Disassembling a complex system by hand is not at all easy, even if you have access to the multi-million pound facilities required to read the programming (I'm presuming it's going to be stored execute-only on-chip like most microcontrollers), which is in EEPROM, not NVRAM unlike say the timings/mappings. Maybe you could figure out a way to inject something like a buffer overflow over the CAN/VAN bus and use it to dump the code, I don't know but I wouldn't bother trying. Then you'd need to find a compatible microcontroller (including the minor point of pin compatibility), blow the image to it, then test the car in every conceivable condition to make sure the programming still works and can interface with things like the ABS relays (which are within the ECU unit itself)

Without the source code you'll be looking at months to years of work to disassemble the programming. That's providing of course you already know the target processor (hint: it's not an x86) like the back of your hand.

But you're an IT engineer and programmer, so that's no problem right?

Just fix the sensor.

Great answer mjb

mjb wrote: Just fix the sensor.

Hmmm, done that one to death, new FAP, new sensors in FAP, fluid tank filled up, pressure differential sensor replaced, wiring checked, still running in 'safe mode' due to faults with this stupid system that I couldn't care less about (not much of a greeny), now they are telling me the Particulate ECU itself is giving errors (I didn't even know it had a separate one, if it does that is). Spent a fortune already and really wishing I'd bought the 2L as I can't even sell it until it's fixed (or at least appears to be)!

Reading / writing the chip isn't a problem, lots if standard equipment available for doing that that plugs between the ECU and connector, the EEPROM chip is a Electrically Erasable Programmable Read-Only Memory chip like you get in a PDA, not a ROM chip of ye oldy days and can be read and, most importantly, rewritten (presumably this is how they do 'software upgrades' to try and fix everything).

the 'Multi million pound facilities' required to read the data is a hex reader, free download from the internet, what I am wondering is if there are any programs available that can interpret this into a higher level language, presumably they must use something along these lines for remapping them.

If you want to ignore the sensor readings, would you not be better off bypassing them and supplying the voltage / resistance for a no fault reading to the leads rather than hacking the brain? God help the poor car!

teamster1975 wrote:If you want to ignore the sensor readings, would you not be better off bypassing them and supplying the voltage / resistance for a no fault reading to the leads rather than hacking the brain? God help the poor car!

That would be ideal, but most of the sensors are new and if what my diesel special tells me is true the problem is with the brain that tells the main brain about the particle filter readings rather than the sensors themselves (could be they just haven't got a clue what's up with it).

I has hoping there would be a way someone had used before to just hack the thing and 'turn off' and reliance on certain readings, e.g. some codes trigger a system melt down resulting in safe mode and some don't, I was hoping you could either turn off some sensors completely or at least adjust the ECU's 'reaction' to them and just make them report them without killing my car.

Sorry to butt in but I see an oportunity here for some clever sod to develop a plug in 'tricker' device to fool the FAP ECU.

You'd make a fortune on ebay

The 2.2 is a great machine but sadly dogged with stupid controls.


carry on.......

ParisEngLtd wrote:I has hoping there would be a way someone had used before to just hack the thing and 'turn off' and reliance on certain readings, e.g. some codes trigger a system melt down resulting in safe mode and some don't, I was hoping you could either turn off some sensors completely or at least adjust the ECU's 'reaction' to them and just make them report them without killing my car.

I'm sure no-one has attempted that!
What faults have been flagged?
Problems with the D9 electronics are rather common

Hey Welton, there's an idea! Now if Paris can design & build it we can take a commission!

i have been trying figure out a way round the FAP on the 2.2, but its a nasty bugger, without testing i cant be sure, but you need to fool the ECU into thinking the filter is clean, stays out of regeneration and the elloys fluid level is ok, now i reckon, if you remove the fap filter and weld a pipe in place, keep the differential pressure pipes fitted, along with the EGT sensors, carry out a forced regeneration, top up the elloys fluid, it may think the filter is permenatley clean, but im sure this will only work on a 2.2 thats is in a good known running order, the other option which is more likely to be succesful, remove the fap filter, differential presure sensor and pipework, and egt sensors, remove the wiring harness, replace it with an L3 (EGR+CAT) HDi 110 harness, and ecu, configure the BSi to tell it that it doesnt have FAP and that may just work

ParisEngLtd wrote:Reading / writing the chip isn't a problem, lots if standard equipment available for doing that that plugs between the ECU and connector, the EEPROM chip is a Electrically Erasable Programmable Read-Only Memory chip like you get in a PDA, not a ROM chip of ye oldy days and can be read and, most importantly, rewritten (presumably this is how they do 'software upgrades' to try and fix everything).

sorry, did I not say EEPROM? Oh look, I did. Just because something's in EEPROM doesn't mean it can be simply read and re-written with a JTAG interface. Most microprocessors have facilities to, through software, prevent code storage areas being read or written to via the JTAG programmer. If this is the case (and as I said, it almost certainly will be) you need to figure out how to get the software already running on it to release the locks. With most hardware devices I've seen this takes the form of a cryptographic challenge-response mechanism.

If software upgrades are as simple as you seem to think they are, how come you can't read dumps of firmware from games consoles, mobile phones, etc? Why does it take elaborate hacks in order for people to read the contents of memory/firmware, usually just getting a couple of bytes at a time? Why do consoles need modchips? Why can you still not get a modchip for an xbox 360, only a device to trick the dvd drive into thinking it's playing genuine media? If it "isn't a problem" why can't I "do a 'software upgrade'" to re-flash the BIOS of my 360 with a dodgy one? Answer: because the required code is protected by the processor itself.

the 'Multi million pound facilities' required to read the data is a hex reader, free download from the internet,

Wow, a hex editor can precisely mill the top off a chip and internally re-wire it to bypass the onboard processor's security? sh*t I am behind on the times!

what I am wondering is if there are any programs available that can interpret this into a higher level language, presumably they must use something along these lines for remapping them.

Have you ever heard of programs that can turn assembly into usable C code? They're not common and they're definitely not a silver bullet, but they are incredibly expensive. Getting one for whatever processor's in the ECU will probably be impossible. The best you might find would be a disassembler which is able to identify and label the assembly code using variables like 'aaaaa' and 'aaaab'.


Why don't you do something much much simpler like get a microprocessor with 2 CAN interfaces and get it to proxy everything, fixing up the bad readings?

mjb wrote:Why don't you do something much much simpler like get a microprocessor with 2 CAN interfaces and get it to proxy everything, fixing up the bad readings?

At this rate you'll have him designing a new ecu!

teamster1975 wrote:At this rate you'll have him designing a new ecu!

I was actually pondering that earlier. Would probably be easier than re-programming an existing one