I once met a person that never drank water, only soft drinks. It’s not the unhealthiness of this that disturbed me, but the fact they did it without the requisite paperwork.

Unlike those disorganised people I have a formal waiver. I primarily drink steam and crushed glaciers.

  • 0 Posts
  • 66 Comments
Joined 1 year ago
cake
Cake day: June 14th, 2023

help-circle



  • There have been constant news articles coming out over the past few years claiming the next big thing in supercapacitor and battery technologies. Very few actually turn out to work practically.

    The most exciting things to happen in the last few years (from an average citizen’s perspective) are the wider availability of sodium ion batteries (I believe some power tools ship with them now?), the continued testing of liquid flow batteries (endless trials starting with the claim that they might be more economic) and the reduction in costs of lithium-ion solid state batteries (probably due to the economics of electric car demand).

    FWIW the distinction between capacitors and batteries gets blurred in the supercapacitor realm. Many of the items sold or researched are blends of chemical (“battery”) and electrostatic (“capacitor”) energy storage. The headline of this particular pushes the misconception that these concepts can’t mix.

    My university login no longer works so I can’t get a copy of the paper itself :( But from the abstract it looks first stage, far from getting excited about:

    This precise control over relaxation time holds promise for a wide array of applications and has the potential to accelerate the development of highly efficient energy storage systems.

    “holds promise” and “has the potential” are not miscible with “May Be the Beginning of the End for Batteries”.


  • A good search term is “SSD over-provisioning”

    The file size discrepancy is usually due to 1000 vs 1024

    No, that’s something else entirely. It doesn’t matter what measurement system you use, the drive juggles more sectors than your OS can see.

    but filling the drive with random data until its full should wipe the drive.

    Only if you assume people can’t access the reserved/unallocated/over-provisioned sectors. If you are only worried about small thieves then this might not be an issue. If you’re handling sensitive data (like medical records for other people or anything with sensitive passwords) then it’s completely inadequate to leave any form of data anywhere on the disk.


  • I assume you’re joking, but if not: the 4MB of flash you see is not mapped 1:1 with 4MB of actual flash on the SD card. Instead there might be something like 5MB, but your OS only sees 4MB of that.

    The extra unallocated space is used as spare sectors (sectors degrade and must be swapped out) or even just randomly if it somehow increases IO performance (depending on the firmware).

    Erasing the 4MB visible to your OS will not erase everything, there still may be whole files or fragments of your files sitting in the extra space. Drive-vendor specific commands can reliably access this space (if they exist and are available to you, which they mostly are not). Some secure erase commands may wipe the unallocated space but that’s vendor specific, not documented and I don’t think even supported over the SD interface (although I might be wrong on this last point).

    Encryption and physical destruction are your best bets.








  • SFF = Small Form Factor. It’s smaller than traditional ATX computers but can still take the same RAM, processors and disks. Motherboards and power supplies tend to be nonstandard however. Idle power consumptions are usually very good.

    USFF = Ultra Small Form Factor. Typically a laptop chipset + CPU in a small box with an external power supply. Somewhat comparable with SBCs like Raspberry Pis. Very good idle power consumption, but less powerful than SFF (and/or louder due to smaller cooler) and often don’t have space for standard disks.

    SBC = Single Board Computer.


  • I wouldn’t attack via USB, that path has already been too well thought out. I’d go for an interface with some sort of way to get DMA, such as:

    • PCIE slots including M.2 and external thunderbolt. Some systems might support hotplug and there will surely be some autoloading device drivers that can be abused for DMA (such as a PCIE firewire card?)
    • Laptop docking connectors (I can’t find a public pinout for the one on my Thinkpad, but I assume it’ll have something vulnerable/trusted like PCIE)
    • Firewire (if you’re lucky, way too old to be found now)
    • If you have enough funding: possibly even ones no-one has thought about like displayport + GPU + driver stack. I believe there have been some ethernet interface vulnerabilities previously (or were those just crash/DOS bugs?)

  • I recommend using a different set of flags so you can avoid the buffering problem @thenumbersmason@yiffit.net mentions.

    This next example prevents all of your ram getting uselessly filled up during the wipe (which causes other programs to run slower whenever they need more mem, I notice my web browser lags as a result), allows the progress to actually be accurate (disk write speed instead of RAM write speed) and prevents the horrible hang at the end.

    dd if=/dev/urandom of=/dev/somedisk status=progress oflag=sync bs=128M

    “oflag” means output flag (to do with of=/dev/somedisk). “sync” means sync after every block. I’ve chosen 128M blocks as an arbitrary number, below a certain amount it gets slower (and potentially causes more write cycles on the individual flash cells) but 128MB should be massively more than that and perfectly safe. Bigger numbers will hog more ram to no advantage (and may return the problems we’re trying to avoid).

    If it’s an SSD then I issue TRIM commands after this (“blkdiscard” command), this makes the drive look like zeroes without actually having to write the whole drive again with another dd command.