Some days ago, Hugh managed to recover a bunch of files from a ZIP disk. Among the files there was this one special archive file: `VAX.ARC`

. So close, yet so far.
Despite all the efforts Hugh had taken to track down, compile and run the ARC 5.21p tool, the file has blatantly withstood all extraction attempts. After having a closer look at the ARC sources, there was only one reasonable conclusion: The file is encrypted.

Considering the colourful past of the ARC compression tools, there was another minimal chance: A compatibility problem between ARC 5.21p and the version that was used to create the archive. Diving deep into my old archive CDs brought up a handful of tools with support for the ARC format: arca, arce, pkarc, arc - DOS files from the late 80's or early 90's. Firing up DOSBOX and ... you guessed it. All show the same CRC errors as ARC 5.21. A little bit disappointing, but certainly not unexpected.

Ok, the password then. Taking a closer look at the ARC sources reveals that we are facing a repeating XOR encryption. Actually nothing fancy, but the encryption is applied to the packed data. This makes everything a lot harder, because it prevents frequency analysis to a high degree.

The only obvious way open to us seems to be brute-forcing the password. But even considering the simplicity of the algorithm we are probably talking about a substantial time frame. Assuming a password length of at least 7 or 8 chars and the fact that we must verify the passwords through the CRC calculation, we are talking about days if not weeks in the worst case. Plus Hugh has detected some serious inconsistencies aka bugs in ARC 5.21 when he added a brute-force option. We probably can reduce the key space a little bit: An early documentation of ARC suggests that all passwords are converted to uppercase and considering the fact that the user has to enter the passwords via shell and the fact that we are talking about the late 80's, we can assume a password consisting of alphanumeric chars. However, not exactly a giant leap forward.

Sigh, and it looked so promising:

```
alice.tar 9 (Squashed) 474673 1421312 1991-06-23 16:01 4AD7
animator.tar 9 (Squashed) 1013114 2396160 1991-06-23 21:33 69CE
as68.tar 9 (Squashed) 226903 675840 1991-06-23 21:46 C5D8
asasin.tar 9 (Squashed) 506893 1157120 1991-06-23 18:38 F320
dvi2ps.gfx 9 (Squashed) 136691 266240 1991-06-23 21:51 60D5
emu.tar 9 (Squashed) 924620 2211840 1991-06-23 22:33 3CDA
fish.tar 9 (Squashed) 530010 1198080 1991-06-23 18:03 1198
fred23jr.tar 9 (Squashed) 42197 112640 1991-06-23 13:47 A1F6
gfi.tar 9 (Squashed) 149121 296960 1991-06-23 22:38 F339
kermit.tar 4 (Squeezed) 324504 358400 1991-06-23 22:45 45A7
lnk.tar 9 (Squashed) 262342 921600 1991-06-23 22:59 8B24
miscc.tar 9 (Squashed) 31894 81920 1991-06-23 23:01 2633
patch.tar 9 (Squashed) 75587 163840 1991-06-23 23:04 9AB0
rcs.tar 9 (Squashed) 216397 532480 1991-06-23 23:13 7FD8
sps2.tar 9 (Squashed) 76224 188416 1991-06-23 23:16 1585
undump.tar 9 (Squashed) 23259 61440 1991-06-23 23:17 B60C
windows.rcs 2 (Stored) 2593536 2593536 1991-05-13 20:07 DA28
```

But wait, there is one file in the archive that is particularly special:

`windows.rcs 2 (Stored) 2593536 2593536 1991-05-13 20:07 DA28`

It is stored, not packed. This has the original data XOR'ed with the password. We might gain a foothold! To begin with, we extract the encrypted data from the archive. Now we have a WINDOWS.RCS, which is still encrypted, though.

Next we need to go for the password. Saying that we need the password length and the actual password chars. Time for a little statistical probing. For each possible password length we shift our raw data about the password length and XOR it with the original raw data.

```
49 D4 D4 6A A5 81 DE BD D4 84 DF 74
49 D4 D4 6A A5 81 DE BD D4 84 DF 74
49 D4 D4 6A A5 81 DE BD D4 84 DF 74
```

Why would we do that? XOR'ing a value with itself results in zero. a xor a = 0. For each shift we count the number of resulting zeroes. If we have an unusual high number of zeroes we hit a potential password length - or a multiple of it. Counting for passwords up to 16 chars, we get the following numbers:

```
1: 17972
2: 17971
3: 17981
4: 18416
5: 17968
6: 18136
7: 17966
8: 24309
9: 18019
10: 18039
11: 17994
12: 18655
13: 18023
14: 18148
15: 18023
16: 24343
```

See, what we got. The numbers for 8 chars and 16 chars are significantly higher than the other ones. Chances are high, our password has a length of 8 or 16 chars and for the above reasons we assume an 8 char password.

Next we need to go for the actual password. If we assume an 8 char password every 9th byte in the original data is encrypted with the same char. The first char of the password encrypts the bytes 0,8,16,...; the second char encrypts 1,9,17,...; and so on. Time to run a frequency analysis on each of the 8 groups.

But what are we looking for? ARC decided to *store* the file in the archive. This means that WINDOWS.RCS almost certainly contains random binary data. The most frequent byte in a random binary file might likely be 0x00. Let's count and see what we get:

In the first group we have a maximum of 4265 hits for char 86. Now here comes the beautiful part: Remember a xor a = 0? Assuming that the most frequent byte is 0x00, the value 86 would immediately represent the first char of the password: 'V'.

What do we get from the other 7 groups?

```
73 with 1786 hits
68 with 4123 hits
69 with 1901 hits
79 with 4292 hits
77 with 1810 hits
79 with 4266 hits
78 with 1874 hits
```

Saying: `VIDEOMON`

There it is: the moment of truth...
Firing up DOSBOX again.
**We got it!**