Here's a short stream
>>> import zlib
>>> from binascii import unhexlify
>>> idat = unhexlify(b'789c626001000000ffff030000060005')
>>> zlib.decompress(idat)
b'\x00\x04'
But what is the shortest stream using the DEFLATE algorithm that is legal?
78 5e 03 00 00 00 00 01 decompresses to zero bytes.
Related
in context of a protokoll I get messages in AMF Format.
The AMF Object Type "Number" is defined as
number-type = number-marker DOUBLE
The data following a Number type marker is always an 8 byte IEEE-754 double [...] in network byte order.
The following Examples are captured using Wireshark:
Hex: 40 00 00 00 00 00 00 00
Number: 2
Hex: 40 08 00 00 00 00 00 00
Number: 3
Hex: 3f f0 00 00 00 00 00 00
Number: 1
I tried to treat these as doube, long long and int64_t but none of these Types seems to use the correct order/format.
The implementation needs to be in C so I cant use any Librarys (The are none as it seems)
What would be the correct approach?
Likely your platform supports 8-byte IEEE-754 doubles but requires them to be in little-endian format. Your examples are in big-endian format. If you store them in an aligned array of unsigned characters from last to first and cast the pointer to a double *, you should get the right value.
I wrote a function that is responsible for moving to a binary file and editing its bytes
int replace(FILE *binaryFile, long offset, unsigned char *replaced, int length) {
if (binaryFile != NULL) {
for (int i = 0; i < length; i++) {
fseek(binaryFile, offset + i, SEEK_SET);
fwrite(&replaced[i], sizeof(*replaced), 1, binaryFile);
}
fclose(binaryFile);
return 0;
}
else return -1;
}
When I use this function, I encounter a strange problem
All data in the file is filled with NULL bytes
And only one of the addresses in the file changes
Example:
FILE* fp = fopen("target.bin", "wb");
replace(fp, 0x57d8b0, "\x1E\xFF\x2F\xE1", 4);
replace(fp, 0x57c770, "\x01\x00\xA0\xE3\x1E\xFF\x2F\xE1", 8);
Result:
0x57c770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...
0x57d8a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x57d8b0: 1e ff 2f e1
Correct result:
0x57c770: 01 00 A0 E3 1E FF 2F E1 ...
...
0x57d8a0: 9c c4 0a ea 70 d2 68 00 44 d4 68 00 10 d1 68 00
0x57d8b0: 1e ff 2f e1 18 b0 8d e2 02 8b 2d ed 18 d0 4d e2
Please help me to solve the function problem or other problems.
wb is not correct. It clobbers the file.
From here,
Mode
Meaning
Explanation
If already exists
If does not exist
"r"
read
Open a file for reading
read from start
failure to open
"w"
write
Create a file for writing
destroy contents
create new
"a"
append
Append to a file
write to end
create new
"r+"
read extended
Open a file for read/write
read from start
error
"w+"
write extended
Create a file for read/write
destroy contents
create new
"a+"
append extended
Open a file for read/write
write to end
create new
You want r+b.
Also, you close the file handle in replace, which is premature. This should be done outside of replace, after you're done with the handle.
As an aside, you shouldn't be doing a number of seeks and writes of length one equal to length; you should be doing one seek and one write of length length.
Is there a function in a C lib to print data packets similar to Wireshark format (position then byte by byte)
I looked up their code and they use trees which was too complex for my task. I could also write my own version from scratch but I don't wanna be reinventing the wheel, so I was wondering if there is some code written that I can utilize. Any suggestions of a lib that I can use?
*The data I have is in a buffer of unsigned ints.
0000 01 02 ff 45 a3 00 90 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 ... etc
Thanks!
I doubt such a specific function exists in the libC, but the system is rather simple:
for (unsigned k = 0; k < len; k++)
{
if (k % 0x10 == 0)
printf("\n%04x", k);
if (k % 0x4 == 0)
printf(" ");
printf(" %02x", buffer[k] & 0xff);
}
Replace the first modulo by the line length, and the second by the word length and you're good (of course, try to make one a multiple of the other)
EDIT:
As I just noticed you mentioned the data you have is in a buffer of unsigned ints, you will have to cast it to an unsigned char buffer for this part.
Of course, you can do it with an unsigned buffer with bitwise shifts and four prints per loop, but that really makes for cumbersome code where it isn't necessary
Through the IDA disassembler I've reached this address:
0010FD74 00 00 00 00 00 00 03 00 00 00 00 00 82 03 80 02
Now I need, given the address to get particular bytes; for example the 7th position where there is "03".
I've tried using C language to do this:
char *dummycharacter;
*dummycharacter = *(char*)0x10FD74;
Now if I try to access 7th value with this:
dummycharacter[6]
I don't get 0x03…where am I going wrong?
You're trying to assign the value dummycharacter points to (which is pretty much nowhere, since it's not initialized). Try dummycharacter = (char*)0x10FD74;.
I have a C header file like this:
#define NAME_LEN 8
#define DEV_MAX 4
typedef struct __device
{
int iDevID;
int iDevSN;
}DEVICE;
typedef struct __person
{
int iID;
char acName[NAME_LEN];
DEVICE aDevices[DEV_MAX];
}PERSON;
and a binary data file maybe like this:
0000000 01 00 08 00 4a 61 63 6b 00 00 00 00 0a 00 00 00
0000020 11 11 11 11 0b 00 00 00 22 22 22 22 0c 00 00 00
0000040 33 33 33 33 0d 00 00 00 44 44 44 44
All that what I need is to visulized data representation with field names using the C header file above....
It'll be better like this...
m--iID : 0x80001
m--acName : Jack
m--aDevices[]
|--aDevices[0]
|--|--iDevID : 0xa
|--|--iDevSN : 0x11111111
|--aDevices[1]
|--|--iDevID : 0xb
|--|--iDevSN : 0x22222222
|--aDevices[2]
|--|--iDevID : 0xc
|--|--iDevSN : 0x33333333
|--aDevices[3]
|--|--iDevID : 0xd
|--|--iDevSN : 0x44444444
or other structured data .. xml / python pickle / json strings / whatever
Of course, the header file which I faced is far more complicated, there will be a msgtype and a msglenth field in the data, so I can find out which is the correct structure and how long is it.
How badly do you need that?
A possible solution might be to make a GCC plugin or a MELT extension (MELT is a domain specific language to extend GCC), but to do that you'll need to understand in some details the internal representation of GCC (notably Tree, and perhaps Gimple), and that will take you some time (days, not hours).
If your declarations are simpler, perhaps consider using SWIG (or maybe the RPCXDR parser), but that supposes that you are able to change or simplify them.
If the binary format were identical to the memory layout of your structure, you could just cast it, no parsing required (with some caveats). However, that evidently isn't what you mean, since your hex dump and sample output don't match that interpretation.
You'll need to actually explain your format though: as described below, it isn't obvious.
You seem to have fixed-length 4-octet integers in little-endian order, OK.
If I assume variable length strings with a nul-terminator, 4a 61 63 6b 00 = acName:"Jack" and 0a 00 00 00 = iDevID:0x0a looks ok, but there is a 3-octet sequence between them I don't know the meaning of.
Or is Jack not nul-terminated, in which case it's fixed at 4 characters long and not the 8 you defined for NAME_LEN? That would make 00 6f 70 65 another 4-byte integer, but I still don't know what it means.
...