[Complete ReEdit3] further progress & shortening the text to fit the 30KB limit
First some input how I got here (for future readers trying to do the same for different format).
Image Data size
Comparing provided background image to its raw image size xs*ys reveal direct dependence Which implies no compression or one that has always the same pixel to ...
You must have been looking at the wrong representation.
Opening the file with a plain graphics viewer shows that it indeed contains "maps", in a 2-byte-per-block format and with a fixed width of 128 bytes/64 blocks:
The first 514 bytes seem to contain some other kind of data but after that every two bytes form one single map block. You'll have to compare ...
You asked this a couple of months ago, but I'm going to answer anyway.
First, I fear that your decompression code is buggy. There are several horizontal lines of noise, and I'm pretty sure they're not supposed to be there.
Your A+B=C guess was correct. A tell-tale sign are the visible horizontal edges but hidden vertical edges. I think your mistake was ...
It is encrypted with AES so you will need the keys from windows.plist to decode.
The format is (all stored in big-endian):
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)
I see filenames. That is an extremely important starting point - if I did not, I'd have to assume the file is encrypted, compressed, or does not use filenames at all, which are all harder to unpack.
For the moment, skip the header "BigFile" and the immedtaly following data and concentrate on these filenames alone.
If the filenames have different lengths, ...
Here is the complete answer to everyone who may encounter compressed GIM file of simular compression.
Basicly the file starts like this:
[magic number 10 00 00 00] [Integer with uncompressed size of file]
After this the compressed file begin.
The compression basicly functions like this: (in terms of decompression)
-> Take the next 2 bytes.
-> Is the second ...
Looks like these files use a variation of the delta compression format (MSDelta) used previously for the Windows Update packages.
I found a project which claims to decompress such files:
Supported file types
Header Sign: 0x44 0x43 0x4E 0x01, DCN 01 (packed IPD PA30)
The precise BPMs are actually in the data files (filename).DAT (may the overall BPM is in the edb.. but I can't confirm)
So I have reversed both data files created by RekordBox:
/numbers are all big endian/
[tag] - 4 byte string
4byte - tag header size
4byte - segment size (including tag header)
(in multibit fields, msb-to-lsb (left-...
I published some tools on github which can do just that: https://github.com/nlitsme/pyidbutil and https://github.com/nlitsme/idbutil.
The first is written in python, the second in C++, both have similar functionality.
pyidbutil provides the most low level recovery options: using --pagedump you can dump each page in the file without the need of an intact ...
It's certainly not a well known format. A quick glance at the file with a hex viewer shows that it mainly consists of records that all have similar, but not identical, size and layout; the very end of the file seems to be something different.
The first 2 Bytes - 047E - seem to be the number of records (1150).
Each of the records seems to start with 7 ...
This looks .. interesting.
When i open the first and second of your files in a hex editor, one has 20240 bytes, the other has 10240 bytes (all numbers in hex). So, 2^16+220 in one case, 2^17+220 in the other case.
Both files have data that "looks a certain way" in their first 240 bytes, then the data starts looking differently. Example:
To me, this smells ...
Binwalk produces multiple large files, because the zlib header does not contain any information about the size of the compressed data.
The following steps should be performed to extract the zip files:
Identify headers (found at 0x200 and 0x483BD)
Save the zip file to a file. But, because there is not any information in the header about the size, the worst ...
You can open any files in a hex editor. The way to think about this is that programs that read files are developed specifically to interpret the bytes in a certain way. The header in a file might contain specific data that only a specific program can understand and use.
There are also some files that are encrypted, and a program with a certain algorithm can ...
I've arrived at a solution by researching an answer for one of my Keychain subquestions.
According to SecItem.h, this kSecAttrIsExtractable has been introduced with OS X 10.6.
To determine where the faces/vertices are laid out purely via inspection can be pretty time consuming and hit-and-miss. Given the executable is available that processes these files, I think it's probably a better starting point - it definitively knows how to process the format.
I used IDA Pro to analyse the code in the executable that's involved in loading ...
COFF files were not designed to support relocation after link-time:
The binary format used initially for Linux was an a.out
variant. When introducing shared libraries certain design
decisions had to be made to work in the limitations of
a.out. The main accepted limitation was that no relocations are performed at the time of loading and afterward.
Without more information, as suggesting by the various comments, it's hard to be completely sure but, based on the information available, the format seems to be a very simple uncompressed vendor-specific 'raw' format with no specific identification or 'magic' numbers or tagged structure.
What follows is my best guess as to the format. Having a full file and ...
Full Disclosure is always appreciated. This seems to be a ("the"?) data file for FASA Studio's "Shadowrun". Anyway, the data file contains enough recognizable items to get a good start (PNGs, Unicode text). Data seems to be aligned on 16 bytes, padded with what seems to be random trash.
PNG images are a good start; you can extract them 'manually' (I used ...
Unfortunately, I cannot provide answer what to do when your database is already corrupted. That's the nature of proprietary binary databases: if you're hosed, you've got to keep all the pieces.
But I may suggest that you should foresee and be prepared to IDA database corruption, which is imminent and happens sooner or later to almost everyone. So:
if you reverse the byte order, and assume signed numbers you get these triplets:
-2468488 976475 146741
732616 976475 146741
732616 976475 -1238346
-2468488 976475 -1238346
-2468488 -142759 146742
732616 -142759 146742
732616 -142759 -1238346
-2468488 -142759 -1238346
these seem like the coordinates of the corners of a 3d cube
This seems very much like the IEEE754 format, and i'd assume each of your two byte timecodes to be preceded by two zero-bytes, which make a 4 byte (32 bit) value.
You can calculate the exponent using the formula
exponent=(byte2 * 2 - 127)
and the value in seconds using
assuming the high-order bit of byte1 is clear; if you ...
OK... it seems to be LZVN compression. Following on from Igor's suggestions I ran kextstat on my Mac, however that only listed:
Looking at the strings inside the 'dataless' compression it turned out to be type 5: ...
I can only definitely recognize code sections by looking if the
IMAGE_SCN_MEM_EXECUTE flag is set, as other sections should not have
this flag set.
The presence of this flag doesn't "definitely" mean that that section contains code, and the absence of this flag doesn't "definitely" mean that that section doesn't contain code:
A PE file can have that ...
You should really learn some assembler, and x86 processor architecture, to attempt this.
To give you a bit of a start:
The var_* declarations correspond to local variables on the stack of the current function. The number of bytes between variables give you a hint about the size of these variables. For example, you have a var_400, a var_800 and a var_804. ...
I'm not aware of any ready-made tools for such task, but I suspect in most cases the good old dd will do the task of replacing the actual bytes in the file (or maybe you can make objcopy work too). What can be more difficult is making the code work with the changed data. This depends on the nature of the data in question. For example:
When replacing (...
The file does not appear to be obfuscated or encrypted in any way. The header appears to be trivial. I have included a description of the header for the .zdata you posted. The .unity3d files contained within are the typical Unit3d webpack files. You can google around for a depacker for those, there are several.
it seems to be compressed in some way because you can read some plain text there
This statement is contradictory. If the binary were compressed or encrypted in its entirety there would not be any readable ASCII strings in a hexdump. Readable ASCII data indicates at the very least that there are regions within the binary that are not compressed or encrypted.
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:
uint32 signature; // 0xFA77FA77
uint32 data_start; // offset of the start of file's data
uint32 timestamp; // ...