When sending the FormatPICC command to a MIFARE DESFire EV1 card, I observe the following behavior:
PCD ---> PICC
--------------
0xFC --->
<--- 0x00 or 0x00 + MAC or ERROR CODE
If authenticated with the command 0x0A (legacy (3)DES authentication), the response to the FormatPICC command is only one byte (0x00).
If authenticated with the command 0xAA (AES authentication), the response to the FormatPICC command is the status byte (0x00) plus the MAC.
When I send another command (e.g. GetVersion (0x60)), the response does not contain the MAC regardless of which authentication was used (0x0A or 0xAA).
Why is that difference? Should I still calculate the MAC for such commands (to update crypto state)? Is there some document that explains that?
Your observation seems to be wrong. Once authenticated using either AuthenticateISO (0x1A) with TDES or AuthenticateAES (0xAA), MIFARE DESFire EV1 will return a MAC in response to all commands (except, of course, the authentication commands and SelectApplication, which both reset authentication).
Consequently, a MAC should be returned in response to the GetVersion command. However, note that the GetVersion command is split across 3 frames. The MAC is only appended to the last frame (the one with the status code 0x00):
PCD ---> PICC
--------------
0x60 --->
<--- 0xAF + DATA
0xAF --->
<--- 0xAF + DATA
0xAF --->
<--- 0x00 + DATA + MAC
Related
I want to do mass erase on my msp430f2619 using bsl. I use software jump in my code to invoke bsl. I send 0x80, get 0x90 from BSL(ack). Then i send mass erase command and get 0x90 again. Then i power off my device, then i power on the device, then i send 0x80 and get 0x90, that means there was no mass erase operation.
Read command is not working too. I send password (0xFF 32 times), after that send rx command, then i get few coorect bytes, and then infinite raw of 0xff.
I think i miised something before jump to bsl, please give an example code, or step by step instruction on how to make software jump to bsl and make it work correctly.
If you are sending 0x80 only, then get back 0x90, this confirms you have entered into the BSL since this completes the required synchronization sequence (see section 2.1 of this document). You should not require the "RX password" command since the "Mass erase" command is not protected.
The next sequence after the synchronization is to send the desired command, which should be the "Mass erase". There is a format to each of the BSL commands called the data frame. You want to send the following data frame: eight mandatory bytes (note two dummy bytes), and two checksum bytes. Note the "Mass erase" command does not contain data bytes, but you need to calculate the checksum bytes. Here are the bytes to be sent to perform the mass erase:
80 18 04 04 dd dd 06 A5 CL CH
Where: dd = dummy bytes (any value accepted), CL = Checksum low, CH = Checksum high
After sending this data frame then you should receive the ACK (0x90) byte. Then power off the device.
Linux kernel : 5.4.24
We are using bluez with a 5.0 feature enabled controller. When doing hciconfig hci0 reset we can see that in LE Set Extended Advertising Parameters even when properties is set as ADV_NONCONN_IND legacy as below:
< HCI Command: LE Set Extended Advertising Parameters (0x08|0x0036) plen 25 #83 [hci0] 9.977909
Handle: 0x00
Properties: 0x0010
Use legacy advertising PDUs: ADV_NONCONN_IND
We can still see bluez sending Ext Scan Rsp Data as below:
< HCI Command: LE Set Extended Scan Response Data (0x08|0x0038) plen 35 #87 [hci0] 9.984415
Handle: 0x00
Operation: Complete scan response data (0x03)
Fragment preference: Minimize fragmentation (0x01)
Data length: 0x0c
Name (complete): pvqseqevk
And since spec says :
If the advertising set is non-scannable and the Host uses this command other
than to discard existing data, the Controller shall return the error code Invalid
HCI Command Parameters (0x12).
The controller is returning this error:
> HCI Event: Command Complete (0x0e) plen 4 #88 [hci0] 9.989066
LE Set Extended Scan Response Data (0x08|0x0038) ncmd 1
Status: Invalid HCI Command Parameters (0x12)
Also, after this command the next commands are passing as seen in hcidump/btmon, but the kernel throws error because this command fails.
My question is , what is the expected behavior?
If this behavior is correct, should we just ignore the error?
If the behavior is wrong, is there any fix already for this?
I'm reading this data sheet for a camera.
Datasheet
I have my Arduino communicating with the camera over SPI and can send it a command to take a picture.
The last step is to send a command to retrieve the data, which I'm stuck on.
On page 4 the command DATA is
FF FF FF 0x0A 0X05 Length Byte 0 Length Byte 1 Length Byte 2'
So in code the command would look like this. But how do I figure out what Length Byte 0, Byte 1 Length Byte 2 are??
uint8_t DataCmd[8] = { 0xff, 0xff, 0xff, 0x0a, 0x05, ?, ?, ?};
On page 6 it says
Image Length = len 0 + Len 1 * 100h + Len 2 * 10000h
What does this mean? And how to I translate it into the three parameters that I need for my command?
As you can read, the DATA command is a command sent BY the camera to you. The flow chart at page 9 shows what it does
When the camera receives "get picture",
is the picture ready? if not send a NAK and return
if it is send an ACK
send the DATA command (with the length)
send the picture data
wait for the host to send an ACK
Page 10 has the steps you have to perform. I'll copy them here for future reference:
Establish communication with the camera
Send command INIT (e.g. FFFFFF0100870107h)
Wait for the ACK (e.g. FFFFFF0E01nn0000h)
Send command SELECT IMAGE QUALITY (e.g. FFFFFF1000000000h)
Wait for the ACK (e.g. FFFFFF0E10nn0000h)
Send command GET PICTURE (e.g. FFFFFF0405000000h)
Wait for the ACK (e.g. FFFFFF0E04nn0000h)
Wait for the DATA (e.g. FFFFFF0AnnL0L1L2h)
Receive Image Data
The DATA packet contains L0, L1 and L2, which contain the data image length. L0 is the low-order byte, so if L0 = 0x45, L1 = 0x23, L2 = 0x01 the total length will be 0x012345 = L0 + L1 * 0x100 + L2 * 0x1000; this means that the image is 0x12345 = 74565 bytes, so you know how many bytes you will receive before actually receiving them
I am implementing USB as a host using OHCI to read the files stored in the Flashdrive. To read I implement the read(10) command in SCSI. The Logical Block address being the sector number. The following is an image of the command I send for read(10) to read LBA 0x0000-
http://i.imgur.com/ky4FHlm.png
I read 512bytes(size of one sector or 1 LBA)and the following is the output that i get for LBA 0x0000-
http://imgur.com/jL6OEjE
The bytes in the above image are not present any where on the pendrive, I checked that using HXD. Now, for testing I filled the pendrive to full capacity. If I read any other LBA, other than 0x0000, then I always get 512 bytes of 0x00.
Could anyone please tell me what the problem could be?
Am I supposed to execute some other command before I do a read(10) so that the USB sends me the right data maybe?
From my understanding I have put DPO, FUA and FUA_NV=0 and also RDPROTECT=2
I am using Telit modem GL 868 Dual V3. AT command AT#SCFG has 2 parameters- packet size to be used and data sending time-out for TCP. Is there any AT command which specifies that if any delimiter string is found, then that data will be sent on TCP ignoring the packet size and time-out?
There are commands #PADFWD, #PADCMD which serves the purpose of delimiter.
Below is a snapshot from AT commands reference guide for telit modem.