How do opaque predicates hinder static analysis?

They change the malware's behavior on each run

They encrypt the code so that it cannot be disassembled

They cause the disassembler to include unreachable code in the control flow graph

They prevent the malware from being debugged

You are analyzing a malware binary that uses control flow flattening. The disassembler shows a large central dispatcher that uses a state variable to jump to different basic blocks. You need to recover the original program structure. Which approach is most effective?

Use a pattern-matching script to find all `jmp [state]` instructions and replace them with NOPs.

Use a symbolic execution engine to track the state variable and enumerate all possible paths through the dispatcher.

Run the malware in a sandbox and observe which API calls are made.

Manually trace each jump in the dispatcher with a debugger and note the order of execution.

What is an opaque predicate?

A condition that changes its value based on user input

A condition that always evaluates to the same value but is difficult to determine statically

A condition that is always false but easy to identify

A condition that is never evaluated because it is in dead code

A malware sample uses opaque predicates that are based on the result of a system call (e.g., `GetTickCount`). This makes the predicate non-deterministic and difficult to evaluate statically. You need to determine the actual control flow. What is the best approach?

Use symbolic execution to model the system call and explore all possible outcomes.

Use dynamic analysis to record the actual values of the system calls and trace the taken paths.

Ignore the predicate because it is non-deterministic.

Patch the system call to return a constant value to simplify the predicate.

While analyzing a packed malware sample in a debugger, you notice that after the unpacking stub executes, the code contains long sequences of instructions that have no effect on the program state, such as `push eax; pop eax` and `mov edx, edx`. These sequences are interleaved with conditional jumps that always take the same path regardless of input. You need to recover the actual logic for further analysis. What is the most efficient approach?

Use a debugger to trace the code and record the taken branch paths, then generate a simplified control flow graph from the trace.

Manually patch every `push eax; pop eax` sequence with NOPs in the binary and re-run the sample.

Run the sample in a sandbox and rely on the behavioral report to infer the malware's capabilities.

Use a static disassembler and manually identify each dead code sequence by looking for instructions that do not modify registers or flags.

GIAC Reverse Engineering Malware

Domain 3Objective 3

Overcoming Misdirection Techniques GREM Practice Questions (Page 5)

Part of the Malware Patterns and Obfuscation domain, which makes up ~22% of our current practice bank. GIAC (SANS) does not publish an official question count, but from its 180-minute exam (~70–120 total, ~15–26 in this domain), expect 5–9 from this objective — we provide 44 practice questions to prepare you well beyond it. (estimate)

44questions here

9free pages

5concepts

Questions 21–25

21foundation · easy
How do opaque predicates hinder static analysis?
Select an answer first
22application · hard
You are analyzing a malware binary that uses control flow flattening. The disassembler shows a large central dispatcher that uses a state variable to jump to different basic blocks. You need to recover the original program structure. Which approach is most effective?
Select an answer first
23foundation · easy
What is an opaque predicate?
Select an answer first
24expert · hard
A malware sample uses opaque predicates that are based on the result of a system call (e.g., `GetTickCount`). This makes the predicate non-deterministic and difficult to evaluate statically. You need to determine the actual control flow. What is the best approach?
Select an answer first
25application · medium
While analyzing a packed malware sample in a debugger, you notice that after the unpacking stub executes, the code contains long sequences of instructions that have no effect on the program state, such as `push eax; pop eax` and `mov edx, edx`. These sequences are interleaved with conditional jumps that always take the same path regardless of input. You need to recover the actual logic for further analysis. What is the most efficient approach?
Select an answer first

Finished these 5 questions?

Review the revealed explanations, or continue through the curriculum.

Next 5 questions →Back to GREM

Free Basic Practice is a study aid with revealable answers — not a scored exam. Examers.io is independent and not affiliated with or endorsed by GIAC (SANS). “GREM” is a trademark of its owner, used for identification only.