Diffie-Hellman key exchange (sometimes Diffie-Hellman-Merkel, often abbreviated as D-H) allows two parties to derive a shared secret key over an insecure channel. This means that if Alice and Bob are strangers on the internet and they want to create a secure, encrypted channel for communication, they can do so even if an attacker, Eve, is listening to all of their communications. The complete source code for this post is available on github. Continue reading “Diffie-Hellman Tutorial with Python” »
Shared object files contain a library of functions that can be used by an executable. When functions are copied from a library into an executable at compile time, source object is called a “static” library. When functions from a library file are linked into an executable at runtime (dynamically), the library is called a shared object because a single dynamic library can be loaded into memory and shared between several executables. In Linux, static libraries are usually given the “.o” extension and shared object files are designated by the “.so” extension. Linux’s shared object files are analogous to Windows DLL files (short for “dynamically linked library”).
You aren’t even using your Caps Lock key, and if you are, you shouldn’t be. If you’re like me and you write a lot of code, especially in Emacs, you probably hit your Control key much more than Caps Lock. Since CapsLk is occupying some of the best real estate on the keyboard, right next to the home row, you might be better off swapping your left Control key with Caps Lock.
I swapped my left Control and Caps Lock keys after switching from Vi to Emacs, and it makes a lot of sense for me. A few days afte I switched to Emacs, my pinky started hurting because I was reaching for the Control key so often, and I worried that I was developing Emacs Pinky (See also: Celebrity Programmers with Repetitive Stress Injuries). Swapping Caps and Ctrl helped. Continue reading “Make your Caps Lock key another Control key in Linux” »
Eclipse Juno and the latest Android SDK provide better platform integration and a bunch of new features that make Android development much smoother and more fun. The process of installing Juno and the Android SDK on [X]ubuntu is similar to installing the previous version of Eclipse and Android (steps and illustrations here) with a few small tweaks.
Update: A few people have had problems accessing installed packages after running Eclipse as root. Don’t run Eclipse as root when you’re installing packages. You shouldn’t run programs as root under most circumstances, really.
This is an abbreviated version of the previous guide, geared toward installing Eclipse Juno and the Android SDK r20 instead of Eclipse Indigo and Android r18. It assumes you have the Java SDK installed already. If you don’t have Java yet, consult the previous guide first.
RC4 is the most popular stream cipher. It’s popular because it’s fast, and it’s fast because it’s simple. There are other, newer ciphers that outperform RC4 in different ways, but RC4 is still the most widespread stream cipher.
Looking at the optimized C or assembly source code for RC4 can be a little disorienting, but the algorithm’s operation is simple: Given a key, RC4 creates a pseudo-random keystream that can be used to encrypt data. The rc4.c source code below clearly illustrates each step in the algorithm, and rc4demo.c provides an animation of RC4′s individual steps. Continue reading “RC4 Tutorial with Animation” »
The Android project provides a fancy, QEMU-based emulator for testing components in software without needing to flash anything to a physical device. The Android “goldfish” kernel is specifically designed to run on the Android emulator, which simulates an ARM-based mobile device.
http://source.android.com/ gives an overview of how to initialize your build environment and compile an Android kernel, but it leaves out some crucial, time-saving details. Continue reading “How to compile the Android Goldfish kernel (and test it in the Android emulator)” »
After building Android, typing emulator at the command line will cause the recently-built AVD to run in the build’s emulator. This happens seamlessly because the build process adds <ANDROID BASEDIR>/out/host/linux-x86/bin/emulator to the PATH. The build process also sets the ANDROID_PRODUCT_OUT environment variable, which points to the directory containing the disk images that comprise your new AVD.
After restarting the computer, emulator will no longer be in the path, and when you try to run <ANDROID BASEDIR>/out/host/linux-x86/bin/emulator, it produces the an error: Continue reading “Android’s envsetup.sh and the emulator AVD error” »
I ran into a few errors when I tried to compile Android on my Ubuntu 12.04 64-bit laptop. Here are my notes on fixing them and compiling successfully: Continue reading “How to Compile Android on Ubuntu (12.04)” »
Reverse TCP or “connect-back” shellcode connects to a predetermined host and presents a shell from the system where the code is running. If you didn’t already know that, or you don’t understand what that means, you’re in the wrong place. You should probably backtrack to the intro to 64-bit Linux shellcode tutorial or your local library before proceeding further.
The shellcode and its prototype each take the following steps:
- Run setreuid() so execve() can run with maximum privileges.
- Create a new socket file descriptor with socket().
- Populate the sockaddr_in data structure with the destination ip, port and connection type.
- Using the information from sockaddr_in, create a TCP connection with connect(). If the connection fails, exit.
- Designate the socket as the source and destination for stdin, stdout and stderr.
- When everything else is done, use execve() to execute /bin/sh. Continue reading “Roll your own 64-bit Linux reverse TCP shellcode” »
Writing shellcode isn’t fundamentally different from writing ordinary assembly. If you can get an assembly routine to run on a given architecture, it’s usually not difficult to convert it to runnable shellcode. In fact, before going through the motions presented in this tutorial, I had never written any shellcode. From a low-level programming perspective, I found the challenges and limitations presented by shellcoding to be interesting, so I gave it a shot.
Most of the shellcode on the internet right now is targeted toward 32-bit POSIX-compliant computers, and it will usually work on 64-bit systems without modification. This post outlines an efficient process for writing, testing and finalizing shellcode specifically targeted to 64-bit Linux systems. This process could serve as a template for porting shellcode between different architectures.
Writing 64-bit shellcode
- Exit shellcode (sys_exit)
- Testing shellcode with stub.c
- “Hello World!” shellcode
- Actual, shell-spawning shellcode