X86 decompiler interr in 9.2

IDA General
1

In IDA 9.2 load any 32 bit exe/dll (create new idb) and try to decompile a function, you will get interr 50735.

Then after interr save idb and open it again and it works without interr.

Was working fine in 9.1 without need to save and reopen idb…

2

Hi @Morgan,

Could you please be a bit more specific:

  • What flavor of IDA are you using (eg. Home, Pro, Free)?
  • Have you tried it with random 32 Windows executables only? If you open a 32 bit ELF, does that work?

This will help us nail down the problem, as I was not able to reproduce it so far (using IDA Pro).

3

This error can be found in verify.cpp

if ( a.type.get_size() != a.size )
  INTERR(50735); // argument size and its type size mismatch

Do you have any third party plugins installed which could be modifying microcode? If so, try removing them temporarily to see if that fixes the issue.

4

So it looks like microavx.py plugin is causing this issue.

I’m using slightly modified version than original one: https://pastebin.com/7w3Jqm1u

5

So any idea how to fix this interr?

6

Well, you need to figure out why the plugin produces inconsistent mcallinfo_t on your files.

7

But it worked fine in IDA 8.4, 9.0, 9.1 without touching plugin. Doesn’t look like issue with plugin to me…

8

Quite possibly it’s been already wrong before but some new optimization exposed it to the verifier. In any case, we can’t be responsible for workings of third party plugins, unless we get proof that it’s our check which is incorrect.

9

@Morgan jfyi the avx lifter in hrtng and especially the original python version you’re using (which the hrtng lifter is based on) have lots of soundness and correctness issues. Specifically, when it is attempting to lift AVX (ff.) instructions in 32 bit binaries, the resulting behavior is undefined since neither lifter variant actually checks they are operating in a 64 bit context, and many assumptions made in the respective lifter variants proceed to emit microcode as if the binary was 64 bit.

I implemented a new lifter with heavy amounts of testing and edge case coverage, which should significantly reduce the risk of undefined behavior: GitHub - 19h/ida-lifter. Give it a try, maybe it helps.

As a side-note, for any technical readers who care:

AVX2 on IA-32 (protected mode, 32-bit):

Register Constraints

  • Only YMM0-YMM7 accessible (VEX.R, VEX.X, VEX.B extension bits ignored/must be 1 in complement form)
  • No REX prefix → no R8-R15, no YMM8-YMM15
  • 256-bit registers still full width, just fewer addressable

VEX Encoding (32-bit specifics)

  • 2-byte VEX (C5h): [C5] [R̄.vvvv.L.pp] — R̄ inverted, but meaningless in 32-bit (always 1)
  • 3-byte VEX (C4h): [C4] [R̄.X̄.B̄.mmmmm] [W.vvvv.L.pp] — X̄, B̄, R̄ all effectively 1 (ignored)
  • W bit still functional for operand size control (e.g., VPSRLVQ vs VPSRLVD)
  • mmmmm: 00001=0F, 00010=0F38, 00011=0F3A

Functional Differences vs Long Mode

  • Identical instruction semantics
  • Memory operands use 32-bit addressing (ModR/M + SIB with 32-bit displacements)
  • No RIP-relative addressing → disp32 absolute or register-indirect only
  • Stack operations still 32-bit ESP-relative
10

Alright, this is embarassing: I tested my lifter against 32 bit binaries and did in fact stumble over errors, specifically due to YMM register handling. I fixed all issues and released a new version (1.1.0): feat: Enable AVX lifting for 32-bit binaries and add headless dump tool · 19h/ida-lifter@e31171a · GitHub.

Funnily enough, I just realised hrtng disables 32 bit binary lifting altogether, probably because when they ported the python plugin to C++ they recognized the soundness issues but didn’t care enough to properly figure out why it didn’t work.

Take care