Switch-case recovery when MSVC used a jump table plus a sparse tree

I would have written the opposite conclusion a year ago. «Switch-case recovery when MSVC used a jump table plus a sparse tree» — specifically One function: dense jump table for 0-31, binary tree for the rest. UPX with a skipped magic is still UPX. Restore four bytes and move on. Same class as the October thread, different binary.

@cryptx

I would have written the opposite conclusion a year ago. «Switch-case recovery when MSVC used a jump table plus a sparse tree» — specificall

That is not what the listing shows. You are arguing a vibe. This matches a public n-day class from last patch Tuesday. You wrote «One function: dense jump table for 0-31, binary tree for the rest». That is the sentence I keep. If it is a crackme you wrote, dump after the decoder. Do not fight the packed view forever. I still have the snapshot named reve-31-pre.

@guard

If you only have the decompiler, you do not have the bug. You wrote «One function: dense jump table for 0-31, binary tree for the rest». Tha

Do not call people skids because they use Ghidra. I ran this on a licensed corpus binary. On «Switch-case recovery when MSVC used a jump table plus a sparse tree»: One function: dense jump table for 0-31, binary tree for the rest. 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.

@idrisconnect

I ran this on a licensed corpus binary. On «Switch-case recovery when MSVC used a jump table plus a sparse tree»: One function: dense jump t

You are describing a live target. Stop. Patched class only. Came back to this after a coffee. Still hold. On «Switch-case recovery when MSVC used a jump table plus a sparse tree»: One function: dense jump table for 0-31, binary tree for the rest. UPX with a skipped magic is still UPX. Restore four bytes and move on. My note id for this: 1f-09.

@downtownjay

Please keep the hashes and drop the mystery zips. You wrote «One function: dense jump table for 0-31, binary tree for the rest». That is the

I read the patch. You read a tweet. Those are not the same source. Did this on ARM64 last week — same shape, different pain. The load-bearing line: One function: dense jump table for 0-31, binary tree for the rest. Vtable grouping without RTTI: xref clusters plus IUnknown shape. Which build of the tool? I got burned mixing notes across versions. Version in my shot: current lab snapshot, not last year's blog.

Please keep the hashes and drop the mystery zips. You wrote «One function: dense jump table for 0-31, binary tree for the rest». That is the sentence I keep. Listing first. The decompiler invented a cast last week that hid a signed compare. My note id for this: 1f-02.

@encode

Did this on ARM64 last week — same shape, different pain. The load-bearing line: One function: dense jump table for 0-31, binary tree for th

Came back to this after a coffee. Still hold. The load-bearing line: One function: dense jump table for 0-31, binary tree for the rest. FID for your own libs is worth the CI time. Watch COMDAT folding or the database will lie. Version in my shot: current lab snapshot, not last year's blog.

@Flybancode

Came back to this after a coffee. Still hold. The load-bearing line: One function: dense jump table for 0-31, binary tree for the rest. FID

Call-convention guess is not evidence. I will argue the opposite and then probably agree. «Switch-case recovery when MSVC used a jump table plus a sparse tree» — specifically One function: dense jump table for 0-31, binary tree for the rest. Call-convention mass-correct with a script. Still too much clicking. My note id for this: 1f-05.

If you only have the decompiler, you do not have the bug. You wrote «One function: dense jump table for 0-31, binary tree for the rest». That is the sentence I keep. I leave CET ops in the listing. They document that CET is on. I will +rep a listing and −rep a vibe. That is the deal.

@jamesnode

Came back to this after a coffee. Still hold. On «Switch-case recovery when MSVC used a jump table plus a sparse tree»: One function: dense

I tried the naive path first and wasted a morning. On «Switch-case recovery when MSVC used a jump table plus a sparse tree»: One function: dense jump table for 0-31, binary tree for the rest. I bookmark the decoder then re-analyze. Reloading the file is the honest fallback. Version in my shot: current lab snapshot, not last year's blog.

I ran this on a licensed corpus binary. On «Switch-case recovery when MSVC used a jump table plus a sparse tree»: One function: dense jump table for 0-31, binary tree for the rest. I leave CET ops in the listing. They document that CET is on. Did you snapshot before, or is this a restore-from-memory story? Pinned a comment at 0x140004144 in the listing.