Help with pcb issue

[Ashly90]

Im guessing it would be code protected as it’s from Rothenberger which Is a big name brand. I also would have a clue how to read/write or write my own program. To be honest I’m hoping it’s working as when I turn it on the fans and pump seem to be running unless these are being powered all the time, I’m not sure. I’m going to try and get some Time one evening this week and pull the transistors and then check the voltages at pic as mentioned above. And to buy a working board would involve buying a working machine which is £200/300. I got this for free which is why it would be great to fix as it’s cost me nothing.

 

[narkeleptk]

Sorry, but I disagree. The first thing you'd need to do is figure out WHY the pic went bad -- if it's bad at all. Then, if it's just a matter of replacing the pic, and since this is such a simple board, you could probably spend some time and write your own program to make it work the way you want. Borrowing or buying another board in order to port over the programming would probably be a waste of time and money because the programming is most likely code-protected.

That may be true for somebody with some programming background but for people with no knowledge of how the electronics are working or programming to begin with cloning a MCU is a much simpler task and easily done following simple instruction. This is common practice in my industry for repairing and it is always code protected that doesn't make much difference for many methods of getting in and cloning.

but I do agree, this is only useful if your issue is failure of the mcu. Which is possible because you can see the board has quite a bit of water damage. If the PIC is like other Motorola mcu's then they are not that difficult to be damaged by shorts from corrosion/water. The main message I was trying to portray was what would need to be done if the MCU is dead and if the TS thought it was doable . If not then I see no reason to pursue testing much past figuring out if mcu is bad or not.

 

[hyedenny]

cloning a MCU is a much simpler task and easily done following simple instruction. This is common practice in my industry for repairing and it is always code protected that doesn't make much difference for many methods of getting in and cloning.

That's a trick I'd like to see. Especially from someone who says he "do not know PIC at all..."
So cloning a code-protected microcontroller from a separately obtained secondary board is easier than writing some basic code and flashing a new chip. OK...

 

[Pommie]

I'd would also like to see the procedure for copying a write protected pic.

Mike.

 

[Mickster]

That's a trick I'd like to see.

+1

 

[Nigel Goodwin]

As I seem to remember there was a 'trick' on the antique 16C84, and perhaps the 16F84? (although it was certainly cured by the 16F84a) that allowed you to read a code protected PIC fairly easily. As far as I'm aware, there's been no such bugs since then?.

 

[narkeleptk]

As stated I do not know PIC so your more likely right and its nice that you can post the correct information and/or provide another way the person can try to get it fixed . I felt his situation is very similar to repairs of water damaged modules that I see and repair everyday in my shop and offered a similar strategy he could research on his own. That is, if the conclusion ended up with the mcu being dead which is not a easy situation for someone with out previous experience to deal with and would require a lot more work then one might think.

In my industry the Motorola/Freescale mcu's I deal with and base my similarities on are the 908, 9s12 and mpc chips (quite different in comparison I'm sure). Commonly found inside automotive modules and its very common practice to bypass security in them. It generally consists of hooking 5-10 wires in-circuit and letting the programmer do its job. Usually not all that difficult with simple instructions so I hope you can understand in my reality this is much simpler to suggest someone do then telling them to go write code (assuming they have no knowledge of coding).

Perhaps PIC do not contain these types of backdoors or bypass methods or maybe there is no market in it to bother seeking them. I do not know and do not have the need personally to research. TS does, so I offer my similar experience he can google about and research on his own.

 

[Nigel Goodwin]

As stated I do not know PIC so your more likely right and its nice that you can post the correct information and/or provide another way the person can try to get it fixed . I felt his situation is very similar to repairs of water damaged modules that I see and repair everyday in my shop and offered a similar strategy he could research on his own. That is, if the conclusion ended up with the mcu being dead which is not a easy situation for someone with out previous experience to deal with and would require a lot more work then one might think.

In my industry the Motorola/Freescale mcu's I deal with and base my similarities on are the 908, 9s12 and mpc chips (quite different in comparison I'm sure). Commonly found inside automotive modules and its very common practice to bypass security in them. It generally consists of hooking 5-10 wires in-circuit and letting the programmer do its job. Usually not all that difficult with simple instructions so I hope you can understand in my reality this is much simpler to suggest someone do then telling them to go write code (assuming they have no knowledge of coding).

Perhaps PIC do not contain these types of backdoors or bypass methods or maybe there is no market in it to bother seeking them. I do not know and do not have the need personally to research it.

They don't, and I'm quite distressed that Motorola/Freescale manufacture such poor quality products? - not to mention that companies actually use such poor products.

 

[narkeleptk]

Thanks for informing me.

What makes it poor quality? The fact that it gets hacked? Its not that they do not do a good job its just the market is so large someone will always find away around it.

 

[Nigel Goodwin]

Thanks for informing me.

What makes it poor quality? The fact that it gets hacked? Its not that they do not do a good job its just the market is so large someone will always find away around it.

The fact that it's so poorly designed that it can be easily hacked - as for 'large market' the MicroChip PIC has the largest market for any single source supplier.

Last I heard PIC 'hacking' required dissolving the encapsulation and using an electron microscope to read the chip, an incredibly expensive and difficult procedure.

 

[narkeleptk]

I wouldn't look down on them to much. Its not really their fault and I think many of the car manufactures requested many of the backdoors for their own development. Both do their best to block out the aftermarket sector and its a p.i.t.a for us to stay current I can assure you.

When I said market above, I mean the entire aftermarket automotive market. Its big business. Tool development, Repair, Security, the tuning world, etc.. Not the market for selling chips. Maybe PIC sells a lot of chips but if they are used in devices that are not worth or have the need for modifying/repairing consistently (or as the other poster said it may be more feasible to just write new code) it may not be much in the pic market for someone to come in and develop the tools or methods needed to bypass. If theres not much money to be made theres not much development.

 

[Nigel Goodwin]

When I said market above, I mean the entire aftermarket automotive market. Its big business. Tool development, Repair, Security, the tuning world, etc.. Not the market for selling chips. Maybe PIC sells a lot of chips but if they are used in devices that are not worth or have the need for modifying/repairing consistently (or as the other poster said it may be more feasible to just write new code) it may not be much in the pic market for someone to come in and develop the tools or methods needed to bypass. If theres not much money to be made theres not much development.

PIC's are used in an incredible range of devices, you find them pretty well everywhere - they are popular because they are cheap, powerful, have good support - AND have good security.

As I mentioned above, PIC's CAN be hacked, but it's extremely expensive, as their superior security features mean it's not possible to do it simply as with the devices you're talking about.

However, as you're talking about 'aftermarket sector' - presumably you're meaning 'chipping' cars to alter their performance?. As far as I was aware this isn't done by manipulating the processors internal code, but merely by manipulating the data stored externally to the processor? - presumably in an EEPROM of some kind?.

In which case you're not cracking the processors security features at all, and perhaps we shouldn't be maligning Motorola/Freescale?.

 

[narkeleptk]

bit off topic now so will shut my trap about PIC. I have obviously assumed to much about something I do not know well enough. But to answer your question about tuning which is a still a small niche in the bigger scope of the aftermarket auto world. This is mainly done in the flash sector not eeprom. Eeprom sections usually only hold onto more specific data pertaining to your exact car. Like immobilizer data, vin, mileage, sensor data , etc.. Where as the flash area is more for overall programming of the whole line of that model. In the case of a pcm, the engine controls (fuel/air/fire) and transmission controls. Please keep in mind this is a generalization and very basic explanation. I do not do much tuning but my daily work still has me in all types of modules both eeprom and flash sections, secured and unsecured. Motorola is not the only one, others like Infineon, Nec, ST is the same. I actually like 9s12 the best but maybe because it is the most common I work in.


I saw "bunnies" article of hacking a pic but only skimmed it. Do you know if, considering they found the address containing the security bits. Is it now not possible to write only to that section to turn if off on all PICS that use that same programming?
I am pretty sure that some 908's work like that to unsecure.

 

[hyedenny]

In which case you're not cracking the processors security features at all, and perhaps we shouldn't be maligning Motorola/Freescale?.

He specifically stated more than once that he was talking about microcontrollers. I don't believe it. I've been in the auto performance/tuning/racing business for more than 35 years, and I've never seen or heard of what he's on about. Granted, his English isn't exactly perfect, but giving consideration for that, I still don't buy what he's selling.
In any case, it makes absolutely no sense in the context of this particular discussion.​

 

[Ashly90]

I would pull the transistors, then check all the voltages at the PIC.

I’ve pulled the transistors and attached a image of the results, hope this helps

Account Suspended

 

[Nigel Goodwin]

bit off topic now so will shut my trap about PIC. I have obviously assumed to much about something I do not know well enough. But to answer your question about tuning which is a still a small niche in the bigger scope of the aftermarket auto world. This is mainly done in the flash sector not eeprom. Eeprom sections usually only hold onto more specific data pertaining to your exact car. Like immobilizer data, vin, mileage, sensor data , etc.. Where as the flash area is more for overall programming of the whole line of that model. In the case of a pcm, the engine controls (fuel/air/fire) and transmission controls. Please keep in mind this is a generalization and very basic explanation. I do not do much tuning but my daily work still has me in all types of modules both eeprom and flash sections, secured and unsecured. Motorola is not the only one, others like Infineon, Nec, ST is the same. I actually like 9s12 the best but maybe because it is the most common I work in.

Like I said, data only, not program code, and not stored in the processor - so no read protection to break.

While I'm ABSOLUTELY certain that you could seriously mess things up by altering the data, it's not 'too' touchy - whereas trying to alter the program code at that kind of level would trash it totally if you got a single bit wrong.

So your original comment didn't apply in any way, as you're not reading security protected processors, only external data memory devices.

I saw "bunnies" article of hacking a pic but only skimmed it. Do you know if, considering they found the address containing the security bits. Is it now not possible to write only to that section to turn if off on all PICS that use that same programming?

No, the security bits (fuses) are in their own 'space', and well documented as to their location - but you can't just alter bits in a protected device, the ONLY way to do so is to erase the entire device. When you do erase, the program space and EEPROM space are erased first, and the 'fuses' (including the security bits) are only erased after everything else has been wiped.

If I recall correctly, the flaw in the antique 16C84 was that you could erase the fuses without erasing the program code first.

Personally I never code protect any of my devices, I don't really see the point for almost all applications.

 

[narkeleptk]

He specifically stated more than once that he was talking about microcontrollers. I don't believe it. I've been in the auto performance/tuning/racing business for more than 35 years, and I've never seen or heard of what he's on about. Granted, his English isn't exactly perfect, but giving consideration for that, I still don't buy what he's selling.
In any case, it makes absolutely no sense in the context of this particular discussion.

I'm not sure why you feel the need to insult my speaking and since I am a native speaker born and raised I take it more as you are insulting my education which is all fine and dandy if you want but what is it you do not believe? Its not common to read secured area's of mcu's in my profession? Maybe we are both confused now and thinking of different things? You know because of my bad English and all. If that is the case I must apologize to you.

Here are a few of my favorite and widely used tools to access secured sectors of many mcu's used in automotive applications:

Alientech USA | Pioneers of ECU Remapping

We are the official North American Division of Alientech SRL (Italy).

www.alientech-usa.com

https://www.eldb.eu/

BDM100 module

www.evc.de

Here are some caps from the flash sections of secured area's you can see what they are in the file location header if your curious. I have 1000's of eeprom and flash (secured and unsecured) files from all different makes/models. If you want, search video's on you tube. I am sure there are plenty to be found.

 

[unclejed613]

However, as you're talking about 'aftermarket sector' - presumably you're meaning 'chipping' cars to alter their performance?. As far as I was aware this isn't done by manipulating the processors internal code, but merely by manipulating the data stored externally to the processor? - presumably in an EEPROM of some kind?.

these days more likely some kind of flash ROM. that way the service chain for the end product doesn't need as large a parts inventory. all they need is a laptop PC and serial or JTAG interface to update the end product's firmware. unfortunately this leaves a physical "back door" to the firmware, and people can make modifications to the firmware. whether it's making performance tweaks to an engine computer, or tweaking their surround sound DSP (something i expected to see, but so far i haven't seen any attempts at, or maybe i'm just not looking hard enough), or getting root privileges on an IOT device, if it's got header pins or just pogo-pin pads on the board, somebody is going to find a way in. there are some ARM processors for embedded systems that have protected boot space and the ability to disable the JTAG permanently, but these features are rarely used. with all the videos i see on the subject (look up "defcon hardware hacking" on youtube), there are some manufacturers beginning to take device level security seriously, but there's just as many or more that don't care (once you buy their gadget, it's your responsibility to protect it from intrusion).

 

[narkeleptk]

Like I said, data only, not program code, and not stored in the processor - so no read protection to break.

While I'm ABSOLUTELY certain that you could seriously mess things up by altering the data, it's not 'too' touchy - whereas trying to alter the program code at that kind of level would trash it totally if you got a single bit wrong.

So your original comment didn't apply in any way, as you're not reading security protected processors, only external data memory devices.



No, the security bits (fuses) are in their own 'space', and well documented as to their location - but you can't just alter bits in a protected device, the ONLY way to do so is to erase the entire device. When you do erase, the program space and EEPROM space are erased first, and the 'fuses' (including the security bits) are only erased after everything else has been wiped.

If I recall correctly, the flaw in the antique 16C84 was that you could erase the fuses without erasing the program code first.

Personally I never code protect any of my devices, I don't really see the point for almost all applications.

Yes you can completely trash things and many tuners do just that.

Thank you for your answer on the security bits. For some of the hc908's you can modify just those bits and unlock the flash so I was curious if PIC was simular.

 

[Nigel Goodwin]

Yes, flash data only. NOT the actual written programming code. You need to know how to edit the flash data in order to make the changes you need but for my original suggestion of CLONING you simply are copying the flash data from one chip to another. Absolutely nothing to do with the written programming language.

In the distant past, I have actually edited programmes at the exe file level, changing bytes in the program code - on Commodore Amiga 68000 programs.

This was simply to bypass the protection schemes, so as to install the programs on an HDD rather than running from floppy disk (protection schemes commonly checked for a physical defect on the disk itself).

However, it's a very long and difficult procedure, even when you can dis-assemble the code to assembler it's pretty horrible, particularly when the original was written in C.