There are 2 memory modes on that processor, Mode0 which uses the
internal RAM and ROM (which is how the PDD is being used), and Mode 1
which addresses external memory and masks the internal ROM. The modes
are selected at startup and can't be switched until the chip is reset.
I used an internal function of the PDD ROM to place a small ASM program
into RAM and then execute it, which then read the ROM and output the
contents to the UART of the chip. I do not know if this attack vector is
present on the PDD2. Judging by the fact that the PDD1 uses almost 100%
of the ROM (only 6 unused bytes out of 4K), that function may have been
removed to allow for new functions on the PDD2.
Attack vector described here:
https://github.com/BiggRanger/Tandy_PDD/blob/master/ROM_DUMPER/PDD1_Dump.INFO
https://github.com/BiggRanger/Tandy_PDD/blob/master/ROM_DUMPER/PDD1_Dump.ASM
For the PDD2 I would use probably a timing or glitch attack with
external memory (read only); make the address 0x0100 to 0xE000 all NOPs
with the code to initialize the UART, read the ROM, and send it to the
UART between 0xE001 and 0xEFFF. With a bunch of timing and reset
glitches it's possible to get the processor to start executing code
somewhere between 0x0100 and 0xE000 and fly through all the NOPs until
it hits the payload. In the release notes it states that location 0xFFFE
and 0xFFFF (which store the reset vector) may get read externally in
Mode0. I would also hard code these address with a reset vector to point
to 0xE001, that way if a glitch forced a reset in Mode0 but accidentally
read the external memory it would jump to the payload and run it.
But for all this to work I would need to remove the processor from the
board and put it onto a new PCB so I could have control over the clock,
power, mode, and reset pins, and connect it to a suitable external
memory. That is why I'm looking for a not-working PDD2 with a working
processor.
Darren Clark
On 3/19/21 7:18 PM, Stephen Adolph wrote:
I wonder if there is a way to boot that processor off of external
memory, such that the firmware could be extracted...
On Friday, March 19, 2021, Darren Clark <biggran...@gmail.com
<mailto:biggran...@gmail.com>> wrote:
That is awesome to see! I was hoping it would talk a little more
about the firmware running on the HD63A01, but the information on
the pinout of the gate array chip is interesting and matches up
pretty well with what I reverse engineered from the firmware.
I'll have to revisit my reverse engineering of the firmware on the
TPDD and see if there is anything to update with this new
information. Looks like the returned error codes may be something
to add.
Here is a link to the firmware I pulled and decoded from the PDD1:
https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD1.ASM
<https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD1.ASM>
And the whole project: https://github.com/BiggRanger/Tandy_PDD
<https://github.com/BiggRanger/Tandy_PDD>
Maybe if someone has a bad TPDD2 or 2 I can try to get the
firmware off of that too.
Darren Clark
On 3/18/21 9:59 PM, Brian K. White wrote:
On 3/18/21 8:31 PM, Joshua O'Keefe wrote:
On Mar 18, 2021, at 5:13 PM, Stephen Adolph
<twospru...@gmail.com <mailto:twospru...@gmail.com>
<mailto:twospru...@gmail.com
<mailto:twospru...@gmail.com>>> wrote:
so I did it brute-force.
https://bitchin100.com/wiki/index.php?title=TPDD_Service_Manual
<https://bitchin100.com/wiki/index.php?title=TPDD_Service_Manual>
<https://bitchin100.com/wiki/index.php?title=TPDD_Service_Manual
<https://bitchin100.com/wiki/index.php?title=TPDD_Service_Manual>>
In the interest of preservation and putting our eggs in
multiple baskets, I have mirrored this file to my S3 bucket
Similarly I put it in archive.org <http://archive.org>
