A200K
Signature left function scope
That means that the signature is getting too long / the function code you are trying to make a signature for is too short. The easiest fix is to check "Continue when leaving function scope". The message is basically just the warning, and it might work just fine in many cases. Another (and the probably more proper) approach could be to create an xref signature, if possible. That means, you are looking for a better siggable function that calls your original, but short function.
The easiest fix is to check "Continue when leaving function scope". The message is basically just the warning, and it might work just fine in many cases.
This has never worked for me in the multiple times I've tried this. Once the signature maker hits a RETN opcode, it's very unlikely it will find this function again even if you just sample some of the padding. However, the plugin's boundary check already has compensated for this, once it starts hitting the compiler padding and hasn't found a unique signature, it's highly unlikely it ever will, and once you finish the compiler padding, the chance of the two functions being in the same position (A function epilogue -> compiler padding -> B function prologue) is infinitesimal.
However, what I have found is the signature maker misses out on duplexing. What I mean by this, is that if your signature eventually becomes unique enough to only land <4 hits, the hits will usually be in order. Hit 1, Hit 2 and Hit 3. If you can find a succinct signature but then tell the user to use the 2nd hit, I've found this to be very consistent between binaries, at least enough to visually gauge the difference between the multiple hits. It'd be nice to have a config option like "find obtuse signatures" which would generate signatures aforementioned.
@Evasion3356 To be fair, it is hard to cover all edge cases and do the "right" thing automatically. Some manual adjustment and different approach finding will be necessary from time to time, if the target binary doesn't play along.
A very manual variant of your aforementioned "duplexing" is already implemented, when you select the "Copy selected Code" option. If you are confident that some selected code in the IDA Text View will yield a low signature match count, you can select as many lines as necessary and it will generate a (possibly non-unique) signature manually, while also accounting for operand wildcards (if that option is selected). Then, you will have to search for signature matches, and see how unique the manually created signature actually is. Some experimentation might be necessary to get a low match count, but that way, you can achieve what you mentioned.
I would have thought that xref matching was a more reliable option though, if it's hard to create a signature for your targeted function.
@A200K XREF only works if the function is invoked via a CALL. Functions that are apart of the VTable will never have a XREF and thus are useless when using XREFing. This becomes a serious problem on objects that are entirely virtual. The reason for their ambiguity, is there are usually one function the compiler is referencing, but during the linking phase, is made multiple copies of for any number of reasons. I first encountered this when attacking Mac Mach-O binaries or Linux SO binaries. the GCC compiler is most notorious for these, and even sometimes using trampoline functions (functions that are just a JMP instruction to the function). I'm not going to say MSVC is immune to this behavior, but it is few and far between when attacking Windows binaries. I usually see it crop up on Windows binaries compiled with CLang or GNU (GTA V's remake recently is notorious for this as they shifted from the MSVC toolchain to CLang).
@Evasion3356 That is very true, I somehow didn't think about that case. Thank you for the input! It might be worth to automate this process, or define an upper limit > 1 for acceptable signature matches.