Projects

{"dots":"true","arrows":"true","effect":"slide"}
ELF Loader Infection
Clean code? Check. Clean compiler? Check. Clean kernel (no rootkits)? Check. Clean libraries? Check. Any extra file? Nope. And yet, malware is sitting there, running behind the scene. Best part, this method can get malware running very early in the boot process. Worst part (for you), you ain't gonna pinpoint it anytime soon.
Learn More
{"dots":"true","arrows":"true","effect":"slide"}
Barebone Filesystem
The barebone file system was implemented as a kernel space file system driver targeting Linux kernel version 4.3 and above. It supported basic file I/O (storage and removal of files). This project was tested using another side-project (virtual mass storage device). The screenshot shows the filesystem (named amishrafs, after myself ) in action on a virtual storage media (/dev/amishra; used another project of mine). Possible uses? Teaching filesystems in depth maybe?
Learn More
{"dots":"true","arrows":"true","effect":"slide"}
Lockpicker
Full disk encryption is a popular method to keep the data secure on physical storage media. It is silently assumed that whole technical stack which facilitates full disk encryption must not be compromised in any way. This project was developed as a proof-of-concept demonstration of filesystem level attack vector, showing data leakage from a LUKS partition while it is in use. This project was powered by another side-project (bare-bone file system), and was tested using yet another side-project (virtual mass storage device).
Learn More
{"dots":"true","arrows":"true","effect":"slide"}
Custom Runtime Loader
This was a bare minimum loader for Linux platform which was able to load binary blobs, identified by a custom magic header, with position independent codes, and run them. The loader worked completely transparently: invoking custom binary blob was enough to trigger the loader and start the process, just like ld.so does for ELF binaries.
Learn More
{"dots":"true","arrows":"true","effect":"slide"}
Reverse Executing Binary
In general, all standard executables run forward, i.e., instruction pointer strictly increases unless there is a jump. As a result all analysts start analysing in top-down fashion once they land on assembly from their favourite disassembler. This proof of concept was designed in such a way that when run as a normal ELF executable file, it runs forward and exits cleanly; but when run with a stager, it runs in reverse, i.e., instruction pointer strictly decreases unless there is a jump, and prints “Hello world” on terminal. This POC exploits some of the techniques commonly found in self-debugging codes. It can be used to obfuscate malware behavior by making in run in reverse in normal operation, and in forward when under analysis. It is also possible to make disassembly impossible (forward and reverse both) (unless the analyst decides to write his own disassembler which bypasses the mechanisms in malware) using previously known techniques.
Learn More
{"dots":"true","arrows":"true","effect":"slide"}
VM based Malware
This proof of concept is built around a self-coded type 2 hypervisor (i.e. hosted hypervisor) which performs hardware assisted virtualization using Intel VT-x. The original machine code sequence (x86) is stored in an encoded form (just a simple XOR), which is decoded right before passing it to VM, and is cleared immediately after it. At time of setup, code is passed to VM using bunch of memory mappings, and input data is passed in registers of virtual CPU, by manipulating initial system state at time of launch. Hypervisor and VM communicate over a virtual serial port. The smallest POC is ~500 bytes in size. The original machine code sequence (x86) is stored in an encoded form (just a simple XOR), which is decoded right before passing it to VM, and is cleared immediately after it. At time of setup, code is passed to VM using bunch of memory mappings, and input data is passed in registers of virtual CPU, by manipulating initial system state at time of launch. Hypervisor and VM communicate over a virtual serial port. POC does not depend upon anything except standard C library (glibc) as shown by ldd output.
Learn More
{"dots":"true","arrows":"true","effect":"slide"}
Tempsmitter
This work is a result of inspiration from Fansmitter attack (ref: https://arxiv.org/ftp/arxiv/papers/1606/1606.05915.pdf), where researchers were able to leak data over noise of software-controlled cooling fan, by controlling its speed from software. Tempsmitter aims to control fans even when the fan is not software-controlled. It is powered by two similar stressing loops (written using MMX instructions) to iterate over a matrix of moderate size, specifically laid out to ensure cache misses at almost every subsequent access (L1-L3), which results in load-cache miss-flush cycle at each access, forcing the CPU to do much more work, resulting in noticeable increase in dice temperature. Box: HP Pavilion DV6 3043TX, which probably has a software-readable fan sensor, which Linux does not seem to talk to. Theory: ---------- 1. Fan speeds up when CPU heats up. 2. CPU heats up when load increases 3. Different components of CPU have different thermal emission properties. Problems: ------------ 1. heavy load for long time will increase CPU temp, but will degrade over-all system responsiveness, which will be a dead give-away signal. 2. CPU is smart enough to optimize for lowest thermal emission while maintaining the performance, and that too agressively (and folks, thats why your CPU has a stable thermal pattern despite of load fluctuation) Plan: Maximize the heat emission while minimizing the stress time. How: Hunted for instructions which have much higher thermal emission relative to other instructions. Hunted for internal CPU events which lead to higher thermal emission (these internal events are minimized by CPU). Laid out an evil plan to outsmart this internal optimization (it happens at microcode level). Mixed them with high thermal emission instructions, and KABOOM! I have used two similar stressing loops to iterate over a matrix of moderate size, specifically laid out to ensure cache misses at almost every subsequent access (not only L1, but L2 and L3 as well ), which results in load-cache miss-flush cycle at each access, forcing the CPU to do much more work (RAM access is costlier than cache access). Plus all those weird instructions are really good in producing heat if you know how to use them Hours wasted: 6 (yesterday) + 4 (today) Test results: temperature increases by 4-6C (slight variation at each run) Duration of test run: ~2s (again, slight variation at each run. Generally falls in 1.9-2,1s range, possibly due to RAM access scheduling) Extra info: All other CPU hogging and non-essential processes were killed.
Learn More
{"dots":"true","arrows":"true","effect":"slide"}
Compile-time Metamorphism
Weekend Fun: Project Dhoomralochana ================================= What is it? A purely compile time mutation engine written in C++17, which generates different instructions for same operation on each compile. How to use it? The engine exposes various data types which are "drop in" replacements for standard C++ data types. You can include the header file(s), and go for a simple "search and replace" across entire project to replace default data types with ones provided by mutation engine. How does it work? The entire engine is written purely in C++ templates. The C++ template metaprogram acts as a code generator for rest of the code. The code generation happens by "mixing and matching" various equivalent sets of instructions, which are selected randomly. The random values come from compile time linear congruential generator which takes seed from current timestamp from system clock. What does it have right now? 1. Instruction swapping 2. Instruction reordering 3. Junk insertion Why? 1. I am too lazy to run a seperate mutation stage. 2. Not willing to install yet another tool (why even bother when compiler works just fine?) 3. Writing a mutation engine itself is challenging. Mutation in templates is even more challenging. 4. For lulz. Current status: started today. Work in progress. Future plan 1. Releasing it in some conference maybe?
Learn More
{"dots":"true","arrows":"true","effect":"slide"}
Runtime Compiled C
It is fun to generate and compile the code on the fly, and then execute it. Since C does not provide such stuff, I decided to develop it just as a fun project. The code is compiled and launched at runtime (instead of interpreting it).
Learn More
{"dots":"true","arrows":"true","effect":"slide"}
Custom Potentiostat
Developed software to interface the potentiostat hardware to computer over USB, and control it directly from computer. Did some hardware work with peers. The project was funded by Indian Institute of Technology, Kanpur, and was guided by Dr. Raj Ganesh S Pala @ IIT Kanpur.
Learn More
{"dots":"true","arrows":"true","effect":"slide"}
C++ Extension
New features added to C++03 by developing a custom translator to generate standard C++ code from non-standard C++ code. The features included foreach loop (later included in C++ 11), cases keyword to work with ranges in switch construct, and repeat...until loop.
Learn More
{"dots":"true","arrows":"true","effect":"slide"}
Hindi Compiler
Developed a small proof-of-concept compiler which accepts source code in Hindi, and emits a binary blob for .NET. The project using handwritten top-down parser to parse the language. MSIL instructions are generated using Reflection Emit (ref: https://msdn.microsoft.com/en-us/library/h0x241a0(v=vs.100).aspx) Video demo: www.youtube.com/embed/w51QUVJp2mc?rel=0
Learn More