Reading P83Cxxx devices - Page 1
Forum section: electronics / general

author: Captain Jack
author_rank: Contributor
timestamp: May 13, 2025, 01:14:33 pm
content: Hello allI have an old satellite receiver which has two microcontrollers within it. They are:P83C851P83C654They both seem to be 8051 derivatives with no EPROMs inside. Just ROM.I have tried reading them using TL866 programmer using 875x device options but it only reads the first 512 bytes and then repeats for the rest of the address space. As I can read the first 512 bytes, which seems valid and the data disassembles OK, I am assuming that it's not read protected.Is there a programmer which could potentially read more than the first 512 bytes in a loop?

author: Phaseseeker
author_rank: Regular Contributor
timestamp: May 13, 2025, 01:20:51 pm
content: If the device's ROM is indeed not protected, it should be readable like any other 8051 using 8051Dumper:https://github.com/JohnDMcMaster/8051dumper

author: LaurenFoster
author_rank: Newbie
timestamp: May 14, 2025, 04:37:01 am
content: Thanks for the link.

author: amyk
author_rank: Super Contributor
timestamp: May 14, 2025, 05:32:28 am
content: Quote from: Phaseseeker on May 13, 2025, 01:20:51 pmLooking at the 83C851datasheetI'm not sure if that will work since it relies on dynamically switching /EA. Page 9 specifically states that "Since the external access mode can only be selected by pulling the /EA pin low during reset, it is not possible to read the internal program memory using the MOVC instruction while executing external program memory." The '654's datasheet has a similar wording.However, being able to read the first 512 bytes suggests that maybe there's a different way of reading it; I assume you did check that the code is actually more than 512 bytes long, and not just whoever originally made the mask for the ROM didn't just repeat the 512 bytes throughout?

author: Phaseseeker
author_rank: Regular Contributor
timestamp: May 14, 2025, 06:14:39 pm
content: Looks like it depends on the specific variant of the microcontroller in question. The (older) Signetics datasheet readsQuote from: Signetics datasheetFor the 851, however, you're right.EDIT: I also took a look to the 8751 datasheet (since Captain Jack said they tried reading the chip as such) and that chip, being the user-programmable EPROM version, does indeed support a "code verify" test mode, in which the MCU shifts out the internal ROM contents of some of the ports. However, the 83C851 datasheet again states:Quote from: NXP 83C851 datasheetSo I have no idea where the TL866 is pulling data from.

author: amyk
author_rank: Super Contributor
timestamp: May 15, 2025, 02:12:09 am
content: Signetics is not Philips/NXP.

author: Phaseseeker
author_rank: Regular Contributor
timestamp: May 15, 2025, 08:11:24 am
content: I'm very much aware of that. However, if you actually look at the datasheet I'm talking about (https://bitsavers.trailing-edge.com/components/signetics/_dataBooks/1992_Signetics_80C51-Based_8-Bit_Microcontrollers.pdf), you'll see it's marked "Signetics/Philips Semiconductors", so I'd bet it's the same parts.

author: Captain Jack
author_rank: Contributor
timestamp: May 18, 2025, 08:49:33 pm
content: Quote from: amyk on May 14, 2025, 05:32:28 amThat's certainly possible though would be a bit odd? The code seems legit. There are no long jumps, only short ones but plenty of code memory switching going and is hard (for me) to read.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: May 19, 2025, 06:03:45 am
content: Would you mind posting it? I can check it.

author: Captain Jack
author_rank: Contributor
timestamp: May 19, 2025, 08:24:33 am
content: Quote from: abyrvalg on May 19, 2025, 06:03:45 amSure - see attached. This has been read using "8758" device in xgecu but other 8051-type devices result in the same dump.I have conflicting information as to what the die inside actually is but it's based on the 8051 with C851 containing mask ROM and a small EEPROM (according to the data sheets) but it could also be an EPROM + EEPROM without the ROM(?).I've been informed (perhaps unreliably) that doing a functional decap and resetting the security fuses with a UV laser beam would allow the read of the entire address space. With the ROM being mask, it may also be possible to read that out optically.I know Caps0ff did a lot MAME chip dumping and this is likely something they could have helped with. However, they are no longer active and I don't know anyone else who would be able to do this (or whether it's even doable).

author: abyrvalg
author_rank: Frequent Contributor
timestamp: May 19, 2025, 11:40:00 am
content: The code looks legit and self-sufficient within 512 bytes (except for a single byte read of address 0xBFEA in CODE space), there are EEPROM accesses etc, but it's overall purpose looks quite meaningless, like it is not a real "application" but some kind of EEPROM tester. Perhaps it even originates not from chip's ROM, but from the programmer itself (the idea of reading mask ROM 8051 variants is to substitute an external ROM containing a dumper code and force external access)

author: Captain Jack
author_rank: Contributor
timestamp: May 19, 2025, 12:51:28 pm
content: Thanks for taking a look. And that's some excellent commenting and variable naming!It does not seem to be coming from the programmer. The 654 chip has the same symptom (repeating 512 bytes) but a totally different, but still valid, code. We've also tried reading it using BPMicro with the same output.The chip is actually from an early 90's satellite decoder, so there are plenty of things we don't know about it. It's interesting that there's an erase EEPROM routine so early on. The EEPROM will contain some decoder-specific data, such as serial numbers, so would be weird to see it erase. I was hoping to see more action from Port 0 as that's connected to what I think is an ASIC, which should be quite chatty.Does this chip allow execution from an external EEPROM? Wondering if we can create a dumper program (a la John McM's one) to dump the internal EEPROM. That would use MOVX, instead of MOVC, which, according to the datasheet, has no restrictions...

author: Phaseseeker
author_rank: Regular Contributor
timestamp: May 20, 2025, 07:50:04 am
content: I'm puzzled about how the xgecu is pulling data considering the ROM verification mode shouldn't work on these chips per the datasheet. Maybe it's the mysterious "test-mode" Philips mentions in their datasheet but does not explain.Also, the wording in the datasheet about "code protection" being a mask-programmable bit strongly implies there's a way to read these from external code (maybe not with the 8051dumper ROM since EA is latched)PS if it's satellite stuff there's a pretty big chance they've taken countermeasures to prevent people from reading their code...

author: Captain Jack
author_rank: Contributor
timestamp: May 20, 2025, 09:06:00 am
content: Quote from: Phaseseeker on May 20, 2025, 07:50:04 amNot a clue... it's all a bit weird. I am going to build McMaster's dumper and see what that shows. Maybe there isn't a fuse set after all? Reading its internal EEPROM will be also be an interesting experiment. The mask ROM can be read optically but it means a chip sacrifice.QuoteYou'd think but I've seen many sensitive ICs being unprotected in these boxes.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: May 20, 2025, 11:13:00 am
content: Quote from: Phaseseeker on May 20, 2025, 07:50:04 amWould be interesting to spy on this process with a logic analyzer. Perhaps it will give a clue how to read the rest.

author: Captain Jack
author_rank: Contributor
timestamp: May 20, 2025, 03:59:24 pm
content: Quote from: abyrvalg on May 20, 2025, 11:13:00 amI don't want to mess about with the "live" chip, so I bought a few scrappy ones from eBay as well as the PCB board for the 8051 dumper. Will use those to practice stuff!

author: amyk
author_rank: Super Contributor
timestamp: May 21, 2025, 02:38:51 am
content: Would you mind posting the dump you got with the '654 too? It might do a similar thing to what abyrvalg mentioned, i.e. the "stub" the programmer uses for reading, but specific to the '654. Reading back this code is precisely the behaviour expected if it latches /EA on reset.

author: Captain Jack
author_rank: Contributor
timestamp: May 21, 2025, 08:13:17 am
content: Quote from: amyk on May 21, 2025, 02:38:51 amSure, see attached the first 512 bytes (which also repeat).Quote from: amyk on May 21, 2025, 02:38:51 amCan you help me understand this (because I am an idiot)? So you think the programmer is dumping its own "bootloader"? Or is that the "bootloader" that's on the 851 device from its ROM that it executes when /EA is latched? From the listing, it looks like it's directly from the ROM, though it's unclear where in the ROM and whether it's actually executed.FWIW, the TL866 programmer I am using does not have "83C851" or "83C654" listed as supported devices. I am using 8052 device from the list. AFAIK, the programming procedure between the two is similar.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: May 21, 2025, 08:56:26 am
content: This one (654) doesn't look like a valid code to me.Programmer reading it's own dumper stub was my guess too, but it looks wrong indeed:- you read different chips using the same setup (8052) and get significantly different contents- you've mentioned using a different programmer on the same chip and getting the same content

author: Captain Jack
author_rank: Contributor
timestamp: May 21, 2025, 03:09:11 pm
content: Quote from: abyrvalg on May 21, 2025, 08:56:26 amThat's correct - the code is identical from both programmers for the respective chips when read as 805x devices.One oddity is that the BP Micro programmer has support for 83C654 chip and that reads the 654 the same as my programmer with identical content. However, when reading 851 chip as 654 on BP Micro, the output is completely nonsensical... Not sure what to make of that.

author: Captain Jack
author_rank: Contributor
timestamp: May 22, 2025, 04:52:20 pm
content: Could someone translate this into plain English?QuoteIn the extracted code block, I see that the security byte is set to 0x55 or 0xAA. That's 4 bits set. Based on the above, does this mean that the SB = 1? (though I am still not clear at which point that code is executed - surely the EEPROM isn't erased on every start?)

author: Phaseseeker
author_rank: Regular Contributor
timestamp: May 23, 2025, 09:10:44 am
content: It's basically saying that the "security bit" SB is set when three or four bits are set in the EEPROM security byte @ 0x8000, and that if SB is set the only operation you can execute when running from external ROM code is the EEPROM block erase command (for which they provide the example code after). So no dumping the EEPROM even if you manage to get the thing to execute external code.Also, I finally figured out how the damn mask ROM protection bit is supposed to work (better late than never): basically, with the bit set, even if you manage to get the 8051 to run code from addresses after 0x1000 (which always point to external memory regardless of EA) without ever pulling EA low, it's not gonna let MOVC instruction read from the 0x000-0xFFF internal ROM range.

author: Captain Jack
author_rank: Contributor
timestamp: May 23, 2025, 03:50:42 pm
content: What does "not let" look like? When executing MOVC A,@0x0123, will the contents of A be 0x00, 0xFF, a random value or will the card simply hang?I've dumped smart cards in the past with protected ROM (Motorola based) that simply hung when trying to do LDA $ROMADDR. There were some interesting tricks that could be used to determine which bits were set on the data bus when the card hung.Alternatively, some glitching could also read these chips. The security bits in EEPROM were read before allowing things to happen. By using clock or voltage glitching, these checks could be bypassed. Though it can also ruin the chip if you glitched in the wrong place (less problems with ROM since these can't be modified).

author: Phaseseeker
author_rank: Regular Contributor
timestamp: May 23, 2025, 07:04:31 pm
content: I'm not sure, the datasheet is (probably on purpose) vague about this. The thing is, the ROM might not even be protected, but the issue is that you need to somehow (maybe by glitching) getting the CPU to jump to the external dumper ROM code (starting from 0x1000) without using the EA pin, because if it gets latched low at reset you're not gonna be able to address internal ROM data.If you're able to do this, 8051dumper code+board would then work to dump the ROM, because it's exactly how it's supposed to work: read code from 0x1000 onward, read data from lower addresses with EA high

author: Captain Jack
author_rank: Contributor
timestamp: May 24, 2025, 06:39:46 pm
content: That's not a bad idea. I dumped a dozen Motorola based smart cards using this method. Plant the "virus" code into the card's RAM, which reads the whole EEPROM address space in a loop and glitch it until the execution jumps into RAM.I am not really familiar with 8051 architecture hence the billion questions. From what I know, the 8051 does not allow execution from RAM but if we attach an external EEPROM to it without the /EA pulled low, then, like you said, it's potentially possible for it to jump there. I have a Chip Whisperer Lite here, which is perfect for this.One question on this - if the /EA is latched high, how does 8051 core know there's an EEPROM attached to its parallel port? Or does it not need to "know" and would automatically jump to the EEPROM address on its port if glitching corrupts the long jump address. Or corrupting the instruction itself.. Or the stack. Basically anything!

author: Phaseseeker
author_rank: Regular Contributor
timestamp: May 25, 2025, 09:12:04 am
content: Yeah, it doesn't need to know an EEPROM is there, addresses after 0x0FFF always map to the external address space. The EA pin is used to force the CPU to fetch data from what would be the internal ROM range from the parallel bus instead. The normal 8051dumper would exploit this by keeping EA low at reset, making the CPU fetch a jump to address 0x1000 where the rest of the dumper code resides, the pull EA high to be able to read the internal code. Here we can't do that because EA is latched hence the need to jump to 0x1000 by glitching or other means

author: Captain Jack
author_rank: Contributor
timestamp: May 25, 2025, 10:25:21 am
content: That's great - thanks!I can fill the 32kb ext EEPROM space with nop slides and jumps to a single address which would spit some string out of its serial port. So any glitch which results in a jump to any 32k address would result in that string being printed. Then I can narrow down the glitch point and the jump location...If that works, I'll be astonished. Let's hope the contents aren't encrypted, which by looking at some MAME dumps, a lot are...

author: Captain Jack
author_rank: Contributor
timestamp: May 25, 2025, 06:30:36 pm
content: Another question. I have been advised that it may not be possible to execute from EEPROM as the data sheet suggests that it's only possible to read EEPROM via the EEDATA register. This only seems to apply to the internal 256 byte EEPROM on that chip and not necessarily the external one (it doesn't specifically mention it either way). My assumption is that the connected external EEPROM will be available on addresse $1000+ and one could long jump to it.Thoughts?

author: Phaseseeker
author_rank: Regular Contributor
timestamp: May 25, 2025, 06:56:02 pm
content: Yeah the EEPROM the datasheet talks about is the internal 256 bytes one, for which the only access is through the various registers you mention. It doesn't explicitly talk about an external code EEPROM because, well, you could hook up any parallel memory device you want to run code from, but yes the microcontroller can and will run code from the 0x1000 range if you manage to jump to it

author: Captain Jack
author_rank: Contributor
timestamp: May 26, 2025, 09:59:13 am
content: OK thanks. One way to find out.Another thought. If the glitching can cause unpredictable behaviour, is it logical to presume that a glitch can also cause the /EA to unlatch during execution? Thereby allowing movc reads? I assume it's nothing more than a transistor latching the thing in its initial state.

author: Phaseseeker
author_rank: Regular Contributor
timestamp: May 26, 2025, 12:06:54 pm
content: I'm not sure, I'm not familiar enough with 8051 glitching. In the datasheet, on page 9, it shows a simplified schematic of the EA circuitry, but as to how it's implemented in the actual chip is anyone's guess. Since it's latched by the RESET signal, it might even be possible to make it latch a new value with a reset pulse that's short enough not to reset the core (though I seriously doubt it).

author: abyrvalg
author_rank: Frequent Contributor
timestamp: May 26, 2025, 12:08:31 pm
content: Latches hold their values quite strongly “at rest”. Glitches are targetingchanges(also allowing to target precisely in time). Flipping a latch at rest would require a stronger glitch which could also disturb any other thing, i.e. the PC reg. But you can target the latched value check during movc (but you’ll need to repeat it for each movc).

author: Phaseseeker
author_rank: Regular Contributor
timestamp: September 09, 2025, 03:03:05 pm
content: Hi, sorry to resurrect such an old thread, but I was wondering: did you ever manage to extract any data from the device? I ask because coincidentally I've come across a similar protected 8051 I'd like to dump...