Haroohie Site/content/blog/: 3.2022-11-02-chokuretsu-archives — Chinese (Simplified) @ Weblate: For convenience, let’s pick the archive that contains the file …

Translation

English

Chinese (Simplified)

Needs editing

Insufficient privileges for saving translations.

Skip

	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）之间。但是，当我们需要表示比这更大的整数时呢？当我们需要这样做时，我们使用多字节整数。常见的类型包括：
	\| Number of Bytes \| Formal Name \| C# Name \| \|---\|---\|---\| \| 2 \| 16-bit integer \| `short`{lang='csharp'} (signed) or `ushort`{lang='csharp'} (unsigned) \| \| 4 \| 32-bit integer \| `int`{lang='csharp'} (signed) or `uint`{lang='csharp'} (unsigned) \| \| 8 \| 64-bit integer \| `long`{lang='csharp'} (signed) or `ulong`{lang='csharp'} (unsigned) \|	\| 字节数量 \| 正式名字 \| C# 名字 \| \|---\|---\|---\| \| 2 \| 16 位整数 \| `short`{lang='csharp'}（有符号）或 `ushort`{lang='csharp'}（无符号） \| \| 4 \| 32 位整数 \| `int`{lang='csharp'}（有符号）或 `uint`{lang='csharp'}（无符号） \| \| 8 \| 64 位整数 \| `long`{lang='csharp'}（有符号）或 `ulong`{lang='csharp'}（无符号） \|
	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 是一个小端序体系结构，所以这些文件也可能是小端序的。

	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 中打开游戏，并导航到我们上次看到的位置……
	![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)
	``` 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…	我们运行这个游戏……
	### Parsing the Magic Integer Let’s continue:	### 解析魔数让我们继续：
	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，向我们展示文件加载看起来如何，以及……
	The end-result of this calculation is 0x5398.	此计算的最终结果为 0x5398。
	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 二进制归档文件”或简称为“二进制归档文件”。让我们选择一个归档文件开始研究。
	* 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	* 归档文件中的文件数量 * 归档文件中的文件列表，包括文件名和偏移量 * 所有文件的文件数据
	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 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)
	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());
	We did indeed! We just found the routine for calculating the offset of a file given its index! But the magic integer is still loaded into LR, so we’re not done with it yet.	我们确实做到了！我们刚刚找到了计算给定索引的文件偏移量的程序！但是魔数仍然会被加载到 LR 中，所以我们还没有完成。
	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 开始，所以要使其为从零开始的索引，我们需要从第一个魔数之前的地址开始。）
	* 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/> 答：他们他妈的给我添麻烦。
	## Out of the Woods Whew! That was a lot of assembly. We could keep going down through subroutines, but we’ve accomplished our main task now: we understand a lot about how Shade bin archives work. If we return to our original list of what we expected an archive might have:	## 走出森林哇！这里有很多汇编指令。我们可以继续往下看子程序，但我们现在已经完成了主要任务：我们对 Shade 的二进制归档文件的工作原理有了很多了解。如果我们回顾一下我们最初期望的归档文件可能具有的内容列表：
	```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;
	### Saving the Archive The ideal way to save the archive is to reconstruct it from scratch, but because there’s data in the header we don’t understand fully we’ll have to settle for editing the header in place. So, we’ll start by just adding the whole header we took while parsing.	### 保存归档文件保存归档文件的理想方法是从头开始重建，但由于头部中有我们不完全理解的数据，我们将不得不接受在适当的位置编辑文件头。因此，我们首先添加在解析时获取的整个文件头。
	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.	为什么把东西搬下来很乏味？好吧，这又回到了魔数——它们包含了每个文件的偏移量。通过向下移动文件，我们改变了它的偏移量，这意味着魔数也会改变。所以我们需要编写代码来做到这一点。