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€ 