PDA

View Full Version : Removing Sentinel SuperPro from VFP application


ner0
January 27th, 2015, 07:58
Hello,

I need to ask for some help with some reversing I'm trying to achieve.
I used the forum's search function but most topics related try to emulate SuperPro dongles when what I really want to achieve is strip it out or at least bypass it to a degree that the program does not use/decrese the # of available licenses.

I'm trying to find a way to follow an amazing tutorial, by Shub-Nigurrath, on how to remove Sentinel SuperPro from an app (Removing Sentinel SuperPro dongle from Applications.pdf ("https://www.google.com/search?q=Removing%20Sentinel%20SuperPro%20dongle%20from%20Applications.pdf")).
Although I'm a noob reverse-engineer, I try to learn what I can from who I can in order to reach my goal. Unfortunately there is little documentation for my specific case.

So, first off, my main obstacle at this point is that I need to remove Sentinel SuperPro checks from a commercial app that was developed in Visual FoxPro 9. The problem I'm facing is that VFP apps can't really be debugged in a disassembler like traditional C/C++ apps. The signatures won't be useful here, I think, because there is no way to see the SProNet imports/exports in the app.

I was somewhat successful in decompiling the app using ReFox XI and now have access to the source code from there, but I'm not really sure where to go from here. I found most of the app's functions to the SProNet API in the decompiled source code but unfortunately I am not able to recompile the program due to missing dependencies.

One of the options I thought about was to go for the SPro libraries themselves (SXFOXNET.DLL and SXFOXPRO.DLL) which the app uses. If only I could defeat the SproDecrement function so that it never decreases the available license numbers, that would kind of work for now. But this might not be possible without patching a few core anti-tamper calls. As an example, here is sproFormatPacket from both DLLs:
- SXFOXNET.DLL: http://i.imgur.com/EodSmi4.png
- SXFOXPRO.DLL: http://i.imgur.com/INPFJHJ.png

Do you think I can patch the DLLs?
In the tutorial I kind of got the idea that the author was patching the app and not the libraries themselves, now that I think of it maybe I misunderstood that point.


The other approach I thought of is using an executable that the program uses at startup.
This one I was able to decompile and recompile successfully due to being very small and simple.
With it I have access to the same calls that the main program does and what I was trying to do was use the sproReleaseLicense call to, well... release a license before using it. Needless to say that this failed miserably, resulting in the app throwing "invalid packet".


Anyway, I just wanted to know if someone can help me head in the right direction.
If the details I provided are insufficient, I'll gladly provide more, of course.

Thanks.

FoxB
January 27th, 2015, 09:05
You known the developer id for your dongle?

ner0
January 27th, 2015, 09:16
Not yet, no.
I'm trying to with DumpSentinel v0.2 and SentRead.
With DumpSentinel, it's still running through trying to find the DevID.
With SentRead, so far I've got the dongle ID, but that's probably not the same as Developer ID.
Any other tool you would advise to get it straight?

EDIT: Ok, it was taking a bit too long so I went digging in the app's source code and found the DevID.
FoxB, how can this help me particularly?

FoxB
January 27th, 2015, 10:42
You need or tell us the developer id for dongle or share the target software.
Dongle id is dongle data from cell00, developer id is dongle data from cell01

ner0
January 27th, 2015, 10:44
The Developer ID is: XXXX

ner0
January 28th, 2015, 08:10
Previously I mentioned 2 SuperPro DLLs used by the software.
I started by analyzing a bit more in-depth, starting with SXFOXPRO.DLL.
This DLL's structure, namely API's, is very similar to the one presented in the tutorial by Shub-Nigurrath.
Unfortunately, the DLL in question (SXFOXPRO.DLL) is only used by the app for dongle maintenance operations, not for daily licensing usage.

The actual licensing is done through sxfoxnet.dll, but this one has a somewhat different structure than the one presented in Shub-Nigurrath's tutorial, I am unable to match what is explained in the tutorial to it. For example, here is a comparison between sproFormatPacket in the tutorial and in my DLL:

Shub-Nigurrath tutorial sproFormatPacket: http://i.imgur.com/LZH9Y62.png
My DLL (sxfoxnet.dll) sproFormatPacket: http://i.imgur.com/FXC5ZEC.png

Not to mention sproRead in this DLL... if I was out of my depth before, now I'm really drowning just by looking at this sproRead call: http://i.imgur.com/CIqZAGE.png

Anyway, in case anyone is interested in looking at the DLL, here it is:
sxfoxnet.zip ("https://mega.co.nz/#!uwh3magY!vveMp-0drTvHjGEPm8gxjvJ782g4Cm5RgPFiaxsobaA")

Thanks for the suggestions.

FoxB
January 28th, 2015, 10:49
try to dump your dongle/emulator with http://rghost.net/74dLQ59Rm

FoxB
January 28th, 2015, 11:14
try to see at folder with dumper the file with dmp-extension

ner0
January 28th, 2015, 11:21
Unfortunately there is none. No file is created.

I tried this with a similar dongle on another machine (different software) and there it worked, it started trying to brute-force the write password and wrote to disk a file: spro_RNBO_SPN_DRIVER_df3c_0.dmp

It did so even before querying the subnet, but it can't dump it in the machine that has the needed dongle, like i said in my previous reply.
I'm not sure if it's the OS (Windows 2008 Server).

ner0
January 28th, 2015, 11:34
FoxB, I was able to dump with a different software, from one of those websites that sell dongles.
I'm not sure if the dump is usable, in any case here is the tool and dump:


Tool: http://goo.gl/hjMMdO
Dump: https://mega.co.nz/#!qgYyhL6a!y4hlek126LtO0NBH_DNErRRBUbQko3_igsPsCb7mQ-0 (password: www.woodmann.com)


FoxB
January 28th, 2015, 11:50
As you wish

ner0
January 28th, 2015, 11:56
This is a registry key for an emulator, right?
Which emulator would be appropriate for this, Sentinel Emu 2007 by EDGE?

Thanks.

AH! Multikey... let's try.

ner0
January 28th, 2015, 13:29
Maybe I'm missing something but I can't get it to work.
I'm testing this with a Windows XP virtual machine and here's what I've done:
1. Installed Multikey v19.1.8 (32-bit);
2. Rebooted;
3. Checked Device Manager and found Virtual USB Multikey;
4. Added the registry key from the post above to Windows registry;
5. Installed Sentinel Protection drivers v7.4.0;
6. Rebooted;
7. Software does not detect either SuperPro nor SuperProNet dongle;

What am I missing here?


EDIT: Problem was the Multikey version apparently, v18.2.4 works.

ner0
January 28th, 2015, 14:04
Apparently the emulator is not completely successful in emulating everything, like sub-licenses.
For example, upon validating the dongle, the software asks the user to select what software functions the user wants to enable. Each of those software functions, if enabled, use a sub-license. With the emulator, if more than one function is enabled, the program will refuse to give access to that part of the software leaving the user restricted to only one basic function per session.

I had run into this trouble in the past using EDGE's Sentinel Emu 2007, that's why I was skeptical of using an emulator now.
Unfortunately it turns out that the emulator can't really suit this particular need.

FoxB, if it's not too much to ask, could you mask the dongle ID bytes, please?
Thank you

ner0
January 29th, 2015, 19:21
FoxB, thanks.
Coming back to the emulator issue... I notice that by using the emulator the hard limit is 1 whereas with the dongle the hard limit is 65535.
Is that the reason why the software fails to use other functions that use additional licences/processes?
I am unsure if there is a workaround with the emulator.

EDIT: Eventually I found a way to extend the hard limit which completely solves the emulation problem!

I'll leave here an example in case it helps somebody else.
Using a Multikey registry dump, here's what it looks like:

Quote:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Multikey\Dumps\XXXX0000]
"sntMemory"=hex:\
YY,YY,XX,XX,00,00,00,00,00,00,FF,FF,00,00,00,00,\
00,00,00,00,00,00,A9,3C,4F,06,DA,03,9F,AB,C4,3D,\
F1,C2,49,56,00,00,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,AC,31,00,00,\
45,24,13,00,05,00,05,00,05,00,03,00,01,00,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,00,00,42,34,00,00,00,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
"CellType"=hex:\
01,01,03,03,03,01,03,01,00,00,00,01,01,01,01,01,\
01,01,01,01,01,01,01,01,01,01,01,01,01,01,01,00,\
01,01,01,01,01,01,01,01,01,01,01,01,01,01,01,01,\
01,01,01,01,00,00,00,00,00,00,00,00,00,00,00,00
"Type"=dword:00000000
"DongleType"=dword:00000003


So, the XXXX or the XX,XX are both the DevID for the dongle and the YY,YY is the dongle serial.
What changes the hard limit is the FF,FF you see in positions/bytes 11 and 12, the first couple FF alone set the limit to 255 and the second couple FF alone set the limit to 65280, if both are set to FF, then the limit becomes the sum of the two: 65535

The first group of bytes are interpreted as a normal number from 0 to 255 (00 to FF), the second group is interpreted as a multiplication by 255 of whatever value is set. Or something along those lines anyway...

Hope it helps, and thanks again to FoxB!

FoxB
January 30th, 2015, 05:30
you are right - cell05 is hard limit

ps: if you want to safe your serial number/devid - delete your spoiler #10

ner0
January 30th, 2015, 05:58
Quote:
[Originally Posted by FoxB;96875]you are right - cell05 is hard limit

ps: if you want to safe your serial number/devid - delete your spoiler #10


eheh thanks, but the link is dead since it wasn't useful to anyone else.