10
You got started well; plotting unknown data as pixels immediately showed you this is indeed graphic data, not compressed (at least the buttons aren't), and in a usable RGB order. I guess the missing RGB format was what held you back; now you know it, you can write a simple program to plot in color and show offsets and widths of the images. Armed with that ...
9
The first byte of the file is 0x47, which suggests that it's an MPEG transport stream.
I used 010 Editor to create the following template for the file to parse it as an array of Partial Transport Stream Packets:
typedef struct {
BYTE sync_byte <format=hex>;
WORD transport_error_indicator : 1;
WORD payload_unit_start_indicator : 1;
...
8
It is encrypted with AES so you will need the keys from windows.plist to decode.
The format is (all stored in big-endian):
offset value
0-3 magic ('NSCR' for PersistentUIRecord)
4-7 version (either '1000' or '0006')
8-11 NSWindowID (used to lookup 128-bit AES key stored in windows.plist)
12-15 record length (including from 0 to xxx)
16-xxx ...
7
The non-linearity is a clue that it's a floating-point encoding. If you are familiar with looking at floating point values in memory dumps, the most significant byte is often in the 0x3f-0x4f range, representing values from 3e-5 to 2e77 for doubles. In this case, it's little-endian.
e.g. 00 4C 99 57 38 E5 CC 42 - 21.07.2014 14:38:26 -> unpacks to -> ...
7
(I'll assume you're talking about the boot process using legacy BIOS as UEFI situation is different)
The boot manager is not a PE, or, rather, not just a PE. It starts with 16-bit realmode part. You can check it yourself by looking at the file.
0000000000: E9 D5 01 EB 04 90 00 00 │ 00 52 8B C3 0E 07 66 33
0000000010: DB BA 01 00 E8 34 00 E9 │ 51 01 2E 88 ...
7
It's a 64 bit floating point value.
See here: https://developer.apple.com/documentation/foundation/nsdate
Returns a TimeInterval which happens to be typealias TimeInterval = Double
Ref: https://developer.apple.com/documentation/foundation/timeinterval
As in the source above, the epoch here is seconds from Jan 1 2001. But it's stored as a float.
41 BB ...
6
libbfd is not a magic wand, it is in fact pretty limited (it's one of the reasons why GDB cannot debug files without a section table). In particular, objcopy won't add PHT entries for you, so you will have to extend or adjust the PHT manually. You can either do it manually with a hex editor or try using a library such as libelf (it gives you necessary ...
5
Adding sections to PE files is not always as simple as editing the sections table. Sometimes you'll have to handle several edge cases such as menifest, signatures and other potential end-of-file optional "extensions".
Although LordPE is a great tool, it isn't the best tool for this task. It is too low-level, and doesn't let you create a complete new section ...
5
No, the Windows loader doesn't care about the name of the .pdata section. It doesn't find the RUNTIME_FUNCTION structs based on the section name, but rather based on the content of NtHeader->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXCEPTION].
Furthermore, the RUNTIME_FUNCTION structs don't need to be in "a separate COFF section".
5
The gzip headers are valid, but the deflate compressed data format is violated almost immediately, within less than ten bytes in for all of the files.
For all of the example files provided, the first deflate block is a dynamic block which has an oversubscribed code lengths code. That means that a Huffman code required to decode the code lengths for that ...
4
There is no reliable resource which gives an answer to the concrete question if a order exists or not. The question is why would you expect a fixed order of fat_arch sections?
The kernel simply loads the Universal Binary at execution time, parses the fat_arch structure(s) and selects a matching architecture type. So in my understanding there is no need for ...
4
The problem being addressed here is commonly called the semantic gap.
If you stumble across any binary snippet like the one you posted, it's nearly impossible to deduce the way the value is meant to be interpreted, unless you find code interpreting this value in any way (e.g. a file loader using this value as an offset, ...).
The main problem is that you ...
4
Unless you are loading a mapped PE file in your vector, you have to convert all RVAs to file offsets.
The pseodocode looks something like this:
func rva2offset(pe, rva):
for section in pe.sections:
if rva >= section.rva and rva < section.rva + section.size:
return section.fileoffset + (rva - section.rva)
return nil
The ...
4
Although some clues on the file's origin could be useful, the format seems to be pretty simple so can be deduced from the sample. It is not a full-fledged filesystem but a simple archive/package.
First, the file's header:
struct Header
{
uint32 signature; // 0xFA77FA77
uint32 data_start; // offset of the start of file's data
uint32 timestamp; // ...
3
First, a couple of clarifications
The Import Address Table is a table that only consists of the imported function's addresses. Unlike the Import Table (which consists of IMAGE_IMPORT_DESCRIPTORs) that also details where to lookup those imports.
To reiterate: (this is slightly oversimplified) The Import Address Table is an array of the imported functions' ...
3
If you check winnt.h from the latest Windows 10 SDK you can find rest of the values there:
#define IMAGE_DEBUG_TYPE_UNKNOWN 0
#define IMAGE_DEBUG_TYPE_COFF 1
#define IMAGE_DEBUG_TYPE_CODEVIEW 2
#define IMAGE_DEBUG_TYPE_FPO 3
#define IMAGE_DEBUG_TYPE_MISC 4
#define IMAGE_DEBUG_TYPE_EXCEPTION 5
#...
3
This is not the pascal/delphi string format, as those are either constant 1 byte or 4 bytes long length fields.
It does have some resemblance to the ASN1 format, except ASN1 comes with an additional field denoting the type of the object.
Anyways, This looks like the Most significant bit of the first byte is not part of the length and has the special ...
3
Each of the eight fields in the record has a one-byte header.
In the header, high nybble 8 means unsigned and high nybble 9 means signed (or possibly the other way around, can't be sure); low nybble is then the number of bytes needed to encode the number (not counting the header byte), decremented by one.
If the high nybble of the header is 0, that's a ...
3
If you really want to understand every byte of the file, then, as Jason pointed out, you'll have to get the program that reads it and reverse engineer that.
Of course, this might be somewhere between hard and impossible, and very time-consuming as well. So the question is what you want to do. Extract a certain sprite from the file? Change the colors of some ...
answered Jan 27 '15 at 17:26
Guntram Blohm supports Monica
11.6k1 gold badge15 silver badges31 bronze badges
2
There are a couple of possiblities here.
One possibility is that the relocation table has been truncated, so you see only the first page of relocation items (the table is an array of items on a per-page basis).
Another possiblity is that the file doesn't support ASLR (perhaps intentionally, or perhaps it is assumed to not exist) so the relocation table isn'...
2
Your files aren't plain disk images, they are using the Encase File Format. Your repetitive bytes seem to be artifacts of that file format.
There's a newer specification of the file format as well, but it requires registration.
Autopsy probably recognizes the file format, so it removes the parts of the file that belong to the file format, not the sector ...
answered Mar 13 '15 at 18:54
Guntram Blohm supports Monica
11.6k1 gold badge15 silver badges31 bronze badges
2
The difference is that Windows 8 requires all regular structures (exports, imports, TLS, exception handlers, relocations... that is, everything described by Data Directory entries) to be located wholly inside a section. The only exception is the Bound Import Table, which is stored external to any section, to avoid "polluting" the contents, since the Bound ...
2
just one sample is never sufficient to answer a checksum query you need a bunch of samples to corelate and find patterns
so looking at the linked pdf it seems it is clear enough
skip the start and sum the data and extract the least two bytes
skip sum mask
x,x,x,x | y,y,... 0x000000ff = checksum
so the sample you posted would be
skip ...
2
You are actually asking multiple different questions here :
[Regarding static linking only a few functions of a library]
Are there any general reasons why this is not a good idea or impossible?
Well it could be possible if it's your code and you know what you are doing (basically making a new library that is a subpart of the first one), but ...
2
They are not inside the application, there should be somewhere on your machine and will be loaded at runtime. You can use Process Monitor to check from where they are loaded.
ILSpy should be able to go into those DLLs so if it can't it might be an indication that it can't find them.
2
This looks like the LEB128 encoding.
Essentially, this is a variable length encoding where the lowest 7 bits of each byte store part of the value and highest bit of each byte is set if it's not the last byte. The successive 7-bit values are stored in little-endian order.
For more details, and especially for how signed numbers are handled, see either ...
2
I am no expert in the matter but I would try:
see exported functions names
if mangling is present you can use it for compiler detection. Just make a list of exported function names and compare to known mangling schemes (for example from the table in linked wiki page)
examine linked DLL's
you can detect well known RTL's by the filenames.
Also you can try ...
2
Additional to PE detection tools (like PEiD, Detect it easy ,Etc) there is some especial code patterns for GCC and MSVC for example GCC use MOVinst instead of PUSH inst for pushing a value on stack.
2
Unfortunately the real life samples don’t always follow the nice and tidy specification; they only need to work on a specific implementation, not the ideal one described in the documentation.
Corkami gathers details about practical PE format features, for example:
If the Import Lookup Table is present, then it also determines the length of the Import ...
2
The first byte starts as 0E is then 0F and then 10.
This looks something like a sequential message id, not part of a checksum.
The second byte has a pattern to it too and, taking into account the message lengths, I'd interpret it as follows -
00 => request to controller
20 => acknowledgement from controller of the request
10 => response from ...
Only top voted, non community-wiki answers of a minimum length are eligible
