Oh you’re right sorry, but yeah it will be nice to can copy on empty tag in 13.56 MHz bc with the ACR122U writer/reader i already make one for VIGIK reader and it work fine. Even the original after tru with my clone. 
1 Like
Hi,
did you make it on your flipper zero or on an other device ?
like our friend said, in france most of the building are on Vigid (or intratone) it would be great to use our flipper on it.
greatings.
1 Like
Any news on this topic? Any chance on using flipper on vigik? I managed to read my vigik building key, all keys, all sectors, but doesn’t seem to work, and the flipper won’t read/detect the reader.
Hoping someone will have some news!
Hi
I have the same issue with some mifare Classic 1k
I tried with reader who only use the “UID” and its working perfectly but when the reader actually use the data stored in the card to authentify it was a failed
I think the flipper don’t send the data with the right “time gap” between each key and that’s why the reader don’t see it as the right card
it seems to be a software problem and not an hardware problem but not sure of that.
This is not the case. The issue is that the reader’s frequency may not exactly match 13.56MHz, and if it doesn’t - it will get out of sync wit the Flipper’s emulation. Flipper Zero has no way to detect the specific frequency of the reader and adapt to it, so it won’t work with some readers just because of that. This cannot be fixed via software.
2 Likes
Ohh Ok thank you
It looks like the reader does detect the emulated card - it blinks red when presented. But for some reason something doesn’t work afterwards. Proxmark emulation fails the same way for those readers, by the way…
If this can help, here is the start of the badge/reader traffic with a real badge:
106394128 | 106395184 | Rdr |26(7) | | REQA
106419856 | 106420912 | Rdr |26(7) | | REQA
106422084 | 106424452 | Tag |04 00 | |
106429712 | 106432176 | Rdr |93 20 | | ANTICOLL
106433348 | 106439236 | Tag |4e ac 3c ab 75 | |
106445584 | 106456048 | Rdr |93 70 4e ac 3c ab 75 7f 00 | ok | SELECT_UID
106457284 | 106460804 | Tag |08 b6 dd | |
106465040 | 106469808 | Rdr |50 00 57 cd | ok | HALT
106494736 | 106495728 | Rdr |52(7) | | WUPA
106496964 | 106499332 | Tag |04 00 | |
106504592 | 106515056 | Rdr |93 70 4e ac 3c ab 75 7f 00 | ok | SELECT_UID
106516292 | 106519812 | Tag |08 b6 dd | |
106529808 | 106534512 | Rdr |60 00 f5 7b | ok | AUTH-A(0)
106536516 | 106541252 | Tag |88 54 9f 91 | |
Whereas with the Flipper, the reader seems to give up pretty fast:
31727440 | 31729904 | Rdr |93 20 | | ANTICOLL
31731108 | 31736996 | Tag |4e ac 3c ab 75 | |
31740624 | 31743088 | Rdr |93 20 | | ANTICOLL
31744292 | 31750180 | Tag |4e ac 3c ab 75 | |
31756496 | 31766960 | Rdr |93 70 4e ac 3c ab 75 7f 00 | ok | SELECT_UID
31768228 | 31771748 | Tag |08 b6 dd | |
31775952 | 31780720 | Rdr |50 00 57 cd | ok | HALT
31805648 | 31806640 | Rdr |52(7) | | WUPA
31807908 | 31810276 | Tag |04 00 | |
31815504 | 31825968 | Rdr |93 70 4e ac 3c ab 75 7f 00 | ok | SELECT_UID
31827236 | 31829732 | Tag |08 b6 01 | |
32269872 | 32270928 | Rdr |26(7) | | REQA
32272132 | 32274500 | Tag |04 00 | |
32277168 | 32278224 | Rdr |26(7) | | REQA
32302896 | 32303952 | Rdr |26(7) | | REQA
32305156 | 32307524 | Tag |04 00 | |
Not sure whether this is because the reader frequency is not tuned to the Flipper and communications are not working properly, or for another reason…
There is a CRC error at some point in the anticollision loop for the Flipper Zero (08 b6 01, should be 08 b6 dd)
my 2 cents
Yes, I think it’s just a capture artifact by the Proxmark…
If that’s the case then, the issue is that currently, there is no way to have the correct frequency for those NFC readers, and the Flipper cannot find the proper frequency hence results in the failure of the emulation.
If so, is there any way with another device, to measure the frequency of an exchange between a Mifare Classic badge that successfully works with the reader, perhaps using any SDR (Software Defined Radio) with such a project perhaps : GitHub - josevcm/nfc-laboratory: NFC signal and protocol analyzer using SDR receiver ? Or would that be useless?
We could measure those exact frequencies and built a database of non-standard frequencies for VIGIK readers.
Hence, blowing away the requirement for the Flipper Zero to detect the specific frequency of the reader (since it cannot) and have the frequencies be measured, available as just a data file in the SD card, just like the Mifare Classic key dictionnary.
But I don’t know if the way that the NFC emulation works at the moment, if it’s possible to tweak the NFC simulation to another frequency that isn’t exactly 13.56MHz or is that frequency not something that can be tweaked in the firmware ?
1 Like
Hi,
Does this clearly mean that we have to wait for a new hardware version of Flipper zero to solve this problem?
Hello there, any news about this ?
I was wondering if writing on a RFID card, badge or something could bypass the frequency problem ?
Yes that should work as a card is a passive element and Flipper is not. It uses its fixed frequency whereas a copy card just reacts “in time” to the reader.
Is someone planning to determine the reader’s pattern? I don’t have an SDR I could use but I would gladly check someone’s capture.
Just out of curiosity was anything ever solved about this issue? Reading through the comments there isn’t a very clear answer. I’m experiencing the exact issue . French apartment. Trying to copy my own Fob . The NFC copies perfectly to my Flipper, but can’t emulate when presented to the reader. Any tips ?
Most times if the Flipper can emulate a card but get not recognised by the reader, in my case, it is a trimming issue.
For reference, see https://github.com/RfidResearchGroup/ChameleonUltra/blob/main/docs/technical_whitepaper.md#ultra-fast-response-speed-and-low-interaction-delaymifare-classic
1 Like
FYI this issue is tracked on GitHub
In my case, on a Urmet Vigik reader, emulation worked with firmware 0.87 then 0.94.1 introduced a regression and broked the feature. Now on my side the emulation works again after the 0.97.1 update.
Have you checked if your reader has an anti-copy protection? Because I also have one of those and it works by not only reading your badge but also writing to it and flipper zero doesn’t support writing through emulation (and I think it doesn’t need too because it could make the original badge unusable)
To check if that’s the case, the simplest way is to read your badge with the Mifare Classic Tool (MCT) app on an Android phone and save your dump.
Then after few days of using your badge, dump it again with MCT and compare both dumps: if you notice differences, then you have a anti-copy protection and can’t emulate your cloned badge.
Emulation is working fine now with the latest version of the firmware
I believe what @theblackhole says here makes a lot of sense.
I do see the reader react, but it doesn’t acknowledge the emulation.
After doing some tests with a Magic Ultimate card (gen4), and despite being careful, I hit a copy protection and both the fob and the card stopped being recognized (despite the card having worked once). From that point on, when trying to use any of those produced the same behavior as using the emulation.
It would thus make sense that the reader does see the emulation, but requires a write ack or exchange to validate a counter being incremented, and won’t accept a fob unless this write is acknowledged. This would be imperative for the copy protection to avoid accidentally flagging fobs because they didn’t update their counters for some reason. Better deny access and try again 0.3s later than locking people out of their homes.
As Vigik is a french standard on top of NFC, it would make sense that almost all French residences equiped with a vigik reader would require a counter increment of some sort, and thus emulation being unable to ack this counter increment would make any “Vigik” reader interaction impossible.
Without a reader-side debug analysis I don’t think we’ll be able to rule out “improper emulation” from “lack of counter write ack” for Vigik readers.
…Now what’s left for me to do is digging deeper into the Vigik specs to find where my test/assumptions went wrong in locking my fob 
But that’s slightly offtopic.
As Vigik is a french standard on top of NFC, it would make sense that almost all French residences equiped with a vigik reader would require a counter increment of some sort
I don’t believe that anti-copy protection is a Vigik standard, but rather an additional option provided by manufacturers (Urmet, Intratone, Kone, etc…). Or if it is a Vigik standard, its activation must surely be optional because I have seen both new residences which do not have this protection and old ones (with older readers) which do.
In any case I wonder how you managed to block your 2 badges. Generally it is the one which is no longer up to date that become unusable (often the original if the copy is used), the other continues to function, as explained in this simplified diagram (in French): Qu'est ce que l'anti-copie ? — mesbadges.com
Perhaps the way to deactivate the badges depends on the brand (and would confirm my theory that it is not a Vigik standard): maybe some only deactivate one of the 2 (by only checking if the bit previously written is valid), others could not only do the same check but also from the moment it detect that a badge is duplicated (e.g. If the reader read an old value that has already been read before), it deactivate both badges by blacklisting the ID.
But that’s just a therory that I can’t verify because Vigik specifications are only available to manufacturers for the modest sum of 500€ 