2

I've got one old brandless giveaway USB flash pendrive, but two disks show up on the running systems instead. One of them is writable but the other is readonly even if there isn't physical write-protect switch visible outside.

On Windows:

WIN-R: diskpart

DISKPART> list disk
...
disk 1 online ...
disk 2 online ...

DISKPART> list volume
...
volume 2 normal ...
volume 3 normal ...

DISKPART> select disk 1
DISKPART> attributes disk
readonly status: no
readonly: no

DISKPART> select disk 2
DISKPART> list partition
partition 1 ...
DISKPART> attributes disk
readonly status: yes
readonly: yes
DISKPART> attributes disk clear readonly
DISKPART> attributes disk
readonly status: yes
readonly: no

DISKPART> select partition 1
DISKPART> format
error: write protection

On Linux:

$ sudo parted -l    
...
Model: Generic Flash Disk
Disk /dev/sdb ...
Warning: Unable to open /dev/sdc read-write (Read-only file system). /dev/sdc has been opened read-only.
Model: Generic Flash Disk
Disk /dev/sdc ...

$ sudo parted /dev/sdc
Warning: Unable to open /dev/sdc read-write (Read-only file system). /dev/sdc has been opened read-only.

(parted) print
number 1 ...

(parted) rm 1
error: not permitted to write

I've googled around and found this article on internal hardware/firmware based USB write-protect. How to verify if it is the case as mentioned by the article? Otherwise, how to remove this sort of USB write-protect?

I've also tried to zero sector 0 with diskpart on Windows as commented @JoepvanSteen, but the readonly status remains.

DISKPART> clean
DISKPART> attributes disk
readyonly status: yes
readonly: no
DISKPART> clean
error: device i/o

Additionally, using Disk Management tool on Windows shows that the volume for disk 2 has functional FAT filesystem, but all the writable options in the sub-menu popup from this volume become grayed out.

As a side note, I firstly posted this problem on stackoverflow and was hoping some firmware devs to give diagnosis hints, but the mod considered it off-topic. It's worthless in terms of economic value to solve this problem but valuable to learn and sort out the underlying during the course of investigation.

Improve this question
13
  • Does it matter if two show up, as long as you can write to one of them.
    – Rohit Gupta
    Commented Jan 30, 2023 at 11:57
  • The two disks shown up aren't physically same. Let's say the pendrive has 100 sectors, disk 1 is from 1 to 50, disk 2 from 51 to 100.
    – sof
    Commented Jan 30, 2023 at 12:13
  • Can't you just zero sector 0 and create a new partition? See superuser.com/a/1760400/705502
    – Joep van Steen
    Commented Jan 30, 2023 at 13:05
  • @JoepvanSteen obviously this isn't due to partitioning
    – Tom Yan
    Commented Jan 30, 2023 at 13:27
  • 1
    For me two indicators point to either firmware malfunction or misconfiguration. 1) zero sector 0 worked at the first time, which meant disk 2 was partially writable, but failure to zero again with device i/o error meant the firmware refused to accept further write operation. 2) clearing readonly led to inconsistent results - readonly: NO but readonly status: YES.
    – sof
    Commented Jan 30, 2023 at 17:25

1 Answer 1

Reset to default
1

I'm going on with the investigation and approaching the root cause via standard Linux tools as follows.

Firstly, the USB device claims disk 2 write-protect when it's plugged into the running host system, and the host follows the claim thus disables writable operations.

$ dmesg
New USB device found, idVendor=...., idProduct=....
[sdb] Write Protect is off
[sdc] Write Protect is on

Secondly, let the host believe in disk 2 writable via USB quirk mode, then the host can send the write request on disk 2 to the device, but the device refuses to write on disk 2 and responds sense key data protect to the host, so the readonly remains intact.

$ dmesg
[sdc] Assuming Write Enabled
[sdc] Write ...
[sdc] Sense Key : Data Protect

Finally, the USB drive controller is listed with a reputable vendor via lsusb command, and it can have imposed readonly status on disk 2 indeed thus avoid unlocking effectively. On the other hand, the controller/firmware has somehow malfunctioned due to allowing zero sector 0 initially, thus ruined the partition even if the data content remains write-protect.

Improve this answer
1
  • "the controller/firmware has somehow malfunctioned due to allowing zero sector 0 initially" .. probably just the last straw. If it's firmware lvl, which I think it is, it must be addressed that that level, see my chipgenius comment ^^^. It's very well possible firmware issues are a result of shitty NAND in which case this is all wasted effort.
    – Joep van Steen
    Commented Jan 31, 2023 at 11:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .