The Parallel Port Problem

Recently I was spending some time programming for Nintendo64 using a gameshark as a means to inject "homebrew" code on the system and have it execute. There exists a version of gameshark (v3.3) that has a parallel port built in that allows you to essentially read and write memory from a PC. The functionality is mainly there to help people create codes by searching for values and modifying them to fit their needs. Because I don't have a parallel port built into my laptop, and because USB to parallel port adapters are 99% of the time made specifically with printer functionality in mind, as well as the fact that even in these cases the software assumes you have a built in parallel port on your motherboard mapped to 0x378, I needed to find another way to use the utilities.

In the past I've made a few hacks for the gameshark "official utilities" that would allow you to use a port outside of the normal 0x378 range, and I've used this method in order to be able to use a PCI parallel port card with the gameshark software. The problem is this doesn't help out much for people running laptops with no built in parallel port. 

The gameshark uses a custom protocol through bit-banging, and it has been reverse engineered by HCS. He reverse engineered the protocol for the gameshark communications and wrote some software that would let him upload an NES emulator (NEON64) he wrote for N64 by using the parallel port on the gameshark. At some point I forked the project and added support in to allow it to work on most any game, during any time during the game. 

Recently HCS re-forked the project, so to speak, and turned it into something quite amazing. He found a USB to parallel port adapter that is actually capable of doing raw bit-banging, and he wrote a library for it using libusb and rewrote the gameshark homebrew loader (gsuploader) so that it could now use the USB to parallel port adapter, as well as adding a lot more functionality to the loader.  

At this point I had an idea to get the normal gameshark hacking tools to work with the library that HCS wrote and started on it. The original idea was overly complex and involved a bunch of patching, debugging calls, interprocess communication, code injection... I started to realize that I was going to have to do all of this stuff twice, because there are 2 "official gameshark tools." 

While writing the debugging functionality for the patcher though, I had an idea. I know that on newer versions of windows there's a permissions bitmap for each port, and it requires a higher CPU privilege in order to make use of some of the instructions. Namely the instructions I was interested in were "IN" and "OUT" respectively.  If you attempt to access the port with these instructions the CPU with throw a privileged instruction exception that gets passed to whatever exception handler is in place. By starting a debugging session on another program I was able to trap these privileged instruction exceptions remotely, and use the trap in order to remap where the data went that should have went to/from the parallel port.

By using this method it's insanely slow, but it does work. The overhead of USB for doing a 1-byte transfer makes the setup not quite as ideal as one would hope. One of the interesting aspects is that you could actually remap legacy software that usually uses the 0x378 range to ANY device (arduino, etc) by just rewriting the READ_PORT and WRITE_PORT functions that I've set up, but for now the simple program I wrote just uses the stuff that HCS wrote. 

It's just a demo for now since it's so slow, but if you're desperate and looking for a way to use legacy software through USB then there's a possibility that this might work for you. Keep in mind you'll need a MosChip 7705 USB to parallel port adapter for this software to work out of the box, but like I said before, you could adapt it to work with anything. 

*HCS: Website: (http://hcs64.com) | github: (https://github.com/hcs64)

*ppcasm: Website: (you are here...) | github: (https://github.com/ppcasm)

mappar: github: (https://github.com/ppcasm/mappar)

DEMO:  https://dl.dropboxusercontent.com/u/6458262/mappar_n64.7z

The demo works with Nintendo64 gameshark "n64utils" program. Just unzip, install libusb drivers through zadig, insert MosChip7705 based adapter, and double click the RUN_N64UTILS.bat file.

Mattel HyperScan Hacking Update - Part 1

This will likely be a multi-part series. So as people may, or may not know (likely the latter.) I have restarted work on an old project of mine that involves reverse engineering/hacking the Mattel HyperScan. I'm mainly going to make this post as a more comprehensive form of a document that I wrote and posted on a now defunct website. That document apparently got picked up on a few sites and made it's rounds on the internet as some sort of informational piece, when it wasn't really intended to be such. So hopefully this will work out better, since I have better foresight now.


What is a Mattel HyperScan?:

This has been gone over many, many times, so I'll keep this short. The Mattel HyperScan was (it is now defunct as of 2007) a system designed to allow users to play games (not many, mind you) while also feeding to the craze of game card collecting at the same time. The system used CD-based media, coupled with RFID cards that you could scan at key points in the game to achieve certain advances, and even save these advances back to the cards. It has some l.e.d lights, and USB, though the USB was never actually used in production. There are also 2 controller ports on the "front" of the console, as well as your usual composite video, and sound cable, and power input. 


Hardware:

From an outside visual glance of the system you wouldn't expect much, but internally there is actually some pretty interesting things. The system contains a Sunplus SPG290 SoC (System-on-a-Chip) which is part of the Sunplus S+Core series architecture. 

The SPG290 is capable of clock speeds of 162MHZ, but in the Mattel HyperScan production run models, the chip has been clocked to 108MHZ. The SPG290 has support for USB, I2C, SPI, UART, NAND/SD memories, NOR memories, PWM, GPIOs, ADC, video, sound, and more. 

There is actually an un-populated, yet labeled SD card and UART interface internal to the system. I had pictures of my current setup that I have wired to both of these interfaces, but as of now, they sit on a dead phone. There is a pin header at the bottom left of the board, This is JTAG, and if I'm correct, I believe the wiring goes something like below.

JTAG Wiring:

8 - GND

7 - JTAG_TRSTN

6 - JTAG_TDI

5 - JTAG_TDO

4 - JTAG_TMS

3 - JTAG_TCK

2 - RESET_FOR_IN_CIRCUIT_EMULATOR (tied to physical reset)

1 - GND

J9 (label)

The controllers are actually a bit interesting. They appear to use I2C, and have a wire used for arbitration, or rather, bus mastering. There also appears to be another line that comes out of the controller port that ties into physical reset. My theory here is that this is done in order to sync up the starting of the system, and the controller. 

The controller itself contains a SPC11122a MCU, which appears to be a SPC11128 series type MCU with 128KB of OTP (One-Time-Programmable) memory. If I have time in the future, I might see if there is possibly a way of dumping the ROM from the MCU in the controller. The controller also contains a Winbond W55AD808 ADC (Analog-to-Digital-Converter) that's used for translating the variable resistance from the analog joystick, and translating them over to a digital value that the SPC11122A can handle. Below I'll list a multiple view configuration of the controller pin-out.

Controller Pinouts:

controller male connector:

     3     4
   2    I    5  
     1  I  6

1:brown : GND
2:yellow : DATA
3:grey : CLK
4:green : ENABLE
5:blue : RESET
6:red : VCC 3.3v

Controller mainboard male connector port:

J1
1:brown : GND
2:yellow : DATA
3:grey : CLK
4:green : ENABLE
5:blue : RESET
6:red : VCC 3.3v

Analog joystick board:

1: brown : GND
2: red : VCC 3.3v
3: orange : DATA 
4: yellow : CLK
5: green : ENABLE

Analog joystick mainboard connector:
 ---
|x_x|
  |1|
  |2|
  |3|
  |4|
  |5|
  
1: red : VCC 3.3v 
2: brown : GND 
3: green : ENABLE : IOD2 on SPC MCU
4: orange : DATA : IOD4 on SPC MCU
5: yellow : CLK : IOD3 on SPC MCU

Analog Joystick:
X -> A0 on ADC
Y -> A1 on ADC

The ADC appears to communicate with the main SPC MCU through I2C. I've wrote a working driver for Arduino that can read the input from the analog stick itself and spit the result out through serial, and that is located @ https://github.com/ppcasm/ADCdriver

As far as communication goes from the SPC to the HyperScan, it appears as though it uses I2C too. It appears that when the controllers are being "polled", the "chip select" pins get arbitrated back and forth, effectively allowing reading input from both controllers. 

The video hardware does not do any sort of 3D acceleration from what I can ascertain. It does do basic frame-buffer access, hardware pallete support, sprite support, and a few other niceties such has hardware supported page flipping. 

In order to facilitate quick code testing while reverse engineering, I have implemented a programming system that uses a micro-controller, PC application, and an application that runs on the HyperScan itself that essentially turns into a quick deployment code testing environment. It works through the controller port. For more information on it, go here: https://github.com/ppcasm/HYCU

Video of it in action here (NOTE: It is not this slow; this was a testing phase!! Also, my antiquated laptop was being pushed hard. :p): 

The USB doesn't seem to be used, but I do know from my firmware reverse engineering endeavors on the device (probably will be in the next installment) that there is a "testing mode" in the firmware that appears to activate the USB into "Mass Storage Mode" when it's testing device mode. This leads me to believe that the firmware actually holds code to externalize an SD card hooked up to the internal interface, over USB, as a Mass Storage Device. 

I have a library that I'm still working on getting set up. So far this includes basic frame-buffer access functions, basic printing functions, l.e.d, as well as functions that work together with doing communications and protocol accesses. 

I haven't done much with RFID outside of patching games to write different values to the cards. I do have working knowledge of the sound, and video so far. 

I guess that's it for part 1. I'm not sure when I'll get around to part 2, but hopefully this will at least answer some basic questions about the system, as well as give a slightly more in depth view of the components at hand. 

Itron Centron C1SR Reverse Engineering Progress...

So, my previous blog post stated that this blog would essentially just be a progress log. So, here it goes. As of now I have the LCD stuff figured out, and even wrote a demo program (See picture in header) to play around with it. I've also found the ERT ID. The ERT ID is used to identify yourself on the power grid. Basically the way that this works (I hope) is that when the meter reader drives by, he's picking up RF packets sent out by this meter in the 910-920MHZ range, and part of the data in those packets is the ERT ID, this is a 26-bit identification number that would basically let the billing system know who used the reported usage. Your physical address would be tied to this number in their billing system. At this point I have a few payloads I've written that actually run on the meter itself. A few of those are, one to change the ERT ID, one is an LCD 7seg character driver, one is an external eeprom dumper that dumps through USART, and a few other small tests. Hopefully I'll have more to post about it the coming weeks.

Itron Centron C1SR Meter Reverse Engineering

I have started a project that involves tinkering with what some would possibly call a "smart meter", but I believe the proper noun would be an "AMR" or, "Automatic Meter Reading" meter. This project started mainly out of my curiosity in how digital metro-logy works, but also out of my curiosity in "smart grid" security in general. This project is in no way intended to commit "theft of service", nor help anyone else commit such acts. For obvious reasons, I don't plan on posting any intricate details on this blog, and all the code and tools I have wrote up to this point will be on a private git server until I decide when (if ever) I will make them public.

Metro-logy History:

Now, with that out of the way, I'm going to go over some quick history about utility meters in general so that people can have a general idea for why new meters are being developed. Most people remember the old electro-mechanical meters with the spinning dials. These generally worked by having a dial turn at varying speed, depending on how many kW/h (kilowatt hours) were being used, and this in turn turned other gears and gave a readout for a meter reader person to physically come on to your property to check. After this, some calculations were done based on the previous month numbers and they were able to determine how many kilowatt hours were used at your residence.

One of the downfalls of this type of meter was that it was time consuming, costly, and a bit of a hazard for a meter reader to have to physically get out of the vehicle and walk to each and every house directly. On top of that, some of the meters were designed with ferrous metals, which allowed a magnet to be placed on the front of the meter to slow down the spinning dial, which would report a lower kW/h usage, and thus rip the utility company off by cutting the price on your bill. Eventually they started to build the meters with non-ferrous metals, but there was also another "hack" which involved placing a meter inside the meter base inverted, or, turned upside down, which would sometimes cause the spinning dial to move backwards. This allowed one to "roll-back" their reported usage, and thus, again, ripping off the utility company.

Now, this is where AMR became practical. AMR uses a few different communication methods, usually they use either cellnet, ISM band unlicensed RF (radio frequency), and sometimes they even use newer technology like broadband over powerlines. The idea here is that the utility company can remotely gather utility usage information by driving by, or even have it sent to their sub station. These meters are usually digital in nature and this is the type of meter we will be focusing on with this particular project. The AMR meters are usually a one-way communication. Generally these meters just broadcast data at a specified interval for the meter readers to pick up on.

The "smart meters" came into existence mainly to build on top of AMR. Some form of AMR is usually built into every smart meter, but smart meters take it a step further. The smart meters usually allows the customers themselves access to the meter reading data, along with the ability to provide customers with a "time-of-use" utility pricing rate. This allows customers more control over when, and how they use utilities, and it allows "peak use" pricing. There are certain times of the day that put more strain on a utility system, and for this, they usually want to charge higher prices. This also makes it possible for people to actually save on their utility bill too by using this same pricing scheme. The way it works is simple, if it costs 10 cent for 1kW/h during the hours of  7am-5pm and it in turn costs 25 cent per kW/h from 5pm on to 7am and someone decides to use more during the 7am-5pm time, then they in turn save more money, as opposed to the utility company just charging the 25 cent at all times during the day. Smart meters also sometimes have more sophisticated functionality, but this is the bigger part of the idea.

Inside the Itron Centron C1SR:

First of all, Itron seems to have a few patents going on with their meters, and one of their ideas is to have boards built on top of their meter core. They usually call these add-on boards "personality modules". What this means is that if they happen to come up with a new module that a utility company sees fit to update to, all they have to do is change out the interchangeable personality module by just removing it, and the base and all of its components stay the same.

This meter core is under some pretty thick plastic, and is kind of hard to remove without breaking.

Meter Core:

The green thing you see in the picture is a metro-logy board, but I call it the motherboard.

Motherboard:

I'm still doing research on this board, but I have mapped out quite a few pins, but the main chip contains no public datasheet that I could find, so at this point, all I can do is speculate for the most part. What I do know is that the board connects by a "slip connector" over the pads (the ones in the far left of the picture).

What this board (likely) does:
Measure line voltage (Should be in the 240v range)
Measure reference voltage
Check energy flow direction (to make sure meter is not inverted)
Energy pulse data
Check line frequency (to make sure it's 50HZ, or 60HZ, respectively)

This board also has an IR LED (Infra Red Light Emitting Diode) that I suspect is used to calibrate the meter, because it seems to blink once for every 1 kW/h used. The way I suspects that this works is that they have an already calibrated "machine" that probably contains some sort of photo-diode that hooks to the top, and the machine draws exactly 1 kW/h of electricity, and the meter probably plugs directly into the machine, and it changes some kind of calibration setting in order to get the meter tuned in to reading 1 kW/h  precisely as 1 kW/h.

The motherboard communicates to the daughter board through the slip connector it seems. The daughter board seems to house most of the "main components".

Daughter-board Front:

Daughter-board Back:

Some of the main components on this board consist of an ATmega MCU, a serial SPI EEPROM, a JTAG header (more on this later), an inversion/shake sensor, and a few other things. The radio itself looks to use the sub-GHZ range, more specifically, the 910-920 MHZ ISM band range. The radio appears to use FSSS (Frequency Hopping Spread Spectrum) as opposed to DSSS (Direct Sequence Spread Spectrum), and I was in fact able to pick up some activity with a hacked IM-ME pager using the spectrum analyzer. On the back of the motherboard there is an LCD header, and what looks to be 4 pins. The 4 pins appear to be the endpoint connector for a "resetting  machine" that might, or might not, be able to reprogram the device also. What I do know is that the resetting machine is able to reset usage data, and tamper evidence data (more on this later too.) 

What is done so far:

Most of the processing is done on this daughter board, and with some soldering, and code that I've written, I was able to dump the SPI EEPROM, the main program flash, the internal EEPROM, and also re-enable the JTAG port, and also turn on on-chip debugging, as well as have write access to all of the above. I've mapped out where a lot of the hardware and external stuff physically connects on to the MCU. I've also done some reverse engineering on the code that actually runs on the unit, and have made my own code that runs on the unit in the form of a "hello world" that works by printing the text out of the UART port.

Hello World Demo:

I have also managed to build an exact copy of the original firmware into an assemble-able form so that I can readily use the IDE to step through the code with JTAG debugging enabled, and also so I can readily make any changes I see fit to the code without doing any "patching", which makes testing things a lot easier. For now, the rest of this aspect of the project is mainly just figuring out what the code is doing, and also looking for any major security flaws I can find. 

Security:

At this point, I'm not really in a position to be speaking on actual security of the meter, as there does not appear to be much. But as far as making headway on reverse engineering the system, I've been able to progress along pretty well. First off, one should know that there is in fact an external "security tamper seal" that you must take off in order to actually get into the meter. This seal is fragile, but with enough care, one could remove the seal, and also put it back on without much evidence left behind.

One of the other security features is the inversion/shake sensor. Apparently the way this works is that there is some contacts with what I assume to be a metal ball inside a canister. This is hooked to the MCU and is able  to determine if someone has shaken the unit, or turned it upside down. The shaking of the unit along with a power outage reports as a "meter removal", where as a no shaking power outage is registered as just a power outage. The inversion detection also taps on the tamper counter. All of these signals are transmitted over RF to the meter reader when they check your meter. One could just as easily do some wiring in order to trick the meter into thinking that it's always turned upright and is never shaken, but in order to do that, you would need to remove the meter itself, which would set off at least 1 tamper signal.

The tamper signal register looks to be 4 bits wide, and accounts for 0-3 tamper evidence counts on each tamper tag (meter removal, and inverted meter) it might be theoretically possible to bypass and reset these 2 tamper evidence counters if you know how many times they have been set off, and through some complicated form of using binary arithmetic in order to cause the 4 bit number to "roll over" by doing different wiring with the sensor and such, until both of them roll back to 0, and have the sensor wired to no longer detect any of the above ones afterward (remember, there is a difference between the shake/power out, and inversion, so the sensor would have to be temporarily wired to mimic both until they reset, unless the whole register gets counted, in which case you could use the lower or upper half of 2 bits in order to make it reset.)

The MCU and external EEPROM at this point do not look to be properly protected, as I've been able to read and write to both of the chips, as well as readily map out traces and such to find where they go. So far I have not found any major vulnerabilities (well, ones that I consider to be major), but the fact that I was able to figure any of this out, and get the code to the point that I actually have it able to be rebuilt into a modifiable code base, means that under physical attack, the meter isn't very secure (for what it's worth, I don't think Itron, or anyone else ever claimed that it was.)

And... Closing...:

I still have a bunch more to figure out about the meter at this point, I just thought I would make a post about it at its current stage, maybe there is some interest out there for this kind of thing, and there does not seem to be much information on these types of things. Hopefully I'll know more in the coming months and I'll be able to get to a point where I can program an IM-ME to be able to do meter reading functions, and other things, but, until then, I guess I'll have to just keep researching. :)