I don't know the exact length of string. But, few things to note here are as follows:
Ghidra and IDA has a minimum bound on size of string to recover correct type (ghidra has a limit - or lower bound of 5).
This is necessary to avoid any false positives or conflicting types. And recover correct types without marking a pointer as a string. Check out this ...
The issue here is not strings, it's the fact that Hex-Rays didn't guess the right calling convention for sub_4022E0. Notice that the disassembly listing moves values into both ecx and edx before the call, whereas the decompilation for that call shows only one argument? Hex-Rays thinks there's only one argument -- maybe even only one stack argument -- whereas ...
If you were given a piece of source code written in a language you had never seen before, you would want to study the syntax and rules of the language so that you could understand what the piece of code is doing.
A compiler transforms a high-level human friendly language (C for example) into in binary instructions that a CPU can run directly. These binary ...
You can't, not as a standard command that's currently available through the user interface, anyway. Force new variable only works for stack locations. Perhaps a future version of Hex-Rays will allow the user to force new register variables.
As of 2020, Ghidra should be considered as a major contender. It is challenging IDA Pro in many areas. The integrated decompiler is one of its greatest assets.
The support for debugging was added recently on the official repository. It will be added to the next official build. Ref
Depending on the specific instruction set encoding, regular expressions operating on the binary itself may be flexible enough to ignore the parts which would change based on address.
Piping the code through a naive disassembler and running the regular expression engine on the textual ouptut may be preferable to doing so on the binary as it's a lot easier to ...
can you clarify if the error you are getting is related to message that says this may be caused by another thread holding the LoaderLock ?
if that is the case then it means you allocate memory etc just after windbg/cdb broke on System Breakpoint
if you are doing .dvalloc when you are on System Breakpoint then HttpRequestA might cause the block
go to the ...
Quote From Link
#define LOBYTE(x) (*((_BYTE*)&(x)))
is that a hypothetical query x is treated as address
so x-1 will be a 32 bit type on a x86 machine so theoretically
you cannot assign a 32 bit type to an 8 bit type
LOBYTE(x) will be a byte and not an address so again
theoretically you cannot assign a byte to a byte
LOBYTE(x) is an AND ...
It sounds like you just want to search a binary file for some sequence of binary values. Maybe I've misread and it's more complicated than that.
I'd start with good old grep.
cat binary.exe | xxd -p | tr -d '\n' | grep -o -e '774b'
Send your binary through xxd -p to turn it into a hex string.
Remove the new lines with tr -d '\n'
The hand it off to grep -o -...
Would disassembly, split off the instruction column, then diff, followed by manually comparing using side-by-side text editors (of the disassembled output of each) be fast and simple enough for a one off use.
Otherwise you need a smart comparison that knows that registers and memory locations can be interchanged for each other as long as each is consistent ...
IDA introduced "Variable Length Structures" and describe the usage of it with a very straight forward tutorial.
In short, you need to make sure the "flexible" item is the last item of the struct, and define it as an array of size 0. To do this, define a new struct member char Name, click on it and press *. Then, set the "Array size&...
Is your binary relocated on load (ASLR)? In that case 14608 points to some random memory (probably unallocated). You need to use a position-independent instruction to load the address of the dlopen stub (e.g. ADRL).
ntohs basically converts a netshort to hostshort
>>> import socket
>>> print (hex(socket.ntohs(0x1337)))
>>> print (hex(socket.ntohs(0x3713)))
it will write back
0x3713-0x2 = 0x3711 or 0x1337 - 0x2 = 0x1335
in the address pointed by remaining if it is > 1u
and return back an address a pointer to ...
official way is as pointed out by other answers use symchk.exe from windbg installation
but you can also fetch it by putting together few dbghelp and winsock functions
find below a poc that uses wget.exe
To add to Igor's excellent reply. Unfortunately IDA Pro up until now does not handle TMS320C6 properly. TI DSP common pattern for the calls is to load up call address into 32 bit register and do the register branching (it has direct branching with immediate offsets as well but compiler seems to use it only for local branches within the function). IDA seems ...