Summary
olevba flags ActiveX/form control event handlers such as CommandButton1_Click under the AutoExec category with the description "Runs when the file is opened and ActiveX objects trigger events." For _Click specifically, that description is inaccurate: a _Click handler fires only on explicit user interaction, not when the document is opened.
This is a description/wording issue, not a request to stop flagging the keyword. Reporting these control events is intentional (see #499). The concern is that the human-readable description asserts on-open execution for events that require user action.
Environment
- olevba 0.60.2
- Python 3.12.3
Steps to reproduce
Analyze any macro-enabled workbook containing a form/ActiveX button with a _Click handler (e.g. Private Sub CommandButton1_Click()).
Actual output
|Type |Keyword |Description |
|AutoExec |CommandButton1_Click|Runs when the file is opened and ActiveX ... |
Cause
In olevba.py, the AutoExec keyword table maps the description
'Runs when the file is opened and ActiveX objects trigger events' to a regex group that includes user-interaction events alongside genuine on-load events:
r'\w+_GotFocus', r'\w+_LostFocus', r'\w+_MouseHover', r'\w+_Click',
r'\w+_Change', r'\w+_Resize', r'\w+_BeforeNavigate2', ...
\w+_Click matches CommandButton1_Click and inherits the "Runs when the file is opened" text. Events like _GotFocus, _LostFocus, and _Resize can plausibly fire during control initialization/rendering as a document loads; _Click cannot — it requires a user to click the control.
Why it matters
The literal wording is increasingly consumed downstream by other tooling and by automated/AI summarizers that treat "Runs when the file is opened" as evidence of auto-execution. For a benign document whose only macro entry point is a user-clicked button, this can escalate into an inaccurate "triggers on open" / auto-exec narrative even though no on-open code path exists (no Workbook_Open / Auto_Open / Document_Open). Tightening the description reduces that misinterpretation at the source.
Suggested fix
Keep _Click (and any other interaction-only events) flagged as they are today, but give them a description that reflects their actual trigger rather than asserting on-open execution — for example, splitting \w+_Click into a separate entry such as:
"Runs when the user interacts with an embedded ActiveX control (e.g. clicks a button)"
This preserves the detection behavior added in #499 while removing the inaccurate on-open wording. The maintainer may want to review the other events currently grouped under the same description (e.g. _Change) and decide which genuinely fire on load versus on interaction.
Related
Aside (out of scope for this fix)
This change is confined to olevba — mraptor emits only A/W/X flags and has no per-keyword description strings, so nothing there needs to change. Worth noting separately, though: the autoexec keyword patterns are maintained in two hand-synced copies (olevba's keyword table and mraptor's re_autoexec regex), which is a drift risk over time. Factoring the shared patterns into a single source would be a nice follow-up, but it's independent of the wording fix above.
Summary
olevbaflags ActiveX/form control event handlers such asCommandButton1_Clickunder the AutoExec category with the description "Runs when the file is opened and ActiveX objects trigger events." For_Clickspecifically, that description is inaccurate: a_Clickhandler fires only on explicit user interaction, not when the document is opened.This is a description/wording issue, not a request to stop flagging the keyword. Reporting these control events is intentional (see #499). The concern is that the human-readable description asserts on-open execution for events that require user action.
Environment
Steps to reproduce
Analyze any macro-enabled workbook containing a form/ActiveX button with a
_Clickhandler (e.g.Private Sub CommandButton1_Click()).Actual output
Cause
In
olevba.py, the AutoExec keyword table maps the description'Runs when the file is opened and ActiveX objects trigger events'to a regex group that includes user-interaction events alongside genuine on-load events:\w+_ClickmatchesCommandButton1_Clickand inherits the "Runs when the file is opened" text. Events like_GotFocus,_LostFocus, and_Resizecan plausibly fire during control initialization/rendering as a document loads;_Clickcannot — it requires a user to click the control.Why it matters
The literal wording is increasingly consumed downstream by other tooling and by automated/AI summarizers that treat "Runs when the file is opened" as evidence of auto-execution. For a benign document whose only macro entry point is a user-clicked button, this can escalate into an inaccurate "triggers on open" / auto-exec narrative even though no on-open code path exists (no
Workbook_Open/Auto_Open/Document_Open). Tightening the description reduces that misinterpretation at the source.Suggested fix
Keep
_Click(and any other interaction-only events) flagged as they are today, but give them a description that reflects their actual trigger rather than asserting on-open execution — for example, splitting\w+_Clickinto a separate entry such as:This preserves the detection behavior added in #499 while removing the inaccurate on-open wording. The maintainer may want to review the other events currently grouped under the same description (e.g.
_Change) and decide which genuinely fire on load versus on interaction.Related
_Layout,_Click, etc. as AutoExec keywords. This issue complements that change by refining the description text, not reverting the detection.Aside (out of scope for this fix)
This change is confined to
olevba—mraptoremits onlyA/W/Xflags and has no per-keyword description strings, so nothing there needs to change. Worth noting separately, though: the autoexec keyword patterns are maintained in two hand-synced copies (olevba's keyword table and mraptor'sre_autoexecregex), which is a drift risk over time. Factoring the shared patterns into a single source would be a nice follow-up, but it's independent of the wording fix above.