[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 ...
I've been dissecting the firmware for another type of embedded device for a while and thought I'd see if I could find anything out. After a few hours I figured it out! There is a hard way and an easy way that I found only after digging the hard way. This is a long post, but I hope it will help others in similar ventures.
A little Googling and I found ...
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 ...
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 ...
Piece of cake: this is ZIP-compatible compressed compiled Java. Any familiar sequences of bytes near the header?
FA CE AF 0E 10 00 10 00 78 9C AC DD ..
.. those first few bytes look like Java's magic ID CA FE BA BE, but Googling that sequence doesn't yield any results, and it might be a red herring anyway. Next up: 10 00 10 00, which can be about anything (...
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-...
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 ...
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)
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:
I couldn't get a comment to format right .. so forgive this being a new reply.
Here is the header format:
0x00 : 4 unknown, probably 2 16-byte words for a version or file ID
0x04 : 4 size of the data block containing file data
0x08 : 4 unknown
0x0C : 4 offset to the data ...
I managed to solve problem.
First file in directory is ZSP.bin. It doesn't matter if offset of this file is 16 or 32 bit because in both cases is 0. As I know where directory ends and first file after directory should be ZSP.bin.
Below there is last two lines of last directory entry and first line of which I suspected should be ZSP.bin.
00 00 00 00 00 00 ...
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 ...