[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Stego-empty hard drives... (fwd)
Jim Choate wrote:
> The point is that this is a weak approach with a variety of attacks open.
All stego methods are weak approaches at hiding data. The point is to hide the
fact that there is hidden data and make it look like the notebook is a
perfectly normal unmodified notebook. There's no perfect stego method that
cannot be detected by a determined analyzer. You can hide all the data you
want in the low bits, but they naturally have biases (low entropy) that if not
present indicates stego (which has high entropy.)
> When one considers the amount of work required to collect BIOS'ed , reverse
> engineer them (unless you got lots of mullah), develop the crypto,
> develop the camouflage code, distribute the code, burn the ROM's, distribute
> the ROM's, cost of suitable TEMPEST monitors, etc. the benefit seems
> questionable at best.
Who the fuck is gonna run a tempest scanner on your notebook again? Let's
stick to the scope of this: UK scans of your notebook using bootable floppies.
And tell me, if you were to modify your BIOS to get around this, WHY would you
need a tempest monitor?
Why would you need to collect BIOSes? You only need to modify a single BIOS -
the one on >YOUR< notebook. The camouflage code would be a few hundred bytes
at most unless you do something overly elaborate.
An EEPROM burner (which for flash upgradeable notebooks isn't needed) is fairly
cheap. JDR sold them for about $200 or less. For flashable BIOSes this is
FREE!
Disassemblers (debuggers) are fairly cheap. DOS and WIN95 come with a simple
one called debug. BIOSes run in 16 bit mode since booting requires that PC's
run in 16 bit mode and there are plenty of books and info on 16 bit x86
programming. You don't need to disasemble everything in the BIOS, you just
need to disable the checksum routine the bios uses on itself, and you need to
slightly modify the place that detects the size of the IDE drive to not go
beyond a certain number of pointers.
Further, PC bioses do support BIOS extensions, you generally wouldn't need to
modify the existing BIOS very much at all. If you can add a BIOS extension,
the existing BIOS will happily run code from it. This is how SCSI adapters
provide booting capabilities from SCSI disks. Of course it's a bit harder in a
notebook computer, but it too can be done.
Back in the days of the Commodore 64 which had only mono sound, it was fairly
comon to piggy back and solder a second sound chip on top of the existing one
with the exception of a few of the pins, and turn your C64 into a stero
machine. (One of the pins was an address pin, the other were sound out.) A
similar thing might be done with an EEPROM.
The way BIOSes work is that they can be set to either detect the IDE drive size
always, or just once. Set them to NOT detect. They store the drive type
(0-47) and size params in the battery backed up CMOS.
An easy, but less effective thing to do is to simply write over the CMOS data
that says X cylinders, Y heads, Z sectors/track, and modify the partition table
a bit. You can do both from DEBUG. You'll have to write a tiny bit of
assembly, but not much.
But again, if they bypass the BIOS and talk directly to the IDE controller,
none of these techniques - short of modifying the IDE controller or drive,
won't work.
> Even if they can't crack it in may places (eg France) such actions would
> be prosecutable in and of themselves.
You forgot to say "If you get caught." :) With successful stego, nobody other
than the owner knows that it's there.
If you visit France and have a notebook computer, expect the Ministry of
Whatever to sneak in your hotel room when you're not there and copy your
notebook's hard drive anyway. Such things have been reported as industrial
espionage. (Talk to the folks on the spyking list about getting refrences.)
One thing all you fine folks are forgetting is that there are MANY MANY types
of notebooks out there. My money says that if they can't scan Mac's they also
won't be able to scan Sparc books, Alpha Books, Newtons, Palm Pilots, and many
WinCE palmtops either. Just buy something exotic.
You don't need to over engineer this, keep in mind: what they're using are
use-once floppies which are discarded. A floppy at most holds 1.7Mb of code.
This code is used to SCAN your disk for contraband. I don't know what they
scan for, but they aren't going to be able to fit decoders for EVERY type of
file system and every file format out there.
So far the viable non-bullshit, non-fictional solutions in order of ease of
implementations.
0. Don't go to the UK with a notebook computer.
1. Use FedEx.
2. Store the data on some other form of media (PC card disks, CD's, books, etc)
3. Use a non PC notebook that they can't scan, or one that can't use floppies
or PCMCIA floppy drives in case they've got some around.
4. Modify the CMOS values in your notebook and your parition table.
5. Modify your BIOS to report a smaller disk
6. Same as 5 but prevent writes to the hidden space.
7. Have your BIOS not boot from floppies and boot only from the hard disk
but make it look like it's booting normally, then run some sort of sandbox
or emulator and let their software run under your code's control.
8. Modify your IDE controller or the controller card on the disk.
I say choice 0 is the best choice. :^) Can we end this noisy thread or are
there other bright ideas?
--
=====================================Kaos=Keraunos=Kybernetos==============
.+.^.+.| Sunder |Prying open my 3rd eye. So good to see |./|\.
..\|/..|[email protected]|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 ==========================