For the CPU, ebp (and even esp most of the time) are not really different from eax, ebx and other registers. They can contain any data, not necessarily valid addresses. You only get problems (faults/exceptions) if you actually try to execute instructions that use those registers as addresses (directly or indirectly), or, in case of ESP, an interrupt happens.
The leave instruction is equivalent to:
mov esp, ebp
The second instruction pops the value on the top of the stack and stores it in ebp. In the case of a stack-based buffer overflow, your stack layout looks like:
<--- low addresses high addresses --->
[ buffer being overflowed ][saved EBP][RET ADDR]
Currently it is not supported to do debug automation in callbacks. This is related to the threading model and is further explained at https://x64dbg.com/blog/2016/10/20/threading-model.html, which links to some older resources.
Recently there was an interesting development though, because it became possible to automate in the debug callbacks with x64dbg’s ...
I think the results of your well-designed tests help explain pretty much everything.
It is an LZ77 variant. Try the following scheme for decoding the length and offsets. (Encoded bytes are shown below as 8 binary bits.)
1st byte 2nd byte 3rd byte token type length offset(*)
======== ======== ======== ========== ====== ==============
For those who can't get it to work with the already suggested answers, try this as Igor Skochinsky said in the comments because it was the only thing that worked for me.
Or just use cramfsck/unsquashfs to extract the image. Or 7-zip
7z e file.cramfs
and it extracted all files perfectly.
I would say this really depends on your definition of packing. Typically packing is limited to compression moreso than protection. In this case the binary is updated to maintain virtual memory while minimizing file size. The entry point will decompress everything so, despite the files differing, the virtual memory at the point of executing the original entry ...
Is there a difference between unpacked and dumped that I should know about while loading it in IDA to see the actual imports section?
You can dump anything not only packed binaries, but with packed ones it usually comes with stripped imports table just to make it hard(-er) to analyze.
After sample is unpacked it usually rebuild its import table so it can ...
Yea, it's not completely automatic like IDA Pro.
Although the NSA dev team is very active on the project. And any US citizen should be able to add such a feature (via Java) and make a pull request to add it.
I found what you do is simply add the module to your Ghidra project.
When you click on the module/executable it will ask "...Would you like to analyze ...
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; // ...
At debug time:
segments belonging to runtime-loaded DLLs are marked with their names (kernel32.dll etc.),
non-module areas (e.g. heap) have names like debug038,
segments coming from the IDB retain their original names,
so .text most likely belongs to the input .exe/.dll (whichever was used to create the IDB). You can also check the Modules view to see the ...
There is no magic bullet. To understand the code you need to figure out what it's doing and this is not easy. You can start by going line by line, but after some practice you should start seeing patterns at a glance.
A few things:
Please include an entropy plot of the file using the -E flag; this will show if any portion of the file is indeed compressed or encrypted.
Please include a link to either the firmware download site or a direct download link, as well as a link to the UAV product page.
The presence of plaintext strings such as "description" and "image" in the ...
There is no need to have the IDB on the remote machine or keep the .idb and executable in the same folder. After creating the IDB you can even delete the input file or move it elsewhere; IDB is completely self-contained and does not need the file anymore.
Here's a suggested workflow:
Open the sample in IDA on the analysis VM/host to create the IDB.
It is to be taken in consideration that many internal functions use strcmp too. For example in this binary for the first hit on strcmp on my machine looks like this
─────────────────────────────────────────────────────────────────────────────────────────[ BACKTRACE ]─────────────────────────────────────────────────────────────────────────────────────────