weird thing the ACR122U does when you place a tag onto it windows then beeps (connected device noise) so it dosnt appear to be active until the tag is there and only while its within the field
1 Like
naa the ACR122U is properly connected at all times… when the red light comes on, this means the driver is working, the OS is talking to the reader, and the reader is looking for tags… the sound is windows detecting the tag… the tag is the “new device”… there is a whole smartcard infrastructure built into windows… in fact, you can check the registry to see new registry keys and entries appear for each tag you present. fun!
2 Likes
I actually can’t see how you could accomplish that with the proxmark3… can it be seen by Windows as a legitimate reader that the OS understands is a reader? The ACR122U is definitely a worth while reader to have if you are wanting to do anything with desktop applications.
2 Likes
I didnt mean that the card reader was not connected im sorry if I gave that impression. I just didn’t want it to throw people like it did me the first time, then realising as you said it was detecting the card as the new device.
2 Likes
good point @amal - now that I think about it, PM3 does need to be issued CLI cmds to trigger it into operations - even for reading the tags. Consequently, it does not surface itself as an always-on reader (per se). I have been using my S10+ NFC Tools Pro app for all the reading thus far.
this begs to renew my question then.
- I think if I need a reader/writer to be always on/app responsive, looks like I will need something like an ACR.
- For in-depth programming and config level workflow, I will need the PM3.
is that an accurate observation ?
can ACR handle (with the “right app(s)”) the programming / config workflows ?
Am I sounding like I am trying to figure reasons to return my PM3 back (
) - perhaps
thanks guys
I have a wrapper I am working on in python to interact with the CLI for you as part of my PM3 GUI project… The ACR seems like a better option though.
1 Like
Sure you can: get coding You can do anything with a PM3 that you can do with an ACR122U. It’s just that you’re going to do all the low-level bits yourself, either in the FPGA or in software PC-side. And then probably all the higher level bits also…
The Proxmark is essentially a specialized digitizer: it samples the carrier and ships the data across the USB port to the PM3 client, that does the heavy lifting (demodulating, interpreting, etc…) When sending something to the transponder, it’s done the other way round (PC determines the waveform, sends it to the PM3 that plays it to the device). The only “evolved” operations that are handled by the PM3 itself are the ones that can’t wait for the data to be ferried to and from the PC.
Standard readers do all that in their firmware, and talk to the PC at a higher level (CCID). But they’re not as flexible - because they don’t need to be.
Your best bet if you wanted to use the PM3 as a “normal” reader would be to make a CCID emulation layer and register it as a PC/SC driver for applications to use normally. I’ve been toying with the idea for a while: But it’s a major undertaking. Still, if you want to do it, it’s possible
1 Like
The pm3_listener() process in the SiRFIDaL server does exactly that also: it spawn a PM3 client and talks to it through a pseudo tty, to send it commands and capture its output, if that can be a source of inspiration.
There are commands in the PM3 client to connect to HF transponders, leave the field on and send raw commands afterwards. Not enough to achieve what the OP wants to do though, I believe. But I haven’t looked into them in detail.
1 Like
ACR122U’s are pretty well supported, moreso than a PM3 for sure.
Just note they’re not the “best” - get a Feitian if you can. They’re not significantly more expensive but they provide proper extended APDU support and proper wait timeouts - see my post (Fix for ACR122U Time Extension) for a workaround on the ACR122U. Not much help if you’re doing random generic commands that could at any point time the reader out, though.
2 Likes
@fraggersparks - thank you for sharing your experience. I have placed an order for Feitian. I was looking in their website, is there a developer SDK page or forum - perhaps in github or someplace? I looked in github, but, nothing there from official Feitian.
Thanks
2 Likes
It’s all PCSC compliant, so there’s nothing really needed. Linux/Windows/Mac all have compliant drivers.
EDIT: From there, you use the PCSC library in C/whatever. If you want to go higher up on the stack, APDU is where you’d go for writing applets. I’m not sure how DesFire apps are written - but a lot of what you want to do is something we’re exploring via the Apex line (we already have MFA and SSH/WebAuthN/other credential methods are well on their way).
EDIT 2: I did some additional research, it looks like DESFire is mostly MF/EF as per ISO7816 - I’m not sure how many applications you’d be able to do for your project.
Also, don’t get rid of your PM3 RDV4. Those things are amazing. If you do want to get rid of it though - PM me, I’m in the market for one.
2 Likes
In general, what RFID SDK libs do you all use when developing apps or services? I am mostly on Windows, WSL, and do dockerize my Linux, Debian, etc environments for non-Windows dev. I am fluent in C, C++, C# and Python. My ASM is rusty lately (use-it–or–lose-it cause). Just trying to get a feel for what the dev populous in this forum uses. Thanks.
Perhaps this question should live in its own posting. But, thought I’d ask here.
For Win32 stuff, use SCard i think? I believe python has a lot of stuff there for it.
Unfortunately I mainly use Java for what I develop, and I’ve done more work on the cards themselves.
2 Likes
@fraggersparks, thanks. Wrt, “…we’re exploring via the Apex line…” who is we ? Is there a team outside of the Vivokey dev team that is building these apps ? Look forward to learning more.
wrt xDF2, dev capabilities I don’t know what I don’t know. Is there are team here building apps for it ? I am trying to stay away from Vivokey due to its proprietary platform.
thanks
aha - good to know. I love it when the product creators stay hands-on with the maturity of the product. Good testimony to the the product’s commitment to success. So, that makes me want to re-consider the Vivokey platform. Well two questions:
-
I like the xDF2 capsule form factor, it appears that APEX is a strip form factor, which then is more involved implanting process. I am not there yet; Therefore, are there any plans to offer APEX in a Spark type form factor?
-
Vivokey products are tightly coupled w/ your/their platform, I like running the infrastructure in my farm for my own ops. I saw a thread earlier in the forum that speaks to “unlocking” the Vivokey Apex to lend itself to this kinda of a flexibility. Is that still in the works ?
thanks for the input.
Apex will be a line of products in various form factors, including 3mm glass like the xDF2.
The Spark is due to simple necessity, but the Apex allows you to write and deploy your own applets to operate truly autonomously if you want. At that point the platform becomes a nice optional set of services.
got it. Thanks for letting me know.
ok, that is indeed intriguing. Will there still be a requirement to registering the APEX chip with Vivokey ? Is it truly autonomous / decoupled or hybrid ? Thanks
Lastly, when is the estimated timeline for the APEX release, if you and Vivokey are able to share that is.
thanks much
Amal beat me to the answer, but to add further
Yes
so the prefix is the form factor in the DT line
x = xSeries “capsule form factor” as you call it
Flex = Flex “strip form factor” as you call it
Vivokey line
- VivoKey Apex Max will be a 3mm x 13mm glass injectable device
- VivoKey Apex Flex will be an 8mm by Length TBD i think but around 34mm?
ie
Vivokey Apex Max “capsule form factor”
Vivokey Apex Flex “strip form factor”
1 Like