简介华中科技大学计算机系统基础课程实验报告打包为单个Word文档共1个文件压缩包约1.6MB面向计算机专业本科生及自学计算机系统底层的开发者。报告完整覆盖三个实验数据表示、Binary Bombs与缓冲区溢出攻击其中数据表示部分深入讲解整数补码、IEEE 754浮点数编码及lsbZero、byteNot、byteXor、logicalAnd、rotateLeft、parityCheck等位操作函数的实现思路Binary Bombs部分通过拆解二进制程序强化汇编与逆向分析能力缓冲区溢出部分则阐明栈溢出原理、返回地址覆盖及防御方法。文档含课程实验报告封面、目录与实验总结结构清晰便于对照复习与撰写同类报告。目前已有1386人学习下载适合需要系统掌握位运算、补码与浮点处理并希望获得可参考实验范式的读者。1. 计算机系统基础实验报告代码能跑并不代表报告能拿高分《计算机系统基础》的实验通常不只看代码是否通过报告占总分比例往往超出预期。我见过不少同学把报告写成代码说明书贴一整段源码、补几句注释就交结果分数明显低于版本代码跑通的预期也有同学代码只完成七成但报告把失败原因和调试过程写得很清楚得分反而靠前。这篇文章想解决一件事怎么把实验报告从流水账改成可复现的记录让读者看到你做了多少也看到你会不会思考。适合正在赶报告的在校生、想掌握评阅尺度的助教以及想把这种能力复用到其他实践课程的开发者。2. 实验类型决定报告写法位运算、二进制炸弹、缓冲区溢出各有侧重很多同学拿到实验题目第一反应是“代码跑通就万事大吉”。但从课程考核的角度看不同类型的实验老师想看到的东西完全不一样位运算实验考的是你有没有把数据表示吃透二进制炸弹实验考的是你能不能按线索把程序逆向拆解缓冲区溢出实验考的是你对内存布局和指令流的理解。报告如果不按类型组织很容易写成千篇一律的“需求分析—实现—测试”流水账丢掉每个实验最值钱的观察结论。2.1 三类典型实验的观察点从解题路径到调试过程的差异先分辨实验类型再决定报告重点。以最常见的三类实验为例。第一类是数据表示与位运算实验也叫 Data Lab 或位运算作业。你被要求用受限的位运算符如! ~ ^ | 实现一系列函数比如判断某个数是不是最大值、统计二进制中 1 的个数、实现逻辑右移等。这类实验的难点不在跑通而在解题路径。报告里最值得写的是你是从什么约束出发推导的比如符号位如何借位、溢出如何绕过受限操作符表达。如果只贴最终代码等于把最值钱的思路扔掉了。我一般会在报告里画一张约束表列出每道题允许的操作符集合和操作数上限然后写清楚每一步化简的逻辑。助教看到这张表就知道你是真的推过而不是猜的。第二类是二进制炸弹实验也叫 Bomb Lab。它给你一个二进制程序每个阶段需要输入一个字符串程序内部逻辑会验证字符串是否正确错误就触发爆炸。拆弹本质上是一个逆向分析过程要么用反汇编去读每条比较指令要么用调试器在关键跳转处设断点观察寄存器变化来推理合法输入。报告的重点是调试路径你在哪一行的分支指令卡住了、靠什么线索排除了错误输入、最终输入为什么能通过校验。这里最忌讳只贴正确答案——助教看到的是结果完全看不到你的排查能力。第三类是缓冲区溢出实验也叫 Attack Lab 或 Buf Lab。它要求你构造特殊的输入载荷利用栈缓冲区溢出来改写返回地址或触发某个隐藏函数。这类实验的主线是漏洞利用链报告要把内存布局画出来把输入字符串逐字节拆开标出哪些字节是填充、哪些字节是目标地址、哪些字节是 shellcode。字节序、栈地址随机化、帧指针的位置都是决定成败的细节这些细节就是要写的内容。常见做法是先用反汇编确认隐藏函数的地址再用调试器观察栈顶位置最后构造 payload三步分别对应报告的三段内容。2.2 报告的七段式框架问题定义、方案设计、实现细节、验证结果与结论无论哪种实验我一般会建议按七段式框架来组织报告。这个框架不是死模板而是保证“思考可见”的结构。问题定义用一两句话说明实验要求你解决什么问题验收标准是什么。实验环境操作系统版本、编译器、CPU 位数必要时写清调试器版本。解决方案分几步完成每一步采用了什么工具或方法。关键细节每类实验最核心的那几个点比如位运算的化简推导、炸弹的每条分支逻辑、攻击载荷的字节布局。实验结果通过了哪些用例、运行输出、截图、性能数据。问题与排查过程中遇到什么问题怎么定位和解决。结论与反思最终学到什么、有没有悬而未决的问题。七段式的篇幅分配要按实验类型调整不是均匀用力。下面是我常用的分配参考段落核心问题素材来源建议篇幅问题定义实验要做什么、验收标准是什么实验文档、评分标准6-8 行实验环境在哪套软硬件上做的uname -a、gcc --version4-6 行解决方案按什么步骤完成Git 提交记录、命令历史四分之一页关键细节哪些推导和逻辑思考量最大调试日志、草稿纸1-2 页实验结果在哪些用例上验证了测试脚本输出、截图每个用例 6-10 行问题与排查卡在哪、怎么找到原因断点记录、grep 日志半页结论与反思学到了什么、还有什么不懂个人复盘6-8 行使用时要避免一个常见误用把“问题与排查”写成一个万能坑位好像每个实验都恰好遇到两三个问题。实际上排查记录应该和“关键细节”强关联比如炸弹实验里你误以为分支条件是大于、实际是大于等于这类偏差才是排查记录的价值。如果只是写“遇到报错百度解决了”等于没写。2.3 写作前要攒的材料清单代码、日志、截图、调试记录一个都不能少动手写报告之前先把五类素材收齐。否则写到一半发现截图没截、命令没存、参数没记只能回去补做实验非常耽误时间。第一源码与提交记录。源码是基础提交记录能支撑你的时间线。建议实验一开始就建 Git 仓库每完成一个小目标就提交一次。提交信息里写“为什么改”不只是“update”比如fix: 修正 allOddBits 对负数的处理边界。这比截图更能证明你的工作过程。第二命令日志。你执行过的每一个关键命令编译命令、测试命令、调试器命令。不要光靠记忆我用过最简单的方式是用script命令把终端会话录到文件里后面整理报告时直接检索比翻历史记录省力得多。第三调试记录。在调试器里看到的关键寄存器值、断点位置、栈地址。这些是报告里“关键细节”的第一手来源。调试记录最好随手记在一个临时文件里注释标明时间哪怕写得乱也没关系整理时有内容可依据就行。第四截图。截图的重点不是“我跑了”而是“我看到什么、它证明什么”。所以截图里要有命令回显、有输出结果最好带了时间或文件名信息。后面第 3 章会专门讲截图规范这里先提醒一句别等实验全做完才补截图补的截图往往没有过程信息。第五实验结果数据。跑测试用例的输出包括通过、失败、超时、边界值。设计用例本身也是工作量不要忽略。用例里要包含正常情况和边界情况这一条在打分时区分度很高。这种攒材料的做法适用所有实验类型但不同实验的权重不同位运算实验调试记录少一些、推导草稿多一些炸弹实验调试记录最多溢出实验截图和内存布局图更重要。知道权重才知道时间优先花在哪里。2.4 用表格量化实验过程测试用例与结果对比的标准格式与其在报告里写“我测试了多种情况结果符合预期”不如直接给一张测试用例表。表格的作用是让助教快速核实验证范围。我常用的表头是用例编号、输入条件、预期结果、实际结果、是否通过、备注。以位运算实验为例用例输入预期实际通过备注isTmax 边界0x7fffffff11是正最大值isTmax 边界0x8000000010否最初忽略了补码对称性logicalShift 右移0x80000000, 10x400000000x40000000是用掩码去掉符号扩展位这种表对炸弹实验特别有用每个阶段一行输入字符串、通过的检查点、卡住的线索放在备注里。对溢出实验可以改成“字节偏移、填充字节、目标地址、实测注入结果”的对照表把构造 payload 时的几次尝试列出来。对缓存模拟或性能实验表头换成“块大小、命中率、缺失率、总周期数”比较不同参数下的数据比文字描述直观得多。注意一个容易被忽略的细节表格里的失败用例不要删除。保留失败用例既体现了你覆盖了边界也说明你确实手工验证过而不是只跑随机测试。同时预期和实际不一致的地方要与“问题与排查”章节一一对应不能表格里写着失败报告别处又没解释否则会被质疑数据可信度。3. 把原始过程变成可复现记录脚本收集、日志整理与截图规范素材攒在手上之后下一步是组织成可复现的记录。这一章讲落地方法用脚本收集产物、规范截图、整理参数表。这三件事做好报告写作就变成了素材重组而不是临时回忆。3.1 用脚本自动收集实验产物一个基于 Makefile 的打包方案常见做法是在实验目录里维护一个收集脚本把所有关键产物汇总到一个专用于存放证据的子目录方便最后写报告时统一引用。脚本通常包含导出 Git 日志、保存测试结果的追加记录、把当前源码复制一份做一个快照。下面是一个我常用的简化版本#!/usr/bin/env bash # collect.sh - 收集实验过程产物输出到 evidence/ 目录 set -euo pipefail EVIDENCE_DIRevidence mkdir -p $EVIDENCE_DIR # 1. 导出提交历史证明实验推进过程 git log --oneline --decorate --stat $EVIDENCE_DIR/commits.txt 2/dev/null || echo no git repo $EVIDENCE_DIR/commits.txt # 2. 保存测试结果把每次测试追加写入 results.txt带上时间戳 # 测试命令需要你自己替换成实验实际的验证入口 { echo $(date %F %T) make test || true # 实验自带的测试目标失败不中断 } $EVIDENCE_DIR/results.txt # 3. 把当前目录下的关键源码复制一份防止后续改动覆盖原版本 cp -r src $EVIDENCE_DIR/src_snapshot_$(date %Y%m%d_%H%M%S) # 4. 打印清单方便确认收集结果 find $EVIDENCE_DIR -type f | sort逻辑说明脚本的核心思路是“重复执行但不覆盖历史”。git log导出的是提交记录不是代码快照用来展示你在什么时间点完成了什么make test的输出追加到results.txt每次改动后跑一遍就多一段记录src快照则保证即使后来改坏了报告里也能引用到当时的版本。set -euo pipefail是防御性写法任何一步出错都会中止避免生成一个看似成功实则缺文件的结果。参数说明EVIDENCE_DIR是输出目录按需改名make test是常见的测试目标如果你的实验用的是make run或者直接跑一个脚本就替换成实际命令src要替换成实际源码目录名。2/dev/null是吞掉 Git 的报错输出因为有些实验目录根本没有仓库。|| true很关键它让make test即使失败也继续往下执行否则最后一次失败会导致整个脚本退出前面的产物反而白收。这里有一个玄学问题很多人以为加了set -e脚本就万无一失实际上make test失败时set -e会立即退出导致快照和提交日志都还没生成就中断了。所以我把make test放进|| true并且先导出 Git 日志再做测试。执行顺序错了坑就来了。3.2 截图与标注规范让助教 30 秒看懂你的关键步骤截图是比较容易被扣分的地方常见的翻车是截了一大张终端窗口但关键命令在滚动区域之外或者截图里有一个报错却没有任何标注助教根本不知道你注意到了什么。我一般按三个规范处理截图。首先截图必须带上下文。终端截图至少包含上一条命令和当前命令的回显也就是让你能看清楚“输入了什么、得到了什么”。如果是调试器截图要把设置断点的命令和对应的运行输出一起截进去而不是只截最后一屏。没有命令回显的截图几乎没有任何证明力。其次截图必须做标注。用系统自带的截图工具或任何画图软件框出关键位置。标注要回应三个问题这里验证了什么、预期的值是什么、实际的值是什么。比如栈地址的截图用箭头指向返回地址的偏移位置旁边写“offset 24, 目标 0x40123a, 实测注入后 RIP0x40123a”助教一眼就能核验不需要自己数字节。最后截图文件命名要可排序。建议用“序号_实验阶段_描述”的格式例如03_bomb_phase5_栈布局.png。这样报告里引用图片时不会乱后期改报告也容易检索。如果实验平台是纯命令行没有可视化界面也可以用script命令录制终端会话之后把关键片段抽出来排版比截图更紧凑也更容易在报告里以纯文本方式提交。3.3 参数与结果的组织方式把反复尝试做成对照表很多实验需要反复调整参数比如缓冲区溢出的填充长度、位运算里掩码的位数、缓存实验的块大小。每次调整都是一次实验都应该记录下来。不要只在报告里写“最终采用 8 字节填充”而要说明为什么不是 7 或 9。下面是一个参数调整对照表的示例框架尝试序号修改参数现象推测原因下一步操作1偏移 24段错误覆盖到其他栈变量查看调试器寄存器2偏移 28段错误目标地址错位对齐问题改用 NOP 填充对齐3偏移 28 NOP正常返回地址对齐成功确认最终方案这类对照表比大段文字更有说服力。它的价值不在于“我多勤奋”而在于展示“假设、验证、修正”的思考链条。特别是逆向了很久的炸弹实验把每个阶段的输入尝试列成表读者能直接看到你从盲目尝试到有目的猜解的转变这是报告里最加分的内容之一。组织的时候注意不要把所有尝试不分主次地堆上去。挑 2-3 次关键调整就够了其余的可以在“问题与排查”里带一句。对照组太多会让报告失去重点让人觉得你没有总体思路全靠穷举。4. 实验报告常见扣分点与避坑清单五类翻车现场及补救方法下面这些坑来自我见过和踩过的实际案例。每一条都按“现象、原因、解决”来写希望你看完之后能对照自己的报告提前排查。4.1 代码全对报告却写成了代码说明书现象报告贴了整段源码每行加一句注释测试结果只有一行“通过”。助教看完不知道你解决了什么问题只知道你把这门课的代码抄上去了。原因没有区分“代码注释”和“实验报告”。报告需要回答“你遇到了什么问题、你用了什么策略、这策略为什么有效”代码清单只是素材不是内容。解决把源码移出正文只在“关键细节”里引用重要函数或指令片段。每一段代码后补三段话这段代码实现了什么它和直接实现方式有什么差异什么约束导致必须这样写如果每一段代码都能回答这三个问题报告就从说明书变成了技术文档。4.2 截图没有上下文助教看不出在验证什么现象一张终端截图只有输出没有输入命令或者截图里有一个失败信息却没写你有没有解决。助教只能看到“某程序运行了”但不知道在验证哪个结论。原因截图是为了“证明我做过”而不是“让读者理解”。没有命令回显的截图证明力很弱。解决每条截图补标注和说明。推荐的格式是“命令 关键输出 一句结论”。例如执行./bomb输入abcdef返回BOOM!!!说明第一阶段的比较指令没有命中预期字符串。图片后面再补一句话解释它对破解路径的意义比如“所以输入长度不是第一阶段的关键约束真正判断发生在字符串内容比较”。4.3 实验数据与结论对不上被质疑可信度现象结论写“所有测试全部通过”但详细数据表里有一行失败。或者前文写“尝试了 5 次”后文只有 3 次记录。这种报告往往会被打回去修改。原因不同时间补写的章节没有互相核对。报告写完之后从头到尾读一遍的人很少数据不一致往往是在最后一刻改结论时漏改了数据表。解决交稿前跑一遍“数据、结论”对照检查。每一条结论都要能在数据表、截图或日志里找到对应证据。如果把失败用例保留在了表格里一定要在“问题与排查”里说明原因例如“该用例失败是因为本机栈地址随机化未关闭关闭后通过”。不要删数据也不要留矛盾。4.4 参考学长的模板连错误的参数都一起抄了现象网上或学长的报告里写某个编译参数、某个偏移量照搬之后发现结果对不上又不知道为什么。最后在报告里写了一个自己也不理解的数字。原因模板里的参数可能是特定环境下的结果。比如栈偏移依赖编译器版本和优化选项抄固定值等于跳过推理过程。解决把模板当验证手段不当参考答案。具体做法先用模板的参数复现结果再用反汇编工具和调试器查看实际值把你环境下的真实参数写进报告。比如学长写“偏移 24 字节”你复现后改成“偏移 28 字节”在报告里说明为什么你的环境多出了 4 字节这本身就是很好的排查记录。4.5 时间估算失误报告仓促交上去被扣格式分现象实验代码早早搞定以为报告两小时能写完结果排版花了一整晚最后交上去缺图表编号或缺目录格式分被扣掉一截。原因报告写作被低估为“对代码的复述”。实际上一份合格的报告需要截图、画图、整理表格、统一术语工作量不比写代码小。解决把报告写作按“资料整理半天、初稿一天、排版半天”来预估。更稳的做法是提前把截图和表格按第 3 章的方法收好最后只做重组而不重新调查。如果时间确实不够优先保证“问题与排查”和“关键细节”完整这两部分比环境搭建截图更值分。5. 交稿前的 10 分钟自查清单与答辩话术报告初稿写完后别急着提交。花 10 分钟做一次结构化自查能避免大部分低级扣分。下面给出一套自查清单和答辩时的应答思路。5.1 四层自查清单页数、格式、数据、结论逐项核对自查建议按页数、格式、数据、结论四层来推进。不要按顺序从头读到尾那样很容易被自己的叙述带走发现不了问题。检查项检查方法常见问题页数篇幅对照评分标准里的页数上限超页被扣格式分低于下限通常意味着内容深度不够图表编号是否从图 1 顺序编号正文是否都有引用插入新图后忘记全局重排出现“图 3”引用错误术语统一“栈”还是“堆栈”寄存器名写法是否一致混用术语会显得不专业代码引用代码片段是否与附件源码一致改完代码忘了更新报告里的片段数据一致性每条结论能否在表格、截图或日志里找到证据结论说通过表格里却有一行失败敏感性信息是否留了别人的姓名学号或非公开数据多人共用模板时最容易出现时间分配建议是这样前 2 分钟只查页数和图表编号不要读内容中间 3 分钟专门找数据表里的失败记录对照结论读一遍最后 5 分钟检查代码引用和术语。这 10 分钟做完报告里最容易被抓的硬伤基本都能扫掉。5.2 代码与报告对应关系让助教按图索骥找到关键行报告里引用源码时不要只写“见附件”要写具体文件和关键行号。这样助教可以快速打开源码核验也方便你自查。我一般会在定稿前跑一个命令把报告里提到的所有符号在源码里搜索一遍grep -n isTmax\|phase_5\|redirect_target src/*.c如果输出为空说明报告里写的函数在源码里根本不存在这是最容易暴露的硬伤。如果输出行号与报告里的引用对不上说明源码改过而报告没更新。这个命令跑一下只要几秒却能救回最尴尬的扣分点。行号引用建议统一写成“文件:行号”的格式例如src/bomb.c:127-142。助教按行号找几秒钟就能定位。别小看这个细节它决定了报告是“让人容易检查”还是“让人不想检查”。5.3 答辩现场的三类提问与应答思路如果课程有演示或提问环节问题一般集中在你最得意的那部分。提前准备三类答法比临场想更稳。第一类是“为什么采用这个方法”。回答模板对比过哪些方案当前方案在哪个条件约束下更合适。例如“我对比了逐位右移和二分法统计 1 的位数在当前操作符限制下只能用逐位”。第二类是“这个参数是怎么确定的”。从实验数据讲不要凭空解释。比如“填充字节长度最开始用 24后面从调试器看到返回地址在偏移 28所以改成 28 并加了 NOP 填充”。有对照表和截图支撑会更可信。第三类是“失败过吗怎么发现的”。讲一个真实的排查记录按“现象、猜测、验证、结论”四步每步一句话。不要怕暴露失败展示排查思路比展示完美更重要。如果确实被问住了直接承认这个点还没考虑清楚然后补一句“我注意到返回值异常接下来会从寄存器入手确认”。这种回答比硬撑更有好感。6. 进阶技巧用“实验日志法”让报告自动长出来前面讲的都是怎么补写报告。最后一个技巧是从源头改变工作方式实验日志法。做法很简单在实验目录里建一个log.md每次改动代码、跑完测试、看到一个关键值就追加三行时间、命令或现象、下一步计划。不用写完整句子关键词就行。这个方法的好处在于报告写作变成了日志重组。比如炸弹实验你某天记下“phase_2 比较 0x40275d输入为字符串 123”写报告时“关键细节”段落只是把这句话扩写成完整逻辑不需要重新逆向一遍。再比如缓冲区溢出实验你记下“偏移 24 段错误RSP 在 0x7fffffffe1a0目标 0x40123a 距离 28”写报告时这一条就直接变成对照表里的一行。我自己的教训是早期我习惯先做实验、后写报告结果写到一半发现某个参数的推导过程完全想不起来只能重新跑实验。后来改成边做边记报告初稿几乎是一口气写完的。实验日志法还有一个额外好处如果实验隔了一周才继续打开log.md就能立刻恢复到上次的进度不用重新熟悉环境。建议你下次做实验时试试这个习惯不用刻意写得很正式乱一点没关系。等报告截止时你会发现最难的部分已经自动完成了。希望帮到你。本文还有配套的精品资源点击获取