Haroohie Site/content/blog/: 3.2022-11-02-chokuretsu-archives — Chinese (Simplified) @ Weblate: Here’s something useful! That `"--- filetbl_load start <%d> ---\n"`{lang='c'} string …

Translation

English

Chinese (Simplified)

Needs editing

Insufficient privileges for saving translations.

Skip

	English	Chinese (Simplified)	Actions
	``` (0x950 - 0x20) / 0x04 = 0x24C ```	``` (0x950 - 0x20) / 0x04 = 0x24C ```
	Oh! Look at that! 0x24C happens to be the very first number to appear in the file (highlighted in red). So we can guess that the first number is the number of files in the archive. (To double check this, we should check that the pattern is consistent for the other archives as well – which it is.)	哦！看这个！0x24C 恰好是文件中出现的第一个数字（以红色突出显示）。因此，我们可以猜测第 1 个数字是归档文件中的文件数。（为了二次确认，我们应该检查其他归档文件的模式是否一致——事实确实如此。）
	![evt.bin open to 0x0000 with green highlights next to the cyan ones creating a series of 32-bit integers](/images/blog/0003/06_magic_integers.png)	![打开到 0x0000 的 evt.bin，青色高亮旁边有绿色高亮，创建了一系列 32 位整数](/images/blog/0003/06_magic_integers.png)
	What about the numbers next to the cyan highlights, though – the ones highlighted in green above? It’s hard to say right now as there’s no obvious pattern. However, we need some nomenclature here, so I’m going to be referring to the combination of the green and cyan highlights as _magic integer_, since they are obfuscated (magic) but do important stuff (also magic). The first magic integer spans from 0x20 to 0x23, which is why they’re “integers” – specifically, 32-bit integers.	那么，青色高亮显示旁边的数字——上面用绿色高亮显示的数字是什么呢？现在很难说，因为没有明显的模式。然而，我们在这里需要一些命名法，所以我将把绿色和青色高亮的组合称为魔数（magic integer），因为它们是模糊的（magic），但起着重要的作用（也是 magic）。第一个魔数从 0x20 到 0x23，这就是为什么它们是“整数”（interger）——准确来说，32 位整数。
	## Into the Thick of It, Reprise The purpose of the previous section was to demonstrate how to a) identify that a file is an archive and b) use some basic pattern matching to begin reverse-engineering the archive. However, this archive is a little weird and obfuscated – while most archives might simply have a table at the top containing the filename and offset (location in the archive) for each file, this one clearly doesn’t have that. That information is somehow hidden. There are a variety of ways one could deal with this, but for me, the easiest option seemed to be diving back into the assembly again.	## 深入其中，重演上一节的目的是演示如何：a) 确定文件是归档文件；b) 使用一些基本的模式匹配开始对归档文件进行逆向工程。然而，这个归档文件有点奇怪和模糊——虽然大多数归档文件可能只是在头部加入了一个表，其中包含了每个文件的文件名和偏移量（在归档文件中的位置），但这个归档文件显然没有。这些信息在某种程度上被隐藏了。有多种方法可以解决这个问题，但对我来说，最简单的选择似乎是再次回到汇编中。
	### File Table Load First, we should try to find the code where these archives are parsed. To do this, we’re going to do essentially the same process as we did last time – we’re going to do a memory search to find the archive _header_ (the top of the file, before the files in the archive start) in memory, set a read breakpoint at that memory address, and see what code uses the archive header.	### 文件表加载首先，我们应该尝试找到解析这些归档文件的代码。要做到这一点，我们将执行与上次基本相同的过程——我们将进行内存搜索，以在内存中找到归档文件的文件头（文件的顶部，在归档文件中的文件数据之前），在该内存地址设置读取断点，并查看哪些代码使用了归档文件的文件头。
	![evt.bin open to 0x20 showing the bytes D1 00 0A 00 highlighted, indicating that these are the bytes we will search for](/images/blog/0003/07_what_we_want.png)	![打开到 0x20 的 evt.bin，高亮区域显示了 D1 00 0A 00 字节，表示这些是我们将要搜索的字节](/images/blog/0003/07_what_we_want.png)
	So, we go back to DeSmuME and search for the four bytes at offset 0x20 (remember, DeSmuME’s memory search expects you to enter the bytes in reverse order, so instead of `D1 00 0A 00` we enter `00 0A 00 D1`)...	因此，我们回到 DeSmuME，搜索偏移量 0x20 处的四个字节（记住，DeSmuME 的内存搜索要求按相反的顺序输入字节，因此我们输入的不是 `D1 00 0A 00`，而是 `00 0A 00 D1`）……
	![DeSmuME's memory search window showing a single result for our search at 0x020F7720](/images/blog/0003/08_memory_search.png)	![DeSmuME 的内存搜索窗口，显示了我们在 0x020F7720 的搜索结果](/images/blog/0003/08_memory_search.png)
	And once again, we’ve found a single hit. So, let’s open up the memory viewer and head to 0x020F7720…	我们又一次找到了一个匹配。所以，让我们打开内存查看器，转到 0x020F7720……
	![DeSmuME's memory viewer showing the memory at 0x020F7720 looking exactly like the header of evt.bin](/images/blog/0003/09_memory_find.png)	![DeSmuME 的内存查看器，显示了 0x020F7720 处的内存，看起来与 evt.bin 的文件头完全相同](/images/blog/0003/09_memory_find.png)
	And it matches the `evt.bin` header exactly! This means that the `evt.bin` header is loaded into 0x020F7700. So now, we’ll load up the game in no$GBA (I was a little hard on no$ last time around, but its debugging tools _are_ very convenient) and set a read breakpoint for 0x020F7700.	它与 `evt.bin` 的文件头完全匹配！这意味着 `evt.bin` 的文件头被加载到了 0x020F7700 中。所以现在，我们将在 No$GBA 中加载游戏（我上次使用 No$ 的时候有点吃力，但它的调试工具确实非常方便），并为 0x020F7700 设置一个读取断点。
	![no$GBA hitting a breakpoint at 0x020338C8](/images/blog/0003/10_breakpoint.png)	![No$GBA 在 0x020338C8 处命中断点](/images/blog/0003/10_breakpoint.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 中调出这个子程序。
	```arm RAM:02033818 PUSH {R3-R9,LR} RAM:0203381C LDR R2, =dword_20A9AB0 RAM:02033820 MOV R6, R0 RAM:02033824 LDR R1, [R2] RAM:02033828 LDR R0, =aFiletblLoadSta ; "--- filetbl_load start <%d> ---\n" RAM:0203382C ADD R1, R1, #0x3F ; '?' RAM:02033830 BIC R3, R1, #0x3F RAM:02033834 MOV R1, R6 RAM:02033838 STR R3, [R2] RAM:0203383C BL dbg_print20228DC ```	```arm RAM:02033818 PUSH {R3-R9,LR} RAM:0203381C LDR R2, =dword_20A9AB0 RAM:02033820 MOV R6, R0 RAM:02033824 LDR R1, [R2] RAM:02033828 LDR R0, =aFiletblLoadSta ; "--- filetbl_load start <%d> ---\n" RAM:0203382C ADD R1, R1, #0x3F ; '?' RAM:02033830 BIC R3, R1, #0x3F RAM:02033834 MOV R1, R6 RAM:02033838 STR R3, [R2] RAM:0203383C BL dbg_print20228DC ```
	Here’s something useful! That `"--- filetbl_load start <%d> ---\n"`{lang='c'} string you see is text that’s hardcoded in the executable program (arm9.bin) itself.	我们找到了一些有用的东西！你可以看到的 `"--- filetbl_load start <%d> ---\n"`{lang='c'} 字符串是可执行程序（arm9.bin）本身中硬编码的文本。
	`=aFiletblLoadSta` is a name IDA gives to the address that holds that string, so `LDR R0, =aFiletblLoadSta`{lang='arm'} is loading the address of that string into R0. In ARM assembly, R0 is used as the first parameter when calling another subroutine, so the `BL` (branch-link or “call this subroutine”) below uses it as a parameter. Because the string looks a lot like a debug string, we can guess that that function is a debug print function (something that would print text to the console for debugging purposes), which is why we’ve renamed the function here to `dbg_print20228DC`.	`=aFiletblLoadSta` 是 IDA 为保存该字符串的地址命名的名称，因此 `LDR R0, =aFiletblLoadSta`{lang='arm'} 将该字符串的名称加载到 R0 中。在 ARM 汇编中调用另一个子程序时，R0 被用作第一个参数，因此下面的 `BL`（branch-link，分支链接，或称为“调用此子程序”）将其用作参数。因为这个字符串看起来很像调试字符串，我们可以猜测这个函数是一个调试打印函数（为了调试的目的，它会将文本打印到控制台），这就是为什么我们将这里的函数重命名为 `dbg_print20228DC`。
	But more importantly, the fact that this debug string is being printed here tells us what _this function’s name was_ in the original source code: `filetbl_load()`{lang='c'}. From this, we can surmise that this function is designed to load the “file table” from the archive – i.e., it loads the header we were just looking at and that header is the list of files we thought it was! This trick (looking at debug or error strings to figure out what a function does) is something I frequently make use of – without even examining the disassembly in detail, we now have a pretty good idea of what this function does.	但更重要的是，这个调试字符串被打印到这里的事实告诉我们，这个函数的名称在原始源代码中是什么：`filetbl_load()`{lang='c'}。由此，我们可以推测，这个函数的目的是从归档文件中加载“文件表”（file table）——也就是说，它加载了我们刚刚看到的文件头，而该文件头正是我们认为的文件列表！这个技巧（查看调试或错误字符串以了解函数的作用）是我经常使用的东西——甚至不用详细检查反汇编，我们现在就对这个函数的作用有了很好的了解。
	### Loading the Magic Integer After trying to analyze this routine the way we did the decompression routine, it turns out that this routine is a little bit more abstract. It references a bunch of memory addresses and other things that I don’t have any context for – so let’s get some context and watch what it’s doing in the debugger. After all, our goal here isn’t to necessarily reverse-engineer exactly what this routine is doing (unlike with the decompression routine), it’s to use this routine to understand the structure of the archive file.	### 加载魔数在尝试像我们分析解压缩程序时那样分析这个程序之后，我发现这个程序有点抽象。它引用了一堆内存地址和其他我没有任何上下文的东西——所以让我们获取一些上下文，看看它在调试器中做什么。毕竟，我们在这里的目标不一定是对这个程序所做的事情进行逆向工程（与解压缩程序不同），而是使用这个程序来理解归档文件的结构。
	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 debugger with the described str instruction highlighted](/images/blog/0003/11_str_instruction.png)	![高亮显示所述 str 指令的 No$GBA 调试器](/images/blog/0003/11_str_instruction.png)
	![The same screenshot of the no$GBA debugger as before but advanced one instruction, highlighting that the number of files have been stored in memory](/images/blog/0003/12_stored.png)	![与以前相同的 No$GBA 调试器的屏幕截图，但向前执行了一条指令，高亮显示了内存中存储的文件数](/images/blog/0003/12_stored.png)
	After we step over that instruction, we can in fact see that 0x24C got stored in 0x20C1A08 as we would expect. So now, let’s set a read breakpoint for that address to see where _it_ gets referenced.	在我们执行过该指令之后，我们实际上可以看到 0x24C 被存储在 0x20C1A08 中，就像我们所期望的那样。现在，让我们为该地址设置一个读取断点，看看它在哪里被引用。
	![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…	我们运行这个游戏……
	![no$GBA debugger showing a breakpoint in a new function](/images/blog/0003/14_new_subroutine.png)	![No$GBA 调试器，显示在新函数中的断点](/images/blog/0003/14_new_subroutine.png)
	And end up in this new subroutine. Navigating to this routine in IDA reveals that it’s very short.	并在这个新的子程序停止。在 IDA 中导航到这个程序会发现它非常短。
	```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`，然后单步执行，看看是什么调用了它。
	![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)
	Let’s pop open this section of this subroutine in IDA:	让我们在 IDA 中弹出此子程序的这一部分：

	English	Chinese (Simplified)	Actions
	![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)
	![no$GBA debugger showing a breakpoint in a new function](/images/blog/0003/14_new_subroutine.png)	![No$GBA 调试器，显示在新函数中的断点](/images/blog/0003/14_new_subroutine.png)
	### Parsing the Magic Integer Let’s continue:	### 解析魔数让我们继续：
	In other words:	换句话说：
	![no$GBA with highlights showing instructions for loading the magic integer into the register](/images/blog/0003/17_initial_header_stuff.png)	![No$GBA，高亮了将魔数加载到寄存器的指令](/images/blog/0003/17_initial_header_stuff.png)
	![The special length integer being calculated in no$GBA](/images/blog/0003/23_magic_length_int.png)	![在 No$GBA 中计算的特殊长度整数](/images/blog/0003/23_magic_length_int.png)
	Here it is in all its glory: what I have dubbed the “unhinged file length routine.” That 0x5398 number was indeed not the actual compressed length, but rather an encoded compressed length that was decoded by this routine. A quick FAQ:	我称之为“令人精神错乱的文件长度程序”。0x5398 这个数字实际上不是实际的压缩后的数组长度，而是被编码后的压缩长度，需要被此程序解码。一个快速的问答：
	int pcIncrement = magicLengthIntLeftShift * 12;	int pcIncrement = magicLengthIntLeftShift * 12;
	return magicLengthInt * 0x800; } ```	return magicLengthInt * 0x800; } ```
	Here, we hit a snag – in some cases, the edited file is going to be longer than the original file, right? This will happen more often than we think since my implementation of the compression algorithm is noticeably less efficient than the implementation the developers used, so even files that stay the same size decompressed will end up longer on recompression. The solution to this problem is actually pretty simple, just a bit tedious: we move everything further down.	在这里，我们遇到了一个障碍——在某些情况下，编辑后的文件会比原始文件长，对吧？这种情况会比我们想象中发生得更频繁，因为我的压缩算法的实现明显不如开发人员使用的实现更高效，所以即使解压后的文件保持相同大小，重新压缩的时间也会更长。这个问题的解决方案实际上很简单，只是有点乏味：我们把所有东西都往下移动。
	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 二进制归档文件”或简称为“二进制归档文件”。让我们选择一个归档文件开始研究。
	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:	关于第二个的快速解释——文件名不言自明，偏移量是指文件中数据所在的位置。简单来说：
	* 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	* 归档文件中的文件数量 * 归档文件中的文件列表，包括文件名和偏移量 * 所有文件的文件数据
	* 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。地址由程序在访问内存时使用，而偏移量在文件中使用（因为它们可以加载到内存中的任意位置），因此由程序本身将这些偏移量转换为地址。
	![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)
	Going back to the cyan highlights in the image above, we can see that if we interpret the highlighted values as little-endian 16-bit integers, we have a sequence like:	回到上图中的青色高亮，我们可以看到，如果我们将高亮显示的值解释为 16 位的小端序整数，我们会得到如下序列：
	These integers are increasing as we continue along! In fact, they continue to increase for another 0x900 bytes, with the pattern terminating at the final integer 0x94E:	随着我们继续前进，这些整数正在增加！事实上，它们继续增加 0x900 字节，模式终止于最后一个整数 0x94E：
	Oh! Look at that! 0x24C happens to be the very first number to appear in the file (highlighted in red). So we can guess that the first number is the number of files in the archive. (To double check this, we should check that the pattern is consistent for the other archives as well – which it is.)	哦！看这个！0x24C 恰好是文件中出现的第一个数字（以红色突出显示）。因此，我们可以猜测第 1 个数字是归档文件中的文件数。（为了二次确认，我们应该检查其他归档文件的模式是否一致——事实确实如此。）
	And it matches the `evt.bin` header exactly! This means that the `evt.bin` header is loaded into 0x020F7700. So now, we’ll load up the game in no$GBA (I was a little hard on no$ last time around, but its debugging tools _are_ very convenient) and set a read breakpoint for 0x020F7700.	它与 `evt.bin` 的文件头完全匹配！这意味着 `evt.bin` 的文件头被加载到了 0x020F7700 中。所以现在，我们将在 No$GBA 中加载游戏（我上次使用 No$ 的时候有点吃力，但它的调试工具确实非常方便），并为 0x020F7700 设置一个读取断点。
	Here’s something useful! That `"--- filetbl_load start <%d> ---\n"`{lang='c'} string you see is text that’s hardcoded in the executable program (arm9.bin) itself.	我们找到了一些有用的东西！你可以看到的 `"--- filetbl_load start <%d> ---\n"`{lang='c'} 字符串是可执行程序（arm9.bin）本身中硬编码的文本。
	And end up in this new subroutine. Navigating to this routine in IDA reveals that it’s very short.	并在这个新的子程序停止。在 IDA 中导航到这个程序会发现它非常短。
	int msbShift = BitConverter.ToUInt32(archiveBytes.Skip(0x0C).Take(4).ToArray()); int msbMultiplier = BitConverter.ToUInt32(archiveBytes.Skip(0x04).Take(4).ToArray()); uint value1 = (magicInteger >> msbShift) * msbMultiplier; } ```	int msbShift = BitConverter.ToUInt32(archiveBytes.Skip(0x0C).Take(4).ToArray()); int msbMultiplier = BitConverter.ToUInt32(archiveBytes.Skip(0x04).Take(4).ToArray()); uint value1 = (magicInteger >> msbShift) * msbMultiplier; } ```
	After executing these two instructions…	执行完这两条指令后……
	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 中，所以我们还没有完成。
	The next two instructions load the integers at offsets 0x0C (green) and 0x04 (pink) in `evt.bin` into R1 and R0, respectively. These instructions are then used in some calculations:	接下来的两条指令将 `evt.bin` 中偏移量为 0x0C（绿色）和 0x04（粉红色）处的整数分别加载到 R1 和 R0 中。这些指令随后用于某些计算：
	![no$GBA showing the below two instructions highlighted](/images/blog/0003/22_find_magic_length_int.png)	![No$GBA，高亮显示了以下两个指令](/images/blog/0003/22_find_magic_length_int.png)
	## 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 的二进制归档文件的工作原理有了很多了解。如果我们回顾一下我们最初期望的归档文件可能具有的内容列表：
	### 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.	### 保存归档文件保存归档文件的理想方法是从头开始重建，但由于头部中有我们不完全理解的数据，我们将不得不接受在适当的位置编辑文件头。因此，我们首先添加在解析时获取的整个文件头。
	```csharp if (i < Files.Count - 1) // If we aren’t on the last file { int pointerShift = 0; // Assume we’re not going to be shifting offsets at all while (bytes.Count % 0x10 != 0) // ensure our file is 16-byte aligned { bytes.Add(0); } // If the current size of the archive we’ve constructed so far is greater than // the next file’s offset, that means we need to adjust the next file’s offset if (bytes.Count > Files[i + 1].Offset) { // Calculate how much we need to shift the magic integer by pointerShift = ((bytes.Count - Files[i + 1].Offset) / MagicIntegerMsbMultiplier) + 1; } if (pointerShift > 0) { // Calculate the new magic integer factoring in pointer shift Files[i + 1].Offset = ((Files[i + 1].Offset / MagicIntegerMsbMultiplier) + pointerShift) * MagicIntegerMsbMultiplier; int magicIntegerOffset = FirstMagicIntegerOffset + (i + 1) * 4; uint newMagicInteger = GetNewMagicInteger(Files[i + 1], Files[i + 1].Length); Files[i + 1].MagicInteger = newMagicInteger; MagicIntegers[i + 1] = newMagicInteger; bytes.RemoveRange(magicIntegerOffset, 4); bytes.InsertRange(magicIntegerOffset, BitConverter.GetBytes(Files[i + 1].MagicInteger)); } // Add file padding while (bytes.Count < Files[i + 1].Offset) { bytes.Add(0); } } ```	```csharp if (i < Files.Count - 1) // If we aren’t on the last file { int pointerShift = 0; // Assume we’re not going to be shifting offsets at all while (bytes.Count % 0x10 != 0) // ensure our file is 16-byte aligned { bytes.Add(0); } // 如果我们构建的归档文件的当前大小大于下一个文件的偏移量， // 这意味着我们需要调整下一个归档文件的偏移量 if (bytes.Count > Files[i + 1].Offset) { // 计算我们需要将魔数移动多少 pointerShift = ((bytes.Count - Files[i + 1].Offset) / MagicIntegerMsbMultiplier) + 1; } if (pointerShift > 0) { // 计算指针移位后的新魔数 Files[i + 1].Offset = ((Files[i + 1].Offset / MagicIntegerMsbMultiplier) + pointerShift) * MagicIntegerMsbMultiplier; int magicIntegerOffset = FirstMagicIntegerOffset + (i + 1) * 4; uint newMagicInteger = GetNewMagicInteger(Files[i + 1], Files[i + 1].Length); Files[i + 1].MagicInteger = newMagicInteger; MagicIntegers[i + 1] = newMagicInteger; bytes.RemoveRange(magicIntegerOffset, 4); bytes.InsertRange(magicIntegerOffset, BitConverter.GetBytes(Files[i + 1].MagicInteger)); } // 添加文件填充 while (bytes.Count < Files[i + 1].Offset) { bytes.Add(0); } } ```