New answers tagged decompilation
1
At a guess, lpParameter is located in a segment marked read-only (e.g. a code section), so the decompiler considers its value to be constant (probably zero) which is why all subsequent accesses are also zero-based. There are two solutions:
Mark the segment containing lpParameter to be writable (edit segment properties). In case the writable data is a small ...
1
As far as I can see according to the decompiler output the program accesses not-existing (not created) segment at address 0x0. This may be a reason why it thinks that some memory is not writeable.
You can check this by creating a segment with r/w permissions at address 0 and size at least 0x20.
In addition as we can see from the full listing of the function ...
4
1) you demangle the function names for these which are called within the function
2) you learn the arguments of these functions and apply the names to local variables which are passed as arguments to the functions
3) you learn the structures and apply them to stack variables, so that you can name more stack variables which are assigned to the structure ...
0
Since we're talking windows (and 5 years later) how about this: intall the program, go to the install dir and get the jar(s) from there. Now you can decompile the jar directly.
0
Even when there are no try/catch blocks in a function, the compiler may generate a FunctionInfo structure and register a C++EH handler (such as __CxxFrameHandler). This is necessary, for example, to destruct automatic (stack-allocated) C++ objects going out of scope, or cleaning up a partially constructed object in a constructor. In such functions there will ...
4
When I assembled the code, the offending instruction was:
0x6c 40 ff d1 call rcx
You will need to use Change Stack Pointer command in IDA to fix this in disassembly. As per IDA documentation:
This command allows you to specify how the stack pointer (SP) is modified by the current instruction.
You cannot use this command if ...
0
It looks like your program reads a function pointer from a global memory location, and then executing it. I can guess that the jump target isn't known at compile-time, but only on runtime.
*(code *)0x142000000)();
Means go to address 0x142000000, and treat its value as a function pointer, and call it.
You can try to look for write references to ...
0
You can potentially change this to what you're looking for by using the "Modify Instruction Flow..." menu item when right clicking the jump instruction.
In ghidra, press F1 and search for "Modify Instruction Flow" for a full description
0
You can give https://retdec.com/idaplugin/ a try. I've heard it can decompile larger functions without much error.
According to them it supports decompiling a whole binary file. So it possibly could decompile this function without much hesitation. Although I can't promise anything.
Good luck! :-)
-1
I guess newByte[two.length + 1] = 1; look like iterate some value in variable two
Top 50 recent answers are included
