You can also keep the
Toolkit in a floppy-sized (or smaller)
Scramdisk container (a "toolbox"); with copies of your
key-blocks, and matching sets of batch-files (*.bat) that are made
to order for each target volume on your hard drive. A small container
like this can be easily "flipped" with the utility "Flip.exe", and
made inoperable until needed; or zipped and flipped with Edxor into
some host-file, such as an *.mp3 to keep it out of view. A second small container should be prepared; to act as a dump. This one can be on, and mounted from, a floppy if you wish or from some obscure folder or steg'd wav-file. This is to keep redundant key-blocks out of view; and is used as a waste-basket. Flip it when it's not being used. The first time you ripped (extracted) your keyblocks, they would be written back to the "toolbox" container (E) on your hard drive that holds the Toolkit and bats. This *.bat ("xmas.bat") would be run from the toolbox container: scd r "C:\program files\movies\xmas.mpg" xmas2.mpg 0x26FF The tools, the ripping *.bat files, and extracted key-blocks would then be in one place. From then on, whenever you MERGE a key-bloc back to a target container, it would come from this working container (E) using a second "merging" bat ("xmas2.bat"); as in this example: scd m "C:\program files\movies\xmas.mpg" xmas2.mpg 0x26FF The first container, then, will be holding the ripping *.bat, the merging *.bat, and the key-block for your target container; as well as the toolkit. In the future,whenever you RIP a keyblock, you also mount the second container from the floppy (or elsewhere) to act as a dump; and the "r" command from "E:\xmas.bat" should be rewritten to redirect the unwanted keyblock to this "dump" container (F) as in: scd r "C:\program files\movies\xmas.mpg" F:xmas2.mpg 0x26FF SCD will not overwrite an existing extracted key-block, so you'll have to clean the dump container after every use, or save them for backups and use a second "dump". You'll have your good key-blocks in the first container, anyway. The first container, the little "toolbox", is relatively easy to hide on removable media, or packed into a host-file with Edxor. Just remember to reboot each time ANY change is made to the actual contents of such a small container, and before moving or copying to other places, or the data will be lost. Once one of these is prepared, and you've rebooted, you're good to go anytime :) SCD does not know if what it is copying out is a key-block or not...it copies out a specific number of bytes to a separate file from the beginning of the container, like from offset 0x0 to 0x2000, holds that in mem, and then copies another set from 0x2001 to 0x4001 which it uses to overwrite the original 0x0 to 0x2000 in a substitution operation...then it writes the original data taken from offsets 0x0 to 0x2000 out to a separate file. It will merge this saved data back, overwriting the dummy data, to restore the container. Be careful not too run the same command twice in a row :) SCD will not tell you if a container has already been modified, so as a general rule, all containers backed up to CD-R should be locked with SCD before burning; and only unlock those containers remaining on your hd when immediate access is necessary. This strategy will be your protection against any type of key-logger. |