New answers tagged assembly
2
The canonical source is the ARM Architecture Reference Manual.
If you prefer machine readable format, the XML files are available too.
6
This doc may be interesting for you:
https://github.com/CAS-Atlantic/AArch64-Encoding
3
Eureka!
HERE IS THIS TABLE
P.S. It's really hard to google it (keywords I used - "b arm64 opcode"), so I decided to post it as answer. Hope it'll be helpful for others.
1
You can extract some file from .exe using pyi-archive_viewer, modify them and put back. But be attention, all files in .exe are compressed using DEFLATE (zlib.compress() - you can watch this in source code of PyInstaller). So, when putting back you need compress file to the exact size, that was when you extracted it.
1
Not Sure i selected uxtw in this post Right Clicked and Search Google For UXTW
the First Hit is Arm Documentation
SUB Wd|WSP, Wn|WSP, Wm{, extend {#amount}} ; 32-bit general registers
SUB Xd|SP, Xn|SP, Rm{, extend {#amount}} ; 64-bit general registers
extend
Is the extension to be applied to the second source operand:
32-bit general ...
0
It depends on what you are achieving:
source code extraction (say to replicate it with minor modifications)
program patching
For the first case, I normally try to use a non invasive debugger attached after suspending the process. If this does not work, I dump the whole process with SysInternals Process Explorer or WinDbg after suspending the process. The I ...
0
I would try to determine the OOP language it was written there might be tools/IDA scripts to help with static analysis
I have found the easiest way to reverse this kind of app is using time travel debugging trace (or similar) On Windows platform this is achieved by downloading WinDbg Preview from Windows 10 store. Once downloaded you can copy the files and ...
2
I would assemble the code and then analyze it using emulation.
Example assembly taken from the link:
mov rax, QWORD PTR [rbp-16] ; Move i (=9) to RAX
movabs rdx, -3689348814741910323 ; Move some magic number to RDX (?)
mul rdx ; Multiply 9 by magic number
mov rax, rdx ; Take only the upper 64 bits of ...
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.
0
Those are indirect jumps caused by the compiler or/and the linker in order to locate an external function.
According to how the function is defined, both the linker and the compiler may end up in emitting a stub, thus making the call stack insanely deep during the analysis.
As stated in the comments, this SO answer Indirect jumps for DLL function calls ...
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
I guess newByte[two.length + 1] = 1; look like iterate some value in variable two
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 ...
Top 50 recent answers are included
