[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 figured it out! Some of the comments on this web site made me go back and think harder - actually to think differently.
I thought that I should post the analysis that I did on these messages to try to determine the CRC algorighm.
My analysis is based on a paper written by Greg Ewing http://www.cosc.canterbury.ac.nz/greg.ewing/essays/CRC-Reverse-...
There's a lot to Google on the topic, so take some time to do that and learn about what the *.dcr format is. A great initial point of reference for you is this post on the ZenHAX forum, where a script or two have been created for use with their program, QuickBMS. That won't teach you how to reverse the format, but if you spend some time reading what QuickBMS ...
I hope you'll find your experience in RE.SE enjoyable and educating :)
Reverse engineering is often studied as a hobby, so you're in good company!
IDA pro is a disassembler, which is focused on reverse engineering / reading assembly/machine code. that is - the code actually executed by the CPU. Since it appears you were only given a format file, without ...
Consider a "gap" to be a "low" interval between two consecutive "high" interval, ignoring the first longest one. Then, a bit 1 corresponds to a long gap, and a bit 0 corresponds to a short gap.
Therefore, the messages decoded that way are:
88 14 4b 00 ee : Light
84 14 4b 00 de : Beep
81 14 4b 00 7e : Zap
82 14 4b ...
From my experience, file extensions are rarely meaningful.
To really understand what format you are playing with, I suggest you to try the linux file command on this file. It will (maybe) give you more insight on what you are working with.
I never did picoCTF but I bet the .dd refers to a raw disk image.
Now I have only a few experience in Forensics (yes I ...
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'm not sure what the 'louie' files are for, but this python script should help reconstruct the images:
# simple scale from [0,0x1f] to [0,0xff]
val = (n<<8)|n
return [scale_up((val>>0)&0x1f), scale_up((val>>5)&0x1f), scale_up((val>>10)&0x1f)]...
You've correctly identified the first four bytes as the header or matrix shape.
If you were to remove those shape bytes and realign the rest of the hex string, the identify matrix becomes very clear:
0000 803f 0000 0000 0000 0000
0000 0000 0000 803f 0000 0000
0000 0000 0000 0000 0000 803f
We can easily see here that the text aligns to the shape of an ...
This question seems simpler than you might expect.
Since as OP noted, the code is irrelevant to validation mechanism used in the discussed system, I shall ignore it. It is indeed irrelevant as will be shown below.
as the first byte in each message indeed looks like a preamble, we'll ignore it. Our goal is to recover the function which, when applied to the ...
It would help if I knew what the data represented, but I have determined the format of the files once unzipped. Each unzipped file has this structure:
short unk1; // 10
short num_records; // 8751 (8760 hours per year)
short unk2; // 0
short num_samples; // varies per file from 8 to 179
short unk3; // 0
short unk4; ...
Oh, I just figured it out. I can interpret each of the following 4 byte values after the header as 32-bit signed floating point values in little-endian format. 0000 803f would be equivalent to 1.0f.
I determined this in node.js using a DataView:
const u = new Uint8Array(4);
const d = new DataView(u.buffer);
u = 0x00;
u = 0x00;
u = 0x80;
u = ...
Based on those images, this appears to be a fairly straight-forward run-length encoded 32-bits-per-pixel bitmap format.
The general structure seems to consist of number of records each with a single 'tag' byte followed by a multiple of 4 bytes of RGBA data. These records appear to encapsulate pixel data only, with no dimensions or other metadata.
I'll leave my previous post/edits for historical purposes, but given this comment
Also, I'd like to try solve it myself as much as possible with your help, not you solving it FOR me, pretty much.
I guess I won't continue trying to make progress on the format. Though I do have some additional ideas based on my previous observations.
So to directly ...
One small discovery on the ND1: In a sys ex dump, byte 6 is 6 if you are dumping a single program, an 8 if you're dumping all. Byte 7 is a 0 if you're dumping one program or the number of the program (-1) if you're dumping all.
Perhaps even more interesting -- this only seems to change the value of the final checksum (byte 110) but not the mysterious other ...
The only Nord Sys Ex spec I found was for the Nord Stage, which apparently used a "7-bit checksum (sum of all bytes above - wrapping)." So I yesterday I tried every variation of that I could think of, basically summing and masking to 7-bits. Failing that I came back to this post.
The message headers are similar between the two devices (same and different ...
I read about similar issue with ZTE modem: ZTE encrypted backup config file
It was ZLIB-compressed and encrypted with AES in ECB mode with a 16-byte key. You can read this topic, maybe it can work for your modem too.
I'll post this as an answer to techniques to reverse engineer an unknown file. Reverse engineering is not about just looking at binary data. It is a detective mystery. You need to gather clues and try to solve the mystery. Sometimes the clues are outside the binary data.
Look at the program generating the data. Look for places where you know the inputs and ...
I'm working on some tooling for automatic reverse engineering.
Having messages of varying length makes it much easier to determine which fields are related to overall message lengths. It also makes it much easier to identify where the 'header' portion is, as it will have a consistent format and precede the variable length portion.
The more data and the more ...
Code and binary is really, really hard. People who say it's easy are either stupid or want to sell you something. On the other hand, it's relatively easy if the code in question is created by a completely naive person or they really don't give a damn if it being attributed to them.
For general education try some results of this search https://www.google.com....
One method (theoretical at this point) that comes to mind is searching for constants like resolution numbers in instructions for example, a game uses 600x800 resolution - you might find instructions like
push 0x320 #800 in decimal
push 0x258 #600 in decimal
or it might reference integers stored in a data section or ...
Your camera has a Xilinx FPGA inside. FPGA design likely includes Microblaze soft CPU core. Files extracted by binwalk appear to be valid ELF files, so you'll just need to download Microblaze toolchain. The easiest way to do so is to download Vivado WebPack (it's free) and install it — you'll find a toolchain in the Xilinx SDK folder.
googling for e-snAetgrU yields the VBA Macros
just copy paste the macros into a VBA module in word/excel/
insert a few Msgbox() and you can decrypt all the strings
the unobfuscation is as follows
obf_str = "e-snAetgrU"
obf_str_len = len(obf-str) == 10
redherr = 1
i = 0
d(69, 43, obf_str)
rand = arg1 == 69
Char_Choice_num = ( ...