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
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.
I would like to express here what I would like to be implemented/improved in future proxmark3 releases; if more than 1 would like to have the same features we can team-up to make them see the light:
HF
- add ISO15693 simulation
- add EPA support (acutal epa is 100% not working for the epa tested by me and a few other people); EPAs are a kind of smart card, you need to know which commands to send and read the response; datasheets (more and less full) are available.
- Mifare Desfire implementation
- Calypso implementation (Calypso probably uses ISO14443B protocol in latest versions; probably earlier versions uses proprietary Innovatron ISO14443B')
- complete Jewel/Topaz support (specially sim command - almost done thanks to the great piwi work)
- add mifare ultralight/ev1/NTAG simulation (pm3 can do that)
- add Sony FeliCa support (technical datasheets available)
- EMV implementation (visa,mastercard - Peter filmoore has one laying around)
- iClass write
- detection of Mifare Classic NACK bug
LF
- improve PCF support (datsheets are available for some tags - maybe iZsh will comes in hand!)
- converting a LF tagnumber (printed number) into complete or partial clone command
- LF sim with a "bruteforce" mode where you can set the facilitycode and simulating the ID in a bruteforcing-way
- EM4x50 full read/write/password
- LF T55x7 password sniff
- EM4x05 full read/write/password
- LF T55XX bruteforce on the password (or analysing the time it takes)
Software Improvements
- A pipe buffer (that you could keep the transaction log on one file in the computer, not in the internal atmel´s buffer)
- Someway of fuzzing protocols.
- Side-channel/power analysis attacks support.
If you have any (feasible) request feel free to post it here. I will update this post adding new (again, feasible, ex. "Make coffee" will not be taken in consideration ) requests and the number of people interested.
Last edited by asper (2015-10-17 17:26:24)
- implementation of Mifare Desfire.
- implementation of EMV (visa,mastercard) Peter filmoore has one laying around. Would love to get that one in the Master.
- implementation of Calypso. (full datasheets needed.)
A pipe buffer (that you could keep the transaction log on one file in the computer, not in the internal atmel´s buffer)
this could keep bigger tansactions logs, because you will use your hdd instead the atmel's memory
LF:
EM4x50 full read/write/password
EM4x05 full read/write/password
HF:
iClass write
UHF: (i know i'm dreaming)
Lol. Look what I started... UHF would need a hardware change, probably a significant one. But it would be a cool device if we could re-use all the pm3 code and have UHF.
When it comes to the wish for better PCF support, it seems this will be solved when iZsh commits his improved PCF functionality.
so thats kind of cool.
Otherwise I must just say that the PM3 has evolved so much in the last year. Nowdays is more about adding protocols then figuring out why basic stuff doesn't work or if it was suppose to be like that.
I think @asper can edit the UL/NTAG sim request...
Back to suggestions:
Marshmellow mentioned once that he wanted to see a LF T55XX bruteforce on the password. Or analysing the time it takes...
I would like to see converting a LF tagnumber (printed number) into complete or partial clone command?! If you understand what I'm aiming at.
Also the old LF sim with a "bruteforce" mode where you set the facilitycode and simulating in a bruteforce manor the id...
Hi guys,
I would love to see a Calypso implementation (v. ISO14443B) come out.
Fuzzing capabilities would be great as well.
I'm starter with Proxmark3 but I was about to try to reverse (using fuzzing?) a calypso implementation (the one that is used in travel card in Paris) so I'd be glad to help/team-up/do something.
I would like to see converting a LF tagnumber (printed number) into complete or partial clone command?! If you understand what I'm aiming at.
Also the old LF sim with a "bruteforce" mode where you set the facilitycode and simulating in a bruteforce manor the id...
the challenge with this is what format should we make? there are literally hundreds.
handling them via the raw wiegand data covers all of them, which is why the commands are the way they are.
I think @asper can edit the UL/NTAG sim request...
granted this hasn't made it's way to the main trunk yet...
Hi guys,
I would love to see a Calypso implementation (v. ISO14443B) come out.
Fuzzing capabilities would be great as well.
I'm starter with Proxmark3 but I was about to try to reverse (using fuzzing?) a calypso implementation (the one that is used in travel card in Paris) so I'd be glad to help/team-up/do something.
a good start would be to get a snoop of the transactions and post them on the forum in the Calypso section. now that 14b is working well if the tags are fully 14b it should be semi easy to make some progress.
Well @marshmellow, I got my wish for a UL/NTAG sim. If it makes its way to PM3 master is another thing.
With @pwpiwi 's fpga compress is finished, that has opened up some more possibilities.
I thought they used 14b' in the past but moved to 14b recently. To be sure I would like
to get '14b snoop' working.
I tried to snoop a transaction but I always obtain a weird error message:
proxmark3> hf 14b snoop
#db# Snooping buffers initialized:
#db# Trace: 39360 bytes
#db# Reader -> tag: 256 bytes
#db# tag -> Reader: 256 bytes
#db# DMA: 128 bytes
#db# blew circular buffer! behindBy=0x74
#db# Snoop statistics:
#db# Max behind by: 116
#db# Uart State: 0
#db# Uart ByteCnt: 0
#db# Uart ByteCntMax: 256
#db# Trace length: 0
Maybe we could start by fixing this?
Update your firmware. It IS fixed.
I thought they used 14b' in the past but moved to 14b recently. To be sure I would like
to get '14b snoop' working.
I tried to snoop a transaction but I always obtain a weird error message:
proxmark3> hf 14b snoop
#db# Snooping buffers initialized:
#db# Trace: 39360 bytes
#db# Reader -> tag: 256 bytes
#db# tag -> Reader: 256 bytes
#db# DMA: 128 bytes
#db# blew circular buffer! behindBy=0x74
#db# Snoop statistics:
#db# Max behind by: 116
#db# Uart State: 0
#db# Uart ByteCnt: 0
#db# Uart ByteCntMax: 256
#db# Trace length: 0
Here is my config:
http://sebsauvage.net/paste/?73f80ed23271fa3e#lGP+oZ2Rwty1hn2yarAjBlQsHbBWjpsITDlh5cPR6kQ=
[EDIT]
This is actually a serious issue. I'm trying to solve it here: http://www.proxmark.org/forum/viewtopic.php?id=2487
I must solve it before beeing able to snoop a full Calypso transaction (RATP or Velib), really frustrating
[/EDIT]
Last edited by lutcheti (2015-07-13 11:28:26)
i have a Request: hf snoop
a generic recording of HF samples regardless of the protocol. for use with tags that we don't know the protocol yet. (sielox.. others)
is it a question of buffer space? it seems like something like this used to exist (hisamples?) i'm going to start digging up some old info on this.
but i remember piwi recently said that passing hf samples (specifically regarding ISO 14b) to the client for demod couldn't work due to speed? maybe?
Hi, this is my first message on this forum, I vote +1 for request of marshmellow.
There is also a patch from another user, never released in master branch, here http://proxmark.org/forum/viewtopic.php?id=1945 maybe is useful
Regarding "HF SNOOP"
https://github.com/EnioArda/proxmark3/commit/1bae666bcfaeab3b86c5a64bb150559862e1089d
Enio's fork had a HF SNOOP implemented, and it got merged, but I can't see it anymore in PM3 master..
lf snoop got merged, but I don't see hf snoop ever getting finished.
Yeah, it was something about splitting up the fpga firmware into a LF and a HF part at that time when Enio was doing this.
There has been changes to the HF part in the FPGA since then, so his adaptations might not work straight up.
But with the memory saving changes with the new BigBuff, the HF snooping might actually be able to snoop complete transactions. I remember that this also was an issue with hf snooping at the time.
Regarding "HF SNOOP"
https://github.com/EnioArda/proxmark3/commit/1bae666bcfaeab3b86c5a64bb150559862e1089d
Enio's fork had a HF SNOOP implemented, and it got merged, but I can't see it anymore in PM3 master..
Nope, it never got merged into master. And afaik, he never did a pull request on it, I don't think he ever considered it finished enough to "officially" submit it, and noone took up on it. Personally, it's not of much value to me (I'd rather use an oscilloscope or my Saleae pro logic), so I haven't put in the time that would be required to make it work.
And yes, he implemented it as an LF-mode, only because of addressing issues (no more flag-space in HF-section). That was a bit awkward, I pinged him a few months back that there now was 'space' available in HF, if he would want to continue with it.
i guess i'll have to find myself a good oscilloscope and learn it...
we have iclass write now (it works most of the time...)
it can be crossed off.
@apt-get See the threshold setting of lf config. It works. (if set properly it should search until the antenna picks up something, then it will attempt all known demods on the captured data) but doing it for more than one tag would be too slow and the output too long to be useful with the current device and implementation.
Last edited by marshmellow (2016-02-23 22:19:48)