> Does it revert the firmware to whatever it was shipped with (bugs and all)? Some vendors do, but most vendors do not.

I think that's the only reasonable thing to do. Have the original firmware either as an actual rom, or only writable with an enable jumper flipped; use a power on key sequence to boot from the original firmware, copy to normal firmware and reboot into normal firmware (which is now the original firmware). Run through that process during manufacturing to confirm it works.

Regularly test that all released firmware images, especially those in the original firmware slot can successfully upgrade (or at least not crash). Preferably include current firmware version in all requests so you can give workaround responses as needed when you figure out you broke something -- in the hostname is ideal, as you can use that to work around version specific certificate issues.

The reason a Blu-Ray player (or a video game console) might not let you go back to original firmware is to prevent reverting to earlier firmwares that allowed copied media, etc. For those, you probably want to have a 'safe' firmware slot (or two, ideally) that drives the factory reset process, and only reflash those slots on some updates (to reduce testing needs)

>I think that's the only reasonable thing to do.

But that'd also mean you need double the flash capacity, which drives up the BOM cost.

Not necessarily. I worked on the team the managed the OS for an embedded hardware project (radio equipment) and our disk was partitioned four ways:

1. current operating system

2. previous operating system (and next, on upgrade)

3. data partition, shared across both current and previous OS

4. factory reset partition

That means if we needed to do a factory reset we could just load the firmware archive from the fourth partition onto the second partition and execute a normal upgrade, albeit to an older version. Since upgrade packages were small, maybe 500MB?, we could easily cut a little space from the rest of the partitions to make it fit without having to increase the flash capacity.

Yeah, but this is 2020... the blu-ray drive needs a copy of React with node_modules sized at 26Gb :P

That might be feasible for high margin products, but definitely not for consumer products. Case in point: enthusiast motherboards (as in, not the ones used for prebuilts) cheaping out and using 16MB ROM rather than 32MB, forcing them to remove features to accomdiate extra code needed to support new CPUs

Companies seem to care more about preventing users from rolling back firmware than they do about releasing firmware that works. I've had more than one device wrecked because it happened to be out of warranty when I installed a firmware update that ruined something important.

As the owner of the device, I couldn’t care less if reverting to earlier firmware has been exploited. Are device manufacturers making more money from customers or studios?

Device manufactures can't make money from customers if studios blacklist their players.

Isn’t all this crazy when pirates can just download the damn movie with no problem. They are just punishing the paying customer. I have a plex server and have zero issues.

Copyright theater.

In this case it wasn't even a firmware update that bricked the device. Just some meta data that told the device how to behave. So a factory reset should still have deleted that stupid XML file from the flash storage, which would totally have fixed the issue. Even with all the paranoia they could have had about reverting to an old firmware version and breaking copy protection through exploits. Just wipe the freaking flash storage and keep the current firmware.

The one issue I can see with this if the original firmware has an outdated TLS trust store, reverting to the original firmware might make it impossible to update it via normal means. Whether or not this is good or bad is an exercise left up to the reader.

Samsung runs their own CA with a long expiration, so at least they aren't affected by trust store issues. Amazon had an issue with this on Kindles though, if you didn't online update your Kindle in time, you have to do an offline update -- i think that one might have been sha-2 signatueres rather than a CA expiration though --- not sure.

> Does it revert the firmware to whatever it was shipped with (bugs and all)? Some vendors do, but most vendors do not.

I think if it doesn't revert to the firmware it had when shipped by the factory, it shouldn't be considered a factory reset.

Just a guess, but I would assume the term factory reset referred to clearing user settings before devices commonly had firmware update capabilities. So the legacy name should not be used to imply how the function should work in relation to firmware downgrade.

It should restore all writable storage to factory configuration. It shouldn't matter a whit whether that storage has code or config on it.

Who pays for more EEPROM/Flash capacity to save factory firmware?

I tried a factory reset with my Samsung TV after a firmware update injected advertising into the UI. Unfortunately it remained on the current firmware version and just cleared the settings.

>Samsung TV after a firmware update injected advertising into the UI.

Wouldn't Samsung and the rest have stopped this if people just returned the TV?

Probably. Connivingly they waited for 9 months after I bought the TV before releasing the firmware update.

I wrote a guide years ago on blocking them via DNS which loads of people found useful. These days a PiHole is probably a better option.

https://gist.github.com/peteryates/b44b70d19ccd52f62d66cdd4b...

Did you buy it with a credit card? Check to see if your credit card has additional return/warranty periods.

Or, if you have the time and opportunity, sue the manufacturer in small claims court.

Better yet, tell your friends and family about how the ads start after the return period closed, and encourage everyone not buy that garbage in the first place.

It really depends how these things are setup.

Factory resetes that reset the EEPROM basically usually means that the hardcoded values form the ROM/Firmware will be used on the next boot.

However you usually have another tier today which is flash storage which isn’t a mechanism that can be easily reset with a “factory reset” because it involves a file system.

If the bad config files are on the flash you need a factory reset mechanism that basically tells the main firmware or boot loader to recreate the file system on the next boot.

That's how factory reset works on Android — it simply erases the entire /data partition, which is the only one normally mounted read-write. Recovery might subsequently initialize an empty file system there, but bootloader certainly does not. (you're usually able to do a wipe from both)

The OS itself then initializes it all from scratch on the first boot.

If you could factory-reset to the original firmware on internal ROM (with buggy xml parser), wouldn’t you still get stuck in the boot loop?

They way I understood it, the write up in the article says that the XML is downloaded and parsed during boot.

Edit: I guess if you disabled network access you could boot. Derp

If they included a factory reset, a good one besides being accessible early in the boot process, would erase and restore the filesystem on the flash chip to how it originally shipped. So that policy file will either be erased or a safe default.

Then you just keep it offline until Samsung fixes the file on their server so you don't have to reset it again. They fixed it a few days later so it is safe now, so even old firmware should be safe to go online.

That article explains why that solution it isn't possible: 'there seems to be no way to recover the devices from the boot loop using normal means – such as a USB stick, CD or network – because the crash happens too early in the boot sequence.'

It would have been possible if it was done this way in the first place.

Thus, the discussion on how factory resets could/should work in consumer electronics...

I like the way you can erase and recover a Mac to a fresh install of MacOS, without needing a USB key or another working Mac. As long as you have an unmetered internet connection, you can recover to the same version of MacOS that shipped with the device.

So long as Apple chooses to make that version available for download.

That's a pretty horrid way. It used to be a time where you could just run a recovery partition to reinstall your operating system outside of re partitioning your hard drive.

Every maOS install includes a recovery partition which works as you describe. However, if your hard drive is screwed up thoroughly enough, the recovery partition may not be accessible. In that case, you can still access Internet Recovery, which is located on some sort of ROM and allows you to redownload a working recovery image from Apple's servers.

I've seen non-Mac laptops ship with a recovery partition but:

1. The recovery partition takes up some space, and

2. You (or malware) can mess up the recovery partition, and

3. The recovery partition doesn't exist if just upgraded the storage (e.g. replace the HDD with an SSD).

Macbooks have other failings (e.g. increasingly hard to upgrade/replace hardware yourself) but the operating system recovery works better than anything I've seen for Windows or Linux. Chromebooks have a factory reset key sequence, but that requires a working ChromeOS on the drive.

The recovery partition on non-Mac laptops typically comes with preinstalled crapware too, making it worse than getting a vanilla Windows DVD.

Modern Dell systems support Internet recovery at least in the business class line. Just tested it a few weeks ago on a Dell all-in-one.

Downside of this is that you could end up in a different broken state: ex. What if the original firmware now has too old of a CA bundle?

This could be avoided by using your own PKI for updates (and bundle your own root), but I assume most devices out there are using Web PKI for updates.

Better write a firmware to avoid this problem i have written in the past firmware for devices that don't affect the user experience including CA's, server domain or ip and other parts that don't require a full firmware update, better to "waste" development time thinking of all future problems that are out or your hand than bother the final users IMO. As a developer you should think every problem you could face or you aren't using the best practices of software development.