GetUSB isn’t becoming an artificial intelligence website. There are already plenty of those, and most days the world probably doesn’t need another article explaining that AI is going to change everything.

What has caught our attention is something a little more practical.

The deeper you get into how artificial intelligence actually works, the more the conversation starts sounding familiar. Memory bandwidth matters. Storage matters. NAND flash matters. DRAM matters. PCIe matters. Moving enormous amounts of data from one place to another matters. These are subjects we’ve been following for years, long before every product announcement needed the letters “AI” somewhere in the first paragraph.

Over the past several months we’ve written a number of articles looking at AI from that hardware perspective. Rather than chasing every new model or software announcement, we’ve been interested in what has to happen underneath all of it.

Looking back, eight articles in particular fit together surprisingly well.

Portable AI Accelerators vs Cloud AI: What Small Businesses Should Actually Pick?

One of the more interesting changes in AI is that running an AI workload doesn’t automatically mean sending everything to a massive data center. Smaller AI accelerators are making local inference practical for applications that don’t require the horsepower of a giant cloud-based model.

In our article about portable AI accelerators versus cloud AI, we looked at the tradeoffs between the two approaches. Cloud AI provides enormous computing resources, but local AI brings some interesting advantages of its own, including privacy, predictable operating costs, lower latency and the ability to continue working without an internet connection.

The important point isn’t that one approach wins. It is that AI processing is starting to spread out. Some jobs belong in the cloud. Some make considerably more sense sitting on a local computer or edge device.

Inside an AI Computer: Why Modern AI Systems Consume So Much Memory

A GPU gets most of the glory in an AI computer, but a powerful processor isn’t particularly useful if it spends its time waiting for data.

That led us to look inside an AI computer and explain why modern AI systems consume so much memory. AI models contain huge numbers of parameters, and those parameters have to be stored, loaded and moved through the system while calculations are taking place.

This is one of the recurring themes behind AI hardware. Computing power has increased dramatically, but feeding that computing power has become a problem of its own. The processor might be capable of doing the work, but only if the rest of the system can keep up.

NAND Isn’t Going Away, But AI Servers Now Depend on More Than Flash

Given our background, NAND flash was an obvious place for us to start digging.

AI isn’t making NAND obsolete. Quite the opposite. Models, training data, databases and generated information all need persistent storage, and flash remains extremely important. But AI servers now depend on much more than NAND flash because storage capacity is only one part of the problem.

An SSD can hold a tremendous amount of information, but the processor can’t perform calculations directly against everything sitting on an SSD at full speed. Data has to move through different levels of the memory hierarchy, each with its own balance of capacity, speed and cost.

AI has made that hierarchy much more visible.

What Is High Bandwidth Memory and Why Does AI Depend on It?

High Bandwidth Memory, usually shortened to HBM, went from being a fairly specialized memory technology to something regularly mentioned in discussions about AI hardware.

There’s a good reason.

In our explanation of what High Bandwidth Memory is and why AI depends on it, we looked at the problem HBM is designed to solve. Modern GPUs can perform an extraordinary number of calculations, but conventional memory architectures can become a bottleneck when those processors need enormous amounts of data delivered continuously.

HBM puts extremely fast memory very close to the processor and provides much greater memory bandwidth than conventional memory arrangements. It is expensive and complicated, but when you’re trying to keep an AI accelerator fed with data, bandwidth can be just as important as raw processing speed.

Think of it as owning a very fast factory. Making the machines inside the factory faster doesn’t accomplish much if the loading dock can’t deliver raw material quickly enough.

Why DRAM Alone Can’t Keep Up With AI Anymore

DRAM isn’t disappearing either. There is simply too much data.

We explored this in why DRAM alone can’t keep up with AI anymore, because the obvious solution to a memory shortage would seem to be installing more memory. Unfortunately, at AI scale, that gets expensive very quickly and still doesn’t solve every bandwidth and capacity problem.

This is where the different layers of AI storage start making more sense. HBM can provide extraordinary bandwidth close to the processor. DRAM provides larger pools of fast working memory. NAND flash provides much greater persistent capacity. Each technology does something the others can’t do economically.

AI isn’t replacing one type of memory with another. If anything, it is forcing computers to use more types of memory at the same time.

Why Hard Drives Are Still Critical for AI Infrastructure

This one might be my favorite contradiction in the whole AI hardware story.

We spend all this time talking about incredibly sophisticated GPUs, HBM, NVMe storage and advanced semiconductor manufacturing, and then sitting farther down the chain is technology based on spinning magnetic platters.

The hard drive is very much alive.

In why hard drives are still critical for AI infrastructure, we looked at the enormous amount of information AI companies need to retain. Training datasets, model checkpoints, backups, archives and other bulk data don’t all need to sit on expensive high-performance flash storage.

At some point economics takes over.

When you’re storing information by the petabyte, cost per terabyte becomes awfully important. Hard drives remain one of the most economical ways to provide enormous amounts of online storage. AI may represent some of the most advanced computing technology we’ve ever built, but apparently it still needs a really big closet to put everything in.

Why AI Is Moving Compute Closer to Storage

For decades, the normal computer architecture has been fairly straightforward: store the data somewhere, move it into memory, send it to the processor and do something with it.

That works beautifully until the amount of data being moved becomes enormous.

Our article about why AI is moving compute closer to storage looks at an interesting response to that problem. Instead of constantly moving huge datasets back and forth across a system, some architectures are beginning to move portions of the computation closer to where the data already lives.

There is a simple logic behind this. Moving data consumes time, bandwidth and power. If you can reduce the distance that data needs to travel, you can sometimes improve the efficiency of the entire system without simply throwing a faster processor at the problem.

This is another place where AI is changing the traditional definition of computer performance. The fastest component isn’t necessarily the answer. Sometimes the bigger improvement comes from moving less data.

KV Cache: The AI Memory Reservoir Keeping GPUs From Running Dry

KV cache sounds like one of those subjects you can safely ignore until you realize it helps explain why AI inference can consume such surprising amounts of memory.

When a language model generates a response, it doesn’t want to recalculate everything it already processed every time it produces the next token. The KV cache acts as a memory reservoir, retaining information from previous calculations so the model can reuse it.

That’s great for performance. It isn’t free.

As conversations become longer and more users interact with a model, KV cache requirements can grow dramatically. Once again, we arrive at the same AI hardware problem from a different direction: where do you put all this information, and how quickly can you get it back to the processor?

KV cache is a good example of why looking only at GPU specifications doesn’t tell you very much about the performance of an entire AI system.

Apparently We Keep Coming Back to Memory and Storage

When we wrote these articles, there wasn’t a plan to build an eight-part AI series. The subjects simply kept crossing paths with the technology we already follow.

That might actually be the interesting part.

Strip away the chatbots, generated images and futuristic predictions and artificial intelligence becomes a massive data-processing problem. Data needs to be stored. It needs to be moved. It needs to be placed into memory. It needs to reach processors fast enough to keep extremely expensive hardware busy.

Suddenly NAND, DRAM, HBM, hard drives, PCIe and storage architecture don’t sound like side topics. They’re part of the machinery making modern AI possible.

And lately we’ve started looking past even the hardware.

Our more recent article, The Biggest AI Bottleneck Isn’t Software – It’s Electricians, takes the story outside the server. Building AI infrastructure requires enormous amounts of electrical power, cooling and physical construction. At some point you can have the GPUs, memory and storage sitting on a loading dock and still have a problem: somebody has to build the infrastructure required to turn all of it on.

That is probably where our AI coverage will continue to go. Not chasing every new AI announcement, but following the places where AI bumps into storage, hardware and the physical realities of computing.

Because those are usually the parts of the story that interest us anyway.

This article originally appeared on GetUSB.info. Subscribe to GetUSB updates.

Storage capacity sounds simple until you start looking below the number printed on the side of a flash drive. A USB drive might be sold as 32GB, Windows reports something slightly different, a manufacturing tool asks for capacity in MB, and somewhere else the device reports an LBA count that looks like a completely unrelated number.

They are all related.

The connection between capacity, sector size and LBA is actually straightforward once you understand what each number represents. It is also useful information when working with USB flash drives at the manufacturing or duplication level, where specifying “32GB” sometimes isn’t precise enough.

What Is an LBA?

LBA stands for Logical Block Addressing. Rather than thinking about the physical location of data inside NAND flash memory, the computer sees the storage device as a long sequence of numbered logical blocks.

LBA 0 is the first logical block, LBA 1 is the next, then LBA 2, and so on until the device reaches its final available LBA.

The important part is that an LBA by itself does not tell us how much storage exists. We also need to know the size of each logical sector.

The basic relationship is:

Capacity in bytes = LBA count × logical sector size

For most USB flash drives, the logical sector size is 512 bytes.

That gives us a very useful shortcut.

There are 1,048,576 bytes in one MiB. If each logical sector contains 512 bytes:

1,048,576 ÷ 512 = 2,048

Therefore, with 512-byte logical sectors:

2,048 LBAs = 1 MiB

And that means:

LBA count ÷ 2,048 = capacity in MiB

Technically, MiB is the correct term here because we are using 1,048,576 bytes rather than the decimal 1,000,000 bytes used for MB. Some manufacturing utilities and MPTools still label this value as “MB,” so it is important to understand what the particular tool means by MB.

A Real LBA Example

Suppose a USB flash drive reports an LBA count of:

60,125,184

Assuming the device uses 512-byte logical sectors, we can calculate its addressable capacity:

60,125,184 × 512 = 30,784,094,208 bytes

Or we can use the shortcut:

60,125,184 ÷ 2,048 = 29,358 MiB

So the device has exactly 29,358 MiB of addressable storage, which is about 28.67 GiB, or 30.78 GB when expressed using decimal gigabytes.

This is also why simply calling something a “32GB flash drive” doesn’t tell you its exact geometry.

Two USB drives sold as 32GB products do not necessarily have exactly the same number of available LBAs. NAND configuration, controller settings, reserved capacity, bad-block management, over-provisioning and the way the device was configured during manufacturing can all affect the final addressable capacity presented to the host computer.

For most users, a small difference doesn’t matter.

For disk duplication, it can matter quite a bit.

Going the Other Direction

The calculation can also be reversed.

If we know the exact LBA count we want and the logical sector size is 512 bytes, we can convert that LBA count into a capacity and configure the flash drive accordingly using an MPTool, assuming the controller and MPTool provide that capability.

The formula is:

LBA count ÷ 2,048 = MiB

We can therefore calculate the required capacity from a customer’s desired LBA count and set the corresponding capacity in the MPTool.

If the MPTool uses 512-byte logical sectors and its capacity field represents binary MiB, setting that capacity should result in the desired LBA count.

This can be particularly useful when producing flash drives that need to match a known master device. It is also one of the reasons USB duplication hardware behaves differently than a simple file copy. A duplicator may be dealing with the actual structure of the storage device rather than simply copying visible files from one filesystem to another.

For example, imagine a customer creates a bootable master image on one batch of USB flash drives. Six months later another batch of nominally identical 32GB drives arrives, but the NAND has changed and the newly manufactured drives expose slightly fewer LBAs.

The label still says 32GB.

The operating system still recognizes them as approximately 32GB devices.

But from the perspective of a sector-by-sector disk image, they are not identical.

If the master image expects more LBAs than the destination device provides, the image may not fit. GPT-based media adds another complication because GPT maintains a backup header at the end of the disk. The location of that structure is tied to the end of the addressable device.

This is one reason bootable media and disk images deserve a little more attention than a normal collection of files. We have also covered why some ISO files work for USB duplication while others do not, and the common thread is that disk structure can matter just as much as the files sitting on the drive.

Controlling the manufactured capacity can therefore be much more useful than simply specifying a marketing capacity such as 32GB, 64GB or 128GB.

Sector Size Changes the Calculation

There is one major qualification to the shortcut above:

LBA count ÷ 2,048 = MiB only works for 512-byte logical sectors.

LBA is an address. It does not inherently mean 512 bytes.

If a storage device instead presents 4,096-byte logical sectors, every LBA represents eight times as much data.

For example, take our same LBA count:

60,125,184

With 512-byte logical sectors:

60,125,184 × 512 = 30,784,094,208 bytes

That is approximately 30.78 GB, or about 28.67 GiB.

But if those exact same 60,125,184 LBAs represented 4,096-byte logical sectors:

60,125,184 × 4,096 = 246,272,753,664 bytes

Now the device represents approximately 246.27 GB, or about 229.36 GiB.

Same LBA count. Completely different capacity.

This is why sector size has to be known before converting an LBA count into a capacity.

Why Would Anyone Use Something Other Than 512 Bytes?

At this point the obvious question is why storage devices don’t simply use 512-byte sectors all the time.

Historically, 512-byte sectors became the standard for hard drives and eventually became deeply embedded in operating systems, BIOS implementations, boot loaders, disk utilities and other software. Compatibility is one of the biggest reasons 512-byte logical sectors remain so common, including on USB flash drives.

But modern storage devices are considerably more complicated internally.

NAND flash memory does not physically operate in neat little 512-byte chunks. NAND uses much larger pages and erase blocks, while modern hard drives have also moved toward larger physical sectors. A controller has to translate what the computer thinks the storage device looks like into the much larger structures actually used by the underlying media.

This is where sector geometries such as 512e and 4Kn come into the picture.

A 512e device uses larger physical sectors, commonly 4,096 bytes, while continuing to present 512-byte logical sectors to the host. The computer gets the compatibility of traditional 512-byte sectors while the storage device can internally operate using a more efficient physical geometry.

A 4Kn device goes one step further and exposes 4,096-byte logical sectors directly to the host.

Larger sectors can reduce addressing overhead, improve the efficiency of error-correction information and better match the physical characteristics of modern storage media. On very large storage devices, larger logical sectors also mean fewer individual logical blocks are required to describe the same capacity.

There are tradeoffs, however.

Older operating systems, boot environments, embedded devices and specialized hardware may expect 512-byte logical sectors. Software that makes assumptions about sector size can also behave differently when presented with 4Kn media. That is one reason storage manufacturers and controller vendors sometimes offer sector geometry as a configurable option rather than forcing one configuration onto every application.

For a normal USB flash drive being used to move Word documents and photos between computers, none of this is particularly exciting. The user plugs in the drive, sees roughly the expected capacity and gets on with the day.

For duplicators, bootable USB media, embedded systems, industrial equipment and controlled manufacturing environments, however, the exact geometry can become part of the product specification.

“32GB” describes the neighborhood.

Sector size and LBA count tell you the actual address.

This article originally appeared on GetUSB.info. Subscribe to GetUSB updates.

Most people buying a USB flash drive have never heard of Yangtze Memory Technologies Corporation, better known as YMTC.

That may not remain true for the companies actually building those drives.

YMTC is a Chinese NAND flash manufacturer that has quietly moved from being a relatively small player in the global memory business to one that now deserves serious attention. According to Counterpoint Research, YMTC increased its share of global NAND revenue from 8% in the first quarter of 2025 to 13% in the first quarter of 2026.

For perspective, that puts YMTC right in the same neighborhood as Micron, SanDisk and Kioxia.

That is a pretty substantial change in twelve months.

We recently took a deeper look at the financial and semiconductor-industry side of this story over at GetFlashMemory.info in an article titled YMTC Has Become a Legitimate Global NAND Competitor. But there is another side to the story that is probably more interesting to GetUSB readers.

What happens if YMTC continues expanding NAND production?

Because sooner or later, a change in NAND manufacturing capacity works its way downstream into USB flash drives, memory cards, embedded storage and SSDs.

YMTC is no longer the little NAND company from China

The market-share progression is worth looking at by itself:

That progression is important because it doesn’t look like one unusually good quarter. It looks like sustained share capture.

Counterpoint says YMTC’s revenue grew approximately 445% year over year. The company also benefits from strong demand inside China, where electronics manufacturers have an obvious incentive to source more memory domestically whenever they can.

And now YMTC’s parent company is pursuing an IPO that could raise roughly $4.9 billion.

The important part isn’t simply that somebody in China is floating another semiconductor company on the stock market. The filing says the money is intended in part for production-line upgrades and research and development of advanced storage technology.

In plain English: YMTC wants to make more NAND, improve how efficiently it makes NAND and continue developing better NAND.

That gets our attention.

What does any of this have to do with USB flash drives?

A USB flash drive is a surprisingly simple product from a component standpoint. Strip away the plastic body, connector and PCB and the two parts doing most of the work are the USB controller and the NAND flash memory.

The controller determines much of the drive’s behavior. The NAND determines where your data actually lives.

And NAND is usually the expensive part.

When NAND prices increase sharply, flash drive manufacturers eventually have to absorb that cost, use cheaper grades of memory, reduce capacity, change suppliers or raise prices. When NAND becomes plentiful and prices fall, the opposite happens.

This is why somebody buying a promotional USB drive or a box of flash drives at retail may never know the names Samsung, Micron, Kioxia, SanDisk, SK hynix or YMTC, but what those companies are doing inside their fabs absolutely affects the product being purchased.

Right now AI is pulling NAND in the other direction

The interesting part of the current memory market is that YMTC’s expansion is happening while AI infrastructure is creating tremendous demand for NAND.

Counterpoint reported that the NAND market reached approximately $46 billion in revenue during the first quarter of 2026, up about 90% from the previous quarter and roughly 3.5 times the level from a year earlier. Enterprise SSDs already represented 43% of NAND revenue, and Counterpoint expects that percentage to exceed 60% by the end of 2026.

That’s a huge shift.

The important distinction is that your average person isn’t suddenly buying three times as many USB sticks.

AI data centers are consuming enormous amounts of high-performance storage, and memory manufacturers naturally prefer selling into markets where demand and margins are strongest.

There is another AI effect happening at the same time. High Bandwidth Memory, or HBM, has become one of the critical memory technologies behind AI accelerators. HBM is DRAM rather than NAND, but the extraordinary margins and manufacturing resources being directed toward AI memory change the economics of the broader memory industry.

Manufacturers have a very good reason to dedicate engineering talent, fab investment and wafer capacity toward expensive AI memory instead of fighting over the lowest-margin commodity products.

That creates pressure further down the food chain.

If enterprise SSD manufacturers are willing to pay more for NAND, somebody making a commodity USB flash drive may find himself standing farther back in line.

This is where YMTC becomes interesting

Memory markets have a habit of correcting themselves in fairly predictable ways.

Supply gets tight.

Prices go up.

Manufacturers make very good money.

Everybody decides they need more capacity.

Billions of dollars get spent building and upgrading fabs.

Then one morning the industry wakes up wondering where all this NAND came from.

Prices fall.

Anyone who has worked around flash memory long enough has seen some version of this movie before.

YMTC could become one of the companies helping write the next ending.

Its own IPO filing acknowledges the possibility of NAND oversupply in 2027.

That doesn’t mean NAND prices are guaranteed to collapse next year. AI storage demand could remain strong enough to absorb a tremendous amount of new production. Samsung, SK hynix, Micron, Kioxia and SanDisk will also adjust their own manufacturing plans as market conditions change.

But the ingredients are beginning to look familiar.

2026: strong AI demand and expensive NAND.
2027: additional capacity starts arriving.
2027-2028: supply and demand begin fighting over who was right.

Memory manufacturers are not always famous for getting that last part perfectly balanced.

There is another complication for USB manufacturers

Not all NAND is interchangeable simply because it has the word NAND printed somewhere on the specification sheet.

Flash drive manufacturers have to qualify memory with specific controllers, firmware versions, capacities and production requirements. Changes in NAND die geometry, page size, error characteristics or packaging can require controller firmware support and additional qualification.

So if YMTC continues taking global market share, we shouldn’t expect every USB flash drive manufacturer to suddenly swap its existing NAND for YMTC parts simply because the price looks attractive.

But increased production adds another source of supply to the market, and additional supply creates competition.

Competition has a funny way of affecting everybody’s price eventually.

There is also a sourcing question

YMTC remains subject to U.S. trade restrictions, and that creates an entirely separate issue for companies selling products into government, defense and other regulated markets.

The original GetFlashMemory.info analysis goes into the geopolitical side in more detail, including YMTC’s efforts to reduce dependence on U.S. semiconductor manufacturing technology.

For ordinary commercial USB products, however, the more immediate question may simply be whether YMTC becomes large enough that its production influences worldwide NAND pricing even when its chips aren’t actually inside the flash drive sitting on your desk.

I think the answer is increasingly yes.

The part worth watching isn’t really the IPO

The headline today is that YMTC is raising billions of dollars.

Six months or a year from now, the more important story could be what it does with the money.

Going from 8% to 13% NAND market share in a year is already significant. Doing it while operating under technology restrictions is even more interesting. Add several billion dollars for manufacturing improvements, capacity and R&D and YMTC stops looking like a regional Chinese NAND producer and starts looking like a company capable of influencing the global supply curve.

For GetUSB readers, that’s the connection.

You don’t have to care who ranks third in worldwide NAND revenue.

But if the company fighting for third place eventually helps push NAND from shortage back toward oversupply, the effect will eventually show up in the price and availability of USB flash drives.

And that is something worth watching.

This article originally appeared on GetUSB.info. Subscribe to GetUSB updates.

The boxes were sealed at the factory. That was the first thing everyone got wrong.

Supply Chain Infection

People trust seals.

They trust shrink-wrap, serial numbers, holograms, tamper tape, embossed foil, microscopic fibers, encrypted manifests, signed custody logs and those little stickers designed to tear themselves apart if somebody looks at them too aggressively.

Give people enough evidence that something hasn’t been touched and eventually they stop asking whether it was safe before anyone touched it.

That was the mistake.

Mine too, for about eleven minutes.

The shipment was waiting for me at Dock Nine beneath the eastern freight district, forty-eight matte-black cases stacked inside a climate-controlled transit crate with enough authentication wrapped around them to make a government auditor feel loved.

Factory origin confirmed.

Carrier handoff confirmed.

Seal integrity confirmed.

Device count confirmed.

Every timestamp matched.

Every identifier matched.

Every box looked exactly like every other box.

Which is usually when I start getting nervous.

My client was Helix Meridian, a financial infrastructure company with the kind of security budget that creates its own weather.

They handled settlement systems, institutional identity services and enough automated transaction traffic that shutting them down for ten minutes would probably become a chapter in somebody’s economics textbook.

They didn’t trust networks.

They didn’t trust clouds.

They barely trusted their own employees.

I liked them immediately.

The drives were destined for a secure deployment facility across the city. Forty-eight identical USB devices containing a signed internal recovery environment used to service isolated systems that were intentionally kept away from the corporate network.

No remote provisioning.

No download link.

No wireless update.

Physical media only.

That was supposed to make them safer.

My instructions were unusually specific.

DO NOT OPEN.

DO NOT CONNECT.

DO NOT SUBSTITUTE.

DELIVER FACTORY SEALED.

Nothing complicated about that.

Pick up the crate.

Verify the seals.

Carry it across the city.

Hand it to someone whose name I wasn’t supposed to know.

Get paid.

Simple jobs make me suspicious.

Complex jobs tell you where the danger is.

Simple jobs let it choose.

I signed the custody transfer at 21:16.

Rain started three minutes later.

Real rain, which had become expensive enough in the city that people photographed it.

I loaded the crate into the rear compartment of my transport and watched Dock Nine disappear behind concrete pillars slick with reflected advertising.

Nothing followed me.

Nothing unusual appeared on passive scan.

The route planner showed green across all six districts.

I ignored it and took a different route.

Courier habit.

Or paranoia.

The difference is mostly whether you were right.

Eleven minutes into the run, the crate reported a custody anomaly.

Not an alarm.

Not exactly.

Just a discrepancy.

The crate contained forty-eight individually registered devices, and the manifest contained forty-eight device identities.

But the passive inventory reader had seen forty-nine.

I looked at the display again.

Forty-eight expected.

Forty-nine observed.

Then forty-eight.

I pulled into the dark lower level of a parking structure where half the lights had been broken long enough to become architecture.

I killed the transport.

Ran the scan again.

Forty-eight.

Again.

Forty-eight.

I stared at the crate.

Machines glitch.

Readers miscount.

Wireless environments create noise.

People who survive in my business don’t treat every strange number like divine revelation.

They also don’t ignore one.

I checked the exterior seal.

Intact.

The custody strip had been applied at the factory and cryptographically registered before the shipment entered transit.

Its microscopic fracture pattern matched the image stored in the manifest.

Nobody had opened the crate.

I checked the individual packaging through the transparent inspection panel.

All forty-eight boxes carried serialized tamper seals.

All intact.

All genuine.

That should have made me feel better.

It didn’t.

I ran a deeper passive inventory scan.

This time the device count remained forty-eight, but one entry carried a controller-family identifier that didn’t belong.

Same product.

Same capacity.

Same exterior specification.

Different controller lineage.

Only for an instant.

Then it disappeared.

I sat there listening to rain strike concrete somewhere beyond the garage.

There are people who believe hardware is simple because they can hold it.

Software feels abstract.

Networks feel invisible.

Hardware feels solid.

Real.

Accountable.

A USB drive is plastic, metal, silicon and a connector you can see with your own eyes.

That’s comforting.

Comfort is dangerous.

Inside almost every modern USB device is a controller.

Not just memory.

A controller.

A small processor responsible for deciding how the device talks to the computer, how the flash memory is managed and, more importantly, what the host computer believes the device actually is.

People see a flash drive.

The computer sees whatever the controller tells it to see.

Storage.

Keyboard.

Network interface.

More than one thing at the same time.

The plastic shell doesn’t get a vote.

The firmware does.

I knew enough about BadUSB research to know the ugly part wasn’t corrupted files.

Files can be scanned.

Files can be hashed.

Files can be deleted.

Controller behavior lives lower.

Below the part most people think they’re checking.

If somebody had changed the firmware inside one of those devices, the drive could appear completely normal right up until the moment it decided not to be.

I called the client.

No answer.

That wasn’t unusual.

Helix Meridian routed courier communications through a broker precisely so couriers couldn’t call the people receiving sensitive shipments.

Compartmentalization.

Everybody knows less.

Everybody feels safer.

Until the person who knows less is the only person looking at the problem.

I sent a priority exception code.

The response arrived twelve seconds later.

SEALS VERIFIED.

MANIFEST VERIFIED.

CONTINUE DELIVERY.

I sent the anomaly report.

The reply came faster.

DO NOT OPEN SHIPMENT.

That was when I knew somebody was scared.

I looked at the crate again.

My contract was clear.

Factory sealed.

Delivered unopened.

Chain of custody intact.

A courier’s job is not to improve the cargo.

Not inspect it.

Not judge it.

Not decide whether the sender and receiver are making good choices.

We move things.

That’s the code.

Codes are wonderful until following one becomes the stupidest thing you can do.

I opened the crate.

The custody seal turned red the instant it separated.

Permanent break record.

Timestamp generated.

My credentials attached automatically.

Somewhere inside Helix Meridian, a security system had just written my name beside the words unauthorized access.

Good.

At least someone would know where to start looking for me.

The individual boxes were packed in six rows of eight.

Clean.

Perfect.

Almost ceremonial.

I removed the device associated with the anomalous controller reading.

Box thirty-one.

Factory seal intact.

Serial matched.

Lot number matched.

Print quality matched.

Even the tiny abrasion on the lower corner appeared in the factory packaging photograph.

Nobody had swapped the box.

Nobody had opened it.

I broke the seal.

Inside was a USB drive no different from the others.

Matte graphite body.

Laser-marked serial.

No removable cover.

Nothing theatrical.

Malicious hardware almost never looks malicious.

That’s the point.

I carried a small isolation kit for exactly the kind of situation nobody expects a courier to encounter.

Battery powered.

No radio.

No persistent credentials.

Nothing connected to anything I cared about.

A machine designed to be sacrificed.

I connected the drive.

It appeared normally.

Correct capacity.

Correct volume identity.

Signed recovery image present.

The files matched the manifest.

Every hash checked.

For half a second I felt stupid.

Then the host recorded another USB function.

It appeared briefly, identified itself, disappeared and left almost nothing behind.

Not storage.

Something else.

The kind of behavior a normal recovery drive had no reason to exhibit.

I disconnected it.

Connected it again.

This time nothing happened.

Normal storage device.

Perfectly boring.

Which was worse.

Bad code repeats mistakes.

Good malicious code knows when repetition becomes evidence.

I opened a second box.

Then a third.

Same controller family.

Same approved firmware revision according to the external identity fields.

Different internal behavior.

By box five, my hands were cold.

Not fear.

Recognition.

The shipment hadn’t been tampered with.

The shipment had been manufactured this way.

I called the broker again.

This time someone answered.

“You broke the seals.”

“Nice to hear your voice too.”

“Your contract is terminated.”

“Probably.”

“Do not deliver the shipment.”

I smiled.

Five minutes earlier I had been ordered to continue.

Funny what evidence does to confidence.

“I need the production records.”

“You’re a courier.”

“Tonight I’m ambitious.”

Silence.

Then:

“Where are you?”

“If you knew that, I’d be disappointed.”

Another silence.

Longer this time.

“The devices came directly from the approved manufacturer.”

“I know.”

“No third-party logistics.”

“I know.”

“No repackaging.”

“I know.”

“Then somebody intercepted them before pickup.”

“No.”

I looked at the broken boxes scattered across the floor.

“That’s the problem.”

People like interception because it gives an attack a location.

A loading dock.

A warehouse.

A truck.

A corrupt customs officer.

A compromised courier.

Find the point where the legitimate object became illegitimate and you can draw a circle around the problem.

Security people love circles.

This didn’t have one.

Every package record was valid from the moment the devices left final assembly.

So I went backward.

Controller lot.

Assembly timestamp.

Firmware release.

Production line.

Programming station.

Quality-control result.

The broker reluctantly opened records one layer at a time while reminding me every thirty seconds that I no longer technically worked for them.

I reminded him I still technically possessed forty-eight devices designed to enter their most sensitive systems.

That improved cooperation.

The controller lot had entered production eighteen days earlier.

Eight thousand units.

Approved supplier.

Approved silicon.

Approved firmware package.

Digital signature valid.

Manufacturing audit clean.

Automated test passed.

Every green box a security department could ask for.

Then I noticed the timestamps.

The firmware package had been signed six minutes before the production server recorded receiving it.

Normal.

But the hash registered by the manufacturing station had been recorded two seconds before the file existed on the server.

Impossible timestamps aren’t magic.

They’re usually somebody hiding a sequence.

I asked for the manufacturing station logs.

Unavailable.

I asked for the backup.

Unavailable.

I asked why.

The broker stopped answering.

That was answer enough.

I left the garage.

Not with the crate.

I moved the drives into three separate shielded containers and left the original transit package where it was.

Anyone tracking the crate could enjoy the parking structure.

I took one compromised device with me.

Twenty minutes later I was standing outside a building in the old manufacturing district that officially hadn’t produced electronics in nine years.

The sign above the entrance still carried the faded logo of a company that had been purchased, renamed, split, reorganized and eventually turned into four subsidiaries owned by a holding company registered somewhere warm and legally convenient.

Inside, the lights were on.

Manufacturing never really disappears.

It just gets renamed until nobody knows whose factory they’re standing in.

A technician met me behind reinforced glass.

Mid-fifties.

Gray uniform.

No visible security badge.

He looked at the drive in my hand and immediately stopped looking at me.

That was useful.

“Where did this come from?” I asked.

“I don’t know.”

“You haven’t looked at it yet.”

“I don’t know anything.”

“Better answer.”

He moved toward the door controls.

I put the drive against the glass.

“Eight thousand.”

His hand stopped.

There it was.

Not guilt.

Fear.

“How many shipped?” I asked.

“You need to leave.”

“How many?”

He stared past me toward the street.

“All of them.”

The room suddenly felt smaller.

“Who changed the firmware?”

“Nobody changed it.”

That answer again.

The one nobody wanted.

“Explain.”

He stepped closer to the glass.

“The package came through normal release.”

“Signed?”

“Yes.”

“Validated?”

“Yes.”

“Production approved?”

“Yes.”

“And malicious?”

He swallowed.

“Yes.”

There are breaches where an attacker breaks into a system.

Then there are breaches where the system itself authorizes the attacker.

The second kind lasts longer.

The firmware signing process hadn’t been bypassed.

The malicious firmware had gone through it.

Valid credentials.

Valid approval.

Valid build.

Valid signature.

The manufacturing equipment hadn’t been hacked into doing something unauthorized.

It had been instructed to do exactly what it was designed to do.

Program controllers.

Verify them.

Ship them.

The infection wasn’t outside the supply chain.

It was using the supply chain.

That distinction would keep people employed for years.

Assuming they survived the meeting.

“Who approved the firmware?” I asked.

“Three people.”

“Names.”

“Two are dead.”

I waited.

“The third never existed.”

I almost laughed.

Not because it was funny.

Because sometimes a problem becomes so perfectly bad that admiration slips through.

A synthetic employee.

Credential history.

Performance reviews.

Payroll records.

Access badges.

Training certificates.

Years of manufactured organizational history wrapped around a person who had never taken a breath.

The attackers hadn’t compromised an employee.

They had inserted one into the company.

By the time anyone looked backward, the approvals appeared routine because the approver had been routine for years.

The technician rubbed both hands over his face.

“We thought the problem was the station.”

“It isn’t.”

“The signing server?”

“No.”

“Then what?”

I looked through the glass at rows of dark manufacturing equipment behind him.

Machines waiting patiently for tomorrow’s orders.

Machines that didn’t know good firmware from bad firmware.

Only approved from unapproved.

“You trusted the process.”

He stared at me.

“You’re supposed to trust the process.”

“That’s what processes are for.”

I put the drive back into my pocket.

“That’s also what makes them useful to someone who gets inside early enough.”

My comm vibrated.

Helix Meridian.

Direct channel this time.

No broker.

When security stops protecting introductions, things have gone badly.

A man’s face appeared.

No name.

No title.

He didn’t need one.

“Ms. Vale.”

“That’s unfortunate.”

“What is?”

“You knowing my name.”

He ignored that.

“We need the shipment delivered immediately.”

“No.”

His expression barely changed.

“We understand you’ve identified a firmware anomaly.”

“You understand enough to stop calling it an anomaly.”

“Our engineers need physical access.”

“Send engineers.”

“The devices belong inside our containment facility.”

“That’s where they were going in the first place.”

He paused.

“Yes.”

Something in the way he said it bothered me.

Not the word.

The timing.

I looked at the compromised drive in my hand.

Then at the technician.

Then back at the security director.

“What systems were these intended for?”

“Restricted information.”

“Then enjoy your restricted malware.”

His jaw tightened.

“Recovery terminals.”

“Connected to production?”

“Isolated.”

“Connected during maintenance?”

Silence.

There it was.

Air-gapped.

Segmented.

Isolated.

Words security people use right up until somebody has to move data between them.

And what do they use when networks aren’t allowed?

Physical media.

The trusted object.

The thing inside the sealed box.

I felt the entire attack unfold backward in my head.

The attacker didn’t need to penetrate Helix Meridian’s perimeter.

Didn’t need stolen VPN credentials.

Didn’t need a zero-day against an internet-facing server.

Didn’t need someone dumb enough to click an attachment.

They just needed Helix Meridian to follow its own security policy.

Use approved hardware.

From an approved supplier.

Delivered through an approved chain.

To an isolated system.

The stronger the policy was enforced, the more reliably the infected devices reached the target.

Beautiful.

Terrible.

Almost elegant.

“How many previous shipments?” I asked.

The director didn’t answer.

I asked again.

“How many?”

“This conversation concerns the current shipment.”

“No. It doesn’t.”

He looked away from the camera.

Just for a fraction.

Somebody else was in the room.

Somebody he didn’t want reacting on screen.

That’s when I knew.

Forty-eight devices were not a problem large enough to scare him this badly.

Forty-eight devices were evidence.

I left the factory without saying goodbye.

The technician didn’t try to stop me.

Outside, the rain had weakened to a fine mist that made every streetlight look tired.

I retrieved the rest of the shipment and drove toward Helix Meridian.

Not because they ordered me to.

Because by then the boxes were the least dangerous thing in the city.

Their containment facility occupied six underground levels beneath a building with no corporate name on it.

Three checkpoints opened before I reached the loading bay.

At the fourth, nobody asked why the primary shipping seal was broken.

They already knew.

A security team waited behind a glass partition.

No weapons visible.

No need.

The kind of people standing there had entire departments for consequences.

The director from the call met me in person.

Taller than I expected.

Older too.

He looked at the open crate.

Then at me.

“You compromised chain of custody.”

“You’re welcome.”

He didn’t smile.

Nobody around him did either.

Tough room.

I placed one of the opened drives on the inspection table.

“Controller firmware is compromised. Packaging is genuine. Device serial is genuine. Factory seal was genuine. Production signature appears valid.”

“We know.”

I looked at him.

“Since when?”

He didn’t answer.

Behind the glass, technicians began moving the unopened boxes into isolated evidence containers.

Nobody looked surprised.

That bothered me more than anything else that night.

“These aren’t the first shipment.”

Not a question.

The director looked at the forty-eight boxes.

Then at me.

For the first time since I’d met him, the confidence left his face.

“No.”

One word.

Enough.

I looked through the glass at the secure facility beyond us.

Rows of terminals.

Service stations.

Recovery systems.

Machines deliberately disconnected from the outside world because somebody had decided physical isolation was safer.

And somewhere inside those rooms were USB ports.

Waiting.

I thought about every intact seal I’d checked at Dock Nine.

Every matching serial number.

Every green verification result.

Every little piece of evidence telling me the shipment had traveled exactly the path everyone expected.

That was the part I couldn’t stop thinking about.

Nobody had intercepted the cargo.

Nobody had opened the boxes.

Nobody had replaced the drives.

Nobody had broken the supply chain.

They had used it.

The director stepped beside me.

“We have teams checking prior deployments.”

“How far back?”

He hesitated.

“Fourteen months.”

I turned toward him.

“Same supplier?”

“Yes.”

“Same controller family?”

“We don’t know yet.”

“How many devices?”

He didn’t answer.

He didn’t have to.

People think cybersecurity is about keeping bad things out.

Firewalls.

Passwords.

Encryption.

Air gaps.

Access controls.

All useful.

All necessary.

But none of them help much when the thing you deliberately carry through the door is already working for someone else.

I walked toward the exit.

The director called after me.

“Vale.”

I stopped.

“You were right to open the shipment.”

I looked back at him.

“Put that in writing.”

For the first time all night, somebody almost smiled.

Outside, morning was beginning to dilute the city lights.

Delivery trucks moved through intersections.

Cargo drones lifted from rooftops.

Factories changed shifts.

Millions of components were moving through millions of hands toward people who would open clean boxes, inspect perfect seals and assume the hard part was over.

Maybe most of them were right.

That’s the uncomfortable thing about trust.

It has to work most of the time or nobody would use it.

The dangerous part is the exception.

One approved file.

One trusted credential.

One controller programmed before anybody thought to question what it had been told.

One sealed box.

I used to think tamper evidence told you whether something had been compromised.

Now I knew better.

A seal can tell you whether somebody opened the box.

It can’t tell you whether they needed to.

Everyone worries about what happens after the seal is broken.

Nobody asks who sealed the box.

More Mara Vale Stories

Mara Vale is a fictional cyberpunk courier used by GetUSB to explore real technology through stories about hardware, data integrity, AI systems and the uncomfortable places where physical security meets digital trust. If you enjoyed Supply Chain Infection, these earlier stories continue the series:

Mara Vale: Some Data Should Never Change
In a world where records can be quietly edited and history can be rewritten, Mara is hired to carry a rare write-protected USB device containing information that absolutely cannot be changed. The story explores hardware write protection, immutable data and what happens when truth itself becomes valuable because it refuses to move.

Mara Vale: The Model That Drifted
A predictive system trusted to anticipate everything begins producing subtly incompatible futures. Mara is asked to deliver a physical USB baseline containing a known-good state of the model, only to discover that correcting a system influenced by chaos may simply create another starting point.

Mara Vale: The Air-Gapped Echo
Mara enters a facility physically disconnected from every outside network, yet sensitive information is still escaping. The trail leads to electromagnetic leakage, machine emissions and a disturbing realization: disconnecting a computer from the network doesn’t necessarily disconnect it from physics.

Mara Vale is a fictional cyberpunk noir series created by GetUSB to explore real-world technology concepts through storytelling. Topics featured in the series are inspired by legitimate discussions surrounding USB security, BadUSB-style firmware attacks, hardware supply chains, controller firmware, write protection, air-gapped systems, electromagnetic leakage, AI infrastructure and data integrity. Story direction, technical themes and editorial oversight are developed by the GetUSB team, with AI-assisted support used for structure refinement and visual concept generation.

This article originally appeared on GetUSB.info. Subscribe to GetUSB updates.

Most people think they know what is going to happen when they plug a USB flash drive into a computer. A drive letter appears, some storage capacity is reported, and you can copy files onto it or pull files off. That’s what a flash drive does.

Except it doesn’t necessarily have to.

USB storage isn’t defined solely by the NAND flash sitting inside the plastic case. Between the USB connector and that NAND memory is a controller, and that controller plays a major role in determining how the device identifies itself and how the host computer interacts with it.

That’s where things get interesting, because a USB flash drive can contain perfectly ordinary NAND flash while presenting itself to the computer as something quite different.

One example is a USB flash drive configured at the hardware controller level to behave like a CD-ROM deviceA USB storage device that emulates an optical CD-ROM drive at the hardware controller level..

And no, the point isn’t simply making the files read-only.

The Computer Doesn’t Really Know What’s Inside the Stick

When you plug a USB device into a computer, the operating system doesn’t somehow look through the plastic enclosure and discover NAND flash. There is a conversation between the USB host and the device, and the device provides information about what it is and how the computer should communicate with it.

Think of it a little like somebody walking up to an airport immigration desk.

The person presents credentials that essentially say:

“I’m this type of device. Here’s how I identify myself. Here’s the type of functionality I provide. Here’s how you communicate with me.”

For a USB flash drive, the controller handles much of that conversation.

With an ordinary flash drive, the controller presents storage in a way the operating system recognizes as disk-like storage. Windows, Linux or macOS then loads the appropriate support and interacts with the device accordingly.

But the NAND flash itself doesn’t inherently have to be presented that way.

A controller designed and configured for CD-ROM emulation can take NAND flash and expose a logical storage device that behaves like optical media. From the host computer’s perspective, it can now be dealing with something that looks much more like a CD-ROM device than an ordinary writable USB flash drive.

The computer doesn’t particularly care that the physical storage underneath is actually NAND flash.

That’s the fascinating part.

The physical storage technology and the storage device presented to the computer don’t necessarily have to be the same thing.

This is also where the distinction between software tricks and true controller-level behavior becomes important. We’ve covered that difference in more detail in our explanation of USB CD-ROM emulation and firmware versus software methods. The short version is that changing how a controller presents storage is fundamentally different from simply changing a file attribute or mounting an ISO file through software.

Think of It Like a Building With a Different Sign on the Door

Imagine one physical building.

Put a sign outside saying BANK, and visitors walk through the door expecting tellers, accounts, deposits and withdrawals.

Change the sign to LIBRARY, and people approach the exact same building with an entirely different set of expectations. They don’t walk up to the counter trying to deposit money. They look for books and expect library rules.

The building hasn’t necessarily changed.

What changed is the identity being presented and the rules associated with that identity.

A USB controller can do something conceptually similar.

The underlying storage may still be NAND flash, but instead of presenting it as ordinary writable disk-like storage, the controller can present a logical device the operating system understands as CD-ROM-style media.

The operating system responds accordingly.

This is an important distinction because creating CD-ROM media on a USB flash drive isn’t the same thing as clicking a file in Windows and selecting “Read-only.”

It also isn’t necessarily the same thing as taking conventional USB storage and preventing writes.

Those approaches are trying to control what someone can do with a storage device.

CD-ROM emulationThe process by which a device mimics the behavior and identity of another device to the host system. goes a step further by changing what type of storage device is being presented to the host.

Why Would Anyone Want to Do This?

At first, configuring a modern USB flash drive to behave like technology from the CD-ROM era sounds backward.

But there are some surprisingly practical reasons for doing it.

Consider an industrial machine built 15 or 20 years ago.

Its service software may have been designed during a period when CD-ROM drives were everywhere. The application might expect updates, calibration files, installation packages, reference material or recovery utilities to arrive on optical media.

Eventually the physical CD drive dies.

Replacement optical drives become difficult to find. Maintaining burned discs becomes inconvenient. Maybe the original computer isn’t worth replacing, but the industrial equipment connected to it certainly is.

Replacing that computer might also create an entirely different problem. Industrial systems aren’t always environments where you can install a new PC, copy over a few programs and call it Tuesday afternoon.

There may be specialized drivers, proprietary hardware, validation requirements, certification issues or software that hasn’t been updated in years because it has been doing its job perfectly well.

The machine might be worth $100,000 while the computer controlling it is running an operating system most people haven’t seen since their kids were in elementary school.

That’s when compatibility becomes more valuable than novelty.

A USB device capable of presenting itself appropriately as optical-style media can potentially provide a bridge between those generations of technology.

Instead of rewriting the old application to understand modern storage, you make modern storage speak the language the old application already understands.

CD-ROM emulation is less about pretending to be a CD and more about speaking CD-ROM to a computer that expects to hear it.

Embedded Systems Can Be Even More Particular

Modern desktop operating systems are remarkably flexible.

Plug an ordinary USB flash drive into a current Windows computer and chances are pretty good Windows will figure out what it is and give you access to the files.

Embedded systems can be a very different animal.

Think about CNC machines, diagnostic equipment, laboratory instruments, manufacturing systems, kiosks, automotive service equipment, point-of-sale systems and specialized measurement equipment.

Many of these machines weren’t designed as general-purpose computers.

Their programmers knew exactly what the machine was supposed to do, exactly what hardware it was supposed to use and, in many cases, exactly how information was supposed to arrive.

There was little reason to write a wonderfully flexible storage routine capable of handling every device somebody might plug into the machine 20 years in the future.

If the original specification said software would arrive on CD-ROM, that’s what the programmer designed around.

The system might therefore make assumptions about device type, media behavior, filesystem structure, logical units or other characteristics of the storage device.

That is where emulation becomes much more than a novelty.

Rather than changing the host system, you change what the USB device tells the host it is.

For old or specialized equipment that is expensive, difficult or impossible to modify, that can be an extremely useful option.

A USB Flash Drive Is More Than a Connector and Some Memory

This also exposes one of the more interesting misconceptions about USB flash drives.

It’s easy to imagine a flash drive as a simple equation:

USB connector + NAND flash = USB flash drive

There is an important piece missing from that equation.

The controller.

The USB controller sits between the host computer and the NAND flash memory. Among its jobs is translating between what the host requests and what actually happens within the flash storage.

The controller also participates in defining how the device identifies itself, how storage is exposed, what characteristics are reported and how the device responds to commands from the host.

That means two USB devices containing similar NAND flash can behave very differently when plugged into the exact same computer.

One might present itself as conventional removable storage.

Another could be configured to present fixed-disk-style behavior.

Another implementation could expose a CD-ROM logical unit.

And some controller architectures can do something even more interesting: expose multiple logical storage devices through one physical USB connection.

One USB Plug Can Lead to Two Different Rooms

Imagine plugging one USB flash drive into a computer.

The computer discovers a CD-ROM-style area containing:

INSTALLER
MANUALS
DRIVERS
RECOVERY TOOLS

But the same physical USB device also provides conventional writable storage containing:

LOG FILES
REPORTS
CONFIGURATION FILES
USER DATA

There is still only one USB connector and one physical device sitting in your hand.

Logically, however, the computer has been presented with two different storage environments designed for two different jobs.

The CD-ROM portion can contain the manufacturer’s original published material, while the writable portion can remain available for information generated in the field.

A technician could carry one device containing the original diagnostic software and service documentation while using another area of that same device to store test results, equipment logs or customer-specific configuration files.

The distinction here is important.

This isn’t simply the same thing as dividing an ordinary USB flash drive into two partitions.

Partitions divide the capacity of a disk-like storage device. Both partitions are still part of the same basic type of storage environment.

A USB controller can instead expose multiple logical units, sometimes called LUNs, which allows one physical device to present distinctly different storage personalities to the host. We have a separate explanation of LUNs versus partitions and why one USB drive can appear as two disks for readers who want to go further down that rabbit hole.

CD-ROM emulation can therefore change the behavior and identity of the logical storage device being presented to the host, rather than merely dividing storage capacity.

It’s the difference between dividing one room with a wall and creating two rooms intended to perform completely different jobs.

There Is Also a Content Distribution Advantage

CD-ROMs had another useful property that most of us stopped thinking about because it was simply how optical media worked.

The publisher controlled the original contents.

Twenty years ago, you bought a piece of software on CD-ROM and installed it on your computer. Installing the software didn’t change the CD.

You couldn’t accidentally drag your vacation photos into the installation directory on the disc. An employee couldn’t casually delete half the installer. Someone couldn’t decide they needed another 300 MB of storage and erase the documentation.

The media was effectively a published object.

USB flash drives improved on optical discs in almost every practical way. They’re smaller, faster, easier to transport and have vastly greater storage capacity.

But ordinary writable USB storage also blurred the distinction between the person publishing the content and the person consuming it.

For documentation, software distribution, service tools, training material, recovery utilities and other controlled content, sometimes that distinction is useful.

A CD-ROM-style logical area can provide a place for content intended to remain in its original distributed state, while other storage on the device can be used for information that legitimately needs to change.

This Isn’t the Same Thing as Security

There is one important boundary to keep clear.

CD-ROM emulation shouldn’t automatically be described as a complete security system.

Making storage behave like optical media doesn’t replace cryptographic signaturesDigital codes that verify the authenticity and integrity of data using cryptographic algorithms., secure boot mechanisms, encryption, authentication or other technologies designed to establish whether software or data can be trusted.

Those solve different problems.

The value of CD-ROM emulation is primarily in device behavior, compatibility, controlled distribution and preservation of published content.

In some applications, preventing normal modification is extremely useful. But “difficult for the user to modify” and “cryptographically proven to be authentic” aren’t the same thing.

Understanding that difference is important, especially when these devices are used in industrial or specialized environments.

Sometimes You Don’t Want a Flash Drive to Behave Like a Flash Drive

The disappearance of physical CD-ROM drives doesn’t necessarily mean every useful characteristic of optical storage disappeared with them.

Sometimes an older computer expects optical media.

Sometimes specialized software was designed around it.

Sometimes an embedded system is far easier to accommodate than modify.

Sometimes a manufacturer wants original documentation or software separated from storage the user is expected to change.

And sometimes the most practical solution isn’t convincing an old system to understand something new.

It’s making something new behave like what the old system already understands.

That’s one of the interesting things about USB technology that gets hidden behind the simplicity of plugging in a flash drive.

What you hold in your hand may contain NAND flash memory, but NAND alone doesn’t determine what the computer sees.

The controller has a say in that conversation.

And with the right controller and configuration, a USB flash drive doesn’t necessarily have to behave like a flash drive.

This article originally appeared on GetUSB.info. Subscribe to GetUSB updates.

Every once in a while a project comes along that reminds us why the maker community continues to push technology in directions manufacturers never anticipated. This week we came across an excellent Raspberry Pi Zero project by Nick Lewis at How-To Geek that transforms a tiny Raspberry Pi Zero 2 W into both a wireless Network Attached Storage device and a traditional USB Mass Storage drive.

What makes the project so interesting is not that it replaces the USB flash drive. It does not. Instead, it demonstrates how USB and networking can work together to create something surprisingly capable in a package that fits into your pocket.

At its core, the project uses a Raspberry Pi Zero 2 W, a high-capacity microSD card and Raspberry Pi OS Lite. When connected directly to a computer through USB, the Pi presents itself as a standard USB storage device using USB Mass Storage Gadget mode. Disconnect it from the computer and power it from a USB battery or wall adapter, and it automatically becomes a wireless access point allowing phones, tablets and computers to browse and transfer files over Wi-Fi.

That flexibility is what caught our attention. A normal USB flash drive excels at moving files quickly between two devices. This Raspberry Pi project takes a different approach by allowing multiple devices to access the same storage without physically passing a drive around the room.

More Than Just a USB Drive

The project is especially useful for hobbyists, photographers, field technicians or anyone who frequently shares files among different operating systems. Windows, macOS, Linux, Android and even iPhones can all connect wirelessly using supported network tools or a browser-based file manager.

Of course there are tradeoffs. A Raspberry Pi Zero 2 W uses USB 2.0 hardware, so transfer speeds are nowhere near a modern USB 3.2 flash drive or portable SSD. Likewise, the onboard 2.4GHz Wi-Fi was not designed for massive file transfers. If your goal is to copy 100GB as quickly as possible, a quality USB flash drive remains the better choice.

However, speed is not the point. Convenience is.

The ability to walk into a meeting, power up a pocket-sized server and have several people access the same files at the same time is something a conventional flash drive was never designed to do.

How the Pocket NAS Works

The clever part of Nick Lewis’s project is the way the Raspberry Pi changes personalities depending on how it is powered and connected. When a computer is detected through the data-capable USB port, the Pi releases control of the storage image and presents that image to the host computer as a removable USB drive. From the computer’s point of view, it behaves much like any other mass-storage device.

When the computer is disconnected, the Raspberry Pi takes control of the storage again, mounts it locally and makes the files available over its own Wi-Fi network. The result is one storage area that can be reached in two very different ways without the user manually changing settings each time.

This automatic handoff is important because two operating systems should not write to the same filesystem at the same time. Doing so would be a good way to corrupt the storage. The switching script makes sure the Raspberry Pi unmounts the storage before giving control to the USB hostA device that controls USB communication and manages connected USB devices., then safely reclaims it after the host is gone.

The hardware itself is fairly ordinary. The software is what makes the arrangement practical.

A NAS That Fits in Your Pocket

Network Attached StorageA dedicated storage device connected to a network that allows multiple users and devices to access and share data. normally brings to mind a box sitting next to a router with two or four hard drives inside. That is still the right kind of system for long-term backups, large media libraries and business data. A Raspberry Pi Zero with one microSD card is not competing with a full-size NAS appliance, and pretending otherwise would be silly.

What it offers instead is portability. The Pi can create its own wireless network, so it does not need access to a home or office router. Give it power and nearby devices can connect directly. That could be useful while traveling, at a job site, in a classroom, during a meeting or anywhere several people need access to the same collection of files.

It could also become a useful family photo transfer device. Several people in the same household could connect their phones and upload pictures to one shared location without searching for the correct cable or adapter. The limitation is that automatic photo backup, especially from an iPhone, depends heavily on the software used to manage the process. The hardware can provide the storage and network connection, but the experience still needs to be simple enough that people will actually use it.

Why This Is Better Than Building a NAS From Old Flash Drives

We previously looked at whether it makes sense to build a NAS out of old USB sticks. The problem with that approach is not that USB storage is bad. The problem is that combining a pile of unrelated flash drives does not automatically create reliable network storage.

Different controllers, different NAND types, uneven write performance and varying endurance can make a collection of old drives difficult to manage. You also need a host controller, power management, network connectivity and software that knows how to organize everything.

The Raspberry Pi project takes the more sensible route. It uses the Pi as the controller and network server, while a single microSD card provides the storage. It is still a DIY project with limitations, but the design is cleaner and easier to understand.

Security Should Not Be an Afterthought

Any device creating its own Wi-Fi access point should be configured with a strong password. The same applies to SMB shares or any browser-based file manager installed on the Pi. An open wireless share might be convenient in your living room, but it becomes a different story in a hotel, airport or crowded conference center.

It is also worth remembering that a single microSD card is not a complete backup strategy. If the card fails, is lost or becomes corrupted, the files may be gone. Important data should still exist in at least one other location.

This device is better viewed as portable storage, a transfer tool or one layer of a backup routine. It should not become the only home for irreplaceable family photos or work files.

Why We Like Projects Like This

At GetUSB.info we have covered USB technology since 2006. One reason USB has remained successful is because it continues to adapt. USB started as a practical way to connect peripherals, then became the standard for flash drives, external SSDs, charging, video output and countless embedded devices.

Projects like this continue that tradition. They do not replace USB. They build on it.

The Raspberry Pi Zero uses USB as both a power source and a data connection, while Wi-Fi extends access to devices that may not have the correct physical connector. Each technology handles the job it does best. USB provides the direct connection and mass-storage compatibility, while wireless networking allows several devices to reach the files without taking turns with a cable.

That combination is the real strength of the project. It is not trying to prove that one connection method is better than another. It simply uses both.

Could This Become a Commercial Product?

Portable wireless storage products have existed before. SanDisk offered wireless flash storage products years ago, and several companies have experimented with battery-powered drives and travel routers containing USB ports. Some worked reasonably well, while others disappeared after their companion applications stopped receiving attention.

That history tells us something important. Building the hardware is only part of the challenge. A commercial version would need reliable iPhone and Android applications, automatic photo backup, duplicate detection, simple user accounts, encryption and an interface that does not require the customer to understand SMB, mount points or Linux services.

The Raspberry Pi community is comfortable with setup files and command-line scripts. The average household is not. For a commercial product to succeed, the technical work has to disappear behind one large button that says something like “Back Up Photos.”

The idea is still compelling. A small device with local storage, Wi-Fi, USB connectivity and no required monthly cloud subscription could appeal to families, photographers and travelers. Whether it becomes a successful product would depend much more on the software experience than the electronics inside the case.

Before You Go

One thing this project quietly demonstrates is that modern hardware has become remarkably inexpensive and capable. A tiny single-board computer, a microSD card, Wi-Fi and USB connectivity can now be combined into something that would have required a much larger and more expensive system only a decade ago.

Yet the most valuable part of this project is not the hardware. It is the software.

The intelligence that automatically switches between USB Mass Storage mode and a wireless file server is what transforms a handful of common components into a genuinely useful device. The Pi, cable and memory card provide the raw capability, but the switching logic is what makes the system feel like one product instead of a box of unrelated parts.

As hardware continues to become more affordable, it will increasingly be software, not silicon, that determines which ideas become everyday products and which remain interesting weekend projects. Great hardware may get people’s attention, but good software is what keeps them using it.

This article originally appeared on GetUSB.info. Subscribe to GetUSB updates.