summaryrefslogtreecommitdiff
path: root/Build/source/libs/zziplib/zziplib-0.13.62/docs/zzip-cryptoid.htm
diff options
context:
space:
mode:
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.htm106
1 files changed, 0 insertions, 106 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
deleted file mode 100644
index ee6b120d7f9..00000000000
--- a/Build/source/libs/zziplib/zziplib-0.13.62/docs/zzip-cryptoid.htm
+++ /dev/null
@@ -1,106 +0,0 @@
-<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 &lt; r; x++) q[x] ^= xor_value[(y+x)&amp;3];
- return r;
- }
-</pre>
-
-</section></section>