Get your Authorization code of V5.1 and plugins from the HD

[doktor1360]

Dear All,

The .key is just a registry file that contains ONLY the authorization CODE. There is no program in this file. The OS checks if the KEY tally with the ESN etc. In fact as DOK said it is created when you input the authorization key for the first time. The mystery is in the rs422.dll file which the Mackie OSv5 calls just before it finishes loading the OS. As i said before the V3 does not have the rs422.dll file. It simply does not exist in the FREE V3

I'm gonna look into this DLL issue... I may need to find a Windoze machine to get a look-see at the function imports/exports. That could say a lot regarding what the operating system does at a low level regarding the authorization process.

In theory, any DLL can be loaded up in a HEX editor and manipulated - but you'd need to know the how's, what's, where's n why's to get a real grasp of the overall functionality of the library and it's implementation - how it works and what exactly that it's doing. There's a lot of variables, but I don't give up easily... if at all...

Stay tuned...

Peace

[bitSync]

This is cool.

[Carlo]

I don't understand but hey, that's not unusual.

Peter

It's all Good, Peter... I answered my own question, actually...

The .key files ARE indeed plain text files, 12-bytes in length - the size of the 3 four digit hex codes used for the authorization unlocks. Imagine that... *winks-grins* I looked at a couple of the plugin .key files on my running 3.0 installation, and verified the file format for that extension AND the contents...

Here's what I'm gonna do in the next day or three; I've already created an rs422.key file with my 'failing' authorization unlock code. I'm gonna mount the 5.1 CF card in Linux, and essentially copy that .key file to the /system5/drivers/rs422 directory. Then install that CF card in my D8B, put on a Welders Mask and boot the console/cpu...

We'll see... I'm not gonna get overly excited with any of this until I beat the hell out of this path to determine if 'The Fix' for the heinously scorned Authorization Unlock Code issue is near... stay tuned...

Peace

My rs422.key contains the failing code DOK and it still asks for authorization.......

HOPE you will manage.

Namaste, Carlo!

I'm gonna go about this just to 'prove it' to myself - no disrespect to your efforts! I'm kinda 'from Missouri' so to speak, I need a 'show me' do-it-yourself execution in order to satisfy my own arcane curiosity in all this...

Thanx, Brutha... RESPECT!!!

\m/ ,,,

No Prob DOK....i will do the same

\m/

[maxcz]

Hi!
Great findings!
From the naming of the DLL (RS422 is the protocol used on the serial communications link to the console) I would deduct that it handless all the communications functions. This might explain why it is called early and often. The actual key checking functions might be hidden elsewhere in the code.
Did you try hiding the dll away by renaming it and see what the OS does then?

[Carlo]

It will not work.....Blank screen just before it finishes loading.....

[doktor1360]

Hi!
Great findings!
From the naming of the DLL (RS422 is the protocol used on the serial communications link to the console) I would deduct that it handless all the communications functions. This might explain why it is called early and often. The actual key checking functions might be hidden elsewhere in the code.
Did you try hiding the dll away by renaming it and see what the OS does then?

I disassembled the DLL, and took a cursory look at the byte code (assembler) and it's pretty busy, however I can see what it's doing per se by simply following the entry point source. The DLL code base calls quite a few subroutine processes that aren't native to it's own contained code, meaning only it's referencing other executing OS5.1 modules in memory. There's an iteration going on comparing two register values (edi, ecx)... it's plausible that this loop is checking the unlock code & esn numbers for a match, but it's really difficult to say with 100% confidence...

For Fuck Sake, I really wish the source was available... this would be a done-deal in a matter of hours... {SMFH}

Stay tuned...

Peace

[Carlo]

Apart from that there are loads of JNE values (JUMP If Not Equal)....in the OS5.1 Code. Im not a computer wizard.....but if you look at the OS3 you will not find any calls to the DLL.

[bitSync]

...There's an iteration going on comparing two register values (edi, ecx)... it's plausible that this loop is checking the unlock code & esn numbers for a match, but it's really difficult to say with 100% confidence...

For Fuck Sake, I really wish the source was available... this would be a done-deal in a matter of hours... {SMFH}

Stay tuned...

Peace

Is there a way to determine what value(s) the DLL returns. If it is Boolean, could the DLL be re-written as a 1-line executable to simply produce the winning Boolean number? That is to say, is OS5 looking to the DLL for a complicated result, a number of outputs, or just a go/no-go?

I agree totally about the source code. If Mackie were interested enough, the DLL source code could probably be used to fix/rebuild the OS5 license server.

[doktor1360]

Is there a way to determine what value(s) the DLL returns. If it is Boolean, could the DLL be re-written as a 1-line executable to simply produce the winning Boolean number? That is to say, is OS5 looking to the DLL for a complicated result, a number of outputs, or just a go/no-go?

I agree totally about the source code. If Mackie were interested enough, the DLL source code could probably be used to fix/rebuild the OS5 license server.

All valid questions...

The DLL has 17 native functions in addition to the entry point (mostly likely the main() function for the lib), and without the source it's difficult to say whether any of them are exported, public/private or what. In reality, I'm looking at disassembled code... so it's what the reverse engineering utility can determine based on the DLL byte code (executable) it processed. There were errors loading it, and that's most likely because it's 'standing alone' - I don't have a debugger that'll interface with the console that would give a look-see at what's actually taking place while it's executing in memory. Hell, it's not even really apparent what language was used, but due to the fact it's a DLL it's gonna be either Visual Basic, C/C++ or Delphi... either way, I WANT THIS CODE...

We as a community need this source code, it's the lynch pin at this point. Mackie/Loud Technologies gains nothing by sitting on this and not making it available, or doing something as simply as recompiling it themselves. It's ridiculous, petty, and unprofessional IMHPO...

This isn't over yet...

Peace

[anyhorizon]

I take your point, dok but Mackie want the thing to die. It's a pitiful display of taking their bat and ball and going home. The new boys never expected it to last so long. Anyway, interesting stuff going on here. A bit beyond my station but I'll stay tuned. Fortunately mine is in pristine condition and will provide years of service. Greg and Bob must be congratulated.

Peter