分类RTOS下的文章

BinarySecurityResearcher,IoTSec,NFVSec,FuzzingTest,CTFer

第一种是传统的静态二进制匹配方式，提取目标函数的CFG特征或者sig等信息，将其与无符号二进制中的函数进行比较，并输出匹配结果的可信度。由于尝试了几个现成的工具后发现效果不尽人意，暂时也没想到优化措施，就暂时搁置了这个思路。

几个关键的前提：

该框架支持使用Ghidra的headless模式，利于命令行处理数据。并且提供了P-codevisitor，可以通过符号执行的方式遍历P-code，判断指令中某个操作数是否存在潜在的溢出。还提供了各种自带的Checker，每个Checker对应一种CWE。当程序分析完成后，该框架就可以调用指定Checker分析反编译后的程序：

可以发现其中本身就提供了CWE190——也就是整数溢出的检测模块，但是非常遗憾的是这个模块实现得较为简单，没有针对漏洞特点进行进一步处理，所以漏报率和误报率都很高。

这是原生的代码实现：

最终，基于BinAbsInspector框架，我们构思了以下的实现思路来实现整数溢出漏洞检测：

在Checker模块添加自定义Sink，并实现扫描程序SymbolTable自动提取Sink的功能（就是一暴力枚举）：

SymbolTablesymbolTable=GlobalState.currentProgram.getSymbolTable();SymbolIteratorsi=symbolTable.getSymbolIterator();...while(si.hasNext()){Symbols=si.next();if((s.getSymbolType()==SymbolType.FUNCTION)&&(!s.isExternal())&&(!isSymbolThunk(s))){for(Referencereference:s.getReferences()){Logging.debug(s.getName()+":"+reference.getFromAddress()+"->"+reference.getToAddress());hasWarning|=checkCodeBlock(reference,s.getName());}}}...这里首先从符号表提取出所有符号，然后过滤出函数符号，过滤掉External符号，过滤掉Thunk符号剩下来的作为Sink。其实这样的过滤还是太粗略的，可以大致总结一些基本不可能成为Sink但是又高频使用的常见函数构成黑名单，提取Sink时从中过滤一下实测效果会好很多。

不再直接遍历CodeBlock中的Instruction，因为这样使用的是Raw-Pcode。与Raw-Pcode相对应的是High-Pcode。Raw-Pcode只是将返汇编指令直接抽象出来得到中间的表示方式，它的CALL指令无法表示函数调用的参数信息。而High-Pcode是经过AST分析后得到的，其包含的Varnode具有语法树上的关联关系，CALL指令也包含了传入的参数

先获取Sink函数的引用点所在函数，调用decompileFunction进行反编译，分析函数的AST结构，并得到HighFunction，由HighFunction可以获得PcodeOpAST，PcodeOpAST继承自PocdeOp类，也就是上面所说的High-Pcode

while(pCodeOps.hasNext()){if(found){break;}pCode=pCodeOps.next();if(pCode.getOpcode()==PcodeOp.INT_LEFT||pCode.getOpcode()==PcodeOp.INT_MULT||pCode.getOpcode()==PcodeOp.INT_ADD||pCode.getOpcode()==PcodeOp.INT_SUB){if(PcodeVisitor.sink_address.contains(Utils.getAddress(pCode))){foundWrapAround=true;//getpCode'saddressandstoreitinlastSinkAddresslastSinkAddress=Utils.getAddress(pCode);}else{Logging.debug("sink_addresssetdoesnotcontain:"+String.valueOf(Utils.getAddress(pCode).getOffset()));}}...}其中PcodeVisitor.sink_address是下文添加的一个用于保存潜在溢出指令的数据结构3.3.1.4CALL指令参数检查因为不能直接认为潜在整数溢出指令就一定会导致后续CALL所调用的Sink函数会受到整数溢出影响，所以还需要明确整数溢出的位置是否影响到了函数的参数。为了提高效率，可以只检查函数的size参数或者length参数的位置，将这些位置对应的Varnode的def地址和lastSinkAddress作比较来确定参数是否受到溢出影响（事实上这操作也有一些问题）。

switch(symbolName){...case"calloc":if(pCode.getInput(1)==null&&pCode.getInput(2)==null){Logging.debug("Input(1)&Input(2)isnull!");break;}found=true;if(Utils.getAddress(pCode.getInput(1).getDef())==lastSinkAddress||Utils.getAddress(pCode.getInput(2).getDef())==lastSinkAddress){found=true;}break;case"realloc":if(pCode.getInput(2)==null){Logging.debug("Input(2)isnull!");break;}found=true;if(Utils.getAddress(pCode.getInput(2).getDef())==lastSinkAddress){found=true;}break;...}3.3.2修改PcodeVisitor这个模块主要完成符号执行的功能，如果某条指令发生了潜在的整数溢出可以通过Kset的isTop()方法来检查3.3.2.1标记潜在整数溢出指令添加一个public的静态HashSet变量，用于保存那些被符号执行认为存在潜在整数溢出的指令

publicstaticHashSet