bit-twiddler
n3wb
- Joined
- Jul 6, 2015
- Messages
- 13
- Reaction score
- 4
I am sorry if this information has been covered in the past, but I decided to take crack at figuring out the encoding scheme for digicap.dav after playing around with hiktools last night. I figured that I would start by looking to see if the author was using an XOR-based encoding scheme. I used XOR-based encoding algorithms to obfuscate static data as well as code in some of the products that I developed earlier in my career. An XOR-based encoder does not stop a determined hacker or competitor from reverse engineering one's code, but it does make the task painful enough that the less determined move onto easier to crack puzzles. The beauty of XOR is that it is symmetrical, that is, if we perform the operation A = B XOR C , then we can recover B by XORing C with A. XOR encoding/decoding is very fast.
Here's what I obtained by XORing the first 40 bytes of the digicap.dav file in the Chinese 5.3 to English 5.2.5 downgrader package with the values returned by hiktools.
BA CD BC FE D6 CA DD D3 BA B9 A3 AB BF CB B5 BE CD BC FE D6 CA DD D3 BA B9 A3 AB BF CB B5 BE BA BC FE D6 CA
Now, what we are hoping to find in this string are repeats. The places where the string repeats tells us something about the length of an XOR encoder's seed value.
BA CD BC FE D6 CA DD D3 BA B9 A3 AB BF CB B5
BE CD BC FE D6 CA DD D3 BA B9 A3 AB BF CB B5
BE BA BC FE D6 CA
As one can clearly see, we start to obtain a repeating pattern after 15 bytes; hence, we know that we are a) dealing with an XOR encoder, and b) the first 15 bytes are part of the encoder's seed value (a.k.a. the key). If we examine the second line above, we discover that it differs in one place when compared with the line above it; namely, the first byte, and the difference is 0x04. That's another key to the algorithm. The first six bytes of the third string differ from the second string in the second byte. If I did not make a data entry error, this pattern tells me that we may be dealing with an encoder that is modifying the key using a shift plus XOR or AND/OR modifier that is folding in bits from some other source. If we XOR all of the header bytes in the raw data with the decoded bytes, the XOR encoding algorithm should reveal itself.
Stay tuned...
Here's what I obtained by XORing the first 40 bytes of the digicap.dav file in the Chinese 5.3 to English 5.2.5 downgrader package with the values returned by hiktools.
BA CD BC FE D6 CA DD D3 BA B9 A3 AB BF CB B5 BE CD BC FE D6 CA DD D3 BA B9 A3 AB BF CB B5 BE BA BC FE D6 CA
Now, what we are hoping to find in this string are repeats. The places where the string repeats tells us something about the length of an XOR encoder's seed value.
BA CD BC FE D6 CA DD D3 BA B9 A3 AB BF CB B5
BE CD BC FE D6 CA DD D3 BA B9 A3 AB BF CB B5
BE BA BC FE D6 CA
As one can clearly see, we start to obtain a repeating pattern after 15 bytes; hence, we know that we are a) dealing with an XOR encoder, and b) the first 15 bytes are part of the encoder's seed value (a.k.a. the key). If we examine the second line above, we discover that it differs in one place when compared with the line above it; namely, the first byte, and the difference is 0x04. That's another key to the algorithm. The first six bytes of the third string differ from the second string in the second byte. If I did not make a data entry error, this pattern tells me that we may be dealing with an encoder that is modifying the key using a shift plus XOR or AND/OR modifier that is folding in bits from some other source. If we XOR all of the header bytes in the raw data with the decoded bytes, the XOR encoding algorithm should reveal itself.
Stay tuned...
Last edited by a moderator: