New SSPro Dumper/Solver for MK (+source)
 

This is just a re-post from exetools.

I think my Sentinel SuperPro dumper/solver is now mature enough to release it to the public. Most settings and commands are accessible through the context menu so don't forget to use your right mouse button :)

Here's a list of SSP2MK's v1.2 main features:

• A nice GUI
• Enumerate attached keys without knowing their devid's or search for a particular devid and/or serial number
• Supports dumping via low-level device access or Rainbow's official API.
• Brute-Force WP (only available if the key doesn't have password counters)
• Solve standard and enhanced algorithms
• Supports multi-threaded solving with up to 24 threads
• Import and export of PVA dump files (export might not work with other tools because SSP2MK's dumps may also contain 128 or 256 cells). You can also drag and drop PVA dumps into SSP2MK.
• Various Multikey settings, eg. version, dongle type, emulation mode, ...
• Supports loading Q/R tables
• A small editor to make some final changes to the generated registry settings before saving.
• Log and device list can be saved as txt or csv too
• Full C++ source code included

Here are two screenshots from a previous version (v1.0)
You can get the binaries and its source code from

You can get the binaries and its source code from
[/quote]

4share please

120 view and don't have any thanks very interesting :D

Thanks man.

Where is the thanks button? :eek:
We need it here, now :D
By the way thanks for the tool, cementmixture :D

Dear zementmischer
Thanks for the tool, Good share

@ Sunil

h**p://depositfiles.com/files/4em0b4kl7
h**p://www.4shared.com/rar/WfzLBJrC

It's time for some benchmarking :eek:

Here are my timing results for f1_nodongle, dmp2mkey v2.5.7.9 and SSP2MK v1.2.
The multi-threading implementation of Git's dmp2mkey and my SSP2MK is completely different and not quite comparable. dmp2mkey uses intervals (eg. thread 1 solves the range 0x80000000-0x8FFFFFFF, thread 2 solves 0x90000000-0x9FFFFFFF, ...) whereas my threads increment a global counter value.
Because of this I've created 5 artificial dongles with completely random algorithm cells for testing purposes (see attachment).

All tests were done on a notebook running an entry-level i7 Q920.

Real dongles

• 25CF
  • f1_nodongle: 313s
  • dmp2mkey: 48s
  • SSP2MK: 56s
• FEF6 (contains only enhanced algos):
  • f1_nodongle: 30s
  • dmp2mkey: 60s
  • SSP2MK: 21s
• C2A3:
  • f1_nodongle: 2s
  • dmp2mkey: 2s
  • SSP2MK: 1s
• A870:
  • f1_nodongle: 3s
  • dmp2mkey: 7s
  • SSP2MK: 2s
• 2675:
  • f1_nodongle: 2s
  • dmp2mkey: 3s
  • SSP2MK: 1s

Artificial dongles with 28 random algos

• 8000
  • f1_nodongle: 1393s
  • dmp2mkey: 456s
  • SSP2MK: 251s
• 8001
  • f1_nodongle: 1410s
  • dmp2mkey: 348s
  • SSP2MK: 253s
• 8002
  • f1_nodongle: 1324s
  • dmp2mkey: 231s
  • SSP2MK: 244s
• 8003
  • f1_nodongle: 1273s
  • dmp2mkey: 313s
  • SSP2MK: 229s
• 8004
  • f1_nodongle: 901s
  • dmp2mkey: 412s
  • SSP2MK: 161s

But the most interesting result was an unsolved cell inside dongle 8002 :confused:
None of the tested solvers were able to compute the algorithm descriptor of cell 40 (see spro8002.reg or sproBAAD.reg).

Move on man, even SHK will be obsolete if you don't get to it soon ;)

Git

I'm like an antiparticle and move backwards in time :D
Codemeter -> Matrixlock -> WIBU/BOX -> SSP/ULP -> ... next stop is Microphar

Are you old enough to remember the Amiga dongles?. One resistor in a small box that plugged in the analog joystick port, and represented one fixed joystick position!

Git