Reverse Engineering Priority Pass Apple Wallet / QRCodes
 

So, in 2015 Priority Pass added the ability to use Apple Wallet / Android to have a digital membership card with QRcode to scan your membership info at lounge entrance.

For some reason, they unfortunately don’t extend this same functionality to PP Select members in the app, requiring them to carry their cards everywhere. This is kind of silly, considering almost all PP lounges will let you in after a membership ID and Expiration lookup. I hate carrying extra cards with me, so I usually opt for this method, even though it’s slower. So if PP won’t fix this, let’s fix it ourselves.

I plan to reverse engineer and replicate the Apple Wallet functionality, allowing PP Select members to enter their information and have a “PP Select” Apple Wallet card generated they can download and install on their phones — and when scanned at the lounge, it will properly pull up their actual account information (no funny stuff!).

(I’ve done with this other things in the past — for example my gym uses a horrible buggy iOS app which takes ages to load and crashes half the time before the QR code comes up. By comparing data with a few other members, we were able to easily make our own Apple Wallet cards which launch instantly and work all the time.)

In order to do this, I need a variety of sample data. Willing to help? I need a few PP members who use Apple Wallet (or the Android equivalent) to screenshot their pass and send it to me. Yes, this means you are effectively sending me your member number, ID, expiration etc. There's no way around this, so you would have to trust me and take my word I have no malicious intentions with this. But if you’re willing to help, email your screenshot to me ([email protected]). I may follow up with some additional questions later on as I make progress.

If I can get this to work, I will release all the code and methodology freely so anyone in the FT Community can take advantage of it, and writeup a blog post explaining the process.

P.S. To be absolutely clear, if this even works, THIS WILL NOT HACK / GIVE ANYONE FREE ACCESS. This would strictly make it possible for Priority Pass Select members to copy their membership info into an unofficial scannable digital card to avoid carrying the physical one.

(Apologies if this is the wrong forum for this, I was having difficulty figuring out the appropriate place to put it.)

It's up to the financial entity sponsoring the PPS membership as to whether they'll allow the digital card. I don't know why people don't, but there you have it. While you might be able to generate a valid QR code, I suspect their systems won't accept a digital card from someone who's not supposed to have one.

There are more important things I'd be spending my time on, personally.

Priority Pass Select cards (with the reported exception of accounts sponsored by Chase) can display digital membership cards using Priority Pass' own smartphone apps:

https://itunes.apple.com/gb/app/prio...ss/id406878019

https://appworld.blackberry.com/webstore/content/40929

https://play.google.com/store/apps/d....prioritypass3

MROTHLY, did you make any progress here? Sadly, I'm a Chase PP member, so no QR code for me. I like your angle though. There is nothing special about a QR code, it is just a series of letters/numbers.

Slight clarification: it depends on the entity generating the QR code. The payment-related ones (e.g. Chase Pay/Walmart Pay) use different letters/numbers every time the user requests the code to be displayed, so any hand-generated one would likely only work once--if that.

That said, I don't think Apple Wallet supports being able to regenerate the QR code every time the pass is brought up.

I made a decent amount of progress, but only one person was able to send me a working QR to look at, so I don't have enough data to fully figure it out yet.

For the most part the QR code is really simple -- just encodes some text roughly like this format:
PP/[$issue-date]/[$cardholder-name]/[$expiration-date]/[$account-number]//[$checksum]

All of those are things that are normally visible on your card except for the checksum (which is a calculated hash designed to make sure the other fields are read correctly). Without more examples though, I can't reverse engineer how the checksum is calculated.

As a test, I made myself a QR code with my actual account details and just put junk data in the checksum field. This actually still worked in about 50% of the lounges I tried it in (the other half got a scan error, and ended up just manually typing in the details).

Since I was curious I also bought a cheap mag stripe card reader and looked at what is on the physical PP card. It's very similar, but doesn't have a checksum field at all (which is ironic since QR codes have built in data redundancy making the checksum largely irrelevant, whereas magstripes get misreads all the time and a checksum would actually be useful in the field).

Any further progress on this?

Formatting
 

Great project Any tips on the formatting of the fields?

Is name full name including middle initial and spaces?

Are dates yyymmdd or yyyy-mm-dd or something else?

How many chars is the checksum?

Poked around in the app to see if it was generated client side or server side. Alas, it's server side.

For me, it looks something like:

PP/<issue date in ddmmyy>/<FNAME LNAME>/<expiration date in mmyy>/<membership number>//1/<6-digit uppercase hex>

I believe the 1 is the "subscription level id", but it's unclear what that means here. One interesting thing that differs between the different ones is that the Amex/Citi issued passes have a "ConsumerType" in the app of "FULL" and the CSR issued pass has a type of "ASSOCIATE".

My guess is that Chase negotiated for a specific type of membership that didn't include this in the contract, since you also don't see unique issuer codes on that one, unlike the other two.

One thing about the hex digits is that I wouldn't necessarily say that it's a checksum. It could also be an HMAC-SHA256 digest or the like, but it's hard to tell without seeing how the code is actually validated. My guess is that it's done remotely, just like the generation.