New answers tagged disassembly
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"
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 ...
2
You need to change the Actions from "Trace" to "Break" When the condition is true the action will execute.
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.
0
In case it is running into this error Received a SIGTRAP: Trace/breakpoint trap even though there are no breakpoints in the program, check the power of Hardware Debugger e.g. J-Link.
In my case, J-Link was powered on but the port wasn't delivering enough power. Changing the port to high-power one fixed this.
3
Try to do ctrl + A - select all and then press D to disassemble. good chance it will solve your problem.
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
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
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
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.
0
Since you mentioned hex files, one additional issue you could have hit is difference between 16-bit and 32-bit code. Hex file loader probably defaults to 32-bit while this code seems to be 16-bit.
Editing segment properties to mark it as 16-bit after loading should give you better results.
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.
Top 50 recent answers are included
