The swipe card holds an identification number unique to it. When a reader reads the card, the information is handed off to a server, the server then checks it's permissions list to see if you have access to the indicated resource. If you have permission to access the resource, an acceptance code is returned and the resource is released, such as a door, vending machine candy, locker, parking garage courtesy stop armature or whatever else your card allows you access to.

Bump for interest.
Also curious about the 'tap on' systems they have on all my city"s buses and trains.
Would love to be able to forge these things...

It's instant because it's just text files. It's not comparing complex images.

>>306388

Its probably RFID. Really though, it doesn't matter if its a chip, or a magnetic stripe or what, its not the format the matters its how they handle security that determines how they are hacked. You have have a freaking paper punch card be more secure that the latest and greatest whatever if your security was good and theirs was shit.

>>306386
>>306392
All makes sense. Thank you.
I occasionally entertain the fantasy of making a "god card" with unrestricted access to all doors.... To do that I would likely need to have access to the permissions list to find out what that master code is, correct?

>>306381 (OP)
>But upon swiping the card, the reaction is completely instantaneous. No delay at all, and I would expect at least some if it has to query a database through a network handling hundreds of other requests at the same time.
I don't think that would be a problem for a card-swipe system. The amount of information passed is very small and has few hops to make. And the card readers probably maintain a connection constantly.
I know that our swipe system is network-connected because we don't have to have our cards updated when moving to different buildings. The locks unlock instantly here, too.

File: 1349591809941.jpg-(20 KB, 450x200, fp1gdvgfjbyz4n5.medium.jpg)

>>306396
Or skim the card of a maintenance worker. If you only want access to all normal dorms you could get a group of friends and a card reader to record card information and then replay that on a magstripe spoofer

http://hackaday.com/2008/08/04/magnetic-stripe-card-spoofer/

>>306401
We have access to all dorms before 2300. What I want is rooftop, tunnel, and machine room access. I don't believe that any one maintenance worker has access to all areas. Besides, if I did steal a card (which I wouldn't like to do, maintenance guys here are real nice) they'd have reason to look up in the database and see where it's being used.

>>306402

It depends on the implementation of the system.
Some will have access logs that are checked (manually or automatically) for odd behaviour, others wont. Or maybe the university is lazy and doesn't care.

Try and find some manufacturer info, then you can look up the systems specs which might lead you somewhere useful.

It is possible that the cards have simple "access level" controls, rather than having unique codes for thousands of people, where each card is assigned a value between 1 and whatever, the higher the number being the more secure area you are able to access. it would be less information for the readers to need to access each time a card is swiped, meaning faser responses. and still have some level of security

>>306428

Would you pay $lots for a shitty system like that? No? Thought so.
This isn't nearly as big engineering problem as OP makes it sound. No matter how you slice it, the required bandwidth is low, occasional hiccups are not a problem, the access control database is small (by modern day standards) and nothing prevents you from using multiple access servers in case there are performance problems.
Oh, and those things commonly use their own networks.

Deducting from my experience as a supporter for software interfaces: 926 Bits means 926 doors or areas which can be stored on the keycard itself.
The software I supported was mostly used in hotels; some of the bits were used for room numbers, others for certain areas, let's say the spa area.

Practically you don't need 1 bit for every door. You can use an access level system like >>306428 already noted, or you subsumize all doors to / within certain areas. Then you only need to read the bit for that area, and if it's I you are granted access, if it's 0 you're not.

File: 1349626483142.jpg-(2 KB, 125x125, 1349051940964.jpg)

I've been thnkin about something similar as OP.
In my case I thought up two scenarios:
>use old walkman casette head to read/write on magstripes using audio in/out on my laptop or something to clone cards
>Assuming that those RFID door locks simply store an access value and not a hash/password, make an RFID scanner that tries all combinations etc.
I just never looked up any specs to see how this shit actually works and how feasible those methods are.

I wanna build that first thing though as I have tons of mag stripe cards, everything from my student ID to subway cards and Im curious at how the data looks on them and if I can play around a bit with that.

Some of you guys are seriously over-thinking this. Each card stores an ID number, nothing else. All the info pertaining to that ID is stored on a server which is much harder to hack than changing a few values on a mag-stripe.

File: 1349627723170.jpg-(11 KB, 256x256, 1346220412083.jpg)

>>306402

Depends if the card is just a magnetic strip or actual RFID.

Besides most of these systems are on timers as well. As in a system can only be accessed at a certain time or it will draw flags.

You better get yourself some boots and a tool-bet if your looking to dress the part.

But definitely take a picture of the device as well as get a model number.

>>306381 (OP)
it's fast because it essentially sends a phone text with your details to the server and the sends one back saying "yes" or "no"

except in this system, the text is sent through a wire to a nearby building instead of an antenna and the server can write the text instantly being electric whereas a person cannot

>>306570
You are over thinking it.

It's just as though the door had a punch combo lock on it. If you know the combo you can get in. They just simplified it by making it electronic and giving you a key card.

This way they don't have to worry about students remembering the code. Also with it being electronic they can place a time restriction on when the lock works.

No complicated server client communication. It really is a low tech setup.

Now perhaps in companies, or govt installations they may have a more robust system that is designed to monitor real time, but I highly doubt a school is going to go to that level.

>>306587
My dorm has little plastic keys which you hold over the door to unlock it. Anyone know how this works exactly? I'd take it apart, but they'd probably charge me at the end of the year

>>306569
>>306413
I did a little snooping around. I found a junction box connected to one of the card readers that's stamped with the Blackboard logo.
They don't seem to provide any info about it, but I'm thinking that the network-database scenario is most likely, given that this box is attached to the reader.

>>306596

RFID

http://en.wikipedia.org/wiki/Radio-frequency_identification
http://electronics.howstuffworks.com/gadgets/high-tech-gadgets/rfid.htm

>>306597
http://www.blackboard.com/Platforms/Transact/Services/Campus-Card-Services.aspx

I suppose it depends on how much effort you want to put in.

You'd need to find the manufacturer and protocol information. If there is a database you'd need to find the specs for that.
Googling might work, or you could ring them.

Getting a mag reader off ebay would let you see whats on the card, a writer would let you mess with the data and see what the results are.

As I said, how much effort do you want to put in.

>>306619
A writer is insanely expensive. A reader isn't hard to build from an old tape deck.
I'd imagine that their reaction would be immediate suspicion if anybody were to contact them asking that information. I might do it from a pay phone at some point.

>>306625

I meant ring the manufacturer, asking about product specs. They might give it out freely.

Your uni's reaction is something to consider, do you want to risk getting on the wrong side of a disciplinary meeting?

I'd be looking at reading your card, and any others you can borrow or find. See how the data varies.

>>306625
Can't you make reader/write out of that tape deck? The only things is getting the perfect swiping speed for that.

>>306634
Possibly, but readers are pretty cheap to buy off the shelf.

Diy reader/writer:
Don't have the time to read through it at the moment so no idea if it works.

http://www.gae.ucm.es/~padilla/extrawork/stripe.html

>>306631
I'm sure that the manufacturer would be immediately suspicious of somebody asking about that product.
>>306664
Interesting.

The only thing on the card is a unique number.

Re the reaction time, how long does it take for a google response? And that's a database with billions of entries. How many cards do you think are listed in your school's access DB?

>>306678
No, they'll be completely open about it.

It's just a card reader. Nothing special about it.

Investigate what kind of signal is sent between the client and server, It's unlikely but it could even be analog or a dumb digital signal. a logic analyzer or oscilloscope could be quite useful.

>>306708
I don't exactly have the luxury of toting an oscilloscope to the card reader and disassembling the panel. But I am sure it uses a completely digital network.

Best guess is that your card will have your student number encoded on it.

To get into areas your card wont allow you'll need a student/staff number that has that access.

Its possible that 'sensitive' areas use a completely different system and your card wont be able to get access no matter how you modify it.

>>306682
I had a look at one of my old Uni ID cards on a commercial card reader, yes, there was a unique ID, but we also had to enter a PIN number at the card reader, bizzarely my PIN code was also embedded in another string on the card stripe.

My other old Uni ID card, I've not scanned as I'd have to find it first, but that particular system was networked going back to a central Oracle database running on a Sun server, with local 'hidden' (in ceiling spaces, mainly) Sun workstations connected to the door controllers via RS-232 links. Total, glorious, expensive overkill. I know that one was based on card ID code alone, checked against the main Database for access rights (as I helped debug the damn system after the contractors fucked it up).

In both cases, I had legitimate full access *everywhere*..fun fun times. My current job, a boring RFID tag based system for door entry at one site, the other, RFID tag to set the building alarm..ID card stripe is blank..well, it *used* to be..

I install these for a living, you guys are spot on about how they work.

I will add that an RFID reader works on induction. The card reader creates a magnetic field and energizes the coil in the card which in turn energizes a microchip with the facility code and card number on it. That information is transmitted back to the controller and the controller decides if the card is valid or not. The database is stored on the controller, which is why it happens so fast.

If anyone has any specific questions, I'll answer them if I can.

>>306397
That and each building probably has their own card server locally, then sync with the main server on a regular basis. I know many larger scale Active Directory setups are like that. You have your primary domain controller and then a few secondary domain controllers. Any changes made to AD are then mirrored through all domain controllers within about 15-20 minutes, at least that is our setup at work.

>>306402
You wouldn't have to steal the card... just have a skimmer (kind of like how people steal debit information from ATM users). However, it would probably be harder to pull off against maintenance workers given they often use those card readers heavily and know if/when they're replaced.

>>306631
Unless you can prove you're a rep from a university looking into purchasing the product, they're probably not going to be too keen on giving that out.

>>306747
My university (A PASSHE school) had blackboard for a few years on their card readers (even after they moved to Desire2Learn, they kept the same readers, just changed the security software). Each card had a long string of numbers on the front of it that was associated in the database with your information. This string was also in the magnetic stripe. Basically to get access to the Unix and SysAdmin labs on campus used for the IT/CS/IS majors, we always had to give that string of numbers to the department secretary and she'd enter them in.

These things are three-stripe readers. Usually, your name is encoded on one stripe, your student ID is encoded on another, and the third one is unused.

You need a mag-card writer, and the info for someone whose card you want to duplicate. Then you copy the same info onto your card with a writer. There are no security features on the card -- knowing someone's student ID should be enough to duplicate the information.

Please do not do this to gain illegal access.

It's entirely possible that there's no way to do this with a card writer. If it's RFID, all the cards have predetermined values.

When I had new guests come in we would add them to the database, take their picture, edit their permissions (drink, areas, gift bags etc.), pick any random card and stick it on the RFID reader. The computer then pairs that card ID with the entry on the database. We never write anything to the card at any point.

>>306969
This is true.
However, with the advent of NFC enabled devices, I'm think one could write a simple application to make the NFC chip send out the right wave to the reader (in a door lock for example).
This is theoretical as I've only learned about NFC hacking in the last few days but it looks extremely promising.

What you need to do is get a card from a university cop or firefighter. You'd have to clone it before you used it, because they would be waiting for you to swipe it at a door.

I imagine there is a way to open the door without messing with the card reader. Think about it... What if there is a substation fire in a building basement.... everyone just gets to burn to death because the doors don't open anymore due to a lack of power? There is probably a relay located in the door, or in the lock which disengages the lock if there is a power outage (or something similar.) It could be a simple as a magnetic reed switch of some sort... a simple magnet in the right place might trip that. Find a place you have legit access to.. make sure no one is around, and cut the circuit breakers for that area and see what happens with the door. Might shed some light on it.

"I've calculated that there is sufficient space on the card for about 926 bits. This doesn't seem like sufficient space to store a list of doors.
So, what say you? Anybody worked with these systems before?"

depending on the language plenty can be done in 926kb most of my programs made in C which are extensively great are 600 lines long and only about 730kb each, either way i'm just guessing that the logic behind it is probably basic if statements that matches between the card and the system it wouldn't take log and it wouldn't have any delays even if the server is far away, it might be something along the lines of the card having some sort of number on it that when matched with the door it opens so perhaps

If ($card =~ /(409932)/) {return $value_open}

the card would have to do very little except have a long list of simply numbers I.E

409932
998302
199503
etc, and when the machine matches the numbers of the card with the door, it opens it. this wouldn't take long since a pentium IV(and this is from the 90's) can calculate numbers at a speed of 1.8million/s matching numbers wouldn't take long either

i will say i am not 100% sure about this but i am assuming this is how it works

>>308532
not 926kb. 926b. Slightly less than 1kb.

And the system is likely not expecting anything executable on the card, nor will you likely be able to execute anything off of it.

>>308705
>the system is likely not expecting anything executable on the card,
so what are the odds that someone could get a really long card (or series of cards?), put something executable in it, and manage to actually get it executed?

/lol Bones

File: 1349918994240.jpg-(306 KB, 3112x1952, Tape drives 70s.jpg)

>>308710
So.... like magnetic tape, then.
The first swipe card was literally a section of magnetic tape glued to a paper card.