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 ==========================