Fugitive Thought

Login | Register | RSS | Help

Fugitive Thought

small logo

Featured Articles:


Keyboard Loopback
Properly Extending NTFS disks
Compiling Amarok
Prado Benchmarks
Smarty Caching in Code Igniter

In Progress:

Safer PHP - avoiding compromise through good design

Preventing SQL injection, information leakage, and writing an authentication system from the bottom up.


New Projects:

Thin Client Clustering

Writeup coming soon.

Evading Email AV

For individuals seeking to study virus/trojan/malware behavior, email AV scanners are a bother. Thus this little application.

Corrupt Partition Recovery

Justin's foray into the lovely world of lost data....


Random Links:
On Fugitive Thought:

Fugitive Thought Archives
Bold - Today
Dark - Blog Entry

Playing with Assembly

March 18, 2010 - By Justin

So I was reading Slashdot yesterday when I came across a link to this article which is basically a crash course in writing super small programs using assembly language (nasm in Linux). I was completely in awe of their acquired 45 byte executable and took it upon myself to learn the basics of assembly.

My first attempt was to write a hello world (the article writes a 45 byte executable that just returns the number 42). That worked super well and was as easy as I thought, so I decided to play around with a couple of more system calls and write a program that sends hello world to a file in /tmp/. There were a few errors that I came across, so I got some help from the friendly guys in #asm on freenode IRC and figured out the last part. Here is the code, and after it is an explanation of the two parts the screwed me up.

; tiny.asm
BITS 32
		org		0x08048000

	ehdr:                                       ; Elf32_Ehdr
		db			0x7F, "ELF", 1, 1, 1, 0         ;   e_ident
		times		8 db      0
		dw			2                               ;   e_type
		dw			3                               ;   e_machine
		dd			1                               ;   e_version
		dd			_start                          ;   e_entry
		dd			phdr - $$                       ;   e_phoff
		dd			0                               ;   e_shoff
		dd			0                               ;   e_flags
		dw			ehdrsize                        ;   e_ehsize
		dw			phdrsize                        ;   e_phentsize
		dw			1                               ;   e_phnum
		dw			0                               ;   e_shentsize
		dw			0                               ;   e_shnum
		dw			0                               ;   e_shstrndx
  
	ehdrsize		equ		$ - ehdr
  
	phdr:                                       ; Elf32_Phdr
		dd			1                               ;   p_type
		dd			0                               ;   p_offset
		dd			$$                              ;   p_vaddr
		dd			$$                              ;   p_paddr
		dd			filesize                        ;   p_filesz
		dd			filesize                        ;   p_memsz
		dd			5                               ;   p_flags
		dd			0x1000                          ;   p_align
  
	phdrsize		equ	$ - phdr

_data:
		msg		db		"Hello, World!", 0xa
		len		equ   $ - msg
		file		db		"/tmp/test.out", 0x0

_start:
		; create the file /tmp/test.out
		mov		eax, 5
		mov		ebx, file
		mov		ecx, 66
		int		0x80

		; save the file descriptor
		mov		ebx, eax

		; set read/write permissions on the file
		mov		eax, 94
		mov		ecx, 0x1ff
		int		0x80

		; write the string to the file
		mov		eax, 4
;		mov		ebx, 1			; uncomment this to print to stdout instead
		mov		ecx, msg
		mov		edx, len
		int		0x80

		; close the file
		mov		eax, 6
		int		0x80

		; exit
		mov		eax, 1
		mov		ebx, 0
		int		0x80

filesize			equ	$ - $$

You can build and execute this yourself straight from Linux command line if you have nasm installed by saving it as tiny.asm and executing "nasm -f bin -o a tiny.asm && chmod +x a". I have the ELF headers embedded directly into the assembly and we use ZERO external libraries so there is no linking needed. In fact, since pretty much everything executed is system calls, you can then run strace on the resultant executable (named "a") and it will give you a pretty nice dump of exactly what it does.

The first thing that kind of tripped me up was when I created the file, it creates by default with no permission flags set at all. To fix this, I added an fchmod call right after I opened the file. The hex value I pass to as the second parameter (ecx) is just the hex value for 777 permissions. That set the permissions right but originally when I went to write to the file it still wouldn't write. Thanks to the IRC help I figured out that when I was opening the file, I was opening with O_CREATE (62) when what I really wanted to do was open it with O_CREATE | O_RDWR so that I could write to it as well, so I changed the mode parameter of the call to open to 64 instead of 62 et voila, it works!

Hope you enjoy and maybe it'll help somebody else out who is trying to write to a file with assembly in Linux.

Xen HVM + obtaining platform data

2009/09/02 - By Steve

The following provides an overview for a quick little project I threw together motivated by some inquiries in the ##xen IRC channel on Freenode.org. It involves a kernel module; full source is included.

Audience: Xen users/admins running linux in HVM context (without the pv-on-hvm kernel module in use) who have avoided paravirtualization for various reasons, yet require information about the underlying virtualization platform.

The following is directly excerpted from the README file.

This is a kernel module for use with linux virtual machines, running in HVM mode atop the Xen hypervisor.

In essence, it functions as a Xen hypercall skeleton for HVM guests, querying the hypervisor for information. Linux is rarely run in this mode unless there is some operational requirement imposing full hardware virtualization instead of paravirtualization. That said, it is occasionally useful for management purposes to obtain a VM UUID from within the guest rather than via the control plane.

Offers information via /proc/zentific including the uuid of the VM and major/minor version information from the underlying hypervisor.

Yes, /proc is 'deprecated.' It was convenient. :)  I'll update this if anyone ever actually cares.
 
 
Instructions
---------------------------------------------------------------------------
1) Build the module
        a) make sure kernel headers are installed
        b) make sure a full development toolchain is installed
        c) run 'make'
2) /sbin/insmod zentific.ko
2a)     alternatively use modprobe if preference/requirement dictates.
3) run dmesg to see some status and initialization output
3) cat /proc/zentific/{uuid,xen_ver}
4) /sbin/rmmod zentific

 

Download: http://www.zentific.com/files/zentific-kernel.tar.gz

Xen 3.4 on the Asus EEE 901

2009-05-09 - By Steve

In pursuit of easy Zentific development while on the go, I've been poking at my Asus EEE 901 for some time, trying to convince xen to work properly upon its somewhat unusual platform. Xen isn't necessarily appropriate for workstation virtualization (even though I make it work), so thus the trouble. I can't promise an experience like that encountered on a nice Opteron 8xxx or Xeon/i7 platform, but if you're like me this may be a good solution for you.

In fact, I'm posting from my eee running Xen this very moment.

As with all such things, the devil is in the details. The trouble with the EEE is its relatively recent hardware. The 2.6.20 kernel distributed by Asus with its custom xandros derivative is very hacked to support such hardware - not that this is a bad thing, because it works wonderfully, but it implies that stepping outside of that rather custom-built box introduces some fun. As it is, the wifi drivers are - as of 2.6.30 - still in the unofficial, not-endorsed, 'staging' section of the kernel, otherwise known as the scary experimental department. Yes, that's ten versions after the .20 kernel originally running this thing, which demonstrates just how new some of this hardware is from a driver perspective.

But I digress, as usual.

I've been running the netbook remix version of Ubuntu Hardy. This is essentially a normal Hardy install with a patched version of 2.6.24 to support hardware appropriately, plus a few userspace helpers and some nice interface tweaks for the tiny screen. At any rate, this distribution is entirely sufficient for Xen (I take issue with the Ubuntu Xen package maintainer and moreover the way Canonical is approaching virtualization, but that's a different post. :)

So, the details:

I've built Xen 3.4-rc4 and a 2.6.30-xen kernel directly derived from Jeremy Fitzhardinge's paravirt-ops tree at git.kernel.org. The former includes its own 2.6.18 kernel (with many backported drivers), but the system is only barely usable in that state. With my kernel, however "everything works" - in quotations because it's not really everything (the webcam doesn't for example), but that's good enough for me for the time being. If someone really cares, I'll poke at it some more.

The meat can be found at http://zentific.com/files/eee/pvops-dom0-xen-kernel.tar.gz and http://zentific.com/files/eee/xen-3.4-rc3-eee.tar.gz -- but be sure to peruse the readme I've put together for particulars. http://zentific.com/files/eee/readme

Hope this helps someone. If not, oh well. Fugitivethought is my personal braindump so I can forget about some of the details and come back to check later.

Any questions, notes, etc email me or leave a comment.

-s

Zentific updates

2009-03-24 - By Steve

Why yes, Zentific can do RDP.

and now, so can xen. :)

Email me or leave a comment if you are interested in the source..

Parallelization in PHP

January 7, 2009 - By Justin

This is a simple example you can re-use for splitting up processing of data across processes for faster execution. Put all of the data into the $set and fill in function process with what you want to do on the data, and let 'er loose! I'm personally using it for telnet scripts because the amount of time spent waiting for a single telnet session is horrible and I can run many sessions at once while I wait for the responses.


/**
 * Splits the given set into $count subsets that are of approximately equal size
 */
function array_split($set, $count) {
   $subset_size = ceil(count($set) / $count);
   return array_chunk($set, $subset_size);
}

/**
 * Forks into $process_count separate processes and executes the function
 * named in $job in each process to split up handling of the data in
 * $set across the processes.
 */
function fork_exec($set, $job, $process_count) {
   $subsets = array_split($set, $process_count);
   $children = array();

   // launch all of the children and store process list
   foreach ( $subsets as $a_set ) {
      $pid = pcntl_fork();

      if ( $pid == -1 ) die("Error forking");
      else if ( $pid == 0 ) { call_user_func($job, $a_set); exit(0); }
      else $children[] = $pid;
   }

   // wait for each process to end
   while ( count($children) > 0 ) {
      $pid = array_shift($children);
      pcntl_waitpid($pid, $status);
   }
}

// example set to work on
$set = array('a','b','c','d','e','f','g','h','i','j');

// Process the job with 3 threads and time it
$time = microtime(true);
fork_exec($set, 'process', 3);
$diff = microtime(true) - $time;
echo $diff . ' seconds for full run'."\n";

// This is the job to run on the set. Make sure it is multi-process safe!
function process($set) {
   foreach ( $set as $item ) {
      echo "Process [" . posix_getpid() . "] executing '" . $item . "'\n";
      sleep(1);
   }
}

Virtualization: Hardening Xen

2008 December 9 - By Steve

Coming soon in this entry, details about hardening your xen installations.

Topics to be discussed include:

-paravirtual framebuffer: intended function, patch sets, and practical considerations. 3.0.4 and up.
-pygrub
-xenstore denial of service
-networking (ebtables, iptables, etc)
-vnc over SSL
-xenapi over SSL
-minios, stubdomains, pvgrub
-driver domains
-pci passthrough (why DMA spells disaster when lacking an IOMMU)

In progress and coming your way as time permits. Check back soon.

http://www.zentific.com :)
Archives: >  >>
About Us | Site Map | Privacy Policy | Contact Us | ©2006 Justin DeMaris & Steven Maresca