Gustavo Silva's Techie Blog

Give me an example and I'll learn to fly…

Hacking a Stellaris Board – Part II

No Comments »

Let’s continue

In the first part we learnt how to interact with the Stellaris board using OpenOCD and GDB, we also performed a dump of the entire image of the flash memory.

Analyzing the memory

OK, now lets to analyze the memory content. A very important thing you should notice is that the empty memory is represented by 0xFF, using the GHex editor we look for the part of the memory where there is nothing more than only 0xFF, in this case I find that the address where the empty flash memory starts is 0x0002A748 so based on this we can determine that the size of the application into the flash memory is about 170 KB so we have 86 KB of free memory. Take a look at the picture below.

Let’s try some assembly code

The next step is to implement some tiny programs and load them in some point using the free memory.

The following code perfom some simple instructions to count even numbers in the range from 0 to 10.

Remember that at this point we have two consoles, in the first one we are running the openocd server and on the other one we are running the gdb client. We need a third console which will be used to assemble and link the tiny_program.s file.

OK, now lets see how to create the object and binary files.

The options -mcpu and -mthumb are used to define the instruction set we want to use. For a better understanding of these and other options I recommend to read the User Guide to the GNU Assembler as.

Loading the binary file to the Stellaris board

Now it is time to focus on the gdb client and load the tiny_program.bin file to the flash memory:

Notice that we are using the address 0x0002A810 in the write_image command to indicate that we want to write our program in this address. As we already know the flash memory is empty starting from the 0x0002A748 address, so we just have to choose any address higher to load our assembly program (in this case the address is 0x0002A810).

If you want to be sure the assembly program is actually located in the address 0x0002A810 you should try the same steps we tried when we dumped the entire board image for the first time, so the binary image should look like this:

Running the assembly program on board

The next step is to set the Program Counter (PC) to the address 0x0002A810 (which is where our assembly program is located) and start typing the GDB commands ‘ni’ and ‘i r’ which means next instruction and info registers respectively.

Put special attention to R0 and R1 registers, see that at some point R0 takes the value of 10 and then decrements to 8 and so on until reach the value of 0. R1 is used to hold the count of the even numbers (10,8,6,4, and 2). At the end R1 reach the value of 30.

At this point we have hacked the Stellaris board using OpenOCD, a low cost ARM USB JTAG and the GNU tool chain. A lot of things are open for learning, in the future I will take these posts as a base for explaining some interesting things I did not cover here.

Thanks a lot for reading this post and see you around! :D

Backtrace a process until reach its first parent

No Comments »

Introduction

Processes are the soul of any operating system. One of the major tasks of any operating system is the process management.

At kernel-space level processes are usually called tasks. In GNU/Linux OS each process is identified by a unique Process ID (PID). If you type $ ps -e you will see every process on the system.

This time we will implement a module to backtrace a process (given its PID) until reach its first parent process.

An easy and fast way to access the kernel-space at the user-space level is using the Process File System (procfs).

The Process File System is a Virtual File System (so it is a pseudo-filesystem) used to configure kernel parameters and to obtain information about the system. The information in the Process File System is generated on the fly at the moment it is accessed. The procfs is mounted on the /proc directory.

What is this post about?

What we are going to do here is:

  • Implement a kernel module that creates, reads and writes /proc entries.
  • Using the echo command a PID will be written to the /proc entry. This PID is the one we want to get the backtrace.
  • Using the cat command the back trace will be read from the /proc entry.

Hands at work

First of all we need to create and initialize a proc entry, the proc_dir_entry structure is used for this purpose:

Once we declared our Proc_Parent_Process variable we also shall create a function to read from user-space and write to kernel-space (write data to an entry for this case) and other function to read from kernel-space (read data from an entry for this case) and write to user-space, so for this case we create the following callback functions:

Before we continue we have to notice a little detail here, even when we already declared the Proc_Parent_Process variable we have not crated the proc entry yet. To create the proc entry an to assign this one to the Proc_Parent_Process we use the create_proc_entry function:

Arguments Description
————— —————
name The name of the directory entry.
mode The permissions of the name directory.
parent If NULL, the entry will go in the /proc main directory,
in other case it could be used an already created
subdirectory of /proc or something created with
the proc_mkdir() function(what we won’t use at this moment).

OK, at this moment we have what we need to create a proc entry, of course we have to define our read and write functions but at least we can perform the creation and initialization of our proc entry into the init function:

In this case our entry is called parent_process.

Now lets see how to remove the proc entry once we do not need it more. To remove the proc entry we just need to use the remove_proc_entry function:

The arguments mean the same as they mean in the create_proc_entry function declaration. Lets see how our exit function looks:

Perfect! Now we just need to define our read and write functions to start playing around with the echo and cat commands :D
The definition of our functions is as follows:

Notice that besides Proc_Parent_Process we also shall declare and define the following variables:

OK, now lets see how to use this module.

In your terminal you can type the ps command to see a list of all processes and their PIDs running on the system, then choose anyone and write it to your proc entry.

$ ps -e

You can download this kernel module and the hello one together with their Makefiles and README files from HERE.

I hope someday it helps someone somewhere around the world.
Thanks! :D

Hacking a Stellaris Board – Part I

No Comments »

What is this hack about?

Basically what we are going to do here is:

  • Connect to the Stellaris board via ARM-USB-TINY and OpenOCD configuration files.
  • Dump an entire image of the flash.
  • Determine the size of the content into the flash.
  • Once we know the size of the content we also can see a big bunch of empty memory, choose a memory address among this bunch.
  • Implement a simple assembly program.
  • Flash this program into the board starting at the chosen memory address.
  • Force the Program Counter point to the memory address we have chosen.
  • Run our program without mess with the original application.

What do you need?

How to start?

First of all we need to:

The next step is configure OpenOCD to communicate with Stellaris board. I have written a couple of configuration files to bring OpenOCD support for Stellaris EKC-LM3S8962 Board. You can download these files from HERE.

To verify the configuration files are working right and we have communication with the Stellaris board run the openocd command into the directory where you uncompressed the files:

$ sudo openocd -f ekc-lm3s8962.cfg

You should see something like this:

Then open a new terminal and type:

$ arm-none-eabi-gdb

Then in the gdb promt (gdb) type:

(gdb) target remote localhost:3333

You should see something like this:

Now that we are connected to the board it is good to get information about the board memory, so for this case we use the command flash info <bank_id> you also can type the command help flash in order to see information about the available flash commands. The command flash banks will give you important information as well. So take a look at the log below and lets analyze it:

Put attention to the information given by the flash banks command:

#0 : stellaris at 0×00000000, size 0×00040000

It means there is only one bank of memory and its bank ID is 0 (thats the reason why we typed flash info 0), it starts at the address 0×00000000 and has a size of 0×00040000 bytes. Now if we do some trivial math we realize that we have a total of 256KB of flash memory.

Taking in account all this information we can dump the entire flash in order to get the whole image inside. Once we dump the flash we will discover which part of the flash memory is free to be used by our assembly program (of course once we implement our assembly program :p) without mess with the application in the image.

To dump the flash we use the command dump_image <filename> <address> <size>. The arguments of this command are the name for the binary file where the image will be stored, the starting address and the number of bytes that are going to be dumped starting from this address. In this case we type something like:

(gdb) monitor dump_image lm3s8962.bin 0×0 0×40000

Now it is time to start using the GHex editor. Once you have opened the image your GHex window will looks like the picture below.

At this moment we have learned how to use OpenOCD together with gdb in order to get information about the Stellaris memory status and dump an image. We have dumped the entire image from this board and now we are ready to analyze it using the GHex editor. Now we have finished the first part of this hack.

Wait for the second part and see you around! :D

How to install an ARM cross-compile environment on GNU/Linux

1 Comment »

An easy way to install an ARM cross-compile environment is downloading the Sourcery G++ Lite 2010q1-188 for ARM EABI TAR file, choose a directory and uncompress the file. Once you have uncompressed the file inside the directory go to your_directory/arm-2010q1/bin/ there you will find the tools you need to compile and debug ARM applications for your target.

Now we just need to update the PATH variable if we want to have access to these tools from anywhere.

To update the PATH variable follow the next steps:

Step 1.

Edit the /etc/profile file

  • $ sudo gedit /etc/profile
  • Look for the PATH variable and add :/your_directory/arm-2010q1/bin at the end of the line.

Note: Maybe you will find that this variable is commented out and the same for the export sentence:

#   PATH=”/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games”

# export PATH

In this case just copy and paste below both sentence without the #:

PATH=”/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/your_directory/arm-2010q1/bin

export PATH

Step 2.

Export your PATH

  • $ export PATH=$PATH:/your_directory/arm-2010q1/bin
  • Now type $ echo $PATH to verify your PATH has been updated. You should see something like this: /usr/local/bin:/usr/bin:/bin:/usr/games:/your_directory/arm-2010q1/bin

The purpose of the Step 1 is to set the PATH variable for the next time you log in to your system and the Step 2 is to updated the PATH for your actual session.

So just to verify that everything is OK for the actual session type (outside your_directory/arm-2010q1/bin/ ):

$ arm-none-eabi-gdb

You should see something like this:

Now you can work the rest of your session (but I recommend log out and log in again right now because the Step 2 only affect the console you are working with at this moment) and the next time you log in the change in the /etc/profile file will take effect forever. :D

How to install OpenOCD on GNU/Linux

2 Comments »

What is OpenOCD?

As you can read in the OpenOCD user’s guide the Open On-Chip Debugger aims to provide debugging, in-system programming and boundary-scan testing for embedded target devices.

OpenOCD installation for a virgin system:

$ sudo apt-get install libftdi-dev
$ sudo apt-get install libftdi1
$ sudo apt-get install libtool
$ sudo apt-get install git-core
$ sudo apt-get install autoconf
$ sudo apt-get install automake
$ sudo apt-get install texinfo

$ git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd OpenOCD

$ cd OpenOCD
OpenOCD $ ./bootstrap
OpenOCD $ ./configure –enable-maintainer-mode –enable-ft2232_libftdi
OpenOCD $ make $PARALLEL (if necessary reinstall texinfo and try again: sudo apt-get install texinfo)
OpenOCD $ make install