in the name of zero

January 31, 2006

dynamic memory allocation in linux assembly

Filed under: hermetic studies

i feel so at peace with myself recently! i can take any torture and my happiness still won’t fade away. today is january 31, and i think i already know what to say to steph fourteen days starting tommorrow.

our group of three members spent the better part of the day today constructing our logic circuit for tommorrow’s digital designs class. wiring integrated circuits is actually quite fun! we seldom found ourselves talking about things that are totally unrelated to our homework. i for instance, talked mostly about steph. i didn’t touch any keyboard until about 4 o’ clock pm.

anyway, onto the subject matter at hand, dynamic memory allocation in linux assembly. it was just another one of my dumb ideas to write my own malloc() function. nothing really fancy in that .. just a simple bare bones allocator library.. error and bug prone at that. lots of reading ahead!!! (i need to get a life outside my room me thinks)

i decided to approach that goal by understanding first the sys_brk system call. which is a kernel interface to adjust the data segment boundary. i’m guessin i’ll manage to make lots and lots of memory leaks ahead! so i’ll use valgrind(don’t know if this will work) and strace too in this activity. hopefully, i can make my own simple malloc() in c after i finish this activity. wish me luck!

(more…)

still stuck at ‘that’ particular time frame

i’m interested in these articles.. i’ll give them a shot sometime soon… that is, if i ever do recover from my shock and delight. oh god! steph talked to me! woohooo!!

introduction to the streaming SIMD extensions part 1, 2 and 3

behind the scenes of memory management

doug lea’s dmalloc

smashing the stack for fun and profit by aleph one

shellcoding for linux and windows

this ladies and gentlemen.

January 30, 2006

having fun with strace

i don’t have any strength to do assembly today (and for the rest of the week) because i’m so happy that stephanie talked to me! my mind is somehow still stuck at that particular time frame and i’ve only been thinking about her ever since this afternoon. i don’t know if that will change anytime soon. she’s such a goddess!

today, i’ll just be doing some strace-ing. still a fun activity imho. i’m curious as to how exactly things work in the background. for my first strace activity, i’ll use my most recent work. i hope to gain more understanding about system calls in linux and of of course, how to use basic strace to diagnose programs.

(more…)

it’s a good day to die

steph spoke to me!! jesus christ she actually spoke to me! i’m soo happy i can’t even think of what to write next! feeling so light and helpless.. someone hold me tight please.

i don’t know where to put my heart today… it’s so full of love and joy!

oh lord! thank you!

January 29, 2006

assemblifying a bash script

first and foremost, to my chinese brothers and sisters out there,

“xin nian kuai le”

way back, i frequently found myself descending deep into the recesses of my git repository. i keep all sorts of stuff there. but more importantly, i keep all my work neatly categorized in special folders inside. anyway, i decided to come up with some remedy, enter bash scripting. i made a (pretty much) straight forward script to create a symlink in my home directory called “workdir” so if ever i wanted to go back to my work, i’d only cd ~/workdir right away.

#!/bin/bash
	
# this script makes a symlink "~/workdir" to
# the pwd or to the first argument
	
CWD=`pwd`
SHORTCUT=/home/amerei/workdir
	
# create a symlink
# if a symlink exists remove it first
function my_linkie {
	if [ -h $SHORTCUT ]; then
		rm $SHORTCUT
	fi
	
	ln -s $CWD $SHORTCUT
	
	exit 0
}
	
# if there are no arguments assume
# current directory to be the target
# otherwise, honor only the first argument
if [ $# = 0 ] ; then
	my_linkie
else
	# i don't want a broken symlink
	# file exists and is a directory
	if [ -d $1 ]; then
		CWD=$1
		my_linkie
	fi
	echo "$1 is invalid"
	exit 1
fi
one day, i was bored so i tried to implement the script above in assembly. here goes..

(more…)

January 26, 2006

going crazy over the downy song

it’s a happy day with downy.

alagang mommy, alagang downy.

it’s a happy day with downy.

pag nag downy na si mommy!

January 25, 2006

intermission

i find it absolutely hilarious whenever someone starts talking about things that are way above his/her head. a stroke of ego? or perhaps a noble attempt to boost foolish zealotry, their reasons always elude me.

anyway, here’s my take on some things he said. (keep newbies away from c)

To actually do anything useful, you have to teach them pointers— and even seasoned programmers have a hard time with pointers;

it’s actually very convenient to use pointers in every C program. the only problem i see here is that in C, one has to explicitly employ garbage collecting for every dynamic allocation he makes. learning other languages first (that don’t employ pointers) cannot in any way be helpful to anyone when he first tries to learn pointers. those who can’t speak C prolly shouldn’t be programming anyway.

There is no real string library, and strings are not real first-order types (i.e. char * is simply an array of characters, and you should really remember that);

what kind of dumbfuckery is this? first and foremost, char * is abso-fucking-lutely NOT an array of characters! where the hell did you learn about this stuff? char * is a 4 byte pointer to a memory location that holds a 1 byte value. it isn’t and will never be, an array of characters!

consider this snippet: (will spit out a warning about incompatible pointer types)

int main(int argc, char **argv)
{
        unsigned short number;
        char *pointer;
	
        number = 0x100A;
        pointer = &number;
	
        printf("0x%02x\n", *pointer);
        printf("0x%02x\n", *(pointer+1));
	
        return 0;
}
as for string libraries, C has lots of them. mix and match. use your imagination. a string in C is an array of (null terminated) characters which are primitive data types. as such, all operations must be done at an atomic level. the contention about a real string library here is overrated and biased over an object oriented implementation.

Teaching C to beginners will keep such bugs as memory leaks and buffer overflows alive, and cause even more problems for future generations of users;

on the other hand, shielding them from these abominations just makes them overly dependent and trusting to libraries. “hey! i write memory leak and buffer overflow free programs coz [language] libraries are free from them!

C is quite low-level, and unless you have a firm grip on data structures and how they are used, learning C won’t help.

how come? data structures are used in every programming language and sooner or later, a student will eventually realize that he already needs to use them (like if he wants to return two values from a function at the same time). the only difference is abstraction. anyone must have a firm grip on data structures regardless of the language.

Worse, thinking in C forces you to think at such a low level, you won’t really learn how to think in terms of the problem space

this might be true to some extent. especially since the biggest win of C is being able to point to memory locations and meddling with atomic, low level, insignificant elements. but that is why algorithm studies are coupled with any programming courses. that is, after the student has gained a little insight and confidence with the language at hand (C or any other language for that matter). anyone can write equally bad implements on any language.

it boils down to this statement: “all i’m saying is that C is as good a first language as any language.”

January 22, 2006

a finer look at elf

Filed under: hermetic studies

first and foremost… to manny pacquiao, congratulations! and mabuhay! godbless the philippines!!!!

the linux binary from scratch program really fascinates me to no end. and now, i’m obsessed! can i now account every last byte in my program like what brian raiter did here? well if i take a look at the assembly listing, i guess so. but this time, i’ll try a different approach. i’ll try going through the program at hexadecimal level, count my way to the last byte and hopefully, give some meaning to the gibberish on my screen. besides, this activity will help me familiarize myself with a tool called, the hex editor. i’ll be using app-editors/hteditor to browse through the file and sys-apps/hexdump to print it’s contents at the terminal.

but before actually jumping right in, i just want to verify something essential that will really be useful when looking at a hex dump of a file! it is called “endianness of a processor”. i’ve read some time ago that intel architectures are “little endian” machines. that is, the least significant part goes first instead of the normal “big endian” way.

perhaps an example would illustrate this much much more clearly.

; endian.asm
; ----------------------------------
; a simple endianness testing thingy
; how is 'deadbeef' (hex) stored?
	
        dw      0xdead
        dw      0xbeef

so how does the intel processor look at deadbeef? let’s check shall we?

amerei@heaven ~/workdir/elf_magic $ nasm -f bin endian.asm
heaven ~/workdir/elf_magic $ hexdump -C endian
00000000  ad de ef be                                       |....|
well! what do we have here!? ad de ef be? if we inspect it closely, we would notice that ‘ad de ef eb’ is just an inverted (sort of) version of ‘de ad be ef’! that proves that my machine, (intel pentium three) is a little endian architecture. the most significant byte of the hexadecimal number dead is de and it’s least significant part is ed. and as what i’ve pointed out earlier, least significant parts come before most significant parts in little endian architectures. looks like people weren’t lying afterall about intel storing word values backward. i should have more faith next time.

now that i’ve verified my machine’s endianness, i suppose i’m now ready to take a peek inside the elf binary i made.

(more…)

January 21, 2006

understanding elf magic : the section header and success

Filed under: hermetic studies

today, i spent the entire day constructing the section header table of my simple program. i also changed some bytes in the elf header to accomodate the section headers and string table index. so without further blabber, here are the additions.

; ----------------------------
; start of segment definitions
; ----------------------------
	
; program entry
_start:
	
	mov eax, 4
	inc ebx
	mov ecx, stringy
	mov edx, strlen
	int 0x80
	
	xor eax, eax
	inc eax
	xor ebx, ebx
	int 0x80
	
s1	equ	$-$$
	
; data segment
dataseg:
	stringy db "I LOVE STEPHANIE!", 10
	strlen	equ $-stringy
d1	equ	$-dataseg
	
%assign liner	(dataseg-$$)
dsegoff	equ	(liner&-8)+8
p_vadd1	equ	$$+(dsegoff)
dseglen	equ	$-dataseg
	
%assign multiplier	(s1/0x1000)+1
psize	equ		0x1000*multiplier
	
; --------------------
; section header table
; --------------------
null_section:
	dd	0	; sh_name
        dd	0	; sh_type
        dd	0	; sh_flags
        dd	0	; sh_addr
        dd	0	; sh_offset
        dd	0	; sh_size
        dd	0	; sh_link
        dd	0	; sh_info
        dd	0	; sh_addralign
        dd	0	; sh_entsize
shdrsize equ $-null_section
	
; text header
text_section:
	dd	11	; .text
	dd	0x1	; SHT_PROGBITS
	dd	0x6	; SHF_ALLOC+SHF_EXECINSTR
	dd	_start	; sh_addr
	dd	_start-$$
	dd	s1	; sh_size
	dd	0	; sh_link
	dd	0	; sh_info
	dd	16	; 16 byte alignment
	dd	0	; sh_entsize
	
; data header
data_section:
	dd	17	; .data
	dd	0x1	; SHT_PROGBITS
	dd	0x3	; SHF_ALLOC+SHF_WRITE
	dd	dataseg	; sh_addr
	dd	dataseg-$$
	dd	d1	; sh_size
	dd	0	; sh_link
	dd	0	; sh_info
	dd	4	; 4 byte alignment
	dd	0	; sh_entsize
	
; string table section header
str_section:
	dd	1	; sh_name
	dd	3	; sh_type
	dd	0	; sh_flags
	dd	0	; sh_addr
	dd	stab-$$	; sh_offset
	dd	stbsz	; sh_size
	dd	0	; sh_link
	dd	0	; sh_info
	dd	1	; sh_addralign
	dd	0	; sh_entsize
	
; string table
stab:
	db	0x0, '.shstrtab',0x0,'.text',0x0,'.data',0x0
stbsz	equ	$-stab

figuring out the section headers.. especially the section that deals with the string table was confusing at first. the elf specification was written by a sadistic writer i assume. the alignment issues also made me doubt if the progam would even work.

amerei@heaven ~/workdir/elf_magic $ nasm -f bin elfhead.asm
amerei@heaven ~/workdir/elf_magic $ chmod +x elfhead
amerei@heaven ~/workdir/elf_magic $ file elfhead
elfhead: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
amerei@heaven ~/workdir/elf_magic $ du -b elfhead
342     elfhead
amerei@heaven ~/workdir/elf_magic $ ./elfhead
I LOVE STEPHANIE!

there you go! a linux elf binary that is truly from scratch.

signing off.

January 20, 2006

understanding elf magic : the elf and program header

Filed under: hermetic studies

lo! the road to elf sorcery is fraught with difficulties and nasty “gotchas”. i don’t know if i’m on the right track, so i’m posting my uncompleted work. and if ever a real wizard passes by, perhaps he could fill me in on some parts i did wrong.

BITS 32
	org	0x08048000
	
; ----------
; elf header
; ----------
ehdr:
	db	0x7f, "ELF", 1, 1, 1
times 9	db	0x0
	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	2		; e_phnum
	dw	0		; 3_shentsize
	dw	0		; e_shnum
	dw	0		; e_shstrndx
ehdrsize equ	$ - ehdr
	
; program header macros
%define pt_load	1
%define	p_align	0xf
%define	pf_rx	5
%define	pf_rw	6
	
; --------------------
; program header table
; ---------------------
phdr:
	dd	pt_load		; p_type
	dd	0		; p_offset
	dd	$$		; p_vaddr
	dd	$$		; p_paddr
	dd	s1		; p_filesize
	dd	s1		; p_memsize
	dd	pf_rx		; p_flags
	dd	p_align		; p_align
phdrsize equ	$-phdr
	
phdr1:
	dd	pt_load		; p_type
	dd	dsegoff		; p_offset
	dd	p_vadd1+psize	; p_vaddr
	dd	p_vadd1+psize	; p_paddr
	dd	dseglen		; p_filesize
	dd	dseglen		; p_memsize
	dd	pf_rw		; p_flags
	dd	p_align		; p_align
	
; ----------------------------
; start of segment definitions
; ----------------------------
_start:
	; this will eventually hold sys_exit(0)
	
s1	equ	$-$$
	
dataseg:
	; .data is zero bytes big
	; linux 2.6.12+? requires explicit .data segment declaration
d1	equ	$-dataseg
	
; this part is very  ugly. :(
; i don't even know if this is right!!!
; align dataseg p_offset to an 8 byte boundary
%assign liner	(dataseg-$$)
dsegoff	equ	(liner&-8)+8
p_vadd1	equ	$$+(dsegoff)
dseglen	equ	$-dataseg
	
%assign multiplier	(s1/0x1000)+1
assign psize		0x1000*multiplier
	
; --------------------
; section header table
; --------------------
things look good in objdump so far.. i think.

objdump -x elfhead
elfhead:     file format elf32-i386
elfhead
architecture: i386, flags 0x00000102:
EXEC_P, D_PAGED
start address 0x08048074
	
Program Header:
    LOAD off    0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12
         filesz 0x00000074 memsz 0x00000074 flags r-x
    LOAD off    0x00000078 vaddr 0x08049078 paddr 0x08049078 align 2**12
         filesz 0x00000000 memsz 0x00000000 flags rw-
	
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
SYMBOL TABLE:
no symbols
contructing the elf header was relatively easier than constructing the program header table thanks to the elf specification. i did look at the elf header example at the whirlwind tutorial from time to time to verify if i was still on the right track of course. objdumps of my former asm programs were very much useful since they provided some sort of blue print-cheat sheet for me.

understanding the difference between “file scope” and “virtal memory scope” was a bit of a stumbling block. again, thanks to my blue print-cheat sheet, i was able to understand those concepts. file scope is offset that is relative to zero. “virtual memory scope” is offset that is relative to the memory address i specified in nasm’s org directive, that being 0x08048000.

anyway, on to the meaty stuff. the code above starts off with an elf header that specifies two (2) program headers (e_phnum) for .text and .data sections respectively. i still haven’t covered the part about “section header table“. reading the elf spec some pages down sure takes a lot toll on your body! i hope to cover more ground tommorrow and post yet another progress report.

for now.. i need steph!

Get free blog up and running in minutes with Blogsome | Theme designs available here