summaryrefslogtreecommitdiff
path: root/Build/source/libs/zziplib/zziplib-0.13.62/docs/zzip-cryptoid.htm
blob: ee6b120d7f91287b68df2f18da432094c7d04f1c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
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 &lt; r; x++) q[x] ^= xor_value[(y+x)&amp;3];
          return r;
      }
</pre>

</section></section>