When you encrypt a disk, the data which is written on the disk is encrypted, but it can be freely read and copied to another disk. Then, you can decrypt it, should you know the key which was used to encrypt the data.
For RFID cards it depends on which card you want to copy. In a properly designed system, the data is encrypted with a key, which is dependent on the card's serial number. If you want to copy the card, you need to use a "magic" card which serial number can be rewritten. Otherwise, if you copy the data to a card with a different serial number, the reader will try to decipher the data with another key, the decryption will fail, and the card will not be recognized.
Also, unlike disks which can be freely read, some RFID chips such as MIFARE require the reader to authenticate with the chip.
The card sends an encrypted random number to the reader, the reader decrypts it and sends it back to the card.
If the numbers match, access to the block is granted.
Then, all subsequent communications between the reader and the card are encrypted, no matter whether the data stored in the cars is encrypted or not.
If you do not know the key, the card won't even allow you to read the block. This is why you need to crack the keys of a MIFARE card before reading it.
Regards,
Atmel9077
]]>Has anyone tried the hunterscat nfc device?
What are the diferences between the proxmark3 and this device?
Does it support mifare desfire emulation?
thanks
]]>With proxmark3, I have been told it can't emulate mifare desfire cards, and when I try to analyze a mifare desfire card (4k), I get a bunch of errors, only a few command works.
Any ideas?
Thanks
]]>Since the file was quite small a question came up, could this be used for rfid tag dumps aswell?
@doegox came through first last night https://twitter.com/doegox/status/1281490778364219392
His EML file is over at Gist https://gist.github.com/doegox/e7a258f0 … f34e1abd53
Once you convert it to binary, it isn't detected to anything, but you can unzip it and it decompresses a file.
funny!
Now next question came, can it produces different detections aswell? short answer, yes it can.
now, the sample file is detected with multiple formats, can be viewed with PDF, can unzip,... meanwhile being a normal dump for mfc.
and of course it didn't end there....
The question came up if a dump could be made an executable aswell.
@neduchaljan accepted the challenge and https://twitter.com/neduchaljan/status/ … 2925341697
His sample dump file https://gist.github.com/TheDuchy/379650 … f679ae660b
So in short to test this, you can just download, cload to a magic card S50, and dump it, or just run the scripts to convert from eml -> bin, and do the testing in your shell.
]]>Anyhow if this isn't the type of thing we can discuss here admins feel free to remove.
I just thought I'd get a feeler first...
]]>For beginners, its an easy read with step by step kind of layout on how to use your Proxmark3 with your implant.
REF
]]>A good source of information,
]]>DRAFT: A Summary of Nintendo Amiibo (NFC Tag) Reverse-Engineering
I was hoping this community could help proof-check this draft blog post and:
1) help me correct anything wrong
2) let me know about any missing information (I'd love to know more about how exactly the encryption scheme was uncovered, how the master keys were extracted, etc)
3) make sure I give due credit to the right people
Thanks,
Kevin
P.S. I purposefully made a simplified Amiibo byte structure as this blog post isn't so much as a definitive reference for Amiibo hacking, but a broader overview for casual tech readers. But perhaps I should add more details at the end?
]]>Concerning the 15693 reader :
- I will add support for reading block lock status and perhaps LOCK BLOCK command. (Be careful with this command!)
- I'm facing problems with WRITE SINGLE BLOCK on some tags (more details here). Some tags don't like my write commands so I may have to revert to a "dirty" blind write + read sequence.
- One byte, transmitted or received, takes 70 bytes in the transmit or receive buffer. I chosed a 1280-byte buffer as this is the minimum to perform an INVENTORY without anticollision. This equates to a total of 17 bytes. Or 10 "payload" bytes after removing the CRCs, command codes and flags. INVENTORY commands with anicollision or addressed mode mean 8 more bytes to transmit and 560 additional bytes of buffer, leaving 208 bytes for the rest of the sketch. At this point it will more or less be useless, if it even compiles...
So yes, I'll try adding features, but I don't expect miracles.
I would also like to know, whether you tested my super-dirty test sketch or not, and if yes have you had good results ?
Regards,
atmel907
I recently bought the PiSwords Proxmark3 from AliExpress, since I wanted to start playing with RFID tags. I decided to buy the two USB ports model because it says that it can perform offline sniffing but I couldn't find any documentation to do it, so this is why I'm writing this post.
First of all, you'll need to flash the RRG/Iceman firmware. To flash the bootloader you have to follow the procedure described in https://github.com/Proxmark/proxmark3/wiki/flashing and keep the button pressed while connecting the USB port (once you upgrade to the RRG/Iceman FW this won't be necessary). I flashed first the original firmware but just because I wanted to see the differences between the original and the RRG/Iceman FW, I assume you can flash directly the second one.
About offline sniffing: you can see on one of the photos of the product that the front connector is for "USB Powerbank" and the side one for "Off-line sniffing". This is wrong, or at least very misleading. The front connector is the only one that has an USB data connection, so the side one will be the one used for the Powerbank.
The procedure for offline sniffing will be something like this:
Connect the Powerbank to the side connector.
Keep pressed the Proxmark3 button to enter standalone mode (I'll talk more about this later).
Perform offline sniffing.
Connect the Proxmark3 to your PC using the front connector.
Dump the sniffing session with the Proxmark client.
It's quite easy, but I had to do some trial and error until I got it right.
About the standalone mode, if you want to sniff 14a using this Proxmark3 you'll have to develop your own mode. This is because the HF_14ASNIFF mode is valid only for the RDV4 model which has a SPI flash memory which unfortunately we don't have with the PiSwords model.
Based on this mode I've tried something like this (I did it copying/pasting from the HF_YOUNG & HF_14ASNIFF modes from Craig Young & Michael Farrell, so I'd like to thank both of them):
#include "standalone.h"
#include "proxmark3_arm.h"
#include "iso14443a.h"
#include "util.h"
#include "appmain.h"
#include "dbprint.h"
#include "ticks.h"
#include "BigBuf.h"
void ModInfo(void) {
DbpString("hf_14asniff_nospiffs: standalone 'hf 14a sniff', keeps it in memory");
}
void RunMod() {
StandAloneMode();
Dbprintf("Starting standalone mode: hf_14asniff_nospiffs");
for (;;) {
SniffIso14443a(0);
LED_D_ON();
for (;;) {
WDT_HIT();
int button_pressed = BUTTON_HELD(280);
if (button_pressed == BUTTON_HOLD)
break;
// exit from Standalone Mode, send a usbcommand.
if (data_available()) return;
}
LED_D_OFF();
SpinDelay(300);
}
}
It basically performs a "hf 14a sniff" until the button is pressed. Then the LED D will turn on and you'll be able to connect the Proxmark3 to your PC and do a "hf 14a list" to dump the sniffing session. Also, if you want to discard the sniffing session you just have to press the button briefly, then you'll return to the sniffing session (the LED D will turn off and A will turn on).
I tried it using my phone to read a tag and it seems to work, however I must warn you that I couldn't try this using a real reader.
For more information to include a new standalone mode check the RRG readme: https://github.com/RfidResearchGroup/proxmark3/blob/master/armsrc/Standalone/readme.md
Last, I'd like to thank Iceman1001 and all the Rfid Research Group for all their great work. Best Regards.
]]>So far I've Cracked both weak and hard mifare classic cards, emulated a FDX pet id tag and got a chip reader to read it, identified several unknown cards/fobs in my collection, found out my work badge is completely rewriteable and in no way locked (!) and generally spent several hours geeking out.
I'm more of a hardware guy, but most of the software seems pretty straightforward, it helps that I primarily use linux, and have a decent understanding of it.
I can already tell I'm going to have fun with this!
]]>I am trying to clone LF125khz casi PL5 card as the purpose of security testing.I have tried using standalone mode but it is not reading this card Below is a link for details of the card. Any other firmware /flash can help to read this card then let me know and to upgrade it.
https://www.id-enhancements.com/rapidprox-proxlite-card-for-casi-compare-to-cxpl5/#product-tab-description.
Any suggestion to clone this card would be really helpful. I have windows 10 Dell 64bit laptop and Proxmark 3 RDV2 from elehouse .
There is only numbers I can see on the back of badge which is 154288383797 and badge is embedded with a small copper square in the middle of the card.
I am willing to compensate if you can solve this mystery.
Thanks and let me know if any details required.
]]>https://www.cherry.co.uk/cherry-secure-board-1-0.html
Has someone tried it?
]]>