New SSPro Dumper/Solver for MK (+source)

[zementmischer]

Nice little anecdote, Git
But to answer your question: my first computer was an Amstrad CPC464 with mighty 64kb RAM (only 42kB were actually usable).
I guess this qualifies as being old enough

But back to the topic:
Today I've added a workaround to SSP2MK for those unsolvable cells (see spro8002.reg and sproBAAD.reg).
I won't post it here though because

1. no one has ever reported such a case so there's no demand for a fix. Btw. all reports so far about unsolvable cells were either due to AES cells or ULP dongles.
2. I don't want to waste my time with constantly uploading any stuff. This little project took already longer than planned...

[malicharli]

Thanks.

[Git]

> see spro8002.reg and sproBAAD.reg

I don't see those files ?

Git

[zementmischer]

@Git: you'll find these files inside the attachment 'testdongles.zip'
h**p://www.reteam.org/board/showpost.php?p=33609&postcount=7

[Git]

I used your test case BAAD that you pasted, run on my own emulator. Dumped with Safedump and solved with Dmp2mkey. Same problem. My emulator was mostly independently written. MK author had some of my source but it was mainly UltraPro and Hardlock, so I would be surprised if the problem is emulator based.

Can you share your analysis of the problem please?

Git

[zementmischer]

The decriptor fails because of the two loops inside the enhanced solver:

 for (k = iSig, iIdx = rgwIdx[i], s = 0; k >= 0; --k)                    
{                                                                       
    d = abs(rgwBC[iIdx] - lpwSig[k]);                           
    s += d * d;                                                         
    if (s > 0x4074 || d > 0x57) { k = 1; break; }                       
    iIdx = _rotr16(iIdx ^ 0x1, 1);                                      
    if (iIdx & 0x8000) iIdx ^= j;                                       
}                                                                       
if (k >= 0) continue;                                                   
                                                                        
for (k = iSig + 1, iIdx = rgwIdx[i], s = 0; k < SSP_SIG_TABLE_SIZE; ++k)
{                                                                       
    if (iIdx & 0x8000) iIdx ^= j;                                       
    iIdx = _rotl16(iIdx, 1) ^ 0x1;                                      
    d = abs(rgwBC[iIdx] - lpwSig[k]);                           
    s += d * d;                                                         
    if (s > 0x4074 || d > 0x57) { k = 1; break; }                       
}                                                                       
if (k < SSP_SIG_TABLE_SIZE) continue;

My workaround was to limit the value of d (I masked it with 0x7F). But increasing the values 0x4074 and 0x57 is also an option.
Needless to say that this is just a dirty hack.
The main culprit is probably one of the pre-computed tables.
As a side note, I also recompiled f1__spor.cpp and this solver was able to calculate the descriptor...

[Git]

Where did you find f1__spor.cpp ?

It all boils down to the statistical nature of the solution. I don't think there is anything set in stone on the limits of 16500 and 7569 on s. BTW, you can precalc s = d*d into a table too if you want to scrape a few more nanoseconds out of the loop.

Git

[zementmischer]

I didn't find it, it found me
Git, your memory lets you down - here's also a thread about f1__spor: h**p://www.reteam.org/board/showthread.php?t=1777&page=3

Indeed, the rce'ed f1_nodongle as well as f1__spor use a lookup table to pre-calculate s=d*d but I don't think it's any faster than a simple imul, especially if you take the cache miss into consideration which will definitely happen at the start of the first loop.

Out of curiosity, where did you spotted this value 7569 ?

[Git]

You expect me to remember 2009?!?. I can't remember what happened 10 seconds ago. Seriously, epilepsy plus the effects of anti-epileptic tablets I have to take knock my memory for six. Eg, if I have to copy a 6 digit number from paper to the computer, I have to look back and read then enter 1 digit at a time, as if I try to read 2 digits I have forgotten them by the time I have turned back to the computer. Makes life difficult, but I have much worse health problems than that.

Anyway, I read the thread. Quite sad to see how fluently I could think back then. There is talk about f1__spor and a missing line from the source but I don't see f1__spor.cpp anywhere and I can't find it on my computer. I don't remember ever seeing it, but of course that means nothing!.

7569 = 0x57 ^ 2

Git (I think)

[tiduskg]

Thank you very much for the tool. It was very good, your tool determine ssp with 128 cell and also query cell.
But there is a problem, the tool report that "Failed to initialize SPROMEPS API"? How to solve it?

I have a Sentinel dongle, I was try every tools I have but still no luck.
Git's tool report it only 64 cells, but zementmischer's tool find out it have 128 cells and an enhanced algo cell 78h and solved it. But after all, still no luck.

In license log of software appear "RNBOsproGetKeyInfoEx"? I think dongle using AES tunnel right?

Now, I don't have any idea how to continues.
If Git and zementmischer want to take a look, I will upload USBtrace and relate files.

Thank