Lazo card with 4-byte UID doesn't match documented keys (possible different batch)

sucotronic commented

2026-09-10 11:54:21 +02:00

I have a Lazo card (top-up/balance type) whose tag info doesn't match the spec documented here.

Tag info (read with MIFARE Classic Tool for Android):

UID: 8D30DCEF (4 bytes) — the README states Lazo cards have a 7-byte UID
ATQA: 0002
SAK: 18
Chip: MIFARE Classic 4K (NXP), 40 sectors, 256 blocks — matches the documented Lazo spec

I tried mapping all 40 sectors with the keys listed in the "Lazo keys" table (sectors 0-31, 32, 33, 36, 37, plus FFFFFFFFFFFF for 38-39), using MifareClassicTool. None of the keys authenticated on any sector — the key map came back empty (0 sectors found).

I made sure the card was held steady against the NFC antenna throughout, and also tested the single default key FFFFFFFFFFFF against just sectors 38-39 in isolation with the same negative result, so it doesn't look like an NFC communication issue.

Given the 4-byte UID (vs. the documented 7-byte UID), this looks like it could be an older or different manufacturing batch of the Lazo card using a different key set. Posting this in case it's useful data for the "unconfirmed"/coverage side of the project — happy to provide more info (e.g. a full dump attempt, block 0/1 contents if I can get any sector to read, or trying other known default MIFARE keys) if that would help narrow it down.

I have a Lazo card (top-up/balance type) whose tag info doesn't match the spec documented here. Tag info (read with MIFARE Classic Tool for Android): - UID: 8D30DCEF (4 bytes) — the README states Lazo cards have a 7-byte UID - ATQA: 0002 - SAK: 18 - Chip: MIFARE Classic 4K (NXP), 40 sectors, 256 blocks — matches the documented Lazo spec I tried mapping all 40 sectors with the keys listed in the "Lazo keys" table (sectors 0-31, 32, 33, 36, 37, plus FFFFFFFFFFFF for 38-39), using MifareClassicTool. None of the keys authenticated on any sector — the key map came back empty (0 sectors found). I made sure the card was held steady against the NFC antenna throughout, and also tested the single default key FFFFFFFFFFFF against just sectors 38-39 in isolation with the same negative result, so it doesn't look like an NFC communication issue. Given the 4-byte UID (vs. the documented 7-byte UID), this looks like it could be an older or different manufacturing batch of the Lazo card using a different key set. Posting this in case it's useful data for the "unconfirmed"/coverage side of the project — happy to provide more info (e.g. a full dump attempt, block 0/1 contents if I can get any sector to read, or trying other known default MIFARE keys) if that would help narrow it down.

preview.webp

43 KiB

hloth commented

2026-09-10 12:33:58 +02:00

Owner

Hi, please try to authenticate sectors with std and std-extended. Since I have no other Lazo cards, I can't cross-check multiple cards. If you'll successfully authenticate with other keys, make sure to share them here!

sucotronic commented

2026-09-10 12:37:37 +02:00

Author

Thanks for the quick reply!

I actually already tried std.keys and extended-std.keys before opening this issue — that was my first attempt, before I knew about this repo. I mapped all 40 sectors against MCT's extended-std.keys dictionary (2568 keys), which took about an hour due to the dictionary size, and it also came back with an empty key map — no sector authenticated with any of those either.

One more data point that might be useful: I also read the tag with NXP's own TagInfo app, and it identifies the chip specifically as MIFARE Classic EV1 (MF1S70), not a plain/original MIFARE Classic. EV1 has a hardened PRNG, which (if this card is genuinely EV1 silicon rather than a compatible chip mislabeled by TagInfo's heuristics) would explain why a plain darkside attack might not work and why hardnested would be needed to recover the first key from scratch.

Combined with the 4-byte UID mismatch (vs. the 7-byte UID documented here for Lazo), my guess is this is either an older batch predating the documented one, or a different chip revision entirely (EV1 vs. original S70) that also got new keys at the same time.

I'm going to pick up a cheap PN532/Proxmark clone to attempt a hardnested attack and try to recover at least one valid key. Will report back here with whatever I find (working keys or a full dump) either way, positive or negative, so this can help cross-check against other cards.

Thanks for the quick reply! I actually already tried std.keys and extended-std.keys before opening this issue — that was my first attempt, before I knew about this repo. I mapped all 40 sectors against MCT's extended-std.keys dictionary (2568 keys), which took about an hour due to the dictionary size, and it also came back with an empty key map — no sector authenticated with any of those either. One more data point that might be useful: I also read the tag with NXP's own TagInfo app, and it identifies the chip specifically as MIFARE Classic EV1 (MF1S70), not a plain/original MIFARE Classic. EV1 has a hardened PRNG, which (if this card is genuinely EV1 silicon rather than a compatible chip mislabeled by TagInfo's heuristics) would explain why a plain darkside attack might not work and why hardnested would be needed to recover the first key from scratch. Combined with the 4-byte UID mismatch (vs. the 7-byte UID documented here for Lazo), my guess is this is either an older batch predating the documented one, or a different chip revision entirely (EV1 vs. original S70) that also got new keys at the same time. I'm going to pick up a cheap PN532/Proxmark clone to attempt a hardnested attack and try to recover at least one valid key. Will report back here with whatever I find (working keys or a full dump) either way, positive or negative, so this can help cross-check against other cards.

Rows
Columns

Lazo card with 4-byte UID doesn't match documented keys (possible different batch) #1