It started as an effort to help a friend who needed a microSD card to load a custom Linux image for his Raspberry Pi. I gave him my card, and he backed up all the data, and then attempted to format it using dd.

It did not work. And there began the hell that lasted for multiple hours that killed a computer and injured another, spit out error codes that were not in OSX/Linux documentation, and confused and challenged and generally wasted the time of many hackers.

What it does

XCalibur can be written to. XCalibur can be read from. But God forbid if you attempt to overwrite its filesystem. It's built in Knights of the Round TableTM technology fights off hackers and meddlers with ease. It doesn't just prevent access, but as any good fighting force, lures the enemy into a false sense of security, and when they believe they have succeed, strikes unexpectedly and renders their work utterly useless.

Attempts at formatting:

  1. @Ben backs up all current data on drive. Attempts to use ApplePi-Baker the Raspbian image onto it.
  2. @Dev attempts to use fdisk to delete the partition. Old partition shows as deleted in fdisk. No errors. Write successful. Drive is unresponsive when trying to mount again, take it out. Plug it back in, no change in file system. All files are readable / accessable as if fdisk did no operations.
  3. @Shanantu given XCalibur to attempt to format. Plugs in his computer, and it freezes his computer. Needs to force restart.
  4. @Jordan given microSD card to attempts format. Using Ubuntu with gparted, gparted shows that it has successfully deleted partition. Eject drive, plug back in, looks like no change. Frustrated, attempts "touch" for foo.txt. Touch successful, file shows in explorer, openable, editable, saveable. Eject drive. Place drive back in, file is gone. Attempt to format again, still nothing. Frustrated, attempt to simply delete all data on drive with rm -rf. Jordan messes up and rm -rf / instead of rm -rf /dev/sdb. His ubuntu filesystem nuked, and spends next 9 hours trying to attempt to install another linux system on top of it (still unable to, something corrupted on his ssd we believe through the rm -rf command).
  5. @Ben attempts another format using official Mac SD card formatting tool this time. Spits out error -50, which as far as we researched, is undocumented. We do find that the official tool is by "".
  6. @Dev attempts to continue looking up possible errors and ways to check for bad sectors. Command "fsck -a" is run, which has the output: icarus@Castle ~]$ sudo fsck -a /dev/sdb1 [sudo] password for icarus: fsck from util-linux 2.27.1 fsck.fat 3.0.28 (2015-05-16) 0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt. Automatically removing dirty bit. FATs differ but appear to be intact. Using first FAT. Free cluster summary wrong (1554557 vs. really 1554558) Auto-correcting. Performing changes. /dev/sdb1: 1583 files, 388034/1942592 clusters [icarus@Castle ~]$ sudo fsck -a /dev/sdb1 fsck from util-linux 2.27.1 fsck.fat 3.0.28 (2015-05-16) /dev/sdb1: 1583 files, 388034/1942592 clusters [icarus@Castle ~]$ Running fsck fixed the problem, and on second run saw an error free run. After safely ejecting and plugging it back in, XCalibur again had the same fsck dirty bit error as before.

We attempted to perhaps break it more by changing its partition table from MDOS to GPT, but despite the use of both CLI and GUI toolsets,

@Nelson & Shanantu attempts on windows PC: Removed MicroSD from USB and put it in SD adapter

  1. Inserted SD-adapter into Windows 10 computer
  2. diskpart
  3. list disk
  4. select disk 1 (SD)
  5. list partition Partition 1 | Primary | 14 GB | 1024 KB offset
  6. clean Succeeded in cleaning
  7. list partition Partition 1 | Primary | 14 GB | 1024 KB offset
  8. regedit did not show a key named StorageDevicePolicies Created key manually to set "Write Protection" to 0
  9. attributes disk clear readonly Disk attributes cleared successfully.
  10. Attempted to quick format FAT32 Windows states "Windows was unable to complete the format."
  11. Attempted formatting from diskpart DiskPart has encountered an error: Parameter is incorrect. Suggests checking event log.
  12. Checked event log, Windows did not appear to log anything
  13. Reverted to USB adapter
  14. Mounted in Ubuntu via USB adapter
  15. Device auto-mounted, attempted to touch a file
  16. ls showed file in the root of the SD card
  17. echo ayy lmao > file
  18. sync
  19. cat file output is "ayy lmao"
  20. sudo umount /dev/sda1
  21. Remove and reinsert hardware from VM
  22. cd into SD card
  23. File was no longer in card

XCalibur has proven to be particularly resilient to change. We have been looking into possible errors with file corruption, hardware failure, and our tests and reasons as to why no single explanation is adequate.

As we spent more time researching it, a couple frequently diagnosed problems with similar hard issues were:

  1. Sector Corruption. This was often the quoted reason for bad drives. However, bad sectors would easy have been found by a check disk or other commands as they would encounter it. Bad sectors are so well known that error codes for them are well documentated, but we did not run into them. was kill.

  2. Another suggested error was that it was write locked. The microSD card did not have write lock on it, and we used 3 different microSD to SD adapters, only one of which featured write lock, of which we tried both locked and not locked. When write locked, we were unable to copy files at all, and the ramdisk functionality

  3. Bad Reader / Adapter. As we stated of , we used three different types of adapters to account for this problem.

How we built it

Mistakes and regrets. Lots of them.

Challenges we ran into


Accomplishments that we're proud of

We haven't burnt it. Yet.

What we learned

When you need to use a microSD card, just don't.

What's next for XCalibur

Probably burning it.

Built With

  • agony
  • salt?
+ 11 more
Share this project: