• The card reader

    PhaseSeeker10/22/2021 at 13:39 0 comments

    As I hinted in the previous log, I managed to score a card reader on an auction site!

    Here it is:

    This is what would normally fit in the smaller red box on the side of the phone (in the project photo it's on the right). Interestingly, the same reader module (along with the two-wire O.V. board, with a different firmware) is used in the Rotor 3.

    The device itself is pretty unusual as far as card readers go. The most obvious difference is the presence of two card slots; the one on the bottom is used only as an exit for the cards and there's a mechanism to prevent you from inserting anything in there.

    The differences don't stop here, as you can see from the top view:

    Circled in red is the first read head (note that cards are inserted "upside down", with the magnetic strip facing up); a photointerrupter (in green) is used to detect the presence of a card. A stop (under the section highlighted in yellow), controlled by a solenoid, is used to block the access to the rest of the mechanism unless a valid prepaid phone card is inserted. Note that ISO-sized credit cards are ALSO not allowed to go further into the mechanism, since they only need to be read by the first magnetic head once at the beginning of a call and do not need to stay in the reader (in fact, I suspect the entirety of the band is read only when pulling out the card, since the instruction specify to "insert it, then remove it quickly")

    If a prepaid card is inserted, the stop moves out of the way and the card is pulled around a rubber coated drum, which can be seen in the next picture (see now why they need to be flexible?):

    Around the drum, a series of photointerrupters (again in green) track the position of the card; there are also two more heads used to read and write data on the card; The drum itself is driven via a small motor (the cylindrical part visible at the bottom left of the first picture) and a long belt (which, unusually, is white-colored)

    This might seem like a whole lot of unnecessary parts, but you have to keep in mind that the original magnetic phone cards had the credit info written directly on them, with all transaction handled locally, so they needed to a) keep the card in the phone until the end of the call and b) change the card contents before giving it back to the user. They changed pretty soon to a remote verification of the cards, reading the card ID from the magnetic strip and then getting the credit info from a remote database, but the readers stayed the same AND still updated the credit info (probably for backwards compatibility with the readers still using the old firmware).

    The first readers built had an interesting "bug": putting a piece of tape on the magnetic strip, increasing the distance from the strip to the write head, was enough to make the write fail, effectively making the card usable for an infinite number of calls. This was fixed pretty soon, and the remote verification made it useless anyway.

    The last interesting detail is the presence at the bottom of a mechanism to snip one of the edges of a card (see the picture in the first post: the card is not rectangular) after the first use. This was done to prevent dishonest sellers from giving you a card that had already been used.

    After playing with the mechanisms for a bit, I turned my attention to the board:


    As you can see, it's got the same HD6305Y2 MCU, a 27C256 EPROM (already removed in the picture) for the code, and a ST chip I could not identify (which is hooked to the CPU bus); under the copper shield, a ceramic module houses the analog circuitry for the three magnetic heads.

    I already dumped the ROM, but without knowing what the mistery "ICWA B22HB9431" chip does I can't fully reverse engineer the code, since it's mapped in memory and thus directly accessed; I still have a lot of code to go through both in this ROM and in the main phone ones, so there will be an update in the future about the code.

  • A bit of an update: new schematics, new parts, and a fix for the decompiler

    PhaseSeeker10/16/2021 at 19:50 0 comments

    I finally found some motivation to start tracing the missing boards (EAGLE files are in the "files" section of the projects).

    The CPU board

    I started with the CPU board:


    A few observations, in random order:

    • Connector CNA has MCU I/O ports A, B and C plus interrupt and standby signals
    • The "mistery" SCL1054-V4 (U3) chip directly hooks up to the MCU's data and address buses
    • CNB has input port PORTD and a bunch of signals from U3

    The first thing that caught my attention is that the MCU's address and data buses are not exposed to the main board, as I would've thought based on the number of pins on the connectors. How are the external RAM and the config ROM connected to the system then? I was a bit puzzled, but I figured it'd be more clear once I looked at the other boards.

    I then started looking into the address decode logic, since I needed to know where the ROM was mapped in the memory space to decompile the code. Looking at the Hitachi manual, here's the basic memory map:

    So, the available range for ROM and/or other memory mapped devices is 0x0140-0x3FFF (plus a tiny slice from 0x0020 to 0x003F). Here's where things get bizarre again:

    First of all, U3 can disable the ROM through IC1B (or, on boards where the three 74xx series chips are missing and J1 is installed, can control the ROM directly). This is somewhat strange but not totally unexpected, so I moved on. Then I found another problem: if you follow the schematics, you'll see that the chip enable output from the CPU (which is bizarrely active HIGH) is totally ignored by the ROM selection logic and only routed to U3. I checked the Hitachi manual and in the section about connecting an external ROM (PDF page 227, section 3.1.1) it shows a schematic which completely ignores the !CE and !OE pins, so either the internal data bus buffer goes HI-Z automatically when accessing internal RAM/registers (which would make sense, since the diagrams show that there's indeed a buffer), or they put some extra decode logic inside U3 to deselect the ROM when needed.

    What really confused me (and I still can't explain) is that the only address where the onboard selection logic (IC1, IC2 and IC3) explicitly deselects the ROM is 0x1FFF; if you check the Hitachi manuals again, you'll see that the reset interrupt vector is stored in ROM at 0x1FFE-0x1FFF (it's a 16 bit pointer to the address of the first instruction to execute, stored big endian), so I really don't understand why you wouldn't want the ROM to be selected while reading that.

    The RAM board

    With these discoveries, I moved on the RAM board:

    This section here is pretty straightforward. ROM and RAM share the same address and data buses, both of which are exposed to the main board through the only connector present (only address lines A1 to A8 seem to actually be in use, but A9 to A12 are still present on the connector). There's some 40xx series logic that selects the two memory chips (interestingly, they're toggling the !CE line and not the !OE line to select the chips, as they do on the CPU board; this works, but I've usually seen it done the other way round), with the inputs connected to some signals I haven't yet identified (perhaps some kind of bus, since there's a resistor array connected to the four lines?). A small lithium cell is connected to the RAM to retain the data even without power, and an Intersil ICL7665 is used to alert the system when the battery runs low.

    This still does not solve the problem of "what is this memory hooked up to?", though, so I started looking at the main board

    The main board

    I'm still working on the main board (there's a lot more stuff going on there), but I've traced enough of it to find out where the RAM board connects to; if you've looked at the CPU board schematics carefully, you probably already found the answer: it hooks up to the SCL1054-V4 chip, through a second set of address and data buses. This, combined with what I already knew from tracing the other board,...

    Read more »

  • Decapping time

    PhaseSeeker10/01/2021 at 20:50 0 comments

    Even before attempting to reverse engineer all the code (I still have to trace the CPU board; I've been pretty busy recently and motivation's been kinda low), I knew that things would be a lot harder if I can't find out anything about the mystery suspected-to-be-modems chips.

    Since I have a number of them (I have a lot more CPU boards and main boards than line interfaces), I tried decapping the chips, in the remote hope to find some more information one the die (like a non application specific part number).

    I used the hot air method to extract the die, which basically consists in heating the plastic packages with a high temperature heat gun until they become soft and then breaking them with pliers. As strange as it sounds, it works (see (13) Chips a la Antoine: an IC chip de-capping recipe without chemicals - YouTube for an example)

    Here's the a picture of the decapped chips:

    (PLCC package SCL1054-V4 on top, "wide" DIP package Italtel v7308 on the bottom)

    Unfortunately, I found out that I do not have a good enough microscope to really analyze these, but I managed to find something interesting inside the SCL1054-V4

    An RCA logo and part number! Unfortunately, this also brings up no results. I guess I'll have to resort to analyze the software to understand what these chips do and why.

    This is as far as I've gotten for now. I really need to trace the remaining boards and to start working on the software. I do know a bit of 6502 assembly, but I've never really done much assembly programming before, let alone reverse engineering on already written code, so this is probably going to take a while. Also, as said before, I'm missing some info on the internal wiring (mainly about the electromechanical actuators and sensors wiring) so I'm a bit stuck on that front.

  • The software

    PhaseSeeker10/01/2021 at 20:37 0 comments

    As I said in the previous log, I decided to take a break from schematics drawing and to look at the software; I chose to start with the ROM from the Rotor 2 board, since I was reasonably sure that it contained card reader interfacing code and since the board is less integrated and easier to probe if need be. I'm not sure if I can post these here; after all, it's still copyrighted code (but then again, with almost no payphones remaining at all, who would care? )

    The first problem I encountered is that the Hitachi HD6305Y2 is not a popular MCU, so there's very little information about it. I managed to find the original Hitachi handbook (http://bitsavers.trailing-edge.com/components/hitachi/_dataBooks/1988_U08_HD6305_Series_Handbook.pdf), but no disassembler or compiler.

    This didn't leave much options: if I wanted a disassembler, I had to write one myself. Luckily, the popular reverse engineering tool Ghidra does offer the possibility to add a new architecture. The process is not all that well documented, but luckily I found a Reddit post which explained it pretty well (see https://www.reddit.com/r/ghidra/comments/ba09tk/documentation_on_adding_new_processor/ ). I copied some stuff from the files for the already supported processors and, with the help of the provided SLEIGH documentation (https://ghidra.re/courses/languages/html/sleigh.html) I was able to write my own processor module (you can find it here: https://mega.nz/file/CDQD3SwT#_zkjB--d8NPhUFaqIKVJzupw02vo9lRbekrEkIG6EP4 but there's no guarantee it's error-free).

    So, I imported the ROM files into Ghidra, aaand:

    Yeah, it's full of errors. I tested the disassembler on a fake ROM i made that contains all the instructions the processor supports in sequence and it recognizes and decodes them correctly, so I strongly suspect this is just due to me not starting the disassembly at the right place in memory (I just dumped the whole ROM from start to end). I need to check the address decode logic on the CPU board to really understand what addresses contain code and what don't.

    Just for fun, I imported the Z80 ROM:

    This already looks better, AND it looks like they're using one of the MCU serial ports as a debug port, as seen in the highlighted strings.

    The next step will probably be tracing the CPU board to get the memory map of the processor, so that I can atleast confirm I'm trying to disassemble code and not random data.

  • The schematics

    PhaseSeeker10/01/2021 at 20:13 0 comments

    The first thing I did after dumping the ROMs (since I was very worried they could start to lose data due to UV exposure and age) was trying to trace the schematics for all the boards.

    I started with the older "Rotor 2 4 fili" line interface board; I just went component-by-component, marking each pin I had traced to another component with a marker while writing the schematics on paper. Since I had two almost identical boards (they are a different revision, but have almost the same schematics and the component designators match), I just kept one with the component side up and one with the trace side up to speed up the process.

    As I was getting to the end of the process, it dawned on me that the method I had used meant that I could have missed some traces (because I marked a pin as "traced" as soon as I reached another component instead of following every single trace); also, there's a couple of relays and coils that. being (almost) direct shorts, could have led to errors.

    Since I had two boards and no phone to put them into (you either find complete phones or ones that have been "converted" and are missing all the mechanical parts), I decided to just strip the most beat up one of all the components:

    Front
    Back

    I then went trace-by-trace, marking each one of them with my trusty marker and cross checking with the schematics I had already drawn. After much tedious work, this is what I was left with:

    (the red lines are all the missing traces/mistakes I found after redoing all the work with the stripped board)

    I still need to redraw this in Eagle, but I put that off temporarily when I realized this board does not contain the stuff I'm interested in (data communication circuitry and/or the card reader interface)

    I then went on to investigate the content of the big potted module at the bottom of the board, thinking it might contain something interesting (after all, why would they pot it otherwise?). After spending much time with paint thinner, boiling water and various razor blades (didn't take any photos of that, sorry), I was left with a bag of broken components

    and most importantly a schematic:

    Turns out the module is a transformer-based switching power supply, used to charge the battery. Knowing this, the most logical possibility left is that the modem circuitry is all in the mysterious IC on the CPU board.

    A bit disappointed that I didn't find anything really useful for my purposes, and sick of tracing PCBs, I decided to went on to track the software part; more about that in the next log

  • The PCBs

    PhaseSeeker10/01/2021 at 14:10 0 comments

    As said in the previous log, I managed to get my hands on a bunch of PCBs from the Rotor 2.

    Here's the whole lot:

    Aside from some ceramic modules which were broken in shipping (the eBay seller crammed all the boards in a much smaller box than this, with almost no padding...), the boards appear to be complete and in good condition.

    I had a good look at all the stuff I've got (and at all the eBay auctions I could find that included photos of the internals) and I've got to say that the phone is a lot more complex that I anticipated.

    There are four boards inside each phone:

    1) The "line interface" board:

    As the name suggests, this contains all the circuitry that interfaces the phone to the phone line(s). The section on the left, with the LS356B, is the actual "phone" part of the device. The connector marked as "a" connects to the keypad and the hook switch, while the RJ45 connector plugs into the headset.

    The green two-pin connector connects to the integrated  6V lead-acid battery, which is recharged from the line and is used to power all of the internal components. This is presumably done to provide the short bursts of high current needed to power the electromechanical components (remember, the phone is spec'd to draw a maximum of 30mA from the line); it's wired like a double-conversion UPS, with all of the phone always drawing power from the battery.

    Connectors D and possibly C seem to be used to connect to the internal/external coin safe, to enable the phone to know if the safe is opened/removed or simply full.

    Connector B is used, alongside a normal 40-pin ribbon connector, to link the line interface to the main board.

    The black box marked "64357/A", which I initially suspected to be the data modem, is actually the buck converter that provides the 6.75V for the battery.

    2) The main board

    This board is housed on top of the mechanical section of the phone and interfaces both to the line interface (through the 40-pin connector on the right) and to the mechanical section itself (with the big connector on the right).

    The actual CPU board plugs in with the two circled connectors, while the single white connector on the bottom is used for the configuration memory.

    This board contains a bunch of 74-series logic and a number of ceramic modules (which I think are DC-DC converters)

    3) The CPU board

    As the name implies, the CPU board houses the microcontroller that runs all of the phone, an Hitachi HD6305Y2. Luckily for us, this variant of the MCU has no internal ROM and it exposes its address and data buses to the outside world; the code is stored in a 27C256 EPROM which plugs in the DIP socket on the right. I've already dumped the ROMs and I currently have two variants, one simply marked "Rotor 2" and the other "Rotor 2 + L.I. v1.11" (L.I. probably meaning "lettore interno", "internal [card] reader")

    The chip on the left is however a bit of a mistery. It's got what seems like a valid National Semiconductor part number, but I can't find any information about it. I suspect this is the actual modem chip I can't find any digital circuitry on the line interface board complex enough to be a modem.

    4) The "external RAM" board

    This board, as the name implies, houses a battery-backed RAM chip used to store configuration data. Contrary to what it might seem, the big DIP chip visible in the picture is actually a 27C64 EPROM; the actual 2K x 8 RAM chip is housed under the ROM.(it's a really weird DIP socket with the pins that taper out, allowing you to house ANOTHER similar-sized chip under the socket).

    There's also an Intersil ICL7665 chip used to monitor the battery voltage and alert the processor if it gets too low.

    4) Mistery board

    I have no idea what this board is used for; I also haven't been able to spot it in any of the pictures of the phone internals I found on the Internet.

    It seems to plug into the line interface board using the connector on the bottom right, but again, I have no clue what it is supposed to be.


    It also seems like I'm actually missing... Read more »

  • Introduction

    PhaseSeeker09/29/2021 at 16:55 0 comments

    Reading through old Italian phreaking e-zines and websites (see https://www.autistici.org/hacking_e-zines/ for an archive and the s0ftproject website http://bfi.s0ftpj.org for their e-zine, BFi, which was even mentioned on Phrack),  I was always fascinated by the Rotor, mainly because it put a stop to all known tricks to get free calls and at the same time introduced a whole load of new features to prevent new attacks (bi-directional data link to the phone exchange, electronic coin discriminator, magnetic strip-based prepaid phone cards).

    Brief history of Italian public phones

    From the '60s up until the end of the '80s, the public payphone in use pretty much everywhere was the Urmet U+I ("Urbane+Interurbane", Italian for "Local+Long distance"); this was a simple electromechanical payphone whose operation was based on a solenoid and a series of microswitches. While there were some tricks put in place to prevent tampering (like subtle modifications to the lines they worked on to prevent people from simply hooking their own lineman's set to them), over the years a number of hacks, both electrical and mechanical, were discovered. While I can't say for certain which of them worked and which were fake, it's pretty clear that the phones were far from unhackable.

    In the '80s, some of the old U+I were replaced with an improved model, the Urmet G+M ("Gettone+Moneta", "Token+Coin"), which as far as I know still worked in a very similar way, at least in regard to the way it interfaced with the phone line. The main differences were three coin/token slots instead of one (allowing the usage of coins alongside the usual tokens, as the name implied), a series of buttons to allow the user to input the number to dial (it still used pulse dialing, though, as all phones up to the Digito did) and a display to show the remaining credit; I suspect they had to add some kind of MCU to keep track of the different coin values anyway so they threw in the display just as a bonus.

    By the end of the decade, however, it was pretty clear that these phones were pretty much obsolete. They had limited functionality, known flaws, and they fact that they stored quite a lot of coins meant that they were a popular target for thieves. To mitigate those issues, SIP (the Italian phone company at the time) commissioned IPM a new payphone; the initial plan was to create three new models, one for use with coins and tokens, one for use with the new phone cards (more on that later) and one for use with credit cards, but then they changed their mind (probably because they realized it meant building close to 3x the number of phones), and all the features were merged in a single new phone, the Rotor.

    The Rotor

    The phone itself is quite a feat of engineering. Weighing in at 32 Kg (approx. 71 pounds) of cast iron and fitted with an Abloy disc detainer core, it was quite resistant to brute force attacks. The mechanical coin acceptor was improved from the previous phones, with features such as an S-shaped tube at the beginning of the coin path (to prevent people from poking at the internals), a shutter with a blade (to prevent the old "coin on a string" trick), an electronic coin discriminator able to measure size, weight and metallic composition (the last one probably using inductive sensing) and a 20-pocket rotor (giving the phone its name) used to store coins until the end of the call.

    On the electronics side, aside from a microcontroller which runs the entire device, it was equipped with a modem/transceiver enabling bi-directional data transfer between the payphone and the exchange using the HDLC protocol; this was used both for signalling purposes (it enabled the phones to alert the phone company of things like faults/tamper attempts/coin safe full) and to check the validity of phone cards and credit cards. It also offered some sort of remote configuration option.

    (all the info here is either from the e-zines mentioned before or the Spaghetti Phreakers Cookbook...

    Read more »