3

This sounds analogous to given a document, infer the language. I'd compare the frequency (count for each value in the file) of instructions with the frequency of instructions derived from files for known processor types. Effectively a unigram model. If you source the files in a common format I can give you a hand.


2

You can't - the Intel hex format doesn't hold this kind of data. You need to manually look for the correct architecture. You can use IDA or Ghidra for that and open in the following for each architecture it might be. Then you need to disassemble the whole file and look if it makes sense. (Control flow, number of functions, xrefs,...) Or of course, use some ...


2

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 ...


2

Yes, Windows 10 can be used for malware analysis. All the modern RE tools, such as IDA Pro, Ghidra, Binary Ninja, etc. run on it.


1

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 -...


1

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 ...


1

Assuming, that executable is not packed, and if you got to the killswitch already, just select some asm commands and look for them in debugger. then you can change necessary bytes with NOP. No recompilation would be necessary at all. Recompilation, even if successful, will make executable not exactly the same as original code.


1

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 ...


Only top voted, non community-wiki answers of a minimum length are eligible