4

When you have just raw bytes without proper headers tools might not know how to process as the code might not start from offset 0. They could try to analyze the bytes to detect if there's code, data or something else but you might also get some false-positives. In your case, you instruct r2 to display those bytes as code (pd - print disassembly) and it does ...


3

Without the proguard mapping, this is not possible. That information is simply no longer contained in the dex file. The best you could do would be to manually rename the methods, etc. with your own names.


3

Try to do ctrl + A - select all and then press D to disassemble. good chance it will solve your problem.


2

Paweł Łukasik is correct. Disassembling the code fragment using Ghidra can be done in 3 steps: Selecting the architecture (which you have already done) Highlighting the bytes to disassemble Press "D" as Paweł stated or right click and select "disassemble"


2

You need to change the Actions from "Trace" to "Break" When the condition is true the action will execute.


1

To add on too Yennefer's wonderful and respectable answer: Going through the memory segments can definitely help, a lot of times obfuscators will tamper with those. Giving a possible clue as to what the obfuscator is. Also look at the imported functions, how do those look? Some obfuscators mess around with the IAT, and some of the functions inside of the ...


1

Usually, I try to detect which obfuscator has been used. Knowing your enemy is the first step towards the victory. If you can detect the obfuscator, you may be lucky and find the corresponding "deobfuscator". You won't have the original source, but you'll significantly decrease the entropy and the noise. A good starting point is to look at how the strings ...


1

If you have U-Boot shell, changing bootargs environment variable to add the single keyword and then issuing the boot command should drop you into a root shell. Use printenv to see current args and the boot command.


1

I don't know IDA debugger very well, but I can tell how it can be done in GDB. First of all, I would suggest disabling ASLR (echo 0 | sudo tee /proc/sys/kernel/randomize_va_space) to prevent address space randomization. If the string you are looking for is at the same location each time, then simply setting watchpoint at that location will do the job. If ...


1

You were almost there. But they have to point to exactly the same address so this "cmp" instruction that comes after it will succeed This statement is incorrect. Not addresses are being compared, but the data at each. The code, starting from .text:00C21094 compares 13 subsequent bytes at byte_C23018 with their counterparts at loc_C23024. So, to get the ...


1

You can open IDA, go to the beginning of the file, press shift, hold it, scroll to the end of the file - which will result that the whole code is selected, and press 'c' for analysis.


Only top voted, non community-wiki answers of a minimum length are eligible