in the name of zero

some people argue that yang mi, (guo xiang on roch 2006) is the better dragon girl over liu yi fei (xiao long nu in roch 2006).

to all the conspirators out there, …clearly, you guys are blind.

i mean, yeah, they’re both very pretty, cute.. (and all other words between pretty and cute) young ladies but liu yi fei is tad bit prettier (and cute).

we were given some programs to do in our cs 217 class for practice.

1) palindrome checker
2) vowel and consonant counter
3) case inverter (uppercase to lowercase and vice versa)
4) string reverser
5) and lastly, a menu program that uses arrow keys (menu.asm)

i’ve done all the first four in both 16bit real mode (dos) and 32bit protected mode (linux) as the only difference would be the binary format (com vs elf) and function calling (realmode interrupts and int21h in dos in contrast to int 0x80 in linux). the algorithm still remains the same but i enjoyed doing them nevertheless.

[ the com file ]
it’s simply a plain 16 bit binary with entry point at 0x0100, ss at 0x07a3 and sp at 0xfffe. i found those values by messing with a debug.exe output with the values outlined in this site , hello world.

i quote from the site:

A .COM program has all its segment registers set to the same value, called the PSP, Program Segment Prefix, which DEBUG or DOS establishes at the first free area of memory. The stack pointer SP is set to FFFF, and two bytes of zeros are pushed, so SP winds up at FFFE. Then, execution begins at 0100. A .COM program basically uses only 16-bit offsets, so the segment registers can be loaded with anything (so long as they are equal) and the program will still work properly. Actually, once a .COM program has been loaded and is running, it can do absolutely anything it wants. It can change segment registers, or load more code, or anything else like this. (In Windows, it may be limited, but not when running under DOS).

my debug.exe output. relevant values are in bold.

dos@localhost C:\CS217>debug c:\cs217\test.com
-r
AX=0000  BX=0000  CX=00AA  DX=0000  SP=FFFE  BP=0000  SI=0000  DI=0000
DS=07A3  ES=07A3  SS=07A3  CS=07A3  IP=0100   NV UP DI PL NZ NA PO NC

i guess that’s all there is to it for the .com binary format. at this point, i scrapped a86 and used nasmi instead to make com files for our class. with the added benefit that i’m used to using nasm (intel syntax also) for everything related to assembly.

[ menu.asm ]
of the five assembly tasks that were given, i found number five to be the most interesting. (come to think of it, i’ve never did any assembly in linux that prints a colored string.)

make a program that prints a menu, then use the up/down arrow keys to scroll thru the menu choices. indicate that a particular menu is highlighted by changing it’s color. also provide a “quit” choice.

to grainne, you’ll find this list useful.

up	72	; up arrowkey
down	80	; down arrowkey
return	13	; enter key

to my classmates,

just incase you guy are sick and tried of doing a86 (hey! i am!), try out nasm for windows.

just add an ORG and bits directive in your listing before anything else like so,

ORG 0100h	; because .COM starts at 0x0100
BITS 16		; we are going explicit 16 bit mode

then assemble your listing by doing

nasm -f bin -o hello.com hello.asm

we’re doing 16 bit real mode assembly in class this semester so i’m making all my class work inside an emulator. this time, i’m doing something in 32 bit protected mode linux (as a refresher).

it’s supposed to be a program that waits for user input and tells if it’s a palindrome or not.
(more…)

got into a problem with my usb thumdrive this morning as i was transferring an anime movie - naruto and the snow country princess. free space was virtually cut in half because of some filesystem inconsistencies.

i even did “rm -rf *” out of frustration but to no avail. i feared the worst…

df reports:
/dev/sda1 998M 413M 586M 42% /mnt/nokia

where it should be:
/dev/sda1 998M 4.0K 998M 1% /mnt/nokia

nothing that fsck.vfat can’t fix.

running a distributed dot net client for the RC5-72 project. the only thing lacking now is an init script to make the dnetc cruncher run at startup. back then, i kept a custom gentoo runlevel named “einstein” for distributed-nature hobbies like seti@home and folding@home. thinking about that now, i guess it was kinda pointless to keep that. *giggle*

i’m still considering about contributing to the seti@home (boinc) cause. i stopped a few months back because of a hard disk failure. didn’t have the motivation to install boinc again.

here’s hoping i’ll nail the winning chunk.

grats to crp- for solving! greets to grainne for inspiring me to write this crackme.

well, in a nutshell, this crackme relies on some simple checks to trigger a cracked condition. i wrote it in c one very hot day while recovering from a sprained ankle. i’ll first explain some nonsense and after that, i’ll finally post the crackme listing for the benefit of everyone.

a) first it checks for a 5 byte file LiuYiFei_143 in the current directory
b) second, it does a simple checksum on argv[1].

here are a few assumptions/ideas that led me to design my crackme the way it’s designed now.

a) anti-ptrace protections are placed in an easily found area, that is, inside a function like main().
b) a lazy cracker can simply override weak functions like ptrace() and other library calls.
c) the strings utility can be used to print strings and i don’t want any cross references easily seen.
d) objdump and other “bfd” (binary file descriptor library) based tools rely on section headers.
e) luring them away from the real check as much as possbile sounds like a good plan.
f) i still don’t know enough to make a very hard crackme.

i tried approaching assumption a, “anti-ptrace in an easily found area” by using constructor attributes. gcc manual. what happens is that before control reaches the main() function, many other functions are called.. i won’t go into details about all those functions except the contructor functions. they are called just before main.

because of this merit, i thought it would be a good place to put protections. in comes your PTRACE_TRACEME trick. but, ptrace is a weak function. and any student of reverse engineering can simply go past this if he uses LD_PRELOAD. in comes the second protection. prevention of LD_PRELOAD overrides. this is for assumption b.

if there are constructor functions that resolve before main() there are also destructors that resolve after main(). i placed the check for the crack condition here. as they resolve automatically, i dont need to call them explicitly. so you wont find any actual link for the primary check condition and the the function to print the string cracked in the main() function.

now, for assumption c, the “strings” utility is a handy tool to print printable characters in files. it’s always used for preliminary forensics so i wanted to raise the bar a bit higher by preventing the “strings” utility from printing strings like the filename “LiuYiFei_143″, the string “Cracked!” and the string “LD_PRELOAD”. winding them with a simple xor operation did the trick. i had to therefore, unwind these strings before actually using them so i also included a string decryptor function. try running “strings” on the crackme to see for yourself.

assumption d is a bonus. i only corrupted the elf header sections, not the section themselves! i’ll remember to do that next time! also, i’ll really consider doing static linkage at the cost of binary size.

assumption e, is self explanatory.

idea f is impossible to achieve.

if you’ve reached this far! you must really be bored now! here’s the source code for my crackme as promised.
(more…)

my new hobby - origami

note to self: update this entry

today, our class will go on a two and a half day retreat. no cellphone, t.v., internet, computer, radio for me. see you all after three days.

bye bye