Let me summarize the links given at https://reverseengineering.stackexchange.com/a/1993/12321 without going into serious disasembly analysis for now.
When the Linux kernel + dynamic linker is going to run a binary with exec, it traditionally just dumped the ELF section into a known memory location specified by the linker during link time.
So, whenever ...
When performing firmware analysis, examination of an entropy plot should always be the first step, since this is the fastest way of determining whether the file is compressed or encrypted.
In this case, an entropy plot and the byte frequency distribution of the file indicate that it is encrypted. Hence, no signatures and nonsense strings.
Basically, it just to wrap the index at the length of the string.
In C it looks like something like this:
src[i] = s[i % strlen(s)] ^ v0;
For instance, if the s is "ABCD", strlen(s) is 4. When i is equal to:
4, 4 % 4 == 0
5, 5 % 4 == 1
and so on.
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; // ...
This is actually quite a straightforward C++ string function. It's just that, behind the scenes, the C++ std::string class is actually a typedef of a template.
typedef basic_string<char> string;
basic_string itself is declared as -
template< class CharT,
class Traits = std::char_traits<CharT>,
class Allocator = std::...
I found all the signatures by performing an Out-of-Band attack on the engine and with the help of a huge set of mutated files. Lots of reverse-engineering as well. I had to triage a lot of false positives and it required manual work, so this is still not the ideal approach, but clearly more scalable than the other suggested ones.
I have shared some of the ...
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 ...
It counts the number of 1's in argument's binary representation (see link).
Basically, each n & (n - 1) cancels out the least significant 1 in n's binary representation, preserving all more significant digits.
This error message probably should be ignored. I found something on the radare2 github
"These ptrace (PT_ATTACH): Operation not permitted messages seem to
happen because of subsequent PT_ATTACH calls to the same pid, even
though it is already attached. This should be fixed, but it probably
shouldn't cause any major issues right now." ~thestr4ng3r
Looks like strings from the first few sections of a Linux ELF32 binary created using the GCC toolchain. I can't tell you which version of GCC though.
Your question should include the output of the following commands:
file [name of binary]
readelf -h [name of binary]
readelf -SW [name of binary]
objdump -dj .text [name of binary]
strings output on its own ...
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 ]─────────────────────────────────────────────────────────────────────────────────────────
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]
You could look at the radare project:
Their ESIL representation of mnemonics can help you track down the access to variables, registers and even flags.
For example, inc edi will result in edi,++=,$o,of,=,$s,sf,=,$z,zf,=,$p,pf,=
If the executable is not compiled statically, I think the easiest way is to inject a shared object (.so) with LD_PRELOAD to hook/overload the function which prints it and display the address of the buffer. If you disable ASLR, you should be able to set a memory breakpoint on the string address and then figure out how it was 'encrypted'.
Another solution is ...
rip = x64
eip = x86
dr shows eip in your case
it is probably some demangled name (not sure why radare2 inserts the GLIBC part )
but if you strip the GLIBC part you can use iD Command to demangle it to std::cout
[0x01012d6c]> iD cxx _ZSt4cout__GLIBCXX_3.4
[0x01012d6c]> iD cxx _ZSt4cout__GLIBCXX_
[0x01012d6c]> iD cxx _ZSt4cout__GLIBCXX
Your breakpoint doesn't work as it is put in the part of the code that is not executed with the pass your provided. I'll try not to give too much hint so that you can still solve it by yourself.
Now I can see that the instruction | ========< 0x0040178f 7519 jne 0x4017aa compare the password with the parameter passed as argument.
This is ...
First I believe loading it with IDA (or r2) could be helpful. But I don't know how to set up a raw dump in IDA, do i have to load it manually? am i missing something?
IDA directly handles raw image, all you have to do is specify the ARM little-endian [ARM] in the processor type.
Once it's loaded, your first challenge is to identify the memory layout.
My guess is that the website is parsing the Rich Signature (see https://www.ntcore.com/files/richsign.htm for analysis and details). There is a shorter description here. Basically, Microsoft's linkers add some info that can be used to infer that information.
Without reviewing the file itself, other than a VB script used as a macro, the second part is more likely an obfuscated/encrypted executable file of some sort.
However since it's evident macros are used, the executable file (either a PE or a script) is probably at least somewhat obfuscated and will only be decoded/decrypted before being it's dropped to disk ...
I used a less smart approach. I wrote the hex blob to a file, wrote a quick Python script to add a padding byte after every 15th byte so the whole file is nicely aligned when opening it in a hex editor with standard 16 byte width and just had a look at it.
With the padding done, all columns share the same key so I just looked at what letter appeared the ...
You have to gather more constraints
The key has to be 15 bytes long
1st, 5th and 9th bytes of the decrypted buffer are expected to be 0x60, 0x0D0, 0x0
The Block should be executable!
And you should start with the last one. I assume this is an x86 executable, so 0x60 would correspond to an PUSHA instruction, which does does seem reasonable.
You could run a ...
Lets take a look at the specific piece of code you can't understand:
mov dword [var_48h], 0
mov dword [var_44h], 0
mov eax, dword [var_48h]
movzx eax, byte [rbp + rax - 0x40]
And go over it a few lines at a time.
The first couple of lines are either initializing a local variable of size qword (8 bytes) to 0 by assigning one dword at a time, or two ...
If the API key is a string then just running strings would reveal it w/o grep as you do in your example. There might be some other strings but longer ones seems to stand out so it should be clearly visible that this is something meaningful. Having that API key I would probably go and use regular disassembler tools to see where and how it is used.
You can't ...
I had some trouble really understanding your question so I'll try to answer this question as best as I can.
When you use pdf you instruct radare2 to print the disassembly of the whole function. Where each function begins and ends is identified when analysis is done (aaa). So if you don't have functions identified pdf won't work.
You run your analysis so ...
relative address can be forward or backward from end of current instruction
or start of next instruction
that e8 00 00 00 00 will be call to the next immediate instruction
forward can be e8 ( 00 00 00 00 .... 7f ff ff ff )
backward can be e8 ( ff ff ff ff .... 80 00 00 00 )
so your immediate here is 0xfffffe6b that is == -0x195
It's not exactly an RE question but I'll try to answer.
First of all, since the capsule is signed, it's very likely that any modification will invalidate the signature and the update process will refuse it.
In general, extracting a raw image from the capsule may range from trivial (e.g. for ASUS capsules it's usually enough to just cut off the header) to ...
In C++, the pointer of the method associated with an object are stored in something called a vtable. In order to call a specific method, you need to get a pointer to that vtable and get to the proper function. In the end, your going to end with a "call eax", even though the function call is not from an external library.
Well, it really depends on your case. ...
I'll present the steps that I would perform in such a case. Note that they aren't necessarily the most efficient and reliable ones although they should work in many cases. I'm assuming that the binary you want to examine isn't packed and obfuscated.
Look for the imports. Sometimes the code you are looking for is just taken from external library. In this ...