Question Strange SD card reads differently every time ?

Status
Not open for further replies.
Jul 12, 2022
21
0
10
I've bought a micro SD card and it reads differently every time:
Bash:
% for i in {1..10}; do sudo sha256sum /dev/sda; done
c066195ad1c5cec4d2b968287a6ec05318f46890f18f31b4a5ed805a1a0db27e  /dev/sda
0eb9b1f88f9d91ebe2fcddf4e9ff28669c5fc311c46ba82e41196704f0a93a86  /dev/sda
b64c6bbc61e3e383a91513f0e352c7569d69d92981778519feec5a4d8a537612  /dev/sda
6cc23f610cb4a4b4b6a4559f4371cd1e0fa47cbb4cfe2807884690f49871622a  /dev/sda
f9054883a25157bf48a785b445199b100976129718a90f9cb6b9022034fb2df4  /dev/sda
e4696bec314352d9508576606d942b149723e13bd4185cac66287d5fde9deaf1  /dev/sda
749e2d81f019600eedbb2e0dcb0f1680942ec00c42e636ab3cf4f5acfebff3d0  /dev/sda
27a37e636b3279931db3df6bf68ae8d6d6a4f1802b7db68ddfeb39949219e5c7  /dev/sda
4b01d013fa09279aa7096e9d30895fa0f62364f0abe259b276c547cd74bd396d  /dev/sda
f7977bc8723cf5d78171f2dc85628ea872becb75b5f5a513c99d169205c0ff21  /dev/sda
*it was not mounted even the hardware read-only switch was on (SD card adapter).
** don't think /dev/sda is my harddrive.
I've though if there is a damaged sector (or more than one) it won't be able to write correctly. But it will read the same so the checksums will match. I've tried multiple card readers. Or is this fake card which gives random data? It can't even make new partition table and file system.

I've bought 2 x 128MB micro SD cards from aliexpress. Both act the same. I know they can be used, sanded, "recycled" and sold as new. I am fine with that I just want a small SD card to put one mp3 file for my phone.

It looks so strange for me or this is typical for damaged SD card? Can this be related to the so small size (128MB)? Something incompatible?
 
Last edited:

Colif

Win 11 Master
Moderator
Last edited:
Jul 12, 2022
21
0
10
I've written 00 to every byte with "dd if=/dev/zero of=/dev/...". Then checked how many bytes are read as not 00. Then I've written 00 to every byte again - the non 00 bytes have increased twice. I've repeated again. There were even more bad sectors.
It looks like those SD cards are so much worn-out that they can't even read.

H2testW requires a partition but I can't make one. In Linux we have f3 which is compatible with H2testW but also requires a partition. I prefer a better tool - dd.

It was $2 for both.
 
Last edited:

Colif

Win 11 Master
Moderator
Buying from them is like playing lucky dip, but the chances of a prize is really slim. Too many live mouse traps in the box, I wouldn't stick my hand in there.

If the big ones are fake, there is no point expecting anything else to be real. There are YouTube channels that just buy from sites like this just to show other people why you shouldn't.
 
Jul 12, 2022
21
0
10
I'll answer but you've missed the point here. It's not where I've bought if from or why it was more like what happens when you read bad sector? When you've overwritten an SD card so many times and it can no longer store data. I've thought those sectors will stuck and you can't write to them correctly but they will read the same thing consistently. It turns out they give random data (from my testing usually one bit was wrong). I guess the more I write the more bits will become bad and this should be why the non 00 bytes have increased. Another option was something to incompatible (card reader, driver, bad contact). If someone has experienced such situation to share their opinion.

Here are my reasons. I need non HC micro SD card. Finding a new one would be really hard and it won't worth the money. I can buy a used one but the shipping alone (inside my country) will be around $3. So a $1 including shipping from China was a good option.

If anyone wonders the wrong bytes are about 500000~510000. Different number each time.
 
Last edited:

USAFRet

Titan
Moderator
I'll answer but you've missed the point here. It's not where I've bought if from or why it was more like what happens when you read bad sector? When you've overwritten an SD card so many times and it can no longer store data. I've thought those sectors will stuck and you can't write to them correctly but they will read the same thing consistently. It turns out they give random data (from my testing usually one bit was wrong). I guess the more I write the more bits will become bad and this should be why the non 00 bytes have increased. Another option was something to incompatible (card reader, driver, bad contact). If someone has experienced such situation to share their opinion.

Here are my reasons. I need non HC micro SD card. Finding a new one would be really hard and it won't worth the money. I can buy a used one but the shipping alone (inside my country) will be around $3. So a $1 including shipping from China was a good option.

If anyone wonders the wrong bytes are about 500000~510000. Different number each time.
Its not a matter of 'bad bits', or that it was "used".

Rather, it is that this is a junk device. A scam.
There was never 128GB actual space on it.

And it is partially 'where you bought it'.
AliExpress is known for selling scam and junk.


What is the requirement for non HC microSD?
 
Jul 12, 2022
21
0
10
I know about the scams but you aren't reading closely. It's 128MB not GB. I want to put one mp3 file on. There is no 128GB non HC.
The capacity is fine - its 120MB the integrity is important:
Code:
sd 6:0:0:0: [sdb] 245760 512-byte logical blocks: (126 MB/120 MiB)
sd 6:0:0:0: [sdb] Write Protect is on
sd 6:0:0:0: [sdb] Mode Sense: 03 00 80 00
sdb: detected capacity change from 0 to 245760
If I write:
Code:
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
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 00 00  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
I read (if I read again it slightly changes):
Rich (BB code):
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00000020  00 00 01 00 00 00 00 00  00 00 00 04 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 02 00 00  00 00 00 00 00 00 00 00
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00000060  00 00 00 00 00 00 00 00  10 00 00 00 00 00 00 00
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
You can calculate how many 'bits' have been changed in every byte.

When I've ordered I new that they are probably used but not worn-out.
 
Last edited:
I've bought a micro SD card and it reads differently every time:
Bash:
% for i in {1..10}; do sudo sha256sum /dev/sda; done
c066195ad1c5cec4d2b968287a6ec05318f46890f18f31b4a5ed805a1a0db27e  /dev/sda
0eb9b1f88f9d91ebe2fcddf4e9ff28669c5fc311c46ba82e41196704f0a93a86  /dev/sda
b64c6bbc61e3e383a91513f0e352c7569d69d92981778519feec5a4d8a537612  /dev/sda
6cc23f610cb4a4b4b6a4559f4371cd1e0fa47cbb4cfe2807884690f49871622a  /dev/sda
f9054883a25157bf48a785b445199b100976129718a90f9cb6b9022034fb2df4  /dev/sda
e4696bec314352d9508576606d942b149723e13bd4185cac66287d5fde9deaf1  /dev/sda
749e2d81f019600eedbb2e0dcb0f1680942ec00c42e636ab3cf4f5acfebff3d0  /dev/sda
27a37e636b3279931db3df6bf68ae8d6d6a4f1802b7db68ddfeb39949219e5c7  /dev/sda
4b01d013fa09279aa7096e9d30895fa0f62364f0abe259b276c547cd74bd396d  /dev/sda
f7977bc8723cf5d78171f2dc85628ea872becb75b5f5a513c99d169205c0ff21  /dev/sda
*it was not mounted even the hardware read-only switch was on (SD card adapter).
** don't think /dev/sda is my harddrive.
I've though if there is a damaged sector (or more than one) it won't be able to write correctly. But it will read the same so the checksums will match. I've tried multiple card readers. Or is this fake card which gives random data? It can't even make new partition table and file system.

I've bought 2 x 128MB micro SD cards from aliexpress. Both act the same. I know they can be used, sanded, "recycled" and sold as new. I am fine with that I just want a small SD card to put one mp3 file for my phone.

It looks so strange for me or this is typical for damaged SD card? Can this be related to the so small size (128MB)? Something incompatible?
/dev/sda is almost always the boot volume and is subject to change at any time, for a multitude of reasons. Unless you're booting from this SD card you're analyzing the wrong drive.
 
Jul 12, 2022
21
0
10
** don't think /dev/sda is my harddrive.
@ex_bubblehead /dev/sda is the correct one because I boot a live iso from RAM. I can explain:
/dev/sda is the live iso but I copy it to RAM with kernel parameter then eject the bootable iso and put the 128MB card in the same card reader. It's still /dev/sda but different SD card.

This is not my first time doing it.
 
Last edited:
It appears that the bits are random. A "1" is indicative of a cell that has been erased, or not programmed. It does look like your cards are worn out.

That said, I would think that if two reads from the same sector are inconsistent, then at least one must be a bad read. Moreover, if it is a bad read, then the controller should be aware that it is bad because there will be an ECC error. This error should then be reported to the host OS.
 
Last edited:
Jul 12, 2022
21
0
10
It appears that the bits are random. A "1" is indicative of a cell that has been erased, or not programmed. It does look like your cards are worn out.

That said, I would think that if two reads from the same sector are inconsistent, then at least one must be a bad read. Moreover, if it is a bad read, then the controller should be aware that it is bad because there will be an ECC error. This error should then be reported to the host OS.
That would be a game changer. I don't see any ECC errors with dmesg or journalctl. Probably I don't know where to look for them. Searching online only shows RAM related stuff.
 
When a sector is written to the NAND flash, additional ECC bytes are calculated and written to the NAND's spare area. When the sector is subsequently read, the ECC is once again calculated and compared against the stored ECC. If there is a difference, and if the number of bit errors is too great to enable them to be corrected, the device should then report a read error to the host. The fact that no read error was reported (?) would suggest that the data were read correctly and the subsequent errors were then caused by the external interface or an internal data bus.

That said, you say that you have tried different readers and different SD cards, so am at a loss to understand the problem. I assume that each reader has its own 3.3V supply, so that would tend to rule out a supply issue.
 
Jul 12, 2022
21
0
10
I've tried:
2 SD cards - act the same
1 SD and 1 micro SD card readers - act the same
an old phone - tries to format and fails
an Android device - doesn't recognize them
also cleaned the contacts many times

Are you sure the SD cards have ECC/parity check or whatever is called? Do they all have it? It should be on hardware level remember I read the block device like a file there is no file system.

I've also tried badblocks. It reports 0 errors in read-only mode and hundreds of thousands errors in write mode (in write mode it writes patterns then checks them).
 
Last edited:
Today's NAND flash devices all have ECC. This is transparent to the host. I can't say what was used during the early days -- I'm not a data recovery professional.

A lot of DR pros hang out here:

https://ww.reddit.com/r/datarecovery/rising/

You might like to ask them.

In the meantime ...

NAND Flash Data Recovery Cookbook (by Igor Sestanj):
http://adreca.net/NAND-Flash-Data-Recovery-Cookbook.pdf

Here is a thread where there was a stuck bit on the interface due to a problem with the reader:

https://groups.google.com/g/datarecoverycertification/c/VshfKZ--t5A/m/aznDgWVkAwAJ

Try to identify the controller and flash ICs with ChipGenius.
 
Jul 12, 2022
21
0
10
Here is 0xFF. It no longer writes until 00046000. This is the first 280KB.
00045fd0 00 00 00 02 00 00 00 00 10 00 00 00 00 10 00 00 00045fe0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 00046000 ff ff ff ff ff ff ff ff ff ff ff fe ff ff fe ff 00046010 ff ff ff ff fb ff ff ff f7 fb ff ff ff ff ff ff

Some more samples:
0% 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000010 00 00 00 00 00 00 00 80 00 00 00 08 00 00 00 00 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 01 00 00 00 00 00 00 00 00 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00000050 80 00 00 00 00 00 00 04 00 00 00 00 00 00 00 00 1% 0011bb80 ff ff ff ff fd ff ff bf ff ff ff ff ff ff ff ff 0011bb90 ff ff ff ff fe ff ff ff ff ff ff df ff ff ff ff 10% 00b93460 fa ff ff 7f ff ff ff ff ff ff ff ff ff ff ff ff 00b93470 ff fe fe ff ff ff ff ff fe ff ff fb ff ff ff ff 50% 03bd2960 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 03bd2970 ff ef f7 ff ff ff ff ff ff ff ff ff fd ff ff ff 99% 076da8c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff f7 076da8d0 ff ff ff ff ff bf ff ff ff ff ff ff ff ff ff ff

Just because I have it here is 0xAA:
00178c80 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 00178c90 2a aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 00178ca0 aa a2 aa aa aa aa aa aa aa aa aa aa 8a 8a aa aa 00178cb0 aa aa aa aa aa aa aa aa aa aa aa a2 aa aa aa aa 00178cc0 aa aa aa 28 aa aa aa aa aa aa aa aa aa aa aa aa
And again no error when reading or writing (in dmesg or journalctl).
 
Jul 12, 2022
21
0
10
Thanks for everyone's help. I am done with those SD cards but will ask in some Linux specialized forum for those ECC errors. If they exist it will change my life.
 
Status
Not open for further replies.