Related
#include <stdio.h>
#include <wchar.h>
#include <locale.h>
int main()
{ int i;
setlocale(LC_CTYPE,"de_DE.UTF-8");
wchar_t cA[256] = {
0xC498, 0xC4AE, 0xC5B2, 0xC482, 0xC496, 0xC48E, 0xC898, 0xC89A, 0xC48A, 0xC4A0, 0xC4B9, 0xC5BB, 0xC7B8, 0xC485, 0xC499, 0xCAF,
0xC5B3, 0xC483, 0xC497, 0xC48F, 0xC899, 0xC89B, 0xC48B, 0xC587, 0xC49A, 0xC4A1, 0xC4BA, 0xC5BC, 0x20, 0x21, 0x22, 0x23,
0xC582, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2A, 0x2B, 0x2C, 0x2D, 0x2E, 0x2F, 0x30, 0x31, 0x32, 0x33,
0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3A, 0x3B, 0x3C, 0X3D, 0x3E, 0x3F, 0x40, 0x41, 0x42, 0x43,
0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4A, 0x4B, 0x4C, 0x4D, 0x4E, 0x4F, 0x50, 0x51, 0x52, 0x53,
0x54, 0x55, 0x56, 0x57, 0x58, 0x59, 0x5A, 0x5B, 0xE1B5BE, 0x5D, 0xC581, 0x5F, 0xC484, 0x61, 0x62, 0x63,
0x64, 0x65, 0x66, 0x67, 0x68, 0x69, 0x6A, 0x6B, 0x6C, 0x6D, 0x6E, 0x6F, 0x70, 0x71, 0x72, 0x73,
0x74, 0x75, 0x76, 0x77, 0x78, 0x79, 0x7A, 0xC2AB, 0xC5AF, 0xC2BB, 0x013D, 0XC4A6,0xC3A1, 0xC3A0, 0xC3A9, 0xC3A8, 0xC3AD, 0xC3AC, 0xC3B3, 0xC3B2, 0xC3BA, 0xC3B9, 0xC391, 0xC387, 0xC59E, 0xC39F, 0xC2A1, 0xC5B8,
0xC3A2, 0xC3A4, 0xC3AA, 0xC3AB, 0xC3AE, 0xC3AF, 0xC3B4, 0xC3B6, 0xC3BB, 0xC3BC, 0xC3B1, 0xC3A7, 0xC59F, 0xC49F, 0xC4B1, 0xC3BF,
0xC4B6, 0xC585, 0xC2A9, 0xC4A2, 0xC49E, 0xC49B, 0xC588, 0xC591, 0xC590, 0xE282AC, 0xC2A3, 0x24, 0xC480, 0xC492, 0xC4AB, 0XC5AA,
0xC4B7, 0xC2B9, 0xC4BB, 0xC4A3, 0xC4BC, 0xC4B0, 0xC584, 0xC5B1, 0xC5B0, 0xC2BF, 0xC4BE, 0xC2B0, 0xC481, 0xC493, 0xC4AB, 0xC5AB,
0xC381, 0xC380, 0xC389, 0xC388, 0xC38D, 0xC38C, 0xC393, 0xC392, 0xC39A, 0xC399, 0xC598, 0xC48C, 0xC5A0, 0xC5BD, 0xC390, 0xC4BF,
0xC382, 0xC384, 0xC38A, 0xC38B, 0xC38E, 0xC38F, 0xC394, 0xC396, 0xC39B, 0xC39C, 0xC599, 0xC48D, 0xC5A1, 0xC5BE, 0xC491, 0xC580,
0xC383, 0xC385, 0xC386, 0xC592, 0xC5B7, 0xC39D, 0xC395, 0xC398, 0xC39E, 0xC58A, 0xC594, 0xC486, 0xC59A, 0xC5B9, 0xC5A6, 0xC3B0,
0xC3A3, 0xC3A5, 0xC3A6, 0xC593, 0xC5B5, 0xC3BD, 0xC3B5, 0xC3B8, 0xC3BE, 0xC58B, 0xC595, 0xC487, 0xC59B, 0xC5BA, 0xC5A7, 0xC4A7,
};
for( i=0;i<252;i++){
wprintf(L"%lc\n", (unsigned char)cA[i]);
}
return 0;
}
I have tried by writing setlocale, but even though it is showing different symbols.I need it to print the correct symbols. Eg. for 0xC498 it is printing ÿ instead of Ę.
In the function wprintf, you are typecasting the wchar_t
(equivalent to uint16_t) to unsigned char (equivalent to
uint8_t). Hence, you are losing half of the information every time
you are printing something.
I think you have an incorrect set of uni-code for the Latin characters. Please follow the chart https://en.wikipedia.org/wiki/Latin_script_in_Unicode and try again.
Meanwhile, wprintf(L"%lc\n", (wchar_t)0x0118); will give you the character you are looking for.
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!
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'
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.
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.