How to dump 8-bit microcontroller ROM? - Page 1
Forum section: electronics / projects

author: CD32Freak
author_rank: Newbie
timestamp: September 08, 2024, 06:04:49 am
content: Does anyone know how to dump the ROM of a classic 8-bit Matsushita/Panasonic MN187164 microcontroller? I have this CD-ROM controller of an Amiga CD32 drive and I would like to decompile the ROM of the microcontroller and figure out how it works. It's the one on the left above:I couldn't find the datasheet of MN187164, but I do have the pinout:Thanks in advance!

author: pcprogrammer
author_rank: Super Contributor
timestamp: September 08, 2024, 06:28:26 am
content: I found thisservice manualwith a block schematic of the MCU in it, and based on that I think it is masked programmed and not possible to read it from the outside world.I also found thisdocumentwith some specifications on the MN1870 family.A search for "MN1870 datasheet pdf" gives a bit more. For instance thisreference manual. Not the exact match for yours but will provide enough information.

author: CD32Freak
author_rank: Newbie
timestamp: September 08, 2024, 05:03:31 pm
content: Thanks, I have found these documents myself before

author: CaptDon
author_rank: Super Contributor
timestamp: September 08, 2024, 05:28:07 pm
content: Many of these little MCU devices are intentionally built with no way to read the contents. That is the surest way to protect intellectual property and a selling feature of the devices for mass production. It is a brutal means of copyright / patent protection. The idea is still common today, maybe even more so. We took advantage of this style of I.P. protection in many of the G.E. Rail products we designed.

author: daqq
author_rank: Super Contributor
timestamp: September 08, 2024, 06:41:53 pm
content: Quote from: pcprogrammer on September 08, 2024, 06:28:26 amI've seen some very physical ways to read out mask ROMs firmware through a microscope:http://adamsblog.rfidiot.org/2013/01/fun-with-masked-roms.html

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 09, 2024, 01:57:40 am
content: There is the distant possibility of hackery -- maybe not even that distant, as it's not uncommon I think, to have bootloader, patching or in-RAM callback functionality; after all, it's mask, you better bepretty damned surewhat's in there is what you need for the application, and if it's not, you just scrapped an entire run of -- whatever, at least slices from a proto wafer and the masks that made it, if not a whole wafer, or run thereof. This has to be balanced with security (in this case perhaps, piracy protection?), and maybe such functions are authenticated (would be fairly simple back in those days, a passkey perhaps), maybe locked down in other structural ways (e.g. turns out you can't input a random-dump function, just a targeted read or narrow range at a time), but maybe that just means it's more tedious to extract (i.e. put it in a loop with power-cycle then re-init with next address and etc.).But that very quickly gets into the realm of, not even exponential, but combinatorial explosion, as you need to first figure out the API, probe (or fuzz) other potentially hidden API calls, maybe supply-glitch your way past other checks, etc. etc., until you finally find enough access, or ROP gadgets or whatever, to achieve readout. And at that point it may start looking very attractive to just torch the device, get a microscope on the chip, and dump it that way. (Maybe both: physical extraction to RE the interface, then attack that for nondestructive readout, and make a toolkit so everyone else can do it.)Tim

author: pcprogrammer
author_rank: Super Contributor
timestamp: September 09, 2024, 05:58:07 am
content: Quote from: T3sl4co1l on September 09, 2024, 01:57:40 amAnd all of that for an old, outdated CD-ROM drive.A more likely scenario for back in the day is that a prototype was developed with a piggy back EPROM version of the MCU before it went into mass production with a masked ROM.

author: CD32Freak
author_rank: Newbie
timestamp: September 09, 2024, 04:42:34 pm
content: Thanks all for your reply!

author: CaptDon
author_rank: Super Contributor
timestamp: September 09, 2024, 05:04:35 pm
content: Years ago it was common to debug and program with an onboard Eprom or EEprom version of the MCU then go to market with OTP version of the I.C. and I.P. security was assured by not being able to access the internal code. IF you have a OTP or metal masked internal ROM there would be no practical reason to access it being that it can't be altered anyway. Reminds me of some of the offerings from Intel years ago. MCU/CPU available with a quartz window for development and no window for production. Some of the newer stuff has an internal crystalline fuse that can be intentionally blown which will prohibit both code changes AND readout of internal code. One of our dimwits fat fingered something during development and told the programming device to blow the fuse at the end of the code load and indeed turned several development boards costing $3K each into 'target practice' junk!! We weren't willing to risk even more lost time trying to remove and replace large BGA devices. We never had good luck going down that road.