NSSCTF逆向2023题目《程序和人有一个能跑就行了》《encode》

Posted 2023-06-01 Corax0o0

总览

程序和人有一个能跑就行了 trycatch rc4
encode 低高位操作 字符爆破
今天出去玩了 写完已经是半夜两点半了 睡大觉

题目程序和人有一个能跑就行了

解法

这道题我比赛的时候是解出来了，但是解出来的很偶然 下面是我的过程。
下载下来是一个exe程序，exeinfo看一下，无壳32位。扔进ida

映入眼帘就是这个玩意，看到了两个字符串的样子的东西，留了个心眼。
因为函数跳转比较复杂，就直接string来定位

看看上面
ok，那大概就是buf1是程序里面的数据，然后我们输入的内容给buf2，key是litctf，加密出来喝buf1比较，所以我们现在只要buf1来解密就可以

。。fakeflag,刚刚我们还看到一个字符串对吧，也输入看看

输入就对了 rc4是https://gchq.github.io/CyberChef/
。
但是既然再做一遍也必然不会这么浅尝辄止了。因为看这边

不管v8为何 u are right都会执行，那我们真正的flag是怎么做出来的呢，那段代码就是不不执行的吗？看了别的师傅的wp，学了很多东西。

首先是在这个地方下个断点，因为比较好奇的是为什么什么样的输入都会进入if的里面
ok
现在输出的是u are wrong。
执行到了这里
执行下去 步过5190

竟然tmd来到了正确flag的地方，我这个地方是步过了5190啊，那么在5190当中一定有什么操作让我们跳出了当前的这条指令来到了现在的这个地方，但是伪代码却没有表示呢？这个就比较有意思了。
5190到底做了什么操作，打开看看

依托代码，但是有用的函数只有这个红框的里面的东西，跟进
阅读代码 这个函数后判断某些东西，然后进入label9 在label9进入10

10中的关键代码就是框中函数，跟进

这个函数返回了一个a1+36，这跟跳转有个鸟关系？
看一下它的汇编

是通过寄存器来传的?
看看调用前是怎么处理的。

call了个这个玩意
到ida里面找到他

是一些线程操作，，暂且看不懂。
我的分析也就到这里了，网上别的师傅有讲是try catch来操作的，我对这些还有进程操作不太明白。
我的理解就是，我们输入一个字符串，进入判断后在一个函数内通过trycatch机制计算出偏移地址给eax然后通过寄存器传参跳转，绕过了ida伪代码的分析。
不过另外的一点是，虽然f5大法好，但多依赖是不好的，如果一开始没留意反汇编窗口，就会掉进fakeflag的坑了。

题目encode

解法

这道题就比上面那道题要简单很多了，exeinfo一看无壳32，扔ida了
通过关键字符串定位

逻辑也很简单呀，我们输入的东西被放在v5，然后通过对v5操作给到v4,v4再和一个字符串比较，对的话就是right了。
所以逆向思路就可以这样。用爆破法，对每个可以表示出来的字符，进行for循环内的操作，然后和这个未知的字符比较，如果对就输出他。
因为内置字符很长，懒得操作了哈哈直接用别的师傅的脚本了

代码能跑就不要动，为什么我们都会有这样的想法？

大家好，我是辣条。

为什么程序员会有代码能跑就不要动的观点？

今天就和大家说说这个有趣的话题。

针对这个问题某乎上有个小哥讲了一个小故事，先分享给大家：

新来的程序员小哥觉得代码不规范，内存释放的模块很混乱。这可能有隐藏的风险。接下来，他做了整合，把内存释放进行了模块化，专门整好了。代码变的更优质了，对吧？到这里算是好的。

然后过几天，就出事了，生产出现重大故障。系统内存泄漏，系统崩了，影响客户使用。客户投诉，扣钱。然后整个项目组开始大排查。排查到最后，就是这个内存释放的优化，有个位置漏了，没改到。但是其他位置全改掉了。然后这个没改到的位置，内存长期不释放。好了，内存爆了，内存泄露，系统崩溃。就是这个优化，导致了重大故障。

然后全公司通报批评。要求项目组整改，并且出检讨，现在能理解了吗。代码能跑，就别改。

辣条对这个倒是没有太大感觉，也没有很多工作这块的经验，不过之前暑假实习，有位前辈和我聊过这个话题，他大致是这么看的：

很多中小型公司和一部分大公司对于代码质量、开发效率等基础设施建设没有什么追求。这些公司的商业模式侧重在业务逻辑方面。由于各种原因（比如垄断等），用户对于产品质量没有什么话语权，不得不容忍系统和应用的缺陷。这使得此类公司的技术团队从KPI的角度没有足够的动力去改良代码和系统的质量，除非这种改良可以直接带来商业利益。

具体来说，比如一个提供打车或者外卖服务的平台，它的商业收益主要来自于线下的用户行为。改善代码质量只有在用户数量增长需要扩容服务、提高性能的时候才有正的商业收益。除此之外，改善代码质量几乎没有可见的商业收益。这给中层管理者带来很大的挑战，因为他们需要去证明投入工程资源的产出。如果这种产出无法直接或间接地通过销售增长、用户增长等指标反映出来的话，中层管理者就不会愿意让自己管理的开发者去改善代码质量。

长此以往，代码库中会逐渐累积各种技术债和潜在的缺陷。随着时间的推移，重构代码的代价会越来越大，风险也越来越高。这种情况下从风险收益比来看，尽量不要改动能够运行的代码是一种局部最优的策略。

只有当代码质量严重影响了系统的稳定性以后，中层甚至高层管理者才会有动力去投入资源做大范围的重构和改良。而这种时候通常伴随着技术团队人员流动，很容易出现全部推翻重写的局面。

辣条个人认为倒也不是绝对的。这取决于你个人对整个项目的熟悉和理解程度。

可以动的情况如下：

• 你是项目的主要代码贡献者之一，你对每个模块做什么都有充分的理解，知道修改带来的影响。
• 项目成败责任在你，你需要判断某个模块如果不修改的风险，以及事故发生时会造成什么损失。
• 虽然之前的代码很乱但能跑起来，但项目还没上线，为了日后系统的稳健，你决定大动干戈，重构一下。

不要动的情况：

• 你往一个巨大的项目里面添加了小功能，为小功能而且修改已经存在很久的部分，风险是很大的，除非你有充分的理由。
• 项目bug很多，改了一个bug会有n个新bug出现。
• 项目已经上线，如果需要大改动，需要测试。

个人建议：

• 如果你的代码能跑，但你不知道它为啥能跑，你还是不要提交这种代码了，搞懂了再提交。
• 写单元测试，以后修改了跑一次全部测试，也知道修改带来了什么影响。

 元芳，你是怎么看的呢？欢迎在评论中留言。

行业资料：添加即可领取PPT模板、简历模板、行业经典书籍PDF。
面试题库：历年经典，热乎的大厂面试真题，持续更新中，添加获取。
学习资料：含Python、爬虫、数据分析、算法等学习视频和文档，添加获取
交流加群：大佬指点迷津，你的问题往往有人遇到过，技术互助交流。

👇🏻 获取可通过搜索下方 👇🏻