From 29babb3f6f5657c4b5d09ffd07c12f06902a7e34 Mon Sep 17 00:00:00 2001 From: _xeroxz Date: Tue, 22 Jun 2021 18:03:47 +0000 Subject: [PATCH] Update README.md --- README.md | 96 +++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 94 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index c0be72c..d5b6e26 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,95 @@ -# LLO - Low Level Obfuscation Framework Draft +# LLO - Low Level Obfuscation (Framework) -This is a design draft for the possible LLO framework \ No newline at end of file +* Language: C++2020 +* Libs: STL (standard template library), [Intel XED](https://github.com/intelxed/xed) +* Casing: snake case + +## Purpose For This Document + +This is a design draft for the possible LLO framework. This document contains theoretical ideas at a drafting stage. This document is being released publicly +for the purpose of obtaining outsider input and is entirely subject to change based upon this input. + +## Introduction - What Is LLO? + +LLO is a low level obfuscation framework designed to be file format agnostic, whilst targeting the Intel x86 ISA, as well as AMD64. LLO's purpose is to +take the heavy burden of code analysis and file format deconstruction and reconstruction off the backs of those interested in designing a code obfuscation algorithm +targeted for x86 and x86_64 specifically. The design of LLO will allow for already compiled binaries to be obfuscated, thus no recompilation will be required, nor any +specific compilers, linkers, or compiler configurations. + + +It's important to state that LLO's end goal is not to prodive obfuscation, it's to provide a framework that allows for one to create their own obfuscation. + +## LLVM Optimization Pass For Obfuscation v.s. LLO (Comparing Against LLVM) + +LLVM optimization passes repurposed for obfuscation is useful when compiling to multiple targets. However, this level of code obfuscation does not allow for instruction +level mutation. In addition, compilation with said optimization pass must be done in order for obfuscated code to be produced. This requires code to be compiled/recompiled +and thus without having the source code the software could not be mutated, unless first lifted to LLVM IR then obfuscated. + + +LLVM "obfuscation passes", will not be able to do simple, instruction level code obfuscation such as appending a segment to a memory operand, or adding in a +scaling memory value. + +``` +mov rax, [rax] +mov rax, [rax*1+0] + +mov rax, ss:[rax] +mov rax, ss:[rax*1+0] +``` + +However, the design of LLVM is much of an inspiration for LLO, as the usage of class inheritance, passes, and other code design features will be applied to LLO. +LLVM "obfuscation passes" are fantastic if you want IR level code obfuscation and not native instruction level code obfuscation. + +## Design Overview + +LLO will consist of four major stages. The first being native file format deconstruction and internal file format construction, in addition, this stage will also +declare where functions begin and end. The second stage will apply obfuscation passes on specified functions. The third and final stage will reconstruct the +obfuscated routines back into a native file format and fix rip relative instructions. + +### Stage One Overview + +Stage one and stage three are the most undecided stages of the framework currently as there needs to be more public discourse on each and every detail. However +as a given, stage one will take, for example, a PE file, and generate an internal file format called LLOIFF or "Low Level Obfuscation Format". This file format in itself +has not been defined yet as, again, there needs to be more discussion and designing. Furthermore, this internal file format will contain a series of sections. Each of these +sections will have a value containing its page protections, virtual memory size, physical memory size, and number of symbols. There could be a structure for symbol as this +could mean many things, a function, a variable in a data section, an import descriptor, etc. These are the details that need to be mulled over. However, this should +provide a clear enough explanation for what stage one should do. + + +Relocations must be handled at this stage as well... The internal file format will contain a place to hold relocations. + +### Stage Two Overview + +Stage two is responsible for dispatching obfuscation passes on specified symbols. Not every single symbol can, or needs to run any obfuscation pass(es). This stage is really +a logistical stage which will allow for the fine tuning of one's desire. A CLI and GUI would implement the features of this stage. + +### Stage Three Overview + +Stage three is responsible for fixing rip relative instructions. Code obfuscation will change the spacing between instructions and thus RIP relative instructions will +need their offsets recalculated or in slang terms "fixed". This stage is also responsible for converting LLOIFF to a native file format. + +### LLOIFF - Low Level Obfuscation Intermediate File Format + +LLOIFF is the intermediate file format of LLO which allows the framework to be file format agnostic. All stages interface with this file format in one way or another so +the design of this format must be considered DEEPLY. Currently this format will not be serializable, meaning it only exists in memory and cannot be sent over the network +or written to disk. The reason for this being ease of use, lack of need for serialization, and expediting development. + + +LLOIFF takes all of the similarities between ELF and PE and abstracts them. For example, for both file formats (and almost all), there are sections. Each of these +sections have a size (virtual and size on disk), protection/characteristic, name, etc... Both PE and ELF have import and export directories, thus LLOIFF would have +an abstracted concept of these. Both ELF and PE have entry points, thus LLOIFF would too... This should be enough information to see what we are going for here, the +details on this are still being considered, but for the time being this should be enough to make sense of the usage... + +## Obfuscation Passes - Overview + +Obfuscation passes are a modular concept which allow for a programmer to interface with the LLO framework in such a way that they will not need to know +the underlying file format, nor will they even need to deconstruct the native file format, nor will they need to find symbols. Obfuscation +passes will be modular enough to support both instruction virtualization, and instruction obfuscation. + + +Obfuscation passes will take the form of native libraries, no other details have been decided though. + + +# Signatures + +Signed: @_xeroxz, @CompiledCode, @irql0, @LimaX