Proxmark3 community

Research, development and trades concerning the powerful Proxmark3 device.

Remember; sharing is caring. Bring something back to the community.

"Learn the tools of the trade the hard way." +Fravia

You are not logged in.


Time changes and with it the technology
Proxmark3 @ discord

Users of this forum, please be aware that information stored on this site is not private.

#1 2016-09-30 04:58:57

Registered: 2016-09-04
Posts: 52

Forced-delay by Calypso's Reader/Writer


I think it would essentialy be or Iceman1001 here but if anyone still works on is to have an idea on this case, it would be very interesting to read.

Tag is a fully working Calypso's RATP B Tag (not B', new one heh) which used to work flawlessly in the past with RATP,
and Being Correctly snooped by Iceman1001 build, tested after his last work on calypso.
Reading was a pain, but is so much dependant on dunno what but totally capricious and Tag dependant, but still it was of no incidence on Snooping or Raw commands.

So trying to provide a bunch of new snoop while making reload of the monthly contract, snooping didn't got trace of the communication... but most strange, snooping also made a very strange and Long delay of the Writer, making it confirming then-not confirming the monthly contract update, and the trace being of 0 byte.
Update was made again with very same results.
Thirst try was too much near the happyhelpers called by my following customers not really understanding why it took so long, and as siscrete as possible, still don't wanted to show a snooping trace to the RATP's helpers, so hmm

More strange now after the ok reload with no snoop on :
- The already in place for long ago readers where still able to snoop on the communication with no probleme
- Any try in snooping "Big" new readers which are everywhere be placed in Near-Paris RER Stops when in large ways to propose being read during the walk made the very same behavior, making strange delay, sometime more that 45s long, then strange behavior like two ok Beep, then nothing, then no light, then what may have been Reader WDT Reset.
It gives 0byte trace.

Any idea on why it may act like that ?
Snooping should be of no consequence in my remembering as coil is passive ? Or could it be detected as "reader" or "snooper" even if the reader itself can't be moving to compare fields and ensure detection of such, and even being sure this "interference" may not be anything but a a snooper ?

As it been already seen on other case?
I'm getting quite annoyed that working on calypso case is always something of ununderstable and unconsistant matter.


#2 2016-09-30 07:50:50

Registered: 2013-04-25
Posts: 9,501

Re: Forced-delay by Calypso's Reader/Writer

Interesting stuff, I'vent heard of anyone working on calypso for the pm3.   I'll go back to this once I finish my legic changes.


#3 2016-09-30 09:30:49

Registered: 2016-09-04
Posts: 52

Re: Forced-delay by Calypso's Reader/Writer

The girlfreidn got the same calypso series but their is something like always readable, but never usable.
Note that our navigo rfid as strong history of very weird behavior, a lot of time making everyone very angry because of total inconsistnce between reader behavior, or even in the very same condition.

This was totally a normal thing for these to not be expected to work when we had the B' only tags. It has gotten better with month and then new reader, big, slow, are making what I expect to be at least an homage of how bad it was.

Maybe that is a new form of security, which may be even more


Board footer

Powered by FluxBB