Last year, I released an IDB for a piece of large, complex malware written in C++, which made regular use of virtual functions, which produce patterns of indirect call instructions like the ones your question discusses. I conducted that analysis purely statically, and I may release more IDBs like it later this year that were also done via static analysis.
I had a bad practice in a similar case 10 years ago (that's an obfuscated code of malware that I could not use debugger to analyze) and I tried to write a simple CPU emulator to run that code (because that time I didn't get a working opensource code or library so I decided a simple one).
Now we have some CPU emulator engine/framework (unicorn engine,...) so ...
if using win32 apis are an option you can try something along this line
the first example command uses cdb to gets rva and bytes for counter checking (something like you do with objdump)
the second is a python script which you can use as refernce to adapt in your language of choice
the third is actual execution and bytes fetched from address
:\>cdb -c &...
If you do not necessary want to use IDA, you could use radare2 and then do:
To get examples of how to use this command on radare2 you could use:
If you necessary want to use IDA pro for your knowledge, you could skip my answer.
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 ...
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 ...