Bad Character

Bad character usually can cause a variety of effects on the exploits we sent. Sometimes making a function to be failing, or activities that are not expected, even derail the process of exploitation, such as is happening on BigAnt SEH exploit case.

After we generate payload with defined bad character that are 0x00 0x0a and 0x0d, we found the code like this,

 the result on SEH handler view,

this view is unexpected result, because the result should be 

To find out which characters are included in the bad character, requires trial and error process. The method that will be used is, by trying to send a data packet payload dummies into the memory, then studied at the byte which has an error reading SEH address. Dummies character that is sent in the form of opcode from \x01 to \xFF, which represents all the opcode on the processor. To make easier we can use generatecodes.pl script

Here are the script :

#!/usr/bin/perl
# generatecodes.pl
# Version 0.1

use Getopt::Long;

GetOptions('help' => \$help);

if ($help) {&help; }

if ($ARGV[0]) {
 @knownbad = split ',', $ARGV[0];
 foreach $bad (@knownbad) {
  $bad = hex($bad);
 }
}

if (! $ARGV[1]) {
 $split = 15; # split at 15 characters if not told otherwise
} else {
 $split = $ARGV[1];
}

$count=0;
for ($a = 0; $a <= 255; $a++) {
 $match = 0;
 foreach $knownbad (@knownbad) {
  if ($knownbad eq $a) {$match = 1} 
 }
 if (! $match) { 
  if (! $count) {print chr(34); }
  print '\x' . sprintf("%02x", $a); 
  $count++;
 }
 
 if ( (int($count/$split) eq $count/$split ) && ($count)) {print chr(34) . "\n"; $count = 0; }
}

if ( (int($count/$split) ne $count/$split ) && ($count)) {print chr(34) . "\n";}


sub help{
 print "This script generates a c style buffer of all characters from 0 to 255, except those specified in a comma seperated list provided as parameter one.  Used to generate a list of characters to enter into a exploit to test for bad characters. \n\n" .
 "Parameter one is optional and should contain comma separated hexadecimal bytes in the format 00,0a,0d and any characters provided will not be listed in the output.\n\n" .
 "Parameter two is also optional and specifies the interval at which new lines are interspersed in the output.  If not specified the default is a new line every 15 characters.\n\n";
 exit;
}

  

Then run the script,

After this, the next step was to enter the script into the fuzzer, but this time, the script inserted line-by line. The purpose inserted the script as per line is to know what character (from \ x00 to \ xFF) that can make the memory system becomes chaos.

 The result is direct into vbajet32.dll, it means there are no bad character in the first line. Then we try 2nd line...

"\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f\x20"

 and the result is the address back again to 90909090, it means there are at least 1 bad character on the 2nd line. We can search again by split the line into 2 section and test again the fuzzer until we know the bad character. OK...after more than 10 times try fuzzing and checking per-line, we can look at the result below :

So from the manually way put the dummies line per line and test it on our fuzzer..we can make conclusion that bad character on this case are 0x00, 0x0a, 0x0d, 0x20.