Shellcode crashing target PE - c

I am currently attempting to patch a target x86 PE file from the disk with a tool, patch.exe.
purpose
The purpose of this tool will be to eventually write/insert a multi-function payload into the target executable, who's purpose is to track the position of certain frames inside a game which I created.
background
I am doing this by mapping the file into memory with PAGE_READWRITE protection flag. After locating the RVA of foobar(...) function from memory, I am replacing the call to this function with a JMP (0xE9) instruction followed by the RVA of the payload shellcode (which is previously appended to a new section I have created within the target PE file beforehand).
When the shellcode simply contains the following bytes
unsigned char shellcode[16] = {0x33, 0xc0, 0xc3, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc}
which translates to the following C function
unsigned long basic_ret() { return 0; }
the target executable successfully executes
problem
however, if I try to include another function (0xDEADBEEF) within the code
unsigned char shellcode[32] =
{
0x6a, 0x0b, 0x68, 0x9c, 0xc2, 0xf4, 0x00, 0x6a, 0x0a, 0x68, 0xa8, 0xc2, 0xf4, 0x00, 0x68, 0xb4,
0xc2, 0xf4, 0x00, 0xb8, 0xef, 0xeb, 0xda, 0xed, 0xff, 0xd0, 0x83, 0xc4, 0x14, 0xc3, 0xcc, 0xcc
};
which translates to the following C function (a simple JMP taking 3 arguments on the stack, to another function)
int simple_jmp()
{
typedef int (*_jmp_target)(void*, int, void*);
_jmp_target jmp_target = (_jmp_target) 0xDEADBEEF;
return jmp_target (0, 5, 0);
}
where jmp_target is filled by patch.exe with the RVA to a function previously referred to, which was inserted into the new section of the target PE.
When the the target executable is executed, this time, it reaches some type of violation/crash (confirmed by the presence of WerFault.exe alongside its execution).
What is the reason for this problem, what am I missing?
diagnostics
When I observe the patched bytes in memory (of the mapped PE file), I can see that 0xdeadbeef is replaced by 0x0dc3f4de which is the same address from which the inserted function shellcode starts. At this point, I assumed there would be no crash, little to my surprise - crash!

Related

Why can't I have an HID descriptor for a gamepad with 17 buttons?

I currently have this HID report descriptor:
static
unsigned char hid_report_descriptor[] __attribute__ ((aligned(64))) = {
0x05, 0x01, // Usage Page (Generic Desktop Ctrls)
0x09, 0x05, // Usage (Game Pad)
0xA1, 0x01, // Collection (Application)
0xA1, 0x00, // Collection (Physical)
0x85, 0x01, // Report ID (1)
0x05, 0x09, // Usage Page (Button)
0x19, 0x01, // Usage Minimum (0x01)
0x29, 0x10, // Usage Maximum (0x10)
0x15, 0x00, // Logical Minimum (0)
0x25, 0x01, // Logical Maximum (1)
0x95, 0x10, // Report Count (16)
0x75, 0x01, // Report Size (1)
0x81, 0x02, // Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x05, 0x01, // Usage Page (Generic Desktop Ctrls)
0x09, 0x30, // Usage (X)
0x09, 0x31, // Usage (Y)
0x09, 0x32, // Usage (Z)
0x09, 0x33, // Usage (Rx)
0x15, 0x81, // Logical Minimum (-127)
0x25, 0x7F, // Logical Maximum (127)
0x75, 0x08, // Report Size (8)
0x95, 0x04, // Report Count (4)
0x81, 0x02, // Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0xC0, // End Collection
0xC0, // End Collection
};
It corresponds to this struct.
struct GamepadReport {
uint8_t report_id;
uint16_t buttons;
int8_t left_x;
int8_t left_y;
int8_t right_x;
int8_t right_y;
} __attribute__((packed));
I'm trying to add support for a single extra button that should serve as the "home" button (think of the X on an Xbox controller). This, in theory, should be done by changing the lines containing 0x29, 0x10 and 0x95, 0x10 to 0x29, 0x11 and 0x95, 0x11 respectively. However, doing so breaks the connection with the custom controller.
I cannot for the life of me figure out why this is and it makes absolutely zero sense to me. Can someone with more experience or knowledge about HID descriptors give me a hand?
In case anyone stumbles upon this or has a similar issue. You can't create a report count field on hid descriptors with numbers not divisible by 8 unless you add padding bits.
The solution was straightforward after reviewing the comments on my question and looking at similar issues online.
My gamepad report struct could only hold 16 bits. Even if I had a correctly defined hid descriptor, this would've prevented it from working. I changed my struct to the following.
struct GamepadReport {
uint8_t report_id;
uint32_t buttons;
int8_t left_x;
int8_t left_y;
int8_t right_x;
int8_t right_y;
} __attribute__((packed));
Modify your hid descriptor to contain the padding bits to the next number divisible by 8 that fits within your struct types. In this case, I need to fill 32 bits and I have 17 buttons. 32 - 17 means I need to add 15 padding bits.
0x75, 0xF, // Report Size (15) - PADDING BITS
0x95, 0x01, // Report Count (1)
0x81, 0x03, // Input (Const,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)

How to interpret this nfc ndef payload used in libfreefare example?

I am trying to write an encoded ndef message using libfreefare example code. Would like to know how to interpret the below hex codes. I have already gathered some knowledge about NDEF format but those are little unhelpful to translate the below mentioned NDEF hex message. I am just following the example program and trying to change default value with my one. What are the below codes represent ?
Refer : https://github.com/nfc-tools/libfreefare/blob/master/examples/mifare-classic-write-ndef.c
I have already tried converting the Hex values to ASCII using online converter. I can able to see the text content but I am curious to know about meaning of the hex values in between the text.
const uint8_t ndef_default_msg[33] = {
0xd1, 0x02, 0x1c, 0x53, 0x70, 0x91, 0x01, 0x09,
0x54, 0x02, 0x65, 0x6e, 0x4c, 0x69, 0x62, 0x6e,
0x66, 0x63, 0x51, 0x01, 0x0b, 0x55, 0x03, 0x6c,
0x69, 0x62, 0x6e, 0x66, 0x63, 0x2e, 0x6f, 0x72,
0x67
};
https://www.rapidtables.com/convert/number/ascii-hex-bin-dec-converter.html
I would like to construct a universal URI NDEF hex values for the below url.
scriptable:///run?scriptName=Clocking
0xD1, // MB/ME/CF/1/IL/TNF Type Name Format
0x01, // TYPE LENGTH
0x0A, // PAYLOAD LENTGH status(1)+language(2)+string(4)
'U', // TYPE (text) 'U' uri
0x02, // Status
// 'e', 'n', // Language
'g', 'o', 'o', 'l', 'e', '.','c','a'

how to print the s_uuid of ext2 superblock in C

I create a variable to store the value of superblock's s_uuid. But I get trouble into how to print this variable like xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx in this form. I tried to use printf in %x and %s to print my variable, but it doesn't work.
I want to know how the UUID stores in file system and how I can print it in console instead of wrong encoding.
The s_uuid is defined in the superblock as:
u8 s_uuid[16];
In order to print this to the console in the above format:
uint8_t s_uuid[16] = {0xf3, 0x58, 0x6b, 0xaf, 0xb5, 0xaa, 0x49, 0xb5,
0x8d, 0x6c, 0x05, 0x69, 0x28, 0x4c, 0x63, 0x9f};
printf("%02x%02x%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x\n",
s_uuid[0], s_uuid[1], s_uuid[2], s_uuid[3], s_uuid[4], s_uuid[5], s_uuid[6], s_uuid[7],
s_uuid[8], s_uuid[9], s_uuid[10], s_uuid[11], s_uuid[12], s_uuid[13], s_uuid[14], s_uuid[15]);

nettle twofish CBC

I had not problems with using nettle's twofish with standard ecb mode however i'm not sure what's wrong with this cbc mode? The decrypted message will not match the original. (using some hardcoded values like iv just for test purposes).
https://www.lysator.liu.se/~nisse/nettle/nettle.html
const uint8_t key[TWOFISH_KEY_SIZE] = {
0xea, 0xad, 0xdd, 0x6c, 0x32, 0x5a, 0xdc, 0x4f, 0x01, 0x5b, 0x4c,
0xde, 0xbb, 0x45, 0xc9, 0xe5, 0x5a, 0xb7, 0x5f, 0x3b, 0x01, 0x9a,
0xf8, 0x39, 0xd0, 0x74, 0x05, 0xeb, 0xf1, 0xaa, 0xa7, 0x67};
const uint8_t src[TWOFISH_BLOCK_SIZE] = {
0x3a, 0x53, 0xec, 0xae, 0xc0, 0xcf, 0xd3, 0xd8,
0xae, 0x05, 0x5d, 0xc0, 0x07, 0x3c, 0x04, 0x0d};
const uint8_t iv[TWOFISH_BLOCK_SIZE] = {
0xa0, 0xfb, 0x59, 0x3d, 0x70, 0x98, 0xdf, 0x8f,
0xff, 0xa0, 0x3b, 0xd5, 0xc5, 0x8b, 0x2c, 0x45};
uint8_t encrypted[TWOFISH_BLOCK_SIZE];
uint8_t decrypted[TWOFISH_BLOCK_SIZE];
struct CBC_CTX(struct twofish_ctx, TWOFISH_BLOCK_SIZE) ctx;
twofish256_set_key(&ctx.ctx, key);
CBC_SET_IV(&ctx, iv);
CBC_ENCRYPT(&ctx, twofish_encrypt, TWOFISH_BLOCK_SIZE, encrypted, src);
CBC_DECRYPT(&ctx, twofish_decrypt, TWOFISH_BLOCK_SIZE, decrypted,
encrypted);
for(int i = 0; i < TWOFISH_BLOCK_SIZE; i++) {
printf("\n%hhX\n", src[i]);
printf("%hhX\n", encrypted[i]);
printf("%hhX\n-------------------", decrypted[i]);
}
James is right: you need to set the IV again before decryption. From the Nettle documentation:
The final ciphertext block processed is copied into iv before returning, so that large message be processed be a sequence of calls to cbc_encrypt.
I.e. the IV inside the crypto context is lost and replaced by the last block of ciphertext. Hence you need to set it to the correct value again.
Nettle is a low level library, so this construct makes sense; higher level libraries may use streaming or assume that you always provide the complete plaintext/ciphertext in the call.

zLib inflate() hangs while uncompressing buffer

I use zLib 1.2.7, taken from here. I have compiled it in Microsoft Visual Studio 2010 as a static library and added it to my project.
I need to decompress some binary data compressed with deflate algorithm. Here it is:
unsigned char rawData[114] =
{
0x00, 0x00, 0x00, 0x00, 0x15, 0x82, 0x05, 0x9D, 0x62, 0x91, 0x9A, 0x86, 0x26, 0xF3, 0x45, 0xBF,
0xE1, 0x69, 0x19, 0xA8, 0x80, 0x21, 0x08, 0x43, 0xF1, 0xEF, 0xCC, 0x01, 0x68, 0x4E, 0x3C, 0x06,
0x59, 0x6D, 0x90, 0xB2, 0x1F, 0xC3, 0x87, 0xC2, 0xBF, 0xC0, 0x90, 0xBE, 0x1F, 0x11, 0xB6, 0xD7,
0xB7, 0x06, 0x18, 0x32, 0x5F, 0x80, 0x8F, 0x09, 0xF1, 0x81, 0xF2, 0xB8, 0xC8, 0x9E, 0x71, 0xB7,
0xC9, 0x73, 0x7E, 0x88, 0x02, 0xD0, 0x9C, 0x65, 0xB0, 0x34, 0xD3, 0x97, 0x33, 0xE8, 0x80, 0x2D,
0x09, 0xC6, 0x5B, 0x03, 0x4D, 0x39, 0x73, 0x74, 0x1B, 0xAD, 0x19, 0x9D, 0xF0, 0xCA, 0x6F, 0xBD,
0xA4, 0xD5, 0x33, 0x6E, 0xDF, 0x1F, 0x11, 0x8A, 0xC5, 0xA2, 0x1C, 0x99, 0xE2, 0xDB, 0xBF, 0x7C,
0x0E, 0x8B
};
This block of data was captured from SPDY session. And this is my uncompress code (SPDY_dictionary_txt can be found on previous link):
INT APIENTRY WinMain( __in HINSTANCE hInstance, __in_opt HINSTANCE hPrevInstance, __in LPSTR lpCmdLine, __in int nShowCmd )
{
z_stream zStream = { 0 };
DWORD Length = sizeof(rawData);
zStream.zalloc = Z_NULL;
zStream.zfree = Z_NULL;
zStream.opaque = Z_NULL;
inflateInit(&zStream);
zStream.avail_in = Length;
zStream.next_in = rawData;
DWORD dwUsed = 0;
DWORD dwSize = 5 * 1024;
LPBYTE lpDecompressed = NULL;
BOOL triedDictionary = FALSE;
BOOL uncompressed = TRUE;
lpDecompressed = (LPBYTE)calloc(dwSize, 1);
do
{
zStream.next_out = (LPBYTE)((DWORD_PTR)lpDecompressed + dwUsed);
zStream.avail_out = dwSize - dwUsed;
int zlib_rv = inflate(&zStream, Z_NO_FLUSH); // <-- THIS HANGS!
if (zlib_rv == Z_NEED_DICT)
{
if (triedDictionary)
{
uncompressed = FALSE;
break;
}
triedDictionary = TRUE;
inflateSetDictionary(&zStream, SPDY_dictionary_txt, sizeof(SPDY_dictionary_txt));
}
if (zlib_rv < 0)
{
uncompressed = FALSE;
break;
}
dwUsed += dwSize - dwUsed - zStream.avail_out;
}
while (zStream.avail_in);
if(!uncompressed)
{
OutputDebugString("Could not decompress buffer.\n");
}
else
{
OutputDebugString("Buffer was decompressed.\n");
}
Sleep(1000);
return 0;
}
I started to debug this code and found out that it hangs on the first inflate() call. What is this? Is this a bug in zLib or maybe my code is wrong?
The code you downloaded is not the original zlib code. It was modified by someone to compile "without warnings and errors" and bugs may have been introduced in the process. You need to download the original and correct code from zlib.net. The code you downloaded has, for example, a commit on May 31, 2014 with the log message "Corrected infinite loop errors in inflate.c and infback.c". You should be more careful about downloading code from strangers.
Note that the data provided in the question is not the result of zlib compression, and would be immediately rejected by inflate() upon reading the first two bytes as not even being a zlib header. You must be using some other input data to get your code to "hang". You need to provide the actual data that caused the issue in order for anyone to be able to help you.
About your code: you do not need to update next_out and avail_out inside the loop as you are doing, since inflate() already does that. You can compute dwUsed when the loop exits as dwSize - zStream.avail_out. You also need to check the return code from inflate() to make sure that it returns Z_STREAM_END when done, otherwise the stream was not complete. You should not abort on Z_BUF_ERROR, but rather provide more output space or more input. See this example for how inflate() and deflate() are used, and read the documentation in zlib.h.

Resources