timmerk / libfreefare Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/libfreefare
License: Other
Automatically exported from code.google.com/p/libfreefare
License: Other
Set of default keys has been provided in mifare-classic-format.c and
mifare-classic-write-ndef.c such as
MifareClassicKey default_keys_int[] = {
{ 0xff,0xff,0xff,0xff,0xff,0xff },
{ 0xd3,0xf7,0xd3,0xf7,0xd3,0xf7 },
....
I have 1k mifare classic tag,
instead of using that default set of keys, can i able to use keys dynamically
that is user defined key while formatting and writing. Using the -k option. Is
there any patch?
And after writing data's to the tag default access bit is changed. how can i
set it to default access bit.
Original issue reported on code.google.com by [email protected]
on 25 Apr 2014 at 11:52
In the source for mifare_application_free(), a call to
mifare_application_find() is done. This call could return NULL if malloc()
fails, but mifare_application_free() doesn't check for this condition.
I suggest applying the attached patch.
Original issue reported on code.google.com by [email protected]
on 19 Mar 2014 at 4:09
Attachments:
Hi, when I call mifare_classic_authenticate for Classic 1k (sak 0x88)
everything is fine. But when I do same for Dual interface card i'm getting
"-1" error code and error:
"error libnfc.chip.pn53x Buffer size is too short: 1 available(s), 2 needed"
What can be wrong?
I'm using libnfc 1.7.0 with ACR-122U-A9
Original issue reported on code.google.com by [email protected]
on 20 Dec 2013 at 11:38
If size_t length ist >52 and is dividable by 4 but not by 8 (like
60,68,...,876,...)
enciphered_data_length results in wrong padded data lenght and the read_buffer
is
to small to keep the content.
Here is a q&d printf debug output for your convenience with 60 as length
+++++++++++++++ ENTER read_data command 189 file_no 7 offset 0 lenght 60 cs 1
############### ENTER padded_data_length: nbytes 8 block_size 16
nbytes % block_size)
############### IF branch : (nbytes / block_size) 0
############### IF branch : ((nbytes / block_size) + 1) 1
############### ((nbytes / block_size) + 1) * block_size 16
=============== ENTER enciphered_data_length
=============== nbytes 60, crc_length 4, block_size 16
############### ENTER padded_data_length: nbytes 64 block_size 16
nbytes % block_size)
############### ELSE: nbytes 64
=============== padded_data_length 64
=============== EXIT enciphered_data_length
+++++++++++++++ enciphered_data_length (tag, length, 0) = 64 rember the + 1
later
+++++++++++++++ bytes_received before memcpy = 0
+++++++++++++++ bytes_received after memcpy = 48
+++++++++++++++ bytes_received before memcpy = 48
+++++++++++++++ bytes_received after memcpy = 68
+++++++++++++++ bytes_received after transfer 68 remvember the ++ later on
+++++++++++++++ sr = 69
############### ENTER padded_data_length: nbytes 61 block_size 16
nbytes % block_size)
############### IF branch : (nbytes / block_size) 3
############### IF branch : ((nbytes / block_size) + 1) 4
############### ((nbytes / block_size) + 1) * block_size 64
*** Error in `/test': malloc(): memory corruption: 0x00e2e238 ***
Increasing the padding by one at enciphered_data_length (padded_data_length
(nbytes + crc_length +1, block_size)
instead of (padded_data_length (nbytes + crc_length, block_size)) solves the
problem for me. And I attached a patch
for it. But I am not sure if this patch will be right in every case. In the
case above the resulting buffer size is
80 which is enough to store the data.
While reading the source I also came along that malloc is not checked for
errors.
Also this part makes me wonder if you wanted to use
uint8_t ocs = cs;
if ((MIFARE_DESFIRE (tag)->session_key) && (cs | MDCM_MACED)) {
switch (MIFARE_DESFIRE (tag)->authentication_scheme) {
case AS_LEGACY:
break;
case AS_NEW:
cs = MDCM_PLAIN;
break;
}
}
uint8_t *p = mifare_cryto_preprocess_data (tag, cmd, &__cmd_n, 8, MDCM_PLAIN | CMAC_COMMAND);
cs = ocs;
mifare_cryto_preprocess_data (tag, cmd, &__cmd_n, 8, cs | CMAC_COMMAND)
instead of
mifare_cryto_preprocess_data (tag, cmd, &__cmd_n, 8, MDCM_PLAIN | CMAC_COMMAND)
Thanks in advance,
Bernhard
Original issue reported on code.google.com by [email protected]
on 4 Nov 2014 at 3:41
Attachments:
hey guys,
i use a pn532 board with arduino as a nfc reader. so i played with it a bit and
found the little tool: mifare-desfire-analyze.
now my problem, sometimes i get an error, so here is the debug log:
[...]
debug libnfc.chip.pn53x InDataExchange
debug libnfc.chip.pn53x No timeout
debug libnfc.bus.uart TX: 00 00 ff 0a f6 d4 40 01 90 aa 00 00 01 00 00 b0 00
debug libnfc.bus.uart RX: 00 00 ff 00 ff 00
debug libnfc.chip.pn53x PN53x ACKed
debug libnfc.bus.uart RX: 00 00 ff 15 eb
debug libnfc.bus.uart RX: d5 41
debug libnfc.bus.uart RX: 00 8d b1 f0 47 07 5d 45 23 80 6a 42 13 90 43 11 80 91
af
debug libnfc.bus.uart RX: c6 00
debug libnfc.chip.pn53x InDataExchange
debug libnfc.chip.pn53x No timeout
debug libnfc.bus.uart TX: 00 00 ff 29 d7 d4 40 01 90 af 00 00 20 6a c1 fd 0c 47
9b ea a3 0e e8 b3 cd 0e 8c 0d 46 a0 27 48 01 ce 60 9c 4e f0 85 4a 47 9e c1 ea
6f 00 a0 00
debug libnfc.bus.uart RX: 00 00 00 00 00 00
error libnfc.chip.pn53x Unexpected PN53x reply!
debug libnfc.chip.pn53x InDataExchange
debug libnfc.chip.pn53x No timeout
[...]
and after this one long command, i only get "unexpected pn53x reply"s.
so i checked the source code of the tool.. the command is generated in
"mifare_desfire.c" in "static int authenticate (...)" because of authenticate
with aes.
any idea why this is happend?
greeting
Tobi
Original issue reported on code.google.com by [email protected]
on 9 Aug 2014 at 4:30
Most functions in mifare_classic.c contain a little prelude to check the input
data for sanity:
ASSERT_ACTIVE (tag);
ASSERT_MIFARE_CLASSIC (tag);
Some other functions don't do this. I found that at least the following
functions don't check the state of tag:
mifare_classic_get_trailer_block_permission
mifare_classic_get_data_block_permission
mifare_classic_format_sector
Perhaps I am in err about this, but if the libfreefare really does not perform
any checks here, this might be a bug. Perhaps the problem also affects other
tag types.
Original issue reported on code.google.com by [email protected]
on 18 Mar 2014 at 1:59
Currently, mifare_ultralightc_authenticate() returns -1 and does not touch
errno when authentication fails. This is very strange and probably errorneous
behavior and makes it difficult to do proper error handling.
I suggest to change libfreefare to set errno to EACCES (access denied) if
authentication fails. Attached is a patch that implements this change.
Original issue reported on code.google.com by [email protected]
on 25 Feb 2014 at 12:33
Attachments:
What steps will reproduce the problem?
1. Create an application with AES encryption on DESFIRE EV1 4k card and
authenticate afterwords.
2. Create a file with AES encryption inside the application.
3. Write data into this file by using mifare_desfire_create_std_data_file().
Expected output of the method mifare_desfire-create_std_data_file is simply the
amount of data written to the card. Instead the corresponding function "
returns -1. I also tried mifare_desfire_create_std_data_file_ex with parameter
cs set to MDCM_ENCYPHERED, which had the same effect.
I'm using libfreefare 1.3.4 and libnfc 1.7.0 under Windows 7 64 Bit, both
compiled using MINGW64. The executables and libraries are 32 Bit versions. The
error occurs with libusb as well as using the PC/SC interface. As reader I'm
using several ACR122U-A9. Devices with firmware 2.13 are affected by the
described issue, while devices with firmware 2.10 are working properly (file is
written without any problems). I will invest more time in further
investigations. Does somebody have this problem too? I could also provide a
code snippet if needed.
If I write a file without encryption (MDCM_PLAIN), it also works with firmware
2.13. So it seems to depend on the communcation settings.
Bye, Eike
Original issue reported on code.google.com by [email protected]
on 7 Nov 2013 at 1:30
When making checks:
make check-TESTS
make[2]: Entering directory `.../nfc-tools/git-svn/libfreefare/test'
OOOOOOO/usr/bin/cutter: symbol lookup error: ./.libs/test_mad.so: undefined
symbol: nxp_crc
FAIL: run-test.sh
This is because nxp_crc() is defined as static in libfreefare/mad.c
Same for sector_0x00_crc8() and sector_0x10_crc8()
Issue is solved by removing the keyword "static" in front of those three
functions but I'm not sure it's the right thing to expose those internal
functions.
If they are meant to be internal, why test_mad is calling them?
Original issue reported on code.google.com by [email protected]
on 15 Jan 2013 at 8:12
I got a :
autoreconf: running: /usr/bin/autoconf
configure.ac:46: error: possibly undefined macro: AC_MSG_ERROR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1
What steps will reproduce the problem?
1. git clone
2. autoreconf -vis
3. read error message on your screen
What version of the product are you using? On what operating system?
Version ea496c4 on Debian 7.0.
Original issue reported on code.google.com by [email protected]
on 30 Jun 2013 at 5:20
Implemented on noprompt branch of my fork
https://code.google.com/r/doncoleman-libfreefare/source/detail?r=070f1a71669778d
11b788183e55230bd7ac07ff3&name=noprompt
Is there a way to issue a github style pull request?
Original issue reported on code.google.com by [email protected]
on 14 Jul 2013 at 8:31
What steps will reproduce the problem?
1. brew install libnfc
2. brew install libfreefare (or compile from source)
3. format and write a tag
mifare-classic-read-ndef and mifare-classic-format work OK,
but mifare-classic-write-ndef fails with Symbol not found: _htole32
What is the expected output? What do you see instead?
$ ./examples/mifare-classic-write-ndef -y -i hello.dmp
NDEF file is 19 bytes long.
Found Mifare Classic 1k with UID fa4360e6.
dyld: lazy symbol binding failed: Symbol not found: _htole32
Referenced from: /Users/don/Downloads/libfreefare-0.4.0/libfreefare/.libs/libfreefare.0.dylib
Expected in: flat namespace
dyld: Symbol not found: _htole32
Referenced from: /Users/don/Downloads/libfreefare-0.4.0/libfreefare/.libs/libfreefare.0.dylib
Expected in: flat namespace
Trace/BPT trap: 5
What version of the product are you using? On what operating system?
libnfc 1.7.0
libfreefare 0.4.0
OS X 10.9.4
Please provide any additional information below.
I get the same results from brew or compiling from source
for compiling, brew install automake and libtool
Original issue reported on code.google.com by [email protected]
on 28 Jul 2014 at 3:30
I'm using libfreefare for multiple projects in order to isolate myself from a
DESfire implementation (I'm under an NXP NDA). Currently it's entirely bound to
libnfc, which is a pity since libnfc only handles a very small fraction of all
available RFID readers. Most of them come with an PC/SC IFD handler, even for
Linux!
The DESfire functions specifically would be a great match for T=CL handling
through PC/SC, but part 3 section 3.2.2.1 of the specification
(http://www.pcscworkgroup.com/specifications/specdownload.php) also details
operations on storage cards like Mifare Classic which are implemented by at
least some devices (all Omnikey devices do this in the IFD handler, some other,
I think SCM, do it in the reader firmware).
Implementing libfreefare support for PC/SC would greatly increase the
usefulness and range of supported devices.
Original issue reported on code.google.com by [email protected]
on 17 May 2013 at 11:56
Am cross compiling libfreefare for arm architecture and took source from
git clone https://code.google.com/p/libfreefare/
while executing autoreconf -vis getting some warning, see
http://pastebin.com/FNQpYdFv
while configuring http://pastebin.com/wSn4xQY1
while compiling am getting errors, see http://pastebin.com/A220HGBC
Is there patch to fix this?
how to fix this?
Original issue reported on code.google.com by [email protected]
on 9 Apr 2014 at 2:10
What steps will reproduce the problem?
1. Compile libfreefare against libnfc-1.7.0-rc7
2. Run mifare-classic-read-ndef
What is the expected output? What do you see instead?
Expected output : Some data
What I see : Segfault
What version of the product are you using? On what operating system?
libfreefare-0.3.4 from distributed tarball
Debian 7.0
Please provide any additional information below.
Segfault is easy to track :
mifare-classic-read-ndef.c:108: nfc_init(NULL);
In nfc.c:183 :
void
nfc_init(nfc_context **context)
{
*context = nfc_context_new();
if (!*context) {
perror("malloc");
return;
}
if (!nfc_drivers)
nfc_drivers_init();
}
Clearly here, sending NULL to nfc_init will result in trying to write a new
context at adresse 0, in the first line.
I think previous libnfc versions were compatible with sending them NULL, albeit
I didn't checked.
Original issue reported on code.google.com by [email protected]
on 30 Jun 2013 at 6:58
What steps will reproduce the problem?
1. Attempt to read page 0x2b
2. mifare_ultralight_read will return -1
Reading other pages seem to be fine.
What is the expected output? What do you see instead?
The expected output is a proper read of page 0x2b. Instead, 0x2b cannot be read.
What version of the product are you using? On what operating system?
Latest libfreefare from git compiled with Ubuntu 12.04 and libnfc-1.7.0-rc7.
Please provide any additional information below.
Using Smartcard Commander in Windows, I am able to read the tag with no
problems, including page 0x2b.
Original issue reported on code.google.com by [email protected]
on 10 Jun 2013 at 8:04
The function mifare_desfire_get_file_ids() has a parameter uint8_t *files[].
The type describes an array of pointers to uint8_t. This is probably not the
type that was meant to be used, as the argument clearly should be a pointer to
an array of uint8_t, denoted as uint8_t (*files)[].
I suggest to change the type of files in the signature of
mifare_desfire_get_file_ids() to uint8_t (*files)[]. As the array decays to a
pointer in a function declaration, these two types should not make any
difference in a regard to the calling convention.
A similar issue exists in mifare_desfire_get_iso_file_ids() where the parameter
uint16_t *files[] should probably be type uint16_t (*files)[].
Original issue reported on code.google.com by [email protected]
on 5 Apr 2014 at 11:07
when I run auroreconf -vis on RasPi, I get the following output:
autoreconf -vis
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf
autoreconf: running: /usr/bin/autoheader
autoreconf: running: automake --add-missing --no-force
configure.ac:8: installing `./ar-lib'
configure.ac:13: installing `./install-sh'
configure.ac:13: installing `./missing'
contrib/libutil/Makefile.am:5: Libtool library used but `LIBTOOL' is undefined
contrib/libutil/Makefile.am:5: The usual way to define `LIBTOOL' is to add
`LT_INIT'
contrib/libutil/Makefile.am:5: to `configure.ac' and run `aclocal' and
`autoconf' again.
contrib/libutil/Makefile.am:5: If `LT_INIT' is in `configure.ac', make sure
contrib/libutil/Makefile.am:5: its definition is in aclocal's search path.
contrib/libutil/Makefile.am: installing `./depcomp'
libfreefare/Makefile.am:6: Libtool library used but `LIBTOOL' is undefined
libfreefare/Makefile.am:6: The usual way to define `LIBTOOL' is to add
`LT_INIT'
libfreefare/Makefile.am:6: to `configure.ac' and run `aclocal' and `autoconf'
again.
libfreefare/Makefile.am:6: If `LT_INIT' is in `configure.ac', make sure
libfreefare/Makefile.am:6: its definition is in aclocal's search path.
test/Makefile.am:33: Libtool library used but `LIBTOOL' is undefined
test/Makefile.am:33: The usual way to define `LIBTOOL' is to add `LT_INIT'
test/Makefile.am:33: to `configure.ac' and run `aclocal' and `autoconf' again.
test/Makefile.am:33: If `LT_INIT' is in `configure.ac', make sure
test/Makefile.am:33: its definition is in aclocal's search path.
test/common/Makefile.am:14: Libtool library used but `LIBTOOL' is undefined
test/common/Makefile.am:14: The usual way to define `LIBTOOL' is to add
`LT_INIT'
test/common/Makefile.am:14: to `configure.ac' and run `aclocal' and
`autoconf' again.
test/common/Makefile.am:14: If `LT_INIT' is in `configure.ac', make sure
test/common/Makefile.am:14: its definition is in aclocal's search path.
Makefile.am: installing `./INSTALL'
autoreconf: automake failed with exit status: 1
Original issue reported on code.google.com by [email protected]
on 14 Jan 2015 at 5:24
Reported by emanuele.bertoldi, Apr 11, 2011
Currently, there are equivalent examples for MIFARE classic and desfire.
It would be great to add an example for MIFARE ultralight too.
Original issue reported on code.google.com by [email protected]
on 15 Jan 2013 at 7:34
Currently an internal table helps guessing the type of tag based on its SAK &
ATS.
But now phones start being able to emulate tags (CyanogenMod, Kitkat,...) while
SAK & ATS are still not under control, so being different than expected.
How to get more flexibility?
Getting an environment variable to bypass entirely detection and assume that
we've a tag of the right type requested by the application?
Or instead of guessing the tag from its SAK/ATS, test proactively if the tag is
of a specific type?
E.g. ASSERT_MIFARE_DESFIRE(tag) would not check a preset flag but would test
actively if the card is a DESFIRE by sending a GetInfo command.
Original issue reported on code.google.com by [email protected]
on 3 Dec 2013 at 3:23
Reported by vishnuocv, Aug 16, 2012
What steps will reproduce the problem?
1. cross compiled for ARM ./configure CC=arm-none-linux-gnueabi-gcc-4.1.2
--host=arm-none-linux
2.
3.
What is the expected output? What do you see instead?
Mifare-desfire-info should show the tag information...
it is not showing anything
What version of the product are you using? On what operating system?
linux, latest one (libfreefare-0.3.4)
Please provide any additional information below.
Libnfc things are working fine. but mifare-DESFire is not
I compiled for PC and it is working Fine. I am able to read the tag information
also
what could be the reason
----
Comment 1 by harishakumara.k, Aug 29, 2012
I also face the same issue. mifare-desfire- functions do not work in arm, but
mifare-classic examples are working fine.
At the same time, linux compilation is working fine for both the cards.
Is it because of endianness problem in libfreefare for desfire card?
Original issue reported on code.google.com by [email protected]
on 15 Jan 2013 at 8:06
The internal function read_data() in mifare_desfire.c contains the following
comment:
/*
* FIXME: This is bogus: the user has to provide a data buffer with enougth
* room to store CRC + padding or MAC. If the user wants to read 1 byte,
* there is no reason to provide a 16 bytes buffer.
*/
It is absolutely inacceptable that read_data() reads bytes from data beyond
length. Please either document how long the buffer behind data has to be or
rework the function to write at most length bytes into data. As is, this is a
huge security hole and makes writing a library wrapper extremely difficult as I
cannot make any assumptions about extra memory I must allocate beyond what is
documented. Please fix this issue ASAP.
Original issue reported on code.google.com by [email protected]
on 9 Apr 2014 at 6:24
Reported by [https://code.google.com/u/114415527994645740894/ kev.y.wang], Jan
1, 2012
*What steps will reproduce the problem?*
1. inside libfreefare-0.3.2 dir, run ./configure --prefix=/usr
2. make
*What is the expected output? What do you see instead?*
The expected output should not have the warnings that I see:
Smooth-Lightning:libfreefare-0.3.2 kevin$ make
make all-recursive
Making all in contrib
Making all in libutil
make[3]: Nothing to be done for `all'.
make[3]: Nothing to be done for `all-am'.
Making all in libfreefare
CC freefare.lo
CC mifare_classic.lo
mifare_classic.c: In function ‘mifare_classic_init_value’:
mifare_classic.c:326: warning: implicit declaration of function ‘htole32’
mifare_classic.c: In function ‘mifare_classic_read_value’:
mifare_classic.c:364: warning: implicit declaration of function ‘le32toh’
CC mifare_ultralight.lo
mifare_ultralight.c: In function ‘mifare_ultralightc_authenticate’:
mifare_ultralight.c:265: warning: ‘DES_random_key’ is deprecated (declared
at /usr/include/openssl/des.h:218)
CC mifare_desfire.lo
mifare_desfire.c: In function ‘authenticate’:
mifare_desfire.c:355: warning: ‘RAND_bytes’ is deprecated (declared at
/usr/include/openssl/rand.h:104)
mifare_desfire.c: In function ‘mifare_desfire_get_df_names’:
mifare_desfire.c:826: warning: implicit declaration of function ‘le16toh’
mifare_desfire.c: In function ‘mifare_desfire_get_file_settings’:
mifare_desfire.c:1249: warning: implicit declaration of function ‘le32toh’
CC mifare_desfire_aid.lo
...
Basically, some of the endian macros defined in freefare_internal.h are not
working. The compilation succeeds, but when trying to run some of the examples
(like mifare-classic-write-ndef), I get the following:
dyld: lazy symbol binding failed: Symbol not found: _htole32
Referenced from: /Users/kevin/dev/libfreefare-0.3.2/libfreefare/.libs/libfreefare.0.dylib
Expected in: flat namespace
dyld: Symbol not found: _htole32
Referenced from: /Users/kevin/dev/libfreefare-0.3.2/libfreefare/.libs/libfreefare.0.dylib
Expected in: flat namespace
Which makes sense, since during compilation, those were never defined.
*What version of the product are you using? On what operating system?*
OS: Mac OS X 10.7.
Version: libfreefare-0.3.2
Looking at it some more, would #ifdef macros in freefare_internal.h that use
<libkern/OSByteOrder.h> work?
----
Comment 2 by project member ludovic.rousseau, May 19, 2012
Maybe the solution is to use _standard_ C functions like:
NAME
htonl, htons, ntohl, ntohs -- convert values between host and network
byte order
LIBRARY
Standard C Library (libc, -lc)
SYNOPSIS
#include <arpa/inet.h>
uint32_t
htonl(uint32_t hostlong);
uint16_t
htons(uint16_t hostshort);
uint32_t
ntohl(uint32_t netlong);
uint16_t
ntohs(uint16_t netshort);
Original issue reported on code.google.com by [email protected]
on 15 Jan 2013 at 7:39
Thanks to time set apart for this purpose by my employer, I've been working in
the month of January on enhancing libfreefare and solving a couple of the
existing issues (some of which I previously opened myself :).
The primary goal was decoupling libfreefare from libnfc and allowing other
reader subsystems to be used. I implemented that for PC/SC as a first step,
other projects that one could think of would be librfid and the new "Linux NFC"
stack (https://01.org/linux-nfc).
A secondary goal was making the API easier to use and removing unnecessary --
and libnfc-version specific -- boilerplate code. To this end the new API that I
built is reader subsystem agnostic and I spent some effort into making it
future-compatible with no API or ABI changes.
I have looked at the work that has been done on the "pcsc" branch and decided
that that is not the way to go forward. Creating "-pcsc" versions of everything
and replicating a *second* flurry of boilerplate code among the code examples
is exactly what I strive to avoid.
The new API is centered around a new FreefareContext object that holds a
library context and references to either automatically acquired or externally
provided reader subsystem contexts (e.g. nfc_context) or devices (e.g.
nfc_device) and provides an easy to use and unified way to retrieve MifareTag
objects. The freefare_get_tags() and freefare_tag_new() methods are still there
but marked deprecated (since they are libnfc specific). The latter is
superseded by a new freefare_tag_new_ex() function that works with all
supported reader subsystems using unions as a way to allow it to accept both
libnfc or PC/SC arguments.
The new freefare_init() takes a flags argument that can be a combination of
FREEFARE_FLAG_READER_LIBNFC or FREEFARE_FLAG_READER_PCSC to automatically
establish a context to the given reader subsystems, or the special value
FREEFARE_FLAG_READER_ALL to establish a context with all supported subsystems,
even future ones. The latter is the recommended value, which means that a
program using the library needs not to be updated to gain access to a future
reader subsystem support by the library. The flags can also include
FREEFARE_FLAG_DISABLE_ISO14443_4 to disable 14443-4 support where possible
(currently only libnfc) to select the -3 version on hybrid cards.
Alternatively, freefare_context/device_add/remove are available to manually
manage associating or dissociating reader subsystem contexts or devices with
the libfreefare library. A FREEFARE_FLAG_AUTOCLOSE in _add will have
libfreefare take over responsibility of the passed in object and automatically
call the respective close function (nfc_close()/nfc_exit()) when it is no
longer needed.
Once a library context has been retrieved, the freefare_tags_get() method
enumerates all supported tags on all on readers on all contexts and returns a
list. Alternatively freefare_tag_first() and freefare_tag_next() can be used to
iterate over the same set without creating the entire list at once. Both accept
an enum mifare_tag_type argument to limit the type of tags eligible (the new
type NO_TAG_TYPE means no limit).
The boilerplate code can thus (without error checking) be reduced to
FreefareContext ctx = freefare_init(FREEFARE_FLAG_READER_ALL);
for(MifareTag tag = freefare_tag_first(ctx, NO_TAG_TYPE); tag; tag = freefare_tag_first(ctx)) {
/* Actual code here... */
}
freefare_exit(ctx);
The PC/SC support currently is not complete, only DESfire is working. No
functional changes to libnfc support should be present (I even added a working
FREEFARE_FLAG_DISABLE_ISO14443_4).
Late in the process I added freefare_tag_wait_* which allows non-busy polling
for tags (e.g. like the pcsc_scan tool does). This is only implemented for
PC/SC and only works on a single context. libnfc has a similar function in
nfc_initiator_poll_target() which only works for a single device, implementing
support for that is possible. Anything further (waiting for multiple
devices/contexts) would require a new threaded approach.
Before I could prepare my code for publication,
freefare_selected_tag_is_present() was added in the main libfreefare branch.
This was another libnfc specific function, which I choose not to continue
supporting (it hasn't been out long, there should be minimal code breakage).
Instead I added freefare_tag_is_present() as a reader subsystem agnostic
alternative.
I pushed all the code changes to
https://code.google.com/r/henryk-libfreefare-extended-reader-support for easy
pulling and request inclusion in libfreefare (sadly Google has no pull request
support).
Original issue reported on code.google.com by [email protected]
on 27 Feb 2014 at 3:19
What steps will reproduce the problem?
Fresh Arch Linux on RPI SD Card as root
wget https://libfreefare.googlecode.com/files/libfreefare-0.4.0.tar.bz2
wget https://libnfc.googlecode.com/files/libnfc-1.7.0.tar.bz2
tar xvjf libnfc-1.7.0.tar.bz2
tar xvjf libfreefare-0.4.0.tar.bz2
cd libnfc-1.7.0
./configure --prefix=/usr
make
make install
cd ..
cd libfreefare-0.4.0
./configure --prefix=/usr
What is the expected output? What do you see instead?
I see: libnfc >= 1.7.0 is mandatory
but libnfc is correctly installed!
I expect to see successful ./configure
What version of the product are you using? On what operating system?
Raspberry Pi version B 512MB RAM, Arch Linux
Linux alarmpi 3.12.23-1-ARCH #1 PREEMPT Fri Jun 27 01:32:04 MDT 2014 armv6l
GNU/Linux
Please provide any additional information below.
The error is caused by PKG_CHECK_MODULES macro in configure.ac which returns
invalid output.
PKG_CHECK_MODULES returns correct output when pkg-config is installed.
i.e. pacman -S pkg-config
This is really annoying error, it took me a few hours to figure out what's
wrong.
Original issue reported on code.google.com by [email protected]
on 3 Jul 2014 at 5:45
It should better do so.
At the same time, it would perhaps make sense to rewrite the function to be a
little bit more efficient than calling snprintf() in a loop.
Original issue reported on code.google.com by [email protected]
on 4 Apr 2014 at 10:17
http://code.google.com/r/dheidler-libfreefare/source/detail?r=cc36619f132e973a3c
c82a6cedc6a03146d24f7d
Original issue reported on code.google.com by [email protected]
on 3 May 2013 at 8:08
Attachments:
I'm currently writing Go bindings for the libfreefare.
Go provides garbage collection, Go programmers expect that objects which aren't
tied to external resources do not need explicit deinitialization. A
MifareDESFireKey is such an object. It contains a key used for initialization.
As far as I am concerned, a MifareDESFireKey does not allocate any resources
and can be free'd at any time.
Right now, MifareDESFireKeys are allocated by the libfreefare using malloc()
and free(). This makes it very hard to give control over allocation to a
garbage collector: You need two layers of wrapping which causes performance
loss and an unneccessary amount of extra garbage to be allocated. Library
support is needed to be able to control the allocation of MifareDESFireKeys.
I request to implement one of the following things:
1) Completely define struct mifare_desfire_key in freefare.h and for each
function mifare_desfire_*_key_new() provide an additional
mifare_desfire_*_key_init() with the same effect, except that you explicitly
pass a MifareDESFireKey.
2) Provide a function mifare_desfire_key_sizeof() that returns sizeof(struct
mifare_desfire_key_sizeof) and otherwise proceed as in 1).
3) For each function mifare_desfire_*_key_new() provide an additional
mifare_desfire_*_key_custom_new() with an extra parameter
void *(*alloc)(size_t size)
to pass a custom memory allocation routine. Albeit not perfect, this would
already simplify allocation control by a big deal. What is missing is the
ability to embed a MifareDESFireKey into a custom Go struct to save even more
space.
Original issue reported on code.google.com by [email protected]
on 25 Feb 2014 at 12:58
There is a bug when reading data larger than a desfire frame.
It happens e.g. with mifare-desfire-read-ndef
----
$ mifare-desfire-read-ndef -o foo
Found Mifare DESFire with UID 04376069fe1e80. Read NDEF [yN] y
Max NDEF size: 3808 bytes
NDEF size: 410 bytes
error libnfc.chip.pn53x Buffer size is too short: 60o available(s), 61o needed
lt-mifare-desfire-read-ndef: Read data failed
----
Desfire "max Le" is =59
freefare_internal.h:
#define MAX_FRAME_SIZE 60
which is I guess error_code + data of a pure desfire frame.
But in reality "read" is a desfire command encapsulated in ISO so ending with 2
SW.
So max=61, not 60
Now the problem is where to do the change as cleanly as possible.
I don't want to mess up things somewhere else by just changing MAX_FRAME_SIZE
E.g. there is dependencies: FRAME_PAYLOAD_SIZE = MAX_FRAME_SIZE - 5
So I thought changing it only in DESFIRE_TRANSCEIVE2 macro.
From where comes the value in the macro giving the recv buffer size??
nfc_initiator_transceive_bytes (tag->device, __msg, __len, __res,
__##res##_size, 0)
=> where is defined __res_size? and wht not just sizeof(__res)?
Moreover __res is defined internally with MAX_FRAME_SIZE(+1) while
__##res##_size linked to res argument rather than locale var __res?
Very dirty hack solving the issue, just to show the direction...
diff --git a/libfreefare/libfreefare/mifare_desfire.c
b/libfreefare/libfreefare/mifare_desfire.c
index cb812ea..c00eb23 100644
--- a/libfreefare/libfreefare/mifare_desfire.c
+++ b/libfreefare/libfreefare/mifare_desfire.c
@@ -157,7 +157,8 @@ static ssize_t read_data (MifareTag tag,
uint8_t command, uint8_t file_no, off_
do { \
static uint8_t __msg[MAX_FRAME_SIZE] = { 0x90, 0x00, 0x00, 0x00,
0x00, /* ..., */ 0x00 }; \
/* CLA INS P1 P2
Lc PAYLOAD LE*/ \
- static uint8_t __res[MAX_FRAME_SIZE]; \
+ /* Max res size is one byte longer when using ISO encapsulation
(2 SW instead of one) */ \
+ static uint8_t __res[MAX_FRAME_SIZE+1]; \
size_t __len = 5; \
errno = 0; \
if (!msg) return errno = EINVAL, -1; \
@@ -173,7 +174,7 @@ static ssize_t read_data (MifareTag tag,
uint8_t command, uint8_t file_no, off_
MIFARE_DESFIRE (tag)->last_pcd_error = OPERATION_OK; \
DEBUG_XFER (__msg, __len, "===> "); \
int _res; \
- if ((_res = nfc_initiator_transceive_bytes (tag->device, __msg,
__len, __res, __##res##_size, 0)) < 0) { \
+ if ((_res = nfc_initiator_transceive_bytes (tag->device, __msg,
__len, __res, __##res##_size+1, 0)) < 0) { \
return errno = EIO, -1; \
} \
__##res##_n = _res; \
Original issue reported on code.google.com by [email protected]
on 15 Jan 2013 at 10:45
Reported by [email protected], Jun 7, 2012
Mifare Classic uses two types of diversification, old and new. The new type is
very very similar to DESFire diversification, actually it is 100% the same, but
the for DESFire the final key is taken from the last 16 bytes, for the classic
it is first 6 bytes of the last 16 bytes. Will there be a fn that simply
returns Classic type keys?
----
Comment 1 by project member [email protected], Jun 7, 2012
Thanks for reporting issue.
Could you provide a patch for this feature ?
If not, we will try to take care at this issue ASAP.
----
Comment 2 by [email protected], Jun 8, 2012
No, unfortunately not due to the time constraints. Perhaps sometime in the fall
i might get the time, for now i can only provide specifications for
diversification.
----
Comment 3 by project member [email protected], Jun 8, 2012
Yes, feel free to let us some references to implement it.
Thanks
----
Comment 4 by [email protected], Jun 8, 2012
Please find the file attached
----
Spec.pdf
3.5 MB Download
----
Comment 6 by project member [email protected], Jun 8, 2012
Thanks for attachement.
As we are quite busy with libnfc and ifdnfc right, I don't think we will
improve libfreefare next days.
ASAP may be not enough for some users, so if any volunteer want to take this
issue, feel free to attach patches.
----
Comment 7 by olifozzy, Aug 13, 2012
I have been trying to understand the algorithm but I am having some trouble
understanding key diversification.
If I understand correctly we need to know the master key and the 3des key to
compute diversified keys for a card ?
Signature should be something like :
- GetKey(masterKey, 3desKey, uid, blockNumber);
I have some tags that looks like mifare classic but the KeyA from the first
sector is always the same , the other keys are diversified.
Do you know if the first sector behave differently of maybe my set of tags
doesn't use that diversification algorithm...
----
Comment 8 by [email protected], Aug 13, 2012 via email
what 3des key? No 3des key is needed. Take a look at the first post and take a
look at DESFire diversification implementation in the project. You have to have
master key and diversification input (which is card UID and sector number) from
the output of desfire diversification take the first 6 bytes of last 16
bytes(because classic keys are smaller).
Marko
----
Comment 9 by olifozzy, Aug 13, 2012
I was talking about the first part of the document (old 2ktdes based key
diversification).
Anyway I also looked at the second part of the document and the way it is done
for desfire in libfreefare.
According to the document there is some padding so that diversification input
is always 32 bytes but in libfreefare, in cmac method it use key block size
that is only 16 bytes.
I've made some slight modification to make it work as in the document.
It still doesn't explain why i have always the same key for all my tags but
only for the first block (sector 0x03). Maybe they used a custom key
diversification :/
----
Comment 10 by [email protected], Aug 13, 2012 via email
could be custom diversification.
sorry, i cannot help you with older diversification.
Marko
Original issue reported on code.google.com by [email protected]
on 15 Jan 2013 at 8:01
With ultralightC we could be in situations where read() is called without prior
authentication and AUTH0 < MIFARE_ULTRALIGHT_C_PAGE_COUNT_READ + 1
Several situations may occur:
Let's put auth0 = value of AUTH0 at 0x2A
read(x) with x <= auth0 - 4:
read done properly
read(x) with auth0 - 4 < x < auth0
read result is wrapped
bug in libfreefare: cached pages are not wrapped
e.g. auth0=3, read(0) returns page0|page1|page2|page0
and libfreefare caches wrongly page4 with page0 content
read(x) with x >= auth0
read fails properly
The difficulty to handle those cases, especially the early wrapping, is that
0x2A cannot be read in such situations and must be deduced by trial & error.
E.g. by trying to access the latest cached page, we can see if we get an error
or not and if cache is valid or not.
And probably we need to keep track of two other state values in the cache to
avoid this extra check whenever it's possible:
* latest known valid page
* if we reach 0x2A we can remember its actual value
* if we're authenticated we don't need to check page validity
My proposal:
* use another temp buffer to hold read data
* reduce tag cache buffer to actual max size (today it's hacked =+3 to cope
with wrapped read of last page)
* if (UL or (ULC and AUTHENTICATED)), copy data to cache with proper wrapping
if required
* if (ULC and not AUTHENTICATED), copy one single page in cache and ignore rest
of data
It's less efficient when reading without being authenticated but it keeps the
code much clearer.
What do you think?
Original issue reported on code.google.com by [email protected]
on 15 Jan 2013 at 8:18
Hi, can you please take a look at my commit
https://code.google.com/r/maximchick-1k-emulated/source/detail?r=9ee3687280fdb37
fedb3d5e2bac54c414acbbb09
It adds support for SmartMX based card emulation like eSE/dual interface
cards/UICC based cards and so on.
I tested it on ACR-122U-A9
Original issue reported on code.google.com by [email protected]
on 18 Dec 2013 at 3:19
What steps will reproduce the problem?
1. Use the function mifare_desfire_debit/credit
2.
3.
What is the expected output? What do you see instead?
the value of the value file gets changed when i get a 0 as return from the
function
What version of the product are you using? On what operating system?
version 0.4.0 of libfreefare on OS X 10.10 and Ubuntu 14.04.
Using an ACR122U and a DESFire EV1 4k card
Please provide any additional information below.
All other functions seem to work as expected.
Original issue reported on code.google.com by [email protected]
on 10 Feb 2015 at 3:21
I'm using libfreefare for multiple DESfire projects (as of yet:
https://github.com/henryk/libopenkey and
https://github.com/henryk/desfire-tools). One issue that's come up multiple
times is handling a "card removed" error.
From the PC/SC environment I'm used to having the framework handle that: Once a
card connection is lost, all further attempts to submit commands will
immediately return with an error. libfreefare doesn't do that. Calling for
example mifare_desfire_select_application() on a card that's been removed will
actually try to transmit the command (as seen in DEBUG_XFER output) and return
after a timeout.
libnfc provides nfc_device_get_last_error() which will return NFC_ERFTRANS in
this case, but it can't be accessed properly from libfreefare. I've discovered
that MifareTag can be cast to nfc_device** and then dereferenced to call libnfc
functions (see
https://github.com/henryk/desfire-tools/blob/64dbb9d51c3feecd1aa99da8556273ebc7c
7db84/src/mifare-desfire-analyze.c#L45) and am using this as a workaround, but
that's hardly proper methodology.
Could libfreefare either:
a) Provide a defined way to access the nfc_device pointer and call libnfc
functions (even just defining the above cast as proper and promising to always
keep the structure to allow it would suffice for this)
b) Track permanent errors and not carry out any timeout-inducing actions
afterwards. Or at least give a defined feedback to the caller that he may not
attempt any further action on the tag. (Currently you could do something like
"if mifare_desfire_select_application() fails but both
mifare_desfire_last_picc_error() and mifare_desfire_last_pcd_error() return 0
then maybe the tag is gone" but that's only a heuristic and not easily
universally used.)
Actually it would be best if both happen. The point where I initially
discovered the cast is for
https://github.com/henryk/desfire-tools/blob/64dbb9d51c3feecd1aa99da8556273ebc7c
7db84/src/mifare-desfire-analyze.c#L296 where I want to find out if an AES or
DES authentication is directly answered with an authentication error (meaning
that the authentication mode is not supported) or an additional frame status
(meaning that the authentication mode is supported).
mifare_desfire_authenticate() handles these internally and
mifare_desfire_last_picc_error() doesn't distinguish between "authentication
mode not supported" and "key wrong". So I still need the ability to issue raw
libnfc commands, or maybe a status flag that I can interrogate that shows
whether the authentication failed after the first or second command.
Original issue reported on code.google.com by [email protected]
on 17 May 2013 at 11:43
Reported by project member [email protected], Sep 30, 2012
If you are authenticated on a sector but the requested MIFARE cmd (read, write)
is not permitted by current access bytes, libfreefare should return "permission
denied" error.
http://www.libnfc.org/community/topic/760/scl3711-mfclassic-dump-problem-chip-er
ror-invalid-received-frame/
Original issue reported on code.google.com by [email protected]
on 15 Jan 2013 at 8:09
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.