fix: compute PF, ZF, SF after AAA and AAS instructions#2300
fix: compute PF, ZF, SF after AAA and AAS instructions#2300huehuehuehueing wants to merge 1 commit into
Conversation
helper_aaa and helper_aas only updated CF and AF in eflags, leaving PF, ZF, SF, and OF stale from the prior instruction. While Intel documents these flags as undefined after AAA/AAS, real x86 CPUs consistently set them based on the masked AL result. The sibling helpers helper_daa and helper_das in the same file already compute these flags correctly. This causes observable divergence when code branches on PF (e.g. JP/JNP) after AAA, which occurs in real-world binaries. The fix computes ZF, PF, SF from the result AL after AAA/AAS, using the same approach as DAA/DAS. Two regression tests verify the correct flag values. Signed-off-by: Larry H <l.gr@dartmouth.edu>
|
Looks good to me. Could you send to dev branch? |
|
The failing CI pipelines are all due to 403/503 errors from whatever external resources you use, obviously rate limited. @wtdcode any updates? |
@Antelox I commented earlier pointing to the PR that merges cleanly with dev. See #2311 Right here and above my comment re broken CI: #2300 (comment) 
|
|
Any chance this could be reviewed and merged? This would close an emulation-detection loophole in Unicorn’s x86 emulation, especially in Heaven’s Gate-style detection chains where small flag mismatches can reveal the emulator. It's a very distinctive discriminating signal particular to Unicorn, AFAIK. (@aquynh maybe?) |
3 participants
Summary
helper_aaaandhelper_aasonly updated CF and AF, leaving PF, ZF, SF, and OF stale from the prior instructionhelper_daa/helper_dasin the same file already compute these flags correctlyFix
Compute ZF, PF, SF from result AL after AAA/AAS, using the same approach as DAA/DAS.
Test plan
test_x86_aaa_flags-- verifies PF, ZF, SF, CF after AAA with adjustmenttest_x86_aas_flags-- verifies PF, ZF, SF, CF after AAS with adjustment