Below is a dump from the sample card that came with the RC522, I have omitted the repeating parts.
What exactly is the data stored at the first block of every sector? In this case FF 07 80 69 FF FF FF FF FF FF.
Also what are those bytes after the ATQA bytes, that simply count from 62 to 69?
(fyi this card is in its factory state; it has not been written to by any system- however other new cards from other sources have the same bytes written)
And what exactly is the memory of a Mifare card used for in the usual application? (I have read that most access control systems only read the UID.)
mfrc522.PICC_DumpToSerial
Card UID: C1 44 53 63
Card SAK: 08
PICC type: MIFARE 1KB
Sector Block 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 AccessBits
15 63 00 00 00 00 00 00 FF 07 80 69 FF FF FF FF FF FF [ 0 0 1 ]
62 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 0 0 0 ]
61 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 0 0 0 ]
60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 0 0 0 ]
...
0 3 00 00 00 00 00 00 FF 07 80 69 FF FF FF FF FF FF [ 0 0 1 ]
2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 0 0 0 ]
1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 0 0 0 ]
0 C1 44 53 63 B5 08 04 00 62 63 64 65 66 67 68 69 [ 0 0 0 ]
The last block of each sector (i.e. block 3, block 7, ... block 63) is the sector trailer. It contains the access keys and the access conditions for the sector. See Mifare 1K authentication keys for the exact format and Locking mechanism of Mifare Classic 1K / Mifare Access condition calculation on how the access bits are calculated.
The first block of the first sector (block 0) is the manufacturer block. It usually contains anti-collision parameters and some manufacturer specific data. I don't think that NXP ever published any information about the exact format of that data. I'm a bit surprised that your card contains the sequence 62 63 64 65 66 67 68 69 there, since usually there was some information about IC production there (batch number, production data, etc.)
Related
I want to write to a mifare classic 4k, using the following APDU command (UPDATE BINARY):
APDU = {FF D6 00 20 10 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0Fh}
It seems fine as a get a 90 00 result...
but when i read the card back I always got the following (even with different data...):
sector: 8 (block 32), auth OK
032: D5 41 00 EA 00 FF 13 3E 86 6A 00 00 00 00 69 FF
033: D5 41 00 EA 00 FF 13 3E 86 6A 00 00 00 00 69 FF
034: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
035: 00 00 00 00 00 00 FF 07 80 69 FF FF FF FF FF FF
where does this string D5 41 00 EA 00 FF 13 3E 86 6A 00 00 00 00 69 FF come from?
Note that i didn't change any setting on the card and was properly authenticated. It was a blank card and i didn't touch the trailer.
I m using a ACR122 reader (this command comes direct from the documentation of the reader...)
Ok i found my problem, i was setting the wrong size for the cbSendLength parameter in SCardTransmit.
Now i set the correct one (the whole size of the APDU command: 21) and it works fine.
Sorry.
I followed this tutorial to the letter, but I'll to explain in detail what steps I took exactly. I have an ECP5-evaluation 85k board.
I soldered bridges on R34/R35 (RX/TX) and R21 (connects LED D1 to RXD)
I used my windows installation to run the latest version of FT_PROG. In FT_PROG I went to FT_EEPROM -> Hardware Specific -> Port B -> Hardware and set it to RS232 and hit program. It completed succesfully according to the software.
Then I forwarded the USB port to my virtual box linux machine. It recognizes the board and I can succesfully run verilog files on it.
I ran ./raw_serial.sh to upload raw_serial.v to my board which is supposed to repeatedly print A to the serial monitor.
I then opened minicom on /dev/ttyUSB1 and it recognizes the device, baudrate is set correctly.
I then tried to use cu as follows: sudo chmod 666 /dev/ttyUSB1 && sudo cu -l /dev/ttyUSB2 -s 115200. It opens a terminal and says it is connected.
Led D1 is lighting up and both terminal programs indicate that the connection is succesful (I tried one of them at a time of course). Nothing is printed to the screen. When I use minicom and reupload raw_serial.v some <?> signs are printed to the screen but that's it. I tried turning echo on and off but nothing seems to work.
The following worked for me and it will probably work for others too. I'm assuming you're using openocd.
Do not use FT_PROG in windows, it doesn't seem to actually flash the FTDI chip. However, it lets you read back the hex dump that was supposed to be flashed to the chip. The hex dump for the unchanged EEPROM as it comes out of the box is as follows:
00000000 01 08 03 04 10 60 00 07 C0 FA 08 00 11 11 9A 10 .....`..Àú....š.
00000010 AA 3C E6 12 00 00 00 00 56 00 00 00 00 00 00 00 ª<æ.....V.......
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000050 00 00 00 00 00 00 02 03 00 00 00 00 00 00 00 00 ................
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000090 00 00 00 00 00 00 00 00 00 00 10 03 4C 00 61 00 ............L.a.
000000A0 74 00 74 00 69 00 63 00 65 00 3C 03 4C 00 61 00 t.t.i.c.e.<.L.a.
000000B0 74 00 74 00 69 00 63 00 65 00 20 00 45 00 43 00 t.t.i.c.e. .E.C.
000000C0 50 00 35 00 20 00 45 00 76 00 61 00 6C 00 75 00 P.5. .E.v.a.l.u.
000000D0 61 00 74 00 69 00 6F 00 6E 00 20 00 42 00 6F 00 a.t.i.o.n. .B.o.
000000E0 61 00 72 00 64 00 12 03 46 00 54 00 32 00 55 00 a.r.d...F.T.2.U.
000000F0 59 00 54 00 4A 00 56 00 00 00 00 00 00 00 FC 27 Y.T.J.V.......ü'
I just post this here for future reference, we're not going to use the stock eeprom.
We need to flash the eeprom to RS232-HS mode. To do so, we must first change the hex dump of the eeprom accordingly. To put channel B in RS232-HS mode we need to change the last column of the last row from ' to |. Create a hex file called eeprom_RS232.bin with the following contents:
00000000 01 08 03 04 10 60 00 07 C0 FA 08 00 11 11 9A 10 .....`..Àú....š.
00000010 AA 3C E6 12 00 00 00 00 56 00 00 00 00 00 00 00 ª<æ.....V.......
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000050 00 00 00 00 00 00 02 03 00 00 00 00 00 00 00 00 ................
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000090 00 00 00 00 00 00 00 00 00 00 10 03 4C 00 61 00 ............L.a.
000000A0 74 00 74 00 69 00 63 00 65 00 3C 03 4C 00 61 00 t.t.i.c.e.<.L.a.
000000B0 74 00 74 00 69 00 63 00 65 00 20 00 45 00 43 00 t.t.i.c.e. .E.C.
000000C0 50 00 35 00 20 00 45 00 76 00 61 00 6C 00 75 00 P.5. .E.v.a.l.u.
000000D0 61 00 74 00 69 00 6F 00 6E 00 20 00 42 00 6F 00 a.t.i.o.n. .B.o.
000000E0 61 00 72 00 64 00 12 03 46 00 54 00 32 00 55 00 a.r.d...F.T.2.U.
000000F0 59 00 54 00 4A 00 56 00 00 00 00 00 00 00 FC 27 Y.T.J.V.......ü|
Now, we need to flash this eeprom to our ECP5 using Anton's method. To do this, first create a file ftdi_RS232.conf with the following contents:
vendor_id=0x403
product_id=0x6010
filename="eeprom_RS232.bin"
flash_raw=true
With the following command we can flash to our ECP5: ftdi_eeprom --flash-eeprom ftdi_RS232.conf. Should we ever want to revert back to the stock eeprom, we can easily repeat this method with the hex dump given in step 1.
Now it's time to flash the verilog file. However, the device description of the ECP5 has changed from Lattice ECP5 Evaluation Board to Dual RS232-HS. We need to tell openocd to look for that specific device. Start by creating a file ecp5.cfg with the following contents:
# this supports ECP5 Evaluation Board
interface ftdi
ftdi_device_desc "Dual RS232-HS"
ftdi_vid_pid 0x0403 0x6010
# channel 1 does not have any functionality
ftdi_channel 0
# just TCK TDI TDO TMS, no reset
ftdi_layout_init 0xfff8 0xfffb
reset_config none
# default speed
adapter_khz 5000
# ECP5 device - LFE5UM5G-85F
jtag newtap ecp5 tap -irlen 8 -expected-id 0x81113043
Then, create your svf file as you usually do and flash it with the following command:
sudo --preserve-env=PATH env openocd -f ./ecp5.cfg -c "transport select jtag; init; svf raw_serial.svf; exit"
Finally, we can open a terminal to read the serial output of the ECP5. Personally, I like to use minicom: sudo chmod 666 /dev/ttyUSB0 && minicom -D /dev/ttyUSB0.
One more problem with the raw_serial.v example was that it doesn't use a baudrate of 115200 as the readme suggests but 19200. The clock that is connected to the FTDI chip runs at 12 MHz. If you want a baudrate of 115200 you need to send a bit every 12,000,000 / 115,200 ~= 104 ticks. This means you need to change line 14 to if (counter == 104) begin.
I am trying to use the webusb api to connect my USB device which basically is a digitizer. the usb version is 2.0.
I have successed to request the device in chrome but failed to open the device with the error Access Deny.
request device
the usb device has 3 interface: 2 HID and 1 USB (winusb loaded). here is the information shown in xusb:
Using libusb v1.0.23.11397
Opening device 2D80:1010...
libusb: warning [hid_open] could not open HID device in R/W mode (keyboard or mouse?) - trying without
Device properties:
bus number: 1
port path: 14 (from root hub)
speed: 12 Mbit/s (USB FullSpeed)
Reading device descriptor:
length: 18
device class: 0
S/N: 3
VID:PID: 2D80:1010
bcdDevice: 0100
iMan:iProd:iSer: 1:2:3
nb confs: 1
Reading BOS descriptor: 1 caps
Unknown BOS device capability 05:
Reading first configuration descriptor:
nb interfaces: 3
interface[0]: id = 0
interface[0].altsetting[0]: num endpoints = 1
Class.SubClass.Protocol: 03.01.01
endpoint[0].address: 81
max packet size: 0040
polling interval: 01
interface[1]: id = 1
interface[1].altsetting[0]: num endpoints = 1
Class.SubClass.Protocol: 03.01.01
endpoint[0].address: 82
max packet size: 0040
polling interval: 01
interface[2]: id = 2
interface[2].altsetting[0]: num endpoints = 1
Class.SubClass.Protocol: FF.00.00
endpoint[0].address: 83
max packet size: 0040
polling interval: 00
Claiming interface 0...
Claiming interface 1...
Claiming interface 2...
Reading string descriptors:
String (0x01): ""
String (0x02): ""
String (0x03): "******"
Reading Extended Compat ID OS Feature Descriptor (wIndex = 0x0004):
libusb: warning [hid_submit_control_transfer] unsupported HID control request
libusb: warning [hid_submit_control_transfer] unsupported HID control request
00000000 28 00 00 00 00 01 04 00 01 00 00 00 00 00 00 00 (...............
00000010 02 01 57 49 4e 55 53 42 00 00 00 00 00 00 00 00 ..WINUSB........
00000020 00 00 00 00 00 00 00 00 ........
Reading Extended Properties OS Feature Descriptor (wIndex = 0x0005):
libusb: warning [hid_submit_control_transfer] unsupported HID control request
libusb: warning [hid_submit_control_transfer] unsupported HID control request
00000000 8e 00 00 00 00 01 05 00 01 00 84 00 00 00 01 00 ................
00000010 00 00 28 00 44 00 65 00 76 00 69 00 63 00 65 00 ..(.D.e.v.i.c.e.
00000020 49 00 6e 00 74 00 65 00 72 00 66 00 61 00 63 00 I.n.t.e.r.f.a.c.
00000030 65 00 47 00 55 00 49 00 44 00 00 00 4e 00 00 00 e.G.U.I.D...N...
00000040 7b 00 31 00 44 00 34 00 42 00 32 00 33 00 36 00 {.1.D.4.B.2.3.6.
00000050 35 00 2d 00 34 00 37 00 34 00 39 00 2d 00 34 00 5.-.4.7.4.9.-.4.
00000060 38 00 45 00 41 00 2d 00 42 00 33 00 38 00 41 00 8.E.A.-.B.3.8.A.
00000070 2d 00 37 00 43 00 36 00 46 00 44 00 44 00 44 00 -.7.C.6.F.D.D.D.
00000080 44 00 37 00 45 00 32 00 36 00 7d 00 00 00 D.7.E.2.6.}...
Releasing interface 0...
Releasing interface 1...
Releasing interface 2...
Closing device...
the first hid interface is used to report digitizer which i think it is already claimed by the system. I guess that is the issue because I have tried to remove the two hid interface and repeat the process. this time the device was opened successfully.
however the same issue is not presented on Mac OS.
so i am wonder if anyone has any suggestion to solve the issue on windows?
It is possible that this is a Chrome issue. I have been working on a new backend for connecting to USB devices on Windows that should be more reliable, especially for complex composite devices.
Please install Chrome canary-channel (at least version 84.0.4110.2) from https://www.google.com/chrome/canary/ and try turning on the “Enable new USB backend” in flag in chrome://flags.
Let me know if this resolves the issue.
For an app that has been around for many years, and which has stored the classic Alias records in files, I like to recreate Alias files pointing to the same file now, without having to resolve the Alias first (because the destination may be unavailable at that moment).
Supposedly this should accomplish this:
CFDataRef aliasRecord = ... ; // contains the Alias Record data, see below for an example
CFURLRef url = ... ; // initialized with a file URL
CFDataRef bmData = CFURLCreateBookmarkDataFromAliasRecord (NULL, aliasRecord);
CFError error;
bool ok = CFURLWriteBookmarkDataToFile (bmData, url, 0, &error);
However, the write function fails, and the error says "The file couldn’t be saved."
If I instead create bookmark data using CreateBookmarkData, the write succeeds.
How do I make this work? I'd try writing an old style Alias file with the data in the resource fork if that wasn't so utterly deprecated.
Here's an example alias record I'd have in the aliasRecord object - I can resolve this using the classic Alias Manager FSResolveAlias function, so I know that it is indeed valid.
00 00 00 00 01 12 00 02 00 01 06 54 54 73 4D 42
50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 CC 31 2F 12 48 2B 00 00 01 A5
F3 9B 03 74 6D 70 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 01 AC 1C 67 D1 FE B7 D0 00 00 00 00 00 00
00 00 FF FF FF FF 00 00 09 20 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 07 70 72 69 76 61 74
65 00 00 10 00 08 00 00 CC 31 12 F2 00 00 00 11
00 08 00 00 D1 FE 9B B0 00 00 00 01 00 04 01 A5
F3 9B 00 02 00 13 54 54 73 4D 42 50 3A 70 72 69
76 61 74 65 3A 00 74 6D 70 00 00 0E 00 08 00 03
00 74 00 6D 00 70 00 0F 00 0E 00 06 00 54 00 54
00 73 00 4D 00 42 00 50 00 12 00 0B 70 72 69 76
61 74 65 2F 74 6D 70 00 00 13 00 01 2F 00 FF FF
00 00
CFURLCreateBookmarkDataFromAliasRecord() doesn't create the bookmark data with the kCFURLBookmarkCreationSuitableForBookmarkFile option required by CFURLWriteBookmarkDataToFile().
CFURLCreateBookmarkDataFromAliasRecord() was intended as a way to convert alias records stored a program's own data files to bookmarks with no I/O.
Before CFURLWriteBookmarkDataToFile(), Finder Alias files (bookmark files) were created by the Finder. Those files contained an Alias resource (containing known properties that could be obtained from the Alias resource with FSCopyAliasInfo()) and icon resources. Apple needed the bookmark data in the files written by CFURLWriteBookmarkDataToFile() to provide the same properties. The kCFURLBookmarkCreationSuitableForBookmarkFile option enforces that requirement.
If you have an AliasHandle and want to create a new-style Alias file with bookmark data, you'll need to:
(1) resolve the AliasHandle to an FSRef, create a CFURLRef from the FSRef, and then create the bookmark data using the kCFURLBookmarkCreationSuitableForBookmarkFile option,
or
(2) you'll need to resolve the bookmark data created with CFURLCreateBookmarkDataFromAliasRecord(), and then create a new bookmark data using the kCFURLBookmarkCreationSuitableForBookmarkFile option.
However, you've indicated you'd like to handle this without resolving the AliasHandle, so the only solution is to create an old-style Finder Alias file. Although I know you already know how to accomplish that, it's described at How do I create a Finder alias within an application?.
The first time a user resolves/opens that old-style Alias file with the Finder, the Finder will detect the Alias file needs to be updated (i.e., CFURLCreateByResolvingBookmarkData() will return with isStale == true) and the Finder will create a new bookmark to the Alias file's target and re-write the Alias file. CFURLCreateBookmarkDataFromFile() will continue to support old-style Alias files as long as possible for backwards compatibility.
I'm currently writing an ssh honeypot in Java as a personal project. I'm having trouble understanding the algorithm negotiation. To be precise, the structure of the received data from the client. Here is what I receive, with my personal annotations:
00 00 07 AC == packet length
08 == padding length
14 == SSH_MSG_KEXINIT
6C 31 89 77 EB 54 E1 8B D4 B1 35 08 FD 52 65 6E == cookie
00 00 00 D4 == string length
kex algorithms in byte form
00 00 01 67 == string length
server host key algorithms in byte form
00 00 00 E9 == string length
encryption_algorithms_client_to_server in byte form
00 00 00 E9 == string length
encryption_algorithms_server_to_client in byte form
00 00 01 92 == string length
mac_algorithms_client_to_server in byte form
00 00 01 92 == string length
mac_algorithms_server_to_client in byte form
00 00 00 1A == string length
compression_algorithms_client_to_server in byte form
00 00 00 1A == string length
compression_algorithms_server_to_client in byte form
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Information about the negotiation can be found here:
rfc4253
There are two things I don't fully understand:
The padding: How is it calculated? According to rfc4253, there should be a random padding (8 bytes in this case). I don't see it anywhere. Moreover, the size of the packet length + padding length + payload + padding should be a multiple of 8, which isn't the case here. (?)
The packet length: If I just sum up everything after the packet length, I get 0x797. Adding the 8 byte padding (wherever it is), I get 0x79F. Am I correct in thinking that the languages for client->server and server->client, although not defined, still take 4 byte each? That gets me to 0x7A7. If I now add the boolean and the reserved 4 bytes (see packet structure), I finally get 0x7AC. Is that correct? That would mean the trailing zeros have the following structure:
00 00 00 00 == length of string for language_client_to_server
00 00 00 00 == length of string for language_server_to_client
00 == boolean first_kex_packet_follows
00 00 00 00 == reserved
rest: garbage?