Ultralight C changing default 3DES key

Hello,

Ultralight C is implemented in libfreefare, so feel free to read the code

Hi,

To change the key, just write it to memory in pages 0x2C-0x2F

Phil

Hey Phil, sorry. I did some research and discovered that the pages 0x2C-0x2F represent the blocks/pages 44-47

Is that right? If that's the case, I can write a new password starting with this command?

mifare_ultralight_write (tag, 44, payloadForPage44);

Is there any command to protect a range of blocks from being written?

Many thanks once again

Awesome! Thank you so much Phil!

See in my example bytes are swapped so you've to use:
uint8_t key1_3des_data\[16\] = "tsettsettsettset";

Note that I just found a bug in libfreefare mifare_ultralight_read() triggered by recent bufferzise checks in libnfc.
This is fixed in r1105
I also added a test for default ULC key in examples/mifare-ultralight-info (in r1106)

To restore the default key:
MifareUltralightPage payloadForPage44  = "BREA";
MifareUltralightPage payloadForPage45  = "KMEI";
MifareUltralightPage payloadForPage46  = "FYOU";
MifareUltralightPage payloadForPage47  = "CAN!";

Phil

This is the log that I get running
"gdb mifare-ultralight-info" after I compile and run the example "mifare-ultralight-info" provided in the latest revision:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000009
pn53x_initiator_transceive_bytes (pnd=0x7fff5fbfbeba, pbtTx=0x101901558 "?", szTx=2, pbtRx=0x7fff5fbfc227 "", pszRx=0x9, timeout=1606402288) at pn53x.c:1324
1324    pn53x.c: No such file or directory.
    in pn53x.c

Thank you once again
Isaac

Hey Phil, I really appreciate all your help.

I know this is a separate issue unrelated to the original scope of the original topic of this thread (Ultralight C changing default 3DES key), so apologies for continuing this conversation in here.

I uninstalled libfreefare and libnfc and reinstalled both using the latest SVN revisions.

When I reinstalled libnfc, it was unable to open the NFC reader I'm using (ACR122 ) when I executed the bundled nfc-list, located in the utils directory of libnfc.  When looking for a solution fot this, I've came across the issue 208 (http://code.google.com/p/libnfc/issues/ … amp;id=208), which is related to the acr122_usb library, which is a new experimental driver that libnfc is using by default for Touchatag/ACR122U devices.

In order to troubleshoot the issue of my ACR122 reader not been found,  I followed the advise in the above mentioned ticket, and recompiled libnfc using  support for acr122_pcsc driver (./configure --with-drivers=acr122_pcsc && make clean all). After this, I was able to successfully get the nfc-list example running and properly recognizing the reader device:
NFC device:
ACS ACR122U PICC Interface 00 00 / ACR122U207 opened
1 ISO14443A passive target(s) found:
ISO/IEC 14443A (106 kbps) target:
    ATQA (SENS_RES): 00  44 
       UID (NFCID1): 04  a3  23  99  10  28  80 
      SAK (SEL_RES): 00

However, when I compile and run a libfreefare example (mifare-ultralight-info.c) that tries to open the reader, I get the same error message I was getting previously, when running the nfc-list example with the new ACR122 driver:
"nfc_open() failed."

Can this issue be related to the new ACR122 driver that libnfc is using by default?

Many thanks as always

When I recompiled libnfc with acr122_pcsc, I made sure to delete the any reference to it in /usr/local/lib and /usr/local/include.  Is there a way to check if libfreefare is using the new one?

Thanks

Awesome.. Everything works fine. Thank you so much Phil for all your help and support! Much appreciated!

Hi! Do you know why even the default key in ultralight C is "425245414b4d454946594f5543414e21" (BREAKMEIFYOUCAN!) the key used for decrypting on is "49454D4B41455242214E4143554F5946"?  (I took this value from mifare-ultralight-info.c in libfreefare examples). I guess there's a relation between them , but I don't know what it is. If I change the 3des key on the card I cannot authenticate using it, but if I return the card to the default one it works again (using "49454D4B41455242214E4143554F5946" for decrypting) . Any help is appreciated.
Thanks
Gaston