In binaries compiled with Visual C++, functions which use SEH (Structured exceptions handling), usually use var_4 ([ebp-4]) for the try level value (value specifying the current SEH scope block).
The value 0FFFFFFFFh (or -1) is used for the outermost, global function scope (i.e. before and after any __try blocks).
For more info check my OpenRCE article.
The function you (or IDA) labeled start is commonly called __x86.get_pc_thunk.bx and is used by GCC and other compilers to calculate the current execution address for Position independent code (PIC). Usually the add instruction after the call results in ebx gettng the value of the GOT (Global offset table) so that external calls can be done without extra ...
I have seen code like this, but it was quite a while ago! It only ever relates to the accessing of global variables: often called a Global Offset Table. More info here: https://stackoverflow.com/questions/55587313/why-use-the-global-offset-table-for-symbols-defined-in-the-shared-library-itself
Generally, the solutions to this problem can be classified to:
Pattern matching heuristics. Just like what you are proposing. For example, searching for pushes in the binary can provide a (rather) rough approximation of function starts. Things are more difficult if you want to locate function ends though.
Machine learning. Pattern matching can be automated ...
This is most likely code that was compiled without optimizations (-O0 ). In such code redundant operations are very common as the compiler faithfully translates individual statements to machine code but does not try to perform optimizations to remove or simplify redundant ones.
You’re in for a wild ride but it can be achieved if you persist and in any case you will learn a lot.
I would probably start like this:
Check what programs are run by autoexec.bat
Run them in DOSBox and observe the output.
Step through the code in DOSBox debugger (you may need to make your own build to enable it) and try to identify accesses to the ...
The data you give - whatever it is - doesn't comply to Base32.
The following script decodes your encoded string with Python3.
encoded = "WfsRRmNNX02LzKxYKrh030TjLxD4636bf0crQ2ZeWBFiCRx9Yn0kQG1OPDcYSEN+cR1+...
The chip number is not “architecture”. You need to find out what CPU core it’s using (e.g. V850) and look for that.
There may be hundreds or thousands of different chips using the same instruction set, it would not make sense to list them all as separate processor entries.
EDIT: I could find a datasheet for a NEC µPD76F0018 which says it uses a V850E ...
ls comes in coreutils. The best way to experiment with these programs is to download and manually build the binaries (in this way you can give your favorite options like -g, -O3 during compilation).
Anyways, coming back to your question, assuming you want to decompile /usr/bin/ls (that's what I get from your comments on Pawel's answer), then open ...
Your physical RAM size doesn't say too much about what your memory addresses will look like. What matters is your system architecture and how many bits there are (usually 64 or 32). Virtual memory also makes RAM insignificant; each process has virtual memory space covering possibly the entire address space but mapped to a limited section of physical memory. ...
From the decompiler view it cleary states there's no function. Decompiler works when you have one - it shows code of a function.
So, if that's the beginning of a function (it might be) just create it by pressing F (or right click, Create Function) while your cursor is on the line that is the beginning of this function. After that the decompiler view should ...
One of things I do is to read the machine code and translate it back into IR pseudo opcodes sans any addressing address values, and then perform differences between those two pseudo-IR binaries after using this reduction method on each.
I recommend to use IDA for this task but you can try something other. There are dozens of disassemblers.
Open your app in the disassebmler, locate something like that:
Scroll up and find XRef with 'qt_metacast(char const*)' (in case the binary is not stripped):
.rodata:00069B90 aMainwindow_0 db 'MainWindow',0 ; DATA XREF: MainWindow::qt_metacast(...
I don't think it is related to BIND_GET_INSTALL_REFERRER_SERVICE. That is related to Firebase Analytics, i.e., referrer for analytics purposes.
However, it may be related to Google Play app licensing? See https://developer.android.com/google/play/licensing/overview for more details.
You can try to use a tool I created called Threadtear to remove those senseless jumps. It is like java-deobfuscator, but with a GUI and support for newer obfuscator versions. Use Generic > Remove obvious flow obfuscation. You can also reobfuscate the class names / method names to get rid of annoying chinese letters.
First off, have you tried the Krakatau decompiler? Krakatau is designed specifically for working with obfuscated Java bytecode, although the decompiler doesn't support lambdas and isn't very user friendly.
That being said, renamed identifiers is not something any tool will able to help you with. You'll just have to reverse engineer it and change them to ...
I don't see Ghidra in the lists in the other answers, probably because this question was asked in 2013, and Ghidra has only more recently been made available to the public.
Ghidra comes with built-in cooperative working tools. Each user who wishes to cooperate on a reverse engineering project would connect to Ghidra server. This is a simple server that can ...