接下来，我们可以开始制作我们的第一个mod了。如果你还需要一个合适的java开发环境，你可以参考Kaupenjoe的视频以及网上其他博主和视频主的资料。这里还是建议使用intelij作为你的开发软件，一方面作为pycharm的同厂商软件，使用手感也与pycharm相近，另一方面，代码自动补全确实省事不少。

先从手头有的东西开始

API的开发模板

我们既然需要通过一些插件作为跳板来开发模组，那么，相关工程的代码模板也必不可少。

这里以forge mod开发举例，你可以很轻而易举地从github上pull一个forge的开发模板到本地环境。我这里使用的是1.19.3的mdk，实际开发中可能还需要针对你modding的目标版本使用不同的模板和编写方式，但大同小异。

如图，src就是日后我们存储大部分相关源代码的地方，gradle相关的文件则用于自动构建项目，git相关则是用作之后在本地与git之间交互的。

除此之外，那些README啥的txt你可以全扬了。

关于模板内部的各类参数，我们等打开开发环境之后再说：

你的开发环境

接下来，我们打开编辑软件，这里以intelij为例：

我们需要做的就是等待gradle自行完成项目的建构，紧接着，你的forge模板上就会有一个完整的minecraft运行环境，里面包括了很多你会用到的东西。

顺带，记得把你的gradle的默认java改成项目自带的Java环境，像这样：

minecraft本体的各类参数和函数

如果你要尝试开发一个包含功能性方块、功能性物件、一套完整合成系统，甚至生物模型、AI、生态的大型mod，其工作量不亚于让你重新开发一个minecraft，但好消息是，minecraft本体当中为你提供了大量原生的代码，减轻了你自行编写函数的工作量。

在gradle建构完成后，你可以在你的External Libaries文件夹看到客户端及其文件，在正式开发mod之前，建议细细翻阅，以免自己在编写（实为复现）的时候出现莫名的格式问题（毕竟不同版本之间可能会有大重构，就像1.19.2到1.19.3直接把物品分类大改了一样）：

让我们回到模板

src文件夹下包含两个关键的大类，一个是项目本体（java），存放实现功能的主要代码；一个是模组资源（resources），存放模组的各类模型等。

在开始编程之前，我们需要认识我们的模板。

java类

java类下有一个ExampleMod文件，那是一切的开始之一，我们点进去看看各项组件：

MODID：你的模组的ID，日后很多调用都需要以ID为关键参数。我们需要把它的内容替换为为全小写格式的，我们自己的模组名。这里就以tutorialmod为例。Kaupenjoe习惯将此变量名改为MOD_ID，可能是后期编写的时候会与客户端源文件冲突？

LOGGER：一个简单日志门面的接口，关于slf4j的详细内容可以参考https://56data.cc/1563.html，本文不作赘述。

BLOCKS、ITEMS、EXAMPLE_BLOCK、EXAMPLE_BLOCK_ITEM：forge提供的各类物件的注册模板，方便你快速在类中注册物品，但自己写的话多半用不上。

以及下方的各类函数，其上都有一定的注释，这里不多赘述。但是需要注意一下EventBusSubscriber，这个组件涉及到forge、mod和minecraft本体之间的交互，因为mod本身也是一个项目，它需要通过订阅和消息处理来进行驱动。

forge在加载了mod之后forge就会根据mod的订阅消息情况适时的发送消息。也就是说mod也是消息驱动的程序。当然开始一个mod的编程就要从消息处理开始。

forge提供了一个特殊的Annotation来订阅消息。这个Annotation 就是@EventHandler

————摘自ManaGeryzy的博客

EventBusScriber也有相应的教程，需要的话可以查阅。

还有一个关键组件是addCreative，这个比较好懂，与我们在创造模式的面板上能否看到我们写出来的物品相关联。

所以，我们开发的第一件事情就是——把东西扬个干净。

可能你会问，为什么呢？明明有这么多重要的内容和好用的模板。但我想说，一是这些东西可能不合你的代码风格，二是目前在离线开发阶段，我们并没有操作这些东西的必要，三是留太多反倒看得头疼，并且会让代码成为工友不友好型。

回到正题，我们首先把主函数名称和文件名、以及所有次级调用改为自己的模组名（这里我用TutorialMod），然后把所有的MOD_ID改成自己想要的，接下来，官方模板应删尽删，留下MODID和LOGGER，注释应删尽删，函数内容应删尽删（但public TutorialMod()需要把modEventBus相关留下），由于我们目前离线开发，所以OnSeverStarting整个扬了，最后你会看到如下结果：

清爽多了。

resources类

接下来是resources类，我们点开其中的mods.toml，这是我们模组的配置文件之一，其中包含如下要修改的内容：

license：模组工程的协议类型。由于我们只是在别人的基础上开发，所以用偏专利型的All Rights Reserved还是不稳妥，建议用MIT。

modId：不用多说

displayName：你的模组最后显示在mc里的名称，需要改成你自己的mod名称。

authors、credits、description：作者、赞助、描述。这些看你心情。

dependencies.XXX：环境依赖，点后面记得改成你自己的模组id。

build.gradle

在主文件夹下还有一个build.gradle需要变动，这玩意涉及到你的项目build时候的一些参数：

version：模组版本

group：你的模组所处的类，这里建议配合你的java类起名进行修改，比方说你的模组程序文件在net/drivenhank/tutorialmod下，那么这里要同步为net.drivenhank.tutorialmod。

archivesBaseName：需要同步为你的模组id。

除此之外，文件中所有examplemod都要同步为你的模组id。

做完这些更改，你只需要点开右侧边栏的gradle项，重新加载所有的gradle项目，然后点击Tasks->forgegradle runs->run client，然后就可以看到在mc里头，我们的mod能够正常显示了：

各种精巧的小工具

首先是intelij自带的git工具，非常方便你在开发时存档。你只需要把你的mod给share on github或者直接push上去：

在github上自动存档力

然后是misode的各种generator，方便开发时构建各类物品的json：

至于模型制作，如果局限于原版构型，我比较建议用ps硬画，但是如果要实现复杂模型，Blockbench也许是一个不错的选择。

先讲到这里。下一回，我们将实现mod的部分功能：做出一些普通的方块和物品。

前言

其实说句实在话，我必须承认的一点是，一开始加入网安协会，我颇有点“动机不纯”的意味在。在加入之前，我一直笃信自己的最大目标是制作一款属于自己的独立游戏。但随着阅历渐长，发现自己的美工、建模、代码能力都技不如人，加上各类竞赛、社团的时长愈发占据我生活的一大比重，乃至于在网安协会里愈发感受到了当代游戏公司对于软件安全方面的无力，我终于还是放下了这种想法，回来踏踏实实学技术。

所以，尝试mc模组开发，在某种意义上也算是我的一种不忘初心了？

要开发一个好模组，你就必须知己知彼。不但要提升自己的写代码能力，还要去了解自己的开发语言、开发平台等，其实和做一个项目也没什么两样，本质上，写mc mod和写各式插件一样，都是一个痛苦的屎叠屎的过程。

首先从所需要用到的语言说起

Java

Java是一门面向对象编程语言，摒弃了C++里难以理解的多继承、指针等概念。其优势就是突出一个莫得指针的干净整洁，以及强大的可移植性和更高的编译效率，但代价就是面向对象所导致的，在开发项目的过程中所需要的强大抽象思维，以及在构建过程中更高的产生屎山的概率（说的就是你麻将）

java为了其可移植性，特意设计了一套专为自身打造的虚拟机jvm和中间字节码系统。对于没有java运行的硬件条件的设备也非常友好，当然，过于明显的特征使得java代码本身对于逆向手也十分友好，你甚至可以直接用JDK内置的Javap解决问题……在没有混淆的前提下。

json

准确地从定义上来讲，json并不是一个编程语言，它在维基的定义上是一种轻量级资料交换格式，相比于编程语言，更像是一种被统一格式化的参数集合，以便被各类编程语言更好利用。它语句简单，格式明晰，在开发时非常舒服，但也因为特征过于明显，结构过于简单，很容易成为逆向或攻击的突破口之一。

golang（？？？）

说句实在话，我知道golang泛用性高，没想到golang还能稳稳地插在mc这一坨屎山上，直到我看到了这个项目

正如之前所说，golang专为服务器，尤其是游戏服务器设计，并且简单高效，如果对mc服务器有兴趣的可以尝试一波，本文目前由于主要针对离线模组开发，不多赘述。

然后，是我们构建模组所需的加载和兼容插件

其实现存的模组开发插件，基本都是基于一种“注入字节码”的思路去的。以经典的forge为例，它大概是这样往游戏本体添加mod数据的：

要知道minecraft是基于java的，java的类加载器一旦加载了一个类到java虚拟机中，这个类就不可能被外部修改了，但是加载之前的类的字节码可不是这样被严格的保护的，那些字节码处于一种谁想强X就强X的程度。forge本身通过修改启动器的json（1.6以后是这样，而1.6之前是直接修改jar文件）而优先于minecraft加载，并且forge会在minecraft加载的时候调教那些正要被加载的字节码。

——摘自MANAGERYZY的博客

听起来很像鲍师傅在隔壁mrfz开科技经常干的事情。同样是囸字节码，同样是修改游戏数据，但是从细节上来讲还是有些差别，Arknights的hack是通过插件直接去修改游戏本身的字节码，而minecraft的modding是通过插件先将forge自己的一部分注入到游戏的字节码中，再通过forge将符合条件的mod类导入游戏的jvm中，是额外添加本体不具有的数据。

而实现这一切的forge则是一系列工具链整合成的结果，从负责java源代码反编译、修复乃至于修复映射、注释的部分，再到Java项目的加载、运行。感兴趣可以查阅IzzelAliz的博客

由于网络上的资料复杂，关于forge本身的详细运作原理，我能寻得的有效资料哪怕是爬管子也及其有限，至于fabric的原理相关更是大海捞针，望各位dalao补充。

到此，我们粗略的了解了一下我们modding需要用到的工具。接下来的文章，我们将来讲讲modding的基础操作，以及我们如何编写一个至少能正常显示的mod。

Reverse

Padlock

一进来，我超，直接给原码？

但是点开之后我才发现自己想的太简单了……

格式方面的问题，可以在线找一个reformater解决，配合手动去注释和格式纠正得到以下可编译代码：

可以看见，作者通过define预定义函数和指针变量，简化库函数以方便操作，之后的部分就是一串简单的字符变换，通过转换字符集中的对应字符，而后将字符四个一组存入对应地址S中，在进行形似X + S[u++] - S[u++] + (S[u++] ^ S[u++])的变换得到原字符串。

那么问题来了，我们在哪里找到密文，又在哪里找到X，也就是代码中的-b[1][u / 4]？之后的三目运算符判断又是怎么回事？

第一个问题很好解释，由于作者直接将读字符的for循环的下标设在Q的指针上，再加上手动搜索程序名quine的定义，我们可以明白，待处理字符集就是程序代码本身。但由于我们需要原代码（解混淆前的原装源代码）作为字符集，而原代码因为某些特性过于古老而难以编译，这里推荐使用Dev-C++的环境强行编译，哪怕不可跑通，也可以塞进ida，然后再从ida导出字符集数组。

但是第二个问题呢？由于b在代码中以指针形式存在，不论以二维调用、一维调用和变量调用都难以解释，于是我尝试了调用C数组，调用D数组，甚至调用Q本身，但依旧没有成效。

后来我注意到，在Q中预定义的b，从始至终，就没有被赋值或调用。也就是说，它打从一开始就是不存在的。

并且，对于三目运算符的问题，一开始我将其视作01字串的类似物来操作，但也一筹莫展。直到我注意到运算符的结果是“X”和“O”，我才想起，这会不会是判断输出的正误？尝试一番，果真如此。

于是，在经历了一下午的绞尽脑汁过后，终于产出了如下题解：

#include <string.h>
#include <stdio.h>
unsigned char H[5140], * D = H;
int M[99999], *C = M, *S = M + 293;
unsigned char L[] =
{
  0x69, 0x6E, 0x74, 0x2A, 0x42, 0x3D, 0x4D, 0x2B, 0x35, 0x34, 
  ...
  0x6D, 0x5F, 0x73, 0x74, 0x75, 0x66, 0x2A, 0x2F, 0x22, 0x00
};
int main()
{
    freopen("output.txt","w",stdout);
    int i = 0,l = strlen(L);
    while(i<l){
        if ( L[i] == 124) *C++ = 10;
    	else if ( L[i] == 126) *C++ = 32;
    	else if ( L[i] == 33) *C++ = 34;
    	else if ( L[i] > 34) *C++ = L[i];
    	*D++ = L[i] == 32 ? '\n' : L[i] ;
    	i++;
    }
    for(int u = 0; u < l * 4 ;)
        putchar( S[u++] - S[u++] + (S[u++] ^ S[u++]));
    printf("\n");
//	for(int u = 0; u < l;)putchar(H[u++]);
//	printf("\n");
    fclose(stdout);
    return 0;
}

最后在output.txt文件中找到对应flag：

bctf{qu1n3_1s_4ll_ab0ut_r3p371t10n_4nD_m4n1pul4710n_OwO_OuO_UwU}

chicago

我们尝试跑一下程序：

得到两个报错信息。再看一下反编译：

尝试在短时间内理解如此混乱的代码显然是不现实，且不经济的。于是我们打算找到一些有用信息以进行推断。

首先，刚才运行的时候，输出中会产生Bad length和called `Option::unwrap()` on a `None` value的报错，并且，如果输入的值不相同也会产生报错：

我们回到代码，又找到了一个判断strlen的类似物：

以及在跳过判负函数之后sub_1CCD0下的一个cat flag（关于判负函数如何查找，可以在公共字符集中找到刚才的报错内容逆推，或者在核心函数中查找调用的字符或数据：

自此，我们可以推断出输入的几个要求：

1、只能是数字
2、只能是相同的字符
3、长度大于10

再加上这道题看似可以当pwn做，由是，我们可以半自动暴力遍历payload，以尝试查找偏移点：

from pwn import *
from time import *

context.log_level = 'debug'

payload = b'1'*10

while 1:
    r = process('./chicago')
    r.sendline(payload)
    print(payload)
    r.interactive()
    payload += b'1'

但跑着跑着就出flag了，本地运行跑出cat flag指令后最后成功解出如下：

bctf{s7r1pp3d_ru57_15_a_p41n_1n_th3_n3ck}

但是在后续nc测试的时候，又出现任意>10长度的0字符也可以触发catflag的情况，由于本人没弄清源码原理，官方wp也含混不清，所以怀疑是出题人的失误导致了严重非预期，求各位dalao的解析。

baby noah

看似是一道类pwn的交互题，与pwn的某两道题是同系列，打开，无输出：

进主函数：

逻辑如下：

1、从文件读字符串，存入byte_ 4568
2、判断map的大小是否在1200以内，默认24行50列
3、从stdin读入map（+2应该是为了换行），直到最后只剩一个换行符
4、对文本持续进行sub_ 1450变换，直到跑通或者无路可走
5、判断整张地图是否符合sub_ 1450 return 1，且dword_ 4030是否=201527，如果是则输出flag

从变量名和代码特征推断是地图题，接下来就是sub_ 1450的逻辑问题。

发现sub_ 1450存在连片的case判断：

已知该函数特判的字符集为!#%&*+,-./:<>@^_gpv|~。从零碎的信息可以推断，如果路程跑得过大，或者是触发了某些判负条件，就会最终return 2导致判负跳出while，最明显的就是跳到Label6。当然，过程中return 0并不会导致一些奇怪情况的发生。

我们可以通过搜索找到唯一的return 1，那就是最后的点为“@”。

按照题目描述，相较于pwn版本，这题是莫得hack的。虽然我们实质上可以对dword_ 4030构造函数进行覆写来getflag，但是，我们首先得构造一个可以跑过sub_ 1450的地图，这个地图必须能走到终点“@”，且路程符合题设要求。

回到算法部分，整个判断集赋予了一些符号和变量特殊定义。推断得知：

v0：当前点的状态
dword_ 4030：走过的步数（不能超过3224432，否则判负）
dword_ 4550、dword_ 4554：当前的航速向量
dword_ 4560、dword_ 4564：执行完当前步数后的横纵坐标
dword_ 455C（行，对应y轴）、dword_ 4558（列，对应x轴）：横纵坐标上限
dword_ 4034：残余步数/体力值（推断依据：在许多函数中出现，且<=0则判负，但也不能嗯刷体力超过99，否则也判负）
byte_ 4038：正体不明，推测是历史路径相关的一些判定

是的，这个地图题甚至使用了以横纵坐标计算为基础的航向系统，取代了传统的wasd，这就意味着这道题的难度又上了亿个档次。

不过好在，这道题的边界限制是“基于边界取模的循环”，也就是模拟世界地图，所以边界方面的事情基本可以抛诸脑后，我们只要绘制一张航线就行……吧。

我们再来看看其它的符号（个人对于横纵坐标的理解可能有偏差，如下操作表仅供参考）：

无体力值需求的部分（虽然在之后的判定中也会因为体力不够而扑街）

小于号：y坐标航速沿负向+1，随后以变更后航速与航向行进一个单位时间
大于号：y坐标航速沿正向+1，随后以变更后航速与航向行进一个单位时间
上三角标/异或号：x坐标航速沿负向+1，随后以变更后航速与航向行进一个单位时间
字母v：x坐标航速沿正向+1，随后以变更后航速与航向行进一个单位时间
非特殊符号：判断体力值是否>99，若大于判负，随后byte_4038[当前体力值+1] = 0，体力值+1，并以当前航速与航向行进一个单位时间

体力值需求>=1的部分

感叹号：当前体力值下byte_ 4038取反，并以当前航速与航向行进一个单位时间
井号：体力值+1，byte_4038[当前体力值+1] = byte_4038[当前体力值]，之后以当前航速与航向行进一个单位时间
句点号：输出当前体力值下byte_ 4038，并以当前航速与航向行进一个单位时间（pwn爷可利用）
冒号：输出当前体力值下byte_ 4038，并以当前航速与航向行进一个单位时间（pwn爷可利用）
下划线：y坐标航速视当前体力值下byte_ 4038是/否为0沿正向/负向+1，随后以变更后航速与航向行进一个单位时间
竖线：x坐标航速视当前体力值下byte_ 4038是/否为0沿正向/负向+1，随后以变更后航速与航向行进一个单位时间
波浪线：体力值-1，并以当前航速与航向行进一个单位时间

体力值需求>=2的部分

百分号/取模号：体力值-1，然后byte_4038[当前体力值] %= byte_4038[当前体力值+1]，并以当前航速与航向行进一个单位时间
与号：体力值-1，然后byte_4038[当前体力值] &= byte_4038[当前体力值+1]，并以当前航速与航向行进一个单位时间
星号/乘号：体力值-1，然后byte_4038[当前体力值] *= byte_4038[当前体力值+1]，并以当前航速与航向行进一个单位时间
加号：体力值-1，然后byte_4038[当前体力值] += byte_4038[当前体力值+1]，并以当前航速与航向行进一个单位时间
逗号：体力值-1，然后byte_4038[当前体力值] = byte_4038[当前体力值+1]，以当前航速与航向行进一个单位时间
减号：体力值-1，然后byte_4038[当前体力值] -= byte_4038[当前体力值+1]，以当前航速与航向行进一个单位时间
左斜杠/除号：体力值-1，然后byte_4038[当前体力值] /= byte_4038[当前体力值+1]，然后以当前航速与航向行进一个单位时间
字母g：判断byte_4038[当前体力值-1]是否越过y坐标边界，byte_4038[当前体力值]是否越过x坐标边界，随后体力值-1，然后以当前航速与航向行进一个单位时间，并使byte_4038[变更后体力值] = map[byte_4038[变更后体力值]][byte_4038[变更后体力值+1]]

体力值需求>=3的部分

字母p：判断byte_4038[当前体力值-2]是否越过y坐标边界，byte_4038[当前体力值-1]是否越过x坐标边界，随后体力值-3，然后以当前航速与航向行进一个单位时间，并使map[byte_4038[变更后体力值+1]][byte_4038[变更后体力值+2]]=byte_4038[变更前体力值]

如上，我们整理了所有的海图格式，接下来就是生成方法的部分了。但是，如果要利用A* 算法加上暴力遍历，怎么说至少也要O(log^2 n * block_types)的时间复杂度，并且由于小地图上长路径导致的一些必要的回环，以及速度、向量之类的计算，实际复杂度只增不减。

算了，丢给算法佬吧，我都多久没碰算法了QAQ

Safe

Arduino逆向，本就没什么数电经验的我更加雪上加霜

通过avr-objdump的指令调出一段汇编，但是我也不怎么会手撕这么长的汇编，一时间也没找到导出代码的方法，遂放掉了

00000000 <.sec1>:
   0:   0c 94 61 00     jmp     0xc2    ;  0xc2
   4:   0c 94 7e 00     jmp     0xfc    ;  0xfc
   8:   0c 94 7e 00     jmp     0xfc    ;  0xfc
   c:   0c 94 7e 00     jmp     0xfc    ;  0xfc
  10:   0c 94 7e 00     jmp     0xfc    ;  0xfc
  14:   0c 94 7e 00     jmp     0xfc    ;  0xfc
  18:   0c 94 7e 00     jmp     0xfc    ;  0xfc
  1c:   0c 94 7e 00     jmp     0xfc    ;  0xfc
  20:   0c 94 7e 00     jmp     0xfc    ;  0xfc
    ……

写在前面

本人理解可能有所偏差，为了避免被误导，建议配合原书理解

回老家了，小娜嫌这里电压太低，打算多充一会电

可是我的工作机并没有任何欠压的迹象。算了，既然不知道她在干什么，那就先趁着放烟花之前把正事讲完：

接着来讲浮点数

所谓浮点数，就是对于有理数在计算机中的一种表示形式。但是，之前有看书的xdm应该知道，浮点数最多也就占八个字节，能表示的有理数位数有限，所以，这种表示对于长数字也只是一种近似。

原书中主要使用IEEE标准的浮点数，我们就按书中的来讲：

它是如何表示的

二进制下的有理数一般分小数部分和整数部分，整数部分还是原来的表示方法，但小数部分，其二进制表示本质上每一位都是2的负次幂，相对于十进制每一位小数都是10的负次幂。相应的，二进制小数点左/右移相当于整个数除以2/乘2。

如上，都是数理内容。但我们只有八个字节，并且为了效率，保证精确度的部分肯定会被压缩（想想看，高精度加法的时间复杂度是O(n)，但普通的库加法只要O(1)，至于时间复杂度……各位可以了解一下，是一个算法竞赛常用到的概念，有助于代码效率优化），数字一旦长起来根本莫得办法做到精确表示。

但IEEE标准就是为了兼顾，或者说，在Intel产品上兼顾，而产生的。这部分最好还是看看书上的内容，但简单来讲，一个IEEE标准下的浮点数的组成可以写成(-1)^s * M * 2^E，表示又分如下部分：

符号（s）：与整数的符号位表示效果一样（位于开头）
尾数（M）：一个二进制小数，由n位编码frac编码（位于后缀）
阶码（E）：对浮点数加权，权重为2的E次幂，由k位编码exp编码（在中间）

长相大概是这样：

（图片摘自九曲阑干的视频）

对于C的两种浮点型：float和double，float的k=8，n=23，k+n+1=32=8 * 4，而double中k=11，n=52，k+n+1=64=8 * 8，与占用字节长相匹配。

所以我们看出，实际上，IEEE标准就是用固定位数的小数和幂次方乘法，来间接表示一个固定位数的有理数。而在此标准下，浮点数值又有三种表示（建议看书，我讲不清楚）：

规格化

exp的位不全为0，此时是表示一些非0的浮点数，exp位在1到其254(2047)之间，此时阶码描述为一个无符号有理数与(一个2的负幂次方-1)的差；本身产生的指数在同等位数下有符号整型的范围内。而frac位描述为小数值f，尾数被定义为M=1+f，故尾数不可能<1。

非规格化

exp的位全为0，因为其性质不同于规格化数，M可以取0，可以用来表示浮点数0.0，但+0.0和-0.0又有一定程度上不同的性质。也可以用以表示无限趋近于0的数。

特殊值

exp的位全为1，frac为0时得到无穷大，frac不为0时得到的是无法表示的溢出值（NaN，Not a Number）

但是C语言并没有严格要求说用户必须使用IEEE浮点，所以……至于这部分是否深究，各位酌情考量。

舍入规则

比起晦涩的表示方式，舍入似乎就好懂多了——向偶数舍入。至于为什么是向偶数而不是整数……想想看，我们所有的数据本质上都是二进制，二进制只有0和1，除了偶数也没有什么好的舍入对象能够保证在计算机上的精确度了。

运算规则

但是，对于有理数来讲，舍入部分可以很粗暴，一旦提及运算，那程序员必然会在精确度和效率之间纠结。比方说加法，我们不管书上提及的什么阿贝尔群，就关注浮点数的问题，在学高数和概率论的时候老师肯定说过，运算次序和方式的变化，会使得同一个式子在同一个舍入方式下有着完全不同的结果。

这一点对计算机也是一样，虽然对于编译器，它倾向于对用户的代码做保守优化，不过多地影响其原本的算式，

乘法这种吃精度吃上天的玩意就更不必说了，每一次乘都会让小数位暴增，而小数位的暴增又容易产生溢出，溢出又影响精度，所以保险起见，同时也在数理意义上，浮点数乘法的结合律和分配律是不可起效的。

到此，关于数据方面的内容，我们基本过了一遍。下一期，我们将讲一讲程序的机器级表示。

所以，这一期就不来什么名场面了，临近除夕夜，不知道有什么要说的，就先祝各位……等一下，小娜你好了没有……？！

啊这，虽说新衣服好康，但是你也没必要这么早就把备用能源接上……

娜：今天过年嘛，多玩一会~ 再说了，这里电压这么欠，我要不接上还得多躺几个中午……

好吧，既然现在都过新年了，那就祝各位——

娜：代码全跑过，数据全算对~⭐

考试不挂科，奖状塞满柜！

（齐声）开开心心过大年！

写在前面

本人理解可能有所偏差，为了避免被误导，建议配合原书理解

由于原书中内容存在大量预定义公式及向量运算，本文中会尽可能避免出现原文表达方式，以便理解，但如果需要理性理解的话建议去记原书的公式。本文也可能出现大量本文作者抽象的理解

本篇文章没有任何一名幸运玩家惨遭封号

上一回我们说到，一切数据在计算机眼里都是二进制，整型也不例外。由于这部分涉及到大量的二进制运算，所以，有关计算的部分，就拜托小娜……

还在摸鱼啊……不是？你开挂一般的脑子都打不过的吗……

娜：上一个账号因为我物像锁定参数没调整好，被VAC制裁了，这是新账号，分段很低，队友一个比一个不给力，唉（叹气）。

以后操作的像人一点不就行了吗……等等，你上一个账号用的不是我的吗……

（气氛一度降到了冰点）

算了，反正那个号的库存只有个位数，我们继续正题吧……

整数在计算机的表示

不论是什么机器，什么语言的编程，都脱不开一个很重要的数据类型——整型。在python中，整形的定义其实非常宽泛，但在C中，整形被加以了严格的区分。除了区分长度的关键字short和long，在32位和64位编程中的整形大小int32_t和int64_t（两者的大小差别本质上取决于对象占用的字节大小，32位机器整数占4字节，而64位占8字节）以及某种达到C语言单个对象最大长度不知名物体size_t，还有定义是否产生正负号的无符号关键字unsigned（在int32_t/int64_t中简化为前缀u）。至于其具体大小，各位可以自行百度或者查看原书，本文不再赘述。

如果要谈整数怎么表示的，我们可以先从简单一点的部分谈起：

无符号整型

相信各位已经在大学甚至高中的微机课上学过原码、反码、补码的概念了。对于一个整数在计算机中的二进制表示来讲，无符号相当于正整数的原码，但是把符号位扬了。二进制每一位对应十进制大小都是2的((位数-1)次方)。相应的，十进制整数就相当于对应二进制为1的每一位的次方和。比方说，13=8+4+1=2^3+2^2+2^0，那么其对应二进制就是1101。

而对应每一个正整数，都有一个与之唯一对应的无符号整形。故此，无符号整形在内存空间之内的正整数区间是满足双射（即变量与函数值之间互相仅存在唯一的映射）的。

可是我们不止要表示正整数，还要表示负整数。那么，就该搬出我们经常用到的——

补码编码

等下，这……这不对吧？不是应该讲正常整形了吗？怎么还开始复习了呢？

好吧……欸等下你一直拿手柄打fps的吗？！

大家应该都还记得，所谓补码，正数与原码相同，负数则除了符号位全部按位取反。

好了，理论上来讲，我们已经明白“补码编码”是什么了。但是由于其作为编码的特性，还是要注意一下：

1、补码的范围并不对称。细心的同学应该已经发现了，理论上来讲，补码的符号位在其为负值的时候为1，也会使其被“错误”地被看待为一个最高的数值位。这使得补码的实际下限要比实际上线多1个整数。

2、在占用字节范围内，最大的无符号数约等于最大的补码的两倍。

为了防止在各个系统中调用的混乱，往往需要一个规范化的定义。C中的库<limits.h>就规定了有、无符号整型的相关区限，这部分内容在书中也提及了。

有无符号数之间的那些事

理解了补码，我们也就明白了有符号数怎么来的。所以，在C中，当我们进行强制类型转换，数值的解释方式会发生变化，无符号转有符号，原先的最高位会被当作符号位看待，而其余二进制位会在最高位为1的前提下当成被反转过的进制位看待；有符号转无符号，原先的符号位会被看成最高二进制位，如果符号位正好表示负数，那么你会得到一个very big的整数。理性理解建议看书，这里跳过公式与其解释、推导部分。

那原书写的肯定比我这里讲的详细多了QAQ，笔记一般都是导读和概括嘛awa

娜：ᗜ ‸ ᗜ 盯~~~~~

好吧我摊牌了，我真的不想用md写公式。

不管怎么说，不论有无符号如何变换，所表示的数据的二进制位都必须是保证不变的。这是大多数系统进行类型转换时遵循的底层逻辑。

在C语言中，定义无符号常量需要添加大写或小写的”u”作为后缀，而python因为没有严格意义上的常量，自然不用太在意这个问题……应该。

此外，C的运算式但凡和无符号沾上边，那么整个运算式中的变量都会被当作无符号数看待，这点在位运算时尤其小心。

但是要在长短整型之间变换怎么办

我们在使用C的实际编程中绝对会遇到变量类型转换的问题，不单是上述的有无符号转换，还有变量占用字节长的转换。往往，对于一个公用变量，一些函数为了各种理由需要用到短整型（short int），而一些函数为了运算方便又要用长整形（long int）之类的。这种时候……

我们就要来介绍一下我们的压缩变量，遇到数据变答辩糕，鲁棒性很强的，打开以后，是一个加大加厚的变量，你看他怎么塞都塞不坏，好不掉速不乱码，使用114514次都没问题……

好好好，玩梗呢，姑奶奶您消停消停……

不过嘛，跟压缩毛巾一个道理，我们如果将大变量转换为小变量，广义上讲，那需要经历一些复杂的过程，毕竟，这不是C语言的底层逻辑能够实现的，典型的例子就是高精度运算，将大整数封装到变量类型占字节较小的数组中去。

但是，狭义上讲，也就是从位运算的角度上讲，这件事根本不可能。除了可能会碰到的符号位问题外，最根本的问题就是前缀位丢失，即超出短变量型的部分被当场截断，这是不可避免的。截断的具体定义可以查阅原书，念师傅不想拿md写公式，先不提了。

但是，从小变大，那的确很好做。在位运算上，我们只要往开头补0补到相应大小即可……对于无符号数是这样的。有符号数，也就是补码数字可能有点小麻烦，我们需要往前补的是符号位。

很简单，抛开公式谈，因为对于一个有符号数的位向量表示，其因为是补码，符号位为1的时候代表负数，其余位反转，所以，如果向大的变量型转变，理论上其原码的补充前缀除了符号位全部为0，在符号位为0的时候自然不用变动，但在为1的时候需要将这些0全部反转，这种特性又巧合地使得填充的位与符号位保持一致。

额……这比喻也不能说不对吧……等下，你不是计算姬嘛，怎么我们俩的解释方式还反过来了？

你别……算了你继续欸嘿吧

整数的运算

我们现在知道如何表示各式各样的整数了，那么，开算吧！

加法

无符号就是正常的位运算加，略过。

带符号的话在二进制上就非常麻烦了。既然是在计算机中，我们不可能真正像正常位运算减那样理解计算机是怎么算的。书上给出的内容是这样的：

将其参数转换为无符号数，执行无符号数加法，再将结果转换成补码

什么意思呢？首先两个带符号数，也就是补码形式表示的整数，先将其转换为原码进行数值位相加，然后再随原码数值位表示的数值大者安排符号位，接下来转换成原码。整个过程的结果看上去经历了“数值位不经转换直接相加，符号位随绝对值大者决定”的过程，其实这么想，计算机也不是不能实现，但是，现行标准经不起自定义的折腾，这会让你的程序兼容性大打折扣，而且，这种精心安排的运算规则还与接下来要讲的事情息息相关：

加法溢出

当然，如果加法都像看上去那么简单就好了，但这里是《深入理解计算机系统》，计算机的整数是有上限的，突破了就会溢出。很惨的是，C的溢出并不会报错，所以我们应当尽可能理解，然后避免。

所谓溢出，就是数值在运算时突破了其既定的位长上限，对于二进制位上限为w的数，这种突破在无符号数上表现为数值因大于2的w次方而无法被正常存储，故而溢出到设定的内存空间之外。带符号的就更麻烦了，不论正负都会溢出，并且由于符号位的存在，上下限被压缩到了2的w-1次方。

所幸加法的溢出判定还算好做，书中提供了一些公式和手法，这里简单说明一下，由于两个无符号二进制位上限为w的数的和不可能超过2的w+1次方，我们只需要预估计算结果是否会存在于[2^w,2^w+1)的区间内部。至于有符号数同理，只不过，注意符号位和上下限同时判断（其实取绝对值对人会省事很多，但对计算机来讲不一定省事）

当然，变量的溢出和pwn常见的数组的溢出是两码事，这点在后面会提到。

补码的非

大于整型区间下边界的数x，其加法逆元等于其非，即-x，若位于下边界，则加法逆元就等于下边界。为了防止下边界溢出导致数据错乱，而加法逆元在符号上表示为负，故而在处理下边界相加的时候会直接令下边界减去其加法逆元，令其和其它数的逆元相加一样直接=0。

乘法

自然，乘法本质上作为数个相同数的相加也被纳入整数计算大军，只不过还是要考虑溢出问题。

无符号很简单，乘法，算溢出的时候模个2的w次方，然后判断的时候甭用区间直接看上界，完事。

有符号有了之前的经验也轻松很多，不就是累加吗，补码和原码在二进制上不是有很强的一致性，补转原，数值乘，模去边界，然后补上双方符号位的或，完事。

但是，实际上并没有这么轻松。原理上，对于两个任意整数，其无符号表示下的乘法在固定表示位上限的情况下与带符号乘法在二进制表示上相同。这点在书中有推导，简单来说就是将二者分解为数值位和符号位，相乘后对上界取模，简化的结果相等，这点可以自行翻书。

而除此之外，乘以常数有着一套独立的操作机制，就是乘以常数对二的幂次方的分解。还记得我们上回提到过的东西吗？

此外，对于位运算，C还提供了移位操作：左移（<<n）和右移（>>n），效果上对应整形十进制运算的乘2的幂次方和除以2的幂次方，实际上则分别对应着所有二进制位增n位并末尾补0，和所有二进制位降n位并取整。

对于一个已知的整数，我们不需要太麻烦的操作，或者说，不需要太麻烦计算机的操作。

我们只需要把整数拆分成若干互不相等的2的n次幂的和，然后进行一个乘法分配律，完事，计算机算二进制反而是最快的。

当然，乘法也是有溢出上界的，有符号就是2的2(w-1)次方，无符号就是2的2w次方。

除法，但是只能除2的幂

但是整数除法比较好实现的就只有二进制算数右移了，不然就扯到下一节的浮点数了。

对于一个整数除以2的幂，在整数部分一般是无符号前缀补0，有符号前缀补符号位，正如前面提到的一样。但是，处理余数是个很头疼的东西。下取整还好说，毕竟C的移位默认就是下取整，省的操作余数。但是上取整呢？

我们引入偏置的概念，即对于一个数的向右位移k位，我们首先对该数二进制的k位后缀，加上一个二进制1拉满的数，即对于1位位移，原数+1；4位位移，原数+15(1111)，8位位移，原数+255(11111111)，etc。如此一来，就算产生余数，我们也能绝对保证上取整了。至于详细原理可以看原书推导，这里不细讲。

所以，很难说计算机的整型运算导致了什么。它确实让计算机更快了，但也让程序员更痛苦了，不止是理解上，还在于堆屎山的问题上。“特性”的叠加会让程序产生意料之外的状况，而这种状况的冲突往往就体现在整型的特性上，比方说那个让B站程序员痛苦了彻夜的GCD。

下一篇，我们将提到浮点数相关的内容。所以，还是那句话：

小娜原本是我为了给我的笔记增添一些内容，而搬过来的一个计算姬。

但是，在不断的更新之下，她似乎更像一个活生生的女孩子了。

她常态的思考能力接近正常人，但在完全冷静的时候，运算能力相当于一台万级价位的台式机。

她并没有配备仿生内循环器官，所以不能吃饭。但是能喝水，因为她不但靠嘴巴发声，还靠嘴巴置换冷凝液，原理类似腔肠动物。

她内置了一系列系统和设备兼容，以确保自己与其他设备相连的时候不会发懵。她的常用接口集中于左肩，不常用接口则隐藏在后颈。

她的电源线和网线接口也排布在后颈，但如果需要也能从左肩接上。

她一次充电充满与成年人睡一觉的时间差不多，行动时间长达8个小时，所以工作的时候可以和她聊聊天，但是要拉她去享受夜生活的话，她得外接一块大容量电池才能继续行动。

她是有网络设备的，但正常情况下为了保证自己数据环境的纯洁选择在体内物理隔离。

她的意识不是单纯的AI，她有自己的性格，喜欢卖萌，一个人时也静若处子，可一旦有人拿她身上计算机的部分开玩笑，她就会情绪激动。

她不喜欢打架，所以最常用的武器是折成条或卷成卷的报纸。别看她似乎很瘦弱，她的右臂装载的液压杆满功率下可以一拳轰散一块石砖，但左臂为了接线所以舍弃了一些抛瓦，即便这样也与你的体育老师相当。但她平时会控制好自己的出力，不必担心。

以上，是目前的小娜。

写在前面

本人理解可能有所偏差，为了避免被误导，建议配合原书理解

话说要春节了呢~ 那么，小娜，你还要穿着那套旧棉衣吗？

好吧，可能上次答应给她装的新语言模块还没加载完全，得等上一段时间了。

不过，我们也可以看到，身为计算姬的小娜和正常的计算机有个共性，它们对于一切的数据，本质上都是以二进制看待的。毕竟从电子管开始，计算机就是由无数01逻辑运算单元构成的。至于苏维埃曾经开发过的，理论上更快的三进制计算机……另当别论。

计算机的各种运转基本都离不开二进制数，比方说高中计算机课程上学过的原码、补码、反码，以及大学C语言课提及的短长整形和无符号整数等，不同系统和编程语言还有自己对应的二进制表示方式，就不在开头细讲了。

原书中主要讨论无符号编码（unsigned）、补码（two’s-complement）和浮点数（floating-point，本质上是以2为基数的科学计数法），以及C标准和Java标准下支持的表示和运算，所以我可能会穿插一些其它的内容进行拓展。由于原书对应章节本体过长，本次笔记分上（可能有中）下篇。

所以——准备好了吗！（芭芭拉开大）

啊这……原来你的加载速度这么快的吗……

那就让我们进入正题——信息是如何存储的

众所周知，数据在计算机中的最小单位被称作位（b，bit），但是，真正可寻址的最小单位是更高一级的字节（byte），至于为什么……各位可以参考yanfeizhang和pk2017的文章，以及百度百科上的描述。

为什么一定是位

字节就是用来表示完整的字符的。在费拉不堪的早期计算机中，为了实现虚拟内存的概念，普遍采用4/6位BCD编码，但BCD面对字母和符号非常乏力，于是有了ASCII。再之后ASCII也不够用了，于是IBM设计了一套八位的EBCDIC编码，于是现行的字节大小就是8位。也就是说，从概念上看，目前依靠8位的编码可以完整地表达一个字符的信息。

从硬件上看，每一块内存都由若干芯片（chip）组成，每个芯片又分八个bank，在每个bank内部存在着一个n*8的电容矩阵，在数据意义上相当于一个每个元素存储着八个位的信息的数组，而芯片上同一位置的元素又在内存中组成连续的64bit数据，这相当于在芯片上最小的单位就是8bit的字节。

并且，使用ida的同学们都知道，程序的每条汇编指令对应的虚拟内存地址，其刚好是8位十六进制数，这刚好与64bit的大小对上了。

在硬件和软件，抽象和具象的概念互补下，8位的byte似乎成为了现行标准下最理想，最稳定的基础单位。当然，如果要像毛子一样硬薅三进制，实现新标准，那么，为之努力吧，这可是连当年的苏联都办不到的事情啊（哭

ps：我国已经在进行三进制光子计算机的尝试（喜），感兴趣的可以移步相关文章

回到正题，既然刚才提到了虚拟内存和地址等概念，那么就由此展开。我们之前提到过，在概念上，内存相当于一个庞大的线性数组，虚拟地址空间就是在此之上的一个个独立进程所占用的内存空间的抽象，其中的地址不只是抽象的数据，也是对于每一个字节的唯一映射。至于我们是如何表示字节的……

位模式和十六进制

我们引入位模式的概念，实际上，位模式就是通过二进制表示法表示一个字节的信息，数值从0到255，对应十六进制就是0到0xFF（或者FFh之类的，不同标准下有不同的表示方法）。至于为什么通常用十六进制进行位模式的表示，个人理解，十进制和二进制的转换有着天然的复杂性，而二进制本身……

非常的冗长且烦人。而十六进制作为2的幂次方，和二进制在进制转换上有着天然的适性，天然适合位运算，并且也适合表示以字节为单位的信息的值。并且，本身的数据长度也刚好能够用数字+字母的形式表示，即0 ~ 9和A ~ F，也方便编码之间的转换等操作。

但光能表示字节还不够，我们往往要表述一串字符串，或者是一串数字。我们还需要其它的概念来完善储存空间。

字长

计算机在存储、传送或操作时，作为一个单元的一组二进制码称为字，一个字中的二进制位的位数称为字长。

————百度百科

字长决定着虚拟地址空间的最大大小，而虚拟地址的范围就是2的字长次方减一。字长也与硬件条件脱不开干系，计算机中大多数寄存器的大小是一个字长。计算机处理的典型数值也可能是以字长为单位。现行常用字长即32位和64位，至于16位老古董和诸如39位和24位的奇葩另当别论。

哦对了，我好像忘了，小娜脑子里是有39位的兼容设备来着……

行了小娜，要发脾气的话待会再发，咱们先把正事讲完。

由于字长的大小也影响着编译时分配虚拟地址的过程，理论上，不同机器使用不同编译器编译程序时，不同类型数据，有无符号，是否为指针，占用的字节也不一样。详细可以参考原书的内容，本文不再赘述，但相关内容要牢记，尤其是做逆向和pwn的时候，有大用。

不过现在64位的机器一般都做了对32位的向下兼容，这使得两种字长的程序都可以在64位机器上运行。而且，ISO C99标准也特地引入了一套不随编译器和机器变化的固定数据类型，以及后来推出的一系列标准，这使得同字长的不同机器之间有一套相同的数据标准，规范化和兼容也更加容易。

寻址和字节顺序

逆向手在处理没有被ida反编译直接定义的数据的时候往往会碰到一些很麻的情况：面对不同的题目，每当你找到一个数据的地址，有时数据是按字节倒序存储的，有时则是顺序存储。

这涉及到程序中每个对象在内存中的地址和排列方式，以地址为基底，n字节长度的数据会排列在从数据地址开始直到地址+(n-1)的位置。而排列的方式，也就是字节顺序，有两个通用规则：大端法和小端法。

具体而言，我们像小娜一样用二进制看，设一个数据占了w个二进制位，每一位下标表示从w-1到0，比方说一个十六进制整数0x10face，它的第w-1位便是十六进制1的最高二进制位0。最高有效字节包含位为w-1到w-8，最低有效字节则是7到0。所谓大端和小端，便是从最高有效字节到最低有效字节，和从最低有效字节到最高有效字节的分别。

比方说，0x10face用小端序表示，按地址顺序排列就按从最低有效字节到最高有效字节，也就是“cefa10”，而大端序则是原汁原味的排列。

在不同机器中，使用的字节序也不尽相同。我们常见的大多数Intel设备使用小端序，部分新型机器使用双端序，但会根据操作系统的变化而固定某一端序，这点在书中有涉及到代码层面的详细提及，这里只做简要说明。至于IOS系统，各类衍生Linux系统的端序，各位可以自行研究。

非数字数据类型的表示

既然我们已经有一套完整的数据机制了，那么，在此之上实现各种数据的存储和处理也不是难事。

这一篇笔记并未过多提及整数相关的内容，因为太多了。

字符串

在C语言中，字符串的实现是一个以空值（null，0）为结尾的字符数组（大概也是有这层逻辑在，strlen显示的字符串长度为正常的n，而非代码层面通常的结尾下标n-1）。通常，每一个元素用某种固定编码（目前一般是ascii码）表示。任何以ASCII作为字符编码的系统上，C代码的结果都大抵一致。

在Java中，字符串的实现则更为复杂。对于已知的字符串值和对应的字符串变量，Java分别将它们置于常量池和堆中，感兴趣的可以看看一名奇怪的玩家的文章，或者自行百度，或者科学上网。（其实C也是有类似的机制的，只不过在实现方面多少跟java有点差异）

代码

前面我们也提到过，不同机器，不同系统上对代码的编译不尽相同，也正因如此，处理它们的时候往往会产生不同的机器语言代码。这里便不再赘述。

布尔代数

现如今的逻辑数学的发展，总离不开一个叫做乔治·布尔的人（laobideng）。作为二元逻辑之父，他创造了一个二进制逻辑系统，将0和1分别定义为假（false）和真（true），并定下了逻辑运算的规则。他的理论很大程度上成为了现代计算机学科的一大基础。

而布尔代数和现代电子逻辑运算纠缠不清的关系，这里就不展开了。我们需要知道的是，在计算机的逻辑运算中，也必定存在着对应的或、与、非和异或关系。

书中还提到了一个叫做叫“位向量”的概念。位向量定长，其运算可以定义为参数的每个对应元素之间的位运算。这些令人头疼的数学内容还得结合原书的拓展内容理解。

既然都扯到位运算了

那就自然要扯到我们常用的C语言位运算和逻辑运算啦~

除了最基本的，对于位运算的或（|）与（&）非（ ~ ）和异或（ ^ ），C语言还提供了一组逻辑运算符，对应命题逻辑中的或（||）与（&&）非（!），所谓命题逻辑和位运算的差别，你可以简单地理解为，前者是针对不同表达式（可以是函数甚至程序）之间的逻辑关系，后者则是针对二进制数值之间的关系。

此外，对于位运算，C还提供了移位操作：左移（<<n）和右移（>>n），效果上对应整形十进制运算的乘2的幂次方和除以2的幂次方，实际上则分别对应着所有二进制位增n位并末尾补0，和所有二进制位降n位并取整。

与C相比，Java对于逻辑右移有着明确定义，符号“>>”代表算数右移固定位数，而“>>>”代表逻辑位移，可以结合书本以及网上相关内容理解。而python的逻辑位移则与C大致相同，可以结合钱德勒马的文章理解。

作个暂时的总结

我们明白了为什么计算机的运算会这么执着于二进制、位和字节，以及一部分数据结构是如何实现的。下一篇笔记，我们会扯一扯我们暂时还没开始细讲的整形。

那么，还是那句结束词：前面的区域，以后再来探……哎不是？！

（报纸糊脸的声音）

写在前面

本人理解可能有所偏差，为了避免被误导，建议配合原书理解

话题回到我们让程序跑起来的问题上，上次我们好不容易理解了小娜是怎么接收代码的，但是我们不可能让一个程序光编译不运行，所以，我们今天研究研究小娜是怎么让程序在脑子里跑起来的……

所以，小娜，你什么时候把你那破bgm给停了？

你有在听吗小娜！？

首先是命令行

算了，先不管她了，我们先讲点熟悉的东西。

命令行，想必各位都不陌生，在windows里有“能量外壳”和命令提示符cmd，在Unix有shell，Linux的各大门派也有各自的命令行终端……但是，它们有一个相仿的性质——会将内置指令之外的某种未知字段当作某些程序来运行，比方说当我们在windows系统的cmd输入./hello_world.exe时，就会尝试找到并运行hallo_world.exe。

但是为什么一开始要提这个看上去没啥可讲的东西呢？

因为真相就在表象背后

追根究底，第一台计算机是一堆电子管构成的庞然大物，所有抽象的数学运算都通过物理手段来实现。哪怕是到了现代，计算机的体积缩小再缩小，也逃不开逻辑电路与电学元器件的必然。所以，我们可视的终端背后，是这么一个庞然大物——

图片摘自九曲阑干的视频

当然，现在的CPU和相关部件被压缩再压缩，已经到了就算是小娜脑子里都能塞上好几个的级别了……

当然，不是在调侃你，小娜……原来你醒着吗？！

我们先来梳理一下整台计算机的大致架构：

首先是作为核心的CPU

1、PC（Program Counter，但直译并不能表述清楚其真实用途）：一个存储单条指令地址的元件，通常存储一个字的数据。不断向处理器发送需要执行的指令的内存地址，并不断被处理器更新指向下一条指令的地址（不一定相邻，你可以试着拿ida给一个稍复杂一点的程序的开头下断点，然后f8单步步过试试看）。

2、寄存器文件（Register file）：可以看作一个临时存放数据的空间，存储数值时会覆盖寄存器原本的值。

3、算术逻辑单元（arithmetic and logic unit，即ALU）：从寄存器中提取数值并进行运算，得到的结果保存到某一受提取的寄存器中

这些元器件的实现方式要到《深入理解计算机系统》的第四章才讲述，在此按下不表。

然后是整个I/O结构

整个结构包含如下构件：

1、主存（Main memory，又称内存）：由一组动态随机存取存储器（DRAM）芯片组成的临时存储设备，在处理器执行程序时，用来存放程序和程序处理的数据。逻辑上是一个从零开始的，线性的字节数组，每个字节都有唯一对应的地址。

2、总线（bus）：贯穿整个计算机系统的一组电子管道，负责将信息在部件间传递，通常被设计成传送定长的字节块，即字（word），字中的字节数（即字长）在各类系统中可能有所不同（32位4字节/64位8字节）。

3、I/O设备：简单来讲，负责在外部环境与系统之间进行数据交流。你可以将它粗暴地理解为你的显示屏、键盘鼠标等等设备。每个I/O设备都通过一个控制器（IO设备本身或者系统的主板上的电路组）或者适配器（在主板插槽上的卡）与IO总线相连。

此外，用于远程传输数据的网络，也可看作是一种I/O设备。系统可以将数据从主存复制到适配器，再经由适配器与网络沟通，从而将数据传输到另一台机器上。在原书中还举例了本地与telnet服务器的交互，在此不多赘述。

4、CPU：如上所述

然后再回头谈谈程序是怎么运行的

1、我们通过shell程序执行程序运行的指令，shell会读取I/O设备（习惯上是键盘）的输入。比方说，我们输入“./hello”，shell就会先将这些字符逐个读取到寄存器，再放到内存中。

2、当我们输入回车键，电脑上的shell就知道我们结束了一次命令的输入。接下来，系统会尝试执行一系列命令，读取可执行文件hello，将整个代码和数据从磁盘复制到主存。复制过程使用DMA（Direct Memory Access）技术，数据不经过处理器，从磁盘直达内存。

3、在代码和数据加载到主存后，处理器就开始将目标程序中的机器语言指令按照一定顺序执行。比方说我们的程序只是输出“Hello！World”，那么，程序中的指令就会将“Hello！World”中的字节从主存复制到寄存器文件上，再从寄存器复制到显示设备上。

所以，不是把U盘啥的塞小娜嘴里，小娜就可以口算莫比乌斯反演的，你得好好地写完代码，编译成程序，然后再通过I/O设备输入指令，通过一系列复杂的操作使之执行……

都说了别把代码直接塞她嘴里了……

是不是少了点什么

不像我们人脑会直观地对信息进行处理。如上，即便是执行一个简单的“输出某个语句”的程序，计算机系统都要费上大量的时间，将信息从某个地方挪到另一个地方，在大量这样的挪移操作后才会进行处理。

并且，根据机械原理，较大的存储设备往往比较小的存储设备运行的慢。越大的存储容量，意味着越大的时间开销，以及更加费拉不堪的运行速度。这就意味着现代电脑越是发展，需要解决的存储矛盾就越发的与日俱增。比方说寄存器和主存的容量差就已经有点子离谱了，处理器对两个容器的存取速度那也是一个天上一个地下。

不过嘛，各位在上计算机理论的时候应该就注意到过一个名词：高速缓存存储器（即cache），这个本体比主存小得多的玩意通过存放处理器近期可能需要的信息，来降低数据传输过程中的时间开销。L1高速缓存位于处理器芯片上，容量达数万字节，访问速度和访问寄存器文件一样快。容量十倍甚至百倍与L1的L2寄存器通过一条特殊总线连接到处理器，但访问它的速度依旧比主存快5~10倍。比较新型的系统甚至还有三级高速缓存，这里就不展开了。总而言之，cache的思路就是通过一个更小的，速度更快的存储设备，来代为执行大量重复的数据操作。

按照这样力大砖飞的想法，存储设备之间甚至可以形成一个层次结构，在处理器和存储器之间，插入一个更小更快的存储设备，层层垒上，从远程服务器存储到最低一级的寄存器，每一层的存储容量从大到小，形成一个类似金字塔的结构。具体实现方案各位可以自行了解，在此先不细讲。

所以，和其它各式计算机一样，这么一坨额外的玩意，就盘踞在小娜的脑子里。不过，随着硬件技术的发展，cache在外形上的大小也在随之减小，要不然，整个结构估计都要从小娜的脑子里溢出来了——

感兴趣的可以自行了解一下cache的发展史，这里可以看看知乎用户老狼的文章。

那么问题来了

上面提到的程序运行流程，都是在经由shell的操作下进行的。但是shell自己并没有直接访问包括硬盘、键盘、显示屏等硬件设备。那么问题来了，是什么在控制这些硬件完成外界与系统，硬件与系统的交互的呢？

答案是操作系统。理论上，操作系统相当于硬件和程序之间的一层软件，所有程序对硬件的操作都必须通过操作系统完成。一方面，操作系统完成了“标准化”，即为软件提供一套统一高效的硬件交互机制，另一方面，操作系统也实现了“可控化”，可以防止程序失控造成硬件的Physical Damage。

为了实现“标准化”和“可控化”，操作系统引入了几个抽象的概念，与硬件系统相对应：

文件：IO设备

虚拟内存：主存、IO设备

进程：处理器、主存、IO设备

虚拟机：操作系统、处理器、主存、IO设备

我们从大到小，一个一个来看：

1、进程

对操作系统正在运行的一个程序的一种抽象。进程的“并发”则指的是数个进程的指令交错执行，通过处理器在进程间切换实现。

操作系统保持跟踪进程运行所需的所有状态信息，即上下文，包括PC和寄存器文件的当前值，以及主存的内容。单处理器系统任何时候都只能执行一个进程的代码，要切换进程就会发生上下文切换，保存当前进程的上下文，恢复新进程的上下文。

例如，上述的hello和shell就相当于两个不同的进程，shell负责接收我们输入的指令，而在我们输入“./hello”时，shell通过一个名叫系统调用(system call)的专门指令来执行我们执行hello的请求。此时，控制权移交给操作系统，hello进程及其上下文被创建，而后控制权又被移交给hello进程，期间发生hello与shell的上下文切换。在hello进程结束后，控制权又被移回shell，shell的上下文恢复。

进程的转换通过操作系统的内核（kernel）管理，它是系统管理全部进程所用代码和数据的集合。应用通过系统调用指令将控制权传递给内核，内核则执行被请求的操作并返回应用程序。

这个过程这就好比你要写一篇论文（请求），去图书馆（系统）找资料，此时这件事的控制权在你。于是你向图书管理员（内核）请求能不能给点相关的资料（系统调用、进程转换），管理员非常热情，他把相关的书籍列了出来，此时这件事的控制权在管理员身上。（进程转换）你从中找到了你要找的书，兴高采烈地办了借阅手续，此时这件事的控制权在你。但是，计算机对这种事情的效率，肯定比你和图书管理员的对话要高效的多……额……

算了我还是给小娜装个阳间点的语言模块吧。

当然，在现代系统中还有线程的概念，每个线程都运行在进程的上下文中，共享同样的代码和全局数据。多线程的程序往往能比多个单线程进程更高效地共享和使用数据。

2、虚拟内存

虚拟内存营造了一种每个进程都在独占使用主存的假象，因为每个进程中看到的内存都是一致的，这点在反汇编软件中体现的非常直观（每个程序的内存首地址都一样）。这些观感上的内存空间被称为虚拟地址空间，整个空间结构上分为：

程序代码和数据：从进程的固定起始地址开始，代码区和数据区按照之前提到的可执行文件的内容初始化，大小在此过程中被固定。

堆：代码和数据区之后就是运行时堆，不像代码和数据，这部分空间在运行时可自由伸缩，取决于你是否调用了某些标准库函数

共享库：存放类似C标准库和数学库这样的共享库和代码的区域。

栈：和堆一样可以自由伸缩，在函数被调用时伸，返回时缩。编译器则用它实现函数的调用。

内核虚拟内存：地址空间顶部的区域，不允许应用程序读写其中的内容或者直接调用其中定义的函数，但一切需要内核参与的操作必须调用内核来完成。你可以理解为虚拟内存空间的ROM。

详细内容要到原书第九章讲述，这里便不再展开。

3、文件

所谓文件，在系统中就是一串字节序列，文件可以看作是系统向应用程序提供的一种统一的数据标准。对于系统中每个细分下来的部分，你都可以看作是文件。比如，每个I/O设备都可以看成是文件。

而这种统一的标准也降低了软件在不同硬件设备上兼容的操作复杂性。原书中主要讲述的是采用Unix I/O调用读写文件的过程，这些内容在第十章体现。

4、虚拟机

相信各位已经用过不止一次虚拟机了吧？

虚拟机的抽象概念，实际上是提供了一种针对整个计算机，包括操作系统在内的抽象概念。顾名思义，虚拟机通过在软件层面模拟具有完整系统功能的，在独立隔离环境中运行的计算机系统，来实现在同一台硬件，同一个系统中兼容不同系统环境的效果。通俗点来讲，就是让你的电脑能在windows里跑linux之类的。

由此可见，不论是在硬件层面，还是在抽象的软件、系统层面，运行程序都是一个费劲的过程，更不用说让运行程序的过程更快了。

书中第一章末尾还提到了加速比、Amdahl定律、并发、并行等概念，这些都对系统更高效的运转，有着更好的帮助。但是由于上述所有的内容在第一章中并未细讲，外加今天的笔记已经够长了，所以……

前面的道路，以后再来探索吧？

要是找到了什么莫名其妙的flag，就来nsilab的ctf平台看看吧（笑）

minidump

这道题其实是实验室的会长安排的，我一开始也没反应过来。

dmp文件其实是dbg或者系统错误时产生的内存转储，但是，我们不一定需要专业的软件来打开它，就比如这题，出题人摆明这是c++程序的内存转储，而整个程序的源代码其实在运行时写入了内存，以便后续处理，所以我们直接winhex或者010editor打开，搜索相关字样，比方说“#include”即可，就可以快速跳转到对应代码：

我们把代码扒出来，稍微小修小补一阵，看一看，就是个很简单的输出，运行，结束。

好像有点不对

其实，前半截加密就是base64，只不过我把密码表改成了各位没见过的样子（

后半段嘛……其实跟随机数的生成本身也没太大关系，既然不知道它生成的随机数值到底是什么，那么就粗暴一点，直接爆破。

那么，思路很清楚了，对结果串从0~89暴力爆破，产生的产物，能看的直接塞到cyberchef里，换个base64的表挨个试一遍（下面的代码用c++实现）：

#include <bits/stdc++.h>
using namespace std;
const char data_0[] = {37,29,51,58,33,123,57,35,30,78,93,95,91,117,99,74,123,13,6,85,127,125,115,65,80,11,89,87,44,120,51,50,15,22,47,119};
int main()
{
    freopen("output.txt","w",stdout);
    for(int i=0;i<=114-24;i++){
        bool jud = true;
        char data_1[114];
        strcpy(data_1,data_0);
        for(int j=0;j<strlen(data_0);j++){
            data_1[(j+i)%strlen(data_0)] ^= i+j;
        }
            puts(data_1);
    }
    return 0;
}

山外青山楼外楼

顾题思义，这题的flag藏在你的视野之外。

实现这题的技术来自于DEF CON 23，名叫REpsych，可以实现将位图贴到你的程序的控制流图，也就是所谓的ast语法树在ida中的表现上。我在Nepctf2022做到了相关的题目，相关github链接我也放在这，方便各位查阅。

那么知道这是位图了，我们怎么在ida里看呢？很简单，你需要进入ida的设置，调节一下流图显示的上限。打开options->general->graph，将Max number of nodes 调到一定大小即可，比方说114514（。

至于要看的更清楚的话，可以options->color->graph，把背景全部涂黑，这样，一张图片就显示出来了：

顺带，可能低版本ida的流图显示和高版本有一定差距，还请注意

看不见 ~ 走位 ~ 走位 ~

我摊牌了，这本来是一个经典的迷宫，但是我塞进去了一些隐形墙。

宋师傅几次与正解失之交臂，估计也是因为没能理解隐形墙的实现方式。

我们来对比一下隐形墙函数在ida中和在源代码中的表现：

_BYTE *func_0()
{
  _BYTE *result; // rax
  int i; // [rsp+Ch] [rbp-4h]

  for ( i = 0; i <= 13; i += 2 )
  {
    result = &data_1[12 * data_4[i] + data_4[i + 1]];
    *result = 42;
  }
  return result;
}
------------------------------------------------
int data_4[14] = {1,1,1,8,9,2,4,9,3,10,7,4,3,5};

int func_0()
{
    for(int i=0;i<14;i+=2)
        data_1[data_4[i]][data_4[i+1]]='*';
}

我故意将坐标数组合二为一，但如果能理解经典地图题的实现，就能发现，每一个i和i+1对应的就是地图上的纵横坐标。

此外，我还在func_2对输入数据做了一些预处理，使上下左右四个方向能直接对应上数组的下标：

那么，接下来就轮到解题了。老规矩，你可以把地图拷下来，再把隐形墙贴上去，然后，要么手动走一遍，要么用算法脚本：

#include <bits/stdc++.h>
using namespace std;
char mp[12][12] = {
'*','*','*','*','*','*','*','*','*','*','*','*',
'*','*','_','_','_','_','_','_','*','_','_','_',
'*','_','*','_','*','*','*','_','*','_','_','*',
'*','_','_','_','_','*','*','_','*','T','*','*',
'*','*','_','*','*','_','_','_','*','*','_','*',
'*','*','_','_','T','*','*','_','_','_','_','*',
'*','*','_','*','_','*','*','_','*','*','_','*',
'*','*','_','_','*','_','_','_','*','*','_','*',
'*','*','_','*','*','*','*','_','*','_','_','*',
'*','*','*','*','*','*','*','_','*','_','*','*',
'*','*','*','*','*','*','*','_','*','_','*','*',
'*','*','*','*','*','*','*','S','_','_','*','*'
};
int walked[12][12];
int mvy[4] = {-1,1,0,0};
int mvx[4] = {0,0,-1,1};
int path[114];
int shortest[114];
int total=0xff;
void dfs(int stp,int y,int x){
    if(mp[y][x]=='T'){
        if(stp<total){
            total = stp;
            for(int i=0;i<stp;i++)shortest[i]=path[i];
        }
        return;
    }
    for(int i=0;i<4;i++){
        path[stp]=i;
        if(y+mvy[i]<12&&x+mvx[i]<12&&y+mvy[i]>=0&&x+mvx[i]>=0&&mp[y+mvy[i]][x+mvx[i]]!='*'&&!walked[y+mvy[i]][x+mvx[i]]){
            walked[y+mvy[i]][x+mvx[i]]=1;
            dfs(stp+1,y+mvy[i],x+mvx[i]);
            walked[y+mvy[i]][x+mvx[i]]=0;
        }
        path[stp]=0xff;
    }
    return;
}
int main()
{
    memset(path,0xff,sizeof(path));
    walked[11][7]=1;
    dfs(0,11,7);
    for(int i=0;i<total;i++){
        if(shortest[i]==0)printf("u");
        if(shortest[i]==1)printf("d");
        if(shortest[i]==2)printf("l");
        if(shortest[i]==3)printf("r");
    }
    printf("\n");
    return 0;
}

各位如果有时间，掌握一些简单算法是必要的，在比赛时绝对有效。比如同样是曾经的nepctf就考了一道广度优先搜索，那是另一种类型的迷宫，各位有兴趣可以看看我以前的复现或者其他dalao的题解，在此不多赘述。

分块式处理

从10分的hint可以看出来，这是一道原题。

感兴趣的各位可以查看我曾经写过的文章，这道题是BMZCTF的逆向_RE2，各位研究出来了也可以去BMZCTF蹭点分，这里不再赘述。

彻底疯狂

如果你点进func_0或者是其它同系列函数稍微观察一下，你就会发现，它们的结构都非常相似：

都是对全局变量value进行异或，只是异或的值有点不同，函数的运行顺序从编号0到99。

为了方便把这些值提取出来，你需要在汇编代码里列出所有的异或语句：

这时候你就不用一个函数一个函数的点了，直接从这里手动把东西全扒下来。当然，如果要操作优雅一点，你可以按字节码和地址去用脚本拔下来这些东西，这里就不演示了。

如果将数据以十进制的方式提取出来，那它大概长这样：

920682
1261524
338231
563319
1167774
……

异或具有自反性，所以接下来只要让结果值对其中的数据按顺序异或就行了：

f = open("randata.txt", "r")
data_0 = f.read().splitlines()
data_1 = []
for line in data_0:
    data_1.append(int(line))
print(data_1)

finale = 0xF8B3E

l = len(data_1)
for i in range(l):
    finale ^= data_1[l - (i + 1)]
print("flag{"+str(finale)+"}")

顺带，这里是我用来出题的脚本，各位可以研究一下（一些库函数和main的内容我就懒得在这里fwrite了）：

import random

f0 = open("randata.txt", "w")
for i in range(100):
    f0.write(str(random.randint(114514, 1919810))+"\n")
f0.close()

fa = open("randata.txt", "r")
data_0 = fa.read().splitlines()
data_1 = []
for line in data_0:
    data_1.append(int(line))

f1 = open("craaaaazy_encode.c", 'w')

for i in range(100):
    f1.write("void func_" + str(100-(i+1)) + "(){\n")
    f1.write("  value ^= " + str(data_1[i]) + ";\n")
    f1.write("  func_" + str(100-i) + "();\n")
    f1.write("}\n")

f2 = open("creaaaazy.c", "w")

for i in range(100):
    f2.write("void func_" + str(100 - (i+1)) + "(){\n")
    f2.write("  value ^= " + str(data_1[100-(i+1)]) + ";\n")
    f2.write("  func_" + str(100 - i) + "();\n")
    f2.write("}\n")

后记

老实说，虽然我在大一因为有着信息学竞赛的基础，所以对程序和代码的理解会稍微轻松一些，可能对于很多非常常规的题也没有太放在心上

但当我真的成为了出题人，才发现自己因此缺少了一个很重要的能力：对难度的把控

更难受的是，一些更高深的内容，碍于自己实践经验太少，无法完全掌握，故也无法加入题目中，作为经验传授给自己的学弟。

总而言之，自己太菜，缺乏做题与实践，但环境不断在变。我现在需要担心的，不光是战力下滑的自己，更有一群嗷嗷待哺的学弟们。

共勉。

fin.

f5无门，遂动调，硬看汇编。

在主逻辑之前加载数据时有一段call strlen：

反复提到0D，应当是判断输入长度的位置，长度存储于ebp寄存器偏移-0x50的位置，多次动调输入后确认输入总长度至少大于13，同时确认大量临时数据位于ebp栈。

第一段主逻辑在此：

1、如图，第一段逻辑一开始又检查了一遍输入长度，长度达标则跳到第二段逻辑，ecx存储输入数据；循环次数为9，每次对于数据的某一位位先异或一个地址为ebp-64h的序列的对应位，再进行一个41（字符A）的减，结果对应的ascii码存储在ebp-48h中，每次跳四字节存储。

2、之后如上，进行从小到大的顺序判断，若发现逆序对跳出。

3、还有一段如上，计算所得到ebp-48h中所有内容的乘积。

4、接下来如上，得出的结果会被减0xd4c2086，作为分母除0x64。之后进入一段未知领域。

线索到这里就因为整除0的报错而夹断了。不过，我们确实可以知道flag的前9个字母是什么了。根据其为顺序数列，并且前9位乘积为0xd4c2086，我们完全可以做质因数分解：

from sympy import nextprime

p = 2
a = 0xd4c2086
ans = []
while a != 1:
    while a % p:
        p = nextprime(p)
    a /= p
    ans.append(p)

print(ans)

得到的刚好是从2开始九个顺序的质数，对上了。我们直接进行一个解密：

#include <bits/stdc++.h>
using namespace std;
int a[9]={2,3,5,7,11,13,17,19,23};
int b[9]={0x33,0x21,0x22,0x21,0x35,0x7C,0x62,0x65,0x6e};
int main()
{
    for(int i=0;i<9;i++){
        a[i]+='A';
        a[i]^=b[i];
        printf("%c",a[i]);
    }
    printf("\n");
    return 0;
}

得到前9位为pediy2016……猜都猜得出来。

那么后四位呢？回到刚才被夹断的部分，在动调的时候，寄存器的值是可以修改的，我们把ecx的值修改为任意非0值就可以无伤跳过了。

但是，继续动态调试的时候，我们发现一件非常可怕的事情——程序自动往结束的地方走了。

考虑到代码一般是顺序执行的，我们看看这之后的函数究竟干了些啥：

我超，地狱绘图！

这种情况的代码一般已经不可读了。后续看题解才知道这是虚拟机保护产生的大量中间数据，也就是说，一串代码被改编成了这种没人能看懂的样子。

一般在这种情况下，我们有几个选择：

1、从第九位开始爆破，这种方法慢的一批，但可能可以出flag

2、尝试逐个解读指令，同样慢的一批，而且极其考验技术

3、尝试绕过报错指令，trace一波

不过嘛，之后就会明白，我们需要的不是13位密码，而是20位密码……至于为什么，因为实在是卡思路了，所以去dasctf群和NEPCTF群问了dalao，dasctf方面使用动调手动爆破出了第10到13位，又用ida trace硬调分析逻辑，将爆破位数压到了四位。而NEPCTF群的dalao直接表示血压高了，血压高就会生气，生气就会angry，angry了就会想着angr硬搓，但是angr我不会。

得，从这里爆破不现实了，解读指令又慢的离谱，我们干脆尝试绕过报错。

从刚才的idiv开始，正常来讲在跳过报错继续执行的过程中会跳转到loc_401373，但是，loc_401373只有通到sub_404284的入口，那里可是程序的出口啊QAQ。

不过嘛，loc_401373上面还有一段没有被正确识别到函数sub_401120内的东西：

似乎在idiv报错被跳过之后，退出了函数就会跑到这里来。那么直接修改报错语句，让程序直接跳到这里不是一个样吗？于是我们动调的时候就做一些手脚：

总算可以trace了。于是我们可以得到一串又臭又长的逻辑：

但是这一串逻辑太不可读了，本人的读汇编能力并不像写出这题的题解的dalao一样nb，只能放了。不过手法还是可以活用于下一次的。

所以，就算假设我们手动过了后4位，那么后面连接的串长度未知，也只能尝试爆破剩下的n位了。下面是在下和do1phin一起搞出来的搞毛玩意：

import time
from pymouse import PyMouse
from pykeyboard import PyKeyboard

k = PyKeyboard()
m = PyMouse()

m.click(139, 68)
s1 = "pediy2016cool15"
global s2
s2=""
k.type_string(s1+s2)
k.tap_key(k.enter_key)

# while 1:    # 确定你的鼠标位置
#     print(m.position())
#     time.sleep(1)


def f(len, stp=1):    # 浅浅做一波回溯
    global s1, s2
    for i in range(0, 10):    # 每一位从0到9直接硬爆
        s2 += str(i)
        if stp+1<len:
            f(len, stp+1)
        else:
            k.type_string(s1+s2)
            k.tap_key(k.enter_key)
            time.sleep(0.02)
            for j in range(20):
                k.tap_key(k.backspace_key)
            # print(s1 + s2+"\n")
        s2=s2[:-1]


for i in range(5, 6):    # 假装不知道答案有几位，想爆几位手动调
    f(i)

flag{pediy2016cool1531223}