The ps command is extremely useful when you want to get some quick information on active system processes (hence the name), especially followed by piping it into grep and kin for some filtering. One gotcha is of course that ps doesn’t run in the current shell process, but is forked off into its own process, so what if everything goes wrong and you absolutely need to run ps aux on a system that is completely and utterly out of fresh process IDs to hand out? In that scenario, you fortunately can write a shell script that does the same, but all within the same shell, as [Isabella Bosia] did, with a Bash shell script.

The how and why is mostly covered in the shell script itself, using detailed comments. Initially the hope was to just read out and parse the contents of /proc/<pid>/status, but that doesn’t have details like CPU%. The result is a bit more parsing to get the desired result, as well as a significant amount of cussing in the comments. Even if it’s not entirely practical, as the odds of ending up on a system with zero free PIDs are probably between zero and NaN, but as an ‘entertaining’ job interview question and example of all the fun things one can do with shell scripting it’s definitely highly recommended.

Hacking — at least the kind where you’re breaking into stuff — is very much a learn-by-doing skill. There’s simply no substitute for getting your hands dirty and just trying something. But that doesn’t mean you can’t learn something by watching, with this root password exploit on a cheap IP video camera being a good look at the basics.

By way of background on this project, [Matt Brown] had previously torn into a VStarcam CB73 security camera, a more or less generic IP camera that he picked up on the cheap, and identified a flash memory chip from which he extracted the firmware. His initial goal was to see if the camera was contacting sketchy servers, and while searching the strings for the expected unsavory items, he found hard-coded IP addresses plus confirmation that the camera was running some Linux variant.

With evidence of sloppy coding practices, [Matt] set off on a search for a hard-coded root password. The second video covers this effort, which started with finding UART pins and getting a console session. Luckily, the bootloader wasn’t locked, which allowed [Matt] to force the camera to boot into a shell session and find the root password hash. With no luck brute-forcing the hash, he turned to Ghidra to understand the structure of a suspicious program in the firmware called encoder. After a little bit of poking and some endian twiddling, he was able to identify the hard-coded root password for every camera made by this outfit, and likely others as well.

Granted, the camera manufacturer made this a lot easier than it should have been, but with a lot of IoT stuff similarly afflicted by security as an afterthought, the skills on display here are probably broadly applicable. Kudos to [Matt] for the effort and the clear, concise presentation that makes us want to dig into the junk bin and get hacking.

It would be better if humans didn’t toss cigarette butts on the ground in the first place, but change always takes longer than we think it should. In the meantime, researchers at the Italian Institute of Technology have used the problem as an opportunity to explore what seems to be a novel approach: attaching vacuum pickups to a robot’s feet, therefore removing the need for separate effectors.

VERO (Vacuum-cleaner Equipped RObot) is a robotic dog with a vacuum cleaner “backpack” and four hoses, one going down each leg. A vision system detects a cigarette butt, then ensures the robot plants a foot next to it, sucking it up. The research paper has more details, but the video embedded below gives an excellent overview.

While VERO needs to think carefully about route planning, using the legs as effectors is very efficient. Being a legged robot, VERO can navigate all kinds of real-world environments — including stairs — which is important because cigarette butts know no bounds.

Also, using the legs as effectors means there is no need for the robot to stop and wait while a separate device (like an arm with a vacuum pickup) picks up the trash. By simply planting a foot next to a detected cigarette butt, VERO combines locomotion with pickup.

It’s fascinating to see how the Mini Cheetah design has really become mainstream to the point that these robots are available off-the-shelf, and it’s even cooler to see them put to use. After all, robots tackling trash is a good way to leverage machines that can focus on specific jobs, even if they aren’t super fast at it.

There’s no doubt that you’ll instantly recognize clips from the video below, as they’ve been used over and over for more than 100 years to illustrate the development of the assembly line. But those brief clips never told the whole story about just how much effort Ford was forced to put into manufacturing just one component of their iconic Model T: the wheels.

An in-house production of Ford Motors, this film isn’t dated, at least not obviously. And with the production of Model T cars using wooden spoked artillery-style wheels stretching from 1908 to 1925, it’s not easy to guess when the film was made. But judging by the clothing styles of the many hundreds of men and boys working in the River Rouge wheel shop, we’d venture a guess at 1920 or so.

Production of the wooden wheels began with turning club-shaped spokes from wooden blanks — ash, at a guess — and drying them in a kiln for more than three weeks. While they’re cooking, a different line steam-bends hickory into two semicircular felloes that will form the wheel’s rim. The number of different steps needed to shape the fourteen pieces of wood needed for each wheel is astonishing. Aside from the initial shaping, the spokes need to be mitered on the hub end to fit snugly together and have a tenon machined on the rim end. The felloes undergo multiple steps of drilling, trimming, and chamfering before they’re ready to receive the spokes.

The first steel component is a tire, which rolls down out of a furnace that heats and expands it before the wooden wheel is pressed into it. More holes are drilled and more steel is added; plates to reinforce the hub, nuts and bolts to hold everything together, and brake drums for the rear wheels. The hubs also had bearing races built right into them, which were filled with steel balls right on the line. How these unsealed bearings were protected during later sanding and grinding operations, not to mention the final painting step, which required a bath in asphalt paint and spinning the wheel to fling off the excess, is a mystery.

Welded steel spoked wheels replaced their wooden counterparts in the last two model years for the T, even though other car manufacturers had already started using more easily mass-produced stamped steel disc wheels in the mid-1920s. Given the massive infrastructure that the world’s largest car manufacturer at the time devoted to spoked wheel production, it’s easy to see why. But Ford eventually saw the light and moved away from spoked wheels for most cars. We can’t help but wonder what became of the army of workers, but it probably wasn’t good. So turn the wheels of progress.

The late 1990s saw the widespread introduction of solid-state storage based around NAND Flash. Ranging from memory cards for portable devices to storage for desktops and laptops, the data storage future was prophesied to rid us of the shackles of magnetic storage that had held us down until then. As solid-state drives (SSDs) took off in the consumer market, there were those who confidently knew that before long everyone would be using SSDs and hard-disk drives (HDDs) would be relegated to the dust bin of history as the price per gigabyte and general performance of SSDs would just be too competitive.

Fast-forward a number of years, and we are now in a timeline where people are modifying SSDs to have less storage space, just so that their performance and lifespan are less terrible. The reason for this is that by now NAND Flash has hit a number of limits that prevent it from further scaling density-wise, mostly in terms of its feature size. Workarounds include stacking more layers on top of each other (3D NAND) and increasing the number of voltage levels – and thus bits – within an individual cell. Although this has boosted the storage capacity, the transition from single-level cell (SLC) to multi-level (MLC) and today’s TLC and QLC NAND Flash have come at severe penalties, mostly in the form of limited write cycles and much reduced transfer speeds.

So how did we get here, and is there life beyond QLC NAND Flash?

Floating Gates

At the core of NAND Flash lies the concept of floating gates, as first pioneered in the 1960s with the floating-gate MOSFET (FGMOS). As an FGMOS allows for the retention of a charge in the floating gate, it enabled the development of non-volatile semiconductor storage technologies like EPROM, EEPROM and flash memory. With EPROM each cell consists out of a single FET with the floating and control gates. By inducing hot carrier injection (HCI) with a programming voltage on the control gate, electrons are injected into the floating gate, which thus effectively turns the FET on. This allows then for the state of the transistor to be read out and interpreted as the stored bit value.

Naturally, just being able to program an EPROM once and then needing to erase the values by exposing the entire die to UV radiation (to induce ionization within the silicon oxide which discharges the FET) is a bit of a bother, even if it allowed the chip to be rewritten thousands of times. In order to make EPROMs in-circuit rewritable, EEPROMs change the basic FET-only structure with two additional transistors. Originally EEPROMs used the same HCI principle for erasing a cell, but later they would switch to using Fowler-Nordheim tunneling (FNT, the wave-mechanical form of field electron emission) for both erasing and writing a cell, which removes the damaging impact of hot carrier degradation (HCD). HCD and the application of FNT are both a major source of the physical damage that ultimately makes a cell ‘leaky’ and rendering it useless.

Combined with charge trap flash (CTF) that replaces the original polycrystalline silicon floating gate with a more durable and capable silicon nitride material, modern EEPROMs can support around a million read/write cycles before they wear out.

Flash memory is a further evolution of the EEPROM, with the main distinctions being a focus on speed and high storage density, as well as the use of HCI for writes in NOR Flash, due to the speed benefits this provides. The difference between NOR and NAND Flash comes from the way in which the cells are connected, with NOR Flash called that way because it resembles a NOR gate in its behavior:

To write a NOR Flash cell (set it to logical ‘0’), an elevated voltage is applied to the control gate, inducing HCI. To erase a cell (reset to logical ‘1’), a large voltage of opposite polarity is applied to the control gate and the source terminal, which draws electrons out of the floating gate due to FNT.

Reading a cell is then performed by pulling the target word line high. Since all of the storage FETs are connected to both ground and the bit line, this will pull the bit line low if the floating gate is active, creating a logical ‘1’ and vice versa. NOR Flash is set up to allow for bit-wise erasing and writing, although modern NOR Flash is moving to a model in which erasing is done in blocks, much like with NAND Flash:

The reason why NAND Flash is called this way is readily apparent from the way the cells are connected, with a number of cells connected in series (a string) between the bit line and ground. NAND Flash uses FNT for both writing and erasing cells, which due to its layout always has to be written (set to ‘0’) and read in pages (a collection of strings), while erasing is performed on a block level (a collection of pages).

Unlike NOR Flash and (E)EPROM, the reading out of a value is significantly more complicated than toggling a control gate and checking the level of the bit line. Instead the control gate on a target cell has to be activated, while putting a much higher (>6V) voltage on the control gate of unwanted cells in a string (which turns them on no matter what). Depending on the charge inside the floating gate, the bit line voltage will reach a certain level, which can then be interpreted as a certain bit value. This is also how NAND Flash can store multiple bits per cell, by relying on precise measurements of the charge level of the floating gate.

All of this means that while NOR Flash supports random (byte-level) access and erase and thus eXecute in Place (XiP, allows for running applications directly off ROM), NAND Flash is much faster with (block-wise) writing and erasing, which together with the higher densities possible has led to NAND Flash becoming the favorite for desktop and mobile data storage applications.

Scaling Pains

With the demand for an increasing number of bytes-per-square-millimeter for Flash storage ever present, manufacturers have done their utmost to shrink the transistors and other structures that make up a NAND Flash die down. This has led to issues such as reduced data retention due to electron leakage and increased wear due to thinner structures. The quick-and-easy way to bump up total storage size by storing more bits per cell has not only exacerbated these issues, but also introduced significant complexity.

The increased wear can be easily observed when looking at the endurance rating (program/erase (P/E) cycles per block) for NAND Flash, with SLC NAND Flash hitting up to 100,000 P/E cycles, MLC below 10,000, TLC around a thousand and QLC dropping down to hundreds of P/E cycles. Meanwhile the smaller feature sizes have made NAND Flash more susceptible to electron leakage from electron mobility, such from high environmental temperatures. Data retention also decreases with wear, making data loss increasingly more likely with high-density, multiple bits per cell NAND Flash.

Because of the complexity of QLC NAND Flash with four bits (and thus 16 voltage levels) per cell, the write and read speeds have plummeted compared to TLC and especially SLC. This is why QLC (and TLC) SSDs use a pseudo-SLC (pSLC) cache, which allocates part of the SSD’s Flash to be only used only with the much faster SLC access pattern. In the earlier referenced tutorial by Gabriel Ferraz this is painfully illustrated by writing beyond the size of the pSLC cache of the target SSD (a Crucial BX500):

Although the writes to the target SSD are initially nearly 500 MB/s, the moment the ~45 GB pSLC cache fills up, the write speeds are reduced to the write speeds of the underlying Micron 3D QLC NAND, which are around 50 MB/s. Effectively QLC NAND Flash is no faster than a mechanical HDD, and with worse data retention and endurance characteristics. Clearly this is the point where the prophesied solid state storage future comes crumbling down as even relatively cheap NAND Flash still hasn’t caught up to the price/performance of HDDs.

The modification performed by Gabriel Ferraz on the BX500 SSD involves reprogramming its Silicon Motion SM2259XT2 NAND Flash controller using the MPTools software, which is not provided to consumers but has been leaked onto the internet. While not as simple as toggling on a ‘use whole SSD as pSLC’ option, this is ultimately what it comes down to after flashing modified firmware to the drive.

With the BX500 SSD now running in pSLC mode, it knocks the storage capacity down from 500 GB to 120 GB, but the P/E rating goes up from a rated 900 cycles in QLC mode to 60,000 cycles in pSLC mode, or well over 3,000%. The write performance is a sustained 496 MB/s with none of the spikes seen in QLC mode, leading to about double the score in the PCMark 10 Full System Drive test.

With all of this in mind, it’s not easy to see a path forward for NAND Flash which will not make these existing issues even worse. Perhaps Intel and Micron will come out of left field before long with a new take on the 3D XPoint phase-change memory, or perhaps we’ll just keep muddling on for the foreseeable future with ever worse SSDs and seemingly immortal HDDs.

Clearly one should never believe prophets, especially not those for shiny futuristic technologies.

Featured image: “OCZ Agility 3 PCB” by [Ordercrazy]

This week Jonathan Bennett and Dan Lynch chat with Paweł Karaś about Amber, a modern scripting language that compiles into a Bash script. Want to write scripts with built-in error handling, or prefer strongly typed languages? Amber may be for you!

– https://github.com/Ph0enixKM/Amber
– https://amber-lang.com/
– https://docs.amber-lang.com/

Did you know you can watch the live recording of the show Right on our YouTube Channel? Have someone you’d like use to interview? Let us know, or contact the guest and have them contact us! Take a look at the schedule here.

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.