CTF:GitS-2013/Writeups/RTFM - Versionsgeschichte

Krisha am 18. Februar 2013 um 23:02 Uhr

2013-02-18T23:02:30Z

← Nächstältere Version		Version vom 18. Februar 2013, 23:02 Uhr
Zeile 6:		Zeile 6:
	We did some testing with different input data and figured out that the output file size can be less or more than the input data. For a one byte input we got either one or 1.5 bytes output. A repeating byte in the input from the readable characters was often compressed to less than the input size. A repeating 0x01 was always encoded to repeating 1.5 bytes. On 0x00 in the input the executable stopped its execution. Similiar things happened to bytes above 0x80. Actually here is the point to see that more common/used character(sequences) are encoded to less, which hints to a [http://en.wikipedia.org/wiki/Huffman_coding huffman] compression.		We did some testing with different input data and figured out that the output file size can be less or more than the input data. For a one byte input we got either one or 1.5 bytes output. A repeating byte in the input from the readable characters was often compressed to less than the input size. A repeating 0x01 was always encoded to repeating 1.5 bytes. On 0x00 in the input the executable stopped its execution. Similiar things happened to bytes above 0x80. Actually here is the point to see that more common/used character(sequences) are encoded to less, which hints to a [http://en.wikipedia.org/wiki/Huffman_coding huffman] compression.

	Anyway we thought it is easier to use a different approach instead of reversing the huffman code including the tables. So we wrote a small application using bruteforce. We put a new byte to the input and then compare if it matches more bits on the output than any other input byte. We use that in a recursive ~~functions~~ to make sure, that it will also follow repeating bytes that get mapped to the same length as the input ~~string~~ one byte before.		Anyway we thought it is easier to use a different approach instead of reversing the huffman code including the tables. So we wrote a small application using bruteforce. We put a new byte to the input and then compare if it matches more bits on the output than any other input byte. We use that in a recursive function to make sure, that it will also follow repeating bytes that get mapped to the same length as the input with one byte less before.

	Our none-error-tolerant code in not-best-coding-style:		Our none-error-tolerant code in not-best-coding-style:

Krisha am 18. Februar 2013 um 21:51 Uhr

2013-02-18T21:51:08Z

← Nächstältere Version		Version vom 18. Februar 2013, 21:51 Uhr
Zeile 4:		Zeile 4:
	First thing was to figure out that the executable was used to generate the data file. The data file included the header "RTFM", which we also found to be written to an allocated memory in the disassembly. Inside this function we also found the code that actually converts the data.		First thing was to figure out that the executable was used to generate the data file. The data file included the header "RTFM", which we also found to be written to an allocated memory in the disassembly. Inside this function we also found the code that actually converts the data.

	We did some testing with different input data, and figured out ~~the~~ the output file size can be less or more than the input data. For a one byte input we got either one or 1.5 bytes output. A repeating byte in the input from the readable ~~charset~~ was often compressed to less than input size. A repeating 0x01 was always encoded to repeating 1.5 bytes. On 0x00 in the input the executable stopped its execution. Similiar things happened to bytes above 0x80. Actually here is the point to see that more common/used character(sequences) are encoded to less, which hints to a [http://en.wikipedia.org/wiki/Huffman_coding huffman] compression.		We did some testing with different input data and figured out that the output file size can be less or more than the input data. For a one byte input we got either one or 1.5 bytes output. A repeating byte in the input from the readable characters was often compressed to less than the input size. A repeating 0x01 was always encoded to repeating 1.5 bytes. On 0x00 in the input the executable stopped its execution. Similiar things happened to bytes above 0x80. Actually here is the point to see that more common/used character(sequences) are encoded to less, which hints to a [http://en.wikipedia.org/wiki/Huffman_coding huffman] compression.

	Anyway we thought it is easier to use a different approach instead of reversing the huffman code including the tables. So we wrote a small application using bruteforce. We put a new byte to the input and then compare if it matches more bits on the output than any other input byte. We use that in a recursive functions to make sure, that it will also follow repeating bytes that get mapped to the same length as the input string one byte before.		Anyway we thought it is easier to use a different approach instead of reversing the huffman code including the tables. So we wrote a small application using bruteforce. We put a new byte to the input and then compare if it matches more bits on the output than any other input byte. We use that in a recursive functions to make sure, that it will also follow repeating bytes that get mapped to the same length as the input string one byte before.

Schinken am 18. Februar 2013 um 21:49 Uhr

2013-02-18T21:49:05Z

← Nächstältere Version		Version vom 18. Februar 2013, 21:49 Uhr
Zeile 1:		Zeile 1:
	{{DISPLAYTITLE:Ghost in the Shellcode: RTFM Writeup}}		{{DISPLAYTITLE:Ghost in the Shellcode: RTFM Writeup}}

	RTFM which usually stands for "Read the fucking manual" was used here for "Rich text for Morons". The challenge supplied an executable x86 ELF file and a data file.		RTFM which usually stands for "Read the fucking manual" was used here for "Rich text for Morons". The challenge supplied an executable x86 ELF file and a data file.

Schinken am 18. Februar 2013 um 21:48 Uhr

2013-02-18T21:48:57Z

← Nächstältere Version		Version vom 18. Februar 2013, 21:48 Uhr
Zeile 1:		Zeile 1:
	== Ghost in the Shellcode: RTFM Writeup ==		{{DISPLAYTITLE:Ghost in the Shellcode: RTFM Writeup}}

	RTFM which usually stands for "Read the fucking manual" was used here for "Rich text for Morons". The challenge supplied an executable x86 ELF file and a data file.		RTFM which usually stands for "Read the fucking manual" was used here for "Rich text for Morons". The challenge supplied an executable x86 ELF file and a data file.

Krisha: /* Ghost in the Shellcode: RTFM Writeup */

2013-02-18T21:48:23Z

Ghost in the Shellcode: RTFM Writeup

← Nächstältere Version		Version vom 18. Februar 2013, 21:48 Uhr
Zeile 2:		Zeile 2:
	RTFM which usually stands for "Read the fucking manual" was used here for "Rich text for Morons". The challenge supplied an executable x86 ELF file and a data file.		RTFM which usually stands for "Read the fucking manual" was used here for "Rich text for Morons". The challenge supplied an executable x86 ELF file and a data file.

	First thing was to figure out that the executable was used to generate the data file. The data file included the header "RTFM", which we also found to be written at an allocated memory in the disassembly. Inside this function we also found the code that actually converts the data.		First thing was to figure out that the executable was used to generate the data file. The data file included the header "RTFM", which we also found to be written to an allocated memory in the disassembly. Inside this function we also found the code that actually converts the data.

	We did some testing with different input data, and figured out the the output file size can be less or more than the input data. For a one byte input we got either one or 1.5 bytes output. A repeating byte in the input from the readable charset was often compressed to less than input size. A repeating 0x01 was always encoded to repeating 1.5 bytes. On 0x00 in the input the executable stopped its execution. Similiar things happened to bytes above 0x80. Actually here is the point to see that more common/used character(sequences) are encoded to less, which hints to a [http://en.wikipedia.org/wiki/Huffman_coding huffman] compression.		We did some testing with different input data, and figured out the the output file size can be less or more than the input data. For a one byte input we got either one or 1.5 bytes output. A repeating byte in the input from the readable charset was often compressed to less than input size. A repeating 0x01 was always encoded to repeating 1.5 bytes. On 0x00 in the input the executable stopped its execution. Similiar things happened to bytes above 0x80. Actually here is the point to see that more common/used character(sequences) are encoded to less, which hints to a [http://en.wikipedia.org/wiki/Huffman_coding huffman] compression.

Schinken: using syntax highlighter

2013-02-18T21:29:50Z

using syntax highlighter

← Nächstältere Version		Version vom 18. Februar 2013, 21:29 Uhr
Zeile 9:		Zeile 9:

	Our none-error-tolerant code in not-best-coding-style:		Our none-error-tolerant code in not-best-coding-style:
	<~~pre~~>		<syntaxhighlight lang="c" line enclose="div">
	#include <stdio.h>		#include <stdio.h>
	#include <unistd.h>		#include <unistd.h>
Zeile 114:		Zeile 114:
	}		}

	</~~pre~~>		</syntaxhighlight>

	During bruteforcing you see the current output. Excitement! The overhead of the "[http://en.wikipedia.org/wiki/Rich_Text_Format Rich Text Format]" was more annoying than ever before ;-) The key "Did I have Vari-good-code?" is again a nice wordplay.		During bruteforcing you see the current output. Excitement! The overhead of the "[http://en.wikipedia.org/wiki/Rich_Text_Format Rich Text Format]" was more annoying than ever before ;-) The key "Did I have Vari-good-code?" is again a nice wordplay.

Krisha am 18. Februar 2013 um 17:54 Uhr

2013-02-18T17:54:19Z

← Nächstältere Version		Version vom 18. Februar 2013, 17:54 Uhr
Zeile 90:		Zeile 90:
	if ( tmp > maxlen )		if ( tmp > maxlen )
	{		{
	/* if u don't ~~do that~~, it will converge to the output~~, but probably never~~ find it ~~(or~~ after centuries) */		/* if u don't set maxlen again, it will converge to the output and find
			it after centuries (might be more correct way todo it) */
	maxlen = tmp;		maxlen = tmp;
	data[data_len+1] = 0;		data[data_len+1] = 0;

Krisha: /* Ghost in the Shellcode: RTFM Writeup */ little cleanup

2013-02-18T17:45:02Z

Ghost in the Shellcode: RTFM Writeup: little cleanup

← Nächstältere Version		Version vom 18. Februar 2013, 17:45 Uhr
Zeile 79:		Zeile 79:
	{		{
	unsigned char c, d;		unsigned char c, d;

	unsigned int tmp = 0;		unsigned int tmp = 0;

	~~// char set[] = "123abcest";~~

	// if ( depth > 10 )		// if ( depth > 10 )
	// return;		// return;

	~~//for ( d = 0 /0x20/; d < /0x80/ sizeof ( set )-1; d++ )~~
	for ( c = 1; c < 0x80; c++ )		for ( c = 1; c < 0x80; c++ )
	{		{
	~~//c = set[d];~~
	data[data_len] = c;		data[data_len] = c;
	tmp = compare ( data, data_len+1 );		tmp = compare ( data, data_len+1 );
Zeile 98:		Zeile 92:
	/* if u don't do that, it will converge to the output, but probably never find it (or after centuries) */		/* if u don't do that, it will converge to the output, but probably never find it (or after centuries) */
	maxlen = tmp;		maxlen = tmp;

	~~//if ( tmp > maxlen+3 && depth > 0 )~~
	~~// depth--;~~

	data[data_len+1] = 0;		data[data_len+1] = 0;

Krisha: /* Ghost in the Shellcode: RTFM Writeup */ typo

2013-02-18T17:43:27Z

Ghost in the Shellcode: RTFM Writeup: typo

← Nächstältere Version		Version vom 18. Februar 2013, 17:43 Uhr
Zeile 1:		Zeile 1:
	== Ghost in the Shellcode: RTFM Writeup ==		== Ghost in the Shellcode: RTFM Writeup ==
	RTFM which usually stands for "Read the fucking manual" was used here for "Rich text for Morons". The challenge supplied a executable x86 ELF file and a data file.		RTFM which usually stands for "Read the fucking manual" was used here for "Rich text for Morons". The challenge supplied an executable x86 ELF file and a data file.

	First thing was to figure out that the executable was used to generate the data file. The data file included the header "RTFM", which we also found to be written at an allocated memory in the disassembly. Inside this function we also found the code that actually converts the data.		First thing was to figure out that the executable was used to generate the data file. The data file included the header "RTFM", which we also found to be written at an allocated memory in the disassembly. Inside this function we also found the code that actually converts the data.

Krisha: /* Ghost in the Shellcode: RTFM Writeup */ code added

2013-02-18T17:40:25Z

Ghost in the Shellcode: RTFM Writeup: code added

@@ Zeile 9: / Zeile 9: @@
 Our none-error-tolerant code in not-best-coding-style:
-...
+<pre>
 During bruteforcing you see the current output. Excitement! The overhead of the "[http://en.wikipedia.org/wiki/Rich_Text_Format Rich Text Format]" was more annoying than ever before ;-) The key "Did I have Vari-good-code?" is again a nice wordplay.