- Obtained from: AliExpress
- Advertised capacity: 128GB
- Fake/skimpy flash: Fake flash
- Protected area: 0 bytes
- Speed class markings: None
| Sample # | 1 | 2 | 3 | Average |
|---|---|---|---|---|
| Price paid | $3.98 | $3.48 | $3.48 | $3.65 |
| Logical capacity | 134,218,776,576 bytes | 134,217,728,000 bytes | 134,217,728,000 bytes | 134,218,077,525 bytes |
| Physical capacity | 8,052,895,232 bytes | 8,233,943,040 bytes | 8,414,822,400 bytes | 8,233,886,890 bytes |
| Manufacturer ID | 0x00 | 0x05 | 0x05 | N/A |
| OEM ID | 0x0000 | 0x000c | 0x000c | N/A |
| Product name | 0x4150505344 (ASCII: APPSD) | 0x6173646667 (ASCII: asdfg) | 0x6173646667 (ASCII: asdfg) | N/A |
| Product revision | 0x00 | 0x22 | 0x22 | N/A |
| Manufacture date | Oct 2022 | Mar 2024 | Mar 2024 | N/A |
| Serial number | 0x12800006 | 0x0000241c | 0x00004453 | N/A |
| Sequential read speed (MB/sec) | 16.51 | 23.12 | 23.14 | 20.92 |
| Sequential write speed (MB/sec) | 4.47 | 4.84 | 4.66 | 4.66 |
| Random read speed (IOPS/sec) | 1,283.48 | 1,679.00 | 1,770.20 | 1,577.56 |
| Random write speed (IOPS/sec) | 1.01 | 146.34 | 143.03 | 96.79 |
| Read/write cycles to first error | 327 | 998 | 1,631 | 985 |
| Read/write cycles to complete failure | 2,610 | 2,082 | Not yet determined | 2,346 |
| Total days to complete failure | 163 | 54 | Not yet determined | 109 |
| Card reader used | SanDisk MobileMate | JJS CR-UTC4AC | JJS CR-UTC4AC | N/A |
| Package front |  |  |  | N/A |
| Package back |  |  |  | N/A |
| Card front |  |  |  | N/A |
| Card back |  |  |  | N/A |
Discussion
This is one I found while browsing randomly through AliExpress, and one I heavily suspected would be fake flash when I ordered it. I was curious to see whether lower and higher capacity models would both be fake flash, or if these sellers would limit their fake flash to just higher capacity models — so I bought a single 128GB card (which was the lowest capacity they offered) and a single 2TB card. Later, after I made the decision to test at least three samples of each brand/model/capacity, I went back and ordered two more. Unfortunately, the seller sent me 256GB cards, so I had to order another two from a different seller. Spoiler: they’re all fake flash.
Disclaimer: I don’t think Lenovo had anything to do with this card. I think this is an unlicensed knock-off (hence why “Lenovo” is in quotes).
I’ve noticed a number of trends with some (though not all) fake flash. For example, many fake flash cards bear the name of well-known electronics manufacturer, even though the manufacturer is not known for selling SD cards. (For example, I’ve obtained cards bearing the names of Lenovo, Sony, and Xiaomi.) Most of them — or at least, the ones I’ve been able to read the CID data from — have had their manufacturer ID set to 0x00 and their OEM ID set to 0x0000, presumably to hide the identity of their manufacturer. Additionally, these cards also tend to have pretty abysmal performance across the board. This card is no exception: all performance results have been below average, with most results being more than one standard deviation below average.
This particular seller also attempted to be sneaky by not including any of the standard speed class marks. Instead, they opted to include the Nintendo Switch icon instead — which, last I checked, wasn’t an indicator of speed. (They did include the UHS-I mark, but this mark by itself also doesn’t make any assertions as to the card’s read or write speeds.)
Sample #1 chugged along on its endurance test for quite some time; however, it only managed to go 327 read/write cycles before starting to display data mismatch errors. At first, the errors only affected two sectors; however, the number of sectors increased nearly every round after that. (Almost all of these errors have been bit-flip errors.)
This eventually caused problems for my code’s device detection logic: the program keeps a copy of the data that it wrote to two fixed segments on the card. When a device is disconnected and reconnected, or when the program is interrupted and restarted, it tries to automatically identify which device it was testing, and it reads back the contents of both of those segments as part of that process. However, this card had so many sectors go bad that both of those segments quickly became unstable. When an issue occurred, I had to restart the endurance test from scratch.
Sample #1 spent most of its endurance test in one of the SanDisk MobileMate readers. However, as a JJS CR-UTC4AC reader became available, I moved it to one of those readers. This, of course, necessitated the restart of the endurance test. Strangely, on the first round of the endurance test, large portions of the card that had been marked as bad in other tests passed verification; however, the remainder of the card failed verification. At this point, over 50% of the sectors on the card had been flagged as bad, and the endurance test was ended.
Sample #2’s first error was a bit flip error that affected two sectors during round 999. It kept going for a while — continuing to experience a number of bit flips, but managing to stay under the 1% failure threshold — right up until round 2,083. In that round, every single sector that it read from the device came back as all 0xff‘s — at which point the card was declared dead (since it reached the 50% error threshold). Here’s the graph of this card’s progression:
Sample #3’s first error was a bit flip error that affected two sectors during round 1,632. It has survived 2,010 read/write cycles in total so far.
July 16, 2024 (current number of read/write cycles is updated automatically every hour)