[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 ...
Hypothesis: the file is encrypted
1. Absence of Compression Signatures
The relevant compression formats that Binwalk detects are as follows: bzip2, lzop, lzip, lrzip, LZO, 7z, gzip, rzip, LZMA, zlib, and LZ4. Since running Binwalk against H201LV2.0_Cur_config.bin returns no results even though Binwalk normally will recognize any of these compression ...
Finding: NGA_FW_CURRENT.BIN is a compressed Videx microchip firmware image file.
There is conflicting background information given in the comments about the file alleged to be firmware in the question.
A gzip compressed data file called authorizer.tar.gz located at https://220.127.116.11:8443/CyberAuditWeb/services/nga/download/ under ...
The encryption for recent ZTE routers' config.bin is AES ECB (Electronic Code Book). The key is stored in the open in /bin/cspd next to string /cfg/db_backup_cfg.xml. The function responsible is CspDBInitPdtInterface, last snprintf call. The key is zero padded if short of 128 bits.
The key very much might be unique to ISP: yours H201L V2 is Renjx%2$CjM, ...
As you say it is an LZ77 style format, however I could not find a specific algorithm which it matches. The compressed data forms a number of blocks, each of which contain at least one of some data, or some back references.
Based on the code I've put together a listing of the data structure of the compressed data.
The format of each block is ...
After downloading ChessBase Reader and playing with ProcMon a bit to find the function that reads the archive and writes the data file, i loaded up the whole thing in IDA to analyze it. The data is Huffman-coded.
Each data block has the following structure. Note that Huffman compression works with bits, not bytes, so each size in the following table is in ...
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 ...
As @w4rex said, it definitely looks like base64. If you try to decode it like a regular base64 string, you end up with :
37 7a bc af 27 1c 00 03 d8 a0 33 34 30 78 00 00 7z..............
You recognize the '7z' magic of a 7zip file, and it's indeed a 30Ko archive containing a single file of 363Ko named 'default'. The file is password-protected though, ...
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 ...
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 don't know for sure but can think of two possibilities.
One is that it's simply a coding error and only the low half of the 32-bit register was initialized when the file was created. If that's the case, then simply zeroing those two bytes should result in a successful decompression using the standard tool.
The other is that it's a (proprietary) ...
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.
Here's a description of the .msh format on Adobe Photoshop CC 2019, at least of what I've been able to glean.
The format uses run-length encoding to encode the offset coordinates of the mesh cells and compress empty cells along the way.
The format is little endian. The header is 64 bytes. At 0x10 and 0x14 are the mesh width and height, 32-bit integers. At ...
The code isn't easy to read since one has to do that statically and it doesn't seem to respect a standard EABI.
So, instead of trying to fully reverse engineer the code, I tried to search for the used constants instead and saw if the code matches with something:
It turned out the algorithm is JCALG1.
I made a quick and very ugly PoC from a code found on ...
You can't. You don't know how the file is packed, the only thing you have is the unpacking code in the file. You could try running the file through an emulator like QEMU, so the unpacking takes place in the emulator, not in the "physical" computer. However, that still executes the code.
And you'll have the problem that you don't know when you reach the end ...
A good way to find compressed or encrypted parts in a binary is entropy investigation, as compressed and encrypted parts show a high degree of disorder (a value of 1 means maximum disorder). I can recommend the tool binwalk which produces a graphical output of the memory's entropy. The picture shows a binwalk output, as an example of such a static analysis ...
I was able to decode the images. Spektre did a great job detecting the files structure, and the debug view was really helpful in the process. I implemented the algorithm in JS, and the source code is available here: https://github.com/K-Adam/DrekDecoder
Each line starts with a flag byte. It tells the decoder how many pixels to write and which mode ...
I took a look at the empty template file that you provided. The file has a very high entropy which indicates that it's probably encrypted and not compressed.
The header in the file could be a lot of things, but it doesn't have any known magic bytes at the beginning and doesn't appear to belong to any commonly known file type.
Your best bet with getting ...
For my unpacking session I'm using x64dbg and I will unpack the executable in kkrunchy_023a2.zip.
Get to the entry point and enable trace record. Also bind the Trace into beyond trace record option to say Ctrl+/.
Next up, press G (for graph) and you should see the return blocks marked in red.
Put a breakpoint on both of them, run, step and you will notice ...
Recommendation: since the firmware is obfuscated, recover the bootloader
The firmware may be encoded, compressed, encrypted, or some combination of these. In order for the firmware image to be loaded into memory and execute, it must be deobfuscated. Since the bootloader is responsible for this, it is likely that deobfuscation of the binary file containing ...
It appears to be stored in byte-reversed order from what you gave with a standard 5-6-5 bit encoding and then scaled to a maximum of 255 for each.
R: 24 (0b11000) * 255/31 = 197 G: 6 (0b000110) * 255/63 = 24 B: 15 (0b01111) * 255/31 = 123
R: 30 (0b11110) * 255/31 = 247 G: 7 (0b000111) * 255/63 = 28 ...
First, I have to say several things don't quite add up in the decompilation, and I often find it easier to understand disassembly than decompilation
Let's start with the function doing most of the work - sub_3B25D0.
As this function is somewhat long and has a little bit of quote-unquote scary math in it, our first impression may be that this function does ...
All the credit for this this answer should go to the @NirIzr and @Avery3R.
Here is a python script that implements the xoring mentioned by these kind people:
data = "%EB%9Ff%C5%A4q%D0%D9%88%F2M%87%C9Z%92%A6%83%BC%3B%86%8B%2D%8B%EC" #quoted data as is
unquoted = urllib.unquote(data)
key = binascii.unhexlify("0C17DE222CC93743") #...
I've had look at your image file and, as the answer to your previous question said, the compression is something like LZSS.
Specifically, the compressed data begins with a flag byte. Each bit of this in turn (from bit 0 to bit 7) indicates that the next decompressed byte(s) are generated by -
(when the flag bit is 1) copying a single literal byte ...
If you read zlib source code alongside the DEFLATE Compressed Data Format Specification you can find where they come from.
The bits in those bytes represent the start and end of the compressed stream.
Specifically they come from 2 relevant places in the source code -
// line 978
send_bits(s, (STATIC_TREES<<1)+last, 3)...
Binwalk did not find the zlib blob because it is also encrypted. It uses the following code to decrypt the compressed data. The decryption uses a table stored in the stack, which is filled with generated values before the loop.
Thus, you have to reverse the decryption code or save the decompressed data from the memory.
For most packers out there:
The start of the decompression or decryption is pretty much the entry point (with a bit of anti-debugging mixed in, perhaps).
The end of the decompression or decryption can't be found generically with static analysis.