Zen

Translation

English
---
title: &title 'Chokuretsu ROM Hacking Challenges Part 2 – Archive Archaeology'
description: &desc 'Jonko puts the Shade bin archive under the microscope and explains how he figured out how to unpack it.'
locale: 'en'
navigation:
author: 'Jonko'
year: 2022
month: 11
day: 02
tags: ['chokuretsu', 'romhacking']
image: '0003/00_thumbnail.png'
head:
meta:
- property: 'og:title'
content: *title
- property: 'og:description'
content: *desc
- property: 'og:image'
content: &img https://haroohie.club/images/blog/0003/00_thumbnail.png
- property: 'og:image:alt'
content: ''
- property: 'og:url'
content: 'https://haroohie.club/blog/2022-10-26-chokuretsu-archives'
- name: 'twitter:title'
value: *title
- name: 'twitter:description'
value: *desc
- name: 'twitter:image'
value: *img
- name: 'twitter:site'
value: '@haroohie'
- name: 'twitter:card'
value: 'summary_large_image'
---
[Last time](/blog/2022-10-19-chokuretsu-compression), we talked about how I reverse-engineered the compression algorithm used in Suzumiya Haruhi no Chokuretsu. Today, we’ll be taking a look at the archives that contain the Chokuretsu files. Please note that while I’ll generally try to keep these blog posts separate, this one absolutely builds on concepts we discussed last time, so I highly recommend you read it first! Also, if you're returning from the last one, fair warning that this one's a bit longer and contains a lot more assembly!
1090/14920 · 1492

Insufficient privileges for saving translations.

English Chinese (Simplified) Actions
---
title: &title 'Chokuretsu ROM Hacking Challenges Part 2 – Archive Archaeology'
description: &desc 'Jonko puts the Shade bin archive under the microscope and explains how he figured out how to unpack it.'
locale: 'en'
navigation:
author: 'Jonko'
year: 2022
month: 11
day: 02
tags: ['chokuretsu', 'romhacking']
image: '0003/00_thumbnail.png'
head:
meta:
- property: 'og:title'
content: *title
- property: 'og:description'
content: *desc
- property: 'og:image'
content: &img https://haroohie.club/images/blog/0003/00_thumbnail.png
- property: 'og:image:alt'
content: ''
- property: 'og:url'
content: 'https://haroohie.club/blog/2022-10-26-chokuretsu-archives'
- name: 'twitter:title'
value: *title
- name: 'twitter:description'
value: *desc
- name: 'twitter:image'
value: *img
- name: 'twitter:site'
value: '@haroohie'
- name: 'twitter:card'
value: 'summary_large_image'
---
[Last time](/blog/2022-10-19-chokuretsu-compression), we talked about how I reverse-engineered the compression algorithm used in Suzumiya Haruhi no Chokuretsu. Today, we’ll be taking a look at the archives that contain the Chokuretsu files. Please note that while I’ll generally try to keep these blog posts separate, this one absolutely builds on concepts we discussed last time, so I highly recommend you read it first! Also, if you're returning from the last one, fair warning that this one's a bit longer and contains a lot more assembly!
---
title: &title '《串联》ROM 破解挑战第 2 部分：归档文件考古学'
description: &desc 'Jonko 把 Shade 的二进制归档文件放在显微镜下，解释了他是如何打开它的。'
locale: 'zh-hans'
navigation:
author: 'Jonko'
translator: 'Xzonn'
year: 2022
month: 11
day: 02
tags: ['chokuretsu', 'romhacking']
image: '0003/00_thumbnail.png'
head:
meta:
- property: 'og:title'
content: *title
- property: 'og:description'
content: *desc
- property: 'og:image'
content: &img https://haroohie.club/images/blog/0003/00_thumbnail.png
- property: 'og:image:alt'
content: ''
- property: 'og:url'
content: 'https://haroohie.club/blog/2022-10-26-chokuretsu-archives'
- name: 'twitter:title'
value: *title
- name: 'twitter:description'
value: *desc
- name: 'twitter:image'
value: *img
- name: 'twitter:site'
value: '@haroohie'
- name: 'twitter:card'
value: 'summary_large_image'
---
[在上一次](/zh-hans/blog/2022-10-19-chokuretsu-compression)，我们讨论了我如何对《凉宫春日的串联》中使用的压缩算法进行逆向工程。今天，我们来看看包含在《串联》文件中的归档文件。请注意，虽然我通常会尽量将这些博客文章分开，但这篇文章绝对是建立在我们上次讨论的概念之上的，所以我强烈建议您先阅读它！此外，如果您是从上篇文章来到这里的，请注意，这篇文章有点长，包含更多的程序集！
Thanks to the proliferation of zip files, you’re likely already familiar with archives: they’re files that contain files, usually compressed versions to help save space on disk. Common archives include `.zip`, `.rar`, `.7z`, and `.tar.gz` files. Chokuretsu uses a custom archive format with the extension `.bin`. Since Shade is the developer of Chokuretsu, these files are referred to as “Shade bin archives” or just “bin archives.” Let’s get started by picking an archive to look at.
由于 zip 文件数量的激增，你可能已经熟悉了归档文件：它们是包含文件的文件，通常保存了压缩的版本，以帮助节省磁盘空间。常见的归档文件包括 `.zip`、`.rar`、`.7z` 和 `.tar.gz` 文件。《串联》使用了扩展名为 `.bin` 的自定义归档文件格式。由于 Shade 是《串联》的开发商，这些文件也可以被称为“Shade 二进制归档文件”或简称为“二进制归档文件”。让我们选择一个归档文件开始研究。
For convenience, let’s pick the archive that contains the file we were looking at last time. We can open the game up in CrystalTile2 and navigate to where we were looking last time…
为了方便起见，让我们选择包含了上次所查看的文件的归档文件。我们可以在 CrystalTile2 中打开游戏，并导航到我们上次看到的位置……
![The ROM opened in Crystal Tile 2 showing that the file we're looking for is evt.bin](/images/blog/0003/01_evt_ct2.png)
![用 CrystalTile2 中打开 ROM，显示了我们要查找的文件是 evt.bin](/images/blog/0003/01_evt_ct2.png)
And in the lower left corner it tells us that this data is contained in `evt.bin` (which is what we might have guessed, since it’s string data).
在左下角，它告诉我们这个数据包含在 `evt.bin` 中（这也是我们可能已经猜到了的，因为它是字符串数据）。
## Examining `evt.bin`
## 检查 `evt.bin`
Before we open it up in the hex editor, though, let’s talk a bit about what we’d expect to see in an archive (in order to confirm that `evt.bin` is in fact an archive). Here’s the attributes I’d put down:
不过，在我们用十六进制编辑器打开它之前，让我们谈谈我们希望在归档文件中看到什么（以确认 `evt.bin` 确实是一个归档文件）。以下是我要列出的属性：
* The number of files in the archive
* A list of files in the archive – this would be composed of _filenames_ and _offsets_
* The file data for all the files
* 归档文件中的文件数量
* 归档文件中的文件列表，包括*文件名*和*偏移量*
* 所有文件的文件数据
A quick explanation on that second bullet – filenames are self explanatory, but an offset is a way of talking about the location of data in a file. Briefly:
关于第二个的快速解释——文件名不言自明，偏移量是指文件中数据所在的位置。简单来说：
* An _address_ is the _absolute_ location of data in memory. When we set memory breakpoints in the debugger, we use addresses.
* An _offset_ is the _relative_ location of data in a file. When we have a single file open in the hex editor, we talk about offsets.
* A _pointer_ is a value that _points_ to an address or offset. A pointer to an address might look like an integer with the value 0x0220B4A8, while a pointer to an offset might be as simple as 0x3800. Addresses are used by the program when accessing memory, while offsets are used in files (since they can be loaded into arbitrary locations in memory), so it’s up to the program itself to convert those offsets into addresses.
* *地址*（address）是数据在内存中的绝对位置。当我们在调试器中设置内存断点时，我们使用地址。
* *偏移量*（offset）是文件中数据的相对位置。当我们在十六进制编辑器中打开一个文件时，我们会讨论偏移量。
* *指针*（pointer）是*指向*地址或偏移量的值。指向地址的指针可能看起来像值为 0x0220B4A8 的整数，而指向偏移量的指针可能简单到 0x3800。地址由程序在访问内存时使用，而偏移量在文件中使用（因为它们可以加载到内存中的任意位置），因此由程序本身将这些偏移量转换为地址。
So with that out of the way, let’s crack open `evt.bin`. First thing we’ll do is scroll down a bit just to get a feel for the layout of this file…
既然这样，让我们打开 `evt.bin`。我们要做的第一件事是向下滚动一点，以了解这个文件的布局……
![evt.bin open in Crystal Tile 2 showing a section of zeros above 0x2800](/images/blog/0003/02_lots_of_zeros_1.png)
![在 CrystalTile2 中打开的 evt.bin，显示 0x2800 以上的一段 0](/images/blog/0003/02_lots_of_zeros_1.png)
![evt.bin open in Crystal Tile 2 showing a section of zeros below the file at 0x2800](/images/blog/0003/03_lots_of_zeros_2.png)
![在 CrystalTile2 中打开的 evt.bin，显示 0x2800 以下的一段 0](/images/blog/0003/03_lots_of_zeros_2.png)
Interesting! After we scroll past a large chunk of data, we end up in a field of zeros, followed by another large chunk of data and then another field of zeros and so on. What’s more, after we scroll past the first bit, each of the large chunks of data seems to start on a multiple of 0x800 (hard to get that sense from two images, but trust me, crack open the files and you’ll see the pattern). To me, this looks like the _file data_ – and what’s more, each file is neatly spaced with padding in between.
有趣！当我们滚动经过一大块数据后，我们最终会进入一个包含 0 的区域，然后是另一大块数据，然后是一个包含 0 的区域，以此类推。更重要的是，当我们滚动过第一段之后，每一大块数据似乎都以 0x800 的倍数开始（很难从两个图像中获得这种感觉，但相信我，如果你打开文件，你就会看到这种模式）。对我来说，这看起来像*文件数据*——而且，每个文件之间都有整齐的填充。
![evt.bin open in Crystal Tile 2 at 0x0000. The first two bytes are highlighted in red and a pattern of bytes starting at 0x22 and spaced every four bytes are highlighted in cyan](/images/blog/0003/04_cyan_numbers.png)
![在 CrystalTile2 中打开的 evt.bin，显示了 0x0000 处。前两个字节以红色高亮，从 0x22 开始每隔四个字节间隔的字节模式以青色高亮](/images/blog/0003/04_cyan_numbers.png)
Let’s get back to the top of the file – again, a lot of numbers, but there are patterns here. But before we take a look at the numbers in cyan, a quick explanation on _endianness_. So far, we’ve mostly thought about things in terms of bytes, which can have values between 0 (0x00) and 255 (0xFF). But what about when we need to represent integers larger than that? When we need to do that, we use _multibyte integers_. The common types of these include:
让我们回到文件的顶部——再说一遍，有很多数字，但这里有一些模式。但在我们看一下青色高亮的数字之前，先来快速解释一下*字节序*。到目前为止，我们主要考虑的是字节，字节的值可以在 0（0x00）到 255（0xFF）之间。但是，当我们需要表示比这更大的整数时呢？当我们需要这样做时，我们使用*多字节整数*。常见的类型包括：
English Chinese (Simplified) Actions
![The RAM address of =sArchiveFileNames viewed in IDA showing a list of archive filenames](/images/blog/0003/16_archive_file_names.png)
![IDA 中查看的 =sArchiveFileNames 处的内存地址，显示归档文件的文件名列表](/images/blog/0003/16_archive_file_names.png)
---
title: &title 'Chokuretsu ROM Hacking Challenges Part 2 – Archive Archaeology'
description: &desc 'Jonko puts the Shade bin archive under the microscope and explains how he figured out how to unpack it.'
locale: 'en'
navigation:
author: 'Jonko'
year: 2022
month: 11
day: 02
tags: ['chokuretsu', 'romhacking']
image: '0003/00_thumbnail.png'
head:
meta:
- property: 'og:title'
content: *title
- property: 'og:description'
content: *desc
- property: 'og:image'
content: &img https://haroohie.club/images/blog/0003/00_thumbnail.png
- property: 'og:image:alt'
content: ''
- property: 'og:url'
content: 'https://haroohie.club/blog/2022-10-26-chokuretsu-archives'
- name: 'twitter:title'
value: *title
- name: 'twitter:description'
value: *desc
- name: 'twitter:image'
value: *img
- name: 'twitter:site'
value: '@haroohie'
- name: 'twitter:card'
value: 'summary_large_image'
---
[Last time](/blog/2022-10-19-chokuretsu-compression), we talked about how I reverse-engineered the compression algorithm used in Suzumiya Haruhi no Chokuretsu. Today, we’ll be taking a look at the archives that contain the Chokuretsu files. Please note that while I’ll generally try to keep these blog posts separate, this one absolutely builds on concepts we discussed last time, so I highly recommend you read it first! Also, if you're returning from the last one, fair warning that this one's a bit longer and contains a lot more assembly!
---
title: &title '《串联》ROM 破解挑战第 2 部分：归档文件考古学'
description: &desc 'Jonko 把 Shade 的二进制归档文件放在显微镜下，解释了他是如何打开它的。'
locale: 'zh-hans'
navigation:
author: 'Jonko'
translator: 'Xzonn'
year: 2022
month: 11
day: 02
tags: ['chokuretsu', 'romhacking']
image: '0003/00_thumbnail.png'
head:
meta:
- property: 'og:title'
content: *title
- property: 'og:description'
content: *desc
- property: 'og:image'
content: &img https://haroohie.club/images/blog/0003/00_thumbnail.png
- property: 'og:image:alt'
content: ''
- property: 'og:url'
content: 'https://haroohie.club/blog/2022-10-26-chokuretsu-archives'
- name: 'twitter:title'
value: *title
- name: 'twitter:description'
value: *desc
- name: 'twitter:image'
value: *img
- name: 'twitter:site'
value: '@haroohie'
- name: 'twitter:card'
value: 'summary_large_image'
---
[在上一次](/zh-hans/blog/2022-10-19-chokuretsu-compression)，我们讨论了我如何对《凉宫春日的串联》中使用的压缩算法进行逆向工程。今天，我们来看看包含在《串联》文件中的归档文件。请注意，虽然我通常会尽量将这些博客文章分开，但这篇文章绝对是建立在我们上次讨论的概念之上的，所以我强烈建议您先阅读它！此外，如果您是从上篇文章来到这里的，请注意，这篇文章有点长，包含更多的程序集！
## Examining `evt.bin`
## 检查 `evt.bin`
For convenience, let’s pick the archive that contains the file we were looking at last time. We can open the game up in CrystalTile2 and navigate to where we were looking last time…
为了方便起见，让我们选择包含了上次所查看的文件的归档文件。我们可以在 CrystalTile2 中打开游戏，并导航到我们上次看到的位置……
```
0x000A, 0x000C, 0x000E, 0x0010, 0x0014, 0x0016, 0x0018, 0x001A, 0x001C, 0x001E, 0x0020, 0x0022 …
```
```
0x000A, 0x000C, 0x000E, 0x0010, 0x0014, 0x0016, 0x0018, 0x001A, 0x001C, 0x001E, 0x0020, 0x0022 …
```
![no$GBA hitting a breakpoint at 0x020338C8](/images/blog/0003/10_breakpoint.png)
![No$GBA 在 0x020338C8 处命中断点](/images/blog/0003/10_breakpoint.png)
So back to no$GBA then. Stepping forward, we come to this `STR` instruction. `STR R2,[R0, R5]` should store the value of R2 (0x24C, what we’re suspecting is the number of files) in the memory location R0+R5.
所以，回到 No$GBA。单步执行，我们来到这个 `STR` 指令。`STR R2,[R0, R5]` 将 R2 的值（0x24C，我们怀疑是文件数）存储在内存位置 R0+R5 中。
![no$GBA breakpoint creation dialog showing us setting a read breakpoint at 0x020C1A08](/images/blog/0003/13_second_break.png)
![no$GBA 的断点创建窗口，显示我们将读取断点设置为 0x020C1A08](/images/blog/0003/13_second_break.png)
We run the game…
我们运行这个游戏……
Here, we’re just extracting the values we found from the header and then looping through and extracting all the magic integers.
在这里，我们只是从文件头提取我们找到的值，然后循环并提取所有的魔数。
So we have a functional parser now. We can write up a quick GUI to show us how file loading will look and…
我们现在得到了一个函数解析器。我们可以编写一个快速的 GUI，向我们展示文件加载看起来如何，以及……
So with that out of the way, let’s crack open `evt.bin`. First thing we’ll do is scroll down a bit just to get a feel for the layout of this file…
既然这样，让我们打开 `evt.bin`。我们要做的第一件事是向下滚动一点，以了解这个文件的布局……
![evt.bin open in Crystal Tile 2 at 0x0000. The first two bytes are highlighted in red and a pattern of bytes starting at 0x22 and spaced every four bytes are highlighted in cyan](/images/blog/0003/04_cyan_numbers.png)
![在 CrystalTile2 中打开的 evt.bin，显示了 0x0000 处。前两个字节以红色高亮，从 0x22 开始每隔四个字节间隔的字节模式以青色高亮](/images/blog/0003/04_cyan_numbers.png)
There are two possible ways to store a 16-bit integer, however. For example, take 512 (0x200). You could choose to store that with the _most-significant byte_ first (i.e. `02 00`) or with the _least-significant byte_ first (i.e. `00 02`). This decision is called _endianness_, where the former is “big-endian” and the latter is “little-endian.” Frequently, the decision is made simply to align with whatever the architecture uses; ARM is a little-endian architecture so these files are likely little-endian as well.
然而，有两种可能的方式来存储 16 位整数。以 512（0x200）为例。你可以选择将*最高有效字节*先存储（即 `02 00`）或*最低有效字节*先存储（即 `00 02`）中。这种决定被称为*字节序*（endianness），其中前者是“大端序”（big-endian），后者是“小端序”（little-endian）。通常，做出这个决定只是为了与体系结构使用的任何东西保持一致；ARM 是一个小端序体系结构，所以这些文件也可能是小端序的。
```arm
RAM:02033A58 sub_2033A58
RAM:02033A58 MOV R1, #0x18
RAM:02033A5C MUL R1, R0, R1
RAM:02033A60 LDR R0, =dword_20C19D8
RAM:02033A64 LDR R0, [R0,R1]
RAM:02033A68 BX LR
```
```arm
RAM:02033A58 sub_2033A58
RAM:02033A58 MOV R1, #0x18
RAM:02033A5C MUL R1, R0, R1
RAM:02033A60 LDR R0, =dword_20C19D8
RAM:02033A64 LDR R0, [R0,R1]
RAM:02033A68 BX LR
```
`BX LR`{lang='arm'} returns us to the subroutine that called this one, so given that we know the previous instruction is the one that loaded 0x24C into R0 (the register that is frequently used as a return value), we might be able to posit that the entire purpose of this subroutine is to load that value from memory. So, let’s rename this function to `arc_getNumFiles` and then step forward and see what called it.
`BX LR`{lang='arm'} 让我们返回到调用此处的子程序，因此，如果我们知道前一条指令是将 0x24C 加载到 R0（经常用作返回值的寄存器）的指令，我们可能能够假设该子程序的全部目的是从内存加载该值。因此，让我们将此函数重命名为 `arc_getNumFiles`，然后单步执行，看看是什么调用了它。
Nice, we hit our breakpoint as soon as the game is loaded. This means that the archive headers are loaded on boot. Let’s pull up this subroutine in IDA.
很好，游戏一加载，我们就命中了断点。这意味着归档文件的文件头是在启动时加载的。让我们在 IDA 中调出这个子程序。
![no$GBA showing a breakpoint in the caller of the previous subroutine](/images/blog/0003/15_subroutine_caller.png)
![No$GBA，显示了调用上一个子程序的程序中的断点](/images/blog/0003/15_subroutine_caller.png)
```arm
RAM:02033D04 loc_2033D04
RAM:02033D04 ADD R2, SP, #8
RAM:02033D08 ADD R3, SP, #4
RAM:02033D0C MOV R0, R10
RAM:02033D10 MOV R1, R9
RAM:02033D14 BL sub_2033A70
```
```arm
RAM:02033D04 loc_2033D04
RAM:02033D04 ADD R2, SP, #8
RAM:02033D08 ADD R3, SP, #4
RAM:02033D0C MOV R0, R10
RAM:02033D10 MOV R1, R9
RAM:02033D14 BL sub_2033A70
```
```arm
RAM:02033A70 PUSH {R4,LR}
RAM:02033A74 MOV R12, #0x18
RAM:02033A78 MUL R4, R0, R12
RAM:02033A7C LDR R0, =dword_20C19D4
RAM:02033A80 LDR R12, =dword_20C19D0
RAM:02033A84 LDR LR, [R0,R4]
RAM:02033A88 LDR R0, [R12,R4]
RAM:02033A8C LDR LR, [LR,R1,LSL#2]
RAM:02033A90 LDR R1, [R0,#0xC]
RAM:02033A94 LDR R0, [R0,#4]
RAM:02033A98 MOV R1, LR,LSR R1
RAM:02033A9C MUL R0, R1, R0
RAM:02033AA0 STR R0, [R2]
RAM:02033AA4 LDR R0, [R12,R4]
RAM:02033AA8 LDR R1, [R0,#0x10]
RAM:02033AAC LDR R0, [R0,#8]
RAM:02033AB0 AND R1, LR, R1
RAM:02033AB4 MUL R0, R1, R0
RAM:02033AB8 STR R0, [R3]
RAM:02033ABC POP {R4,PC}
```
```arm
RAM:02033A70 PUSH {R4,LR}
RAM:02033A74 MOV R12, #0x18
RAM:02033A78 MUL R4, R0, R12
RAM:02033A7C LDR R0, =dword_20C19D4
RAM:02033A80 LDR R12, =dword_20C19D0
RAM:02033A84 LDR LR, [R0,R4]
RAM:02033A88 LDR R0, [R12,R4]
RAM:02033A8C LDR LR, [LR,R1,LSL#2]
RAM:02033A90 LDR R1, [R0,#0xC]
RAM:02033A94 LDR R0, [R0,#4]
RAM:02033A98 MOV R1, LR,LSR R1
RAM:02033A9C MUL R0, R1, R0
RAM:02033AA0 STR R0, [R2]
RAM:02033AA4 LDR R0, [R12,R4]
RAM:02033AA8 LDR R1, [R0,#0x10]
RAM:02033AAC LDR R0, [R0,#8]
RAM:02033AB0 AND R1, LR, R1
RAM:02033AB4 MUL R0, R1, R0
RAM:02033AB8 STR R0, [R3]
RAM:02033ABC POP {R4,PC}
```
```csharp
public ArchiveFile(byte[] archiveBytes)
{
NumFiles = BitConverter.ToInt32(archiveBytes.Take(4).ToArray());
```csharp
public ArchiveFile(byte[] archiveBytes)
{
NumFiles = BitConverter.ToInt32(archiveBytes.Take(4).ToArray());
After executing a few steps, we can see that the first part of this subroutine is just loading the address of the `evt.bin` header we’ve already found into R0. It’s also setting LR (which is called R14 in no$) to the address (highlighted in cyan) right before the first magic integer (highlighted in green). Interesting! The currently highlighted instruction is `LDR LR, [LR,R1,LSL#2]`{lang='arm'} – this is going to load the value at the address `LR + R1 * 4` into LR. R1, remember, is the file index – therefore, this is loading the magic integer that corresponds to that file index! (Recall that the magic integer array starts at 1 rather than 0, so to make it zero-indexed we need to start from the address directly before the first magic integer.)
在执行了几个步骤之后，我们可以看到这个子程序的第一部分只是将我们已经找到的 `evt.bin` 的头部的地址加载到 R0 中。它还将 LR（在 No$GBA 中被称为 R14）设置为第一个魔数（以绿色突出显示）之前的地址（以青色突出显示）。有趣！当前高亮的指令是 `LDR LR, [LR,R1,LSL#2]`{lang='arm'}——这条指令把地址 `LR + R1 * 4` 处的值加载到 LR 中。记住，R1 是文件索引——因此，这将加载与该文件索引对应的魔数！（回想一下，魔数数组从 1 开始，而不是从 0 开始，所以要使其为从零开始的索引，我们需要从第一个魔数之前的地址开始。）
The address we should be loading from is `0x020F771C + 0x245 * 4 = 0x20F8030`, and indeed, when we step forward we see that value loaded in. Now that the magic integer is loaded in, let’s see what happens next.
我们应该加载的地址是 `0x020F771C + 0x245 * 4 = 0x20F8030`，事实上，当我们继续执行时，可以看到该值已加载。现在，魔数已加载，让我们看看接下来会发生什么。
Note the debug string five lines from the bottom (`"read:[%s],idx=%d,ofs=0x%x,sz=%dKB"`{lang='c'}). After the magic integer is processed, we have a debug string explicitly referencing the file index, offset, and _size_. However, 0x5398 is not the length of this file (we know its offset, so we can check its length manually; including padding, the file is 0x5800 bytes in length). So let’s have a look at the one subroutine call in between `arc_processMagicInteger` and that debug string: `sub_201D310`.
注意倒数第五行的调试字符串（`"read:[%s],idx=%d,ofs=0x%x,sz=%dKB"`{lang='c'}）。处理完魔数后，我们得到了一个调试字符串，显式引用了文件索引、偏移量和*大小*。但是，0x5398 不是这个文件的长度（我们知道它的偏移量，所以我们可以手动检查它的长度；加上填充字节后，文件的长度是 0x5800 字节）。因此，让我们来看看 `arc_processMagicInteger` 和调试字符串之间的一个子程序调用：`sub_201D310`。
Before we get to adding files to the archive, we have to convert that compressed length function. I could go through and explain how I converted from the assembly step-by-step, but that would be a lengthy and tedious explanation. So instead, here’s the final code:
在将文件添加到归档文件之前，我们必须转换压缩长度函数。我可以一步一步地浏览并解释我是如何从汇编代码转换过来的，但这将会非常冗长乏味。因此，以下是最终代码：
* Q: Why is there so much repetition in this routine?<br/>
A: This is the result of a function of some compilers (including ARM compilers) called _loop unrolling_. Basically, there is a tradeoff made in favor of execution time over program space when the compiler can statically determine how many loops will occur at compile time.
* Q: What does that mean?<br/>
A: Don’t worry, it doesn’t really matter. Point is, that’s a loop, so we can treat it as a loop.
* Q: I’m seeing a lot of `ADCS` and `SUBCC` instructions here. What’s up with those?<br/>
A: `ADCS` is “add with carry, set flags.” Essentially, this means that we add two numbers and, if the previous operation resulted in a “carry,” we add one to the sum. We then set or clear the carry flag depending on whether that addition resulted in a carry. A “carry” here refers to “unsigned overflow” – when a 32-bit integer exceeds its maximum value and loops back around. `SUBCC` is “sub if carry clear.” This means we subtract two numbers if the previous operation did _not_ result in a carry.
* Q: Why would the devs do it this way?<br/>
A: They want to fuck with me specifically.
* 问：为什么这个程序有这么多重复？<br/>
答：这是一些编译器（包括 ARM 编译器）的一个名为*循环展开*的函数的结果。通常情况下，当编译器可以静态地确定编译时将发生多少循环时，会在执行时间与程序空间之间进行权衡。
* 问：这是什么意思？<br/>
答：别担心，这其实并不重要。重点是，这是一个循环，所以我们可以把它当作一个循环。
* 问：我看到了很多 `ADCS` 和 `SUBCC` 指令。它们是什么意思？<br/>
答：`ADCS` 表示“加和并进位，设置标志”。本质上来说，这意味着将两个数字相加，如果上一次运算产生“进位”，我们就在和上加 1。然后，我们根据加和是否导致进位来设置或清除进位标志。这里的“进位”指的是“无符号溢出”——即 32 位整数超过其最大值并循环。`SUBCC` 表示“如果没有进位则相减”。这意味着如果前一个运算没有导致进位，我们令两个数字相减。
* 问：为什么开发者会这样做？<br/>
答：他们他妈的给我添麻烦。
```csharp
public partial class FileInArchive
{
public uint MagicInteger { get; set; }
public int Index { get; set; }
public int Offset { get; set; }
public List<byte> Data { get; set; }
public byte[] CompressedData { get; set; }
public bool Edited { get; set; } = false;
```csharp
public partial class FileInArchive
{
public uint MagicInteger { get; set; }
public int Index { get; set; }
public int Offset { get; set; }
public List<byte> Data { get; set; }
public byte[] CompressedData { get; set; }
public bool Edited { get; set; } = false;
public FileInArchive()
{
}
}
```
public FileInArchive()
{
}
}
```
Now we have a function that can determine the compressed length of a file from its magic integer. But here’s the problem – when we save the file, we’ll have to reverse that and go from the compressed length back to the magic integer. How do we accomplish that?
现在我们得到了一个函数，可以根据文件的魔数来确定文件的压缩长度。但问题是，当我们保存文件时，我们必须将其反转，并从压缩的长度返回到魔数。我们如何做到这一点？
Why is moving things down tedious? Well it comes back to the magic integers – those contain _offsets_ for each file. By moving the file down, we’re changing its offset, which means the magic integer will change as well. So we need to write code to do that.
为什么把东西搬下来很乏味？好吧，这又回到了魔数——它们包含了每个文件的*偏移量*。通过向下移动文件，我们改变了它的偏移量，这意味着魔数也会改变。所以我们需要编写代码来做到这一点。

Loading…

User avatar admin

Translation added

  1. Haroohie Site
  2. content/blog/: 3.2022-11-02-chokuretsu-archives
  3. Chinese (Simplified)
---
title: &title 'Chokuretsu ROM Hacking Challenges Part 2 – Archive Archaeology'
description: &desc 'Jonko puts the Shade bin archive under the microscope and explains how he figured out how to unpack it.'
locale: 'en'
navigation:
author: 'Jonko'
year: 2022
month: 11
day: 02
tags: ['chokuretsu', 'romhacking']
image: '0003/00_thumbnail.png'
head:
meta:
- property: 'og:title'
content: *title
- property: 'og:description'
content: *desc
- property: 'og:image'
content: &img https://haroohie.club/images/blog/0003/00_thumbnail.png
- property: 'og:image:alt'
content: ''
- property: 'og:url'
content: 'https://haroohie.club/blog/2022-10-26-chokuretsu-archives'
- name: 'twitter:title'
value: *title
- name: 'twitter:description'
value: *desc
- name: 'twitter:image'
value: *img
- name: 'twitter:site'
value: '@haroohie'
- name: 'twitter:card'
value: 'summary_large_image'
---
[Last time](/blog/2022-10-19-chokuretsu-compression), we talked about how I reverse-engineered the compression algorithm used in Suzumiya Haruhi no Chokuretsu. Today, we’ll be taking a look at the archives that contain the Chokuretsu files. Please note that while I’ll generally try to keep these blog posts separate, this one absolutely builds on concepts we discussed last time, so I highly recommend you read it first! Also, if you're returning from the last one, fair warning that this one's a bit longer and contains a lot more assembly!
---
title: &title '《串联》ROM 破解挑战第 2 部分：归档文件考古学'
description: &desc 'Jonko 把 Shade 的二进制归档文件放在显微镜下，解释了他是如何打开它的。'
locale: 'zh-hans'
navigation:
author: 'Jonko'
translator: 'Xzonn'
year: 2022
month: 11
day: 02
tags: ['chokuretsu', 'romhacking']
image: '0003/00_thumbnail.png'
head:
meta:
- property: 'og:title'
content: *title
- property: 'og:description'
content: *desc
- property: 'og:image'
content: &img https://haroohie.club/images/blog/0003/00_thumbnail.png
- property: 'og:image:alt'
content: ''
- property: 'og:url'
content: 'https://haroohie.club/blog/2022-10-26-chokuretsu-archives'
- name: 'twitter:title'
value: *title
- name: 'twitter:description'
value: *desc
- name: 'twitter:image'
value: *img
- name: 'twitter:site'
value: '@haroohie'
- name: 'twitter:card'
value: 'summary_large_image'
---
[在上一次](/zh-hans/blog/2022-10-19-chokuretsu-compression)，我们讨论了我如何对《凉宫春日的串联》中使用的压缩算法进行逆向工程。今天，我们来看看包含在《串联》文件中的归档文件。请注意，虽然我通常会尽量将这些博客文章分开，但这篇文章绝对是建立在我们上次讨论的概念之上的，所以我强烈建议您先阅读它！此外，如果您是从上篇文章来到这里的，请注意，这篇文章有点长，包含更多的程序集！
a month ago
User avatar None

String updated in the repository

  1. Haroohie Site
  2. content/blog/: 3.2022-11-02-chokuretsu-archives
  3. Chinese (Simplified)
---
title: &title 'Chokuretsu ROM Hacking Challenges Part 2 – Archive Archaeology'
description: &desc 'Jonko puts the Shade bin archive under the microscope and explains how he figured out how to unpack it.'
locale: 'en'
navigation:
author: 'Jonko'
year: 2022
month: 11
day: 02
tags: ['chokuretsu', 'romhacking']
image: '0003/00_thumbnail.png'
head:
meta:
- property: 'og:title'
content: *title
- property: 'og:description'
content: *desc
- property: 'og:image'
content: &img https://haroohie.club/images/blog/0003/00_thumbnail.png
- property: 'og:image:alt'
content: ''
- property: 'og:url'
content: 'https://haroohie.club/blog/2022-10-26-chokuretsu-archives'
- name: 'twitter:title'
value: *title
- name: 'twitter:description'
value: *desc
- name: 'twitter:image'
value: *img
- name: 'twitter:site'
value: '@haroohie'
- name: 'twitter:card'
value: 'summary_large_image'
---
[Last time](/blog/2022-10-19-chokuretsu-compression), we talked about how I reverse-engineered the compression algorithm used in Suzumiya Haruhi no Chokuretsu. Today, we’ll be taking a look at the archives that contain the Chokuretsu files. Please note that while I’ll generally try to keep these blog posts separate, this one absolutely builds on concepts we discussed last time, so I highly recommend you read it first! Also, if you're returning from the last one, fair warning that this one's a bit longer and contains a lot more assembly!
 
a month ago
Browse all string changes

Things to check

Mismatching line breaks

Number of new lines in translation does not match source

Reset

Glossary

English Chinese (Simplified)
No related strings found in the glossary.

String information

Source string location
:36
String age
a month ago
Last updated
a month ago
Source string age
a month ago
Translation file
content/blog/3.2022-11-02-chokuretsu-archives/zh-hans.md, string 1