[FEATURE] Some pooltags aren't recognized

[eranzim]

Describe the bug Pooltags which aren't immediate values in the correct place, but possibly propagated via a register, aren't found. Example code snippet:

...
mov     ebp, 'ABCD'
mov     rdx, rax        ; NumberOfBytes
mov     r8d, ebp        ; Tag
call    cs:ExAllocatePoolWithTag

Expected behavior All Pooltags should be found

Desktop (please complete the following information):

• OS and version: Windows 10 21H2 (19044.1586)
• IDA version: IDA 7.7 SP1
• DriverBuddyReloaded Version: latest (1.3)
• Python Version: 3.9.5

[VoidSec]

I can see your point in having DriverBuddyReloaded recognize the above-mentioned case, unfortunately, it is easier said than done. At the beginning of the development, I've decided to exclude this case (it can also be applied to banned functions parameters) due to the added complexity that it brings in.

In order to do so, I would have to add some "backtracking" mechanism (able to work for both x86 and x64 function calling convention) that can trace the tag parameter across multiple opcodes that populate the register/push the value on the stack. In any case, it would only be able to find "hardcoded" immediate values but it will miss (AFAIK uncommon) run-time computed Tags.

While I agree that this feature would be nice to have, at the moment I do not have the time to implement that. Plus, IDA is already able to correctly mark function's parameters as follows:

[VoidSec]

~On second thought, the implementation at:~ On third thought, the implementation at:

• https://github.com/VoidSec/DriverBuddyReloaded/blob/a07d9196cbcc1ffc7fa2d668dfcae85de3663a19/DriverBuddyReloaded/dump_pool_tags.py#L6

~already use IDA Tag information to find and report the tag, it seems an implementation bug rather than a feature.~ "dump" the Tag only if it is an immediate value and contains ASCII characters, otherwise it would have to backtrace it.

In order to implement that I can think of backtracking a fixed amount of opcodes (~10?), looking for an immediate value containing one to four ASCII characters. Otherwise, I can just print the function without reporting the tag, I'll have to think about it.

[eranzim]

This sounds like a pretty good solution to me. I would probably backtrack to the beginning of the current basic block (whether it's short or long, to avoid problems with code that chooses the tag based on a condition, for example), maybe also print "inconclusive" on values gathered this way, and your suggestion for printing the address even if the tag is unknown sounds good to me.