exxos wrote: 17 May 2020 01:18
I would assume cubase has a serial number which would match the same number in the gal ? Then it would output some sequence to say yes or no back to cubase. Though the gal probably couldn't process many bits anyway.
It would have been very simple to patch the software then :D
In Synthworks, the result outputed by the cartridge is used as an offset in jumps. The jump goes to pieces of code that looked garbage in the disassembler or the debugger because of unaligned instructions. With the correct offset the software keeps running, otherwise it crashes badly.
A check is performed at the program startup to ensure that the dongle is OK. This part would be easy to patch. But then the dongle is still accessed in numerous parts of the code to compute jumps offsets and there is no warning in case of a wrong result, because there is nothing to compare with. :D
terriblefire wrote: 17 May 2020 08:21
Its not quite this simple. A PAL can keep state based on previous inputs clocked into D type flip flops internally. Maybe it doesnt do this, maybe it does but it has that capability.
This I don't understand. I have limited experience with GALs, but I don't see how a state can be kept without it at least using an output register. Please help me out.
(So far my assumption is that there are 65536 possible states resulting in 256 possible outputs when the PAL is clocked. This would be possible to brute force)
beel1 wrote: 16 May 2020 23:13
I made a few posts about my findings on a Synthworks dongle in AF a few years ago.
Am I reading that correctly in that you succeeded?
troed wrote: 17 May 2020 08:46
This I don't understand. I have limited experience with GALs, but I don't see how a state can be kept without it at least using an output register. Please help me out.
/Troed
In ABEL you just declare as
SIGTYPEsignalname REG;
instead of
SIGTYPE signalname REG OUT;
You dont need the OUT but i think internal registers are limited *and* may not be there on all PALs.
But even if they are only using the OUT registers.. Those registers can feed the inputs of the next state internally.
———
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
A PAL16R8 has no internal (hidden) registers. All registers are observable on the respective output pins if you force /OE to low. So you can know what is fed back into the logic array.
Still, it is not straightforward to brute-force by applying all possible inputs, simply because you cannot directly control all inputs to the logic array. Consider this made-up example of state machine that is perfectly possible in a PAL. You can control the inputs and you can observe the outputs and thus the states. However, you don't know which input to apply to get into the next state. If you apply the wrong input, this made-up state machine locks up and requires a power cycle before you can try again, starting at state 0. Therefore, simply trying different inputs will take a long time. It certainly could be made more complex still.
states.PNG
You do not have the required permissions to view the files attached to this post.
czietz wrote: 17 May 2020 09:10However, you don't know which input to apply to get into the next state. If you apply the wrong input, this made-up state machine locks up and requires a power cycle before you can try again
Ah, ok. Yeah that's valid, I'll need to ponder that. I'm also assuming that simply clicking around a few times within Avalon observing the data will be futile in that I will never know if I've caught all instances of checks being done.
troed wrote: 17 May 2020 08:46
Am I reading that correctly in that you succeeded?
/Troed
Indeed :D
The problem is: I don't have the synth anymore to check that I covered all paths (and Korg Collection doesn't support Sysex :( ), but everything I was able to test was OK, and Steem log confirmed that the dongle was accessed.
I don't know if what I did can be applicable to Avalon, but enclosed are the pictures of my dongle (it won't help to get the chip used! )
You do not have the required permissions to view the files attached to this post.
beel1 wrote: 17 May 2020 08:39
It would have been very simple to patch the software then :D
In Synthworks, the result outputed by the cartridge is used as an offset in jumps. The jump goes to pieces of code that looked garbage in the disassembler or the debugger because of unaligned instructions. With the correct offset the software keeps running, otherwise it crashes badly.
A check is performed at the program startup to ensure that the dongle is OK. This part would be easy to patch. But then the dongle is still accessed in numerous parts of the code to compute jumps offsets and there is no warning in case of a wrong result, because there is nothing to compare with. :D
Interesting. Has anyone debugged the software when it access the dongle to see where code starts and ends after accessing it ?
Maybe the dongle is being used as a adder.. Like adds 5 each time to whatever number is sent to it.. Of course it would get massively complicated if the internal count in the gal wasn't cleared after each access. As if we sent number 2 and added 5, we would get 7. But if we sent 7 next time and added 5 plus the result of the previous calculation, we would get 2+7+5=14.. Now that would need to be taken into account with cubase software...in this case a brute force attack might not work ?
Amazing! You did years ago what I still thought nobody had. From the picture it seems Steinberg used the same method (just different equations) for all their dongle protected products. Your experience then caps the expectations on how problematic this will be.
Afaik you should go into the history books of crackers as the first to "clone" their dongles for emulator usage. I'll just replicate it for additional ones.
@beel1: BTW, considering what you wrote in the AF thread...
1. The PAL is clocked by the UDS signal, which toggles even if there is no activity on the cartridge port, inputing address bus data to the PAL
[...]
But what I found during my experiments with Synthworks dongle almost 2 years ago is that because of 1., the software has to be very specific to access to the dongle using always the same pattern:
... it makes sense that the Avalon handbook notes that on the MegaSTE it only runs when the cache is disabled. With enabled cache, there are fewer bus accesses (asserting /UDS) and, therefore, the dongle behaves differently.
If it would help - I have Synthworks dongles for the Yamaha DX & Korg M1 (as well as Cubase 3 & Avalon) so I might be able to set them up with my synths & compare operation with & without a dongle?
It may take a period of time to get the results but happy to help where/when time allows.
