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.

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. 

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.

Virtual Memory Layout for Linux

There was a time when I struggled to understand the virtual memory layout in Linux , details of Physical-to-virtual memory mapping ,paging etc. Unfortuantely there is not a single book available which explains these things with non-x86 Architecture in mind. 

Here I will try to explain a few of these things.

MMU-Less Systems

Important terms : PIC [ Position Independent Code]
MMU [ Memory Management Unit]

PIC : Position Independent Code
[*] execution is independent of the memory in which the code resides

[*] Used in Shared libraries and on systems without an MMU support [ and that is the reason we are discussing this here]

A MMU-less system has a single address space.
In a system with MMU support each program executes in its own virtual address space. MMU less system doesn not have this distinction of virtual address space and physical memory. Therefore all programs must execute in a single address space and should not depend on the address in memory where it resides. A single buggy program can also cause the whole system to go down!

Inspite of this obvious disadvantage MMU-less sytems ( a good example is uCLinux )are becoming more and more popular again due to the following advantages :-

[1]: MMU-Less cores are smaller

[2]: Cache has to be flushed after every context switch in a system with virtual memory which is not required for MMU-Less systems. This results in faster context switches. Most of the processors have virtually indexed cache. This would require the OS to flush the cache (and TLB ) whenever a context switch happens.However for a MMU-Less system contents of Cache and TLB are valid even after a context switch because the same address space is shared by all processes. [ Reference : Context Switching and IPC Performance Comparison between
uClinux and Linux on the ARM9 based Processor by Hyok-Sung Choi and Hee-Chul Yun]

[3]: with uCLibc the binaries are much smaller. [hence the name "micro" ]

fork( ) issue 

fork creates a new process ( child ) which is a exact copy process but with a different PID. The parent and child execute simultaneously. MMU maps the memory from the parent process to the child process and does a COW (Copy-on-Write)  to the child process.

This however is not possible in MMU-Less systems like uCLinux.

All is not lost as vfork ( ) comes to the rescue here. vfork halts the the parent process and allows the child process to execute. posix threads can also be used instead of fork as the they share the same memory space ( including the stack)