Issue with Intel C++ version 19

[VilleK]

When compiling the attached project with Intel C++ version 19.0, and then protecting it with VM-Protect, the resulting exe-file does not work correctly. Please check what is wrong, thank you. Attached sources and binaries.

[Admin]

VMProtect doesn't support this trash:

Code: Select all

0000000140001074 movzx eax, byte ptr [r8+rcx+000042BC]
000000014000107D lea rax, [r8+rax+00001087]
0000000140001085 jmp rax
0000000140001087 inc dl

[VilleK]

What part of the C-code generates that set of instructions? I don't see it here with same source on godbolt: https://godbolt.org/z/5UTpEY

[Admin]

Code: Select all

    for (int i=0; i<16; i++)
    {
      // do nothing because all operations with "dest" and "src" were optimized
    }

Code: Select all

0000000140001063 xor dl, dl
0000000140001065 cmp dl, 0F
0000000140001068 jnbe 0000000140001087 ↓
000000014000106A movzx ecx, dl
000000014000106D lea r8, [0000000140000000]
0000000140001074 movzx eax, byte ptr [r8+rcx+000042BC]
000000014000107D lea rax, [r8+rax+00001087]
0000000140001085 jmp rax
0000000140001087 inc dl
0000000140001089 cmp dl, 10
000000014000108C jl 0000000140001065

[VilleK]

I see. If I understand you correctly it means VM-Protect has an issue with virtualizing a jumptable when it is generated using this technique that Intel C++ uses. But can you detect this code sequence while VM-Protect is processing the binary and emit an error if it fails to virtualize the code correctly?

[Admin]

It seems you didn't understand why this code is trash. Look at this more curefully:

Code: Select all

000000014000106D lea r8, [0000000140000000]
0000000140001074 movzx eax, byte ptr [r8+rcx+000042BC] // EAX is always equal "0"
000000014000107D lea rax, [r8+rax+00001087]  // RAX is always equal "0000000140001087"
0000000140001085 jmp rax // WTF ???
0000000140001087 inc dl
...
.rdata:00000001400042BC                 db    0
.rdata:00000001400042BD                 db    0
.rdata:00000001400042BE                 db    0
.rdata:00000001400042BF                 db    0
.rdata:00000001400042C0                 db    0
.rdata:00000001400042C1                 db    0
.rdata:00000001400042C2                 db    0
.rdata:00000001400042C3                 db    0
.rdata:00000001400042C4                 db    0
.rdata:00000001400042C5                 db    0
.rdata:00000001400042C6                 db    0
.rdata:00000001400042C7                 db    0
.rdata:00000001400042C8                 db    0
.rdata:00000001400042C9                 db    0
.rdata:00000001400042CA                 db    0
.rdata:00000001400042CB                 db    0

I don't understand why "Intel C++" didn't optimize this trash after optimization of all branches inside SWITCH, so we have one external address at "0000000140001087" (you can set "External address" with VMProtect's GUI here and a protected application will work fine).

About jumptable - VMProtect doesn't support jumptable with "byte" elements.

[VilleK]

Ok, we did try to make a smallest reproduceable example of a problem we have in our product. In the real code the branches in switch are not optimized away so this example probably does not expose the real problem. I'll try to create better example.