In the LDB there is (one or more) special subsignature ${min-max}MACROID$,
which means:
must match any signature from group MACROID (for current filetype),
and the match must occur at a distance of min-max from the start(!) of the
previous logical subsignature match.
It also has the sideeffect of making the previous subsignature considered a
match only if both that and the macro matches. The offset of first match for
the previous logical subsig will be the offset where the {min-max} distance is
satisfied.
The macro logical subsignature will have a count of 0 (if it didn't match
together with the previous subsig), or a count of 1 if it did.
The matches can occur anywhere (even in
different ac scan buffers), since I don't call cli_ac_scanbuff I just use the
offset of first match (which we have for the bytecode anyway).
There can be at most 32 macro groups, signatures are added to a macro group by
using $MACROID$ as offset.
For example pdb entries could be converted to PDB:3:$0:<hexsig of domainname>
if we assign macro id 0 to PDB (and we can assign 31 more macro ids to
whatever).
Example:
test.ldb:
TestMacro;Target:0;0&1;616161;${3-4}12$
test.ndb:
D:0:$12:6262
D:0:$12:6363
D:0:$11:6262
test.dat:
aaaaxccdd
test-nomatch.dat:
aaaaxxxccdd
lsig->bc was referring to the bytecode directly (via a pointer),
but the bytecode struct changes place in memory (it is realloced on each .cbc
load). So use an index instead of the direct pointer.
and relative offsets into BM matcher (load other ones into AC) and
use per-file computed offset table to pick up best shifts (not
enabled by default, bb#1300)
all special offsets are supported for PPC32/64 and x86 executables; for ARM and other archs only section based extensions (Sx[+-]n, SL[+-]n) are supported atm