XeNTaX

chrox
the 3 bytes for tmc and 4 bytes for tmcl is not always correct. i do the 4 bytes key, and if the key's "second byte" == "third byte" then i convert this key to a 3 bytes key. this method works fine also for 2 bytes keys. it's not a cure for all files, but this way you don't have to worry about file type.

Hey chrrox.

I tried the Scripts on the DoAU DLC1. All works fine. Just 1 TMC File gives me Trouble:

2R863@1S100@6L1M1I]]K1935AD2F1PQ551A8O{C98191F

BTW: Thanks for the great Tools @ all

>2R863@1S100@6L1M1I]]K1935AD2F1PQ551A8O{C98191F
key is 0x0C6722

Another one:

BV8K3@1S100@D10D1]IB12]H1K1GB5I1QE16B6GN006A2219{PQ1L
BQ161R1@131B@S1]]2J372K42E1QRE1100N10{S65131H
BYA73@1S100@DF1]H]723E21544PQ10310MC121{R72100H

If someone got the intimate dlc, both models are extractable.

b0ny wrote:chrox
the 3 bytes for tmc and 4 bytes for tmcl is not always correct. i do the 4 bytes key, and if the key's "second byte" == "third byte" then i convert this key to a 3 bytes key. this method works fine also for 2 bytes keys. it's not a cure for all files, but this way you don't have to worry about file type.

Can someone explain this in more detail pls

he is explaining what i said not all files use a 3 byte xor key for tmc and a 4 byte xor key for tmcl.
you can test both of these by changing the first letter of the file name from B to 2 or from 2 to B.

chrrox wrote:he is explaining what i said not all files use a 3 byte xor key for tmc and a 4 byte xor key for tmcl.
you can test both of these by changing the first letter of the file name from B to 2 or from 2 to B.

only that??

Lol I tried that before with a tmcl file with little sucess.

Darko wrote:

chrrox wrote:he is explaining what i said not all files use a 3 byte xor key for tmc and a 4 byte xor key for tmcl.
you can test both of these by changing the first letter of the file name from B to 2 or from 2 to B.

only that??

Lol I tried that before with a tmcl file with little sucess.

actually i suggested here how to create a more universal method of creating the key in the bms script, that will work for keys with all lengths. this will not magically fix all the keys that do not work, but will fix some of them.

it's not intended for manual renaming to see if it works.

Does anyone have any suggestions on how to find the alternate texture containers? The --H, --HL ones?

The unpacked versions don't have the uncompressed file size in the head, so locating them in a RAM dump is a bit difficult. I tried both versions of the extractor bms script on a compressed --HL file combined with a RAM dumped --H file. b0ny's extractor dumped dds files, but they were scrambled, so I take it the data in the --HL files was not correct.

Hey guys, I'm trying to follow along with your guys' work, however I'm kind of lost as to where you start. Is everyone using the doa5-lnk-bin.bms file (previously used on DoA5) to extract the initial .dat files, then using the doa5Udecrypt.bms file chrrox had provided on the .dat files? This is what I've done and I've so far only produced .dec files, no .tmc/.tmcl

I'm a little confused because the order of .bms files used was previously, lnk.bms>extract.bms>decrypt.bms

DoA5U Archivarius version 1.4 - (click to download)

this is a tool to unpack files from doa5U lnk archives(the injection won't work and some times decryption key is wrong). you need Python installed to run it.

--
Protocol X27give me the files you have troubles with i'll have a look, when i'll have enough time.

[edit]
i'm trying to figure out why the inflating fails when the key seems to by right. my guess is that they use something else than zlib for deflating, knowing that in doa5u the same files have a much better compression ratio, this could be something like 7zip(and also knowing that 7zip can produce incompatible zip files).

kasake wrote:Hey guys, I'm trying to follow along with your guys' work, however I'm kind of lost as to where you start. Is everyone using the doa5-lnk-bin.bms file (previously used on DoA5) to extract the initial .dat files, then using the doa5Udecrypt.bms file chrrox had provided on the .dat files? This is what I've done and I've so far only produced .dec files, no .tmc/.tmcl

I'm a little confused because the order of .bms files used was previously, lnk.bms>extract.bms>decrypt.bms

Use this 4, one to extrac the lnk or bin file and the other to find out the encyption:

Protocol X27 wrote:Does anyone have any suggestions on how to find the alternate texture containers? The --H, --HL ones?

The unpacked versions don't have the uncompressed file size in the head, so locating them in a RAM dump is a bit difficult. I tried both versions of the extractor bms script on a compressed --HL file combined with a RAM dumped --H file. b0ny's extractor dumped dds files, but they were scrambled, so I take it the data in the --HL files was not correct.

Yep. Use the file below, is a copy of the DOA5U dump made by bony. It's easy, just see what 2 correspond to the tmc you want the texture, copy it's raw name and aste in the notepas++ search tool. Normally it comes a 2, then a B, then again a 2, a 7 and B. The 7 and the B is what you need, bony extractor estracts some of the 7 files and use the bms scripts to decrypt the b's.

DoA5U Archivarius version 1.5 - (still not decrypting all files)

updated with reconstructed names for doa5u dlc's. they added imparity for indexes in dlc files for costumes names and for icons names, i.e. the icon for "helena_dlcu_006" is "helena dlc_016.--P". i wasn't sure what should i do, use the real names or use the index of corresponding costume like "helena dlcu_006.--P" for "helena_dlcu_006".(the real names are used but this is not very convenient).

i need you guys to help me with a detailed tutorial on how to inject in the core "lnk" files, to automatize the process with this tool.

Hmm, Thanks for the updates, guys.

Results seem to be hit or miss. The two in question are a set for Helena's Pop idol costume. Archivarius throws a key generation failed error, and the bms throws an 'incomplete input file'

--H: 7R06S@10T10000@7I1S]]K128L8110RG187H1F1S003O{TA511J71J
--HL: BR06S@10T10000@DI1]T]C128L8110RG9735H1F1S005O{TB511J71J

Anything else I could be missing? If I need to provide data let me know.