0

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
2
  • 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). Mar 25, 2018 at 23:41
  • 2
    Check out the C functions defined in <ctype.h>.
    – Ian Cook
    Mar 26, 2018 at 5:35

1 Answer 1

2

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

3
  • 1
    I think the exact file depends on the MSVC/CRT version you are looking at.
    – Ian Cook
    Mar 26, 2018 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, 2018 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. Mar 26, 2018 at 17:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.