MW2 shell screens
Posted: Sat Aug 02, 2008 7:21 am
This is as far as I've come with decoding the MW2 shell screens. Any help with decoding the code bytes is welcome.
The shell screens are stored in database.mw2 as PCX files with
an additional compression/obfuscation layer. The layer has three
types of bytes - control bytes, code bytes and data bytes. Control
bytes consist of two opcodes, each of which is stored in a nibble.
The following opcodes have been identified:
0h: Decode 8 bytes (totally read: 8)
1h: Copy one, decode six (totally read: 7)
2h: Decode two, copy one, decode 4 (totally read: 7)
3h: Copy two, decode four (totally read: 6)
4h: Decode four bytes, copy one, decode two
5h: Copy one, decode two, copy one, decode two (totally read: 6)
6h: Decode two, copy two, decode two (totally read: 6)
7h: Copy three bytes, decode two (totally read: 5)
8h: Decode six, copy one (totally read: 7)
9h: Copy one, decode four, copy one (totally read: 6)
Ah: Decode two, copy one, decode two, copy one (totally read: 6)
Bh: Copy two bytes, decode two, copy one (totally read: 5)
Ch: Decode four bytes, copy two (totally read: 6)
Dh: Copy one byte, decode two, then copy two (totally read: 5)
Eh: Decode two bytes, then copy three (totally read: 5)
Fh: Copy four bytes (totally read: 4)
Decoding takes a pair of code bytes to produce output.
There are two theses about decoding code bytes in the EFA:
1. The code bytes refer to data in input or output by absolute or
relative offset
2. There is a separate dictionary somewhere. It is not known where
that dictionary might preside, nor how it is encoded, but it could be
part of the executable.
Data bytes are simply copied to output. To decode an EFA, start by
analyzing the control byte at offset 4 (always EFh). Fully decoding
an EFA produces a PCX file. The PCX signature from offsets 3 to 12h
can be used as a signature:
00 EF 0A 05 01 08 FC 1F 7F 02 DF FF 01 48 00 48
For lack of another naming source, I derived the file type name EFA
from the signature.
Replacing EFA files in 31st's Database.MW2 with EFA from other
versions demonstrates that all EFA's can be displayed with MW2:31stCC's
algorithm. This proves that all EFA's use an identical compression
algorithm and control bytes. However, replacing an EFA with a PCX does
not work, so MW2 relies on "knowing" the file types, even if it is wrong.
The shell screens are stored in database.mw2 as PCX files with
an additional compression/obfuscation layer. The layer has three
types of bytes - control bytes, code bytes and data bytes. Control
bytes consist of two opcodes, each of which is stored in a nibble.
The following opcodes have been identified:
0h: Decode 8 bytes (totally read: 8)
1h: Copy one, decode six (totally read: 7)
2h: Decode two, copy one, decode 4 (totally read: 7)
3h: Copy two, decode four (totally read: 6)
4h: Decode four bytes, copy one, decode two
5h: Copy one, decode two, copy one, decode two (totally read: 6)
6h: Decode two, copy two, decode two (totally read: 6)
7h: Copy three bytes, decode two (totally read: 5)
8h: Decode six, copy one (totally read: 7)
9h: Copy one, decode four, copy one (totally read: 6)
Ah: Decode two, copy one, decode two, copy one (totally read: 6)
Bh: Copy two bytes, decode two, copy one (totally read: 5)
Ch: Decode four bytes, copy two (totally read: 6)
Dh: Copy one byte, decode two, then copy two (totally read: 5)
Eh: Decode two bytes, then copy three (totally read: 5)
Fh: Copy four bytes (totally read: 4)
Decoding takes a pair of code bytes to produce output.
There are two theses about decoding code bytes in the EFA:
1. The code bytes refer to data in input or output by absolute or
relative offset
2. There is a separate dictionary somewhere. It is not known where
that dictionary might preside, nor how it is encoded, but it could be
part of the executable.
Data bytes are simply copied to output. To decode an EFA, start by
analyzing the control byte at offset 4 (always EFh). Fully decoding
an EFA produces a PCX file. The PCX signature from offsets 3 to 12h
can be used as a signature:
00 EF 0A 05 01 08 FC 1F 7F 02 DF FF 01 48 00 48
For lack of another naming source, I derived the file type name EFA
from the signature.
Replacing EFA files in 31st's Database.MW2 with EFA from other
versions demonstrates that all EFA's can be displayed with MW2:31stCC's
algorithm. This proves that all EFA's use an identical compression
algorithm and control bytes. However, replacing an EFA with a PCX does
not work, so MW2 relies on "knowing" the file types, even if it is wrong.