How to trash a file system in various ways

Try switching thw power off during some intensive disk use. This totally stuffed my system up !!

Tried that - but the cheeky thing repaired itself.
Did mutliple copies of major directories in diff terms - switched of hard. Thing muttered about errors and fixed em.

If this was a production machine I suppose a power off would have trashed it . . .  ;-)

dd count=1 bs=512 if=/dev/null of=/dev/hda
# be warned ;-)

ahoffmann's trick with larger counts and a "of=" of any local partition (ie /dev/hda2) should trash that filesystem quite nicely.

BUT wouldn't "if=/dev/random" be better?

> BUT wouldn't "if=/dev/random" be better?
.. and would Murphy tell you that it just generates what it should be/what is now ?

/dev/random might be "trashier" if he has access to a tool that can determine latent magnetic signatures on the platters - otherwise, not gonna matter much.

I'd do 10 runs alternating between /dev/null and /dev/random - much closer to the "federal government wipe".

-Jon

or i could use /dev/zero -
I am already aware of spitting junk on to a mbr
but how to make a file system unreadable but repairable.
...

I gues you have found a hard enough test for yourself if you now claim that you cannot repair such damage.

Glad to be of service.

Cheers,
-Jon

Or to paraphrase - the leading cause of wrong answers is wrong questions.

-Jon

sigh.

dd with a block of 456 and count 1 onto hda1 will trash the mbr - fixable by various methods.
dd with larger block size or count will catch the tail end of the partition table. Harder but not impossible.

The question as first stated.
I am testing my self on system recovery - eg rescue
I know how to trash the MBR eg dd onto hda
I am interested in say - trashing partition table, superblock, unmountable partitions etc

So, still waiting for a suggestion method to upset a superblock, make a file system unmountable but not completely destroyed etc etc.

Thank you for your efforts so far.

Unless you have a standardized definition of "completely destroyed", all we can do is follow the original question and try to post ways to trash a filesystem that would be hard for you to fix - what is the point if I suggest a way to trash it that you know you can fix?

If you know what I and others have suggested is hard to fix, then go to it...  I think there are many data recovery services out there that would care to argue that our suggestions are do not necessarily compromise a 100% data loss scenario, or any sort of impossiblity of recovery.

Also, since you never specified what kind of partition table scheme (there are more than one, you know) nor what kind of filesystem you are using, I think the responses to your question tended to be accordingly vague.

As I said - wrong questions = wrong answers

-Jon

I bet what you really want is an encrypted file system. Some way to protect your data from being read by other people and still be accessible by yourself.

Am I right?

If so, I can suggestion several senarios. Another important security tool is obscrurity. You may contact me directly if you prefer not to broadcast exactly how you are going to achieve it.

comotai@comotai.com

Are you saying if you let dd write over the entire contents of the drive you can still repair it?  Do tell.

comotai says:
>Another important security tool is obscrurity

Rubbish - that sentence is the leading cause of insecurity.  If you can't mention a good way to encrypt something in public, then your encryption scheme is broken.

Private keys and other authentication information should be kept secret - the way they are used should never be a secret (or you are begging to get hacked).

-Jon

A general question for a general senerio.

I will use the editor to introduce errors into the file system, should be suff't for my purposes.

This was simply an exercise in system recovery.



Thankyou for your comments captain - very helpfull.

Thanks - but I'd have given points to ahoffman (since he was the first to describe a way to trash any filesystem (just use dd) that would be a challenge for you to repair).

As comotai points out, stuff like this rarely happens in ways that are really easy to fix - sure, you might be able to fix a partition table if it gets a hole punched in it somewhere, but most data loss situations are a lot more messy, and are more along the lines of the 'dd' example as far as repair difficulty in concerned...

Didn't really expect you to give points to ahoffman, since he was giving a practical solution that you obviously didn't want to hear.

If you say "how do I trash my house - I want to test my home repair skills" and someone says "dynamite it", I think they have given you the ultimate test of your home repair skills, regardless of how much you expect/like/accept the answer.

I was tempted to answer your original post by saying "chuck the drive onto the parking lot", but I *do* think surface-mount electronic repair and clean-rooms go a little beyond what most people think of under the guise of "data recovery"

Cheers,
-Jon

>  comotai says:
> >Another important security tool is obscrurity
>
> Rubbish - that sentence is the leading cause of insecurity.  If you can't mention a good way to encrypt
> something in public, then your encryption scheme is broken.
>
> Private keys and other authentication information should be kept secret - the way they are used should
> never be a secret (or you are begging to get hacked).

I can assure you that the DoD and any decent hacker does not agree with you.

but.. this is a subject for another question.

The DoD has been hacked so many times it's not funny - that should give you some idea about their security.  By "any decent hacker" I presume you are referring to the fact that most hackers are lazy and tend to bypass machines with non-standard configs - I call those hackers "script kiddiez".  A truly decent hacker would take note of such a machine and consider it a challenge...  A hacker only bypasses a machine because it is too trivial to attack, or too hard.  "Too hard" may or may not mean "obscurely configured", depending on the level of skill.

If you need further convincing, look at Mickeysoft - their chief method of security is through obscurity ("no, you can't examine our security code"), and their products have the worst security track record of all...  Anyone that argues this point is wither smoking crack, or has been reading to many mickeysoft-funded "independant" reviews.

If you want to put your money where your mouth is, throw up an SSH1 server on a non-standard port, and we'll see how far security through obscurity gets you...  I give your box a week or so before it gets hacked.

Do you know what I mean when I say "security through obscurity"?  Obscurity is not refusing to divulge your passwords/authentication keys - obscurity is refusing to say how those passwords/keys are used to authenticate.  No one has a problem about folks knowing how unix passwords are authenticated, because the underlying methodology (one-way encryption) is secure.  Same goes for other open encryption standards.   You will always get hacked if you attempt to implement security that relies on the attackers being ignorant of methodology - they can (and will) figure it out.  I don't think you would have had a problem discussing encrypting data via PGP, because everyone knows how it works, and it is excessively hard to crack without some knowledge of the key data...  The fact that you wanted to discuss encryption off-list suggests you meant to implement a scheme that has not been subjected to peer-review, or is otherwise not publicly verified to be secure.

-Jon

BTW, most network operators agree with my point of view, at least on this continent - ever read (or subscribe) to the North American Network Operators Group mailing list (affectionately known as NANOG)?  

The fact that the DoD does not spend enough money to hire such knowledgeable folk is not my concern.  I'm sure the DoD could not, for example, ever match my own criteria for employment.

-Jon

Thanks The--Captain for voting the dd solution.
KISS - keep it small and simple.

But to improve it, even for some sophisticated data recover tools, do it like this:
     while (as-much-as-you like) {
         dd count=1 bs=512 if=/dev/random of=/dev/hda
     }
     dd count=1 bs=512 if=/dev/null of=/dev/hda

where you use bs=512 to just destroy MBR and partition table, and a huge value to destroy the complete disk.
AFAIK, this is a much better, 'cause full-proove, solution than anything recomemded/sold by DoD :-))
And it works since roughly 30 years, without any change.
(Please don't tell DoD:)

ahoffman - no problem - we are seemingly in complete agreement.  

Although I feel kind of silly pulling rank, with regard to the security argument, I would remind comotai that there is a reason that ahoffman (sorry for pulling you into this) and I are topic experts in the security forum...  It usually does not result from being a complete idiot on such topics.  The points for topic experts may be unusually low, but I would suggest that this is due to the relatively low traffic in the Security TA (try becoming a topic expert in ATM or OS/2 - not gonna happen anytime soon).

-Jon

I dont suppose you chaps noticed that I already mentioned the dd file system "trash" in my question at the start which is why it wasn't given any points. eg I already knew that.

I also didn't mention any sort of security erase. widely off the topic of the question.

The only real new information in relation to the actual question came from "he who has the points".

hangman actually came second in the race.

EOF

calm down, I don't answer just for grabbing points (don't know whatever I can use them for:).
It's some kind of "brain jogging", and that's why I sometimes also do not read carefully enough, yes the dd was mentioned in the question, I missed it, shame on me ..
Anyway, I always try to find a small and simple solution, that's what I post (in a hurry, usually;-)

So, you're welcome if you just explain why this or that answer was the winner, makes it more understandable for future readers.

yeah, I noticed that dd was mentioned inititally, but only to trash the MBR - I think ahoffman was good to point out that you can use dd in a myriad of ways (above and beyond trashing the mbr) to test your data recovery skills.  If you use pre-built filesystem editing tools to trash the filesystem they will most likely do a much smaller amount of damage, and be easier to fix (especially since you can easily identify the affected parts of the filesystem, since you did the damage yourself) - using dd can more realistically simulate a drive and or software failure, where random data just starts appearing in the completely wrong place - dd gives you access to the raw device - I doubt you can find a tool that will give you more chances to hose the filesystem than that.

I expected to gain no favor here, since I support an unfavorable but totally correct "answer" to this post.  You say hangman gets your second vote for his "turn off the power" solution?  Do I then get your third vote for my suggestion to throw the HD onto the parking lot?

Sad,
-Jon

I am calm though..

Dear Jon
Ever consider that I might ask some one else to do the damage for me to find ? guess not.

The last post from me on this question/answer

As I indicated in my earlier post and comment to the accepted answer to my question. The accepted answer was considered to be the best solution. If you feel this is not the case I suggest you contact cs@experts-exchange.com

Thankyou for whatever time you have spent considering the questions and have a nice day.

I am calm though..

Dear Jon
Ever consider that I might ask some one else to do the damage for me to find ? guess not.

The last post from me on this question/answer

As I indicated in my earlier post and comment to the accepted answer to my question. The accepted answer was considered to be the best solution. If you feel this is not the case I suggest you contact cs@experts-exchange.com

Thankyou for whatever time you have spent considering the questions and have a nice day.