This topic was archived here:

https://web.archive.org/web/20230000000000fw_/https://www.zenhax.com/viewtopic.php?t=16445

AlphaTwentyThree, posted Fri Jan 28, 2022 8:44 am (69394)

---

Hello,

I know that Luigi wrote a decrypting tool for Black Hole Studios games for PC. Is there any way to extract the contents of an Xbox 360 version? I mean, the console needs to get the decryption from somewhere. The only other files in the ork folder are a hash file (attached) and the data.xex (encryption key is 3608E31BDC4A064ADE0E9145B2E0EA7E). Also attached the xex info.
Any info on this matter?
Thanks!

aluigi, posted Fri Jan 28, 2022 10:49 am (69400)

---

This is the format of Pack.hsh for extracting all the files from the various ORK archives:

Code:

endian big
for i = 0
    get NAME line
    putarray 0 i NAME
    # open FDSE NAME i
    if NAME & "===="
        break
    endif
next i

get FILES long
for i = 0 < FILES
    get NAME_CRC longlong
    get ORK_NUM long
    get DUMMY long  # maybe some name offset somewhere?
    get SIZE long
    get ZSIZE long
    get OFFSET long
next i

Can you upload the smallest ork just for curiosity?

AlphaTwentyThree, posted Sat Jan 29, 2022 4:32 am (69421)

---

sure, attached

AlphaTwentyThree, posted Sat Jan 29, 2022 5:16 am (69425)

---

Checked it with this script:

Code:

endian big
for i = 0
    get NAME line
    putarray 0 i NAME
    if NAME & "===="
        break
    endif
next i

get FILES long
for i = 0 < FILES
    get NAME_CRC longlong
    get ORK_NUM long
   get DUMMY long  # maybe some name offset somewhere?
    get SIZE long
    get ZSIZE long
    get OFFSET long
   getArray NAME 0 ORK_NUM
   open FDSE NAME 1
   set FSIZE asize 1
   if OFFSET > FSIZE && SIZE != ZSIZE
      print "overshoot"
   endif
next i

It gives me overshoots all over the place. Somehow the ork_num has another connection. I'll investigate a bit. Maybe it has something to do with the first name entry which isn't an ork archive.

Here's a list of the ork archives:

Code:

appendix_xbox.ork
Balance_of_Chaos.ork
Black_Fire_Valley.ork
Blood_on_the_Snow.ork
Caravan_Conflict.ork
Castle_of_the_Gods.ork
Chaos_Chapter_1_Challenge.ork
Chaos_Chapter_1_Collect.ork
Chaos_Chapter_1_Defend.ork
Chaos_Chapter_1_Duel.ork
Chaos_Chapter_1_Relic_Caravan.ork
Chaos_Chapter_1_Tacmap.ork
Chaos_Chapter_1_Village1.ork
Chaos_Chapter_2_Demons.ork
Chaos_Chapter_2_Duel.ork
Chaos_Chapter_2_High_Mage_Castle.ork
Chaos_Chapter_2_Orc_Islands.ork
Chaos_Chapter_2_SkavenHelp.ork
Chaos_Chapter_2_Skaven_Siege.ork
Chaos_Chapter_2_Tacmap.ork
Chaos_Chapter_2_Traditional.ork
Chaos_Chapter_3_Besieged_Fortress.ork
Chaos_Chapter_3_DwarfBarricade.ork
Chaos_Chapter_3_Lighttower.ork
Chaos_Chapter_3_Sudobaal.ork
Chaos_Chapter_3_Tacmap.ork
Chaos_Chapter_3_Thorgar_Transform.ork
Chaos_Chapter_4_BigCannon.ork
Chaos_Chapter_4_Duel.ork
Chaos_Chapter_4_Graveyard.ork
Chaos_Chapter_4_RiverBarricade.ork
Chaos_Chapter_4_Tacmap.ork
Chaos_Chapter_4_Talabheim.ork
Emerge.ork
Empire_Chapter_1_Duel.ork
Empire_Chapter_1_KurtLuiten1.ork
Empire_Chapter_1_OrcGoblinCamp.ork
Empire_Chapter_1_Siege1.ork
Empire_Chapter_1_Tacmap.ork
Empire_Chapter_1_Tower1.ork
Empire_Chapter_1_Village1.ork
Empire_Chapter_2_Besieged_Fortress.ork
Empire_Chapter_2_CollectElves.ork
Empire_Chapter_2_Duel.ork
Empire_Chapter_2_Entrance.ork
Empire_Chapter_2_Reinforcement.ork
Empire_Chapter_2_River1.ork
Empire_Chapter_2_SkavenCaverns1.ork
Empire_Chapter_2_Tacmap.ork
Empire_Chapter_3_Artillery_Support.ork
Empire_Chapter_3_Chaos_Shrine.ork
Empire_Chapter_3_Duel.ork
Empire_Chapter_3_Elf_Defend.ork
Empire_Chapter_3_Siege1.ork
Empire_Chapter_3_Tacmap.ork
Empire_Chapter_3_Vampire.ork
Empire_Chapter_3_WarriorPriest.ork
Empire_Chapter_4_Chaos_Traditional.ork
Empire_Chapter_4_Duel.ork
Empire_Chapter_4_High_Elf_Siege.ork
Empire_Chapter_4_Tacmap.ork
Empire_Chapter_4_Talabheim.ork
Escort_the_Flag.ork
Expansion_Chapter_1_Chaos_Retreat.ork
Expansion_Chapter_1_Defense.ork
Expansion_Chapter_1_Duel.ork
Expansion_Chapter_1_Dwarf_Mountain.ork
Expansion_Chapter_1_Orc_Camp.ork
Expansion_Chapter_1_Orc_Siege_Elf.ork
Expansion_Chapter_1_Tacmap.ork
Expansion_Chapter_2_3rdTower.ork
Expansion_Chapter_2_Ambush.ork
Expansion_Chapter_2_Duel.ork
Expansion_Chapter_2_Escape.ork
Expansion_Chapter_2_Helf_Camp.ork
Expansion_Chapter_2_Slave_Capture.ork
Expansion_Chapter_2_Tacmap.ork
Expansion_Chapter_2_Treasure_Hunt.ork
Expansion_Chapter_3_Aurelion_Tower.ork
Expansion_Chapter_3_Betrayal.ork
Expansion_Chapter_3_Skaven_Canals.ork
Expansion_Chapter_3_Skaven_Passage.ork
Expansion_Chapter_3_Tacmap.ork
Fields_of_Blood_Normal.ork
Fields_of_Blood_Reinf.ork
fx.ork
General_Conflict.ork
gui_tex.ork
Hightower.ork
ire_Chapter_4_Elf_vs_Orc_Traditional.ork
Killing_Fields.ork
menu.ork
music.ork
pansion_Chapter_3_Dark_Elves_vs_Orcs.ork
pansion_Chapter_3_Orcs_vs_Dark_Elves.ork
particle_tex.ork
Prosperity_2teams.ork
Prosperity_ffa.ork
Range.ork
Refill_Conflict.ork
Reinforcement_Conflict.ork
Rivers_of_Fire_and_Ice_Normal.ork
Rivers_of_Fire_and_Ice_Refill.ork
sound.ork
Staged_Arena.ork
Stielstand.ork
Struggle.ork
Swamps_of_Desolation.ork
The_Bone_Field.ork
The_Burning_Slopes.ork
The_Frozen_Plateau.ork
The_Wastes.ork
Two_Hills.ork
Village_in_Squeeze.ork
Watch_over_Ford.ork
work_out.ork
X360Tutorial1.ork
X360Tutorial2.ork
X360Tutorial3.ork
xpansion_Chapter_1_Orc_Help_Commando.ork
xpansion_Chapter_2_Dark_Elf_Crystals.ork

AlphaTwentyThree, posted Sat Jan 29, 2022 6:04 am (69426)

---

A little more investigation: music.ork (#0) is extracted correctly when I add 8 to the offset for compressed files.

btw, how can I get the complete 16-bit CRC into the file name? something like x but for a longlong variable.

aluigi, posted Sat Jan 29, 2022 12:24 pm (69432)

---

I just released the script here:
http://aluigi.org/bms/whbm_hsh_ork.bms

It also answers your question about the 64bit names in quickbms (split them in 2 long and concatenate them with xx)

AlphaTwentyThree, posted Sat Jan 29, 2022 5:04 pm (69449)

---

Hm, something goes awry - only a small percentage of the files get extracted by the hash file. I know that there are only so many entries but when there are only a couple of files extracted from an archive of 40MB, I get a bit suspicious nevertheless...

Take a look at this example:



Here's the corresponding file: https://www.mediafire.com/file/k18bkwqu ... os.7z/file

What could be the cause for that behavior? I don't suspect they used heaps of dead data. Maybe we additionally need to write the data in between the table entries to get everything?

AlphaTwentyThree, posted Sat Jan 29, 2022 5:53 pm (69451)

---

Oh and also I found this list of IDs with corresponding names:



Do those IDs correspond to the longlong value in the TOC in some way? Because if so, the variable should be written as the ID so I can potentially parse the names.

AlphaTwentyThree, posted Sat Jan 29, 2022 6:13 pm (69452)

---

Ok, I think I figured out where the residual data is. The DUMMY variable in the TOC is actually the file number. Music.ork is completely extracted because all numbers are listed. Now, looking at the file from above inside the TOC, you can see that there are a lot of un-indexed files:



No idea where those are stored but maybe one could just dump the data in-between indexed files? I mean yeah, you'd need to write everything into an array, sort and then check for blanks. For clarity, each name should start with the file number of the archive, residual data can be named accordingly. In our case
[ork_name]_0_[CRC]
[ork_name]_1_[CRC]
[ork_name]_2_[CRC]
[ork_name]_3-64_[CRC]
[ork_name]_65_[CRC]
[ork_name]_66_[CRC]
So everything is sorted and can be traced.
I don't know if you still have the energy to get there. If not, just say so and I see what I can do.

aluigi, posted Sat Jan 29, 2022 7:43 pm (69455)

---

I double checked the script again and it's perfect in my opinion.
Every field is correctly parsed.

It's true that 75% of Balance_of_Chaos.ork is not parsed but just because there are no references at all in the index table.
The unreferenced data is valid zlib compressed data and all the offsets at the end like 0x0257a4e1, 0x02594474, 0x025edec4, 0x0262ea58, 0x026399b7 are not available in the index, the last referenced one is 0x0256c66a indeed.

AlphaTwentyThree, posted Sat Jan 29, 2022 7:50 pm (69456)

---

Alright, will get to work with this tomorrow.
My plan is basically to either apply the script on the hsh file and extract the listed entries - or apply it on an ORK archive and extract all its contents.

Shouldn't be too hard to do actually. Will post the updated script here once I'm done.

I'm curious what else is inside those files - maybe unused assets that aren't accessed by the game, maybe beta versions, maybe parts of the development engine even... at this point it could be anything to be honest. I'm excited to dive into this.

aluigi, posted Sun Jan 30, 2022 1:59 am (69463)

---

Script updated for supporting the extraction of the ORK archives you select.
The format was just a simple version of the one in orkdec (probably a key-less version, explaining the zero at the beginning).

Please note that the filenames are different if you select HSH or ORK because in HSH they seem to be 64bit (or if 32 it's a different algo) and in ORK are 32bit crc. Example: 0abec11e7bcaf695 vs 337b76ac

AlphaTwentyThree, posted Sun Jan 30, 2022 5:35 am (69465)

---

Oh! Ok, with your info you had the clear advantage. Thanks for rummaging around in your old programs (and memories for that matter) to bridge the gap between the two platforms! Seems like "Good luck!" was the right thing to say for them - 0x0fbf6a67 is random enough for that.
Will run some tests later to compare the files and see if we somehow missed some info in-between the two approaches.

AlphaTwentyThree, posted Mon Jan 31, 2022 5:53 am (69506)

---

One small correction:

Code:

      if ZSIZE != SIZE
         clog NAME OFFSET ZSIZE SIZE
      else
         log NAME OFFSET ZSIZE
      endif

AlphaTwentyThree, posted Mon Jan 31, 2022 6:21 am (69507)

---

I'd also do this to skip the first 8 bytes and get the correct extension:

Code:

      if ZSIZE != SIZE
         putVarChr MEMORY_FILE SIZE 0
         log MEMORY_FILE 0 0
         clog MEMORY_FILE OFFSET ZSIZE SIZE
         set OFFSET 0x8
         math SIZE -= 0x8
         log NAME OFFSET SIZE MEMORY_FILE
      else
         log NAME OFFSET ZSIZE
      endif

AlphaTwentyThree, posted Mon Jan 31, 2022 6:44 am (69508)

---

Hm, something is strange: sometimes those additional 8 bytes are added, sometimes they are not. Any way to figure that out somehow?

aluigi, posted Mon Jan 31, 2022 8:37 am (69509)

---

I think they are just part of the file if you mean those starting with cf 70 fe ed and having GOBJ at offset 8

I will fix that log/clog part.

AlphaTwentyThree, posted Mon Jan 31, 2022 12:54 pm (69513)

---

Oh ok, that could be of course. Would explain the strange behaviour.
Thanks, I think we're done here finally.