Lab 10: What's in Your Wallet?

In this lab, we will feed the asynchronous RS-232 serial datastream from the card reader and associated translation hardware into the computer to efficiently read magnetic information off of various cards.

If the work from Lab 9 is done correctly so that you have valid RS-232 frames (packets) coming out of your circuit, then this lab may go very smoothly. It is worth being absolutely sure that your packets are exactly as they should be before proceding.

The Actual Lab

The program complexity being what it is, it is unreasonable to expect you to hammer it all out on your own. So the task is simplified for you by including various snippets below, but you are left to fill in some blanks and rearrange parts of the snippets appropriately so that they will work. This means moving #include statements to the top, declarations all to the same place near the top, and watching out for loop boundaries.

In each of the snippets, a few things have been left for you to figure out. These are all marked with XX (upper case). It's like an easter egg hunt: find all the XX's and put in the appropriate thing.

You may find it useful to refer to the the magstripe documentation for the 5-bit and 7-bit codes, etc.

Lab Procedure

  1. Start with the program outline, into which the rest of the functions will go. Remember to look for XX as a signal that you need to insert information. Comments are guides as to where to put things.
  2. Add in the serial open and configure snippet. Be sure to place the #includes at the top of the file.
  3. At this point, if you add the two lines: char sInBuff[51] = {0}; and DWORD dwBytesRead = 0; in the type definitions section,you should be able to compile the program. It's a good idea to do this early to clear up any problems before getting in too deep (a larger program is harder to debug). You should also be able to run the program from a DOS window, and it should hang and do nothing until you hit the <Enter> key.
  4. Now add the n_bits and mask part, again placing the constituent parts in the appropriate place within the file. Compile and run as a check that it works, perhaps printing n_bits to verify that the command line argument is working. Remember that if you want to print anything, you'll need <stdio.h>.
  5. Add the input and masking code, being careful not to replicate existing pieces of code that might already be in your working version. Again, you should be able to compile and run to make sure no errors were introduced.
  6. Add the parity accumulation code, again compiling to verify no mistakes.
  7. Add the LRC accumulation code, checking that it still compiles when done.
  8. Add the string processing code, checking that it still compiles when done.
  9. Now add the final output code, checking that it still compiles when done.
  10. Check to make sure you have the wrap-up code, which you may have from previous steps. Make sure all opening and closing braces are present in the right way (almost certainly true if you've been able to compile and run up to this point).
  11. If you haven't done so already, solder some wires to the DB-9 solder-cup connector and plug into your breadboard, then connect a cable between this and the computer's serial port.
  12. The program is complete, and now you should be able to run it. If you run it with no command line arguments, it will default to n_bits = 5, for track 2 reading. Go ahead and run it in track 2 mode, then swipe a track 2 card in the reader.
  13. You should be getting streams of data. When you hit <Enter>, you should see the accumulated read string, parity string, and LRC value based on XOR logic. If this is not happening, debug your code until it is. Make sure the breadboard is set up for track 2.
  14. Using a (track 2) card that you manually decoded the hard way in Lab 9, swipe and make sure all the parity values are odd (except for zeros after the LRC), and if so the read is complete and valid. Record the sequence of characters, including the start and end sentinels and the LRC (exactly as you see it on the screen). Directly below this, record the parity string so that the characters line up appropriately with their companions above. Record the LRC value and verify that it is the same as that of the character following the end sentinel.
  15. Run through at least three track-2 cards and record the information listed above. See the tip below about maintaining privacy and guarding sensitive information. Identify the segments that you can decipher as making some sense: student ID, account number, expiration date, etc. Did the LRC work? If you get any even numbers in the parity string, swipe again: there was a mis-read.
  16. Run at least two track 1 cards using 7-bit mode (configure breadboard, use shim, and use command line argument). If the parity is all odd, the read was good. Include samples of the information, again writing the output string and parity right below, as well as LRC check. Identify fields and mask sensitive information.
  17. If you want, use one of the Omron readers (beware: pinout is different) and read a track 3. You may have to hunt around to find a card that actually uses track 3. It should be in 7-bit mode.
  18. Have fun figuring out what's in your wallet! Include in the writeup the thing you found most surprising or interesting about what you saw.

Tips

  • The new computers in the lab do not have a built-in serial port (usually designated COM1). Look at the Device Manager on the computer to figure out which COM ports are provided by the PCI card. On the one I tested, it was COM4 and COM5. Try either one to see which works. I suspect it depends on which port you plug into on the card.
  • Rather than write potentially sensitive information in the write-up, you may substitute Xs for random characters so-as to render your information private/unusable by others. Try to keep innocuous things (like expiration date or name) intact so that it is easier to judge whether it works or not.
  • Remember when switching between tracks 1 and 2 that you need to take care of three things:
    1. breadboard SW1
    2. shim
    3. command line argument.

    Lab 10 Write-up

    The write-up should consist of all materials requested from the Lab 9 write-up, plus the final C code listing, and the requested sample swipe data above, with the output string and parity string in a one-to-one alignment. Identify which swipe corresponds to the manual decode from Lab 9, and note any discrepancies, along with a reconciliation of any such discrepancy.


    Back to Physics 121 page