Forum (#19736) - Plus/4 World



	Home Search Games Tapes Covers Cheats Maps Software New Stuff Hall Of Fame HVTC Game Endings Solutions Remakes Publications Magazines Effects Top List Members Groups Features Plus/4 Encyclopedia Hardware Tools Options Forum Home Search Games Tapes Covers Cheats Maps Software New Stuff Hall Of Fame HVTC Game Endings Solutions Remakes Publications Magazines Effects Top List Members Groups Features Plus/4 Encyclopedia Hardware Tools Options Forum	Login

Back to forum

Reply to this topic

Go to last reply

Posted By

Csabo
on 2010-06-08
09:21:37

AustroSimple

Shortly after the news of AustroSpeed being decompiled comes something even more exciting. MikeZ has figured out pretty much all the mysteries of the Austro protection. Intrigued? Read on!

The original Austro had a copy protection "dongle" that plugged into the user port. As soon as the first menu appeared and the user selected drive configurations, Austro did a GOSUB to a dongle reading routine. It PEEKed at FD1X, looking for the bit setting of the dongle. If it was not found, then the first Austro menu repeated forever.

RAVEN created the wedge to insert a JMP $0353 in the Austro run-time interpreter (RTI) in the place where above PEEK is done. This way he could emulate the correct dongle setting and the program would advance to the second menu. This worked, but the approach is flawed. Austro copies its own run-time into whatever C/PRG it compiles. Thus every compiled program carried that JMP $0353 code!

Here's where SVS' wedger comes in. It adds the code to the compiled programs so that when they do jump to $0353, there's valid code there. Until now, it's been said that this wedger is not always necessary, but no one knew why...

The reason that the wedge is only necessary sometimes in a C/PRG is because the said jump is in the PEEK execution. If you
don't use PEEK, then you shouldn't need the wedge! So far no other places have been found, likely this is the only one.

MikeZ continues:

"Now, I was able to see all this because I have my decompiled austroBASIC to look at. RAVEN must have somehow decompiled the dongle GOSUB in order to create the wedge. But I don't think he ever saw what I will now tell. If he did see it, why bother with the wedge?

I studied the dongle GOSUB further and I discovered that the decomp prg I used could not decomp the first byte of the dongle GOSUB. It REM'd it so the decompilation would continue.

The mysterious byte is $3A, which is a legal P-Code that has no BASIC keyword/token equivalent. It has an executable location in the Austro RTI, and its function is basically the same as "NOP" in ML. It came to me to just substitute the P-Code "1D" - RETURN - for the "3A". This immediately bypassed the dongle check!

No need for the crack wedge, no need for the corrupted RTI within every C/PRG produced all these years. I removed the JMP $0353 from the RTI and at Austro P-Code location $4EE0 replaced "3A" with "1D" and we now have a clean and free and compiled AUSTROSIMPLE!"

Well, there you have it. If you're itching to give this a try, just head on to the Austrospeed Compiler page to find the download. Keep in mind that this is in Beta stage. It would be helpful if others could test this as well, so give it a try. Kudos to MikeZ for this amazing discovery!

Posted By

MikeZ
on 2010-06-09
09:21:37

AustroSIMPLE

I've tested this version of austro without the wedge, etc and have good results. But SVS reports that his CALC prg has many string variable problems with this wedge-less version of austro.

Please give feedback if you try it and find other problems.

MikeZ

Posted By

Csabo
on 2010-06-09
11:05:58

Re: AustroSimple

I only did a simple test last night. I wrote a quick basic program with some prints and peeks, then compiled it with AustroSpeed and AustroSimple. As expected, the first version crashed, the second worked fine.

From SVS is experiencing it looks like the problem is a bit more complex. I wonder if he did a byte comparison... Shouldn't the two compiled programs be identical, with the exception of the changes in the run-time interpreter?

Posted By

MikeZ
on 2010-06-09
15:36:51

Re: AustroSimple

Austro stores its strings at the top of High RAM. The string's variable storage location only gives the address in High RAM where the string physically is. RAVEN's hack deleted a STA FF3F and I may not have replaced it. This could affect string fetching. I'm checking.

Posted By

SVS
on 2010-06-10
02:18:25

Re: AustroSimple

I have repeated my test, with complete procedure. Result is very good: the whole beta SVS-Calc works as well (it introduces new improved programming features). Thus it is certified that the MikeZ discovery is valid.
I cannot understand why previous test gave me wrong result. Maybe a Windows/Yape hidden bug, really I don't know.
Hat off for MikeZ, the Austro guru

Posted By

Chicken
on 2010-06-10
16:14:55

Re: AustroSimple

I also tested AustroSimple with some bigger programs (above 100blocks) and everything worked fine

These programs weren't too much of a challenge, though. (Lots of PRINTs and nothing unusual). Still it shows, how stable AustroSimple is. Congrats, MikeZ

One thing that could definitely be improved is the handling of errors. Austrospeed just leaves "open" files on the work disk when it finds an error in the source file.
COLLECT should clean up these files but it just ruined the disk image when I tested this (not sure if this is an emulator problem, though).
Anyway, proper closing of work files would be a nice addition.

Posted By

MikeZ
on 2010-06-11
13:06:56

Re: AustroSimple

Chicken: First thanks for the test results. Between you, SVS, and Csabo it seems that the preliminary test results indicate that Austrosimple has a future.
My purpose for decompiling austrospeed into AustroBASIC was to create a run-able source file that could incorporate improvements to the original Austro. I will certainly include your suggestion about file closures, along with several from SVS, and my AustroSimple mods into a rewrite/recompilation of austroSimple. That goes for any other suggestions/improvements that may come along.

BTW: If you have previously compiled prgs that require the crack to run, and you can't locate the Basic source file, I can provide instructions on how to modify them to run without the crack.

Thanks again to all of you! MikeZ

Posted By

Chicken
on 2010-06-13
12:16:58

Re: AustroSimple

We discussed Austrospeed a while ago in this thread...
http://plus4world.powweb.com/forum/16902

I mentioned there that I have never used the wedge and still the compiled programs worked fine. In retrospect I conclude that they didn't contain any PEEK command. But I would have never guessed that this is the reason. So thanks again, it's always good to know why certain things work or why they don't work.

There's some more info in that thread, especially SVS's testing of the RESUME COMPLETE and RESUME WITH LINE NUMBER options. But from what you wrote, SVS has probably already sent details to you.

Another small suggestion: Let the user define the line number used in the compiled program's BASIC start line and set the default to "2010".

I'll definitely do more tests with AustroSimple and I'll keep you informed about the results.

Posted By

MikeZ
on 2010-06-13
15:48:26

Re: AustroSimple

Chicken: Thanks for the thread reference. Reading through it shows that now we have a fairly complete undertanding of the issues.
My personal documentation includes a completely annotated version of the fully operational AustroBASIC source code decompiled from the non cracked "austrospeed +4" as updated into English by SVS, as well as an annotated and flow charted austro Run Time Interpreter.
As I said, I'll collect everyone's suggestions, test them on the Basic running version, and then recompile with AustroSimple.
If you have a chance, please reread my remarks on austro structure(I think they are still available for download on the austro page as a read me).
The point is that the compiler produces a firmly controlled prg structure that really cannot be violated without rewriting austro from the ground up.
This forces the compiled line numbers (actually fixed RAM locations of the pcode equivalent of each basic line number coding) to begin right after the end of the RTI at$2ef3, so actual austro line numbers must commence in the neighboor hood of 12018-12040.

With that in mind, please tell me what your thinking is when you say "Another small suggestion: Let the user define the line number used in the compiled program's BASIC start line and set the default to "2010".

Regards,
MikeZ

Posted By

Csabo
on 2010-06-13
15:57:35

Re: AustroSimple

I'll chime in for him. Load any "C/FILENAME" programs and give it a LIST. It will be a single BASIC line with a SYS, right? That line's number is what he's talking about. It used to be (is?) a convention to make that first line's number represent the year of the release. I think it should default to the system date's year

Posted By

Chicken
on 2010-06-13
17:20:36

Re: AustroSimple

MikeZ:
Yes, Csabo can read mind

But the system date's year is kinda hard to find out on the real iron

Anyway, I was refering to that line described by Csabo.

You mentiond "... decompiled from the non cracked "austrospeed +4" as updated into English by SVS".
Do you have an original version of "austrospeed +4" and the dongle? The only version that was "circulating" in Germany back then was "The (new) Raven" crack. And I think that SVS's translation is based on that one, too. Or does "non cracked" refer to the "wedge-less" version?

Yes, I have dled your documentation the day it was posted here (and it's still available on the page), very interesting read! But for my "small suggestion" you just need to change 2 bytes. So I guess you can implement this quite easily

Posted By

MikeZ
on 2010-06-14
13:24:34

Re: AustroSimple

Chicken/Csabo:

So for the basic line at the beginning of austrosimple you would like to see "2010 SYS 4124"? If so, then not a problem.

Regarding the "uncracked" austro: The crack only changed the PEEK section of the RTI, which is just ML.(Just look at the old austrospeed code in the area of $206X, and you will see either a "STA $FF3F" - the original, or "JMP $0353" - the crack to Raven's dongle buster. It did not alter the Dongle GOSUB in austro. I have it in Austrobasic. If the Austrobasic previously posted to the austro page is still there then just look at the basic listing starting at 20192. All you need to know is that the PEEK location is actually $FD1F, but because Commodore engineer Fred Bowen once told me that the PLA only outputs the 12 MSBs of an address, it is all FD1X, which includes user port at FD10. From the dongle code you could probably reverse engineer the dongle internal components.

A little off topic: I think it needs to be said that changing Austro only changes the compilation process. If a change in how code is executed in the "C/PROGRAM" is what's desired, then we must alter the RTI itself. This is a bit of a challenge as the RTI must always end at $2ef2, or else all the GOSUBs, JMPs, and GOTOs in austro itself will have to be changed.

Reply to this topic