Attempt to execute privileged instruction

I have a working licence checking app written in C++ and compiled with SCC. The 32 bit version works well, the 64 bit version crashes and complains of a privileged instruction error (below). I've tried running this as admin and still get the same error.

The licencing code (third party component from LimeLM) might be performing some fancy Virtual Machine detection in which case I'd probably still get the same issue if I called it direct from Fortran.

I'm happy to share the source and build steps. This will be quite a pain if I can't apply the licencing framework as it's pretty much the last step in a 3 year rebuild of the app.

Silverfrost 64-bit exception report on C:\Users\Ryan\Source\Repos\xxx\Licencing\LicenceCheck\x64\bin\LicenceCheck.exe Sat Jul 06 18:24:15 2019

Attempt to execute privileged instruction (c0000096) at address 7ffeb2fec83e

Within file TURBOACTIVATE.DLL In TA_SetTrialCallback at address 1E5E In TA_IsGenuineEx at address 109 Within file LicenceCheck.exe in ShowInfo(int) at address 87 in main at address 2e2

RAX = 00000000564d5868 RBX = 0000000000000000 RCX = 0000000000000014 RDX = 00000000025c5658 RBP = 000000000240ec00 RSI = 000000000260b198 RDI = 0000000002631c78 RSP = 000000000240eac8 R8 = 000000000263d520 R9 = 0000000000000002 R10 = 000000000261dd80 R11 = 000000000240ead0 R12 = 0000000000000030 R13 = 0000000000000004 R14 = 0000000000000000 R15 = 0000000000000001

7ffeb2fec83e) db ed,c3,48,89,5c

Thank you,

I'll revisit it with ints/longs in mind. As you suggested, it may be storage.

Ryan

Is the file TURBOACTIVATE.DLL one that you built from source, or did you obtain it from a vendor?

If the former, you can recompile with the /exp option and look at the assembler instructions in the neighbourhood of the crash.

If the latter, you can use a disassembler on the DLL, but you may need to take up the issue with the vendor.

mecej4, the file is provided by a software licencing company so no chance of decompiling it.

In discussion with them I think what is happening is that the Silverfrost set of compilers handle process level traps for catching / filtering these specific exceptions differently to how they are normally done. The instructions being executed are for the detection of a virtual machine.

It's not to do with the parameter sizes either, they are fixed to uint32_t on 32 and 64. I'll work around it by calling out to an MSVC compiled executable that will pass back the data with a signature to prevent tampering.

They have some more info about how the Delphi compiler handled this (probably the same issue) at https://wyday.com/limelm/help/using-turboactivate-with-delphi/#privileged-instruction but in particular the following statement;

Delphi XE (released 2011) and all newer versions are mis-configured by default. In Delphi, you need to go to 'Tools' menu, click 'Options', and scroll down to the 'Debugger Options → Embarcadero Debuggers → Native OS Exceptions' and change 2 settings. First, under the '32-bit Windows OS Exceptions', change the 'Privileged Instruction' to be handled by 'User program'. Next, under the '64-bit Windows OS Exceptions', again, change the 'Privileged Instruction' to be handled by 'User program':

Thanks anyway, it doesn't appear possible to use this library direct from Silverfrost code in 64 bit.

Ryan

It may be possible to handle this exception from 64 bit SCC code.

I will make enquiries.

That's interesting Paul. Is there a compiler switch I missed?

Not a compile switch but something like the following might work...

#pragma use_at
#include <stddef.h>
#include <stdio.h>
extern 'C' void* TRAP_EXCEPTION@(int& exception, void* routine);

void* handler()
{
  printf('Handled OK\n'); 
  return NULL; 
}
 
int main()
{
   int exception = 11;
   TRAP_EXCEPTION@(exception, handler);
   //Do something that raises the exception.
   return 0;
}

Thank you, only just seen this.