Cubase Audio Dongle Clone

[matt]

I have a dongle I'm willing to donate. But it's in storage so I won't get to it for a couple of months.

[exxos]

I'm sure I saw a floppy the other day saying "cubase cracked" ?!

[Dal]

I think most Cubase users would prefer to use an un-cracked version for stability reasons. The whole premise of this thread was to look into whether the hardware dongle could somehow be 100% replicated or preserved.

[dbsys]

I think most Cubase users would prefer to use an un-cracked version for stability reasons. The whole premise of this thread was to look into whether the hardware dongle could somehow be 100% replicated or preserved.

Well said, Dal. I agree.

[edingacic]

so what is the status now can we clone it?

[AmigoMexicano]

I also wanna know the status on this, I hope there are good news!

[Malekko]

If this project ever gets completed i have an SMT facility in Portland Oregon i can run PCBs and assemble them!

[edingacic]

I think this project might be dead ?

[crashman]

Hi,

I've just received a logic analyzer and I'm preparing some cart extender to get the signals from within the cart and the ST.
I know my timings, so it would be long, but I'll try to work on it.
No promises here, not false expectations.I'm just a guy trying to look at it.
I'll post here as soon as I start.

Regards.

[CodeKiller]

Logic analyzer won't help you as the combination logic designed to take too long to brute-force it.

As i said earlier, a non-invasive method would be the side-channel attack (monitoring the power consumption with arbitrary pattern)
Decapping would be even better but requires more tools and destroys the device under test.

[beel1]

You're right, it won't help to clone the PAL but it might help to mimic its behaviour.
Assuming the schematic is this one:
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
2. The PAL outputs will be enabled only during cartridge port readings (ROM Select 3 signal)

Because of 2., a logic analyzer between the ST and the cartridge won't capture the outputs at every UDS cycles, missing a lot of information to help guessing the PAL configuration (I doubt it would be possible with a PAL that big anyway).
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:
- mask all interrupts
- switch a small dongle access routine code with the data at the begining of the RAM (the interrupt vectors table)
- call the routine at the beginning of the RAM with a parameter giving the number of iterations. There are different routines with different initial data
- at each iteration the cartridge port is read but the value is discarded (only the last one is kept) and the address is increased (or decreased, depending on the routine used). There may be up to 64 iterations.
- switch back the dongle access routine code with the data at the begining of the RAM (restoring the interrupts vectors table)
- unmask the interrupts
- use the last value read from the dongle in the protection routine

So I made a software in Omikron inlining those routines' code that writes the last dongle value to disk for each parameter values, making tables.
Then I was able to mimic the dongle in a modified Steem that includes those tables (and writes to trace.txt all accesses to the cartridge port with the number of CPU cycles between them). By using Synthworks under Steem, I can check the trace to see if there are accesses to the dongle that are not covered by the tables.

My goal wasn't to make a clone of the dongle but to run Synthworks in emulator, but maybe the tables can be embbeded in a MCU or programable logic in a cartridge which behaviour would be the same as the original dongle. This wouldn't be an exact copy of the dongle but could be enough to use the protected software.

[havok1919]

You're right, it won't help to clone the PAL but it might help to mimic its behaviour.
Assuming the schematic is this one:
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
2. The PAL outputs will be enabled only during cartridge port readings (ROM Select 3 signal)

Did you create that wiring diagram based off an actual dongle? I'm curious if the part was actually a 10L8? An 'L' series PAL has no internal registers (hence no internal state) and it purely combinatorial-- they're rather easily brute-forced. If it was a 10R8 that'd have (up to) eight registers (one per output cell). Again though, the 10x8 series was pretty old/early tech and I don't know for sure that it even had the ability to do a 'buried' register (that the internal state couldn't be observed).

Newer parts like the 22V10 or early CPLD's had buried node capabilities though.

Still, all this stuff was done in the late 80's/early 90's and the protection wasn't expecting people to have access to incredibly deep (and fast) logic analyzers and ICE, so I suspect it's all pretty vulnerable to just stimulus/observation of results to come up with an equivalent.

[beel1]

Did you create that wiring diagram based off an actual dongle? I'm curious if the part was actually a 10L8?

This is a schematic I found in the forum, not mine: viewtopic.php?p=111369#p111369
The wiring is the same as a dongle I found on the internet: http://www.nightfallcrew.com/19/08/2011 ... -hardware/
(this one: http://www.nightfallcrew.com/wp-content ... G_9830.jpg ) but the chip is a ST's GAL16V8

Unfortunately I cannot open my dongle without totally breaking it...

[havok1919]

Ah, makes sense. Thanks. I'm still just brooding over these dongles. I'm going to have to find/buy some to poke at. As MasterOfGizmo mentioned, it's probably just an LFSR with the data line XOR'ing something in along the way and if the (earlier?) dongles were implemented in 22V10's or 16V8's then there's at most 10 or 8 registers. Along those lines, I don't *think* that you can have a registered macrocell in a 22V10 that's buried (not connected to a pin)-- if that's the case, then the internal state of the registers should be probe-able. (That would seem to be a pretty big vulnerability, so I may be wrong about that, but it might also explain why they'd go to a gate array instead since I can't imagine they were worried about a couple of dollars for the GALs given how much they seemed to spend on everything else...)

Some 22V10 PAL/GALs are also vulnerable to external attack allowing the fuse array to be read, so since the pictures earlier in this thread showed a variety of different manufacturers it's possible that we might get lucky and get a 'weakly' protected GAL used at some point.

[qq1975b]

Hi,

Is there any news about this? It would be great if it is possible to clone these dongles

[edingacic]

looks like its dorment but maybe its being worked on hard

[charles]

I thought the dongle had memory storage on it 128 kb ? held memory mapping addresses?
read that somewhere along the way

[matt]

I have access to my dongles, happy to loan them out, if anybody is still going on this?

[Foxie]

There are a few companies operating out of China who claim to be able to reverse-engineer programming for GALs and MCUs. For example, http://www.break-ic.com/ - I have never used them so no idea if they're reputable.

If suitable funds could be raised, some sacrificial dongles could be sent to such a company for reversing. I'd also hope there would be enough interest reverse-engineering the GALs on the Log3 too. One potential problem - the Log3 uses Altera GALs, which that company doesn't list as being able to reverse-engineer. Whether they have any weaknesses, I don't know.

The Log3 also has an MCU, but I'm reasonably certain it's only used for MIDI output rather than protection. In any case, it's an older MCU which is known to have flawed code protection - so extracting the firmware shouldn't be too much of a challenge. Since that MCU is still available, it should be trivial to build a 1:1 clone of the Log3 if the programming can be extracted.

In parallel to this, I've been doing some work on reverse-engineering the Midex and Unitor. If the reverse-engineering of the dongle succeeds, it might be interesting to implement a combined device. It could provide the functions of Midex and a Cubase/Cubase Audio dongle in one unit. If the Log3 can be cracked too, then a DIP switch could simply switch it into Notator/Logic mode (also providing the functions of Unitor). The only hardware needed would be a small FPGA and some level shifters - or a CPLD and an MCU.

I thought the dongle had memory storage on it 128 kb ? held memory mapping addresses?
read that somewhere along the way

AFAIK, there's no memory in the Cubase dongle - only a GAL. Exactly how and where it maps itself in the cartridge address space I'm not sure. Judging by the design of the Midex, I think it's only using at most half of the address space. The Atari probably needs to write data to it, which it could do in one of two ways. It could just use the address lines as data. Or it could do what Midex does, and "sniff" the data straight from the data bus when it's being written into ST RAM.

[charles]

I think iwould be quicker to just write our own sequencer , you sound confident and competent and I have 15-25 years experience with midi ....

[leech]

I think iwould be quicker to just write our own sequencer , you sound confident and competent and I have 15-25 years experience with midi ....

That would be awesome. New MIDI sequencing software for the ST/TT/Falcon?

[charles]

I have a good many parts written
need help with timing routine

[leech]

Might want to create a new thread for that.

[charles]

I have , everyone says they know how to do it , nobody has ever contributed the material data ...

[nativ]

I think most Cubase users would prefer to use an un-cracked version for stability reasons. The whole premise of this thread was to look into whether the hardware dongle could somehow be 100% replicated or preserved.

Yeh when I finally got a legit cubase 3 I had issues loading in the song files.. some would work.. idea is to resave out asap.. cause there's something amiss in the memory allocation of data and they lock up and crash :/

having some trouble with my legit dongle at the moment! so a solution would be nice... SelDON ( not selTOS )

Cheers

/nativ