llvm

LLVM代码混淆分析及逻辑还原 概述 LLVM Obfuscator是一款工业级别的代码混淆器，在过去几年的CTF里我们经常会遇到经过代码经过它混淆的情况。这片博文记录了我们对混淆器原理的研究以及从中发现的有关混淆器的设计实现的脆弱之处。基于我们的研究结果，我们在Binary Ninja平台上写了一个插件，通过这个插件可以自动化的解决掉由于代码混淆带来的逆向分析困难。 LLVM Obfuscator简介 LLVM Obfuscator是一个基于LLVM框架实现的一个开源代码混淆器，整个项目包含了三个相对独立的LLVM pass, 每个pass实现了一种混淆方式，通过这些混淆手段，可以模糊原程序的流程或者某一部分的算法，给逆向分析带来一些困难。 由于上述的三个pass是基于LLVM IR实现的, 因此从理论上来说， 这种混淆器是支持世界上任何一种语言和机器架构的。 关于每种pass的详细文档，可以查看下面的这三个链接： Instructions Substitution(指令变换) Bogus Control Flow(流程伪造) Control Flow Flattening(流程平坦化) 上面的这几个链接里面是各个pass的作者维护的一份简单文档，如果你觉得文档不够详尽，建议直接参考相应的源码即可，可能对你来说会又直观又准确。 如果说看代码，其实是比较费劲的一个事情

I am a newbie to LLVM and try to generate a human readable .ll file on Linux. I installed llvm-gcc but as I see it can generate only assembly code (-S option). Is there any way to get something like what is generated by llvm online compiler ? That's what I get with -S -emit-llvm on Linux: .file "hello.c" .ident "GCC: (Ubuntu/Linaro 4.5.1-7ubuntu2) 4.5.1 LLVM: " .text .globl main .align 16, 0x90 .type main,@function main: pushl %ebp movl %esp, %ebp subl $8, %esp movl $.L.str, 4(%esp) movl $1, (%esp) call __printf_chk xorl %eax, %eax addl $8, %esp popl %ebp ret .Ltmp0: .size main, .Ltmp0-main

I'm implementing a simple lazy functional language with LLVM as its backend in Haskell. I've read two books written by Simon Peyton Jones ("The implementation of functional programming languages", as well as "Implementing functional languages: the tutorial") and based on that I managed to implement the G-Machine compiler and interpreter . I'm now currently stuck on the problem of generating LLVM IR code from G-Machine instructions. The main problem is that G-Machine is a stack machine whereas LLVM IR is a register machine. Thus in order to translate G-Machine into LLVM IR I have to maintain

Some system libraries like malloc strlen want or return size_t as parameter. What is the right choice in LLVM IR to interact with these functions? Is the selection the task for the compiler? Does LLVM IR have a size_t type? At the LLVM level, size_t doesn't exist. It is a construct for the benefit of the developer that is typedef'd to a native type. The native types have a fixed size for the target architecture and that is how the compiler represents them in LLVM bit code. So on x86, size_t might by viewed by the front end as unsigned long, which it then writes to LLVM as i32 (since LLVM

If I compile the following code with Clang 3.3 using -O3 -fno-vectorize I get the same assembly output even if I remove the commented line. The code type puns all possible 32-bit integers to floats and counts the ones in a [0, 1] range. Is Clang's optimizer actually smart enough to realize that 0xFFFFFFFF when punned to float is not in the range [0, 1], so ignore the second call to fn entirely? GCC produces different code when the second call is removed. #include <limits> #include <cstring> #include <cstdint> template <class TO, class FROM> inline TO punning_cast(const FROM &input) { TO out;