From: Guido Draheim Date: Tue, 11 May 2004 17:25:22 +0000 (+0000) Subject: describing zzip-cryptoid handling X-Git-Tag: v0.13.36 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=8e5a55ba8f8f42bcb68536944aa5ffda5e286eaa;p=zziplib describing zzip-cryptoid handling () --- diff --git a/ChangeLog b/ChangeLog index d5f2285..4aa6b67 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,6 @@ +2004-05-11 + * documenting zzip-cryptoid handling + 2004-05-09 * documenting zzipmmapped and zzipfseeko parser libraries diff --git a/docs/Makefile.am b/docs/Makefile.am index 5c7608f..f3d9e70 100644 --- a/docs/Makefile.am +++ b/docs/Makefile.am @@ -4,7 +4,7 @@ AUTOTOOL_VERSION=autoconf-2.52 automake-1.5 libtool-1.4.2 doc_FILES = README.MSVC6 README.SDL COPYING.MPL COPYING.LIB COPYING.ZLIB \ zziplib.html htm_FILES = zzip-index.htm zzip-zip.htm zzip-file.htm zzip-sdl-rwops.htm \ - zzip-extio.htm zzip-xor.htm zzip-crypt.htm \ + zzip-extio.htm zzip-xor.htm zzip-crypt.htm zzip-cryptoid.htm \ zzip-api.htm zzip-basics.htm zzip-extras.htm zzip-parse.htm \ 64on32.htm future.htm fseeko.htm mmapped.htm \ configs.htm sfx-make.htm \ diff --git a/docs/Makefile.in b/docs/Makefile.in index ab35d9b..39566ca 100644 --- a/docs/Makefile.in +++ b/docs/Makefile.in @@ -156,9 +156,10 @@ doc_FILES = README.MSVC6 README.SDL COPYING.MPL COPYING.LIB COPYING.ZLIB \ zziplib.html htm_FILES = zzip-index.htm zzip-zip.htm zzip-file.htm zzip-sdl-rwops.htm \ - zzip-extio.htm zzip-xor.htm zzip-crypt.htm \ + zzip-extio.htm zzip-xor.htm zzip-crypt.htm zzip-cryptoid.htm \ zzip-api.htm zzip-basics.htm zzip-extras.htm zzip-parse.htm \ - 64on32.htm future.htm configs.htm sfx-make.htm \ + 64on32.htm future.htm fseeko.htm mmapped.htm \ + configs.htm sfx-make.htm \ history.htm referentials.htm copying.htm SDL_RWOPS = $(SDL)/SDL_rwops_zzcat.c \ diff --git a/docs/body.htm b/docs/body.htm index 110dcf0..16210e6 100644 --- a/docs/body.htm +++ b/docs/body.htm @@ -34,6 +34,7 @@
- ext/io Customization
<> xor/io Obfuscation
<> zip/no Encryption +(2)
- Library API
<> basics <> extras diff --git a/docs/zzip-crypt.htm b/docs/zzip-crypt.htm index 99599aa..34151ab 100644 --- a/docs/zzip-crypt.htm +++ b/docs/zzip-crypt.htm @@ -1,4 +1,4 @@ -

ZIP Encryption

Standard Zip Encryption is Weak. +

ZIP Std Encryption

Standard Zip Encryption is Weak! 15. July 2002 @@ -9,23 +9,27 @@ first of all the standard zip-encryption has not been strong enough for modern computers, and there are hacker tools that even a half-literate computer-user can use to crack the password of a - zip-archive. Furthermore, adding real encryption is a heavy weight + zip-archive. In other words: every encrypted zip file can be + cracked using freely downloadable helper tools . That's because + standard zip encryption is weak regarding modern personal computer + power. Furthermore, adding real encryption is a heavy weight that many people do not need, see the last argument for seeing the standard one is useless anyway, and adding a non-standard one should not be the case of the standard zziplib either, ye know.

On the other hand, obfuscation is a means to fear off half-literates - just as well - there are no premade tools for the obfuscation you + just as well - there are no premade tools for the obfuscation you can invent from the xor examples. And a hacker that can de-obfuscate - such a dat-file is able to dissassemble your program as well thereby - going to see your decryption routine and the decryption key. - Although there is a difference, it just ranges on about times and - exprience, not magnitudes. Remember the old saying: you can irritate + such a dat-file is able to dissassemble your program as well - just to + remind you that the disassembly of a program will reveal the decryption + routine and the decryption key, even for a heavyweight crypt + algorithm. Although there is a difference, it just ranges on about times + and exprience, not magnitudes. Remember the old saying: you can irritate some people for some time but not irritate all people for all the time. As for encryption of artwork and AI scripts in games and applications, just keep in mind that the final recipient has the decryption key on his system anyway, just obfuscated. So each such encryption is nothing - more than just a clever form of obfuscation, nothing mathemetical strong. + more than just a clever form of obfuscation, nothing mathematical strong.

Some other people might ask why to obfuscate anyway. Well, the reason is theft. Even people who write opensource free software generally diff --git a/docs/zzip-cryptoid.htm b/docs/zzip-cryptoid.htm new file mode 100644 index 0000000..072deac --- /dev/null +++ b/docs/zzip-cryptoid.htm @@ -0,0 +1,102 @@ +

ZIP Ext Encryption

ext/io used for cryptoid plugins + + 11. May 2004 + +

Stronger Obfuscation For ZZip

+ +

+ 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 + reasoning page why it can not be + real encryption and that the resulting obfuscation has an upper + limit being lower than the crypt routine complexity. +

+ +

+ 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. +

+ +

+ 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). +

+

+ 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 exactly 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. +
And btw, the abbreviation "posix" stands for + "Portable Open System in Unix". +

+ +

+ 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. +

+

+ 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: +
#define tell(fd) lseek(fd,0,SEEK_CUR) +

+ +

+ 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. +

+

+ 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. +

+ +
+      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;
+      }
+
+ diff --git a/docs/zzip-xor.htm b/docs/zzip-xor.htm index 8478455..7f91a0e 100644 --- a/docs/zzip-xor.htm +++ b/docs/zzip-xor.htm @@ -23,7 +23,7 @@ static zzip_ssize_t xor_read (int f, void* p, zzip_size_t l) { zzip_size_t r = read(f, p, l); - zzip_size_t i; char* q = p; + zzip_size_t x; char* q = p; for (x=0; x < r; x++) q[x] ^= xor_value; return r; } diff --git a/zziplib.spec b/zziplib.spec index 9bf4ca9..16491a8 100644 --- a/zziplib.spec +++ b/zziplib.spec @@ -1,7 +1,7 @@ %define lib lib010 Summary: ZZipLib - libZ-based ZIP-access Library Name: zziplib -Version: 0.13.36 +Version: 0.13.37 Release: 1mdk Serial: 1 Copyright: LGPL