Does it not work with running "make install" and then just using -lnfc in the gcc line?
1 2010-10-13 20:20:54
Re: Using libnfc in Eclipse on a Mac (64bit) (8 replies, posted in Questions and Requests)
2 2010-09-30 08:02:34
Re: [SOLVED] Info about nfc-cryptorf (4 replies, posted in Questions and Requests)
Download the zipfile you can find here:
http://www.libnfc.org/_media/documentat … omemrf.zip
type "make nfc" and you will have your demo app.
3 2010-07-20 10:42:50
Re: Passive target mode initialization *without* secondary reader (3 replies, posted in Hardware Devices)
This is awesome!
I've tried to do this myself, but I didn't got it to work that quickly, when then I was intrigued by other problems I never looked back into it. Great job Tomas! I'll let you know if it works the same with other (PN53x) devices as soon as I find some time to test it.
Keep up the good work!
Cheers, roel
4 2010-07-20 10:24:46
Re: How to emulate a tag with libnfc (2 replies, posted in ISO14443 card emulation)
Hey Chris,
Let me try to answer your questions.
chrissmith51 wrote:
1) The first 3 values received from the reader before anti-collision?
These are values that follow the RATS request. Since we need to "break out" the non-responsive mode of the PN53x chip first, it has to receive a RATS command. After that it will give messages back to the host as feedback where we can handle the anti-collision our self. The OMNIKEY though, still tries to get response from the tag after the RATS. We just ignore those and let the OMNIKEY reader restart.
chrissmith51 wrote:
2) The last value received in the anti-collision (30 00 02 a8)?
This is not a anti-collision request, but a MIFARE Ultralight READ (0x30) BLOCK 0 (0x00) CRC (0x02, 0xa8).
Since the tag is responding as a MIFARE Classic tag, the OMNIKEY reader should first authenticate before sending a READ.
This is a BUG in the (new) driver of the OMNIKEY, try to reinstall the driver with this one. You will see that version 1.1.1.4 will work just fine.
chrissmith51 wrote:
3) Why the Omnikey 5321 is unable to detect the emulated tag at all? It says "no tag present"
Since the tag does not respond on the buggy message the OMNIKEY dismisses the available tag (probably flashes green+red). Updating the OMNIKEY driver should fix the problem 
.
Cheers,
Roel
5 2010-07-15 07:37:54
Re: [Call for Testers] Announcing Mifare DESFire support in libfreefare! (21 replies, posted in NXP MIFARE DESFire)
Great work Romain!
It is nice to see that related projects seem to get more and more body every day 
Maybe I can help you in the future with some new cards (like the Plus and the Ultralight C).
Cheers,
Roel
6 2010-07-14 07:24:49
Re: SWM1703 device support (2 replies, posted in Hardware Devices)
It seems that SWM1703 is a NFC controller (with embedded CPU, SWP, etc.) produced by polaric.
Since there are no datasheets available yet, we can not say anything about support for it right now.
7 2010-07-12 08:32:10
Re: MySnapper 1.0.2 released (4 replies, posted in External projects that use libnfc)
Great, thank you again for info. We want to update the website with better information about projects that are using libnfc. I assume that your company (Snapper) has no problem if we mention and link to the product website?
Cheers, Roel
8 2010-07-09 12:49:55
Re: MySnapper 1.0.2 released (4 replies, posted in External projects that use libnfc)
Thank you for informing the community about this development. It is a pleasure to see that we can inspire non-commercial as well as commercial projects. We hope to support all the developers that use libnfc.
Is it possible for us to point out the signed libusb-win32 driver for PN531 devices? Is this a generic driver, or did your company pay for the certification expenses?
Thank you again very much for your contributions and support!
Cheers, Roel
9 2010-07-06 11:10:43
Re: nfc-relay (3 replies, posted in Questions and Requests)
Dear chrissmith51,
Relaying a passport involves some difficulties.
First of all, there is the timing problem. Since the firmware in the Omnikey requires the (emulated-)tag to respond within a few milliseconds, it could occur that it times out for the host before finishing the setup procedure (initialization during the anti-collision fase). Secondly, the passport uses a ISO/IEC 14443-4 type A, layer '4' requires a extra acknowledgment between the reader and tag that describes some functionality like the transmission speed. Since the current nfc-relay demo is a simple example using the (low-speed) 106 Kbps in stead of the newer 212, 424 or 848 speeds it could break end up in a incorrect transaction when the ATS from the passport describes a higher speed to use than the 106.
Personally I was able to fix this problem just by replacing the RATS message by a dummy answer (with no speed change). But the (reading img) frames for the passport seems to be very long, so I ran into buffer problems later on.
I hope you can figure out the problems you have right now, we will probably soon release some more solid examples for the more advanced features of libnfc (relay, p2p).
Cheers,
Roel
10 2010-05-12 11:21:40
Re: [SOLVED] ATS of ISO14443-A too long? (2 replies, posted in Problems, Bugs and Fixes)
Would it be possible to use "--enable-debug" as ./configure parameter, run the same test and post the debug log here in this thread?
This would help us a lot while investigating this problem.
11 2010-05-12 11:12:36
Re: [SOLVED] nfc_initiator_deselect_tag (15 replies, posted in Problems, Bugs and Fixes)
Great, good to hear you got it working!
12 2010-05-12 11:10:52
Re: ACS ACR122U on OS X (7 replies, posted in Hardware Devices)
Hey zarafa,
This is mainly because you are using the 2.0x (firmware) version of the ACR122U reader. Sadly it is not possible to change this firmware to the older 1.0x releases. The newer version do work, but they require use of a strange feature in the pc/sc protocol, namely the Escape Command.
More info about how to enable this (in linux?) is available here:
http://wiki.yobi.be/wiki/RFID#ACR122U_PICC
In Mac OS X there seems to be not much information about how to use this. So if you get it to work, please let us know, so we can add a fix/howto to this page. If you rather want to use a (more stable) older firmware version of this reader, try to get your hands on a touchatag
Let me know if you have more problems / comments.
Cheers,
Roel
13 2010-04-07 15:29:53
Re: Tag emulation with ACR122 (4 replies, posted in Questions and Requests)
Dear TR44,
Thank you for your question.
The short answer to this is: use a different reader (not a Nokia phone) to test.
The long answer is: Because the ACR122 usb-hardware (and corresponding host-pc usb-software stack) is not fast enough, it will not respond with the ATQA in time. More about the anti-collision can be found in this example. This is not really solvable by keep using the (slow) usb-interface. The PN533 dongles for example, have direct USB support, they are twice as fast as the ACR122 readers in USB communication. But this is still around 5 times to slow to be in time for a Nokia phone (or e.g. public transport gate) to respond in time.
If you use two ACR122 readers, you can use the nfc-anticol example and the nfc-emulate together. They will show that with enough patient, the proof-of-concept works. To make this work for fast readers you should use a hardware specific device like the mikeycard for example. This will use a dedicated uC communicates fast over the SPI, I2C or USART connection to the PN53x chip itself.
I hope this answers the question for you?
Best regards,
Roel
14 2010-03-27 18:37:00
Re: MiFare Pegoda (2 replies, posted in Hardware Devices)
Hey Brett,
A)
No, this is the old chip from philips (NXP), it is more than 10 years old and does not support the advanced firmware features that are used in libnfc to send raw frames
B)
No experience, but you probably have to do this in hardware (set registers, raise a certain pin to ignore ISO14443-A parity-errors).
C)
Make sure you buy a PN53x compatible reader. The New Zealand "Snapper Feeder" readers are compatible. Try to get your hands on one of those. Or...check out this page
Cheers,
Roel
15 2010-02-01 12:58:24
Re: Where to buy NXP PN533 semiconductors? (7 replies, posted in Questions and Requests)
Hey Hey,
Well here you can order them for all kind of quantity from avnet.
A friend of my ordered around twenty PN532 chips by Jarry.
Shipment went well, though not very professional packaged. He seems also to sell the PN533
He is currently working on the mikey card, I try to help him where I can, but hard for me to find time.
Can you tell us more about your project?
Thanks a lot in advance, cheers,
Roel
16 2010-02-01 12:02:09
Re: Where to buy NXP PN533 semiconductors? (7 replies, posted in Questions and Requests)
I have some addresses laying around, I'll look them up later today.
Are you willing to tell me more about the device/application you are designing?
There are currently a few projects already, maybe you can join/help.
17 2010-02-01 10:48:44
Re: Where to buy NXP PN533 semiconductors? (7 replies, posted in Questions and Requests)
You can order an example package here.
But a cheaper way is to order a SCR3711 which also uses a PN533 and is libnfc compatible
18 2010-02-01 10:05:40
Re: Nested Authentication (11 replies, posted in NXP MIFARE Classic)
can you post your complete code, so I could test it?
19 2010-01-21 09:06:24
Re: Nested Authentication (11 replies, posted in NXP MIFARE Classic)
Hey telesfor,
The best way to find your mistake is to compare with working code. The guys from Nethemba released their nested authentication tool. I guess it would be useful to compare their results with your own code.
Let me know if this fixes your problem.
Cheers,
Roel
20 2010-01-05 09:23:09
Re: Addition of details to PN53X-Chip page (2 replies, posted in Website Feedback)
You are totally right. But I guess you can better blame NXP than us
I suspect it has something to do with the licenses. The NXP chip can emulate their own MIFARE but not a -B card, but since they corporate with Sony, it does support FeliCa though. It seems to look like something Patent/License related. If I look to the register/raw settings, I come to the conclusion that the chip actually CAN emulate a -B card. But... it means you have to do everything in low-level and probably walk into lot's of side-problems like timings again.
The best way to emulate a -B card, is using the proxmark. Besides this you could try to use the ISO14443 (layer4), since A or B does not matter here. The E-passport for example could work on both modulations, it just uses the layer on top of this and sends APDU's. Most PayPass/Visa readers are A / B compatible.
Well, for what it's worth, I hope this helps
21 2009-11-17 21:30:09
Re: Mifare Classic Key Recovery tool - "Dark Side" Attack (60 replies, posted in NXP MIFARE Classic)
it works perfectly under linux/mac!
Just needed a Makefile.
Check out:
http://code.google.com/p/tk-libnfc-crap … etail?id=1
22 2009-11-15 21:27:54
Re: Mifare Classic Key Recovery tool - "Dark Side" Attack (60 replies, posted in NXP MIFARE Classic)
Thank you very much for making this project zveriu.
It needs just a few minor tweaks I guess to make it running on all platforms, but it windows it seems to work fine
Though it is kind of confusing that it asks for a "key" and a "block", the block I understand, but the key is going to be recovered right?
23 2009-11-15 21:07:50
Re: Mifare Classic Key Recovery tool - "Dark Side" Attack (60 replies, posted in NXP MIFARE Classic)
zveriu wrote:
1. For the sake of shortening the release time, the windows version of the .c files was released, i.e. it is a version is uses Sleep() function from windows.h. If you have MS Visual Studio 2005/2008, you can use it with vs-2005 solution of libnfc
The following code should be a portable sleep (Windows, Mac OS X, Linux, BSD, etc.)
// Set time-out on 30 miliseconds
const struct timeval timeout = {
.tv_sec = 0, // 0 second
.tv_usec = 30000 // 30000 micro seconds
};
void test()
{
struct timeval tv = timeout;
select(0,NULL,NULL,NULL,&tv);
}NOTE: do not trust the content of struct timeval tv after the running the select() function!
24 2009-11-15 19:18:00
Re: Mifare Classic Key Recovery tool - "Dark Side" Attack (60 replies, posted in NXP MIFARE Classic)
The code seems for windows "only" at the moment.
Are you using the current (SVN) version of libnfc?
25 2009-11-14 00:38:39
Topic: uart (serial / rs232) portability (2 replies, posted in Problems, Bugs and Fixes)
It is almost unbelievable!
UNIX has support for the select() function. Windows does support select, although not for all descriptors (it does for sockets, but not serial ports).
So the u(s)art implementation and support is different for windows and UNIX. I knew I had to live with that. But now there seems to be a serious problem with the select() function. It seems that linux chose to do some implementations different from other UNIX systems (like SUN / BSD / MAC OS X). The last parameter of select(), which is the timeout value, is not a const value, I already noticed that. But since there seems to be no sense in changing this value, it is assumed by other (UNIX) systems, the timeout stays the same. Linux though decided to change the value in the "struct timeval". So we need to reset / restore all the parameters every time we are going to fire the select() operation.
Well anyway, now I know, my code was easily fixed, but it took me a while before I understood the problem.
The new version of uart.c in the SVN should be ok and compatible with all major operating systems.
Cheers,
Roel
ps. more info about this specification was found here.