PoC or GTFO, Volume 2

by Manul Laphroaig

  Following these instructions, with enough time, patience and abstinence, you’ll be able to make your own legitimate-looking pregnancy test that works on men and women alike! Or jazz it up to say “HI MOM” in no time.

  Teardown

  To open the case of a digital pregnancy test (DPT), take a nickel or quarter, place it in the detent in the injection molded case, and gently twist. The model of DPT I did most of my work with was the generic “CVS Clear Results” test. The mechanical specifics may vary from brand to brand, but the nicest part of the cheap injection-molded plastic is that the shell parts are universally thin-walled and toleranced to snap-fit together, which makes it easy to snap them apart without visibly damaging the case.

  Inside that case, there will be a circuit board that has another multi-piece injection-molded assembly of ABS plastic, press-fitted into mounting holes on the PCB. This is the test strip alignment/ejection mechanism.28 For my purposes, I removed this semi-destructively, by twisting off the retention pins on the back side of the PCB. I wanted to save the housing for when I rebuilt the test with my own internal electronics, to be virtually indistinguishable from the stock pregnancy test but with added entrepreneurial functions. This strategic re-use of injection molded parts and hard-to-design mechanisms adds that special professional flair to demonstration prototypes.

  Once you’ve got the holder off, you’ll uncover an activation switch and the analog optical sensor (made of two photodiodes and three LEDs), a PLL (used only for its voltage-controlled oscillator) IC, the Holtek HT48C06 microcontroller, a 3V battery and a custom LCD. You can either look up the battery type to confirm it’s 3V, or just read the CE-mark label on the outside of the DPT that lists the part number, lot data, confirmation that this test is made by SPD GmbH out of Geneva, Switzerland (made in China), and that the test runs on 3V DC. Safety first, kids. Also convenient: if you peel up this label, you’ll see holes in a pattern of the case that line up with un-tinned pads on the PCB. These are the calibration and test points for the Holtek, which means if you prefer firmware reverse-engineering to hardware reverse-engineering, you can go fiddle with the insides from the outside.

  By the by, that label isn’t tamper-evident. You can easily replace it, but don’t get any ideas!

  Schematic

  Flick the little button, and you’ll see the whole test light up. The LEDs strobe, the LCD thoughtfully blinks its “thinking” icon, and a scope or DMM will show plenty of pin activity until the test errors out because you just set it off without a valid test strip. I could have started probing there, but I realized that an optical test requires a dark environment, and I wanted to bring my test wires out through the conveniently placed unit-test-and-programming holes on the case. My ultimate goal was to test the unit under multiple conditions to determine the internal logic. That meant making a schematic.

  I don’t enjoy tracing out circuits with dark soldermask, and the DPTs are relatively cheap, so I gathered up the pinouts for each IC and then did my physical net trace using graphic design tools.

  Step 1. Desolder all components from the PCB.

  Step 2: Scrub the pads with solder wick to get them nice and flat.

  Step 3. Using a razor blade or fine-grit sandpaper, sand off the soldermask with loving attention on both sides of the PCB.

  Step 4. Scan the PCB with high contrast.

  Step 5. Import the scans into an illustration tool of your choice. Color code the top and bottom scans to match your preferred layout scheme. Drop circles on the vias—first. Then add the IC and passive pins. Then add your traces. Use the vias to register the two images on top of one another for a single layout trace.

  Step 6. Annotate the trace with the reference designators from an intact PCB. Add your own net names and pin labels. Use this to build a reference schematic.

  Let’s Skip the Firmware

  Let’s walk through what this sweet little circuit is up to.

  First off, the Holtek micro is always on, albeit in sleep mode. The battery is sized for the shelf life of the device plus a couple of uses (three strips ship with each one). When a test strip is placed in the tester, it mechanically triggers the switch which a) flags an interrupt to the microcontroller to wake it up out of sleep mode and b) enables power to the PLL and sense circuitry that would not otherwise be powered. If you remove the test strip mid-test, it cuts power to the PLL and the micro will error out, making it a bit of a pain to work with. Meh, meh, power-saving feature and fault reporting during foreseeable misuse.

  Once all supplies are up, the Holtek samples the state of the optical sensor four times a second for twenty iterations, averaging the samples. In order to sample the test strip, the Holtek drives the LEDs and then reads back the output state of the photodetector, using the voltage-controlled-isolator (VCO) sub-function of that phase-lock-loop IC. The role of the VCO is to convert the analog voltage from the photodetector into a square wave for easy edge counting. Higher voltage implies a higher frequency of edges. Because the micro controls the LED excitation timing, it can easily tell by edge counts what color test strip the LEDs might be illuminating. It’s pretty nifty.

  Because I wanted to build new electronics to fit inside the case of the original DPT and reproduce a function similar to the original hardware and firmware, I dove into the deeper specifics of how the DPT detects whether one or two blue stripes show up in that plastic clear-view window. The secret is stereoscopic vision enabled by time-division multiplexing and the physical layout of the optosensor. The three LEDs are interdigitated with two parallel photodiodes that are the base current sources in a PNP common emitter amplifier (D4, D5, Q2). The Holtek enables each of the 3 LEDs (D1, D2, D3) sequentially using a 25% LOW duty cycle waveform at 10kHz. The LEDs are strobed in a round-robin fashion and the Holtek samples the result via the VCO.

  When any one of the three LEDs is strobing, the induced current in the photodiode causes the filter cap on the output of Q2 to charge. The LED’s light causes charging, while discharging occurs while the LED is off. Because the Holtek excites the LEDs intermittently, the output of the photodetector is a sawtooth wave. The period of the sawtooth is the LED drive interval, while the peak and trough of the sawtooth wave correspond to the colorimetric intensity of the test stripe that appears and/or the amount of mis-alignment between the photodetector and the LED array.

  But how does this produce stereoscopic vision, you ask? For the same background test strip, when D1 is on, the sawtooth peak-to-peak amplitude will be different than when D3 is on, giving the sensor some ability to resolve spatial light sources. Because the LEDs are independently addressable, it also means that the Holtek can discriminate between a colored stripe hanging over D5 (stripe #1) versus one hanging over D4 (stripe #2).

  Also, all apologies for the fact that the reference designator order for the diodes makes no physical sense. It’s not how I’d design the board, but it apparently took eight revisions for the manufacturer to get this far.

  Schrödinger’s Rabbit

  Okay, so if you’re pregnant, it works like this.

  Just kidding, folks—here’s what the DPT is doing.

  Photodetectors

  Test Stripe

  D3

  Dl

  D2

  STI

  ST2

  PREGO

  L

  H

  L

  CNTRL

  PREGO

  CNTRL

  L

  H

  H

  CNTRL

  …

  ERROR

  H

  H

  L

  …

  PREGO

  BLANK

  H

  H

  H

  …

  …

  Remember that a high PD voltage implies more edges counted by the Holtek per excitation cycle. The Holtek uses this and sequencing to tell if you’re pregnant. Based on the chemistry of the test stripe, the test expects the CNTRL s
tripe to fire first. If only the CNTRL stripe fires—congratulations, you aren’t pregnant! Again, due to chemistry, the PREGO stripe ought to always fire second, if at all. If the stripes fire out of order, that’s an error. If the PREGO stripe fires but the CNTRL stripe doesn’t, that’s an error. If no stripe fires, that’s an error.

  The factors that contribute to setting the DETECT vs. NO-DETECT threshold for “how many edges do I expect to count if the rabbit died” are (1) the distance from each of the three LEDs to each of the two sensors, (2) the intensity of the LEDs, (3) the color of the LEDs (as that corresponds to the sensitivity of the sensors for a given wavelength of light), (4) the placement of the stripes (if they appear) with respect to the two photodiodes, and (5) the color of the stripe and the saturation of the stripe. Because process controls on LEDs are fucking horrible, each test has to be individually calibrated after assembly.

  But that’s good news for us!

  Hands-On Hacking

  Let’s be honest, you don’t want to come up with a new set of guts to shove into the case of a digital pregnancy test relabeled OxBEEF and OxCAFE for maximum entertainment and confusion to potential investors! You just want to have fun with the available raw materials that God and your local drugstore have provided.

  Each element of the LCD for the digital pregnancy test is custom, just like an old Tamagotchi. That means one pin polarizes the layer with the test logo artwork on it. A second layer covers “SEE LEAFLET” for reporting error states, a third conveys “NOT” and a fourth, “PREGNANT.” A given layer is active when the phase of the drive pin is 180 degrees out of phase with the COMMON pin.

  So, let’s go through the pins that make this happen. Pin 1 is the common pin, against which the segment pins are pulsed to light a given segment. Pin 2 lights the word “NOT”, pin 3 “PREGNANT”, pin 4 “SEE LEAFLET”, and pin 5 lights the logo.

  Pin 1 is the rightmost pin if you’re looking at the LCD face and the pins are at the top of the package, opposite the reference designator. Make sure to not just short pins—you actually have to lift and move any pins you might be interested in swapping around. Cut a wire here, tack in a jumper there. Mix and match, and get ready to have a ball! Dance a jig! I mean, shoot, a fella could have a pretty good weekend in Vegas with all that.

  At the time I was doing this work, the Holtek micro wasn’t available for purchase from Digikey or Mouser, so in a fit of intellectual incuriosity, I didn’t bother to crack it. I can’t give you any information on its internals other than what I’ve inferred from reverse-engineering the rest of the circuit. I’d love to see it done, though—just because the programming physical interface is obfuscated in the primary datasheet doesn’t mean it’s impossible. If I were doing this twice, I’d start with the ICE. The correct ICE tool for the job, assuming you’re into that, is the CICE48U000006A. In the interest of speed, I based my redesign on a PIC16F1933 and a character LCD that fit nicely in the same window as the original.

  The demo worked, but I never got paid. So, demo code and hardware design files are available for any neighbor who wants to buy me a beer.

  Cheers!

  –WOz

  10:7 A Brief Description of Some Popular Copy-Protection Techniques on the Apple ][ Platform

  by Peter Ferrie (qkumba, san inc)

  Ancient history

  I’ve been. . . let’s call it “preserving” software since about 1983, albeit under a different name. However, the most interesting efforts have been recent, requiring skills that I definitely didn’t have until now: I am the author of the only two-side 16-sector conversion of Prince of Persia,29 the six-side 16-sector conversion of The Toy Shop,30 the single file conversion of Joust, Moon Patrol, and Mr. Do!, as well as the DOS and ProDOS file-based conversions of Aquatron, Conan,31 The Goonies, Jungle Hunt, Karateka, Lady Tut (including the long-lost ending from side B), Mr. Do!, Plasmania, and Swashbuckler, to name a few. I am also the only one to crack Rastan cleanly on the IIGS, just twenty-five years late.32 Yes, I do 16-bit, too.

  I’ve spent thirteen years writing articles for the Virus Bulletin journal. My faithful readers will recognise the style.

  Isn’t it ironic

  4am declined to write this document himself, but his work and approval inspired me to do it instead. Since his collection is so varied, and his write-ups so detailed, they served as a rich source of information, which I coupled with my own analyses, to fill in the gaps for titles that I don’t have.33 Everyone knows already that he’s funny, but he’s also quite friendly and very generous. Together, we corrected a few mistakes in the write-ups, so I gave something back. I even consider us friends now, so I think that I got the better deal.

  While I don’t regret writing this paper, I do have to say that, considering the time and effort that it required, he probably made a wise decision. ;-)

  I have tried to associate at least one example of a real program for each technique, but in §10:7.12 you’ll find some nifty new protection techniques that I’ve developed just for this paper.

  Why why why?

  Why the Apple ][? It’s because I grew up with the Apple ][, I learned to code on the Apple ][, I know the Apple ][.

  Why now? Because the disks that were fresh when the Apple ][ was modern are failing, and if we do not work to preserve them now, some of the titles will be lost forever.

  This paper is dedicated to anyone who has an interest in helping to preserve what’s left. I sincerely hope it may help to recognise and defeat the copy-protection that they have come across.

  Okay, let’s split

  We can separate copy protection into two categories; they are either What You Have or What You Know. What You Have protections are generally protected disks, while What You Know protections are generally off-disk, such as requests to type in a word from the manual.

  What You Know protections come in several forms. One is an explicit challenge with immediate effect; you must answer now to continue. Another is an explicit challenge with delayed effect; if you answer incorrectly now, the game becomes unplayable later. Yet another is an implicit challenge; in order to proceed, you should perform an action as described in the manual, but the game will appear to be playable without it.

  Infocom were infamous for their use of all three:

  Starcross issued a direct challenge with immediate effect, and you could not even leave the second room without typing the correct co-ordinates from the star chart.34

  Spellbreaker35 issued a direct challenge with delayed effect, along the lines of “name the wizard who. . .” Any name from their word list is accepted, but an incorrect answer results in the player receiving the wrong key. This key cannot unlock a critical door much later in the game, causing the character to be killed instead.

  Border Zone made use of an implicit challenge. It required reading the manual in order to know the correct words to excuse yourself Oopzi Dazi!36—after bumping into someone, in order to establish contact with the friendly spy. Failure to make contact within the allotted time ended the game.

  Brøderbund’s Prince of Persia had a variety of delayed effects, depending on which of the several copy protection checks failed. One of them included crashing immediately before showing the closing scene upon winning the game. That is, after completing fourteen levels!

  However, the What You Have protections are more interesting, given the vast number of possibilities.

  Accept your limitations

  The first important component that we will consider in the Apple ][ is the MOS 6502 or 65C02 CPU. These CPUs have no separation of code and data. That is, they are a Von Neumann, not Harvard architecture. All memory and I/O addresses are executable, and everything that is not in ROM is writable, including the stack.

  Since the stack is writable directly, it introduces the possibility of tricks relating to transfer of control. (§10:7.6.) Since the stack is executable, it introduces the possibility of hosting code. (§10:7.10.)

  The CPU has no prefetch queue, only a single p
refetched byte of the next instruction,37 as the last stage in the execution of the current instruction. This introduces the possibility of self-modifying code, including the next instruction to execute, because any memory write will have completed before the prefetch occurs. (§10:7.7.)

  Lay it out for me

  The second important component that we will consider in the Apple ][ is the Disk ][ controller. The Disk ][ controller is a peripheral which is placed in a slot. It exposes an interface through memory-mapped I/O, so the various soft-switches can be read and written, just like regular RAM. The interface looks like accesses to $C0sX, where s is #$80 plus the slot times 16, and X is the switch to access.

  The Disk ][ controller runs independently of the CPU. Once the drive is turned on and spinning the disk, the drive will continue to spin the disk until the drive is turned off again. The drive rotates the disk at a fixed speed—approximately 300 RPM, and five rotations per second, which works out to be 200ms per rotation. However, the speed varies somewhat from drive to drive. For 5.25" disks, the data density is equal across all tracks. At 300 RPM, each track holds 50,000 bits, which is equal to 6,250 8-bit nibbles.

  The data on a disk is simply a stream of bits to be read. For a 5.25" disk, those bits are usually gathered into 16 sectors of 256 bytes each, spread across 35 tracks—256 × 16 × 35 = 143, 360 bytes, or 140kb. When reading from a disk, the Disk ][ controller shifts in bits at a rate equivalent to one bit every four CPU cycles, once the first one-bit is seen. Thus, a full nibble takes the equivalent of 32 CPU cycles to shift in. After the full nibble is shifted in, the controller holds it in the QA switch of the Data Register for the equivalent of another four CPU cycles, to allow it to be fetched reliably. After those four CPU cycles elapse, and once a one-bit is seen, the QA switch of the Data Register will be zeroed, and then the controller will begin to shift in more bits. As a result, programmers must count CPU cycles carefully to avoid missing nibbles fetched by the controller.