View previous topic :: View next topic |
Author |
Message |
Ryan
Joined: 25 Feb 2016 Posts: 110
|
Posted: Sat Jul 06, 2019 6:45 pm Post subject: 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 |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Tue Jul 09, 2019 9:37 am Post subject: |
|
|
Hi Ryan,
Not knowing anything about this I googled and came to the conclusion at first that it must be an OS restriction (guessing Windows 10 might be the source of your problem).
However I continued ....
THIS LINK might (although probaby not) give some pointers, as it were.
In there close to the top is written by one contributor:-
Quote: | "... the cause is probably a corrupted stack or a messed up function pointer call.
This sort of thing usually happens when using function pointers that point to invalid data. It can also happen if you have code that trashes your return stack. It can sometimes be quite tricky to track these sort of bugs down because they usually are hard to reproduce." |
Then there was:-
Quote: | "A privileged instruction is an IA-32 instruction that is only allowed to be executed in Ring-0 (i.e. kernel mode). If you're hitting this in userspace, you've either got a really old EXE, or a corrupted binary." |
For more about 'Ring-O' try TRY READING AND UNDERSTANDING THIS (if you dare ! )
but finally there was revealed the reason for the message:-
Quote: | As I suspected it was something silly that I did. I think I solved this twice as fast because of some of the clues in comments in the messages above. Thanks to those especially those who pointed to something early in the app overwriting the stack. I actually found several answer here more useful that the post I have marked as answering the question as they clued and queued me as to where to look, though I think it best sums up the answer.
As it turned out I had just added a button that went over the maximum size of an array holding some tool bar button information (which was on the stack). I had forgotten that |
(My) Conclusion - (once again) programming is sometimes like navigating our way through a minefield.
If you're lucky you get a few minor scratches which will heal, in the worst case scenario you find yourself quickly (self-)sectioned and ready to tear up the nearest water funtain (fossett) to escape
There ya go, something to start with anyway. Good Luck !!! _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
Back to top |
|
|
Ryan
Joined: 25 Feb 2016 Posts: 110
|
Posted: Tue Jul 09, 2019 9:57 am Post subject: |
|
|
Thank you,
I'll revisit it with ints/longs in mind. As you suggested, it may be storage.
Ryan |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Tue Jul 09, 2019 12:58 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
Ryan
Joined: 25 Feb 2016 Posts: 110
|
Posted: Sat Jul 13, 2019 1:55 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Sat Jul 13, 2019 2:25 pm Post subject: |
|
|
Ryan
It may be possible to handle this exception from 64 bit SCC code.
I will make enquiries. |
|
Back to top |
|
|
Ryan
Joined: 25 Feb 2016 Posts: 110
|
Posted: Sat Jul 13, 2019 6:40 pm Post subject: |
|
|
That's interesting Paul. Is there a compiler switch I missed? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Mon Jul 15, 2019 11:03 am Post subject: |
|
|
Not a compile switch but something like the following might work...
Code: | #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;
} |
|
|
Back to top |
|
|
Ryan
Joined: 25 Feb 2016 Posts: 110
|
Posted: Sun Jul 21, 2019 4:43 pm Post subject: |
|
|
Thank you, only just seen this. |
|
Back to top |
|
|
|