shane007 发表于 2009-6-11 20:21

【汉化资料】通用解包器制作工具QuickBMS图文教程2

ok so set up our c:\temp directory bye extracting our file BoneObject.hsp
1. to c:\temp
2. create a new text document called astro.bms
3. and place the newest version of quickbms in the folder also.

Ok so open up BoneObject.hsp in your hex editor and lets take a look at it.

good we have some plain text.
you will notice I highlighted the first 4 bytes 20 50 53 48 or " PSH" that is a space followed bye P S H.
hmm that seems familiar that is the file extension only backwards. this is know as the idstring
so up until now you would think to write in bms
get IDSTRING long
there is nothing wrong with that but there is a better command
idstring " PSH"
make sure you include the quotes.
so open your bms string and on the first line type
idstring " PSH"
the reason this command is better is it will tell the program not to run if it does not find that string don't try to extract that file.
"aka noob proofing it"

Ok so now lets look at what we can read I see
Datas\Texture\BoneObject\npc_nagoya_octopus01_body.dds , Datas\Texture\BoneObject\Toon.bmp , Datas\Texture\BoneObject\Toon_a.bmp , Datas\Texture\BoneObject\Toon_zero.bmp
so I will assume there are 4 files in this archive.
well lets look at the next 4 bytes and see what it is 01 00 00 00 hmm that is equal to 00 00 00 01 or 1 and we have more files in this archive than that so we do not know what this represents
so lets write that in bms language
get UNK1 long
this saves those 4 bytes as the variable UNK1.

ok the next 4 bytes are 04 00 00 00 hmm this translates into 00 00 00 04 or 4
hey that is the number of files we counted so lets write that in bms
get FILES long
this saves those 4 bytes as the variable FILES.

the next 4 bytes are 00 00 00 00 well that is equal to zero so for now I will write that in bms
get NULL1 long
this saves those 4 bytes as the variable NULL1

ok now we have reached the first file name Datas\Texture\BoneObject\npc_nagoya_octopus01_body.dds
this is 0x36 bytes long but wait there was no indicator like the last file that told us how long the name is how do we write this?
well lets look for a pattern
Datas\Texture\BoneObject\npc_nagoya_octopus01_body.dds is 0x36
Datas\Texture\BoneObject\Toon.bmp is 0x21
Datas\Texture\BoneObject\Toon_a.bmp is 0x23
Datas\Texture\BoneObject\Toon_zero.bmp is 0x26
hmm I don't see anything that makes that a pattern.
but I do see all the names are followed bye a lot of zero's. how long is the name + the zeros of each file?
Datas\Texture\BoneObject\npc_nagoya_octopus01_body.dds + 0's is 0x80
Datas\Texture\BoneObject\Toon.bmp + 0's is 0x80
Datas\Texture\BoneObject\Toon_a.bmp + 0's is 0x80
Datas\Texture\BoneObject\Toon_zero.bmp + 0's is 0x80
hey they are all the same size when I include the 0's
so in bms I would write this as
getdstring NAME 0x80
this tells it to grab 0x80 bytes and store the text value of it
and as an added feature it will automatically remove trailing 0's

ok so now we have 0xC bytes before I see the next file name
which is 3 long values
so lets write those in and we will figure out what they represent later.
get UNK2 long
get UNK3 long
get UNK4 long

ok so now we see the name again
we have our pattern so lets write our script based on what we learned
so it would look like this up until now

Code:
idstring " PSH"
get UNK1 long
get FILES long
get NULL1 long
for i = 0 < FILES
getdstring NAME 0x80
get UNK2 long
get UNK3 long
get UNK4 long
clog NAME OFFSET ZSIZE SIZE
next i


ok this may look complex but it is almost identical to the first tutorial file except we added 1 more variable
ZSIZE this represents the compressed file size while SIZE represents the decompressed file size
and we also changed the log command to clog to represent it is a compressed file.

ok so now we have our loop and the commands to extract our files but we still need to fill in the variables
OFFSET ZSIZE SIZE
so that means our 3 unknown values must represent that but how do we know what order they are in?

Well ill let you in on a cool trick follow the file loop to the end start at Datas\Texture\BoneObject\npc_nagoya_octopus01_body.dds and highlight the whole 0x80 length
then add our 3 unknown variables so that means we are highlighting 0x8C for our length. the first file is from 0x10 - 0x9B
so now do this for the rest of the files and you end up at highlighting 0x1B4 - 0x23F

ok so we reached the end of our loop now what?
well the next 2 bytes are 78 9C and this is an archive extractors best friend when you see this at the start of a file.
78 9C represents the standard zlib compression header
ok so this means our first file starts there which is at offset 0x240

well lets go back to our first file in the list and look at those unknown variables.
24 72 00 00 is = 00 00 72 24 = 0x7224
80 00 02 00 is = 00 02 00 80 = 0x20080
40 02 00 00 is = 00 00 02 40 = 0x240
I think we have a winner so the third variable is 0x240 aka the offset
so lets update our script


Code:
idstring " PSH"
get UNK1 long
get FILES long
get NULL1 long
for i = 0 < FILES
getdstring NAME 0x80
get UNK2 long
get UNK3 long
get OFFSET long
clog NAME OFFSET ZSIZE SIZE
next i


now that just leaves ZSIZE and SIZE
well bye process of elimination the decompressed file must be bigger than the compressed file so we compare the 2 variables
24 72 00 00 is = 00 00 72 24 = 0x7224
80 00 02 00 is = 00 02 00 80 = 0x20080
well 0x20080 is definitely bigger so we now know the last 2 variables


Code:
idstring " PSH"
get UNK1 long
get FILES long
get NULL1 long
for i = 0 < FILES
getdstring NAME 0x80
get ZSIZE long
get SIZE long
get OFFSET long
clog NAME OFFSET ZSIZE SIZE
next i


now try our code out on the file
open the command prompt and change to the directory
c:\temp
now type
quickbms.exe -l astro.bms BoneObject.hsp .
yay it listed our files without any errors now lets try extracting them
create a folder called extract
and type
quickbms.exe astro.bms BoneObject.hsp extract
if we look in there we now have folders and in those folders are 4 pictures
we did it.

Let me know if you want more pictures or any way I can improve the tutorials.


Last edited by chrrox on Tue Jun 09, 2009 2:33 pm, edited 1 time in total.

aliangcn 发表于 2011-5-29 19:15

要是大大能把QuickBMS的帮助翻译一下就好了

herojimmy 发表于 2009-9-9 21:53

cool turotials ,thx!

深绿 发表于 2009-10-7 21:48

应群里朋友之请,翻译了一下这篇教程,不是完全照翻的,后面差不多是自己rewrite了,希望会有帮助
——————————————————————————————
建立一个目录C:\\temp来放我们解包出的文件

1,进入C:\\temp文件夹
2,建立一个新文件 astro.bms(QuickBMS解包脚本)
3,把最新版的quickbms也放到这个文件夹

现在,用你的十六进制编辑器打开BoneObject.hsp,来好好观察一下
(图)

很好,我们看到了一些清楚的文字

你会注意到最开始4个字节20 50 53 48,是空格跟上PSH
看起来就是文件后缀名的反向排列

这被称为idstring(标识字串)
所以,现在在脚本里写上一句

get IDSTRING long       (将四个字节(long)存为IDSTRING)

这没什么错误,不过我们有一条更好的指令

idstring " PSH"      

确保你没漏掉引号。

这条指令更好是因为你可以告诉程序,如果没有在开头找到这个标识符,那么就不要解包这个文件。

之后继续观察文件,我们可以看到
Datas\\Texture\\BoneObject\\npc_nagoya_octopus01_body.dds , Datas\\Texture\\BoneObject\\Toon.bmp , Datas\\Texture\\BoneObject\\Toon_a.bmp , Datas\\Texture\\BoneObject\\Toon_zero.bmp
所以我假设有4个文件在这个包里。

ok,回到开头标识符,接下来看之后的四个字节,是01 00 00 00,那等于00 00 00 01或者1,文件数量比这要多,所以我们不明白这代表什么

那么我们在脚本里写这么一句

get UNK1 long
这句指令把4个字节存为变量UNK1

ok,之后四个字节是04 00 00 00,就是00 00 00 04或者4
这就是包里的文件数量,所以我们在脚本里写这么一句:

get FILES long
这一句把4个字节存为变量FILES

之后四个字节是00 00 00 00,嗯,那就代表0
于是我们这么写

get NULL1 long
把这四个字节存为变量 NULL1

好了,现在我们到达了第一个文件的文件名部分
Datas\\Texture\\BoneObject\\npc_nagoya_octopus01_body.dds
这个字串的长度是0x36,不过等等,这儿没有一个标示符告诉我们文件名的长度,那么我们该怎么写脚本呢?

well,我们来找找规律
Datas\\Texture\\BoneObject\\npc_nagoya_octopus01_body.dds is 0x36
Datas\\Texture\\BoneObject\\Toon.bmp is 0x21
Datas\\Texture\\BoneObject\\Toon_a.bmp is 0x23
Datas\\Texture\\BoneObject\\Toon_zero.bmp is 0x26

看起来没什么规律,呵呵

不过我注意到,文件名之后都跟着一大堆的00,那么把文件名加上那些0,长度是多少呢?

Datas\\Texture\\BoneObject\\npc_nagoya_octopus01_body.dds + 0's is 0x80   
Datas\\Texture\\BoneObject\\Toon.bmp + 0's is 0x80
Datas\\Texture\\BoneObject\\Toon_a.bmp + 0's is 0x80
Datas\\Texture\\BoneObject\\Toon_zero.bmp + 0's is 0x80

嘿,看到了吧,他们的长度都是0x80
所以,我们在脚本里这么写
getdstring NAME 0x80

这告诉程序,读取0x80个字节,把他们存到NAME变量里,程序会自动移除后面的那些0

ok,那么在下一个文件名之前,我们还有0xC字节的数据,这些是三个long型数据
我们暂时这么写,之后再来搞清楚他们到底是什么意思
get UNK2 long
get UNK3 long
get UNK4 long

那么我们现在又看到了文件名
现在,我们找到了规律,所以按我们之前学到了来写脚本:

代码:
idstring " PSH"
get UNK1 long
get FILES long
get NULL1 long
for i = 0 < FILES
getdstring NAME 0x80
get UNK2 long
get UNK3 long
get UNK4 long
clog NAME OFFSET ZSIZE SIZE
next i

ok,这看起来可能有一点复杂,不过应该跟第一篇教程差不多,除了我们多加了一个变量ZSIZE,它表示压缩过的文件大小,而SIZE代表没压缩过的文件大小
我们同样将log命令改为clog,表示这是一个压缩过的文件。

现在,我们有了循环,指令来解包,不过先得给这三个变量赋值
OFFSET ZSIZE SIZE

这意味着我们那三个未知变量很有可能代表的就是他们,那么我们怎么知道顺序呢?

好,现在让我们来到这个循环的末尾,定位到最后一个文件的文件名,选择0x8C个字节。
然后之后2个字节是78 9C,这是一个解包器的最好朋友,尤其当你在一个文件的开头看到它时。
78 9C 是标准zlib压缩格式的头部标识

所以,这意味着我们的第一个文件从偏移0x240开始

之后,我们回到列表里的第一个文件,看看这些未知变量。
24 72 00 00 代表0x7224
80 00 02 00 代表0x20080
40 02 00 00 代表0x240

我想我们至少知道第三个变量0x240代表着偏移量
那么,更新一下脚本:

代码:
idstring " PSH"
get UNK1 long
get FILES long
get NULL1 long
for i = 0 < FILES
getdstring NAME 0x80
get UNK2 long
get UNK3 long
get OFFSET long
clog NAME OFFSET ZSIZE SIZE
next i

好了,现在还剩下ZSIZE和SIZE
显然,压缩后的文件大小要比原来的要小,那么比较一下这两个变量
一个是0x7224,一个是0x20080
显然,后者要大,于是我们这么改写脚本:

代码:
idstring " PSH"
get UNK1 long
get FILES long
get NULL1 long
for i = 0 < FILES
getdstring NAME 0x80
get ZSIZE long
get SIZE long
get OFFSET long
clog NAME OFFSET ZSIZE SIZE
next i

好了,现在试试我们的代码吧。
打开命令提示符,进入到c:\\temp目录

输入 quickbms.exe -l astro.bms BoneObject.hsp
他会列出我们的文件,没有提示任何错误
好了,现在我们建立一个目录 extract
输入quickbms.exe astro.bms BoneObject.hsp extract

好了,现在我们在目录里有了4张图片,我们完成了。

笨蛋狐狸 发表于 2011-4-28 09:42

感谢各位前辈,留爪备查。
页: [1]
查看完整版本: 【汉化资料】通用解包器制作工具QuickBMS图文教程2