# Does someone recognize this “lookup table”? (used for xor encryption)

This table is part of the packet encryption of an old game for which I am developing a server.

The crypto algorithm doesn't just xor the password with the message. It uses a multiple of the ascii value of the letters in the password as an index for this table/array. With the retrieved value, it then does logical and operations which null out most, but not all values.

The result of this is finally xor'ed with the corresponding letter in the message.

I mean the general idea seems nice for a software that was developed 10+ years ago and was mainly a kids game, but I wonder why someone invents such an algorithm an then puts so many zeroes in there.

Is it possible, that this table is in some way a part of a standard library function that was mistakenly used in this context? Or are these just a bunch of random values to mess with someone who is trying to reverse engineer the encryption?

``````20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00
20 00 28 00 28 00 28 00 28 00 28 00 20 00 20 00
20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00
20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00
48 00 10 00 10 00 10 00 10 00 10 00 10 00 10 00
10 00 10 00 10 00 10 00 10 00 10 00 10 00 10 00
84 00 84 00 84 00 84 00 84 00 84 00 84 00 84 00
84 00 84 00 10 00 10 00 10 00 10 00 10 00 10 00
10 00 81 00 81 00 81 00 81 00 81 00 81 00 01 00
01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00
01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00
01 00 01 00 01 00 10 00 10 00 10 00 10 00 10 00
10 00 82 00 82 00 82 00 82 00 82 00 82 00 02 00
02 00 02 00 02 00 02 00 02 00 02 00 02 00 02 00
02 00 02 00 02 00 02 00 02 00 02 00 02 00 02 00
02 00 02 00 02 00 10 00 10 00 10 00 10 00 20 00
``````
• my guess is this restricts the set of characters that is recognized by the algorithm. it looks like ASCII 0-9, A-F, and a-f all have bit four set (0x80). other ranges of printable and non-printable characters seem to have different sets of bits set (punctuation 0x10, uppercase letters 0x01, lowercase letters 0x02, non-printable 0x02, whitespace 0x28). – Willi Ballenthin Mar 25 '18 at 23:41
• Check out the C functions defined in <ctype.h>. – Ian Cook Mar 26 '18 at 5:35

The data appears to be a lookup table to support the functions in the C library header `<ctype.h>`

Specifically, the bit-field values being used here represent, for each character -

``````0x01 => Upper Case
0x02 => Lower Case
0x04 => Digit
0x08 => Space
0x10 => Punctuation
0x20 => Control
0x40 => Blank
0x80 => Hex Digit
``````

These values match those that (at least) the Microsoft C runtime library uses. You can see these defined in the MSVC `<ctype.h>` header.

Other CRT's might use the same, similar (e.g. libc), or different values (e.g. glibc).

• I think the exact file depends on the MSVC/CRT version you are looking at. – Ian Cook Mar 26 '18 at 13:43
• these #defines are in corecrt_wctype.h in w10 includes may be it depends on crt versions grep -h -A 12 -r "#define _UPPER" "c:\Program Files\Windows Kits\10\Include\10.0.16299.0\ucrt" – blabb Mar 26 '18 at 17:16
• With that in mind, some further debugging seems to undermine your answer. I could verify for different passwords, that the algorithm uses only certain characters for the encryption. I guess the original developer tried to add another element of unpredictability through that. – Maurice Döpke Mar 26 '18 at 17:52