My problem is that I used the "read and write" example on the Arduino to re-write an RFID card (MIFARE Classic 1K) block by block. I started writing at block 4. At block 7 it stopped and now I can't read any sector. I wrote zeros to each block.
The DumpToSerial function just prints for every sector
PCD_Authenticate() failed: Timeout in communication.
It can still read the UID, the SAK, and the PICC type.
Did I destroy the card or can I recover it?
Some more info:
Card: MIFARE Classic 1K
Arduino Mega2560 from Elegoo
RC522 from the starter-kit
With MIFARE Classic 1K, every 4th block is the sector trailer (each 4 blocks are grouped into one sector). The sector trailer contains the access keys (key A on bytes 0..5, key B on bytes 10..15) and access conditions (access bits on bytes 6..8) for a sector.
The access conditions are protected by a redundancy mechanism where each access bit is present multiple times in positive and negative logic. A MIFARE Classic card allows overwriting these access conditions with invalid values (impossible combinations of access bits). However, once the access conditions are set to such an invalid value, the security logic of the chip will disable all access to the wole sector. Consequently, writing invalid access conditions to the sector trailer renders the whole sector unusable. This state is permanent and cannot be reverted.
You wrote all blocks starting at block 4 with all-zeros. Consequently, you wrote the sector trailer of sector 1 (in block 7) with the access conditions set to all-zeros. This is an invalid value for the access conditions. Therefore, sector 1 is permanently unusable. Since you indicated that you immediately received errors after writing block 7, you might be lucky and did not overwrite other sector trailers (e.g. block 11 for sector 2). In that case, those other sectors should still be usable. Similarly, since you started writing at block 4, the first sector (sector 0, blocks 0..3) should also still be accessible.
Related
I can't authenticate the sector with "key A" after I write new content to the sector trailer block.
My tag is MIFARE Classic 1K and I use "MF_API.dll".
I do this:
On a new tag with default config, I authenticate with "key A" and value "FFFFFFFFFFFF", and the result is success.
Then, I write AAAAAAAAAAAA078069BBBBBBBBBBBB to the sector trailer.
When I then try to authenticate with "key A" and value "AAAAAAAAAAAA", it fails. The same thing happens when I try to authenticate with "key B" and value "BBBBBBBBBBBB".
Where is my mistake?
And my second question:
Is there any free software for writing and reading on MIFARE Classic 1K tags?
The value that you write to the sector trailer seems to miss one byte (the value is only 15 bytes long, but the trailer block is 16 bytes long). See Changing authentication key of a sector in MIFARE Classic for the format of the sector trailer block.
Moreover, the access bits (078069) that you have in your trailer block don't seem to be valid since this would be
C1 = 0x8 and nC1 = 7 (-> check okay)
C2 = 0x9 but nC2 = 0 (-> check not okay, since not(C2) would be 0x6)
C3 = 0x6 but nC3 = 0 (-> check not okay, since not(C3) would be 0x9)
As a result, if you managed to write this to the sector trailer, the sector will be permanently blocked (due to the checksum mismatch in the access bits), see Can I recover a MIFARE Classic card?.
Based on the values you used, I would guess that you actually wanted to write this to the sector trailer:
AAAAAAAAAAAAFF078069BBBBBBBBBBBB
Note that these permissions mean that you can authenticate to that sector with key A only, Key B is readable with those permissions and, consequently, cannot be used for authentication.
Regarding your second question: I would not recommend any specific software. Also, please be aware that this type of question is off-topic here.
I have noticed that in some of the cases in emv transactions, the tag 9f37(TAG_UNPREDICTABLE_NUMBER) length is not 4 bytes, It is a read only tag so I cannot set it. Please someone explain me is it must be 4 bytes or it can be of any length upto 4 bytes. And also please guide me how this number is generated and what can cause its length.
As the name denotes it should not be predictable by any means and you can use any random number generation algorithm to create a value whether you developing a card application or terminal app as explained below.
Unpredictable number is used during Offline Enciphered PIN verification to ensure
that PIN block generated is different at all times. This is
generated by the chip and length is 8 bytes(image 1). This unpredictable
number you will not see at host and you will need a tool like FIME
Smartspy or Keolab Nomadlab to get the value.
Another is Unpredictable number generated by Terminal which is used
in cryptogram generation ensuring a different cryptogram is
generated every time even when all other CDOL elements are same. Its
length is 4 bytes(image 2)
image 2
I am implementing USB as a host to read the files stored in the Flashdrive. To read I implement the read(10) command in SCSI.
This command has a field called Logical Block Address, as in the address I want to read. Now, I know the sector number I want to read.
So, is the Logical Block Address and Sector Number the same?
I looked into Cylinder-Head-Sector(CHS) but I dont have information about cylinder or heads
In common usage in SCSI, a sector is the same as a Logical Block Address. It is very likely that your device has 512-byte sectors (512-byte logical blocks). There are some high-performance SSD's and large-capacity spinning media drives that have 4096-byte sectors. These drives are labelled as having "Advanced Formatting".
CHS addressing isn't supported by SCSI. So, if you somehow have just a sector number, it's probably the SCSI "sector" or logical block address.
All of those integer fields in the typical SCSI commands are in big-endian format. If you're on a typical x86 PC of some kind, your integers will be little-endian format. Before you put your sector number in the field in your READ(10) command, you'll need to convert it with htobe32() or htonl(). Likewise for the num field: (htobe16() or htons()).
I have a board with quite a few flash chips, some of them are showing intermittent failures. Standard memory tests are not showing any specific problem addresses, other than certain chips are failing intermittently under mechanical and thermal stress.
Suspecting the actual connections and not the flash cells themselves, I'm looking for a way to test the parallel bus for address or data pin errors.
There are some memory tests but they apply better to RAM rather than flash memory (http://www.ganssle.com/testingram.htm). Specifically, the parallel flash has a sequence of bus writes to write to each value; a write/verify failure could easily be the write operation which could be any pin on the bus.
Ideas welcome...
The typical memory tests are there to do that. I prefer a pseudo randomizer (deterministic using an lfsr) to the 0xAA, 0x55, 0xFF, 0x00 tests. This allows for an address bus test as well as data bus test in two passes (repeat inverted). I say typical in the sense of wiggle the data bits and address bits both states each and vary the states of signals and their neighbors. The pounding on a ram to create thermal or other stresses, well you cant write very fast to a flash so you cant really do fast write/read cycles.
Flash creates another problem and that is writing then reading back isnt that interesting, you want to write the read back later, hours, days, weeks to determine if the part is actually holding data.
When you say thermal or stress do you mean only during the time it is above X degrees it fails, or do you mean that due to thermal stress it is broken all the time after the event. Likewise with mechanical, while vibrating or under mechanical stress the part fails, but when relieved of that stress it is okay, or the mechanical stress has done permanent damage that can be detected under stress or not.
Now although you cant do fast write/read cycles, you can punish a flash by reading heavily. I have seen read-disturb problems by constant reading of one block or location. Not necessarily something you have time to do for every location, but you might fill the ram with a pseudo random pattern and concentrate on one location for a while, (minutes, tens of minutes), if you have a part that you know is bad see if this accelerates the detection of the problem and if any location will work or only certain ones. then another thing is to read all the locations repetitively for hours/days or leave it sit for hours/days/weeks and then do a read pass without an erase or write and see if it has lost anything.
unfortunately as you probably know each new failure case takes its own research project and development of a new test.
First step to test a memory is data bus test0 0 0 0 0 0 0 • In this test, data bus wiring is properly tested to0 0 0 0 0 0 0 confirm that the value placed on data bus by processor0 0 0 0 0 0 0 is correctly received by memory device at the other end0 0 0 0 0 0 00 0 0 0 0 0 0 • An obvious way to test is to write all possible0 0 0 0 0 0 0 data values and verify 0 0 0 0 0 0 0 • Each bit can be tested independently• To perform walking 1s test, write the first data value given in the table, verify by reading it back, write the second value, verify and so on. • When you reach the end of the table, the test is complete
In the linked article Jack Ganssle says: "Critical to this [test], and every other RAM test algorithm, is that you write the pattern to all of RAM before doing the read test."
Since reading should be isolated from writing, testing the flash is easier. Perform the writing portion of the tests while the system is not under stress. Then perform the reading portion with the system under stress. By recording the address, expected value, and actual value in enough error cases, you should be able to determine the source of the errors.
If the system never fails when doing the above, you can then perform the whole tests while under stress. Any errors that appear are most likely write errors.
I've decided to design a memory pattern that I think I can deduce both data and address errors from. The concept is to use values significantly different as key indicators of possible read errors. The concept is also to detect a failure on one pin at a time.
The test will read alternately from only bottom and top addresses (0x000000 and 0x3FFFFF - my chip has 22 address lines). In those locations I will put 0xFF and 0x00 respectively (byte wide). The idea is to flip all address and data lines and see what happens. (All other values in the flash have at least 3 bits different from 0x00 and 0xFF)
There are 44 addresses that a single pin failure could send me to in error. In each address put one of 22 values to represent which of the 22 address pin was flipped. Each are 2 bits different from each other, and 3 bits different from 00 and FF. (I tried for 3 bits different from each other but 8 bits could only get 14 values)
07,0B,0D,0E,16,1A,1C,1F,25,29,2C,
2F,34,38,3D,3E,43,49,4A,4F,52,58
The remaining addresses I put a nice pattern of six values 33,55,66,99,AA,CC. (3 bits different from all other values) value(address) = nicePattern[ sum of bits set in address % 6];
I tested this and have statistically collected 100s of intermittent failure incidents synchronized to the mechanical stress.
single bit errors detectable
double bit errors deducible (Explainable by a combination of frequent single bit errors)
3 or more bit errors (generally inconclusive)
Even though some of the chips had 3 failing pins, 70% of the incidents were single bit (they usually didn't fail at the same time)
The testing group is now using this to identify which specific connections are failing.
I use AES128 crypto in CTR mode for encryption, implemented for different clients (Android/Java and iOS/ObjC). The 16 byte IV used when encrypting a packet is formated like this:
<11 byte nonce> | <4 byte packet counter> | 0
The packet counter (included in a sent packet) is increased by one for every packet sent. The last byte is used as block counter, so that packets with fewer than 256 blocks always get a unique counter value. I was under the assumption that the CTR mode specified that the counter should be increased by 1 for each block, using the 8 last bytes as counter in a big endian way, or that this at least was a de facto standard. This also seems to be the case in the Sun crypto implementation.
I was a bit surprised when the corresponding iOS implementation (using CommonCryptor, iOS 5.1) failed to decode every block except the first when decoding a packet. It seems that CommonCryptor defines the counter in some other way. The CommonCryptor can be created in both big endian and little endian mode, but some vague comments in the CommonCryptor code indicates that this is not (or at least has not been) fully supported:
http://www.opensource.apple.com/source/CommonCrypto/CommonCrypto-60026/Source/API/CommonCryptor.c
/* corecrypto only implements CTR_BE. No use of CTR_LE was found so we're marking
this as unimplemented for now. Also in Lion this was defined in reverse order.
See <rdar://problem/10306112> */
By decoding block by block, each time setting the IV as specified above, it works nicely.
My question: is there a "right" way of implementing the CTR/IV mode when decoding multiple blocks in a single go, or can I expect it to be interoperability problems when using different crypto libs? Is CommonCrypto bugged in this regard, or is it just a question of implementing the CTR mode differently?
The definition of the counter is (loosely) specified in NIST recommendation sp800-38a Appendix B. Note that NIST only specifies how to use CTR mode with regards to security; it does not define one standard algorithm for the counter.
To answer your question directly, whatever you do you should expect the counter to be incremented by one each time. The counter should represent a 128 bit big endian integer according to the NIST specifications. It may be that only the least significant (rightmost) bits are incremented, but that will usually not make a difference unless you pass the 2^32 - 1 or 2^64 - 1 value.
For the sake of compatibility you could decide to use the first (leftmost) 12 bytes as random nonce, and leave the latter ones to zero, then let the implementation of the CTR do the increments. In that case you simply use a 96 bit / 12 byte random at the start, in that case there is no need for a packet counter.
You are however limited to 2^32 * 16 bytes of plaintext until the counter uses up all the available bits. It is implementation specific if the counter returns to zero or if the nonce itself is included in the counter, so you may want to limit yourself to messages of 68,719,476,736 = ~68 GB (yes that's base 10, Giga means 1,000,000,000).
because of the birthday problem you've got a 2^48 chance (48 = 96 / 2) of creating a collision for the nonce (required for each message, not each block), so you should limit the amount of messages;
if some attacker tricks you into decrypting 2^32 packets for the same nonce, you run out of counter.
In case this is still incompatible (test!) then use the initial 8 bytes as nonce. Unfortunately that does mean that you need to limit the number of messages because of the birthday problem.
Further investigations sheds some light on the CommonCrypto problem:
In iOS 6.0.1 the little endian option is now unimplemented. Also, I have verified that CommonCrypto is bugged in that the CCCryptorReset method does not in fact change the IV as it should, instead using pre-existing IV. The behaviour in 6.0.1 is different from 5.x.
This is potentially a security risc, if you initialize CommonCrypto with a nulled IV, and reset it to the actual IV right before encrypting. This would lead to all your data being encrypted with the same (nulled) IV, and multiple streams (that perhaps should have different IV but use same key) would leak data via a simple XOR of packets with corresponding ctr.