Comprehensive NWT Comparison Project (calling all technically skilled members) (page 12)

Apognophos

Good news, MMM, forum member fredPotato has pointed out that the browseable NWT is now the 2013 version! It wasn't long after all.

YAY... I just cracked the DB... I mean just a few minutes ago. Dang, they must have put that out there just today, because I checked earlier. Oh well. I can take it from the web easier. But I can still say that the DB didn't beat me!

Hacking info to follow...

MMM

MeanMrMustard

All,

So it looks like the NWTx2 version is out on the web. Good. I will parse through that very easily now. But interestingly enough, just a few hours after they posted the online NWTx2, I was successful with castthefirststone's method, using the SQLite database. I was actually surprised at the lengths they went to in order to keep someone from just reading the publication text from the database. After my previous posts, I decided to step through the Dalvik java assembly code one line at a time to figure out the logic. I used the OP codes here: http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html.

The top of the Deobfuscator class contains this byte array, 32-bytes:

.array-data 0x1
0xbet
0xeet
0xb8t
0x3bt
0xe3t
0xf0t
0x45t
0xf6t
0x43t
0x1dt
0xe1t
0x2et
0x26t
0xa9t
0xe4t
0x8t
0x2ct
0xc6t
0x74t
0xc2t
0x67t
0x44t
0xadt
0x36t
0x3ft
0xe9t
0xe0t
0xaft
0xd8t
0xb6t
0x8bt
0xf7t
.end array-data

But that is not the secret key for decryption. The AES descryption is 128 bit, it needs a secret key that is 16 bytes (not 32), and an IV (initial vector) that is also 16 bytes. Stepping through the code, here is how they come up with those values.

1. Take the meps language symbol, publication symbol, and the year and create a string separated by underscores: 0_nwt_2013.

2. SHA-256 hash that string into a 32-byte array, same size as the constant array above.

3. Derive the secret decrypt key from XORing the first 16 bytes of the constant array and the SHA key.

4. Derive the IV array from XORing the last 16 bytes of the constant array and the SHA key.

After this is all over, you are presented with a byte array that you need to "inflate" or decompress. For this I used J#, and got ahold of the java Inflator class. The rest of this hack was written in VB.NET.

So here is what you get when its all over:

Here is the VB code:

hmmm, code doesn't work out very well.. let's try images...

Java code for the Inflator object. Compiled to DLL and referenced in VB.NET project:

:)

Apognophos, I will probably get the NWTx2 version from the web later. Still easier.

MMM

Apognophos

Oh man I was going to reply to this when I first saw it last night, but I had a meeting to go to, and all that :-$ I had been wondering if you were quietly hacking away at the database, or if you needed some help. I guess not! I don't have the time to get together a test project right now, but I bet that this works for the WT Library CD-ROM's .PUB files too. Even if this ends up not being used on the Bible, perhaps it could be useful in converting the publications which are found on the Library and are now in public domain (though I don't know how many that might be), for the web sites which like to archive those old publications. Very nice work!

MeanMrMustard

Apognophos,

This is happening now:

MMM

MeanMrMustard

Apognophos,

It would be interesting to know if the PUB files could be read with this method. It is important to note: The WT would have to use, not only the exact same method, but would also have to use the exact same secret keys and initial vector to the AES encryption. Just a single byte change and it would no longer work. Also, after the decrypt, you have to use the right unzip code. The andriod app uses the java Inflator/Deflator (for obvious reasons). But the WTLIB doesn't run in the java virutal machine (unless they changed something!) and so they might be using a different process completely. It would be interesting to see if just the decryption only yields the text.

Actually, I think there is an easier way to get the content out of the WTLIB. It would require getting WTLIB and using the Spy++ app that comes with Visual Studio to examine the window structure. Once you know that you can get the handle (GetWindow() API function) to get the top level window and traverse into the window the WT lib uses for users to traverse the document. Then you can send in clicks and other messages to automate it, and pull the text out of the app directly - with no need to go through the decyption.

MMM

jgnat

I stand in awe.

Simon

Kudos for the hard working figuring all that out !

MeanMrMustard

jgnat and Simon,

Thanks - it was fun believe it or not :) It got me away from the normal development routine.

One thing I noticed, once I started to partse through the text for the verses in NWTx2, they do not spell out numerical figures. An example if this from Genesis 5:15:

1984 version: "And Ma·hal′a·lel lived on for sixty-five years. Then he became father to Ja′red."

2013 version: "Ma·hal′a·lel lived for 65 years and then became father to Ja′red."

MMM

MeanMrMustard

As an update:

I am gathering the text to the NWTx2 version and stumbled upon some issues with John 7 and 8. The portions of chapter 8 (verses 1-11) that are printed in the 1984 version with a warning that they aren't found in some manuscripts are not completely left out in the 2013 version. I didn't expect this and its giving my parser some issues... fixing now.

MMM

Comprehensive NWT Comparison Project (calling all technically skilled members)

Share this