Difference between revisions of "MagSpoof"
(→How to Links)
|Line 113:||Line 113:|
==How to Links==
==How to Links==
:[https://classes.engineering.wustl.edu/ese205/core/index.php?title=Using_Fusion360#Descripition Using Fusion360]
:[https://classes.engineering.wustl.edu/ese205/core/index.php?title=Using_Fusion360#Descripition Using Fusion360]
Revision as of 13:44, 8 December 2017
- 1 Project Summary
- 2 Team Members
- 3 Objectives
- 4 Challenges
- 5 Gantt Chart
- 6 Ethical Concerns
- 7 Budget
- 8 Final Design and Solutions
- 9 Results
Our project aims to enable magnetic card communication of WUSTL ID cards and Dorm Key Cards, with locks, wirelessly. Our project is based off the the Magspoof project done by Sammy Kamkar. You can find a link to his project here. Our project aims to expand upon this design by having multiple cards stored on the device. As a basic design we are using the Attiny85 to control the output of a SN75441 motor driver .The motor driver will output the RF signals to an inductor. The inductor should acts as an amplifier to the RF signals that will be readable by a magnetic card swipers. We will have an indicator for the current card in use as well as a means to switch between cards. The challenge comes in that our micro controller, the Attiny85, has only six configurable pins. Three of these pins are taken by controlling the motor driver. This leaves only three pins and outputs. As well as this added functionality we plant to 3d-print a case for the device to provided a better aesthetic to the device. File:MagSpoof Presentation.pdf
Amelia Delzell-TA Jim Feher- Subtistute TA
- Learn objective C and Arduino C
- Use Arduino to program attiny85
- Fully assemble circuit using IC chips
- Practice soldering skills for final project design
- Recreate the RF field of a WASHU ID
- Open Urbauer 015 with the device
- 3D print case
Barring Major Set-Backs:
- Be able to upload multiple cards
- Switch between and use multiple cards
There are a number of challenges associated with this project. The first will be figuring out the standard of the WASHU ID. The WashU standard would likely be an ISO standard but we cannot assume that. Once we determine the standard we can use a card reader to read the data in from the card. One possible problem is that we cannot download the driver software on the network computer. So I may need to talk to IT to get permissions.
We would then have to build the supporting circuit to actuate the RF field using the schematic as shown on the left. As you can we see we plan to use the motor driver L293D H-Bridge, connected to an inductor, to amplify the signal from the ATTiny85. We will have a switch for the actuation of the RF field.
Once we have the hardware constructed we can move onto the challenge of software. The software needs to conform to the WashU ID standard (whether that is ISO or otherwise). Once we have a functional program that compiles we have to upload it to the Attiny85 using an arduino. Then we can move onto debugging the program. We can debug it using the same card reader talked about in the first part. Once we are receiving the smae information from the car reader that we found on our card using our device then we will have reached our main objective. We should then test the device on various doors and other readers.
As a demo for the project we would have a participants ID loaded on to the device and then swipe them in to the Washu attendance software.
One challenge is that the batteries on the device may not last long. We may include a breaker switch on the battery so the device has long term usability.
With extra time we can modify our project to add multiple cards. We would add a second switch to our cirucit as well as 2 more LEDs. The LEDs would indicate in binary which card we are using (0:3). The switch would give a signal to Attiny85 to switch tracks. We may also develop a better way of encoding cards because with this design we have to hard code them into the firmware.
Updates as of 10/12/2017
We were able to find find the proper device driver to read the WASHU ID. Running a copy of Windows on Jon's laptop we were able to use the serial ports to run the a mag stripe reader. We found that the encoded information of the ID were the numbers at the top of the card directly above the name on the card with 13 leading zero's. The standard at this point is still unknown but it should not have an impact on functionality. The standard should only have an impact on the duration of the RF signal for each signal. We should be able to just trouble shoot this once we have a device.
Another major challenge was in found in programming the Attiny85. Using the Arduino as an ISP we could not initialize communication with the Arduino UNO that we were using. We are using an Attiny85 ISP Library. This library is supposed to support the UNO as an ISP. We found that the UNO was unresponsive to any serial communication. After investing 3 hours in troubleshooting the error we decided that we would invest in an AVR programmer board. We got the AVR programmer in less than five days. In our first test it was successful as USB ISP. This AVR Programmer is very well designed. The programmer has breakouts that allows for testing the Attiny85 without remounting the IC chip every time. This is well worth the money in terms of time saved.
We also used the Arduino UNO to develop an input algorithm. Originally we had our input as a single and a double press. In development we decided that it would be cleaner to simply have a long and short press input. The short press would activate the device while a long press would swap the cards.
As a safety concern no credit card should be uploaded to this device
In terms of ethical concerns, the pitfalls here are clear. Identity theft is a serious problem in the United States, and if misused, our device could be used to propagate this issue. It would be easy, for example, for a nefarious user of our device to swipe someone else’s card and in that way masquerade as another person on campus. Student IDs not only have building access; they also have access to bear bucks which are essentially cash. Thus, the ethical challenges facing this device are serious. It is important to note, however, that the system is flawed as well. Magstrips on cards are low-tech, antiquated and low-security identifiers. Thus, somewhat dubious nature of MagSpoof should not be completely attributed to the device itself, but also to the card system as a whole.
In the end, however, my partner and I believe the benefit of this device far outweighs the potential abuse. Not every student at Washington University, for example, is physically able to swipe a key card 2-4 times to enter their building and room. There are elevators in every building and handicap-assisted doors, but what about those with a broken arm, or wrist? Our device represents a viable solution to make access to buildings even more universal. Beyond that, our device is simply downright convenient. If a student is carrying many books or other supplies, MagSpoof is an easy way for them to contactlessly enter the building. We project that that MagSpoof will save time and make the entry process more seamless.
Attiny85 x 4-$5.68
SN75441 H-Bridge x 4-$9.40
24AWG Magnet Wire -$11.95
100mAh 3.7V LiPo battery x 3-$11.01
LED X 10 - $2.85
Momentary switch x 10 - $5.00
Mini Protoboard x 2 - $5.90
AVR Programmer- $19.95 (optional)
Breadboard - $4.95
Capacitors x 2 - $.54
Resistors x 10 - $.80
Battery Holder - $.90
PCBs - $33.60
Final Design and Solutions
Multicard design had two major points: to be able to program multiple cards into the device and to be able to freely switch between these cards. We first tackled the design of input. Due to the limited pins of the Attiny85 we were limited in terms of device capabilities. We wanted an indicator LED for multicard so that we could differentiate which card was in use, but this left us with a single button input. So decided to make the input to our device variable. Originally we wanted to have a double press, single press input but this proved to hard to integrate with the debounce code that we had written for the device. Instead we went with a long vs. short press. We found that using this input was more reliable and less prone to a debounce error. We in fact did not need to implement a debounce on the input after we had switched because the inputs were able to perfectly function without it. The code for the debugging these inputs can be found in the design references link under software/input. We paired this input code with a simple circuit that had an Attiny85 output high to one LED with a long press of a button and output high to another LED with a short press of the button. With input sorted out we could move on to loading multiple cards on to the device. This was mainly an effort of modifying structures to account for more than one card. I tested my code by having the main loop play a specific card and seeing if the card registered on the reader correctly. Once I could reliably play any track I wanted, I integrated the input code I had written. I made the the long press automatically switch cards on the device and the short press to simply activate the device.
Circuit Design & PCB
We went through several iterations of the circuit. We wanted to added functionality to the original circuit. We wanted to indicate what card we were using as well as add a battery kill switch. Below is the final circuit design that we settled on. We originally were originally planning on using a hand soldered board. After creating 2 initial prototype boards we realized that the size of these boards was inconsistent with the form factor we wanted. Therefore, we decided that the final device would run on a printed circuit board (PCB). We designed the PCB in EAGLE, a software program used to design circuit boards. Manufacturing was outsourced to OSHpark, a PCB producer.
3D Printed Case
After consulting with Professor Feher at the start of the semester we decided that we needed a case to hold the final MagSpoof circuitry. Our initial plan was to use the case itself as an inductor core, and wrap the inductor wires around the box. This, however, was not feasible. Given the relationship for inductance:
- I= (n^2*U*A)/L
Where I is total inductance in henrys, n is number of turns of wire, U is a constant based on the material of the inductor core, A is the cross-sectional area of the inductor and L is the length of wire used. We found that we could increase inductance by placing a smaller inductor on the exterior of the MagSpoof case. This is because I grows exponentially as the number of turns of wire increases, yet linearly as area increases. So the loss in inductance by reducing the area of the inductor was offset by many more turns in the wire, resulting in higher overall inductance. The case for MagSpoof was designed in Fusion360 (see “How to Use Fusion360”).
Programming the Attiny
Programming the Attiny85 turned out to be more difficult then originally expected. We originally planned to use an Arduino uno as a serial programmer to program the ATtiny85. We used the library linked under design references/software. Following the set up described by this guide we ran into some issues where the code would not compile and upload to the the Arduino UNO. While the issue seemed to have cropped up for many other people there was no clear solution. By this point we had invested about 10 hours in just trying to compile the code. We decided that to save time we would invest in an AVR Programmer to upload directly to the Attiny85. Fortunately this worked successfully, and we were able to move past this critical point in out project.
Our project met almost all our design specifications and goals. In terms of design we were able to both recreate a WASHU-ID as well as switch between multiple ID's. In addition to these original design features we added a 3d-printed case and a PCB to our device. The only goal that we were unable to fully achieve was accessing Urbauer 015 with the device. The card reader to Urbauer 015 is enclosed in a metal casing. The casing acted as a Faraday cage that our RF signal was unable to penetrate. We were able to work around this by jamming a small inductor into the slot and next to the read head. However we felt that this contradicted the idea of a wireless device and so labeled it a failure. However, we were able to successfully use our device on to wirelessly 'swipe' into plastic-enclosed card readers. We initially proved the functionality of our device on the card readers attached to the printers in Lopata as shown in the video below. On demonstration day we chose to show the security issues that our device brought up by using our device to charge both me and my partners card on a Bear Bucks card reader generously loaned to us by Student Union.
If we were to continue with this project there are a few more goals we would probably like to complete. The biggest one is form factor. Our original aspiration was for MagSpoof to be a pocket-sized device. Although our final device (measuring 2x3x1.5 inches LxWxH) can technically fit in one's pocket there is still clearly room to make the device more compact. Additionally, if we were to bring this device to market we would have to make it more user-friendly- perhaps with a small screen or simply more indicator LEDs to further differentiate between the different actions on the device. As emphasized in the previous paragraph, however, we accomplished all of our initial goals and for the purposes of this class consider MagSpoof to be an unconditional success.