A while back, I used the old tutorials posted by CrackZ and others to crack an old Sentinel SuperPro protected program I had. I had the dongle for the program to compare against, so this wasn't much of a challenge. I mainly was interested in using it as a vehicle for learning how to crack a dongle protected program. I now want to try the same thing from the other end. I want to try using this same program to learn what is going on inside the dongle. I'm hoping someone can evaluate my strategy for investigating the dongle protocol and comment on whether they feel my method is logical, or if I'm going the "long way around the barn".

The program is an old application from about year 2000 and uses the Sentinel driver version 5.38. The dongle is the USB version and so uses the SNTNLUSB driver of the same version. I'm using Ida to step through the program and using SoftIce to handle the drivers. I previously had used Ida on the drivers to create as much of a map as I could. I'm also using a USB bus analyzer to observe the packets going to and from the dongle.

What I am finding is that Sentinel is using a series of vendor defined requests to handle each of its API calls. For example, the FindFirstUnit call results in seven sets of USB packets being transferred to the dongle and then retrieving results. Each packet, of course, consists of 8 data bytes being sent either to or read from the dongle. At this point, however, I have not been able to equate the data contents of the packets to the FindFirstUnit call returning success. Each successive call to FindFirstUnit results in a new set of data being transferred to the dongle (are they being hashed by the current system clock?).

Can someone comment on my strategy of trying to map the various Sentinel API calls to the actual data being sent back and forth to the dongle? Is what I'm seeing consistent with what others have seen with the lower level protocol that Sentinel has developed? If anyone is interested, I can send the various code segments that result in the data transferred. At this point, however, I can't see how this code results in the set of data bytes that are being sent back and forth and this is what I'm tryingt o discover.

Again, I not trying to crack the program, I've already done that. Now I'm trying to learn a little about the inner workings of the drivers and the dongle itself. I chose this program even though it is pretty old since I'm hoping the older driver/dongle will be a bit simpler than the newer devices. Also, since we aren't using the program any more, if I screw up the dongle itself, it is no problem.

Thanks in advance for any assistance anyone can give.

MA700C

Hmmm, 75 views and no comments. Does anyone have any input?

I've spent more time looking into this, but not getting too far. Tracing through the code, I see that it gets down to the following code inside their library:

__stdcall I386SPRO552SPRONETHT(x,x)
_I386SPRO552SPRONETHT@8 proc near ; CODE XREF: I386SPRO552SPRONETHW(x)+81.p

var_4 = dword ptr -4
arg_0 = dword ptr 4
arg_4 = dword ptr 8

sub esp, 4
push esi
push edi
mov esi, [esp+0Ch+arg_4]
mov word ptr [esi+6], 0FFFFh
push esi
callv_I386SPRO552SPRONETHJ@4 ; This call does many loops of data manipulations
lea eax, [esp+0Ch+var_4]
push 0 ; push LPOVERLAPPED
mov ecx, [esp+10h+arg_0]
push eax ; push pointer to bytes read
xor eax, eax
mov edx, [ecx]
mov ax, [esi+2]
push eax ; push number of bytes to read
push esi ; push buffer pointer
push edx ; push handle
call ds:__imp__ReadFile@20 ; __declspec(dllimport) ReadFile(x,x,x,x,x)
mov edi, eax ; Call to ReadFile results in packets being sent
; to the dongle and the success or error code
; being stored in ApiPacket[6]
push esi
call _I386SPRO552SPRONETHI@4 ; I386SPRO552SPRONETHI(x)
cmp edi, 1
jnz short loc_41D886
cmp word ptr [esi+6], 0FFFFh
jnz short loc_41D88C

loc_41D886: ; CODE XREF: I386SPRO552SPRONETHT(x,x)+3C.j
mov word ptr [esi+6], 23Bh

loc_41D88C: ; CODE XREF: I386SPRO552SPRONETHT(x,x)+44.j
mov ax, [esi+6]
pop edi
pop esi
add esp, 4
retn 8
_I386SPRO552SPRONETHT@8 endp

This function is eventually called by as a result of a number of API calls, for example FormatPacket and FindFirstUnit. The call to "_I386SPRO552SPRONETHJ@4" appears to fill the body of the packet structure with random values (it does many loops of various boolean operations). The "ReadFile" is a read to the device "\.\\RNBODRV0". It overwrites the packet structure area that was filled by the call to "_I386SPRO552SPRONETHJ@4". In the case of a FindFirstUnit call, there will be multiple calls to this function and the final one will result in communication to the USB dongle.

Some specific questions:

1) Does someone have a full description of the Sentinel packet? It is about 0x0404 bytes in length, but can't determine what all areas are used for.

2) Why would the library fill up the packet with what appears to be random values prior to the call to ReadFile?

3) Since this is in the library, it must be generic Sentinel routine and not customized for the specific application. Is that correct?

4) Does anyone have a better approach to trying to understand the library/driver/dongle protocol than the brute force method I appear to be using?

Any assistance would be appreciated.

Thanks,

MA700C