这writeup是断断续续写下来的，最近事情比较多，所以也拖得比较久 (然后就没想到又拖了快4个月——2021.3.14)

在今年的flareon上，再次ak，这次排名是107，希望能拿到那根钥匙吧T_T (收到了 yeah！)，去年的牌居然给我寄丢了，气死我了

再次是简单回顾总结整个比赛 (其实就是流水账writeup)

因为官方的wp已经很详细了，所以这篇会很流水账，主要记录一些跟官方不一样的东西，或者有学到的新的奇淫技巧

感觉今年的难度比去年的要高一些

官方WP：https://www.fireeye.com/blog/threat-research/2020/10/flare-on-7-challenge-solutions.html

写在前面

好久没更新，之前立的 toWrite plan几乎全倒了

不过比较好的是，去年flareon2018做了6/12，立了个flag今年要拿牌

现在做到了！！！

所以必须得来更新一下writeup

其实跟去年的题目比较，感觉今年前面的题目相对比较简单，因此前面做的比较快

最后卡在了最后一题，断断续续做了快20天，心态都快崩了

不过还好，最后还是拿到了牌（虽然现在还没寄到手上

不得不说，flareon总是能学到许多

下面开始描述我的解法，在记录完我的解法后，我才会提及到一些题目相关（题目设计、官方解法）

http://flare-on.com

记录一下今年的flare-on，断断续续做了好久，最后12题中总共解出6题，后面的题就不够时间看了

再一次感受到自己是在太菜了，发现自己在逆向的时候很不善于用一些有用的工具，大部分时候是通过自己手动硬逆，事实上，逆向的目的是要搞懂程序在干些什么，不必去过于探究一些细节，而对于我数学、算法方面的硬伤，只需要抽时间去恶补理论基础就好了。但对于逆向技巧，flareon给了一个很好的学习逆向的题目。

另外，flare-on的官方writeup真的是太感人了，太详细了！

https://www.fireeye.com/blog/threat-research/2018/10/2018-flare-on-challenge-solutions.html

希望明年能拿到徽章

在咸鱼很久以后，我突然想起了这个被我荒废了很久的博客

结合在断更之后所做过的事，现在立几个flag，先占几个坑，发布准备更新的文章

1. android的api以及Linux内核hook的实现
2. Flare-on5 题解1-6
3. giglf的工具集

这段时间打了好多ctf比赛，主做re，但是没打算写wp23333

有些是太久远了，而更主要原因是因为做出来的题没价值

最近做了flare-on5，做出了6题，flareon感觉还是能学到非常多的东西的

接下来打算着重总结一下

暂时，就这样（顺便测试一下新电脑上的hexo deploy

记录最近配置ubuntu网络时遇到的神坑……

首先，我现在工位的电脑我装的是ubuntu16.04，然后因为端口的ip是跟mac地址绑定的，并且当时绑的是我笔记本的地址

所以，为了避免麻烦再绑一次，我就想直接改了ubuntu的mac就好了，那样我有时用笔记本直接插网线也就可以了

某次ctf内部赛上出了一题android的re，算是第一次认真出题了23333

因为太菜了，这破题从开始想到写花我4天= =，最后还改了一个思路

题目源码https://github.com/giglf/CTF_RE_FindTheActivity

首先吐槽一下小米3移动版，居然用的是英伟达的CPU，而联通、电信版是高通的

比较舒服的是小米已经开源了很多内核源码，资料基本都能查到

虽然安卓底层也是linux的内核，但因为安卓百花齐放，一堆不同的硬件、适配，不同版本的手机也有定制的内核，不然很可能出现某个硬件用不了的情况

另外，编译过程还出了很多的错误emmmmm

猜测是编译器版本不同导致的问题

一下算是手把手教如何编译一遍了……

简单来说

就是觉得以前用的那个主题freemind

太单调了

毕竟也不是自己写的

某次看别人的博客，看到一个叫spfk的主题

https://github.com/luuman/hexo-theme-spfk

感觉就是

艾玛太炫酷了

然后就用了

前言

在目前许多的Android应用加固中，都用到了so文件，并且通过针对so文件的section table进行混淆处理，以避免ida等逆向工具进行静态分析，因为在Android源码中，so的加载是完全不需要section信息的。

在此之前，很多文章都已经写到过关于Android so加载的流程，但很多都是基于Android4.x系统

虽然流程大同小异，但在Android5.0以后已经从Dalvik转换成ART，文件关系上已经对不上

因此，我针对Android7.1.2_r28的代码，对so加载过程进行分析

so加载

在加载一个so的时候，必然要写一句

1

System.loadLibrary("native-lib");

那么，我们就从这个函数看起

之前在写一个cpp的项目，不想用一些比较臃肿的IDE，所以就直接vscode+Makefile了

然后，因为是在windows下开发，遇到了一些神坑了。。

首先是make clean （别问我为什么不用cmake，是懒得配置

1
2

clean:
	rm $(TARGET) $(OBJS)

很正常的代码，但是就是运行崩了

并不是因为rm的原因，因为这是运行在powershell下的结果

首先，它报出了这样的错误

1
2
3
4

process_begin: CreateProcess(NULL, rm sb.exe src/main.o src/ELFReader.o, ...) failed.
make (e=2): 系统找不到指定的文件。
Makefile:23: recipe for target 'clean' failed
make: *** [clean] Error 2

似乎是找不到命令的原因。

后来我发现在powershell底下，rm后面的文件与文件之间必须要是逗号分隔……

修改后，还是爆出一样的错误，经过一系列的搜索并没有搜出个什么来

后来经朋友提醒……加个引号试试

1
2

clean:
	"rm $(TARGET) $(OBJS)"

很有道理，那么CreateProcess第二个就像一个参数了

果然，不一样的报错了

1
2
3
4

"rm sb.exe src/main.o src/ELFReader.o"
/usr/bin/bash: rm sb.exe src/main.o src/ELFReader.o: No such file or directory
Makefile:30: recipe for target 'clean' failed
make: *** [clean] Error 127

好的，你告诉我为什么在Windows下会调用的是bash（万脸问号）？？？

结合起来搜索，似乎说这是因为git bash的原因 ´_>`

不过，我并不打算管了，Windows下开发不用ide坑太多了

果断转移到Linux底下去

另外就是，MinGW在window下的依赖问题

如果是mingw-w64，则能很好的进行64位程序的编译，但是，当我加上-m32

正常的默认设置是不支持编译32位程序的，但SJLJ的是支持的

重新安装过后，-m32能正常编译了，但是程序运行会爆出

应用程序无法正常启动0xc000007b的错误，似乎也是一些依赖问题

但暂时不打算解决了，要想编译32位的程序，大可另外下个w32版本的mingw

Windows实在……太坑了´_>`