Re: Article - Hiding Data in Hard Disk Firmware (Service Area)

With all due respect )

VIII. CONCLUSION

This proof of concept was intended to provide the digital forensic examiner with information not previously written about or discussed elsewhere.

Not exactly "original" (replacing an unused/rarely used service module is a nice new approach ) though ) but the general idea is not so much new
http//www.recover.co.il/SA-cover/SA-cover.pdf
as a matter of fact by using unused service area the Author of the above paper reportedly managed to hide a significant amount of data, 94 Mb, as opposed to the "data (text and small image files)" of this new article.

And the notion that any dd-like tool or forensic imager only accessed "accessible areas" of a modern hard disk is - I believe - well established, besides your 2012 article
https://articles.forensicfocus.com/2012/01/27/forensic-imaging-of-hard-disk-drives-what-we-thought-we-knew-2/
there is this 2010 one
http//proceedings.adfsl.org/index.php/CDFSL/article/download/93/91
and this one
http//ojs.jdfsl.org/index.php/jdfsl/article/view/165
http//ojs.jdfsl.org/index.php/jdfsl/article/download/165/82

What is IMHO more relevant is that instead of the "specialized" and costly PC3000, the linked to article from 2013 managed to use a free and freely available tool (though limited to a certain number of WD disk drives).

jaclaz

Agreed. Thank you for the reply Jaclaz and many thanks also for pulling out some of our older papers (2009) under our old university name of University of Glamorgan. You will no doubt have matched up the author names.

I appreciate your view point regarding costly tools; it is a concern that this has also been achieved with low cost hardware and some free tools /coding techniques by us and others. This is why we feel it a subject of note.

We have developed open-source tools to aid in the recovery of data and would be happy to help anyone in LEA that requires assistance.

Thank you.

We have developed open-source tools to aid in the recovery of data and would be happy to help anyone in LEA that requires assistance.

Which is good, but that won't be of much practical use (yet) I believe in most cases.

I mean, one thing is storing in the service area a small jpg (that can thus be identified/carved/etc.), OK for a POC but another thing is having something making use of cryptography and/or steganography (much more difficult to distinguish from a real module) and the further level (the one related to "Equation Group") what they did was to replace modules with working modules (but doing another thing).

I believe that the good Kaspersky guys needed to compare the actual contents of the service area with the manufacturer "standard" firmware (something that not necessarily is available) to detect it, and anyway they are not even too sure about what exactly the malware does
https://blog.kaspersky.com/equation-hdd-malware/7623/

So, a method for dumping the whole service area (not only the used area but the whole reserved one) would be a very nice new tool, but then analyzing its contents may prove well beyond "normal" capabilities and possibilities of the investigator, or be considered too time taking to be effective.

On the other hand things like these
http//www.forensicfocus.com/Forums/viewtopic/t=10910/
http//spritesmods.com/?art=hddhack
don't come from a multi-million budget criminal organization, it is something that a smart, dedicated electronic hacker ) can do, he also managed to find ways to modify the firmware (again without any need for costly tools) adding modules
http//spritesmods.com/?art=hddhack&page=6

jaclaz

Jaclaz,

Thanks for the comments. However, what we describe in using off the shelf tools not readily available to law enforcement is new. Ariel Berkman’s work is more on point with ours than Dr. Davies. Dr. Davies is manipulating the Glist file in the Service Area to hide data in the Logical block space. Mr. Berkman hid data in an unused track in the Service area. We are manipulating actual service area modules and secreting the data in the existing module structure. Also, thanks for using one of our own papers in your references.

Our intention behind using off the shelf tools was by design. We used WD drives because of their ease of manipulation, but the concept goes across many of the manufacturers. Data recovery companies have been manipulating Service Area and HDD PCB Rom modules for a long time. The mere fact that they exist outside of the understanding of most forensic examiners is problematic. Dumping the entire Service Area may not be practical now in every case but we need to better understand the impact of the data in this space and what it could mean during investigations.

'Thanks for the comments. However, what we describe in using off the shelf tools not readily available to law enforcement is new. Ariel Berkman’s work is more on point with ours than Dr. Davies. Dr. Davies is manipulating the Glist file in the Service Area to hide data in the Logical block space."

To be clear

Said tools are of note in pertinent labs, not all labs will have this budget now, or will have in the future. As is normal for all things. Hence, development of free tools and awareness by researchers like us to support the community. Most will not need this capability as Jaclaz points out. Effectively, with other low-cost HDD FW specific tools tools coming out from other manufacturers, it is very cheap to gain this type of capability for a specific target, which was highlighted in our research as being the main cause for concern..

Re first research concept We do not place data in the LBA space ultimately, but in the ABA space, which is not addressed by the LBA space, which is the function of the defect management system. This is basic physical addressing error principles. This is a far more complex data recovery effort than a copy and paste hex exercise to a simple hdd firmware module, (which is a basic data recovery technique for firmware corruption) in ABA disk space. It is a fact that a typical LBA read-only write blocker (Tableau et al) cannot acquire this space due to no understanding of ABA addressing or raw ATA commands. This has been covered previously in many research papers before "what we thought we knew about imaging hard disks".

"The mere fact that they exist outside of the understanding of most forensic examiners is problematic."

Agreed. This is the motivation for the last 6 years of work educating the correct individuals. It should be obvious that not all of our capability should be in the public domain. It is a shame you missed the seminal research work in the field. This may have progressed your own work in a more effective direction, or been used as a validation mechanism. There are a list of other publications / presentations that cover this article focus already, and more advanced techniques; please see our post above in the Gen. Discussion. Specific resources are only available to active LEA due to need to know principles. However, We would welcome offline discussion as our research has already surpassed your future research work interests, and as a community we should work on new challenges. it is a constant battle to keep up with technology, and ultimately we need to work together on these. Please get in touch if you are interested in working forward on new issues in this space. It would be a pleasure to work with likeminded practitioner's. Thank you.

It is honourable to recognise / reference research inspirations. I would like to highlight this white paper from 2005. Thank you Arne Vidström!

http//www.cse.scu.edu/~tschwarz/coen252_07/Resources/foi-computer-forensics.pdf

Thank you.

Most will not need this capability as Jaclaz points out.

I claim to be able to better express jaclaz's thoughts on the matter wink , the point is not at all about this capability being needed or not (by most or a few), rather the opposite.

It is years that the community knows that this or that trick is possible.

It is IMHO (and in theory) something that should be taken into consideration in many cases, particularly those of fraud and or pedopornography (which I believe represent a large part of LE cases).

As said the "Equation Group" story tells us that it is possible, both in theory and in practice to modify a module in such a way to execute *something else*, but - seemingly the guys form Kaspersky Labs (which I would define as "most probably very proficient in cryptography/reverse engineering and more generally advanced computing) were not able to "detect" or "explain" the modifications, as said - from what I have read on the matter - it seems like they managed to compare the "Equation Group" modified firmware against a "original known one" from the manufacturer.

The article at hand is a nice POC and of course "knowing more is better", but I am failing to see (at the moment) a viable practical use, outside of detecting a "plain" (and "small") jpg.

The other linked to articles/resources prove that it is possible to store in non-plainly accessible areas of a hard disk or hard disk controller *any* payload.

A tool to dump the whole service area would be - as said - a nice tool, but in practice, what could be the use of such a dump (again assuming that instead of a "plain" jpg the modification is some kind of crypted data or executable code (in itself not distinguishable from an ordinary, "manufacturer issued" module or "bunch of bytes")?

What is missing in practice is a sure way to know whether the dump differs in any way from the one issued by the manufacturer, and seemingly the only way to do that is to have the "original" file and compare it with the dump.

And here we are talking of the difficulties with Western Digital drives, that seemingly everyone likes to fiddle with as they are much simpler and plain than - say - Seagate's.

In a coded procedure it would be easy to add the requirement to image/dump the whole service area, both eeprom and sectors on platters, but it is unthinkable that every investigator would be able to have handy the original manufacturer dump or an absolutely untouched device to compare the dump with.

So what would be needed would be a database containing the dumps (or the original firmware) of all hard disks makes and models accessible to make such comparisons.

Since in practice sometimes is impossible to even determine the exact version of a disk, of its PCB or of the firmware loaded on it, and even different revisions of an exactly same model or (as it seemingly came out at the time of the re-known 7200.11 LBA0/BSY issue) exact same model but manufactured in a different factory or even manufactured in the same factory but on different manufacturing lines, it seems to me like very, very improbable that something like the said database could ever be assembled.

And we haven't even touched the topic of re-furbished disk drives (which are often made demoting the capacity by disabling one or more heads in the firmware)[1].

On the other hand disassembling/reverse engineering firmwares of all makes/models is a gargantuan task, besides - with all probabilities - be illegal or however protected by the manufacturer's copyrights or protection of IP (Intellectual Property).

In conclusion, all we have talked about is nice and interesting ) , and "good to know", but in practice it is unlikely to become part of an investigating procedure any soon, simply because it won't give any useful result in a reasonable time and with a reasonable effort.

Surely in some "edge cases" this may be of use also in practice but not in "standard procedure", in the real world I am told by several fellow forensic focus members that are LE investigators how the number of devices (to be subjected to current "standard examinations") is increasing and hard disks and handies are piling up unexamined, with backlogs of months or years, so making the procedure more complex and lengthy is something that simply cannot be afforded.

jaclaz

[1] As a side-side note it is perfectly possible to write data on a platter through a given head, then disable it (and re-enable it when you want to re-access the data).

Jaclaz,

You are so right. Certainly this is may not be as significant at this time as you want, but almost every basic digital forensic course (in the U.S. any way) teaches that the forensic imaging process copies the entire hard drive (or some language like that) such as "A Bit for Bit copy". That is simply not true and that is why we are here collectively commenting now about some of the data not imaged. Unfortunately, all the tricks of hiding data are not commonly discussed in forensic courses. You mentioned Kaspersky's report which was incomplete as to what they discovered and where. Manipulation of the Drives firmware such as removing a head can hide data. Not every case would need the investigator to look for these types of things but we should at least research a way for them to look for this if they need it. What best practices can we provide for them, or other recommendations as simple as go to their local Data Recovery company.

Todd

.. but almost every basic digital forensic course (in the U.S. any way) teaches that the forensic imaging process copies the entire hard drive (or some language like that) such as "A Bit for Bit copy". That is simply not true and that is why we are here collectively commenting now about some of the data not imaged. …

Yep ) , and there are a lot of people that still talk of low-level formatting an hard disk (which was something possible in some early HD models in the good ol' SCSI times, when cylinder and heads or tracks actually had some real correspondence to the physical media)….

The new (since what, 20 years or so!) concept that a mass storage device has become a "black box" of sorts is seemingly very hard to go through ( .
https://en.wikipedia.org/wiki/Black_box

jaclaz