Study plan
Tell me what is on your desk. This page answers with the questions you can settle tonight, the ones a browser settles with no hardware at all, and the ones still waiting on a device.
The order is deliberate. Nothing in the first two levels needs a device, and that is not a consolation prize: a reader in your hand invites you to capture first and think later, and a fixed capture makes you read what is actually in front of you. Buy hardware when a question needs it, which for most readers is somewhere around module 13.
One rule outranks everything on this page. No live cardholder data, ever. Sanitize a capture before you analyze it rather than before you publish it, keep the original outside the repository, and read the safety guides before pointing a reader at a card you did not issue. Read the guides
1 / Your bench
Check what you have. None of it is sent anywhere: the plan is derived in your browser and remembered there, which is the only reason the question can be this direct.
0 on your bench · 13 in the browser · 4 waiting on a device
Nothing checked, so the plan below is the browser route. It runs complete through level two: the corpus covers modules 3 to 7 entirely and most of 8, and the practice VM installs without a single device attached.
2 / What that reaches
Four positions by three layers. A device buys a position at an interface, down to a depth, and a hole in this grid is a question you cannot ask yet. Almost every tool somebody regrets buying was bought for the wrong row.
- Readeryou are the terminal
- Level 1
- Out of reach
- Level 2
- Out of reach
- Level 3
- Out of reach
- Targetyou are the card
- Level 1
- Out of reach
- Level 2
- Out of reach
- Level 3
- Out of reach
- Snifferyou are nobody
- Level 1
- Out of reach
- Level 2
- Out of reach
- Level 3
- Out of reach
- Man in the middleyou are both
- Level 1
- Out of reach
- Level 2
- Out of reach
- Level 3
- Out of reach
- Reader cannot observe anyone else's transaction: you power the field, so there cannot be two.
- Target cannot produce a valid cryptogram, because you do not have the key.
- Sniffer cannot change anything, and you need hardware that listens without energizing.
- Man in the middle cannot avoid needing two interfaces at once, plus a link between them.
- Level 1 · The ISO 14443 radio: activation, modulation, timing, anti-collision.
- Level 2 · The APDU exchange, and the bytes that carry it.
- Level 3 · The EMV application: selection, records, authentication, the decision.
3 / Your plan
Every stage names what you are finding out, the module that takes it apart, and what the result does not establish. That last line is not decoration. A capture proves the data can be obtained, and that is several rungs short of a transaction an issuer accepted.
Level 1Foundations
Read a real session end to end
Which commands a terminal sends, in what order, and what the card returns to each one. Start on the Visa debit capture: it is the shortest in the corpus and it stops before GENERATE AC, so nothing is hidden behind a cryptogram yet.
Without a device The workbench, which names every APDU, explains every status word and walks every TLV object. No account and no device.
What this does not prove A capture is one transaction, on one terminal, with one card, on one day. It does not show what that terminal would have done differently, which is the question hardware exists to answer.
CapturesVisa debit
Decode bytes somebody handed you
What is actually inside a TLV blob when you have no note saying where it came from. This is the skill that turns a pasted trace from a colleague into a finding.
Without a device The decoder at /decode. It runs entirely in your browser and uploads nothing, which is the only reason it can be pointed at your own card data.
What this does not prove Decoding names the fields. It says nothing about whether anybody checked them, and that gap is where most of the course lives.
Stand up the bench
Whether your host and your stack agree before a card is anywhere near them. libnfc, pcscd and the Python bindings each want particular versions and compete for the same USB device, and finding that out with a card in your hand costs an evening.
Without a device Download the practice VM, check its SHA-256 before importing, then snapshot it before you change anything. It is Xubuntu 26.04 with libnfc, pcscd and the Python stacks already talking to each other, plus Cardpeek, the NFCGate server, the Proxmark3 client, ATRIUM, Plexus and the SIMtrace2 T=1 research, installed. Several stages below go through ATRIUM, and it is already there. The snapshot is what makes breaking it safe.
What this does not prove The VM is for reproducibility, not for isolation. The cards are not the threat, and a machine that signs in as payment/payment is a research environment rather than a hardened one.
Ask a card what it holds
What a card answers when you choose the questions. Select the application, read the records, and compare what came back with the capture you already know.
Without a device The corpus covers the reading. What it cannot give you is the choosing, and that difference is the whole reason to own a reader.
What this does not prove A reader sees what it asked for. It cannot see what a real terminal would have asked, which regularly includes sequences and parameters nobody anticipated.
Level 2Practitioner
Find the card number three times
Where the account number appears in one contact session. It is in tags 42, 5A and 57 at once, and the Visa debit capture has no tag 5A at all: the number is in 57 only. A redaction script written against 5A passes that file and publishes the number.
Without a device Both captures are in the workbench, already sanitized. Compare the two and write down which tags you would have searched.
What this does not prove Finding the number in a file is a data-handling result, not an attack. It tells you what must never be committed, and nothing about whether a transaction can be forced.
Watch a PIN that was never asked for
What the card offered in its CVM List, and which method the terminal picked. The contact capture carries a CVM List and no VERIFY command anywhere in the session, so the list and the outcome can be compared directly.
Without a device The workbench walks tag 8E and tag 9F34 on that capture, which is the whole exercise.
What this does not prove The contactless CVM limits live in tags DF8123 to DF8126 and never cross the card interface, so no capture can show them. That boundary is a property of where the values live, not of the equipment.
CapturesEMV contact transaction
Read the terminal's verdict bit by bit
What the terminal decided, as opposed to what it authenticated. Tag 95 is five bytes of the terminal's own opinion, and the action codes decide what each bit costs.
Without a device Decode tag 95 from either capture in the workbench, then read it against Visa's published action codes.
What this does not prove The TVR records the terminal's verdict. It is not evidence that the check behind a bit ran, or ran correctly, and one of those bits turned out never to have been bound to anything.
Take the same transaction over the air
How a contactless session differs from the contact one you have already read. Same application, different interface, and a set of tags that only appear over the air.
Without a device Three of the five captures in the corpus are contactless, and the longest carries six transactions in one recording so the counter moves between them.
What this does not prove No reader in this toolset exposes Level 1, so activation, anti-collision and timing stay invisible however good the reader is. Changing library does not help. Changing position does.
Tell a token from a card number
Whether the number in front of you is the card's own or a device number standing in for it. A token is a different, independently valid number rather than an encrypted one, so the difference is not visible in its shape.
Without a device The Mastercard session in the corpus is the one to read for this, alongside the tokenization modules.
What this does not prove Recognizing a token says nothing about where its keys live or who can provision another one, and that is the part the module has to answer with documents rather than captures.
Level 3Operator
Watch a real terminal, unprompted
What a real terminal asks when nobody is steering it. This is the position that produces sequences, parameters and selections you would never have thought to try, and it is the reason the corpus is worth reading in the first place.
No substitute No capture answers this one. The question is about timing, or about what a terminal does when nobody is steering it, and neither is in the file format.
What this does not prove A sniffer changes nothing, so it cannot test a hypothesis. It tells you what happened, which is a different and usually earlier question than what would happen if.
Answer a terminal with values you chose
How a terminal behaves against answers under your control. Standing in for the card is how a terminal's configuration becomes readable, because its questions change with what you tell it.
Without a device ATRIUM can stand a card up in software and replay a corpus capture as its answers, which exercises your own stack end to end. It comes installed in the practice VM. It does not give you a terminal to answer, so the half of this stage that is about a terminal stays out of reach.
What this does not prove Standing in for a card cannot produce a valid cryptogram, because the key is not yours. Everything reachable from this position is reachable without one.
Measure a terminal's unpredictable number
Whether tag 9F37 from this terminal is unpredictable. It is the terminal's only contribution of freshness to the cryptogram, and some terminals supplied a counter instead of a random value. Collect enough of them from one terminal and the answer is arithmetic.
Without a device The captures show you what 9F37 looks like and where it sits in the PDOL, and the replay session shows the counter moving across attempts. Measuring a generator needs many values from one terminal, which a fixed capture cannot provide.
What this does not prove A sound generator closes one variant of pre-play and nothing else. The attack scales with organization rather than with computing power, so a good random number is a fix for the terminal you measured.
Try to catch a relay from the bytes, and fail
One of the sessions in the corpus was relayed. Find it from the APDUs alone. You are meant to fail, and the failure is the lesson: the capture records command bytes, response bytes and status words, and nothing in it says when any of that happened.
Without a device The workbench, on the longest Mastercard session. Read it looking for the relay, then read what the file's own banner line said before the workbench discarded it.
What this does not prove An APDU trace cannot answer the only question relay raises. Timing is the evidence, and timing is exactly what the format does not carry.
Run a relay and time it
How much delay an exchange tolerates before something refuses it. Two phones running NFCGate put a network between the card and the terminal; SIMtrace2 in cardem firmware does the same on the contact side. Then measure, because the number is the finding.
No substitute No capture answers this one. The question is about timing, or about what a terminal does when nobody is steering it, and neither is in the file format.
What this does not prove A working relay proves the data can be carried. Whether a transaction completes is a separate claim, and the countermeasure protocols in module 17 are where the timing limits stop being incidental.
Level 4Researcher
Follow one cryptogram out to the issuer
How the amount the card signed relates to the amount the issuer approves. They are two copies of one number in two places, and only one of them is inside the cryptogram. Whether anybody compares them is not written down in any specification.
Without a device The contact capture carries the field 55 side, and the module follows it out through an ISO 8583 message and back as an ARPC. Readers with an enrollment also have the transaction lab, where switching one issuer check off answers which one was doing the work.
What this does not prove How often a production issuer makes that comparison is not documented anywhere, and the module ends on exactly that question rather than answering it.
CapturesEMV contact transaction
Measure where the ACR122U actually stops
An open question with a known method. A contactless relay on an ACR122U dies four commands in, on tag 9F46: the certificate is 256 bytes, 259 with its header, and the outbound frame the reader broke on was 263. The true ceiling has been bracketed and never measured. If it reaches 258, the firmware path completes a transaction. If it does not, that is a hardware conclusion rather than a bug still worth chasing.
No substitute No capture answers this one. The question is about timing, or about what a terminal does when nobody is steering it, and neither is in the file format.
What this does not prove This tells you where your own reader stops, and nothing more. Past the limit the reader stops answering, and it stays that way for the rest of that session: disconnect it and connect it back and it works normally again. So the cost of finding the ceiling is a cable pull. A result here is a fact about one reader rather than about the family, and it says nothing about whether any transaction would have been accepted.
Produce a capture somebody else could reproduce
Whether your experiment can be rebuilt from what you published. A capture without the card, the terminal, the date, the environment, the firmware version and the hypothesis being tested is a file rather than a record. Two terminals apparently running the same transaction diverge on configuration, software version and regional parameters.
No substitute No capture answers this one. The question is about timing, or about what a terminal does when nobody is steering it, and neither is in the file format.
What this does not prove Sanitize before analysis, not before publication: keep the original under control and generate a separate file for sharing. Removing a visible account number is not enough, because tag 9F46 recovers to a structure containing the number and the keys to unwrap it are published. That is why the certificate is replaced rather than trusted.
4 / The next device
Opens 6 questions
An ACR122U
Level 3 and most of Level 2. A PC/SC and CCID reader built on the NXP PN53x family, so both stacks talk to it.
Will not do Sniffing. It is a reader, not a listener, and it cannot watch someone else's transaction. A contactless EMV relay on it stops at the certificate record, and a second reader does not fix that.
- Ask a card what it holds
- Take the same transaction over the air
- Answer a terminal with values you chose
- Measure a terminal's unpredictable number
- Measure where the ACR122U actually stops
- Produce a capture somebody else could reproduce
5 / What this cannot place
A plan that lists only what it covers reads as though it covers everything. Each of these is a property of where the data lives rather than of anybody's budget.
Instant payments and QR
There is no capture for module 11 and there will not be one. A QR rail has no card interface to sit on, so the observation positions this plan is built from do not exist there. That module is read against specifications and incident reports instead.
Relay resistance
The corpus carries no INS EA exchange, so module 17 works from the byte layout by hand. Producing one needs a terminal that implements the protocol, which is a harder thing to find than a reader.
Contactless CVM limits
Tags DF8123 to DF8126 never cross the card interface. No position in this plan can observe them, whatever the device, because they are terminal configuration rather than traffic.