I use this code snippet when I need to find, define, and do the auto-analysis of every function starting by a specific stub:
from idaapi import *
from ida_search import *
from ida_funcs import *
cnt = 0
my_pattern = '' # The hex value of the opcodes you are looking for
content = get_bytes(start_addr, 4, False).hex()
When in ida you use patch byte, patch word, or assemble, the patch is NOT applied to the base executable.
You just have to go to Edit-> Patch program -> Apply patches to input file.
Then your input file is modified now.
Disclaimer: I'm going to expose my workflow when I see similar things. I'm not telling you that this is the best one or the faster, and I'm sure you have a lot of other way to deal with this. But this should give you an insight on how you can do this.
As your question is really wide and does not contain any details (malware name, hash, or what 'failed to ...
I am not an expert, but have you hear about fuzzing??
"Fuzz testing or Fuzzing is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion." [link]:https://owasp.org/www-community/Fuzzing
I don't know how my tools are doing it under the hood, but if I had to do it myself, I would search for some function's prologues related to my architecture of choice.
This is a good 'signature' to identify a function, as this is something standard (even if you may find some cases where a function doesn't have any prologue/epilogue).
As you may know, the ...
Since this is obviously a pain to do statically or by hand in a dynamic fashion, I would suggest trying another approach.
I personally would try to do it by writing a small emulator.
Since it is mostly 'stack arithmetic' and junk code, this would be perfect. Take a look at the emulation framework named 'Unicorn'.
With this option, you don't have to re-...
A handle is an abstract object.
I am assuming that you are using IDA for static analysis, and that you are not using any embedded debugger through IDA. Correct me if it's not the case.
From a static analysis point of view, you can't trace back the object where is comes from only with its value (100 in your exemple). The handle value is going to be different ...
This seems more so an issue with the dump you've provided to IDA rather than IDA analyzing the imports wrong. Depending on how you dumped the executable, some fix-ups may be required on imports and the PE header.
The easiest way is to get a build of libstdc++ with DWARF debug symbols e.g. by downloading it from the Debian repositories https://packages.debian.org/buster/libstdc++6-7-dbg.
In general you can also compile it yourself, but for common libraries Debian tends to have a version built with debug symbols already. You can then auto analyse it (or run only the ...
Lighthouse might be the one of the best solutions for this.
Instead of using gdb to trace your execution you can use something like Dynamorio or a pintool that is compatible with IDA Lighthouse
You can also modify your script to produce compatible output. You can use existing pintools and frida script present here