Tuesday, January 13, 2009

Minimal GIT guide

1. Create a new branch on the remote git repository

git push origin origin:refs/heads/

e.g git push origin origin:/refs/heads/nemesis-debug

creates a branch called nemesis-debug on the remote repository.

Confirm this by typing git branch -r. Your new respository should appear there.

2. create a local branch to track the newly created remote branch.

git checkout --track -b

e.g git checkout --track -b nemesis-debug origin/nemesis-debug

3. make all necessary changes.

4. commit your changes
a.add files/directories you want to commit
git add
git add .   # adds all the files in the directory recursively

b. commit
git commit -m "commit-message"

c. push all your changes to the repository

git push origin
e.g git push origin nemesis-debug


5. In case you screwed up and want to delete the remote branch 

git push origin :heads/
e.g git push origin :heads/nemesis-debug

Tuesday, January 6, 2009

Memory Optimizations: Kernel Programming

UNLIKE User-space code/data, kernel code/data reside PERMANENTLY in memory. They are NOT swapped Out.

>>> module_init : RUN Time Optimization. Executed when the associated module is loaded. If the module is statically included in the kernel, the kernel can free the module_init routine right at the boot time, after it runs.

>>> module_exit: LINK Time Optimization. It is never executed if the modules are statically included in the kernel. In such cases, it is not needed to include module_exit routines into the kernel image and are discarded at Link Time.


Monday, January 5, 2009

SSH: Logging without Passwords

Here is what to do :-

1. generate a public and private key pair.

ssh-keygen -t rsa -b 4096 -C "comment"

This would generate a 4096 bit long key using RSA encryption mechanism. You can choose to use DSA instead of RSA.

2. When prompted save the key to your home directory.
In my case it would be /home/nemesis/.ssh/id_rsa.pub

3. When prompted for a passphrase, just press enter. Press enter to confirm again. This means a blank password.

4. scp the above generated password file to the remote server.
e.g scp /home/nemesis/.ssh/id_rsa.pub nemesis@remote-server.org:/home/nemesis/

where remote-server.org is the remote machine that I want to login to without using passwords.

5. ON THE Remote machine now.

>Check to see if there is a .ssh folder. If it doesnt exist in your home directory, create it

mkdir -p /home/nemesis/.ssh

Now add your credentials to the authorized lists. Here is how to do it.

cat id_rsa.pub >> .ssh/authorized_keys

6.Logout

7. ssh nemesis@remote-server.org
Voila!!! You are in. No password required.

Tuesday, November 11, 2008

Remote Debugging Using gdbserver

There are many articles on Remote debugging using gdb-gdbserver setup. Sadly many of them are not comprehensive and some of them are even outright wrong.

I will try and explain the setup here :-

1. You need a gdbserver running on the target. This is target specific. E.g if you are compiling for a ARM target , make sure you have a gdbserver compiled for ARM.

2. A gdb debugger running on the host. This is where many of the tutorials on the net are not clear. The gdb running on the host has to debug programs built for the target architecture but still run on the host machine ( Just like gcc cross compiler).

3. The program to be debugged has to be the same --both on the target and the host. However you can run a stripped version of the program on the host. Apart from this they should be exactly the same.

steps:-

Get the iptables mess out of the way

#iptables -P INPUT ACCEPT
#iptables -P OUTPUT ACCEPT
#iptables -P FORWARD ACCEPT
#iptables --flush

on the board start the gdbserver
#gdbserver :1234 debug-program

here it means thats gdbserver would listen for connection on port 1234. The program which is to be debugged is "debug-program". The above command is same as using :-

#gdbserver localhost:1234 debug-program 
or even
#gdbserver 127.0.0.1:1234 debug-program



on the host start the gdb

#gdb debug-program

At the gdb prompt type the following

(gdb) target remote 192.168.1.1:1234 

This instructs the gdb to connect to gdbserver on the machine with IP 192.168.1.1 on port 1234. 


Monday, November 3, 2008

On-Target source Level Debugging Using NFS

Many a times we would like to have to have a luxury of source level debugging but do not have fancy tools like a JTAG/ICE. But thanks to NFS, we do have a solution. Using NFS one can mount the entire source directory ( or any other directory for that matter) on to the target and run a debuggger on the target.

Besides aiding source level debugging NFS can help save crucial development time by circumventing the need to flash the board for every little change. If only a small portion of the code changes, selectively compile that particular program and replace the existing program on the board with the newly built program. Copy-And-Paste instead of Flash-And-Burn!!!


1. Build the Kernel Image for the target with NFS support.

2. Install NFS server package on the host. On debian machines it is as simple as

sudo apt-get install nfs-kernel-server

3. A file called /etc/exports is created. Open this file for editing.

add the following line :-

/home/kernelexploit 192.168.1.1(rw,all_squash,anonuid=kernelexploit,anongid=1000,insecure,no_subtree_check)

where /home/kernelexploit is the path on the host. This will be mounted on the target. [192.168.1.1] is the IP address of the target in my system. Replace it with your board specific parameters.

4. On the target type the following command

mkdir -p /home/kernelexploit-target [ This is where the remote directory would be mapped]

mount -t nfs -o async,noatime,exec,rw,nfsvers=2,nolock 192.168.1.11:/home/kernelexploit /home/kernelexploit-target


Where, 192.168.1.11 is the IP address of the host machine and /home/kernelexploit is the path on the host. The trailing /home/kernelexploit-target is a directory we created on the target where the remote directory is mounted.