My first program on my Samsung Galaxy S

Posted: Aug 21, 2011, 16:17

No, it is not a java program, it is in assembly, which was possible because I recently flashed Cyanogenmod on my phone. Here it is:

.text
.global _start
_start:
    mov r7, #1
    mov r0, #42
    swi #0

The program simply returns 42 and exits. I used my own cross-built binutils (--target=armv-android-eabi) to build this and simply copied it over to my phone, chmod and executed it. You need to put it outside your sdcard environment however, since you cannot execute anything in /sdcard. A Stackoverflow thread helped figure out the right opcode for the syscall.

It took me all of 6 hours to figure this out. 5 minutes to figure out the above code and 5 hours and 55 minutes to realize and fix the last line from

swi 0

swi #0

Comments

Hacking on assembly code: Dynamic memory allocation on stack?

Posted: Jun 26, 2010, 19:59

So I started dabbling with assembly language programming a couple of days ago. This was the next logical step in the "going lower down" move I have been doing ever since I started writing programs in Visual Basic some years ago (there, I admitted it). Since then I went through C#, Java, C++, C and now finally assembly. And it is fun to watch a program die in so many innovative ways. It is helping me understand the internals of a program much better.

One of the first things I learnt about assembly programming was that I needed to use completely different syscall numbers and instructions for x86_64 as compared to i386. For example, the syscall number for exit on i386 is 1 while on x86_64 it is 60. Same goes for write -- 4 on i386 and 1 on x86_64. I spent half an our trying to figure out why my program was calling fstat on x86_64 while a similar program built with --32 would work fine.

Crossing all these hurdles, I finally wrote a slightly more complicated (but still useless) program than a hello world. This is a program that takes in an integer string through the command line, converts it to an integer, converts it back to string and prints it back out. Pretty useful huh :)

Now for the interesting part in the code. I always thought of dynamic memory allocation as something you can only do through the OS using the brk() and/or mmap() syscalls. Generally we do this indirectly through malloc() and friends. But what I ended up doing in my program is allocating memory on the stack on the fly. Here's the code snippet:

    movb $0x0a, (%rsp)
    decq %rsp
next_digit:
    movq $0, %rdx
    divq %rdi
    addq $0x30, %rdx

    # Hack since we cannot 'push' a byte
    movb %dl, (%rsp)
    decq %rsp

The complete code along with the makefile is at the end of this post. You can build it if you have an x86_64 installation. What I do above is simply:

Read a digit from the number
Move the stack pointer ahead to make room for a byte
Store the ascii representation of that number into that byte

I could not use the push instruction itself, since it can only push 16, 32 or 64 bit stuff on to the stack (with pushw, pushl, pushq). If you push a single byte value, it will be stored in one of the above sizes, not in just 1 byte. What I wanted was to create a string on the fly without limiting myself to a fixed size array, so this seemed to be the only approach. While this works, I still need to find out a few more things about this:

Is it safe?
If it is safe, then is there a similar way to do this in C without embedding assembly code? This would be really cool, especially in usage scenarios such as the above. Admitted that the above scenario is pretty useless in itself, but I'm sure there must be similar examples out there that are at least a little more useful.

The code:

.section .data usage: .ascii “Usage: printnum-64 <the number>\n” usagelen = . - usage

.section .text .globl _start

Convert a string representation of an integer into an int

.type _get_num, @function _get_num: push %rbp movq %rsp, %rbp movq 0x10(%rbp), %rdx mov $0x0, %rcx mov $0x0, %rax nextchar: # Iterate through the string movb (%rdx), %cl cmp $0x0, %rcx je call_done

subq $0x30, %rcx
imulq $0xa, %rax
addq %rcx, %rax
incq %rdx
jmp nextchar

Convert a number into a printable string

.type _print_num, @function _print_num: push %rbp movq %rsp, %rbp movq 0x10(%rbp), %rax movq $0x0a, %rdi

# Hack since we cannot 'push' a byte and increment
# %rsp by only 1. push will push whatever it has as
# a 16, 32 or 64 bit value (pushw, pushl, pushq)
movb $0x0a, (%rsp)
decq %rsp

next_digit: movq $0, %rdx divq %rdi addq $0x30, %rdx

# Hack since we cannot 'push' a byte
movb %dl, (%rsp)
decq %rsp

cmp $0x0, %rax
jne next_digit

movq %rsp, %rbx
addq $0x1, %rbx
movq %rbp, %rcx
subq %rsp, %rcx

push %rcx
push %rbx
push $0x01
call _write
jmp call_done

Wrap around the write system call

.type _write, @function _write: push %rbp movq %rsp, %rbp movq 0x10(%rbp), %rdi movq 0x18(%rbp), %rsi movq 0x20(%rbp), %rdx movq $0x01, %rax syscall jmp call_done

I always do this when I am done with a function call

call_done: movq %rbp, %rsp pop %rbp ret

#Program Entry point _start: # Command line arguments: # The parameter list is: # argc: The number of arguments # argv: The addresses of all arguments one after the other # They can be popped out one by one pop %rax cmp $0x2, %rax jne error

# Pop out the first arg since it is the program name, but
# keep the second so that it can be fed into the next function
pop %rax

call _get_num
push %rax
call _print_num
jmp exit

error: push $usagelen push $usage push $0x2 call _write movq $0xff, %rax exit: movq %rax, %rdi movq $60, %rax syscall

The makefile:

32:
    as --32     $(target).s -o $(target).o
    ld -melf_i386   $(target).o -o $(target)

64:
    as $(target).s  -o $(target).o
    ld $(target).o  -o $(target)

If you save the source as foo.s, you can build it with:

make target=foo 64

Comments