IoT设备逆向工程中的函数识别
本文主要讨论IoT设备逆向工程中的函数识别、符号迁移问题，不考虑BinDiff、PatchDiff2等重型工具，有些场景也不太适用。函数识别技术主要涉及两大类，一是IDA自身的FLIRT技术，二是Craig的rizzo技术，本文介绍它们的基本原理、工程实践细节。另外附赠几个其他类型IDA插件的使用说明。
离线生成/proc/kallsyms结果
标准kernel的源码是公开的，但很多手机、IoT设备的kernel有定制化开发，比如把一些加解密处理放进kernel，用户态通过ioctl()调用内核态代码。没有改动后的源码，要想搞清楚这些定制化开发在干什么，只能对之进行逆向工程。
远程SHELL中进程因TCP连接中断而失去控制的预防及救急方案
在一个SSH会话里执行vi，后因TCP连接中断而失去控制。重新登录后发现原SSH会话对应的伪终端还在，其中的vi进程也在。有什么办法重新获取对vi的控制？本文通过设计一个实验复现问题并给出救急方案。另外，本文介绍了两个成熟的工具screenify、reptyr，第一次听说的朋友会感谢我的。
ARM模式、THUMB模式若干工程实践问题
ARM架构中有一个CPSR寄存器，它的的bit-5是T位(Thumb state flag)，置1表示THUMB模式，置0表示ARM模式。二者区别很多，对于逆向工程来说，可以简单理解成ARM模式都是4字节指令，THUMB模式尽可能采用2字节指令编码方案；这种说法很不严谨，但不影响大局。此处只考虑32-bits ARM。
非常规手段上传下载二进制文件
文中演示了3种数据映射方案，有更多其他编解码方案，这3种够用了。前面介绍的都是bin与txt的相互转换，各种编码、解码。假设数据传输通道只有一个弱shell，有回显，可以通过copy/paste无损传输可打印字符。为了将不可打印字节传输过去，只能通过编解码进行数据映射。
关于x64/Win10中Shim机制的一次调试分析过程
有阵子给windbg写jscript插件，无意中在x64/Win10上发现一件事，执行notepad不从nt!PspProcessOpen()过，mspaint则过。跟bluerust说起这事，他瞎猜了一个说法，是不是因为mspaint有Shim机制介入，进而导致这种区别。为什么有这种区别，到了也没去深究，不是刚需。但他说的Shim机制，对于一向孤陋寡闻的我，有点意思。
kd调试的某些技术原理
作者: Tarik Soulami
内核态调试时设置断点，与用户态调试时一样，在指定地址写入0xCC(int3)。断点命
中时，OS暂停运行，调试器接手，在进入”break-in send/receive loop”之前，恢复
断点所在地址的原始字节。因此，你在kd提示符下，看不到断点处的0xCC。这里不讨
论硬件断点、内存(属性)断点之类的。
windbg jsprovider.dll的一个BUG
这是微软提供的一个windbg JavaScript插件例子: