Help with Multikey and algo query

[asch75]

Hello; I need some help. I'm trying to use multikey to emulate a SuperPro dongle; running on Windows XP.

I'm using SuperPro Monitor (By chinadragon) while using Multikey. This is the report:
0005 0 AlgoID:1 Query Unit: 0A, Lenth: 4, StringIn: 8DC0970F, StringOut: 8DC0970F
0004 0 AlgoID:1 Read Addr: 09, Value: 0000
0003 0 AlgoID:1 Read Addr: 08, Value: 07FF
0002 0 AlgoID:1 FindFU Dev_ID: 3971
0001 0 Init
\\.\RNBODRV0 12FE9C


Seems that the program queries 8DC0970F and receives 8DC0970F instead of 3AB2C918.
How can i fix this? Anyone can send me query/answer table example?


This is my "homemade" reg file:

REGEDIT4
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\MultiK ey\Dumps\39710000]
"sntMemory"=hex:5C,01,71,39,00,00,4C,CE,F8,BD,00,0 0,00,00,08,00,\
FF,07,00,00,53,E7,A9,01,74,F2,90,52,93,9D,87,6B,\
30,AE,4B,ED,3A,88,43,FF,8F,1A,57,7D,80,FA,10,2A,\
48,EB,39,2A,89,D7,12,A2,8C,FF,26,2B,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,04,5F,F0,70,\
01,01,00,00,01,01,00,00,01,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,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,07,03,07,03,07,03,\
07,03,07,03,07,03,03,03,\
03,03,07,03,03,03,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,00,\
00,00,00,00,00,00,00,00

"Type"=dword:00000000
"DongleType"=dword:00000003

"License"=hex:6a,7f,9f,8d,aa,c9,b5,f1,7d,50,4a,09, 90,16,1d,0c

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\MultiK ey\Dumps\39710000\algo_0A]
"1122334455667788" = hex: 8D,C0,97,0F,3A,B2,C9,18


[HKEY_LOCAL_MACHINE\System\CurrentControlSet\MultiK ey\Dumps\39710000\algo_10]
"1122334455667788" = hex: 3F,B3,5E,5F,40,7C,75,37


thanks!

[kjms]

what dumber&converter are you used??? upload your dump file here..

"CellType"=hex:\
01,01,03,03,03,01,03,01,\
00,00,07,03,07,03,07,03,\
07,03,07,03,07,03,03,03,\
03,03,07,03,03,03,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,00,\
00,00,00,00,00,00,00,00

same thread repeated

[Git]

07 is a correct access code, it means the cell uses AES encryption for the algo.

asch75 - what version of multikey are you using?. The format for fixed Q/R pairs varied at some point in its history.

Git


Git

[zementmischer]

If you want to use q/a tables you must set

"Type"=dword:00000001

Wasn't the syntax for q/a entries something like "query"=hex:reponse, eg.

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\MultiKey\Dumps\39710000\algo_0A]
"8DC0970F" = hex: 3A,B2,C9,18
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\MultiKey\Dumps\39710000\algo_10]
"3FB35E5F" = hex: 40,7C,75,37

[Git]

Correct, but at one time the format was quite different, especially for hasp HL.

Git

[zementmischer]

But I'm pretty sure that

"1122334455667788" = hex: 8D,C0,97,0F,3A,B2,C9,18

has never worked with MK to get the right response 3AB2C918 by querying 8DC0970F

[asch75]

Hi, thanks. I'm using Multikey 19.1.8 x32.
* Changed "Type"=dword:00000001
but still I don't know the correct syntax for the SuperPro q/a algo table.

The Multikey manual says (google translation):
The table format:

if the handle of the algorithm is 0 reg file, then look for data in the table

... MultiKey \ Dumps \ xxxxxxxx \ algo_yy] where yy - number of algorithm

"1122334455667788" = hex: 11,12,13,14,15,16,17,18

We use a simplified table - request a reg file is limited to 8 bytes, ie if the length of
Request transforms more than 8 bytes, the query name in the registry take only the first 8 bytes, the answer is written is full.

[Git]

zementmischer - no, obviously someone has followed an example without reading the manual

asch75 - read the manual

Git

[zementmischer]

Git, you're sort of wrong (or maybe you're sort of right) - he actually used the example from the manual (so, at least asch75 glimpsed at it)

@asch75

We use a simplified table - request a reg file is limited to 8 bytes, ie if the length of
Request transforms more than 8 bytes, the query name in the registry take only the first 8 bytes, the answer is written is full.

This means that only the first 8 bytes of the query are used to distinguish between different q/a.

Just consider the query "CAFEBABEDEADBEEFBAADF00DDEADC0DE"
and its response "FACEFEEDFEE1DEAD8BADF00DDEADFA11".

The query and the response consist of 16 bytes but MK is limited to the first 8 bytes of the query (the response doesn't have this limit for some obvious reasons)

Hence your q/a entry would look like:
"CAFEBABEDEADBEEF"=hex: FA,CE,FE,ED,FE,E1,DE,AD,8B,AD,F0,0D,DE,AD,FA,11

Your query on cell 0A was only 4 bytes in size. Unless your queries are longer than 8 bytes you don't have to worry much about this limitation.

Btw. you can easily test such things by using sproeval which is part of the SSPro SDK!
(or get an older version from hxxp://www.pericosecurity.com/useful-tools-for-working-with-sentinel-hardware-keys.227580-35626.html)

But I'm with you mate, the MK 'manual' leaves much to be desired!!!

[asch75]

First, thanks for trying to help me; and sorry about my poor english.

-Git, I readed the manual.
-zementmischer, I tried your syntax ""CAFEBABEDEADBEEF"=hex: FA,CE,FE,ED,FE,E1,DE,AD,8B,AD,F0,0D,DE,AD,FA,11" with my q/a data with no luck.

Changed "Type"=dword:00000000; with 1 the sentinel monitor didn't show q/a.

I think the q/a table syntax is not clear; maybe is not supported.

My cell: 0A
My lenght: 04
My querie: 8D,C0,97,0F
My answer: 3A,B2,C9,18

Nobody has a Sentinel Superpro Multikey REG file example with q/a?