Update README.md

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
+* 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