最近出了一个libSSH认证绕过漏洞，刚开始时候看的感觉这洞可能挺厉害的，然后很快github上面就有PoC了，msf上很快也添加了exp，但是在使用的过程中发现无法getshell，对此，我进行了深入的分析研究。

国庆节的时候，Git爆了一个RCE的漏洞，放假回来进行应急，因为公开的相关资料比较少，挺头大的，搞了两天，RCE成功了

上一篇《以太坊智能合约OPCODE逆向之理论基础篇》，对智能合约的OPCODE的基础数据结构进行了研究分析，本篇将继续深入研究OPCODE，编写一个智能合约的调试器。

在我们对etherscan等平台上合约进行安全审查时，常常会遇到没有公布Solidity源代码的合约，只能获取到合约的OPCODE，所以一个智能合约的反编译器对审计无源码的智能合约起到了非常重要的作用。

目前在互联网上常见的反编译工具只有porosity[1]，另外在Github上还找到另外的反编译工具ethdasm[2]，经过测试发现这两个编译器都有许多bug，无法满足我的工作需求。因此我开始尝试研究并开发能满足我们自己需求的反编译工具，在我看来如果要写出一个优秀的反汇编工具，首先需要有较强的OPCODE逆向能力，本篇Paper将对以太坊智能合约OPCODE的数据结构进行一次深入分析。

最近在学习智能合约，记录下学习笔记

背景

最近学习了下以太坊的智能合约，而且也看到挺多厂家pr智能合约相关的漏洞，其中《ERC20智能合约整数溢出系列漏洞披露》[1]文章中披露了6个CVE编号的漏洞，而这些漏洞都属于整型溢出漏洞范畴，其中5个漏洞均需要合约Owner才能触发利用。本文正是针对这些漏洞从合约代码及触发逻辑上做了详细分析，并提出了一些关于owner相关漏洞的思考。

前段时间meh又挖了一个Exim的RCE漏洞[1]，而且这次RCE的漏洞的约束更少了，就算开启了PIE仍然能被利用。虽然去年我研究过Exim，但是时间过去这么久了，所以这次复现还是花了大量时间在熟悉Exim源码上。

上一篇分析出来后，经过@orange的提点，得知了meh公布的PoC是需要特殊配置才能触发，所以我上一篇分析文章最后的结论应该改成，在默认配置情况下，meh提供的PoC无法成功触发uaf漏洞。之后我又对为啥修改了配置后能触发和默认情况下如何触发漏洞进行了研究

感恩节那天，meh在Bugzilla上提交了一个exim的uaf漏洞：https://bugs.exim.org/show_bug.cgi?id=2199，这周我对该漏洞进行应急复现，却发现，貌似利用meh提供的PoC并不能成功利用UAF漏洞造成crash

之前看到了一个CVE, CVE-2017-13772

是TP-Link WR940N后台的RCE, 手头上正好有一个TP-Link WR941N的设备，发现也存在相同的问题，但是CVE-2017-13772文章中给的EXP并不通用

所以准备进行复现和exp的修改，折腾了将近4天，记录下过程和遇到的坑