diff options
Diffstat (limited to 'Build/source/libs/zziplib/zziplib-0.13.62/docs/zzip-cryptoid.htm')
-rw-r--r-- | Build/source/libs/zziplib/zziplib-0.13.62/docs/zzip-cryptoid.htm | 106 |
1 files changed, 106 insertions, 0 deletions
diff --git a/Build/source/libs/zziplib/zziplib-0.13.62/docs/zzip-cryptoid.htm b/Build/source/libs/zziplib/zziplib-0.13.62/docs/zzip-cryptoid.htm new file mode 100644 index 00000000000..ee6b120d7f9 --- /dev/null +++ b/Build/source/libs/zziplib/zziplib-0.13.62/docs/zzip-cryptoid.htm @@ -0,0 +1,106 @@ +<section> <date> 11. May 2004 </date> +<h2> ZIP Ext Encryption </h2> ext/io used for cryptoid plugins + +<!--border--> + +<section> +<h3> Stronger Obfuscation For ZZip </h3> + +<P> + Some people feel that a simple bytewise xor is not strong enough + as an obfuscation for the data. There we have the question how to + implant a stronger obfuscation routine to protect that data of an + application from artwork theft. Perhaps there is even the idea to + use an obfuscation in the range of a real crypt routine - in which + case I want to recommend strongly to read the + <a href="zzip-crypt.html"> reasoning page </a> why it can not be + real encryption and that the resulting obfuscation has an upper + limit being <em>lower</em> than the crypt routine complexity. +</P> + +<P> + After reminding you of this fact we can go at evaluationg how to + implant a stronger obfusction routine to protect your data. The + ext/io feature uses a callback routine "read" that must read a + block of the given size - for the obfuscation case it will call + the "read()" function of the underlying operation system, and + the obfuscated block will be deobfuscated before returning it to + the caller. +</P> + +<P> + In this mechanism there is not asseration at which file-offset + the ext/io-read() callback is triggered. That is the reason we + have shown obfuscation with bytewise xor-key example - formally + this is using obfuscation blocks of 8bit width being aligned + on 8bit boundaries in the data file, and our decryption stream + is stateless being the same for each obfuscation block (of 8bit + width). +</P> +<P> + In order for a stronger obfuscation we have to break those + limitations which are directly derived from the natural way + of the handling of files by a contemporary operating system. + This is triggered as the call synopsis of the ext/io read() + callback matches <em>exactly</em> the one of posix, so that + one can use the posix read() function reference as the default + for ensuring the most minimal overhead in accessing non-obfuscated + zip files. +<br><small>And btw, the abbreviation "posix" stands for + "Portable Open System in Unix".</small> +</P> + +<P> + The trick we show here: the first argument of the ext/io read + callback is the file descriptor of the underlying operationg + system. While we can not add another argument to the ext/io + read call we can pick up additional information with the help + of that file descriptor id being globally unique even across + multiple threads. One solution would make the application map + that descriptor id to a special argument but this is often too + much overhead: the current file position is enough. +</P> +<P> + The current file position is managed by the operation system + via the file descriptor table. There is a function call to + map a file descriptor to the current read position offset + usually named "tell(fd)". Since this call is not mandated by + posix, you can emulate it with the posix lseek() call which + returns the resulting offset after the operation was performed, + so we just seek by a zero offset: <br><code> + <> <> <> <> #define tell(fd) lseek(fd,0,SEEK_CUR) +</code> +</P> + +<P> + That file offset is measured from the start of the zip archive, + not per each zipped file. Remind yourself of that fact when + creating your own "zzobfuscate.exe" which should work on the + zip archive and not per file before zipping. That is a difference + over normal zip archives where the user can atleast recognized the + dat file as a zip archive and see a list of files contained in the + archive, atleast their names and data start offset. +</P> +<P> + Now, let's use the file read offset to break the blocking + limitations of 8bit/8bit to a larger xor-key. In our example + we expand to a 32bit/32bit xor-key giving a search space of + 4<>billion keys instead of the just 256<>keys in 8bit blocking. + That is simply done by a static 4<>byte xor-key sequence and using + modulo operations for alignment. For the 2^X cases any modulo + operations shrink to a set of ultra-fast bitwise-and operations. +</P> + +<pre> + static char xor_value[4] = { 0x55, 0x63, 0x27, 0x31 }; + static zzip_ssize_t xor_read (int f, void* p, zzip_size_t l) + { + zzip_off_t y = tell(f); + zzip_size_t r = read(f, p, l); + zzip_size_t x; char* q = p; + for (x=0; x < r; x++) q[x] ^= xor_value[(y+x)&3]; + return r; + } +</pre> + +</section></section> |