Re: Stego-empty hard drives...

[Sunder <sunder@brainlink.com>]

Anonymous wrote:

> Once they realize people are doing this, they will begin taking hashes or
> some other record of the blank space. The next time you are scanned by
> customs, they pull the record and compare the previous "blank"  space with
> the current "blank" space. If they don't match, you're suspect.
> 
> They still cannot prove that you're carrying hidden data. They ask you if
> you know what stego is. They ask you if you have hidden data on your
> drive. If you say yes, they demand to see it. If you say no, they say
> "Okay, then it should be no problem if we push the wipe button on our
> program, should it?"
> 
> If they start doing that they have still won, because now you are not
> carrying the data across the border or the data is destroyed as you cross
> the border.

What's this bullshit, eh?  Just overwrite the BIOS roms in your machine to
return all zeros for the sectors you don't want to show them.  Have some
special passphrase you have to type in while in the BIOS setup program to
deactivate this.  Most newer notebooks have flash upgradeable ROMs anyway.

Better yet, simply have it report a drive size that's much smaller than what
you really have.  i.e. install a 4gb drive, but have the bios only see it as a
1gb disk.  When software tries to read or write beyond the 1gb space, have it
return errors like a real disk would.

Anyone who knows x86 assembly can do this sort of shit.  If you want to get
real wicked on this or are afraid they'll have software that talks directly to
the IDE controller, take apart the disk controller card on the drive itself
and give it this type of functionality (much harder.)  Hell, even if they
switch to taking out your hard drive out of your notebook and duplicating it,
as long as the HD itself reports LESS space than it really has, they can't get
to it, they can't scan it, they can't copy it, they can't overwrite it.

Don't want to do that or can't?  Okay, boot their software in a Virtual CPU
box, and if they try to access I/O directly, have your code intercept and
emulate the access.  They try to run privilidged opcodes, trap'em and make it
look like they're running fine, etc...

Let's get this nice and clear once and for all: Software running on untrusted
(i.e. your notebook) hardware cannot be trusted as it can be fooled and
modified by it.  It doesn't matter how sophisticated their scanning software is
as long as the hardware DOESN'T COMPLY with it's requests.  Software always
asks the hardware to do things for it.  The hardware doesn't have to obey. :)

The solution to getting around this bullshit is in hardware or firmware.

I will ignore Anon's idiotic idea of them comparing blank space before and
after.  That's stupid for one of several very obvious reason: temp files.  If
that's not clear enough, here's another: defrag.

-- 

=====================================Kaos=Keraunos=Kybernetos==============
.+.^.+.|       Sunder       |Prying open my 3rd eye.  So good to see |./|\.
..\|/..|sunder@sundernet.com|you once again. I thought you were      |/\|/\
<--*-->| ------------------ |hiding, and you thought that I had run  |\/|\/
../|\..| "A toast to Odin,  |away chasing the tail of dogma. I opened|.\|/.
.+.v.+.|God of screwdrivers"|my eye and there we were....            |.....
======================= http://www.sundernet.com ==========================