please help me convert ssp722.bin to *.reg

[luoge]

i have ssp722.bin file dump by sentinel superPro dongle and
I want to convert to *.reg file for VUSB emulation.
can anyboby convert *.reg to me.
thanks

flie:
http://rapidshare.com/files/260889178/ssp722.bin.html

[Git]

Use the Search luoge. Look for MultiKey emulator and Dmp2Mkey solver.

Git

[BfoX]

3 algo
cell 0e enh. algo Cell_0e = fade Cell_0f = c000 C6 = 8951
cell 10 enh. algo Cell_10 = cafe Cell_11 = c000 C6 = 8951
cell 12 enh. algo Cell_12 = dabb Cell_13 = c000 C6 = 8951

[alphasxb]

first you should search in the forum
then you can get what you want

many people can do it !

but if you can't
send me a valid link , i can help you

[luoge]

I search the forum but did not find a tool for *.bin to *.reg
and I tried dmp2mkey but will not work.

I fix the link:
http://rapidshare.com/files/260889178/ssp722.bin.html

Who can help me to convert the format *.reg
Thanks

i used dump tools (safeNet dongle dumper)
http://rapidshare.com/files/260908772/safenet_dmp.rar.html

[gazsan]

you can use this tools


http://rapidshare.com/files/260923636/Sentinel_Tools_GAZ.zip.html

if u can dump your dongle to dmp format (with pva dumper) and convert it to reg it's easy and better.


also u can see at this post:
http://www.reteam.org/board/showthread.php?t=1042


regards

[Git]

Try this. Save the 'code' as 77120000.reg. I don't know why, but the version of sp0raw .bin to ssp converter I have solves different values for the algo constructors. In each case. bit 24 is 0 in the solutions I get, and 1 in BFox solutions, so you know what to try if it doesn't work.

If you had persevered with the search and found out how to do it yourself, you would have gained knowledge and know how to do it again. Now, you will just have to ask again next time. Which is better?


Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\MultiK ey\Dumps\77120000]
"DongleType"=dword:00000003
"Copyright"="None"
"Created"="Tue Jul 28 11:23:49.311 2009"
"Name"="7712 Sentinel SuperPro Dump"
"Type"=dword:00000000
"CellType"=hex:\
01,01,03,03,03,03,03,03,\
01,01,01,01,00,00,03,03,\
03,03,03,03,01,00,01,00,\
00,00,00,00,00,00,00,00,\
01,01,01,01,01,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
"sntMemory"=hex:\
49,07,12,77,00,00,00,00,5B,EC,00,00,51,89,00,00,\
53,41,45,31,CD,15,31,41,C2,00,00,00,DE,7A,00,C0,\
FE,4A,00,C0,BB,5A,00,C0,FF,FF,00,00,FF,FF,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
02,00,F1,7C,BF,36,F1,7C,BF,36,F1,7C,BF,36,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,00,00,00,00,00,00,00,00,00,00,00,00



and BFox solution :

"sntMemory"=hex:\
49,07,12,77,00,00,00,00,5B,EC,00,00,51,89,00,00,\
53,41,45,31,CD,15,31,41,C2,00,00,00,DE,FA,00,C0,\
FE,CA,00,C0,BB,DA,00,C0,FF,FF,00,00,FF,FF,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
02,00,F1,7C,BF,36,F1,7C,BF,36,F1,7C,BF,36,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,00,00,00,00,00,00,00,00,00,00,00,00


Git

[kiki]

and i get this from my computer

"sntMemory"=hex:\
49,07,12,77,00,00,00,00,5B,EC,00,00,51,89,00,00,\
53,41,45,31,CD,15,31,41,C2,00,00,00,DE,FA,00,C0,\
FE,CA,00,C0,BB,DA,00,C0,FF,FF,00,00,FF,FF,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
02,00,F1,7C,BF,36,F1,7C,BF,36,F1,7C,BF,36,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,00,00,00,00,00,00,00,00,00,00,00,00

[Git]

kiki - Something strange is happening with one version of f1__spor (if that is what you are using). I have both a PVA *.dmp and a Sp0raw *.bin for one dongle so I tested f1_spor on that and I get the same descriptors as I get from the pva dmp.

Can I have a look at whatever solver you used please so I can try the same test?.

Git

[Klopschik]

multikey doesnt work with my 2 dumps (i changed serial from key to FFFF), with gambit release it works but I need solution for 64 bit multikey.

155

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\MultiK ey\Dumps\EA6E0000]
"DongleType"=dword:00000003
"Copyright"="Git"
"Created"="Mon Jul 27 13:38:16.203 2009"
"Name"="EA6E Sentinel SuperPro Dump"
"Type"=dword:00000000
"CellType"=hex:\
01,01,03,03,03,03,03,03,03,03,03,03,03,03,03,03,\
01,01,01,01,00,00,00,00,01,03,03,02,03,03,03,03,\
03,03,03,03,03,03,03,03,01,01,01,01,01,01,00,00,\
03,03,02,02,03,03,03,03,02,02,02,02,02,02,02,02
"sntMemory"=hex:\
FF,FF,6E,EA,1D,AD,00,00,1D,AD,00,00,4A,94,00,00,\
A4,63,C3,D4,74,06,E4,DE,74,86,E4,DE,00,00,00,00,\
CE,CF,C9,C9,CE,CE,FF,FF,51,70,00,00,00,00,00,00,\
06,00,00,00,00,00,02,00,74,86,E4,DE,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
71,C8,70,72,46,48,31,44,44,39,00,33,D9,AC,66,4A,\
00,00,00,00,01,00,C8,00,BF,68,3B,F1,88,05,97,97,\
63,00,63,00,63,00,63,00,00,01,00,01,00,01,00,01

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\MultiK ey\Dumps\EA6E0001]
"DongleType"=dword:00000003
"Copyright"="Git"
"Created"="Mon Jul 27 14:58:48.437 2009"
"Name"="EA6E Sentinel SuperPro Dump"
"Type"=dword:00000000
"CellType"=hex:\
01,01,03,03,03,03,03,03,03,03,03,03,03,03,03,03,\
01,01,01,01,00,00,00,00,01,03,03,02,03,03,03,03,\
03,03,03,03,03,03,03,03,01,01,01,01,01,01,00,00,\
03,03,02,02,03,03,03,03,02,02,02,02,02,02,02,02
"sntMemory"=hex:\
FF,FF,6E,EA,1D,AD,00,00,1D,AD,00,00,4A,94,00,00,\
A4,63,C3,D4,74,06,E4,DE,74,86,E4,DE,00,00,00,00,\
CE,CF,C9,CA,CE,CF,FF,FF,28,09,00,00,00,00,00,00,\
06,00,00,00,00,00,02,00,74,86,E4,DE,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
91,CA,DE,6C,46,48,31,44,36,39,00,45,B9,D9,56,4A,\
00,00,00,00,01,00,C8,00,BF,68,3B,F1,88,05,97,97,\
63,00,63,00,63,00,63,00,00,01,00,01,00,01,00,01

With gamebit release and toros monitor i get this:

http://img512.imageshack.us/img512/8573/gamebit.th.jpg (http://img512.imageshack.us/i/gamebit.jpg/)

and with multikey i get this:

http://img166.imageshack.us/img166/2382/multikey.th.jpg (http://img166.imageshack.us/i/multikey.jpg/)

can anyone please check what the problem is.

[foffa]

very strange

looking for 2 different devid after all that querys
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[kiki]

Can I have a look at whatever solver you used please so I can try the same test?.
Git
I use f1__spor, to solve it

[Git]

Klop : Was this meant to be a new thread?. BTW, dunno if it's my browser, but your pictures are 150x111 and are unreadable. As for the problem, your dumps are incorrect or corrupt. The algo on cell 0x08 has problems. Also, you have run into bad luck on cell 0x0C. The statistical function that decides if the dump data is from an Enhanced or Simple algo can, by virtue of being statistical, sometimes get it wrong. The only recourse is to take another dump and try again and if that doesn't work you have to find the descriptor of the awkward cell by brute force. I have tested the dump with 3 different solvers, and all have problems on those cells.


Kiki : yes, that is what I used.

f1__spor.exe 208,939 bytes, dated 07 OCT 2007, CRC 0x22257B18

If yours is different can you get a copy to me please?

Git

[Klopschik]

@Git
Please click on 900x575 below the pictures

Why does it work with gamebit release?

I will try with new dump.

Klop

[Git]

Even random numbers stand a chance of working. Maybe the app just has not used the bad cells yet, but I assure you there is a problem. You must have seen the message from the solver about Inactive cell?. Also, all solvers show solving Simple algowhen solving the third algo, yet resulatnt Descriptor is 0XDEE48674. Descriptors in the range 0xC0000000 to 0xFFFFFFFF are Enhanced algos, Descriptors in the range 0x80000000 to 0xBFFFFFFF are Simple algos. So it is wrong.

Git

[kiki]

f1__spor.exe 208,939 bytes, dated 07 OCT 2007, CRC 0x22257B18
f1__spor 71680 bytes, date january 14 2007, crc 0xb0b50352,
this is same as you upload here.

[Git]

aha, yes, bopoh gave us the link to an archive with that and others in it. Don't think I uploaded it, but any thing is possible with my memory.

f1__spor 71680 bytes, date january 14 2007, crc 0xb0b50352
3 algo
cell 0e enh. algo Cell_0e = fade Cell_0f = c000 C6 = 8951
cell 10 enh. algo Cell_10 = cafe Cell_11 = c000 C6 = 8951
cell 12 enh. algo Cell_12 = dabb Cell_13 = c000 C6 = 8951
file 7712.ssp is created. Total time=33 Press any key.


f1__spor.exe 208,939 bytes, dated 07 OCT 2007, CRC 0x22257B18
** Total 3 algoes
WP=EC5B
cell 0e enh. algo
**** Cell_0e = 7ade Cell_0f = c000 C6 = 8951
cell 10 enh. algo
****** Cell_10 = 4afe Cell_11 = c000 C6 = 8951
cell 12 enh. algo
* Cell_12 = 5abb Cell_13 = c000 C6 = 8951
file 7712.ssp is created. Press any key.

One of them is probably correct...

Git

[kiki]

f1__spor.exe 208,939 bytes, dated 07 OCT 2007, CRC 0x22257B18

@Git:
would you give me a copy of this version? i'll try it with my other dump and compare the result.

@BOPOH:
I ask your permission too :)

thanks
kiki

[ngoksun]

aha, yes, bopoh gave us the link to an archive with that and others in it. Don't think I uploaded it, but any thing is possible with my memory.

f1__spor 71680 bytes, date january 14 2007, crc 0xb0b50352
3 algo
cell 0e enh. algo Cell_0e = fade Cell_0f = c000 C6 = 8951
cell 10 enh. algo Cell_10 = cafe Cell_11 = c000 C6 = 8951
cell 12 enh. algo Cell_12 = dabb Cell_13 = c000 C6 = 8951
file 7712.ssp is created. Total time=33 Press any key.


f1__spor.exe 208,939 bytes, dated 07 OCT 2007, CRC 0x22257B18
** Total 3 algoes
WP=EC5B
cell 0e enh. algo
**** Cell_0e = 7ade Cell_0f = c000 C6 = 8951
cell 10 enh. algo
****** Cell_10 = 4afe Cell_11 = c000 C6 = 8951
cell 12 enh. algo
* Cell_12 = 5abb Cell_13 = c000 C6 = 8951
file 7712.ssp is created. Press any key.

One of them is probably correct...

Git
@Git, the crc 0xb0b50352 f1__spro result is correct and the crc 0x22257B18 f1__spro result have little bug.
The root cause was somebody distribute the f1__spro source code and delete one line of the code. You need add:
if (!(Descriptor & 0x3C000000)) Descriptor |= 0x00008000;
to LFSR_96 sub-function then it should work correct.

[smithjsmi]

@Git, the crc 0xb0b50352 f1__spro result is correct and the crc 0x22257B18 f1__spro result have little bug.
The root cause was somebody distrubute the f1__spro source code and delete one line of the code. You need add:
if (!(Descriptor & 0x3C000000)) Descriptor |= 0x00008000;
to LFSR_96 subroute then it should work correct.

you have the corrected f1_spor with problem solved?

[BOPOH]

if (!(Descriptor & 0x3C000000)) Descriptor |= 0x00008000;
to LFSR_96 sub-function then it should work correct.

It is for safekey emulator only
For multikey all results are correct.

[Git]

The root cause was somebody distribute the f1__spro source code and delete one line of the code

Thanks Koo. If it was done deliberately and without telling people a line was missing, then it was a thoroughly nasty thing to do!. Even nastier is that somebody then compiled the wrong source and distributed the faulty binary under the same name as the original.

Git

[ngoksun]

@BOPOH, thanks for your kindly info. I just test this years ago but haven't see what details changed between safekey and Multikey algos. Could you help to finger out it? I'm not doubt what your info but just want to know how to improve the algos at emulator because you are all f1__xxx solver's ower. Thanks!
@Git, sure this behavior was thoroughly nasty but don't care about it, you know, there is so many nasty at DONGS scene but not all people is righteous like you. Actually, no fish if the water is too clear.:) I had see more than 3 version of this type solver but only the original one that from tch2000 (BOPOH) is perfect.

[luoge]

f1__spor 71680 bytes, date january 14 2007, crc 0xb0b50352
this version of the conversion data is correct?

[rooky2000]

f1__spor 71680 bytes, date january 14 2007, crc 0xb0b50352
this version of the conversion data is correct?

yes,I have tested it

[Git]

Koo - I most definitely am not righteous and I am sure nothing in this world is perfect :)

luoge - that version is the original.

GIt