Mag Stripe on Tickets

[napnet]

Does anyone know what data is actually on it? I am working on a new project at work dealing with mag stripe readers (like for credit cards) and was curious to see what was on my AP. Well in raw form it is just a bunch of characters repeated twice with the first three characters different. Anyone know what it means, how to decrypt it or calculate what it is? Thx

 

[PurpleDragon]

I was always curious about that myself. In reference to your AP, it probably has the valid start/end dates, maybe the history of what parks you've visited, as well as your information.

The characters are probably part of a program they have and a certain character in a specific position refers to a specific park, or record number in the system, or something, no real way to tell.

 

[wannab@dis]

More than likely, it's simply an identity that points to a record in a database. The information relevent to the pass is in the database.

How many characters?

 

[wannab@dis]

I was always curious about that myself. In reference to your AP, it probably has the valid start/end dates, maybe the history of what parks you've visited, as well as your information.

The characters are probably part of a program they have and a certain character in a specific position refers to a specific park, or record number in the system, or something, no real way to tell.

I doubt it has historical information on the actual card. How would that data be added to the card? Rarely are the swiping machines writers... they are readers only.

 

[napnet]

More than likely, it's simply an identity that points to a record in a database. The information relevent to the pass is in the database.

How many characters?

Here is the scan i got for my ticket (X = character, 0 = number)...

% XXXXXXXXXXXXXXXX0XX00XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX0XX00XXXXXXXXXXXXXXX ?

After the 35th character was where the repeating began (and removing the first character and bolding the different character)

XXXXXXXXXXXXXXX0XX00XXXXXXXXXXXXXXX
XXXXXXXXXXXXXXX0XX00XXXXXXXXXXXXXXX

Here is some things I figured out...

The leading character is not repeated and only the second character of the two repeating characters is different. Something makes me think either the string is a hash of some sort of like the begging date and ending date but i wouldn't expect to see the values so similar.

It is odd because all my credit cards and sorts scanned with just plain text. I would expect that data to be encrypted.

 

[napnet]

I was always curious about that myself. In reference to your AP, it probably has the valid start/end dates, maybe the history of what parks you've visited, as well as your information.

The characters are probably part of a program they have and a certain character in a specific position refers to a specific park, or record number in the system, or something, no real way to tell.

I doubt that, writers are expensive. The data is more than likely a key to something in the database or an encrypted string done in some Disneyish way

 

[PurpleDragon]

Quote:
<table border="0" cellpadding="6" cellspacing="0" width="100%"> <tbody><tr> <td class="alt2" style="border: 1px inset ;"> Originally Posted by PurpleDragon
I was always curious about that myself. In reference to your AP, it probably has the valid start/end dates, maybe the history of what parks you've visited, as well as your information.

The characters are probably part of a program they have and a certain character in a specific position refers to a specific park, or record number in the system, or something, no real way to tell.
</td> </tr> </tbody></table>
I doubt that, writers are expensive. The data is more than likely a key to something in the database or an encrypted string done in some Disneyish way

Please read my whole post, the second part mentioned it being something similar to references to records in a database. I didn't actually mean they kept all the data on the magnetic strip. I was just saying what data is recorded with the scanning of the anual pass. So each time the magnetic strips is scanned it adds updates to the database.

Sorry guess I didn't phrase my post clearly enough, I was simply explaining to him what the probably keep track of with the code on the AP.

 

[napnet]

Yes im sure they track it in some huge DB... that probably the reason for the lag time of when they scan my card and it lets me in or gives a FP. I can only imagine how that network and DB is setup.

 

[Miss Bell]

Last week we were having trouble with my daughter's AP. It wasn't reading all the time at entry. After one of those times, we could no longer ger her Fastpasses. When we went to Guest Services for a replacement, they said that either her magnetic strip was wearing out, or that her card was reading that she wasn't in the park.

In other words, because they manually let her through the gate because her card wouldn't read, she couldn't get a Fastpass in the park. That implies write capabilities to me, or how would the system know not to give her Fastpasses--same holds true for not being able to more than one FP at a time.

Either the magnetic strips are being written to when you swipe them, or their is some major data system somewhere housing that info that extends from park to park. (Cause I've tried to get a Fastpass at another park while I was still had a valid one from the park I was previously at.)

 

[napnet]

Either the magnetic strips are being written to when you swipe them, or their is some major data system somewhere housing that info that extends from park to park. (Cause I've tried to get a Fastpass at another park while I was still had a valid one from the park I was previously at.)

I'd go with a ginormous database under the castle... only like 400 bytes of data is available on the mag strips. The structure of the data on the card points more towards some database instead of updatable data. Also, mine has lost its value and i had to go to guest services to have them remagnatize it.

 

[robhedin]

Last week we were having trouble with my daughter's AP. It wasn't reading all the time at entry. After one of those times, we could no longer ger her Fastpasses. When we went to Guest Services for a replacement, they said that either her magnetic strip was wearing out, or that her card was reading that she wasn't in the park.

In other words, because they manually let her through the gate because her card wouldn't read, she couldn't get a Fastpass in the park. That implies write capabilities to me, or how would the system know not to give her Fastpasses--same holds true for not being able to more than one FP at a time.

Either the magnetic strips are being written to when you swipe them, or their is some major data system somewhere housing that info that extends from park to park. (Cause I've tried to get a Fastpass at another park while I was still had a valid one from the park I was previously at.)

1. card is scanned at entry.
2. id from card is then used to lookup data in central database
3. if database says it's ok (i.e. number of days left is > 0 and/or card not expired) give green light to admit guest. In the Database: deduct 1 from days left (if applicable), store date, store park.
4. At fast pass, scan card
5. id from card is then used to lookup data in central database
6. if park was entered today and it's ok to issue fast pass, issue fast pass and update fast pass field in database.

Now, if the card wouldn't scan in step 2 (because the mag stripe is bad or the reader is broken, for example), then step #3 doesn't happen. The cast member just presses a button to admit the guest, BUT that can't be tied back to a ticket (since the ticket couldn't be read).

Hence when you go get the fast pass #6 wouldn't work and hence no fast pass.

No writing to the ticket is necessary at all, and everything happens via a central computer and a database.

rob.

 

[kcnole]

In other words, because they manually let her through the gate because her card wouldn't read, she couldn't get a Fastpass in the park. That implies write capabilities to me, or how would the system know not to give her Fastpasses--same holds true for not being able to more than one FP at a time.

Information is most definitely being written when you swipe the card, but not to the magnetic strip itself. It's being sent via network to wherever they house their large data warehouse. That database keeps track of what park you entered, and at what time and date. It also keeps track of what rides you have fastpasses for and the times on them, etc... Apparently there's also code to not give out a fastpass if that card wasn't recognized as going through entry which would stop you from coming by yourself and bringing your kids card to get an extra fastpass with.

I don't even want to think about how complicated or huge that database has got to be though.

 

[SpenceMan01]

More than likely, it's simply an identity that points to a record in a database. The information relevent to the pass is in the database.

How many characters?

1. card is scanned at entry.
2. id from card is then used to lookup data in central database
3. if database says it's ok (i.e. number of days left is > 0 and/or card not expired) give green light to admit guest. In the Database: deduct 1 from days left (if applicable), store date, store park.
4. At fast pass, scan card
5. id from card is then used to lookup data in central database
6. if park was entered today and it's ok to issue fast pass, issue fast pass and update fast pass field in database.

Now, if the card wouldn't scan in step 2 (because the mag stripe is bad or the reader is broken, for example), then step #3 doesn't happen. The cast member just presses a button to admit the guest, BUT that can't be tied back to a ticket (since the ticket couldn't be read).

Hence when you go get the fast pass #6 wouldn't work and hence no fast pass.

No writing to the ticket is necessary at all, and everything happens via a central computer and a database.

rob.

Bingo on both counts.

 

[wannab@dis]

Here is the scan i got for my ticket (X = character, 0 = number)...

% XXXXXXXXXXXXXXXX0XX00XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX0XX00XXXXXXXXXXXXXXX ?

After the 35th character was where the repeating began (and removing the first character and bolding the different character)

XXXXXXXXXXXXXXX0XX00XXXXXXXXXXXXXXX
XXXXXXXXXXXXXXX0XX00XXXXXXXXXXXXXXX

Here is some things I figured out...

The leading character is not repeated and only the second character of the two repeating characters is different. Something makes me think either the string is a hash of some sort of like the begging date and ending date but i wouldn't expect to see the values so similar.

It is odd because all my credit cards and sorts scanned with just plain text. I would expect that data to be encrypted.

Yep, that appears to be a simple identity. I'm not sure about the repeat other than a secondary copy that has enough changed so they can reduce attempted fakes.

As for the credit card number being plain text... Having them encrypted would be a problem since there are so many networks that sell CC terminals and then forward the swipe information out to the processors. The only way it would work if there was a single private key for the hash. That would basically defeat the purpose since everybody and their brother would need the key and it would no longer remain private.

But, logically, if you have the card and can slide it through a reader, then you could simply write down the number.

By the way... what kind of work do you do?

 

[Rob562]

My guess on the same sequence appearing on the strip twice is to help limit the number of rejects due to demagnetized cards.

If the serial number only takes up half the capacity of the strip, why not put it on twice. That way if only a segment of the mag strip is demagnetized, the readers might be able to read at least ONE copy of the serial number.

Or possibly as some sort of cross-reference error-checking. The turnstile reads the full strip, both copies of the same number. If copy 1=copy 2, then it can be sure that it has the proper serial number to work with. If copy 1 is different from copy 2, it can try reading the card again, or spit it out as an error. Let's say that a part of the stripe gets exposed to a magnetic field and scrambles the info. Now, that random scrambling could possibly be read as a *different* number. Also, the readers are not 100% error-free. I'm sure they have mis-reads on occasion. So, if you have the reader double-check the two copies against each other first, Disney can make sure to deduct the admission from the proper pass. (Imagine if someone else's card was really subtracting days from YOUR pass....)

I work with barcode scanners in a library setting all day. And though they're optical and not mag readers, the principal is the same. The scanners *do* make errors reading the data on occasion. In my case, it could be a dirty barcode, a dirty window on the laser scanner, and in one case a printing error on the barcode where the scan didn't match what the text underneath said it should have been. Bad scans are a fact of life, but we have operational practices set up to minimize the possibility of a bad laser scan causing problems. So I'm assuming that that's what Disney has set up, too. Quite smart.

-Rob

 

[Rob562]

And noone brought up the flaw in the Fastpass system when it was first rolled out. Originally, the Fastpass machines *weren't* linked to the admission database. It was its own stand-alone system. WHen you inserted your ticket, it would read the serial number. If that serial number wasn't in the database as already holding a fastpass, it issued one. I assume then that when your fastpass time rolled around, the system then deleted your pass' number from the database. Simple and elegant design.

But, the problem was that it would record ANY Disney serial number. So as long as you had a ticket with the proper-length serial number, whether it be a ticket to a park, PI, water park, even old room keys that didn't have admission on them at all. It just read the serial number, saw it was a Disney serial number, and copied it down into the database. Depending on how many old tickets you were carrying around with you, you could have a dozen or more fastpasses all at once.

Disney eventually realized this loophole, and then connected the Fastpass system to the entrance gate database. Now it checks to see if the pass# has entered the park that day before issuing a Fastpass. After that check, the system probably still works as it originally did.

-Rob

 

[napnet]

As for the credit card number being plain text... Having them encrypted would be a problem since there are so many networks that sell CC terminals and then forward the swipe information out to the processors. The only way it would work if there was a single private key for the hash. That would basically defeat the purpose since everybody and their brother would need the key and it would no longer remain private.

Yeah thats true.... i'd rather have a CC with no numbers on it and the card, when swiped, sends the encrypted data off my card to be decrypted at the processing center limiting who has the keys to decrypt it. put im just paranoid

By the way... what kind of work do you do?

Web and Application development for a govt contractor. Mostly things having to do with the DOJ and Federal/State law enforcement.