DETERMINING THE CORRECT OFFSETS OF YOUR OWN KEY-BLOCKS


I haven't figured out how to identify the key-block portion of a Scramdisk container without comparing it to a copy, or clone of itself, that has been refilled with different files; or at least emptied. Here is how to do the compare with both the "Compare" function of SCD, and that of Hexworkshop with copies of the same container:

Using SCD's Compare Function:

1) Drag/copy a container to a separate folder, rename it, and change the contents of this copy by emptying or refilling with different data.

2) Compare both of the containers with the "c" command in SCD; which will display the offset of the first different byte.

Example:(The offset will be displayed in a black DOS window after this command)

     scd c c:\temp\scramble.svl e:\clone.svl 0x5000

The offset displayed with the Compare function will often be around 0x26FF-0x2700, (almost 10kb) but could be smaller or larger by quite a few bytes. The areas up to the point at which they differ are usually your key-blocs, but sometimes a few bytes of the data-portions could be the same; which you'll have to allow for. You don't have to remove the entire key-block with SCD, but to be sure not to go over; make a note of the offset shown in the DOS box, and count backwards for about 20 bytes. Use this new offset in your SCD remove/merge command-line, or with the new masking operation.

Using a hex-editor:

1) Drag/copy a container to a separate folder, rename it, and change the contents of this copy by emptying or refilling with different data.

2) Run SCD at the maximum range of 0x5000 on both (unmounted) containers which will extract their key-blocs along WITH portions of the data sections.

3) Compare both of these extracted 20kb files in a hex-editor, such as HexWorkshop, and note the offset at which they become different. It will often be around 0x26FF-0x2700, (almost 10kb) but could be smaller or larger by quite a few bytes.

The areas up to the point at which they differ are your key-blocks. Make a note of that offset, and use this in your SCD command-line. You don't have to remove the entire thing with SCD, but be sure not to go over.

Note:

For working containers; those that have their contents changed frequently; extra care must be taken not to corrupt the data blocks when extracting or merging the key-block. If you are even ONE byte over into the data portion of your container, your data may be irretreivably gone when the SD.vXd does its encryption run. This also applys to the *.dll that v.302a uses.

If you opt for removing/masking just a portion of the key-block without running Compare with SCD or a hex-editor, you can use the minimum offset: 0x2000, as a safe choice. This will remove/mask enough of any key-block to achieve our goal.

If SCD is only used on cd backups, any offset up to the 0x5000 limit will work; since the volume will be read-only anyway. It will have to be copied to a drive to restore its key-block; and the read-only attribute removed in the "Properties" dialog before the restoration will work. This is ONLY for static (unchanging) volumes. If such a container becomes a working volume on your drive, you should make a clone and determine the correct offsets for its key-block.