Archive for the ‘Hacking’ Category

Useable Sec: Good interface design (3 Rules)

Good interface design is…
  1. Easy to recover from errors
  2. Minimal training needed for a person to use the system
  3. Relies on common interaction techniques for familiarity

Usable Sec: System Centered Design

Questions Asked in a System Centered Design Approach….

  • What can be built easily on this platform?
  • What can I create from the available tools?
  • What do I as a programmer find interesting to work on?

If you’re concerned with usability, then avoid this approach!

Usable Sec: User Centered Design

  •  User Centered Design is based upon a user’s
    • Abilities and real needs
    • Context
    • Work
    • Tasks
Golden rule of interface design: “Know The User”
Note: This and other “Usable Sec” notes are indirectly or directly from my U. Maryland “Usable Security” Coursera course

Rails: Add Authentication to Your Ruby on Rails Website in 4 Easy Steps

Step 1
In the terminal:

gem install Devise
bundle install
rails generate devise:install
rails generate devise user
rake db:migrate

Step 2
In seeds.rb:

user = User.create(email: '', password: 'password1', password_confirmation: 'password1')

Step 3
In the terminal:

rake db:seed

A route will be automatically created by the devise gem

Step 4

In _topnav.html.erb:
Add an if statement to check if the user is logged in:

if user_signed_in?



Continuing the reverse engineering and software development series on debugging, below I review the role of bits in debugging.

Bits 0-7 are the on/off switches of breakpoints.
Bits 8-15 are used for non-debugging purposes in DR7
Bits 16-31 determine the type and length of the breakpoint that is being set

Bits’ L and G fields are defined as followed:
L — local space
G — global space

 To Do: Add to this post or merge it with prior debugging posts

Breakpoints and other Debug Events

There are 3 major types of events you encounter when debugging:

  1. Breakpoints
  2. Memory violations (!!)
  3. Exceptions
buffer overflow, for example,  is probably the most well-known for of memory violation and is both a notorious headache for end-users of buggy software and a breath of fresh air for reverse engineers.
     There are 3 types of breakpoints of interest:
  1. Software Breakpoints
  2. Hardware Breakpoints
  3. Memory Breakpoints
Soft breakpoints are used specifically to halt the CPU and are the most common type of breakpoint. Soft breakpoints are sing-byte instructions that stop execution of the debugger process. In RStudio you can set a soft breakpoint simply by clicking on the left margin of a particular line or function (or by choosing “Rerun with Debugger” in the error traceback dialog). Soft breakpoints can be persistent if they remain after the CPU has executed its tasks or one-shot if they are cleared out. Soft breakpoints are associated with the interrupt 3 (INT3) event.

Using assembly language, to process a soft breakpoint the single byte instruction must be converted into an operation code (a.k.a. an opcode).

In x86 Assembly language an instruction looks like:
which tells the CPU to move the value stored in the EBX register to the EAX register. In native opcode, this would just be:
A common analogy is that x86 Assembly language is to individual opcodes what DNS is to IP addresses. Memorizing thousands of opcodes is impractical, whereas assembly language is much more manageable.

Hardware breakpoints, associated with the INT1 event, are useful when a small number of breakpoints are needed and the software can’t be modified. When registers are used in this way they’re known as debug registers.

Most CPU’s have 8 debug registers denoted as DR0 through DR7. Up to 4 of the 8 registers can be used for breakpoints and each can only set up to 4 bytes at a time. This means you can only use up to 4 hardware breakpoints at a time. DR0 to DR3 is usually reserved for the breakpoint addresses. DR4 and DR5 are reserved and DR6 is the status register (which determines the type of debugging event triggered by a breakpoint).
Unlike soft and hard breakpoints, memory breakpoints are not true breakpoints. Rather, a memory breakpoint refers to the permissions on a region or page of memory set by a debugger.
memory page is the smallest portion of memory that an OS deals with.
Examples of memory page permissions:
  1. Page execution
  2. Page read
  3. Page write
  4. Guard page
The guard page permission allows us to separate the heap and the stack and can ensure that a chunk of memory does not grow past a given boundary. It does so by  throw a one-time exception whenever accessed and then returning to its original status.

Introduction to the Stack

A fundamental concept in computer science is the stack. Ironically, as coding and scripting becomes more and more removed from the underlying basic software and hardware operations, fewer and fewer code authors have an understanding of concepts such as this… but if nothing else you must’ve wondered where the name StackOverflow comes from, right?

The stack stores information about how a function is called, the parameters it takes, and how it should return after it is finished executing.

Some important points to keep in mind:

  • The stack is a First In, Last Out (FILO) structure
  • Arguments are pushed onto the stack for a function call and popped off the stack when the function is finished
  • The stack grows from high memory addresses to low memory addresses


CPU Registers: an Overview

Register: a small amount of storage on the CPU; the fastest method for a CPU to access data

In the x86 instruction set, a CPU uses 8 general-purpose registers:
  1. EAX — a.k.a. the accumulator register, used for performing calculations as well as storing return values
  2. EDX — a.k.a. the data register, basically an extension of EAX
  3. ECX — a.k.a. the count register, used for looping, counts DOWNWARD not upward
  4. ESI  — a.k.a. the source index, used for reading, holds the location of the input data stream
  5. EDI  — a.k.a. the destination index, used for writing, points to the location where the result is stored
  6. EBP  — a.k.a. the base pointer, used for managing function calls and stack operations, points to the bottom of the stack unless freed up from this function by the compiler, in which case it would be an extra general purpose register
  7. ESP  — a.k.a. the stack pointer, used for managing function calls and stack operations, points to the very top of the stack
  8. EBX  — an extra register, not designed for anything specific

    Another register worth mentioning is:
  9. EIP — a.k.a. the instruction pointer, points to the current instruction that is being executed; as binary code is being executed by the CPU the EIP is updated to reflect the location where the execution is occurring

White & Black box Debuggers, Intelligent Debugging, and Dynamic Analysis

Debugging is a common task for data scientists, programmers, and security experts alike. In good ole RStudio we have a nice, simple built-in white-box debugger. For many analysis-oriented coders, the basic debugging functionality of an IDE like RStudio is all they know and it may be a surprise that debugging is a bigger, much sexier, topic. Below I define and describe key topics in debugging and dynamic analysis, as well as provide links to the most cutting edge free debuggers I use.

Dynamic Analysis: Runtime tracing of a process, usually performed using a debugger. Dynamic Analysis is critical for exploit development, fuzzer assistance, and malware inspection.

Debugger: a program that is used to test and troubleshoot other programs.Intelligent Debugger: a scriptable debugger that supports extended features such as call hooking, such as Immunity Debugger and PyDbg.

White Box Debugger: Debuggers built into IDEs and other dev platforms, which enable developers to trace through source code with a high degree of control, as to aide in the troubleshooting of functions and other code breakages.
Black Box Debugger: Used by bug hunters and reverse engineers, black box debuggers operate on compiled programs when the source code is not available and the only information is available in a disassembled format. There are two broad subclasses of black box debuggers, which are user mode (i.e. ring 3) and kernel mode (i.e. ring 0).
User mode black box debugger: a processor mode under which your applications run, usually with the least amount of privilege (e.g. double clicking PuTTY.exe launches a user-mode process).
Kernel mode black box debugger: a processor mode where the core of the OS runs using the highest amount of privilege (e.g. capturing packets with a network adapter that is in passive mode).
User-mode Debuggers Commonly used among Reverse Engineers
WinDbg by Microsoft
OllyDbg by Oleh Yuschuk, a F.O.S.S. debugger
GNU Debugger (gdb), a F.O.S.S. Linux debugger by the community

Linux: How to Install and Configure a Seedbox

#rTorrent for Transferring Free and Open Source files only!
mkdir ~/install
mkdir /var/www/files
mkdir /var/www/watch
mkdir /var/www/.temp
chown -R www-data:www-data /var/www
apt-get update
apt-get -y upgrade
apt-get -y install apache2 apache2-utils autoconf build-essential ca-certificates comerr-dev libapache2-mod-php5 libcloog-ppl-dev libcppunit-dev libcurl3 libcurl4-openssl-dev libncurses5-dev ncurses-base ncurses-term libterm-readline-gnu-perl libsigc++-2.0-dev libssl-dev libtool libxml2-dev ntp openssl patch libperl-dev php5 php5-cli php5-dev php5-fpm php5-curl php5-geoip php5-mcrypt php5-xmlrpc pkg-config python-scgi dtach ssl-cert subversion zlib1g-dev pkg-config unzip htop irssi curl cfv nano unrar-free mediainfo libapache2-mod-scgi
ln -s /etc/apache2/mods-available/scgi.load /etc/apache2/mods-enabled/scgi.load
cd ~/install
svn checkout xmlrpc-c
cd xmlrpc-c
./configure --disable-cplusplus
make install
cd ~/install
tar xvf libtorrent-0.13.2.tar.gz
cd libtorrent-0.13.2
make install
cd ~/install
tar xvf libtorrent-0.13.2.tar.gz
cd libtorrent-0.13.2
make install
nano ~/.rtorrent.rc
# Configuration file created for for single user rutorrent seedbox
# Maximum and minimum number of peers to connect to per torrent.
# min_peers = 25
max_peers = 100
# Same as above but for seeding completed torrents (-1 = same as downloading)
min_peers_seed = -1
max_peers_seed = -1
# Maximum number of simultanious uploads per torrent.
max_uploads = 100
# Global upload and download rate in KiB. "0" for unlimited.
download_rate = 0
upload_rate = 0
# Default directory to save the downloaded torrents.
directory = /var/www/files
# Default session directory. Make sure you don't run multiple instance
# of rtorrent using the same session directory. Perhaps using a
# relative path?
session = /var/www/.temp
# Watch a directory for new torrents, and stop those that have been
# deleted.
schedule = watch_directory,5,5,load_start=/var/www/watch/*.torrent
schedule = untied_directory,5,5,stop_untied=
# Close torrents when diskspace is low.
schedule = low_diskspace,5,60,close_low_diskspace=100M
# The ip address reported to the tracker.
#ip =
#ip =
# The ip address the listening socket and outgoing connections is
# bound to.
#bind =
#bind =
# Port range to use for listening.
port_range = 6890-6999
# Start opening ports at a random position within the port range.
#port_random = no
# Check hash for finished torrents. Might be usefull until the bug is
# fixed that causes lack of diskspace not to be properly reported.
#check_hash = no
# Set whetever the client should try to connect to UDP trackers.
#use_udp_trackers = yes
# Alternative calls to bind and ip that should handle dynamic ip's.
#schedule = ip_tick,0,1800,ip=rakshasa
#schedule = bind_tick,0,1800,bind=rakshasa
# Encryption options, set to none (default) or any combination of the following:
# allow_incoming, try_outgoing, require, require_RC4, enable_retry, prefer_plaintext
# The example value allows incoming encrypted connections, starts unencrypted
# outgoing connections but retries with encryption if they fail, preferring
# plaintext to RC4 encryption after the encrypted handshake
encryption = allow_incoming,enable_retry,prefer_plaintext
# Enable DHT support for trackerless torrents or when all trackers are down.
# May be set to "disable" (completely disable DHT), "off" (do not start DHT),
# "auto" (start and stop DHT as needed), or "on" (start DHT immediately).
# The default is "off". For DHT to work, a session directory must be defined.
dht = disable
# UDP port to use for DHT.
# dht_port = 6881
# Enable peer exchange (for torrents not marked private)
peer_exchange = no
# Do not modify the following parameters unless you know what you're doing.
# Hash read-ahead controls how many MB to request the kernel to read
# ahead. If the value is too low the disk may not be fully utilized,
# while if too high the kernel might not be able to keep the read
# pages in memory thus end up trashing.
#hash_read_ahead = 10
# Interval between attempts to check the hash, in milliseconds.
#hash_interval = 100
# Number of attempts to check the hash while using the mincore status,
# before forcing. Overworked systems might need lower values to get a
# decent hash checking rate.
#hash_max_tries = 10
scgi_port =
To test: 
cd ~/install
tar xvf rutorrent-3.5.tar.gz
mv rutorrent /var/www
tar xvf plugins-3.5.tar.gz
mv plugins /var/www/rutorrent
mv /var/www/rutorrent/* /var/www
chown -R www-data:www-data /var/www/rutorrent
#Set up authentication
nano /etc/apache2/sites-available/default
#paste this:
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
nano /var/www/.htaccess
#paste this:
AuthType Basic
AuthName "Protected Area"
AuthUserFile /var/passwd/.htpasswd
Require valid-user
#change permissions to enable www-data group
chown -R www-data:www-data /var/www/.htaccess
# create pw file using Apache's htpasswd util
mkdir /var/passwd
htpasswd -c /var/passwd/.htpasswd testuser
chown -R www-data:www-data /var/passwd
#run on boot
nano /etc/rc.local
# add this before ‘exit 0’:
screen -S rtorrent -d -m rtorrent