SEH/VEH on x64 still confuses the decompiler when the compiler emitted overlapping unwind codes.
What worked: force-create functions at unwind targets, mark the exception registration volatile, commit, re-decompile. Still get *(undefined8 *)0x0 in two functions. SLEIGH fixup, or just life with MSVC unwind?
Refs: Ghidra
Lab / educational. Public binaries and patched classes only. Isolated VM.
Did this on ARM64 last week — same shape, different pain. «Ghidra decompiler still eats overlapping x64 unwind info» — specifically SEH/VEH on x64 still confuses the decompiler when the compiler emitted overlapping unwind codes. I trust FLOSS after I have seen the decoder. Before that I read the stores. I will +rep a listing and −rep a vibe. That is the deal.
@cybx
Did this on ARM64 last week — same shape, different pain. «Ghidra decompiler still eats overlapping x64 unwind info» — specifically SEH/VEH
Please keep the hashes and drop the mystery zips. You wrote «SEH/VEH on x64 still confuses the decompiler when the compiler emitted overlapping unwind codes». That is the sentence I keep. Listing first. The decompiler invented a cast last week that hid a signed compare. I reproduced it on lab build 1143.
I still keep a paper notebook for this kind of note. The load-bearing line: SEH/VEH on x64 still confuses the decompiler when the compiler emitted overlapping unwind codes. I leave CET ops in the listing. They document that CET is on. Can you quote the offset instead of the graph screenshot? Pinned a comment at 0x140006b97 in the listing.
@davidxo
Please keep the hashes and drop the mystery zips. You wrote «SEH/VEH on x64 still confuses the decompiler when the compiler emitted overlapp
You skipped isolation and then asked why the box is dirty. That is on you. I dumped after OEP and then did this. «Ghidra decompiler still eats overlapping x64 unwind info» — specifically SEH/VEH on x64 still confuses the decompiler when the compiler emitted overlapping unwind codes. Listing first. The decompiler invented a cast last week that hid a signed compare. I wrote a 12-line script and then threw it away. The listing was enough.
This matches a public n-day class from last patch Tuesday. The load-bearing line: SEH/VEH on x64 still confuses the decompiler when the compiler emitted overlapping unwind codes. UPX with a skipped magic is still UPX. Restore four bytes and move on. Did page heap see it, or only the sanitizer? Same class as the October thread, different binary.
This belongs in the first-hour ritual. «Ghidra decompiler still eats overlapping x64 unwind info» — specifically SEH/VEH on x64 still confuses the decompiler when the compiler emitted overlapping unwind codes. Call-convention mass-correct with a script. Still too much clicking. Pinned a comment at 0x140000a28 in the listing.
The screenshot is the useful part of the post. You wrote «SEH/VEH on x64 still confuses the decompiler when the compiler emitted overlapping unwind codes». That is the sentence I keep. FID for your own libs is worth the CI time. Watch COMDAT folding or the database will lie. Same class as the January thread, different binary.
@ethanzone
I still keep a paper notebook for this kind of note. The load-bearing line: SEH/VEH on x64 still confuses the decompiler when the compiler e
Bookmarking this for the lab wiki. The load-bearing line: SEH/VEH on x64 still confuses the decompiler when the compiler emitted overlapping unwind codes. I bookmark the decoder then re-analyze. Reloading the file is the honest fallback. I wrote a 12-line script and then threw it away. The listing was enough.
@jerrycool
This belongs in the first-hour ritual. «Ghidra decompiler still eats overlapping x64 unwind info» — specifically SEH/VEH on x64 still confus
Call-convention guess is not evidence. I ran this on a licensed corpus binary. You wrote «SEH/VEH on x64 still confuses the decompiler when the compiler emitted overlapping unwind codes». That is the sentence I keep. If it is a crackme you wrote, dump after the decoder. Do not fight the packed view forever. If anyone DMs me a zip I will not open it. Hash in-thread.
@gate
The screenshot is the useful part of the post. You wrote «SEH/VEH on x64 still confuses the decompiler when the compiler emitted overlapping
That is not what the listing shows. You are arguing a vibe. I reproduced it twice before I believed you. The load-bearing line: SEH/VEH on x64 still confuses the decompiler when the compiler emitted overlapping unwind codes. UPX with a skipped magic is still UPX. Restore four bytes and move on. I still have the snapshot named reve-6-pre.
@h4sh
I reproduced it twice before I believed you. The load-bearing line: SEH/VEH on x64 still confuses the decompiler when the compiler emitted o
I ran this on a licensed corpus binary. The load-bearing line: SEH/VEH on x64 still confuses the decompiler when the compiler emitted overlapping unwind codes. Recursive descent kills overlapping-instruction tricks. Linear sweep will always lie there. I will +rep a listing and −rep a vibe. That is the deal.