<For some reason, I cannot public it. But I'm planning to open it at some time later >
This blog presents an idea to defend against both ROP (Return-oriented Programming) and JOP (Jump-oriented Programming) attacks ...
It is a low-overhead, real-time, and non-invasive solution with no need target exploit binary/source change.
Tuesday, September 30, 2014
Sunday, September 28, 2014
Why smaller code size with XEN on ARM?
This white paper (Xen ARM with Virtualization Extensions whitepaper) indicates that "Xen on ARM is 1/6 of the code size of x86_64 Xen, while still providing a similar level of features". what does this mean? Does this mean that Xen/ARM is better than Xen/x86? We cannot simply just make this conclusion, but anyway smaller code size means smaller TCB, which can reduce security risks (e.g. security vulnerabilities).
Labels:
AMD-v,
ARM,
Hypervisor,
Virtualization,
VMM,
VT-x,
x86,
XEN
ARM TrustZone (Security Extension) and Virtualization Extension vs x86 Virtualization Technology
A typical virtualization system on both x86 and ARM includes three major parts:
- CPU virtualization
- Memory virtualization, and
- I/O virtualization (device, interrupt virtualization).
Friday, August 15, 2014
Monitor/Trap Software Interrupt INT 80h (System Call) with x86/Intel Virtualization Technology
In an unix-like system, before syscall/sysret and/or sysenter/sysexit instructions were introduced by x86/Intel processors, software interrupt "INT 80h" was used as system call interface. Unlike my previous post, this one is going to talk about how to monitor this old type system call.
Labels:
Hypervisor,
INT 0x80,
Interrupt,
Monitor,
syscall,
Virtualization,
VMM,
VT-x
Monday, July 14, 2014
Kernel Information Leak with Unprivileged Instructions (SIDT, SGDT) on x86 - WHY ?
In computer security, information leaking is one of threats to software security. For example, the memory address of kernel critical resource should not be visible to user mode. Address space layout randomization (ASLR) is just one of techniques to prevent an attacker from reliably getting a particular exploited function in memory.
However, I'm just very curious about why x86 processor leaks kernel data structures by some unprivileged instructions. Is this a bad CPU design?
However, I'm just very curious about why x86 processor leaks kernel data structures by some unprivileged instructions. Is this a bad CPU design?
Friday, June 13, 2014
Exploit NULL pointer dereference bug (ARM and x86)
A NULL pointer dereference occurs when a pointer with the value of 0 (NULL) is assumed to be a valid memory location, and that pointer is then accessed. A write from, or read to, the memory address 0x0 (+ small-offset) will generally reference invalid or unused memory, which typically leads to the majority of published denial-of-service (DoS) attacks both locally and remotely.
Sunday, May 18, 2014
Thoughts on Hardware Virtualization Exception (#VE)
Recently in the latest Intel SDM, you can find that there is a new exception type, Virtualization Exception, in Chapter 6 (Interrupt and Exception Handling) of VOL2.
What is it? How to use it? ...
What is it? How to use it? ...
Tuesday, May 06, 2014
Introduction to Processor Hardware Security Features in x86 & ARM Architectures
x86 and ARM processors both provide many hardware enforced security features, e.g. NX (No-eXecute) for executable space protection, to help system software engineers to build a secure computing environment.
This article summaries those security features for both x86/Intel and ARM architectures, and explains how are they used by Operating System.
This article summaries those security features for both x86/Intel and ARM architectures, and explains how are they used by Operating System.
Friday, April 11, 2014
Yet Another Solution to Monitor/Trap SYSCALL with Virtualization Technology (x86)
This article describes an idea to monitor SYSCALL with x86 Hardware Virtualization Technology. It doesn't require visible guest code/data modification, so that in some cases, even Kernel Patch Protection (e.g. Windows x64 PatchGuard) cannot detect it. Here the SYSCALL could also be SYSENTER or INT 80h for system calls.
Labels:
Exception,
Hypervisor,
syscall,
Virtualization,
x86
Wednesday, April 02, 2014
Thoughts on VMXON and VMCS regions in VT-x (from security's point of view)
Previously when I was working on a Hypervisor based on Intel VT-x. I always did exactly as what I'm told to do in the VT-x specification when programing VMM software.
But now I'm going to revisit this again starting by asking these questions: What if I won't do it as what we're told to do? Is Intel VT-x exploitable? Can we find vulnerabilities in hardware VT-x implementation? Is it possible to do "reverse-engineering" to get internals on VT-x CPU implementation? Can we take advantage of VT-x to attack other privileged resource? Can we bypass EPT layer? However, those are just some open questions, I don't have answers either, but it has a lot of fun when you look into it.
But now I'm going to revisit this again starting by asking these questions: What if I won't do it as what we're told to do? Is Intel VT-x exploitable? Can we find vulnerabilities in hardware VT-x implementation? Is it possible to do "reverse-engineering" to get internals on VT-x CPU implementation? Can we take advantage of VT-x to attack other privileged resource? Can we bypass EPT layer? However, those are just some open questions, I don't have answers either, but it has a lot of fun when you look into it.
Labels:
Bypass,
Hypervisor,
Virtualization,
VMM,
Vulnerability
Thursday, March 27, 2014
How to get to know the memory address at which my code/data is actually loaded at boot initialization stage?
In embedded software development, sometimes when you're writing a PIC (position independent code) boot code, you might need to know at which memory address my bootstrap code/data is loaded by a loader at runtime. This article discusses the solutions to this question with assembly language implementation (x86).
Sunday, March 23, 2014
Good practices for programming with hardcode
What a contradiction!
Programming with many hardcodes is not a good practice because it is hard to understand and also has maintainability issue, for example, when a condition is changed for some reason, the previous well-tuned hardcode value might not be working any more.
However, when there are some conditions under which we must have to write hardcodes when programming, then what're good practices? The rest of this article is focusing on this.
Programming with many hardcodes is not a good practice because it is hard to understand and also has maintainability issue, for example, when a condition is changed for some reason, the previous well-tuned hardcode value might not be working any more.
However, when there are some conditions under which we must have to write hardcodes when programming, then what're good practices? The rest of this article is focusing on this.
Tuesday, February 25, 2014
Approach to retrieving the physical memory map on different system (SFI, LEGACY,UEFI)
According to Wikipedia, in computer science a memory map is a structure of data (which usually resides in memory itself) that indicates how the memory space is laid out. In the boot process, a memory map is passed on from the firmware in order to instruct an operating system kernel about memory layout. It contains the information regarding the size of total memory, the range of specific memory space and any reserved regions, it may also provide other details specific to the architecture and platform.
Friday, February 21, 2014
Monitoring Windows OS scheduling events in a noninvasive way with Hardware Virtualization technology (Anti-Rootkit)
A rootkit is a stealthy type of software, typically malicious, designed to hide the existence of itself or certain processes/programs from normal methods of detection and enable continued privileged access to a computer. However, even though the malicious process/program can be invisible to users, internally it must have to get time slices for running, otherwise if it has no chance to get scheduled by CPU, such an existence is meaningless for malware author.
This article provides a solution to detect the malware and inspect its behaviors by monitoring each OS thread scheduling event.
This article provides a solution to detect the malware and inspect its behaviors by monitoring each OS thread scheduling event.
Labels:
anti-malware,
anti-rootkit,
rootkit,
scheduling,
thread,
Virtualization,
VMM,
Windows
Sunday, January 26, 2014
Debug Registers on Intel x86 Processor Architecture (with or without VT-x)
Intel processor architectures provide debug facilities for use in debugging code and monitoring system behaviors. Such a debug support is accessed using debug registers (DR0 through DR7), and handled by a dedicated exception routine.
Debug registers (Dr0~DR3) hold the addresses of memory and I/O locations called breakpoints. Breakpoints are user selected locations in a program, a data-storage area in memory, or specific I/O ports. They are set where a programmer or system designer wishes to halt execution of a program and examine the state of the processor by invoking debugger software. A debug exception (#DB, vector = 1) is generated when a memory or I/O access is made to a breakpoint address.
Debug registers (Dr0~DR3) hold the addresses of memory and I/O locations called breakpoints. Breakpoints are user selected locations in a program, a data-storage area in memory, or specific I/O ports. They are set where a programmer or system designer wishes to halt execution of a program and examine the state of the processor by invoking debugger software. A debug exception (#DB, vector = 1) is generated when a memory or I/O access is made to a breakpoint address.
Sunday, January 19, 2014
Multiboot Specification and limitations (Bootloader -> OS)
Typically in a computer system, the boot sequence is like this: firmware -> bootloader -> Operating System. The problem is that nowadays we have the largest variety of operating systems, boot loaders, and firmwares (UEFI/Legacy), and even some of them are proprietary software that are not public. So, the interaction might be a problem if the interface is not well-defined.
Saturday, September 21, 2013
Subscribe to:
Posts (Atom)