使用Android Studio和Android模拟器完整调试LaunchAnyWhere漏洞的整个过程，包括exp代码、Settings APP和system_server进程这三部分代码的调试与理解。

用故障注入的思路：【反序列化（老数据）】→【序列化（注入故障）】→ 【反序列化（新数据）】理解 Bundle Mismatch

议题 Unearthing the TrustedCore: A Critical Review on Huawei’s Trusted Execution Environment 的子部分，其分析的TEE方案是华为自研的TrustedCore，解密TA的大概流程主要有三步：（1）模拟运行TEE中的白盒密码算法解出RSA私钥prikeyx。（2）使用RSA的私钥prikeyx解密TA头部的manifest。（3）使用解密后manifest中的AES key 解密 TA 正文。但作者没有给出解密过程中的一些细节，例如RSA和AES密钥的组织方法。所以我尝试复现了这个解密，并给出解密过程中的所有细节。

欢迎报名 OSR TrustZone Pwn

欢迎报名 OSR TrustZone Pwn

欢迎报名 OSR TrustZone Pwn

题目为采用8051模拟器运行的交互式程序，交互命令可以读写I2C总线设备。漏洞点为其对I2C总线设备号校验不严格，导致可以通过交互式命令行读写到挂接在I2C总线上的，并存储着8051程序代码的EEPROM。而flag位于8051可以访问的特殊寄存器中，因此通过对EEPROM的非法写即可写入shellcode并完成控制流劫持。不过由于EEPROM物理特性，通过I2C总线对其写入只能按bit将1写为0，但这现象似乎违背EEPROM可重复擦写的特征，其实其擦写的方法为通过对其引脚的一系列电平操作，使得整块EEPROM全部bit归1，然后按bit将1写0，这个操作在现实中一般使用编程器对EEPROM单独操作，在8051的shellcode中无法完成，本模拟器也将本物理特性如实模拟。因此对于本题中控制流劫持的位置以及shellcode写入位置都有额外的限制，需要针对题目固件选择特定的位置进行写入。

五道使用logic2逻辑分析仪进行总线电路信号分析的小题，主要涉及UART、I2C与SPI总线协议。

第一次在比赛中做出QEMU赛题，难度不大，6解，800分。漏洞点为：在目标代码进行base64解码时，数据长度限制由于除法忽略小数点后数据，进而产生的单字节溢出。溢出可以覆盖掉题目中的关键数据结构的size成员（PipeLineState.decPipe[3].size），进而可以越界读写题目中的函数指针，完成地址信息泄露以及控制流劫持。并且通过此函数指针可以简单的完成system(cmd)的调用，最终读取flag。

总共5道嵌入式赛题，全部非预期…

2020年11月，淼哥、老徐、我，仨人代表清华校队Redbud参加补天杯，项目为现场破解小米小爱音箱Pro。预期效果为在内网环境下，通过对音箱的破解，接管目标家庭的所有米家智能家居，包括：扫地机器人，窗帘，电饭锅，台灯以及电风扇。但由于小米安全人员（李海粟、曾颖涛）进行现场干扰，导致比赛现场的小米小爱音箱启动并联网后，就直接被小米后台远程重置，也就无法进入正常的业务逻辑，最后判定漏洞演示失败。本篇将以Redmi小爱音箱Play（2020年左右软件版本的1.60.10）为例，公开我们当时完成的播放音乐、录音窃听、家居控制等后渗透利用的具体方法，虽然过后看起来难度不大，但也是我们仨经过曲折探索才找到的一条可行路径。

一个以ESP32为底座的新手向CTF IoT赛题，包括基本的硬件操作，串口调试，网络通信，WIFI，蓝牙，MQTT，固件提取等，总共13个flag。其实就是我们仨这几年学到的一些经验，以及海特西湖论剑那张板子上的部分思路。具体玩法为：通过USB线连接ESP32开发板，通过串口工具即可看到题目信息的相关输出，并通过各种有线无线的方式与ESP32交互获取flag。解题的总体思路是通过对隐去flag的源码分析应该如何获取flag。并且在真实板子上的代码中，采用了AES动态解密真flag的方式，防止选手通过读取固件直接获得所有明文flag。另外在源码中为了清晰阅读，直接采用include c文件分离不同方向题目代码，省掉了头文件。淼哥对此赛题评价是：没有一点弯，纯训练。欢迎大家来玩～

更新中…跨架构shellcode

比赛时，雅儒为Redbud拿下本题一血，我为赛后复现。题目为DNS服务器软件dnsmasq 2.86，漏洞为人工埋入的域名字段栈溢出。由于交互接口为真实网络程序的socket，因此如何将flag带出成为本题的重点。这里我使用ROP，并结合栈溢出崩溃现场残留的寄存器信息，完成了任意命令的popen调用，最终使用wget将flag带出。

目标进程会读取用户输入并送入到初始化状态非常纯粹（intel 实模式）的kvm虚拟机中运行，所以可以理解为用户输入shellcode送入kvm运行。漏洞点为，kvm映射的宿主进程内存空间过大，导致可以在kvm虚拟机中访问到宿主进程的堆空间。因此最终通过shellcode读写宿主进程的堆完成利用。需要注意的是，处于实模式下的shellcode只有1M的寻址空间（20根地址线），因此应该使用shellcode进入到保护模式下，完成本题。但由于随机化影响，存在恰巧堆空间与1M的寻址空间有交集的可能，因此我没有进入保护模式，而是采用爆破的手段。当恰巧遇到：堆在1M可寻址范围内时，在实模式下直接对堆进行读写，完成利用。

支持MRP游戏的山寨机伴随了我初中那无聊的课上时光。记得当年把手机藏在笔袋里，哪怕老师就在眼前，也堂而皇之的在课桌上打超级玛丽，紧张刺激。高中之后，有了昂贵的iPhone，也有了便宜的Android，昔日辉煌的山寨机很快就成为了记忆中模糊的历史，但我依然会时常想起那串进入MRP游戏世界的神秘代码：*#220807#。如今，我终于有能力去探索当年MRP游戏背后的秘密…

通过HITB GSEC2017 babyqemu理解qemu逃逸，简化了地址转换函数，更新中…

参照从0到1的虚拟机逃逸三部曲，实现了一个通过linux内核后门对docker逃逸的例子。

题目很好玩，为QEMU模拟运行的x86简易裸机系统，和目标的交互方式只有ping，漏洞为ICMP栈溢出，无任何防护手段，最终通过shellcode将flag塞回到ICMP的reply报文中并重新计算ICMP校验和完成带出。

aarch64:linux5.17，一个存在栈溢出漏洞的ko。我的利用方法为通过ROP调用set_memory_x开启内存的执行权限然后在内核态执行shellcode，shellcode中使用了读文件的内核函数并把flag存到寄存器中，然后主动触发崩溃，打印的崩溃现场寄存器会把flag泄露出来。

更新中…

本是想将目标代码运行在一个已有root shell并支持insmod的设备内核态中，具体底座为 arm:linux3.18.71，并不是要搞Rootkit。但直接去编译对应内核版本的ko（内核模块）在insmod时会发生崩溃，而他自带的ko却可以正常insmod，后排错一天无果。故不得已才想到可以将目标代码揉进他自带的ko中，这个行为无意间就和Rootkit保持一致了，即感染ko。说酷炫点是感染，其实就是patch，本以为和patch用户态ELF一样简单，在ko的.init.text段糊上目标代码就完了。但没想到ko外部符号重定位的实现方法，居然是内核直接根据符号信息修改ko代码本身。所以我糊上的代码，就有可能由于ko原有的重定位信息被内核改的乱七八糟。最后我通过直接删除ko中重定位section的方法，将代码固定在了ko中并可以被稳定执行。

HITCON18的 ARM64/32 系统Pwn题，总共6关，目前打到第3关。最近要忙毕设，所以估计后三关得过几个月才能打完了。此题相关内容都在：https://github.com/xuanxuanblingbling/SuperHexagon中，详解为superhexagon.pdf。

最近需要使用一个通信模组的SDK，其运行在嵌入式linux上，包括了设备树和内核的patch、驱动、用户态库和可执行程序等，文档中说明其适配了i.MX6QSABRESD（ARM32）。我知道市面上有非常多的iMX6的开发板，作为练习IoT正向开发的开始，我希望自己编译uboot、linux运行在板子上，然后探索其中的道理。同时也是为了在使用SDK的过程中，能更好的排错。我先后体验了四家公司的开发板，分别是：百问网、迅为、飞思卡尔、野火。本以为很容易，没想到的是，倘若是怀着探索实现原理心态去看一些的开发板教程，那真是如此的令人费解。所以本篇的选型，说的不是性能，而是在我踩坑的过程中，看到了谁家的开发板能让学习者对计算机看的更透，更清楚。

赛后和王皓共同完成，目标为AArch64纯字符shellcode，认真看论文把编解码器抠出来即可。赛时没做出此题着实该反思。

AArch64:libc2.27:ubuntu18.04，题目是在mini_httpd的baisc认证处塞了个栈溢出，远程不是qemu-user，应该是真机，所以不能直接ret2shellcode。故必须要ROP，使用AArch64通用gadget调用mprotect，再shellcode即可。

一段C级别的源码，编译在不同指令集上，最终功能一致，这固然理所应当。但它却能做到在汇编层面，以黑客ROP视角的高度统一，使自己能够跨越不同指令集成为真正的通用gadget，仔细想想会觉得很神奇，再多想一点可能会感到暗藏杀机。

破解新版本AMI的BIOS密码，其实就是存储在flash的nvram区中的一个SHA256。

需解密IPMI协议的流量，此协议运行在服务器的BMC（Baseboard Management Controller）上，可理解为独立的小核，可能实现为arm:linux等，用于带外管理，如远程装机等操作。虽然通信过程中，有认证，有加密，有完整性保护，但此协议本身设计的并不足够安全，导致在捕获到合法用户的认证流量后，可对其登录口令进行离线破解，最终解密其通信流量。

你猜？

在GDB中可以使用p或call指令调用进程内存中的任意函数，这并不新奇，但用此法直接去调函数调试堆，则需要调用一套带下划线的函数： __libc_malloc()、__malloc()、__libc_free() 、__free() ，而不能直接用malloc()、free()，这是为什么呢？

和徐老一起完成，HITCON2019时为netatalk的1day，漏洞是由于memcpy长度没限制导致的越界写，可覆盖关键变量，最终可导致有一次任意地址写，主要挑战为绕过ASLR。由于程序通过fork出一个子进程来处理每一个连接，所以在任意地址写时，可从低到高逐字节的覆盖并爆破原本的合法地址。比较麻烦的是，因为没有和Pwnable远程题目一模一样的环境，所以从合法地址到libc基址仍需要再爆破一次。最后通过覆写位于ld.so数据段_rtld_global结构体，并在程序超时退出时（远程tcp close后需要三分钟），完成控制流劫持并反弹shell。

漏洞位于/usr/sbin/upnpd，是ssdp（UDP 1900）协议的解析过程中，对MX字段的strncpy引发的栈溢出。由于是字符串拷贝，最终的利用方法仍与 PSV-2020-0211 一致，采取栈迁移的方法规避空字符截断。具体来说就是先把带00的ROP链打上栈，然后再触发栈溢出，用 ADD SP, SP, #0x800; POP {R4-R6,PC} 这种gadget完成栈迁移并将控制流打到ROP的gadget上。

在misty的帮助下完成，方法是使用由VMware提供的自定义gdb命令：monitor来查看特权寄存器，如 monitor r cr3。其实叫特权寄存器并不准确，其主要包括了x86的控制寄存器和系统地址寄存器，但又没有很好的统称，故就按照其属性：只能由运行在ring0级别的特权指令来操控，统称他们为特权寄存器。查看特权寄存器的目的，是为了更彻底的理解操作系统。

最近发现自己的binwalk在提取一些直接包裹在其他数据中的ELF文件时失效，但是识别是有结果的，一顿折腾最新版本还是不行，但发现用老版本就可以正常提取。经过分析，最终找到了问题的根源，新版本的默认提取规则配置文件：extract.conf，把单个ELF提取的规则给注释了…

和xkt共同完成，题目是一个用python3运行的简易python解释器，可以任意地址写，读内存的功能被patch了。比赛时因为没发现ubuntu18.04默认的python3是没开PIE且GOT表可写的，所以采取了野蛮的解法：任意地址写，可以泄露栈地址，所以直接写栈上的main函数返回地址为one_gadget，复用main函数返回到的libc_start_main地址的高字节，写低三字节，需要爆破1.5字节，概率为1/4096。

许久未见我这水平能做的堆了…

当年买树莓派的时候是为了研究ARM底层一些东西，比如Linux内核、JTAG、TEE啥的，却没成想配到的书籍都是教你用一些封装好的python库控制树莓派的GPIO，以控制外部一些简单的零部件、传感器啥的，很是失望，然后就把树莓派扔到一遍，买了讯为的4412开发板。后来随着自己平日研究的深入，还有也是遇到了纽创，发现其实树莓派可以胜任这些底层的学习与研究，只不过相关中文资料虽然有：从底层玩转树莓派，但是很少，也就更不会作为树莓派商家的配套教程了。本文按照前辈wellsleep之前的工作，构建了一个：① Ubuntu18.04和OP-TEE的混合系统 ② 并可以正常编译内核模块 ③ 开启了JTAG 的树莓派3B镜像。对未来的ARM底层研究，搭建好了一个可以调试的真实环境。当然学习ARM底层可以用qemu完成，但还是感觉在真实设备上更踏实。（我一直以为手中的是3B+，经过网友提醒发现是3B…之前坑人了，对不起大家…）

本文是徐老文章：物联网设备消息总线机制的使用及安全问题中TOTOLINK的MQTT业务的具体分析过程，由一个开启telent的功能出发，逆向分析出设备业务的处理过程，最终定位到漏洞挖掘的目标。意在强调对于设备的业务逻辑逆向过程，类似强网杯 2021 线下 RW Mi Router。

在开源软件的编译过程中，一般都是先使用configure检查编译环境并生成makefile，然后使用make进行编译。但是对于IoT安全研究来说，经常要遇到两个坎，一个是交叉编译，一个是静态链接。如果是单个c代码文件，类似shellcode或者后门，使用相应的交叉编译工具，在加上 -static 参数直接编译就好了，可是对于一个有configure以及makefile的软件，我们该怎么跨过这两个坎呢？一般的交叉编译都是在configure处做一系列的配置，这个配置虽然方便，但却令人困惑，我们配置的那些变量到底在哪生效的呢？如：交叉编译+静态编译。不过，最终编译还是makefile的事，所以其实可以在某些比较简单的情景下，直接忽略configure。由于make的命令行参数优先于makefile文件中的变量，所以可直接在make命令后加相应的参数，进而完成交叉编译和静态链接。本篇采用这种奇怪的方法，编译出5种架构（x86_64,arm,aarch64,mips,mipsel）下的静态链接的tcpdump程序。

正向开发是理解一个复杂系统的必要过程，我们熟悉linux用户态的Pwn，是因为随手就能写出一个helloworld，然后编译、运行、逆向、调试一条龙，进而理解它完整的生命周期。linux内核Pwn的文章有很多，不过大都是以完成一道题目的视角行文的。而本文希望，我们能熟悉内核态的代码的运行状态，具体来说就是：在 ubuntu20.04 (linux 5.11.0-25) 的本机环境下完成 ① 正向开发：将我们的代码送进内核态运行，了解有哪些可以使用的内核函数，基于这些函数实现一些功能。② 内存调试：使用log大法看到内核的内存。③ 内核本体：不同于源码视角，我们要找到内核二进制代码本体，认识一下。

这题淼哥基本写的差不多了：QWB-2021-Final:RealWorld MiRouter WriteUp，补充些淼哥没写的：设备串口开SSH、eCos业务分析、流量分析、多人策略、只开一个窗口的exp。另外今年的文章省去了一些基础操作，如果想看新手教学可以看去年的：思科路由器 RV110W CVE-2020-3331 漏洞复现。与去年相比这次没有考察二进制漏洞的利用，而是一个命令注入漏洞点的触发路径分析，明年再来一个和云侧、app侧结合的，后年再来一个从空口打的，这样IoT的大面就基本考全了。

Tile-gx指令集的linux用户态程序，除了qemu-user可以运行这个程序以外，没有任何的辅助工具，并且该架构的qemu-user即qemu-tilegx没有实现-g的调试功能。所以其他工具（逆向、调试、编译shellcode）全部要自己找到或者搞定，做题时找到并且编译了这个架构的gdb客户端和交叉编译工具，以及对qemu源码魔改了一个此架构下能读写寄存器的gdb桩。运行发现，此程序的功能是以标准输入输出为接口的httpsevrer。有了查看寄存器的能力后，即对此程序瞎发包进行测试，最终在basic认证处发现了不确定是不是栈溢出的控制流劫持。因为是qemu-user，没有NX，还给了和远程环境一样的docker，故ret2shellcode即可。比赛时这题只有More Smoked Leet Chicken和我们Redbud做出来了，老外的解法更正统和出色。

虽然之前总结过：关于蓝牙的漏洞研究，但对于蓝牙还是很懵，因为从来没有实践过，西湖论剑IoT比赛时，蓝牙的题目一个也没做出来。每次看到蓝牙都不知道在说哪一层的协议，看到wireshark抓的包也感觉之前看的蓝牙包不长这样啊。这次经过一段时间的研究，才大概的明白：（1）蓝牙的协议栈之所以复杂，是由于历史的变迁，以及兼容性的考虑，导致出现了（老的）经典蓝牙和（新的）低功耗蓝牙并存复杂的协议栈，单独来看这新老两个技术的协议栈，都没有很复杂，并且其结构都是很清晰的。（2）蓝牙的数据包在其从用户程序发送到空中的过程中，封包并非如TCP/IP协议仅仅将上一层的数据进行简单的封装就传递到下一层，相邻层之间的数据变换可能比较复杂，于是就导致了由于抓包的层次不同，看到的同一过程的数据的组织方式是不同的，典型就是在空口抓包以及在HCI层抓包。（3）另外以西湖论剑的三道蓝牙题目为例子，总结了主机控制蓝牙不同层次的收发包工具以及背后原理。

最近需要在一个采用了海思解决方案HI3518 CV100(armv5l)的设备上打一个反连并且没有空字节的shellcode，但是网上直接找shellcode大部分都是在armv7l上测试成功的，能够在armv5l的指令集上兼容的shellcode并不多。并且设备上的busybox的启动sh时，execve的第二个参数也必须布置好，否则会启动失败，网上的大多shellcode第二个参都是直接0。最后拼接了两位前辈（rtmcx、Ken Kitahara）的shellcode，并在HI3518 CV100、 Allwinner F1C200s上测试通过。

IoT设备上出现的真实内存漏洞大多都是对字符串操作不当所引发的，于是就必然会出现对于空字符的截断，进而导致我们的利用变得异常艰难。不过即使如此，黑客也可以使用各种花了呼哨的手段来完成利用。以下整理：由于字符串操作引发的栈溢出时，可以考虑的利用方法。

更新中…在内存破坏漏洞的攻击过程中，攻击者的最终目标一般来说是控制流劫持。如果攻击者能获得一个任意地址写（aaw）的能力，则之后的需要做的就是修改的在间接跳转过程中被使用的关键数据。首先能想到的就是函数指针，因为其内容就是间接跳转的目标地址。另外还有可能是对间接跳转的起着间接影响的数据，比如多级指针、数组索引等，不过落到最后仍然是函数指针。攻击大流程走到这步，攻击这个动词的宾语就变成了某个数据、变量、内存位置，比如攻击__free_hook。本文对CTF Pwn题中 常见的 位于libc中的 可以被攻击者利用进行控制流劫持的 函数指针 以及 触发方式 进行了整理。

对CTF Pwn题中 常见的 属于目标程序本体中的 可被攻击者利用进行控制流劫持的 函数指针 以及 触发方式 进行了整理。

这次运气不错，因为PKS的题目，Redbud包揽此次比赛的所有头奖。PKS的含义是：Phytium（飞腾CPU） + Kylin（麒麟OS）+ Security（安全能力），是我们国产自主化的一套体系。题目是突破它的安全机制，包括用户态强制访问控制机制Kysec，安全内存模组HSDIM-Lite以及安全启动。我打的主要是Kysec，就还是主要鼓捣用户态这套东西，从头打到尾发现并利用了五个洞：进程的/proc/pid/mem可被同用户读写、进程允许被同用户ptrace、安全机制仅在启动前检查程序是否合法、交互式python允许未校验的python代码执行、一个后装程序的root进程的命令注入。

aarch64:libc2.27，主要难度在逆向，根据提示，题目是个可以开车在地图（一个堆空间）上移动的程序，构造地图上的红绿灯，可以让车开出地图（堆上越界写）。由于自己逆向比较菜，只设计出了一个溢出单字节的地图，不过也够用了，相当于off-by-one。利用方法为：构造堆块重叠修改tcache块的fd，在malloc回来即可完成泄露libc与任意地址写，最后修改__free_hook为system即可getshell。

三道Pwn，比赛时均没有写出利用，看出并修上两个题的洞，另外一个没看出洞，当然也没修上。

更新中…结营赛还有非常多值得探索的东西

IoT安全研究员使用交叉编译的主要目的，就是编译一段能运行在目标嵌入式设备上定制的恶意代码，以达到我们邪恶的目的。根据目标情景的不同，编译前的工具选择、编译中的参数设置、编译后的成品形态也不同。如果目标是linux，那我们的目标成品一般有三种形态：可执行ELF，动态库so，以及用于内存破坏漏洞的shellcode。如果是非linux，则可能是一段shellcode，甚至是整个固件。本文介绍了交叉编译工具本身，获得这些工具的办法，以及针对以上不同目标的编译方法。

本次入营赛时长4天半，仍然由安恒承办，赛题只有四类：固件、内核、逆向、Pwn。对于二进制选手足够友好，其中固件题目与IoT实战结合紧密，难度总体来说不大，入门友好型赛题。自己在比赛中也学到了很多东西，最终AK了Pwn和固件，内核和逆向分别做出来最简单的一个，总成绩排名第二。

题目底座为riscv:rv64:libc2.27:ubuntu18.04，漏洞是该用户态程序栈溢出。不过远程环境是patch过的qemu，其功能限制了模拟程序去执行特定的系统调用，即没有riscv:rv64执行层面的execve。Pwn题总共两问:(1)读文件(2)Getshell。读文件就正常写orw的shellcode，本文也着重练习了shellcode的制造流程。Getshell的解法是：因qemu-user对模拟起来的代码访存隔离不完全，导致qemu-user模拟的程序可以直接修改qemu-user本体进程的内存，最终导致可以直接在qemu-user本体进程（x86_64层面）上Getshell。比赛时抢了第一问的一血，也是人生第一次xctf的一血，后在煜博的提示下解出第二问，感谢煜博。

对于补码，最简单的理解是最高位的权值是负数，而不是取反加一。

在思科的RV130W路由器，因为字符串拷贝存在许多栈溢出漏洞，故利用时要考虑到空字符截断，一般来说存在这种限制条件的漏洞是不容易利用的。但不知为何，在思科这个系列的路由器中，进程加载动态库的地址是固定不变且位于高地址的，故可以通过各种动态库中的gadget来完成整个漏洞的利用，这里抽象出一道练习题进行练习寻找ROP的过程。

更新中…

栈溢出，ARM题目的一般环境是QEMU用户态，默认不支持NX，故直接ROP+栈迁移然后写shellcode即可。

更新中…没有一道题是看出洞来，因为没工具不会看，全是手测然后调出来的…

house_of_orange原题

遇到情景是可以在android上安装任意apk，执行apk后有个反弹shell的效果。一般来说直接用msf就可以生成android后门，但不知为何在目标设备上无法正常使用，故决定自己编写一个简单的apk以完成反弹shell。最终实现三个纯JAVA版的shell_reverse_tcp，当然塞进apk也好使。开始自己完成了一个无法完全交互的shell，类似一句话木马那种伪tty。因为思路也是web的思路，执行->取结果字符串->发送结果字符串。后来参考msf的实现，人家是使用线程直接转发了启动shell的输入输出流到反弹的socket的输入输出流，不仅可以获得一个完全交互的shell，还省去了byte流转字符串的操作。这个其实就是和shellcode的思路一样了，类似dup socket的文件描述符到程序的输入输出流中。二者最重要的区别就是执行顺序上，因为自己对线程不熟，没有想到转发的过程其实是持续的，是伴随着我们对后门的操作的。也是因为自己的编程水平还停留面向过程的1234，不容易想到多个实体一起执行的情景，想的总是执行完第一步，然后第二步…最后找到一个单线程死循环获得完全交互shell的写法，通过判断输入流是否可用来进入转发，是目前看到的最短实现。

不要瞧不起命令注入，因为你不得不承认，命令注入型漏洞就是要比内存破坏型漏洞要稳。在实际的攻击中，我们发现的漏洞代码的运行实体可能是单蹦儿的一个进程，也可能是某个进程的一个线程。如果攻击发生在某个线程中，对其他线程，以及线程所属的进程会不有影响呢？在这种情况下，内存破坏漏洞的表现怎么样呢？

命令注入本身就是system函数，内存破坏漏洞的利用如果想获取shell，控制流劫持后也无非是system和execve，那么这二者又有什么区别呢？当你控制流劫持，并成功的getshell后，你可想过，被你打的漏洞进程，他现在过的怎么样了呢？

真实的网络程序和Pwn题目中把输入输出映射到网络端口，二者程序本体的交互接口显然是不同的，后一种的CTF题目，真的具有现实意义么？如果是真的网络程序，我控制流劫持后直接执行system(“/bin/sh”)可以拿到shell么？如果不能，我如何才能Getshell呢？本篇我们通过一个例题回答上述问题。

Getshell的背后就是代码执行，执行的是shell程序，并且此进程的输入输出可控。不过由于漏洞位置不同，输入点不同，达到Getshell目标的攻击载荷也不同。可以按照攻击载荷的量级来对payload进行分类，个人分为如下四类：shellcode，ELF，param，command。

黑客费尽心机Getshell后，有危害的（在现实的生活中产生恶意影响）最终意图无非两种，盗取和操控，其中操控无非是软件或者硬件。比如CTF就是盗取flag，三体中killer5.2病毒对罗辑的刺杀就是操控各种外部硬件。当然操控外部硬件的意图可能仍然为盗取，比如操控门锁打开，则最终意图是入室行窃。总之，这些事可以概括的称为：后渗透。

后门通信分析，比较容易的是Metasploit是开源的，故可以直接分析其后门工具meterpreter，以及对端的后门程序的源码。发现新版MSF6中的meterpreter与后门程序通信是使用了RSA和AES，即后门程序使用攻击者发过来的RSA公钥对之后通信的AES秘钥进行加密，此AES秘钥由后门程序随机生成，所以正常情况下应该是无法解密其双方通信的。但题目中公钥给了个可以被分解的素数，导致通信可被破译。另外对于密码算法的操作非常陌生，解题过程中感谢楚涵和gml的帮助。

通信，至少两个实体才有通信这一说，通信各方都需要实现共同的一套通信逻辑，而这个通信逻辑就是我们要分析的，这个逻辑可能是软件实现，也可能是硬件实现。所以柿子要挑软的捏，找到通信各方里，最好分析的实体，一般来说肯定是软件了。Godzilla这款后门管理软件虽然没有开源，但是他的对等实体，也就是他自己的php后门，肯定是可以随便看以及调试的，也就是说并不需要知道他通信加密的所有细节，直接用后门php脚本里的函数就一定可以对发往该脚本的流量进行解密了。如果是对称加密的话，双向的流量也都可解。

题目为网络接口的Web Server，瞎发包测出来的栈溢出，没审出来的原因是给出的目标程序的指令集是MIPS32 rel6（第六个大版本的MIPS32的指令集），比赛时手中的IDA7.5并不能正确的分析出其伪代码。当然有现场直接看汇编看出来毛病的同学，人家是厉害。因为是qemu环境，所以利用直接就是ret2shellcode就完了，不过shellcode只在堆上存在，但因为是qemu-user所以堆的地址在一个环境中是固定的，还是可以猜大概的地址来完成攻击的。

32位静态链接程序，开了canary和NX，可以溢出可控的IO_FILE结构体，之后会fclose该结构体，所以非常容易控制流劫持。但因为静态链接，也没有后门函数，只能靠系统调用，但因为没法控制栈，也就没法找到一条gadget就能完成execve(“/bin/sh”,0,0)的。比赛时没做出来，比赛后发现他还有个没有canary可以输入的栈溢出函数，控制流劫持到这然后ROP就完了。

比较简单的Pwn，其中的MIPS Pwn是人生中拿到的第一个Pwn的一血，全是4哥的功劳。

给出了非常长的01串，并告知这是用ubertooth抓到的原始数据，其中含有蓝牙的广播报文，请解析报文。

卡住了…更新中…rt-thread的main函数栈溢出，不用getshell，ROP/shellcode读出根目录下的flag即可：

本次IoT闯关赛为西湖论剑的其中一个赛项，由安恒的海特实验室出题，时长8小时，采用定制硬件为解题平台，玩法新颖，题目底座为armv5:linux5.4.75:libc2.30。但考察点偏CTF风格，与IoT安全实战尚有一定距离，最终赛况如下：

Realworld赛题，要求挖掘并利用CISCO RV110W-E-CN-K9（固件版本1.2.2.5）中的漏洞，获取路由器的Root Shell。攻击演示时的目标设备端口只开启了443端口的https服务，且不知道路由器的Web登录账号，故其实要求就是路由器Web的前台getshell。

以HWS夏令营的两道题目入门MIPS Pwn，都是栈溢出，但栈地址是否已知这个利用前提不同，故利用方式有也所不同。

附件：easy_vm

HWS夏令营的课程分为三个部分，IoT固件安全，linux内核安全、IoT硬件安全。GDB作为一个出色的调试工具，也在三个部分的课程中频频登场，说哪都有他一点也不过分。三个部分中，我们用GDB依次调试了：arm,mips等与本机x86（x64）不同架构的linux用户态应用程序、x86（x64）的linux内核、STM32裸机程序。前两者目标的运行方法是qemu，后者是用的STM32单板以及JLINK仿真器。

题面非常简单，scanf格串参数可控。但无任何输出函数，无法泄露libc，不过程序syscall指令。利用方法：scanf格串构造任意地址写，写stack_chk_fail的GOT表，然后继续利用scanf栈溢出触发canary报警，控制流劫持，但是只找到两个能利用rdi和rsi的gadget，无法直接控制rax和rdx。最后在程序中找到一段gadget(0x4011DE)能间接控制rax和rdx，不过需要劫持rbp才能满足这段约束的条件。总之最后一顿ROP到syscall上即可execve(“/bin/sh”,0,0)。

更新中…

更新中… 一句话描述漏洞：对USB请求处理不当造成的UAF漏洞。淘宝卖了一个二手iPhone6，决定研究一下checkm8这个漏洞。checkra1n虽然可以越狱iPhone6，但是ipwndfu不支持iPhone6，于是我又买了一个iPhone7。

本文是写给只会Linux Pwn，而对Windows Pwn一窍不通的朋友，对照Linux Pwn的工具、原理、方法，讲解Windows下对应的内容。通过本文可以了解到：1.一种在Win下搭建Pwn题环境的方法（socat+pwntools+IDA） 2. Windows用户态进程运行的基本原理与一些实用工具 3.Windows堆管理的基本方法。本题的漏洞点是存在悬空指针可以UAF，而且对于该悬空指针可以继续show、edit、free。利用方式为通过UAFleak堆地址，然后通过unlink完成堆上的节点索引的改写进而继续leak出程序基址，进而继续改写堆上的索引节点leak出ucrt的基址，最后继续修改索引节点的函数指针为system并控制参数为cmd即可getshell。

本文通过SCTF2020的STM32门锁固件题目，介绍了STM32的正向开发方法，逆向分析方法，以及IDA在分析固件的时候一些使用技巧。最终，通过静态分析以及动态模拟调试的方法分别获得 flag1：门锁密码 以及 flag2：UART输出的信息 。

本题官方分类是杂项，题目情景来自于一个实际的android投屏软件，出题者给出的解题目标非常明确，解析数据包中的视频流即可看到flag。这种杂项题目就非常的友好，实际软件、目标明确、思路清晰，并且自己在本题也收获了一些视频方面相关知识，故做此记录。解题方法概括为：1. 识别：识别投屏软件以及软件采用的视频技术。 2. 提取：从数据包中提取出原始的视频流信息。 3. 恢复：将视频流封装成文件并播放。

前一阵给媳妇买了个树莓派4B，教程里使用wiringPi这个c库对GPIO口进行控制。但是说到底硬件接口肯定是需要通过操作系统进行控制的，wiringPi这个库到底是怎么跟操作系统打交道的呢？换句话说，操作系统提供了什么样的接口让用户程序来控制硬件？操作系统又是怎样真正的完成了一次硬件的控制呢？答案是：树莓派上的Linux通过对映射到硬件寄存器的内存地址读写来真正的控制硬件，提供的接口为GPIO设备文件。不过root用户可以通过/dev/mem这个文件，来直接控制物理内存，从而绕过GPIO设备文件，对GPIO进行控制。这就是wiringPi这个库的原理，有些黑客。

本实验来自清华大学张超老师的《数据安全》课程中侧信道攻击小节作业，内容为：给定一个存在Meltdown漏洞的CPU并且安装了老版本linux系统的低权限用户，进行读取目标驱动的内存中的flag字符串，其中目标驱动的源码给出，真正flag的在源码中被隐去。作业环境为学生使用低权限用户通过ssh登录到一台机器上，然后对目标驱动的设备节点进行攻击，因为ssh环境终究会关闭，而且有驱动源码，所以决定自己动手复现一遍这个环境并完成攻击实验，首先是想了解一下Meltdown漏洞，不过重点也是想入门一下linux驱动。最终参考SEEDLabs的实验文档，使用自己的笔记本电脑，CPU为Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz，通过在vmware中安装了官方原版ubuntu12.04完成了实验。并且在过程中读完了宋宝华老师的《Linux设备驱动开发详解》前半本，以及左耳朵耗子的《跟我一起写Makefile》。

三道题的题目附件：5space_attachment.zip

漏洞点为索引没有过滤负数以及堆溢出。利用方法为首先通过负数索引泄露libc，然后构造堆溢出到tcache的fd为__malloc_hook的地址，再触发两次对应大小的malloc即可实现任意地址写，写入one_gadget即可。另外题目环境为libc2.29，本文还使用了ld-2.29.so直接加载题目的方式，介绍了在任意版本的ubuntu下做任意libc版本Pwn题的方法。

Rockwell/AB PLC 的ENIP协议经过简单的构造session即可实现正常通信，通过抓取组态软件和PLC通信的数据包，找出读取架子信息的流量，构造遍历架子序号，即可泄露机架上的模块信息。

漏洞点为一个整数溢出和一个堆溢出，其中整数溢出可以转化为另一个堆溢出。本题利用方法为利用原生的堆溢出漏洞，可以覆盖一个存在间接跳转的二级指针，因为没有开启NX，所以结合堆喷即可getshell。虽然堆喷解法的exp很简单，但本题的逆向却是是很耗时的。

这是一道堆喷思想和堆风水思想结合的题目，漏洞点是堆上变量初始化。利用方式和本题代码强相关，通过堆喷思想控制堆上的未初始化的变量，然后综合利用堆风水和堆喷泄露出堆块的布局信息以及libc基址，然后在利用堆喷思想劫持控制流并完成栈迁移到堆上，最后进行ROP即可getshell。

三菱系列PLC，Melsoft私有协议，但如果没有配置口令，则可以直接进行重放攻击，通过wireshark抓取组态软件与PLC的通信报文即可获得控制PLC的数据包，重放即可。

多亏mcfx指导，才能做出这题，感谢。64位程序，保护全开，可以执行我们发送的c代码，但可以执行的代码有些限制，不能执行system之类的函数，但可以任意写内存。最终通过利用栈上的数据，获得了libc的基址，完成了对__malloc_hook的劫持，进而getshell。

漏洞点是：使用C++中的STL中vector存储对象的指针时，在earse清除其中元素时，总会调用最后一个对象的析构函数，最终导致存在悬空指针，并且可以被使用，即UAF。其使用的方式是可以继续free以及show其内容。

本题前面是Web，SQL注入注出管理员的密码，然后能任意读取文件，发现php使用了一个自定义的函数，读取到这个函数的实现的动态链接库，去除花指令后发现有个栈溢出，但是在利用的过程中需要注意栈的使用情况。

大学的时候第一次接触到我的世界，觉得是个很自由浪漫的游戏，可以在游戏里天马行空的创造，当时也是因为这个游戏第一次要指定JAVA路径，听到了什么JDK、JRE的相关名词。最近和家人一起在玩这个游戏，正巧前几天的比赛里也出了游戏相关的题目，而且在CTF中出现MC也不是第一次了，所以借着这个机会玩一下游戏，也研究研究的运行原理，整理下我知道的方方面面。

题目文件：fengshui

解决了在arm架构的32位linux下，由于链接器不同，动态库不全导致的IDA的调试server无法运行的问题。后来发现这种方法调试多进程时IDAserver会崩溃，应该是libthread_db.so.1与环境不兼容。另外其实有更简单的方法，直接在运行时设置环境变量，然后用本地的ld运行，ELF为参数即可： LD_PRELOAD=./libthread_db.so.1 /lib/ld-2.25.so ./armlinux_server