Hi forum,

imagine the following: you set up a system and as everything is in place, you set a HDD's parameter to "IMMUTABLE". All the changes written afterwards are moved to an unused (and specially marked) area on the disk.

Upon next reboot all the differences are gone and your previously installed system is back as you left it when setting the IMMUTABLE parameter.

Of course, VirtualBox is doing exactly that with the images. But I'm not aware of any HW-related function in standard or SSD drives.

Do you have an idea if such a feature is available?

For the sake of completeliness: There are SW tools available, but none of them REALLY protects your "image" in case of attacks...

Thanks!
BR,
arcanoid.

Many enterprise level storage systems can do hardware snapshots
which is broadly the same idea
(various ways of implimenting it depending on where you put the later writes,
either on a seperate drive or area (as per your idea) or more usually they let the recent writes go to the drive (so that it is always up to date) and move the previous contents to a snapshot diff area)

At the other end of the spectrum, some embedded systems (with RO storage) have a storage stack driver that redirects any write to seperate temporary RW storage


For standard drives you theorectically modify the drive firmware to do your idea
Not aware of any vendors providing that sort of feature
but if they had a big OEM opportunity they might

Hi xsoliman,

thanks for answering! Do you maybe have one or two names as a reference? I saw some references on wiki, but they deal with prices around 1K€ and up. So I think I'll have to find a solution which is in the region of a fraction of that price.



Currently I run a SuSE Linux box with a write-protected SD-Card in a SD-to-IDE Adapter mounted as RO. But I had to change around 100 settings to get it up and running.
That system is not based on a changed HW, but on changes in settings and some skripts. The suggested method of redirecting WR and keeping a sector lookup table requires either a good ATA stack in an e.g. ColdFire (Freescale) or dedicated IDE HW.
An other option could be to redirect the R/W commands on that SD-Interface via a CPLD (serial speed?) to two cards, which could be easier to handle and in case the storage media crashes, the system could be "repaired" by just changing the defective card.
Of course, there is still the HDD option "commit=60" or "commit=200" to be used then.

Do you / anybody have a better idea? E.g. are there cheap chips for IDE handling available?




Well I checked for Firmware upgrades of HDDs to find out ...
- which kind of MCU these devices use
- find HW details of the Controller boards
- see if there are some un-documented features available
... but did not really succeed (time! )

I think that there should be more customers having the same need, but (see first comment) as the prices are that high, demand is low for private / home users or done with high-power VirtualBox / VMware tools.


Does anybody have an idea / is aware of such undocumented HDD features?

Or is there an easy way to decode the IDE signals to divide the HDD into sections? Of course, I'm aware of the commands, parameters of the standard, but with the DMA and count register settings it's not too easy to split the sectors...

BR,
arcanoid

I have such a home-brew hardware "system" that I use in research work......

The system can be used for what you are trying to do, but it is more a tool for building realtime analysis logs of block devices whilst they are being operated, specifically Nand-flash & SSD
(Really it should be patented but I cannot be bothered)

It has the facility for an "image" of the device it works on , this can be accessed via 3 methods:

1. Direct read/write destructive (monitor only writes are allowed through)
2. Exploration (read only)
3. Fully protected base image file + transaction file + log.


In the 3rd mode, each and every transaction is intercepted via custom hardware and timestamped.
If it is a "write", the write is written to a sequential file(yes that is correct),but then an intercept pointer is updated, so that if a read occurs on that point in future , the read is either taken from:
1. the raw image (if there have been no writes to that area)
2. From a random access pointer into the sequential file.(if there HAS been a write)

Now the good part, because the system uses a log file and a Sequential write area, absolutely every write to the image is logged and can be backed out by rolling back in time(taking the base file and applying the transaction log).
On re-construction, the system takes the "base image" and can see the history of every single transaction occurring on a given point, with the benefit that writes show exactly what has been written.

This is not just a software system, but rather it plugs a hardware intercept and redirect into the physical hardware.

1. A CPLD may not be fast enough or complex enough(long string counters really chew up resources).
I'm currently running this system at 300mhz, which gets me down into the ns clock range for intercepts.( you need to be running AT LEAST a 2X multiple(I.E 2x,4x,8x,16x) as fast as the system clock you are intercepting in ,so that you can correctly detect edges and sync the clocks)

2. A software only system will not work reliably. especially related to device timeouts.

3. Forget trying to 'modify' firmware image files, i looked at this route, you need to intimately know the assembler, and the hardware to work out patches, then there are issues such as ROM firmware.(Nand-Flash sticks), though some of these do have loadable software images

_________________
Universal Declaration of Human Rights: Article 19