[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 ...
Looking at it in OllyDbg it looks like a heavy task. Looks like a custom database with encrypted and (custom?) compressed data. This or the like would usually be the case in such applications. A flat file with structured data is not part of this one.
Anyhow. As a starter:
A quick check after trying out some general compression tools like 7z or binwalk, (have ...
You can try Netzob tool. This is a tool dedicated to reverse engineering protocols.
You can download it here : http://www.netzob.org/
A great example w/ ZeroAccess C&C protocol : http://www.netzob.org/documentations/presentations/netzob_29C3_2012.pdf
You can also take a look at CANAPE : http://www.contextis.com/research/tools/canape/
The numbers in the third column do increase over time, which is a good start. Let's check the differences between numbers on consecutive lines, to see if the progression is linear:
import re, sys, time
lines = sys.stdin.readlines()
def parse(l): return time.mktime(map(int,l[0:6]) + *3), int(l, 16)
stamps = [parse(re.split('[\n.: ]...
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, ...
Your best bet is Hachoir-Subfile. You can pass a file stream to Hachior-Subfile, it will search for all known embedded files and display the location. Some known formats it will calculate the size of the file. This makes it easy to carve out the files using dd. A helpful description of Hachoir-Subfile was left by one of the developers a couple weeks back in ...
I can't give you a specific solution, though I can tell you a tool to make reverse engineering a protocol easier.
Scapy is a python packet manipulation tool. One of the problems you have is, that wireshark doesn't know those packets. With Scapy its very easy to build and dissect strange/own packets. This will definetly help when you start to reverse ...
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 ...
You can find some information about PDB on the blog of PDBParse's author:
This article is a good resource about PDB :
Other link on the subject :
From what I have recently gathered DxClient is designed as a client for DVR Netview technology. Just by looking at functionality of the DxClient, it is clear that it is more then just binary transfer of AVI formatted stream. I think, it is safe to assume, that rather proprietary transfer and control protocol is used. 2 frames that you provided is just not ...
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 (...
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 ...
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 ...
Any such functionality is dependent on the player or viewer used. I know of no image formats that require any kind of interaction from the viewer, but some video formats do (or, rather, did) use it.
In addition to Quicktime mentioned by 0xea, the Windows Media/ASF format allows embedding of script commands, and one of them is opening an URL:
0x73687371 is apparently a magic value used to indicate LZMA compression by some vendors.
I can't test it since I don't have the image but here's a blog post with some description and source code links which is supposed to handle it:
EDIT: after some struggle with the download site I was able to get the decrypted shsq ...
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 ...
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 ...
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.
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)