×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Hiding and Recovering Data on Linux

CmdrTaco posted more than 12 years ago | from the hah-its-in-the-other-hand dept.

Linux 151

neuroticia writes "linuxsecurity.com has an interesting article on data hiding and recovery: "On a 4GB Linux partition, the block size is typically 4K (chosen automatically when the mke2fs utility is run to create a filesystem). Thus one can reliably hide up to 4KB of data per file if using a small file. The data will be invulnerable to disk usage, invisible from the filesystem, and, which is more exciting for some people, undetectable by file integrity checkers using file checksumming algorithms and MAC times. Ext2 floppy (with a block size of 1KB) allows hiding data as well, albeit in smaller chunks.""

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

151 comments

Mum ? (-1, Offtopic)

selderrr (523988) | more than 12 years ago | (#3161911)

Can I cut my mum-in-law into bits and hide her away ? I've got a 80GB hard drive, and with my new DVD-R I can spread bits all over the pleace !

I don't see why not! (-1)

ringbarer (545020) | more than 12 years ago | (#3161922)

Best First Post Ever!

Re:I don't see why not! (1)

selderrr (523988) | more than 12 years ago | (#3162400)

yeah, but apparently, some lame moderator with humor up his ass moderated me offtopic.. jeez.. if I had said CowboyNeal instead of my mum-in-law, I'd probably be moderated (+4,funny)

Today (-1, Troll)

Anonymous Coward | more than 12 years ago | (#3161982)

Tomorrow may be payday but today is pi-day!!!

Go pi-day. Go pi-day. It's your birthday.

3.1415926535897932384626433832795028841971693993 75 10582097494459230781640628620899862803482534211706 79821480865132823066470938446095505822317253594081 28481117450284102701938521105559644622948954930381 96442881097566593344612847564823378678316527120190 91456485669234603486104543266482133936072602491412 73724587006606315588174881520920962829254091715364 36789259036001133053054882046652138414695194151160 94330572703657595919530921861173819326117931051185 48074462379962749567351885752724891227938183011949 12983367336244065664308602139494639522473719070217 98609437027705392171762931767523846748184676694051 32000568127145263560827785771342757789609173637178 72146844090122495343014654958537105079227968925892 35420199561121290219608640344181598136297747713099 60518707211349999998372978049951059731732816096318 59502445945534690830264252230825334468503526193118 81710100031378387528865875332083814206171776691473 03598253490428755468731159562863882353787593751957 78185778053217122680661300192787661119590921642019 89380952572010654858632788659361533818279682303019 52035301852968995773622599413891249721775283479131 51557485724245415069595082953311686172785588907509 83817546374649393192550604009277016711390098488240 12858361603563707660104710181942955596198946767837 44944825537977472684710404753464620804668425906949 12933136770289891521047521620569660240580381501935 11253382430035587640247496473263914199272604269922 79678235478163600934172164121992458631503028618297 45557067498385054945885869269956909272107975093029 55321165344987202755960236480665499119881834797753 56636980742654252786255181841757467289097777279380 00816470600161452491921732172147723501414419735685 48161361157352552133475741849468438523323907394143 33454776241686251898356948556209921922218427255025 42568876717904946016534668049886272327917860857843 83827967976681454100953883786360950680064225125205 11739298489608412848862694560424196528502221066118 63067442786220391949450471237137869609563643719172 87467764657573962413890865832645995813390478027590 09946576407895126946839835259570982582262052248940 77267194782684826014769909026401363944374553050682 0349625245174939965143142980919065925093

Pi-Day!!! (-1, Troll)

Anonymous Coward | more than 12 years ago | (#3162061)

3.141592653589793238462643383279502884197169399375 10582097494459230781640628620899862803482534211706 79821480865132823066470938446095505822317253594081 28481117450284102701938521105559644622948954930381 96442881097566593344612847564823378678316527120190 91456485669234603486104543266482133936072602491412 73724587006606315588174881520920962829254091715364 36789259036001133053054882046652138414695194151160 94330572703657595919530921861173819326117931051185 48074462379962749567351885752724891227938183011949 12983367336244065664308602139494639522473719070217 98609437027705392171762931767523846748184676694051 32000568127145263560827785771342757789609173637178 72146844090122495343014654958537105079227968925892 35420199561121290219608640344181598136297747713099 60518707211349999998372978049951059731732816096318 59502445945534690830264252230825334468503526193118 81710100031378387528865875332083814206171776691473 03598253490428755468731159562863882353787593751957 78185778053217122680661300192787661119590921642019 89380952572010654858632788659361533818279682303019 52035301852968995773622599413891249721775283479131 51557485724245415069595082953311686172785588907509 83817546374649393192550604009277016711390098488240 12858361603563707660104710181942955596198946767837 44944825537977472684710404753464620804668425906949 12933136770289891521047521620569660240580381501935 11253382430035587640247496473263914199272604269922 79678235478163600934172164121992458631503028618297 455570674983850549458858692699569092721

much like timma (-1, Offtopic)

neal n bob (531011) | more than 12 years ago | (#3161914)

plays hide the salami with cowboy neal.

keep your hands off me, you damn dirty hippies!

Well... (0)

junkster191 (551312) | more than 12 years ago | (#3161916)

Privacy is always a good thing. But how quickly do you think the FBI or USSS will try to regulate this sort of "uncrackable encryption"?

Re:Well... (0)

Anonymous Coward | more than 12 years ago | (#3161926)

It's not encryption and it's not uncrackable.

Re:Well... (1)

-brazil- (111867) | more than 12 years ago | (#3161937)

It's not encryption and laughably easy to find - the agencies would probably quite happy to have everyone use it instead of real encryption.

first? (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3161919)

mebbe?

Now I am the master (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3161920)

First post 0wNz j00!

That reminds me (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3161923)

Tonight I will play hide and recover the salami with the wife tonight.

Interesting. Very interesting. (0)

wondercat2 (544298) | more than 12 years ago | (#3161930)

Would it be possible to break up the encrypted passwd file and hide it in slack space? Perhaps have an ersatz passwd with useless passwds, and hide the real one in several places around the disk. Or am I just being really REALLY paranoid??

Re:Interesting. Very interesting. (2)

gazbo (517111) | more than 12 years ago | (#3161989)

...but you'd need to tell the OS where to find the pieces, so whoever it is who's beaming radio waves at your foil hat would be able to track their location just as easily, by finding out where the system would look.

And even if the paranoid people who think that government agencies have advanced encryption breaking hardware are correct, I still think that locating the hidden chunks in the manner I suggested would be trivial compared to cracking MD5 hases.

Reserve (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3161934)

Be, all that you can be... in the Troll Army, Reserve~!

We do more trolling before 9 AM than most trolls do all day!

just to make sure.. (0)

Anonymous Coward | more than 12 years ago | (#3161935)

why not strong encrypt your document first, when embed the result steganographically into a jpeg before "hiding" it on an ext2 filesystem.

That should do it.

Re:just to make sure.. (4, Interesting)

-brazil- (111867) | more than 12 years ago | (#3161944)

Better yet, how about combining the "slack space" concept with that of a steganographic filesystem [mcdonald.org.uk]? In fact, the two concepts fit together very well...

Re:just to make sure.. (-1)

neal n bob (531011) | more than 12 years ago | (#3162015)

you dirty open sores hippies are always talking about encrypting things and keeping the 'man' from seeing what's on your computers. What do you have to hide? Anything besides kiddie porn and your secret family recipe for hash brownies? Filthy bastards.

Some questions... (3, Insightful)

Saib0t (204692) | more than 12 years ago | (#3161939)

The article, while explaining rather well that there IS such a thing, fails to explain some things:


- what are the potential uses for such a thing?
- a hacker could hide some information somewhere, but what to hide?
- Is there any legitimate use for that?
- Does moving the file to another location suffices to prevent any use of such a thing? (after all, if the file is moved, the block is free for reuse).

Just my 0.01 worth questions...

Re:Some questions... (4, Insightful)

redhog (15207) | more than 12 years ago | (#3161957)

This is a question of security by obscurity. If everyone used exactly this technic to hide their data, everyone and their dog will be able to recover it. But if everyone hides their data at different places (I hide mine in the most insinificant bits in a picture, you hide yours in teh filesystem, etc), we'l increase the workd needed to find any given information.

If you think that "if you are innocent, you have nothing to hide", then certainly, this has no uses. Otherwise, it has lots of uses :)

Hiding dirty pictures of you and your SO from parents perheaps?

No, just _moving_ it does not free the block. You must either move it to another disk, or copy it and remove all had links to it.

Re:Some questions... (1)

Saib0t (204692) | more than 12 years ago | (#3161994)

This is a question of security by obscurity. If everyone used exactly this technic to hide their data, everyone and their dog will be able to recover it.

Let's assume that if you want to hide something, you'll be clever enough to at least encrypt it before storing it (or even ROT13 it). How can one determine the different between that and random bits left over from old programs, pictures?

Re:Some questions... (0)

Anonymous Coward | more than 12 years ago | (#3162039)

There are techniques. I remember a slashdot story about someone making a "stenography-classifier" of some sort: It uses statistics to determine "the possibility" of the picture being altered for stenography purposes. You see, all data have certain characteristics. Encrypted data would have to be suspiciously random, while data left over from other files are not so random. Unless you encrypt everything! :-)

Anyways, there's always solutions, but it gets harder to uncover them in reasonable time.

Re:Some questions... (2, Insightful)

Saib0t (204692) | more than 12 years ago | (#3162164)

There are techniques. I remember a slashdot story about someone making a "stenography-classifier" of some sort: It uses statistics to determine "the possibility" of the picture being altered for stenography purposes
that's why I think sound files are better to hide information: If you have a RGBA picture of 800x600 pixels, that's 480000 floats where you can steal a bit or two. That's equivalent to a 44.1Khz 10 second wave file. So if you have something longer to hide, hiding it in sounds may sound (;-)) like a better idea, besides, you can do that in a way that the excessive data results in only unhearable data is added...

Well, That's another way of hiding data, the possibilities are endless

Re:Some questions... (2)

friscolr (124774) | more than 12 years ago | (#3162073)

How can one determine the different between that and random bits left over from old programs, pictures?

your programs won't leave random bits behind, they leave program-droppings - maybe pointers, strings of data, etc. as with hiding data in image files, you have to be careful that the signature of your hidden data matches what one would expect in that area.

do a google search for steganography to learn more about it, like into Neil Provos's stegdetect work at citi.umich.edu.

Re:Some questions... (1)

Saib0t (204692) | more than 12 years ago | (#3162187)

your programs won't leave random bits behind, they leave program-droppings
I think you misunderstood my question (or I misunderstood your reply). I was talking about this: you have a program on the HDD, it's on a given block, you delete the program, create a 100 bytes file on that block, the remaining 3996 bytes would be filled with part of the code of the program. Now, how would a malicious person be able to figure out that the files you hide in the blank space are not leftovers from programs you deleted?

Thanks for your advice on steganography, I bookmarked it for later reading.

Re:Some questions... (3, Interesting)

friscolr (124774) | more than 12 years ago | (#3162301)

you delete the program, create a 100 bytes file on that block, the remaining 3996 bytes would be filled with part of the code of the program. Now, how would a malicious person be able to figure out that the files you hide in the blank space are not leftovers from programs you deleted?

It depends on what kind of data you are hiding, and how that data compares to the data already there.

the 3996 bytes left over will have a very discernable pattern: it will be machine code of the program, NOT random bytes.
the 100 bytes encrypted file you create will be random data and will (most likely) look very different from the machine code.

It would be like reading this message and finding a bunch of random numbers in the middle of it - you've got to ask yourself why the pattern was broken.

A better option would be to make your encrypted data look like bytecode and not like random data, kind of like how uuencode makes binary data into ascii characters - that way it won't stand out against the other non-data in the file.

Re:Some questions... (2)

MartinG (52587) | more than 12 years ago | (#3161964)

- what are the potential uses for such a thing?
Fun mostly! But really, it's useful for anyone who wants to hide information from governme^wuntrustworthy people.

- Is there any legitimate use for that?
See above.

- Does moving the file to another location suffices to prevent any use of such a thing?

AFAIK, no. Not with ext2 at least if you're moving the file from one place on a filesystem to another on the same filesystem. The data doesn't actually get moved. All that changes is the link to the inode. (can somebody correct me / elaborate)

Re:Some questions... (0)

Anonymous Coward | more than 12 years ago | (#3161968)

- what are the potential uses for such a thing?

Hide small bits of data eg. phone numbers used infrequently that are useful using this method would require just a tad more effort to retrieve then the Post It Notes(tm)I keep in that awkward spot under the vase on the 19th floor.

- a hacker could hide some information somewhere, but what to hide?

Anything but once you get over 4k you need a map of where and what bits are where.

- Is there any legitimate use for that?

See the first point.

- Does moving the file to another location suffices to prevent any use of such a thing? (after all, if the file is moved, the block is free for reuse).

Yes but some will consider that a plus. If the information is moved then some other entity is messing with my disk and those phone numbers mentioned in the first example were not meant for their eyes.

sws

Re:Some questions... (-1, Flamebait)

Anonymous Coward | more than 12 years ago | (#3161972)

You might want to hide pictures of the plants you are growing. Plants which you enjoy, and which ease the pain of people with MS or undergoing chemotherapy, but which are illegal. The fact that they are illegal may not bother you, but you could go to prison for it. So best to hide them away, then everyone is happy.

OK?

Re:Some questions... (1)

WalterSobchak (193686) | more than 12 years ago | (#3161974)

Good point.

Indeed, the empty space is a nice place to hide things, but just one among very many, and obviously not specific to Linux.

There is a wide variety of unused space on file systems in general, and media files for music, images and the like make a perfect hiding spot. Or am I missing something here about the importance of this issue?

Alex

Re:Some questions... (2, Interesting)

Saib0t (204692) | more than 12 years ago | (#3162012)

The problem is that to hide information that I would think important (such as pictures, blueprints, my new DeCSS2, the plans to bomb a MacDonald for providing the world with bad food for years, ... ) take more than 4K.
It would take more than one of such blank spaces left on the disk, which would make it very difficult to recover as I'd need to start mapping the different blocks. I think hiding data in images, movies or (way better) music would be better than putting files there or am I missing something (too)?

Re:Some questions... (1)

fyonn (115426) | more than 12 years ago | (#3161992)

> a hacker could hide some information somewhere, but what to hide?

good place to hide a rootkit ;), much like ntfs's file "streams". unless you know where to look explicitly, you're unlikely to find it in general day to day use...

dave

Re:Some questions... (1)

Cally (10873) | more than 12 years ago | (#3162053)

Unless you run AV software like that produced by my current employer (who shall remain nameless: if you're shopping for a/v software it's not hard to find. And of course STD disclaimer applies - I speak for myself only, etc etc) which checks NTFS alternate streams as well as the main fs.

Re:Some questions... (0)

Anonymous Coward | more than 12 years ago | (#3162602)

I think you're looking at it from the wrong perspective, rather than what you CAN hide there, it's more a security issue from what possibly you HAVE in the whitespace that you are unaware of. Where unaccessible for reading by the OS, some low level disk utilities are capable of reading this information.

Nonsense (4, Informative)

blane.bramble (133160) | more than 12 years ago | (#3161942)

Sorry, I fail to see how this is news (block sizes and slack space have been well known for years) or a useful technique - you'd need to have a large number of known unchanging files to store any sensible quantity of data. The obvious source would be binary executables. If you are able to store data in the slack space of binary executables, you're presumably root, in which case why not secure your data in a more sensible way.

Re:Nonsense (3, Interesting)

friscolr (124774) | more than 12 years ago | (#3161977)

If you are able to store data in the slack space of binary executables, you're presumably root

not necessarily root, but you have root access, like in the case of a compromised system.

until detection utilities become widespread, this would be a great place to hide your 1337 +001z like DDoS utils, portscanners, passwd crackers, lists of cc's passwds etc etc. set up a redundant distributed system across all your hacked boxen to hide files in executables and the sysadmin will not even realise what his system is housing.

Re:Nonsense (1)

tius (455341) | more than 12 years ago | (#3162022)

100% agree. Just wanted to add that anyone having access to the raw device can scan _whatever_ they want. So, if our little 'secret' filesystem has any identifiable structure then it is readily made insecure.

Personally, I think strong custom encryption and a compact flash disk makes more sense for very sensitive info.

Virus/Trojan! (1)

malaba (9813) | more than 12 years ago | (#3162029)

storing small exe ?

virus/tronjan!

perfect way to hide backdoor
RootKit have another cool hack to exploit...

my 2 cent

Re:Nonsense (0)

Anonymous Coward | more than 12 years ago | (#3162152)

Nonsense? Isn't anyone tired of pretentious assholes who think any subject repeated during the course of humanity is somehow redundant or irrelevant?

Not everyone has used linux for 5000 hours, many of us are newbies and admire fresh perspectives on previously covered subjects.

How much would you like to slap a driving instructor, who when observing you fumble with the shifter for the first time said:
"Geeee this whole shift thing, we covered this in the 30s, get with the program... Mkay?"

Re:Nonsense (1)

blane.bramble (133160) | more than 12 years ago | (#3162712)

This isn't a computer course though. How useful do you think an article in a driving instructors magazine would be telling you where the steering wheel was?

Re:Nonsense (4, Insightful)

bourne (539955) | more than 12 years ago | (#3162321)

If you are able to store data in the slack space of binary executables, you're presumably root, in which case why not secure your data in a more sensible way.



Unless, of course, you're just "borrowing" root access from the chappie who actually owns the box.



A skilled attacker will hide as many signs of his intrusion as possible. This is one more method he may use, to avoid file integrity checkers like Tripwire, AIDE, and FCheck.



As for what he's hiding? Let's say he puts a trojan sshd in place to grab passwords - those passwords could be conveniently hidden until Bad Guy can come around and collect them.


Re:Nonsense (4, Insightful)

zCyl (14362) | more than 12 years ago | (#3162506)

Sorry, I fail to see how this is news (block sizes and slack space have been well known for years) or a useful technique

Remove yourself from that high equine animal you are saddled upon. Yes, to many of us here, the idea of storing data in unused sections of a drive is old hat, and many of us have even used such a technique before for various purposes such as for copy protection flags, or for hiding information where people wouldn't think to look, etc. (which are examples of where it would be useful) The "news" in this post is not that you can hide data in the unused portions of blocks, but that a new article overviewing this technique was recently posted, so that those who are not familiar with the concept can go read it and learn about it. These are important concepts that system administrators should know about, so that they know when they can and cannot trust what the tools at their disposal (such as ls, for example) tell them about the contents of their system.

By itself, hiding something in a system doesn't provide a very good amount of security, but in combination with other things, it can be the best form of security possible. Never underestimate the value of other people not even knowing there is a secret they need to look for.

Re:Nonsense (2)

agentZ (210674) | more than 12 years ago | (#3162663)

Things in /bin change very rarely. And they don't have to be small, only the last block has to be small relative to the block size.

There isn't a way to prevent data hiding... (0)

Anonymous Coward | more than 12 years ago | (#3161943)

...until you're free to think something without being forced to tell anyone.

uses (0)

Anonymous Coward | more than 12 years ago | (#3161950)

sounds more like something you would use in an easily-defeated copy-protection scheme for software distributed on read-only media.

More useful if filesystem copied whole Blocks (4, Informative)

Anonymous Coward | more than 12 years ago | (#3161952)

This trick is more useful on other OSs that copy using entire blocks.

for example data hidden in the tail portion of 512 bytes on a mac will be copied from one floppy to another on the Mac OS for the last 18 years.

Using modern network protocols or file compression will lose these tail end bytes.

A way of hiding data in a Mc file that survives network and file compression is to store data in the 12 byte undefined section of a resource fork header.

Some people write 12 byte hole scanners to search for passwords and credit card numbers and somwtimes find them according to legend.

But the mac has a concept of a physical file length and a logical file length, and the two values do not have to equal each other, and the physical file length has to be modulo 512 minimum.

But hiding data can get easily lost, its better to hide such data in node cluster control areas rather than file tail ends.

Re:More useful if filesystem copied whole Blocks (0)

Anonymous Coward | more than 12 years ago | (#3161996)

But where do you find a Mac with a floppy drive these days?

Re:More useful if filesystem copied whole Blocks (0)

Anonymous Coward | more than 12 years ago | (#3162128)

same priciple works with any removable recordable media (ZIP, JAZ, USB-RAM) that use HFS or HFS+ filesystem.

HFS is common on all mac media, not just floppies.

Floppies are just good example.

Hide data in 1.44Mb blocks (4, Funny)

tom_newton (179430) | more than 12 years ago | (#3161956)

Of course! Copy the requisite illegal plans to a floppy, jam it in a bag, and bury it in your garden. Of course, if you have a dog, he might dig it up and nark on you to the feds, but that's life I suppose :)

Personally, my data is about as interesting as a box of dry Jacob's cream crackers, so I ain't about to go hiding it, either in my slack space *or* my window box!!!

Uses? (5, Funny)

secondsun (195377) | more than 12 years ago | (#3161958)

Good for hiding all of my 1 - 4 kB pr0n.

Re:Uses? (1)

Marwin (57353) | more than 12 years ago | (#3162696)

I normally put a . in front of the filename. That kind of encrypts the file and make it disappear, because i never see the file again when i type "ls" in my bash. Call med the Superhaxxor if you want!

shred (4, Interesting)

ksw2 (520093) | more than 12 years ago | (#3161965)

They didn't mention...

shred -u [filename]

...in the article. It beats writing /dev/zero to your entire free space. Besides, if you try and overwrite your free space by dd'ing from /dev/zero, won't the outfile top out at 2 gigs on ext2?

Re:shred (3, Informative)

boaworm (180781) | more than 12 years ago | (#3162071)

Besides, if you try and overwrite your free space by dd'ing from /dev/zero, won't the outfile top out at 2 gigs on ext2?

No, it wont. Unlexx you are writing the zero's to a file which is already larger than 2 gigs. If you write on the device (/dev/hda1 etc) you are not accessing a file or a filesystem, therefor no limitation.

Besides, the 2 GB limitation is not valid any more, unless you use an old kernel. I made a 2.5 GB ascii file last night, and it worked fine :-)

Re:shred (3, Informative)

Dr_Claw (68208) | more than 12 years ago | (#3162075)

They didn't mention...

shred -u [filename]
...in the article.

Really?

Several Linux file cleansing utilities exist. All but one can only be used to wipe files, rather than empty disk space. GNU shred (by Colin Plumb),
...
As reported in shred man page "shred relies on a very important assumption: that the filesystem overwrites data in place". If this condition is not met, no secure deletion will be performed (with no error message!).
...
The important fact to note is that when empty space is wiped, slack space for all files remains intact. If file is wiped (at least using current version of GNU shred), the associated slack space is NOT wiped with it!

Mentioned, and also reasons given why it may not be as good as you think.

Besides, if you try and overwrite your free space by dd'ing from /dev/zero, won't the outfile top out at 2 gigs on ext2?

No. 2Gb is the maximum filesize on 32bit architectures - nothing to do with ext2. This limit can be got around anyway I believe. Besides, in this case you could just keep creating files until the partition was filled.

Re:shred (1)

Ioldanach (88584) | more than 12 years ago | (#3162370)

The important fact to note is that when empty space is wiped, slack space for all files remains intact. If file is wiped (at least using current version of GNU shred), the associated slack space is NOT wiped with it!

So maybe we should fix shred, then.

Re:shred (4, Informative)

cromano (162540) | more than 12 years ago | (#3162528)

shred -u [filename]

Hrm... may not work with a lot of setups. From "shred --help":

CAUTION: Note that shred relies on a very important assumption: that the filesystem overwrites data in place. This is the traditional way to do things, but many modern filesystem designs do not satisfy this assumption. The following are examples of filesystems on which shred is not effective:

* log-structured or journaled filesystems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, etc.)
* filesystems that write redundant data and carry on even if some writes fail, such as RAID-based filesystems
* filesystems that make snapshots, such as Network Appliance's NFS server
* filesystems that cache in temporary locations, such as NFS version 3 clients
* compressed filesystems

...Since many of the latest distributions (like RH7.2 and MDK-8.1) offer journalized FSs (ext3 by default even), shred will fail. RAIDs will fail too.

Note as well that, unless you specify the -x option, it *will* attempt to shred the final block completely, beyond the end of the file (thus killing the hidden data).

I'll go back to lurking now.

What's wrong with using removable media? (3, Insightful)

WIAKywbfatw (307557) | more than 12 years ago | (#3161976)

Take your data with you. Keep it with you at all times or put it somewhere more secure or less obvious than an open server.

Yes, it's not a perfect solution but it works 99 per cent of the time. And, if you're paranoid, you can always encrypt the files on your CDR/floppy/zip/Compact Flash card/USB key chain drive for further security.

Sometimes the simplest solutions are the best.

Re:What's wrong with using removable media? (2, Insightful)

friscolr (124774) | more than 12 years ago | (#3162017)

Sometimes the simplest solutions are the best.

Guido's fist is a rather simple solution and will come in quite handy retrieving any files he lost on my zip disk (after he's pulverized my face and stolen everything i own). i hope i was paranoid and encrypted them...

i prefer storing everything on my servers b/c i never know what's going to happen to that removable media. I've never had anything stolen of of me but have had to chase down people who've tried to steal my shit and have known plenty of people who have had their phyiscal stuff stolen from them (pickpocketing, muggings, etc) and plenty more people who are very forgetful and lose zips/cds/etc everywhere.

I find some interesting data around town from people who thought storing on removable media suited them! As long as you *can* keep it safe on you, that's fine.

Good or Evil? (2, Insightful)

juliao (219156) | more than 12 years ago | (#3161979)

As for securely wiping files, most of us already know a bit about it.

Regarding slack space, yes, it works as described, you can use slack space to write your data, and hope that it doesn't get overwritten when the file grows.

Using encription and spanning multiple slack zones, namely on binary files, you can, for instance, write a tool that encrypts a file, writes it on a number of slack zones for the files in /usr/bin (since these won't grow much over time, will they?), and then is able to recover the file.

You can even write the tool so that it creates two pipes, one to read, another to write.

But in the end, is this good or bad? Like it is said in the article, it can as easily be used to hide evidence as it can be to plant evidence.

What should we do? Write tools to use this to our advantage, or write tools to automatically wipe clean the slack area and render this inoperant?

Or should we do both?

FBI caught a traitor who did this on a floppy (2, Interesting)

Anonymous Coward | more than 12 years ago | (#3161981)

Less than a years ago the FBI caught a guy who used various technologies such as this exact trick on a floppy, and ram storage, and other pda things, to help hide and transport stolen military secrets.

This exact trick (hidden portions on tail ends of files) was cited in one news article.

He got caught. Why? Because the forensic tools are designed to work on DELETED files adn totally IGNORE THE FILE STRUCTURES ON MEDIA.

The many commercial forensic tools work on entire blocks of data and ignore the lengths of files when foing a default scan of a hard drive or floppy.

So this type of hiding is silly, even if encrypted.

The FBIs tools they purchase will find it.

Re:FBI caught a traitor who did this on a floppy (0)

Anonymous Coward | more than 12 years ago | (#3161999)

I think what Taco is interested in is not hiding data from the FBI, but other people who might use his computer (such as Ms. Fent).

Re:FBI caught a traitor who did this on a floppy (1)

Ayon Rantz (210766) | more than 12 years ago | (#3162026)

How on earth do you catch someone on a floppy? Can't have been much left of him when they were finished. What you get for being a traitor I guess.

Too fragile for many uses (3, Informative)

Bowfinger (559430) | more than 12 years ago | (#3162003)

Beware that this hidden data is extremely fragile. It will not be preserved when copying files. It will only be backed up if you choose to backup the raw file system or drive. If you use file-oriented backups like cpio, you'll lose the hidden information.

You could rename the file or link to it without losing data. You could rename a parent directory successfully. If you tried to copy the directory, however, you'd lose the data. In short, if you do anything that changes the file's location on the disk, the secret data is lost, or at least disassociated with the original file name and vulnerable to overwriting.

Re:Too fragile for many uses - NOT TRUE (0)

Anonymous Coward | more than 12 years ago | (#3162217)

not fragile on a mac.

A mac will faithfully copy a file and round up to 512 bytes if needed under HFS and HFS+ OS's.

Probably on all mountable OSs except over networks on a mac.

Under Linux, who knows, have to sheck the source I guess or try it.

but a more practical use? (3, Interesting)

transiit (33489) | more than 12 years ago | (#3162008)

Alright, so you could hide data within the trailing unused space of a block, (IIRC, people like Tanenbaum refer to this as internal fragmentation), and the article says you could use a tool like bmap to handily stuff data in this space....but for those who aren't convinced this does much in the way of hiding anything, could a more practical use be put into place for the slack space? Perhaps write support into the filesystem that would start stuffing things in a relatively (user) transparent way...thus finally making a 10GB disk something much closer to holding 10GB (base-2 or 10 calculations of a GB aside)?

Or perhaps some sort of piggyback filesystem that uses the slack space but would be mounted as a separate partition?

I'd imagine this would introduce lots of external fragmentation on anything stored there, but as a separate filesystem, you could suffer those pains and move your "current, but not often accessed" files there, where you really don't care if you suffer a bit of a performance hit because it's still a whole lot better than reading it from backups.

-transiit

Re:but a more practical use? (1)

braque (16684) | more than 12 years ago | (#3162062)

reiserfs has such a feature: pack the tails of files together in one block

Re:but a more practical use? (2)

ceswiedler (165311) | more than 12 years ago | (#3162307)

Ok, so you want to store data in the unused parts of the filesystem. How are you going to keep track of it? Well, a tried-and-true way is to use the concept of addressing through blocks and then use an inode/block/extent structure to keep track of which data corresponding to which file is in which block. And you know what? You'd *STILL* probably waste space, so why not implement a mapping structure which keeps track of data stored in the holes of the blocks stored in the holes of the blocks of the original filesystem.

In other words...you'd have to implement a filesystem again, using smaller blocks, and gain nothing. Worse than nothing, since the "first" filesystem will be keeping track of its own data in the first part of each block, the "second" filesystem will have to cope with variable-sized blocks, which means more overhead.

If you want to waste less space on your drive (silly, considering the cost per gig these days) just use smaller blocks. And suffer a performance hit, of course, and reduce the upper limit on the size of your drive, and...

Novel Netware 5.x (1)

yzquxnet (133355) | more than 12 years ago | (#3162009)

The file system that comes with the latest releases of Netware allows you to use that extra space. The file system varies the size of the cluster (or block, I forget what it is) to tailer the filesystem to the data. This way if you have a 5k file on 4k filesystem you may only use 6k instead of 8k because the file system gives the file a 4k and a 2k area to store the file.

Why hide the data when you can use that area and reclaim space. On a big drive it can add up pretty quickly. But still is no massive sum.

Defragmentation (1)

Novus (182265) | more than 12 years ago | (#3162028)

How many BOFHs do you think will start to threaten to defragment users' workstations (using a tool that doesn't do use direct block copying, of course) just to see if they have hidden data on their disks?

Make sure you have the right FS (4, Informative)

mnordstr (472213) | more than 12 years ago | (#3162036)

Just make sure you don't use a smart filesystem like ReiserFS, which can use the slack space for storage. If you try to put something in its slack space you might find yourself a bit lost...

Does not work with ReiserFS (5, Informative)

Anders (395) | more than 12 years ago | (#3162066)

I did not see it mentioned that ReiserFS is able to "pack tails", which means that the ending parts of files that do not fill an entire disk block (typically 4KB) are not stored in their own block. Thereby, it does not waste (on average) 2KB per file.

Actually using the disk blocks seems, to me, more appropriate than hiding stuff in them. There is even work in progress of an ext2 version [linux.org] of this technique.

Nothing new here... move along. (4, Informative)

Zocalo (252965) | more than 12 years ago | (#3162076)

This technique is really *old*. I once had a DOS game that used this to prevent casual copying - the installer was writing additional data into the slack space at the end of it's main executable. There was something similar on the floppy too. I think what it was doing was hashing the data on the floppy with whatever was generated on the HDD, but since I just NOP'ed over the subroutine call, I really didn't need to look too closely. Or require my diskette to play the game for that matter. ;)

Won't hide from raw access (5, Interesting)

redelm (54142) | more than 12 years ago | (#3162085)

File/block slack is hardly news. Nor is it even moderately secure.

One of the first things a forensic analyst will do, mostly in search of deleted blocks is `strings /dev/hda1`. More likely off a ro image, but out everything ASCII will pop.

Have a look at The Coroner's Toolkit [porcupine.org]

Re:Won't hide from raw access (2, Informative)

Stickster (72198) | more than 12 years ago | (#3162129)

On Linux, the chattr(1) command will allow you to set the secure deletion attribute of selected files, so that when deleted their allocated block space is wiped with 0x00 values. It would be trivial for a user to set up aliases or cron jobs to ensure that all this flag is set on all her data.

As for searching slack, there are plenty of Perl scripts to cull for interesting data such as IP's, credit card numbers, and other patterned text.

Re:Won't hide from raw access (1)

redelm (54142) | more than 12 years ago | (#3162246)

Has the `s` flag been implemented in 2.4? My manpage says it wasn't implemented [working] in 2.2 .


*BSD has the -P flag for `rm`, but I don't know if it wipes full blocks, or just the listed filelength.

Re:Won't hide from raw access (4, Interesting)

markmoss (301064) | more than 12 years ago | (#3162397)

Yes, searching the raw data would definitely pop up ASCII strings in the slack space -- and it's quite likely the first thing the FBI would do if it was searching your HD for evidence that, say, you were plotting a terrorist attack on the MPAA, would be to search the entire disk for "MPAA" and "bomb".

So, encrypt it before you hide it in the tail. Make sure the encryption format doesn't have a recognizable header. If you don't want to bother with real encryption, exclusive-OR with 0xAA, and it will look like random leftover binary data, just what would be expected to be left in the slack space. Just don't write how and where you hid it on a sticky note...

Re:Won't hide from raw access (1)

BrokenHalo (565198) | more than 12 years ago | (#3162552)

Thanks for the coroner's handbook link - I hadn't come across this one before, and it's quite good... :-)

someone mod this poster up +n informative...

Mounted dirs (1)

ceeam (39911) | more than 12 years ago | (#3162104)

Storing smth into some dir like /var and then mounting some partition onto it is about as nice, IMHO.

I used to be paranoid.. (5, Interesting)

linuxrunner (225041) | more than 12 years ago | (#3162153)

And I used to encrypt everything... Hide files, secure my boxes with passwords that were ridiculous!!!!

Then..

I had to stop and wonder why I was doing it. No one was writing e-mail to my using my PGP. Even though I made it available on my web site, and sent as attachments to people could e-mail me back using it. No one did.
I bought secure removable media. A chain to keep it on me. And had it encrypted. Now i just keep it in a bag with my laptop and never bother to use it.
My palm pilot has encrypted media.
No ones ever touched it... I just keep it on my desk hooked up to my Linux box for easy syncing...

What's my point.. Do I have one? MAYBE.

I stopped because I was lazy. I didn't have anything to hide, nothing I do is that important that I have to encrypt it. My code is opensource, and my bank info and passwords, etc are kept on my linux laptop, not on a server.

I guess, I'd like to know Who is using constant encryption and why?
For me, Encryption needs to be strong, standard, and integrated, otherwise it's just a pain.

This of this as an e-mail client. Kinda like PGP but easier.
I write an e-mail. I click "send". My e-mail client checks the "encryption" server. It finds a match for the e-mail recipient I'm sending to and downloads the PGP file and encrypts the e-mail to the recipients specifications. I did not have to do anything. If no PGP key is found then it will be sent unencrypted and let you know that it is doing so.

Re:I used to be paranoid.. (3, Insightful)

Sloppy (14984) | more than 12 years ago | (#3162568)

I stopped because I was lazy. I didn't have anything to hide

This is the essential problem. Crypto needs to be easy enough to use, that people who are lazy and have nothing to hide, will still do it anyway by default.

Any programs to zero out this "hidden" data? (0)

Anonymous Coward | more than 12 years ago | (#3162204)

How hard would it be to write?
I'm guessing it's not very difficult.

Another way to hide some files (1)

WetCat (558132) | more than 12 years ago | (#3162223)

Here is another way to hide some files in
Linux, at least temporary...
cp file_to_hide /mnt
mount /dev/hda4 /mnt
ls /mnt
{stuff from hda4}
Almost the same level of protection as in that article...

Re:Another way to hide some files (2)

iamsure (66666) | more than 12 years ago | (#3162437)

In your example, if /mnt was part of the / partition, then df would show that usage.

Thus, the article's example is a little bit better.

The only use for this... (1)

Procrasti (459372) | more than 12 years ago | (#3162230)

The only real use I can see for this is hiding information on someone else's compromised machine...

Great....

I haven't seen anyone mention this... (5, Insightful)

SkyLeach (188871) | more than 12 years ago | (#3162241)

There are several practical problems with this.

First: defragmenting. If you run any utility to defragment your drive, the data will (probably) be lost.

Second: Don't move that file! If you don't know what file space your "secret" data is stored in, then moving, adding, deleting, copying or otherwise altering (editing) any file may destroy some part of your hidden information. Remember that you only have 4k to work with at any given time. This isn't a huge amount of space. You start hiding data all over the place and you quickly start running into this risk.

Third: The govm't and spies aren't stupid. They will have thought of this possibility. In order to implement such file-hiding techniques you would almost certainly need to implement some type of disk partition and format management system on top of the existing one in order to avoid the problems mentioned above. It isn't very hard to search for direct-to-disk calls, and checking the kernel source for partion management against current versions to see if it has been altered is easy too. Unless you hide the source code for your (ext3.01?) filesystem somewhere else or in your hidden system area (pretty hard to do) then the person searching for your data has some pretty clear evidence of where to look for your stuff and how to get at it.

Re:I haven't seen anyone mention this... (3, Insightful)

Sloppy (14984) | more than 12 years ago | (#3162600)

First: defragmenting. If you run any utility to defragment your drive, the data will (probably) be lost.

I wouldn't be too sure about that. I suspect that most defraggers (well, at least a cheesy DOS FAT one that I wrote in the 80s ;-) always move entire blocks, so the data would be preserved. i.e. if a 4k clustersize (DOS terminology) and a 5k file, my defragger would move two 4k clusters instead of having extra code that knows that on second block, only 1k needs to be read and written. I just looked at what clusters were allocated to a file, not what the actual filesize was, in the dirctory.

(I wholeheartedly agree with your other points.)

Re:I haven't seen anyone mention this... (1, Redundant)

Enonu (129798) | more than 12 years ago | (#3162642)

Correct me if I'm wrong (and please give a reference), but doesn't Linux handle files by entire blocks? Thus, defragmenting, copying, moving, and adding to other files should not hurt your own data. For example, here's defragmentation:

before:

[A][B][A-extra][B]

after:
[A][A-extra][B][B]

[A-extra] is the block of data with the additional information hidden.

However, this obviously doesn't hold between partitions or other file systems, e.g. copying a file from ext2f to ntfs.

About the defrag. (1)

SkyLeach (188871) | more than 12 years ago | (#3162723)

The reason I said probably in the first post about the defrag operation is because many (not all, and I have NO IDEA about the ext2/3 code) don't actually read the whole block from the disk if only the first 100 bytes are needed. Still others only write out the actual copied data (100 bytes) to the new block. Thus if you have following possibilities...

[A][B][Afrag-secretstuff][Bfrag-secretstuff]
An d you defragment you could have
[A][Afrag-gargage][Bbfrag-garbage]
either because the defragmenter read only
[Afrag] or [Bfrag] or wrote only [Afrag] or [Bfrag] to the disk.

Now obviously, a defragger which copies only blocks (like the old Win stuff) would not do this.

Use ReiserFS (1)

Mike Greaves (1236) | more than 12 years ago | (#3162433)

...And much of this wasted space is available to the *legitimate* filesystem on the volume...

And "Hiding" is an interesting term here. It's not hidden, if it's not encrypted; and if it's encrypted, why bother with such nonsense...

booooring.... (0)

Anonymous Coward | more than 12 years ago | (#3162735)


viruses have used this trick since the early 80s. tell us something new.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...