Author Topic: Reverse-engineering a HD63B03RP-based AES Prodata bus ticket machine  (Read 1235 times)

0 Members and 1 Guest are viewing this topic.

Offline Rjevski

  • Supporter
  • ****
  • Posts: 11
  • Country: gb
Hello,

I'm trying to reverse-engineer a very obscure piece of equipment - an AES Prodata bus ticketing machine - it can read/write and print (thermal) paper tickets with a low-coercivity magstripe. The one I got is actually an Australian one as it had a sticker about "not for Opal cards" on the face of it. It's one of old green ones as in this picture.

(I've updated the post with my latest findings/understanding of the device - original post will be below for reference)

The main CPU is a HD63B03RP, and there's an IO multiplexer chip HD63B21P. There's also a timer chip HD63B40. Board photos are available here (the forum doesn't allow me to upload the full resolution photos unfortunately).

The board has two ROMs (one EEPROM "P28F010-120" marked "BOOT DRIV" dumped as "ROM2.hex" and one EPROM "AM27C128-200DC" dumped as "ROM.hex") as well as an SRAM chip "HY62256ALP-10" powered by a backup battery which I've temporarily shorted to try and clear it thinking it would make it go into a factory/debug mode (it didn't) so let's assume the contents of that one are now lost/unreliable. There's also an FPGA "XC2064-50 PC68C" which I assume would be used for the magnetic card reading/writing, printing or motor control for the card transport mechanism.

At the moment the machine itself powers on and displays a fixed value on the LCD - something like "SBZ001" and stays stuck there, presumably it's waiting for the right sequence of bytes on the serial port to begin operating. I'd like to figure out what it wants so I can send it to it and make it boot properly. There's an RS485 transceiver on the board. The device spews out regular garbage on the serial port - I'm not sure what baud rate it is (is there even a concept of baud rate in RS485? My USB converter presents itself to the system as a standard serial port to the OS and I can set a baud rate) but I've tried them all and I get garbage in every case so I assume it's just outputting binary for now. I do not yet have a scope to probe further.

There are also 16 DIP switches on the board however no combination of them appears to have any visible results even after rebooting.

Power-wise it seems to be able to run on both 12 and 24 volts - there seems to be a huge block on the board around the power area and several connectors coming back to the board which can be configured in different ways - presumably you can either feed the right voltage directly to the board or change the connector to make the power go through the extra block which would step it down to a proper level. I've got the board powered up properly (I've fed in 19V from a laptop PSU both with and without the extra block and the board powers on and appears to be fine - going through the extra block makes it take longer to power on - I assume that one expects a higher voltage normally and the delay is just its caps charging up on a lower voltage than it expects).

What would be the next steps that you would suggest?

I will eventually get around to tracing the full board which would allow me to figure out the address space (my el-cheapo multimeter has a good 500ms delay on the continuity mode making this process extremely tedious, but I'm planning to get a better one), in the meantime I'd like to make as much progress as possible with what I've got at hand. At the moment the memory map is assumed to be like the following thanks to abyrvalg:

Quote
boot:
ROM2:0:4000 -> C000 - this is an FPGA loader (FPGA bitstream is at +0x40), it jumps to "main" ROM C022 after load. Looks like a standalone banked ROM.

main:
ROM1:0:4000 -> C000 - entry point at C022, vector table at end
ROM1:6000:8000 -> A000
ROM1:8000:C000 -> 6000 - entry point at 6022

0:6000 must be HY62256 RAM (overlaid by CPU’s SFRs 0:20 and IRAM 80:100)

Regarding disassembling, IDA is out of the question - I don't have a license and the Home one wouldn't be suitable as it doesn't support this architecture. I've reached out to them to see if they can sell me a "special" non-commercial license for that architecture at a more affordable price but no luck. Ghidra was recommended here, however I'm not sure which CPU architecture to pick. Here's a list of architectures it supports - which one should I pick? Alternatively, do you know any other GUI-based disassemblers (free or paid but reasonably priced) that would support it?

I've been thinking of getting a logic analyzer - I'd need 32 channels at a minimum for this and they are reasonably pricey - do you guys know if there's a way to combine multiple cheap 16-channel analyzers instead? There are cheap Chinese USB ones on Amazon and it would come out cheaper to buy 2 or 3 of these and somehow combine them than buy the "proper" one.

Also I'd like to figure out what I can use to substitute the "AM27C128-200DC" EPROM. I've searched around and most drop-in flash alternatives are no longer in production (though eBay is full of fakes) - would a modern microcontroller with the right pin count be fast enough to emulate one? Alternatively, are there commercially-available emulators that would take a ROM file from a computer and emulate it? I've seen such a product on an automotive tuning website but the price was in the 300 bucks range - does anyone know if others exist? I could see this being useful for cartridge-based consoles too so surely something like that must exist?

Thanks.



Hello,

I'm trying to reverse-engineer a very obscure piece of equipment - an AES Prodata bus ticketing machine. The one I got is actually an Australian one as it had a sticker about "not for Opal cards" on the face of it. It's one of old green ones as in this picture: https://railgallery.wongm.com/sydney-ticketing/E115_9101.jpg.html

The main CPU seems to be a HD63B03RP, which according to my understanding has 64K of internal ROM. The board does have an EEPROM which I have dumped and while it does contain some strings (that would be displayed on the LCD) my disassembly efforts have failed (all the free disassemblers out there only produce nonsensical assembly, although I haven't tried IDA yet as I can't justify the price of a license) so I'm assuming it must be just configuration data and the actual firmware is in the microcontroller itself. I've attached the ROM file as well in case someone is curious.

Assuming I am correct about the chip having internal firmware, does anyone have ideas about dumping it? I would like to do so to understand what it expects in the config ROM and what's the protocol on the serial port - so far all combinations of baud rates I have tried produce unintelligible text, so I'm assuming it's just speaking binary which isn't easy to make sense of.

At the moment the machine itself powers on and displays a fixed value on the LCD - something like "SBZ001" on the LCD and stays stuck there, presumably it's waiting for the right sequence of bytes on the serial port to begin operating. I'd like to figure out what it wants so I can send it to it and make it boot properly.

Regards.
« Last Edit: May 03, 2021, 01:31:07 pm by Rjevski »
 

Offline oPossum

  • Super Contributor
  • ***
  • Posts: 1200
  • Country: us
  • The other white meat.
Re: Extracting firmware from a HD63B03RP
« Reply #1 on: April 12, 2020, 02:24:22 am »
The HD63B03 has a 16 bit address bus so it can use up to 64 kB of memory. The only internal memory is 128 bytes of RAM. There is no internal ROM. It is the functional equivalent of a Motorola MC6803. Instruction set is the same as 6800/6801/6802/6803/6808.
« Last Edit: April 12, 2020, 02:26:45 am by oPossum »
 

Offline up8051

  • Regular Contributor
  • *
  • Posts: 166
  • Country: pl
Re: Extracting firmware from a HD63B03RP
« Reply #2 on: April 12, 2020, 09:18:20 am »
 

Online PA0PBZ

  • Super Contributor
  • ***
  • Posts: 4601
  • Country: nl
Re: Extracting firmware from a HD63B03RP
« Reply #3 on: April 12, 2020, 10:38:47 am »
Can you check your EPROM dump again? It should at max be 64K, the top half of your file is empty and the first part 0000-3FFF should be at C000-FFFF. Maybe they tried to obfuscate stuff by swapping some high address lines or you used the wrong EPROM type to read it?
« Last Edit: April 12, 2020, 10:40:58 am by PA0PBZ »
Keyboard error: Press F1 to continue.
 

Offline Rjevski

  • Supporter
  • ****
  • Posts: 11
  • Country: gb
Re: Extracting firmware from a HD63B03RP
« Reply #4 on: April 12, 2020, 03:32:35 pm »
Thanks for getting back to me. There is another EEPROM on the board which at first I discarded because it had references to Xilinx in it (there is an FPGA on the board as well), but now reading it more closely it might actually contain the actual code (the sticker on the EEPROM says "BOOT DRIV"). I've attached it to this post.
 

Online PA0PBZ

  • Super Contributor
  • ***
  • Posts: 4601
  • Country: nl
Re: Extracting firmware from a HD63B03RP
« Reply #5 on: April 12, 2020, 03:55:46 pm »
Your first dump is the boot ROM, I can see the RESET, NMI and IRQ vectors in there, but the 'problem is that they are supposed to sit at FFF8-FFFF but in your dump file they are at 3FF8-3FFF. If I relocate the 0000-3FFF part to C000-FFFF it makes sense:

Code: [Select]
ROM:FFF8 IRQ:            fdb $E8E2
ROM:FFFA SOFTI:          fdb $D30B
ROM:FFFC NMI:            fdb $D89C
ROM:FFFE RESET:          fdb $C475
ROM:FFFE ; end of 'ROM'

Code: [Select]
ROM:C475 ; ---------------------------------------------------------------------------
ROM:C475                 sei                     ; RESET
ROM:C476                 ldaa    #6
ROM:C478                 bsr     sub_C480
ROM:C47A                 bra     loc_C4B9
ROM:C47A ; ---------------------------------------------------------------------------

So the question is what type of EPROM is it and what type did you use to make the dump?
Keyboard error: Press F1 to continue.
 

Offline Rjevski

  • Supporter
  • ****
  • Posts: 11
  • Country: gb
Re: Extracting firmware from a HD63B03RP
« Reply #6 on: April 12, 2020, 04:04:12 pm »
The second dump in the post above is an EPROM and seems to be an "AM27C128-200DC", it's a ceramic package with the window for the UV lamp to erase it.

I've used a TL866II Plus with the "minipro" software to dump it, with the following command line:

Code: [Select]
minipro -p 'AM27C128@DIP28' -r ROM2.hex
Could it be that there's some circuitry in hardware that would relocate this ROM at a different address space?

The first dump in the initial post was from a Intel P28F010-120 dumped with "minipro -p 'P28F010@DIP32' -r ROM.hex".
« Last Edit: April 12, 2020, 04:08:33 pm by Rjevski »
 

Offline oPossum

  • Super Contributor
  • ***
  • Posts: 1200
  • Country: us
  • The other white meat.
Re: Extracting firmware from a HD63B03RP
« Reply #7 on: April 12, 2020, 05:08:37 pm »
There is probably some sort of banking scheme that allows access to all off the Flash (128 kB) and EPROM (32 kB). That would also do mapping necessary to put the vectors at the right address.
 

Offline Rjevski

  • Supporter
  • ****
  • Posts: 11
  • Country: gb
Re: Extracting firmware from a HD63B03RP
« Reply #8 on: April 12, 2020, 06:49:26 pm »
Just wondering, how would I go about disassembling the first ROM with the understanding that the data should be relocated at C000? I've tried the Online Disassembler at https://onlinedisassembler.com and despite selecting m68k and setting the base address at 0xc000 I'm still getting what seems to be garbage.
 

Online PA0PBZ

  • Super Contributor
  • ***
  • Posts: 4601
  • Country: nl
Re: Extracting firmware from a HD63B03RP
« Reply #9 on: April 12, 2020, 07:09:36 pm »
Just wondering, how would I go about disassembling the first ROM with the understanding that the data should be relocated at C000? I've tried the Online Disassembler at https://onlinedisassembler.com and despite selecting m68k and setting the base address at 0xc000 I'm still getting what seems to be garbage.

M68K is a 68000 32-bit processor so that is why you get garbage. What I did is take the 0000-3FFF part of ROM.hex and saved it as a seperate file. Upload that file and pick 68HC11 for Arch and load address 0xC000. Press No when asked to start disassembly at the beginning of the file. Note that the last 2 bytes in the file are C475, that is the reset vector. Navigate to C475, press C and enjoy.

[attach=1]

Your ROM2.hex is also a bootable 6800 file, maybe used to reprogram the xilinx? What is IC21 and what is the size of the IC16 RAM?
Keyboard error: Press F1 to continue.
 
The following users thanked this post: Rjevski

Offline Rjevski

  • Supporter
  • ****
  • Posts: 11
  • Country: gb
Re: Extracting firmware from a HD63B03RP
« Reply #10 on: April 12, 2020, 07:56:00 pm »
Thanks so much. I'm going to try the disassembly in a second.

IC16 is a HY62256ALP-10 SRAM chip powered by a lithium battery backup (there's a battery on the board and I measure 2.55V on the power pin of the chip even if the board is unpowered). Seems to be 32K in size.

IC21 is a XC2064-50 PC68C FPGA.

Here are the board photos: https://rjevski-my.sharepoint.com/:f:/g/personal/hi_rjevski_io/EtvU2rrlwRNOk5D7cHymoesB4Y3EBhf90xPPfwzkDdG_Yw?e=l0IfKJ
« Last Edit: April 13, 2020, 12:38:45 am by Rjevski »
 

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 528
  • Country: ru
Re: Extracting firmware from a HD63B03RP
« Reply #11 on: April 18, 2020, 01:49:11 pm »
The complete memory mapping looks like this:

boot:
ROM2:0:4000 -> C000 - this is an FPGA loader (FPGA bitstream is at +0x40), it jumps to "main" ROM C022 after load. Looks like a standalone banked ROM.

main:
ROM1:0:4000 -> C000 - entry point at C022, vector table at end
ROM1:6000:8000 -> A000
ROM1:8000:C000 -> 6000 - entry point at 6022

0:6000 must be HY62256 RAM (overlaid by CPU’s SFRs 0:20 and IRAM 80:100)
« Last Edit: April 18, 2020, 01:52:05 pm by abyrvalg »
 
The following users thanked this post: Rjevski

Offline Rjevski

  • Supporter
  • ****
  • Posts: 11
  • Country: gb
Re: Extracting firmware from a HD63B03RP
« Reply #12 on: April 18, 2020, 05:30:04 pm »
Thanks for the information.

I just got a 16-channel logic analyser (Kingst LA1010). It doesn't have enough channels to cover both the entire address bus and the data bus (in fact even for the address bus alone I'm missing an extra channel for the clock pin). I'm thinking to return this and get a bigger one (or get 2, have both share a pin and then sync the two captures in software based on that clock pin) but in the meantime does anyone know any tricks I could do with this logic analyser to get further?

The A0-A7 address lines from the MCU go into a latch (PC74HC573P) and the latch enable pin goes to the MCU's AS (address strobe) pin. Presumably this is to multiplex the address/data bus (the first A0-A7 pins are also marked D0-D7) of the MCU. At the moment I'm probing the outputs of the latch for A0-A7 and then the A8-A14 directly and using the last channel for the clock. My idea is to at least get a look at which addresses the MCU is looking at during powerup.

Quote
it jumps to "main" ROM C022 after load

In your post you say both ROMs are mapped to C000 - is this correct or is this a typo? And if it is correct, there must be a mechanism to switch the ROMs right before jumping to C022, correct?
« Last Edit: April 18, 2020, 06:06:15 pm by Rjevski »
 

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 528
  • Country: ru
Re: Extracting firmware from a HD63B03RP
« Reply #13 on: April 19, 2020, 04:16:45 pm »
Yes, the two regions mapped to the same C000 address are switched somehow (and there are some PORT1 bits manipulations before jump). But the boot rom looks like a standalone component, there are no function calls between it and the main rom. No need to load them both into the same disassembly.
I can be wrong about jump to C022, it’s a calculated jump to something+22 and both C000 and 6000 parts have entry points at +22, so it can be 6022 actually. But the C022 entry leads to a jump to 6022 pretty quickly, so it is not much difference which one you’ll choose for the start.
I’m sure about rom1 mappings described above - all those 3 parts have absolute calls from one to other and the call targets look sane with that mapping (a call from one part leads to a code sequence looking like a function start in the other part).
 

Offline Rjevski

  • Supporter
  • ****
  • Posts: 11
  • Country: gb
Re: Extracting firmware from a HD63B03RP
« Reply #14 on: April 19, 2020, 08:25:03 pm »
Thanks for the info. May I ask which disassembler you're using and how you're loading the ROMs into it (at the proper addresses)? Do you manipulate the files beforehand to arrange the regions at the proper address or is your disassembler able to let you remap regions of the ROM?

Also there is a IO multiplexer chip HD63B21P which I'm assuming is connected to the main CPU and probably manages the ROM mapping.
 

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 528
  • Country: ru
Re: Extracting firmware from a HD63B03RP
« Reply #15 on: April 20, 2020, 09:17:57 pm »
I use IDA, it allows to load the binary piece-by-piece at any desired addresses. But it is a bit too pricy for a one time project, I recommend to try Ghidra, it even has a decompiler (outputting C code) for 68xx.
HD63B21 is a memory-mapped parallel I/O port (so a few yet unknown addresses are directed to it) adding 16 gpio lines to the system.
Edit: HD63B40 (from your photo) is another memory-mapped I/O device (timer).
« Last Edit: April 20, 2020, 09:25:43 pm by abyrvalg »
 

Offline Rjevski

  • Supporter
  • ****
  • Posts: 11
  • Country: gb
Re: Reverse-engineering a HD63B03RP-based AES Prodata bus ticket machine
« Reply #16 on: May 03, 2021, 01:32:44 pm »
Bump (edited my first post with more details and questions).
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf