______ _____ / __/___ ______ ____ ______ ______ ______ ______ /\ \_ \/ / __ \/ _\/ /___/ \/ \/ \/\ / \/ \ / / / ____/ /__\ ____/ /___/ / / / / \/ / / _/ / _/ / _/ / _/ / _/ / _/ / _/ / _/ _/ x /_ \ / \ / \ / \ / \ / \ / \ / \ \ / / \___ / \___ / \___ / \___ / \_/.sNs.\___ / \_/\ / \_/ \_/\__ / \/ \/ \/ \/ \/ \/ \/ VECTRONIX NEWSLETTER #6 (20 August, 1997) All text by Phoenix/Vectronix (unless stated otherwise!) Contact: vectronix@hotmail.com [1] Contents -------------------------------------------------------------------------- 1 - Contents 2 - Forewords 3 - Vectronix Gfx Competition 4 - Want to Become a Kickass Cracker? 5 - Finishing, Preparing and Packaging 6 - MonST v3.x Command Summary 7 - Publication of Contents [2] Forewords -------------------------------------------------------------------------- Believe it or not, but VEXNEWS #6 is already here! It was not my intention that it should be released this soon, but here it is! Actually I forgot that I had promised the MonST command summary for issue #4 to a few people, so I thought I could as well make anoher little newsletter! As I start typing I canot stop, the adrenaline is kicking and the fingers are bleeding of hunger to write, write, write!!!! ;-) [3] Vectronix Gfx Competition! -------------------------------------------------------------------------- We're hereby announcing a Vectronix Graphix Competition! We need new, fresh, cool and outstanding logos for our forthcoming webpage(s). There is no other prices than fame and glory to this competition. You will get your name mentioned if we use your graphics, and we will try to make a toplist of the ones we like best if we recieve enough contributions. Take the chance and prove how good gfx artist you are! Please let us know if you or anyone else in your crew is considering to take part of this competition so we know what to expect. Finished graphics can be mailed directly to phoenix@weirdness.com or uploaded to one of our headquarters. [4] Want to Become a Kickass Cracker? -------------------------------------------------------------------------- Yeah, won't we all? ;-) As we brings you the shortkeys for the most popular and well used debugger there ever was for the atari, maybe a few wise words about cracking could be in good place as well. There's a few things you must ask yourself and the most important I think is if you have the moral to crack software? What it means is to remove the protection from a program so that it can be copied and/or spread without any limits. The author might loose money on this, and he will not be happy when he finds out what YOU have done to his beloved piece of work. There is other aspects of this subject as well, cracking software for a dying platform as the atari might be a very good solution to keep it alive, and keep people to stay with it! People who uses cracked software would never buy it anyway, and it allows you to test before you buy etc... So, you have decided you want to learn how to crack? Good, stay with us! How do one proceed to crack a program you might ask? How does it work? What do you need? Well, the most important thing of it all, which you cannot get away from is your assembler knowledge! The better you know assembler, the better cracker you will be, no question about it! If you don't know assembler at all you should stop thinking about cracking and learn to code in assembler first, you _need_ to know how things works in order to crack, and do _not_ think you can take easy on this part, there is _no_ shortcuts! When you learn to code in assembler, you also learn how to use a debugger to trace your programs and find out what's happening for every instruction you pass by. The debugger is the crackers best friend, some people use dissassemblers as well, and it can be usefull sometimes, but most of your time you will spend in the debugger. This is really what you need to start with, if you know assembler and you know how to master the debugger, you will also know how to crack, almost atleast. A good cracker will need a lot of patience, time and imagination, he need to be able to look forward, and know what will happen next. You're playing a game, it's you against the protection and you cannot give up just like that, you have to defent your honour from the evil dark side... ;-) There is many different protections, some better than other, but most of them are really lame. If we take a very easy example, a shareware program which needs to be registered in order to unlock all the fatures. There is usually a register dialog to do this somewhere, let's find this! We enter a fake name and serialnumber, and starts tracing. We are now looking for a working serialnumber so we can replace the fake one we just entered. Sooner or later an alertbox will probably pop up telling it was the wrong serialnumber, "shit!" you may think, it didn't work! Well, if we look on the code right before this alertbox we might find something which looks like this. cmp.l d0,d1 beq.s $154553 bsr wrong_code bra.s $154545 Okay, this was a _very_ easy example, but believe it or not, sometimes it looks just like this! What happens here is that the values in the data registers d0 and d1 is being compared, if equal we will jump to the location we're we will get a nice little message telling the program was correctly registered, if it was not equal we will get that ugly alertbox right in our face saying we failed, you remember it don't you? If we stop here and think for a while, what are we looking for? What is happening here? Can we put this together in some way? Yeah, probably! If we look into the dataregisters again, we might just find the fake serialnumber we entered before, it have probably been converted into a hex value though. If you're not a living hexadecimal calculator (I know one who is) you bring up the little calculator tool (press "O" in MonST), enter d0 since it contains teh value we want to convert. And hey, look at that! It _is_ our serialnumber! So, we found the serialnumber we entered when we should register the program, and this value was then being compared to another value, remember? Then, what if we try the other value in that registration dialog instead? Yeah, let's give it a try... bring up the calculator again and convert the value in d1 so we get a nice code to enter in the serialnumber field. Then go ahead and register the program again, and I bet you'll be successfull this time! Let's pretend the above code was in the startup sequence of the program instead, the dataregisters does not contain the serialnumber but some control value instead, we cannot find any serialnumber. If the serialnumber is not correct, the program will be terminated. Hmmm, we could try to force the program to think the serialnumber was okay, let's replace the beq instruction with a bra instruction and the program will always think the code was okay. You see the point? Now please remember this was a very simple example, it's not always as simple as this, but as said, sometimes it is. This all gives you a basic idea of what it is about though. It's always best if you can find a working serialnumber and don't need to do modifications to the program, this way you know the program is 100% registered, and it might also work with future versions as well. Perfection is important, more about that later. If you want to practise or try cracking at a novice level, get the address register program DaCapo and use it as your first victim. This is one of the easiest programs to crack I have ever seen, the serialnumber is only 3 characters long, and you should be able to find it quite simple. It still requires you to know assembler and how to use a debugger though, this is something you have to learn on your own. If there is interest for it I can go through the basic of how to do things in the debugger, but I cannot teach you assembler... Please send us response to this article, whether you liked it or not, if you found it interesting and useful or just a piece of crap. If there is interest for more things like this, please let us know! [5] Finishing, Preparing and Packaging the Release --------------------------------------------------------------------------- For the crackers in Vectronix perfectionism is of high priority. First it's _very_ important that the crack is working properly, therefore we try to test it as much as possible. We always use a work directory for the program we're cracking, and when it's done we do all testing here. When it's time to pack it, we unzip a new fresh and untouched version. We add our *.nfo file containing the serialnumber, a short description of the program and such things and also the file_id.diz description. If we did modifications to the program (or other files) we replace these as well. It's important that everything is just the way it was in the original distribution. We pack it all together using Lharc, and then we unpack this almost-ready-to-go file and run testings on it again, to see that our distribution really _is_ working the way it's supposed to do. Now the release is ready! You might call us insane, but for us it's normal. Our job is to bring you high quality and working cracks, and we don't take easy on this. We want everyone to know that a Vectronix release is of the highest possible quality, and that you always can trust that it works the way it's supposed to work. [6] MonST v3.x Command Summary --------------------------------------------------------------------------- We bring you the shortcuts for the popular debugger MonST/MonTT which comes with the Devpac assembler package. This command summary was copied directly from the Amiga Devpac/Amon manual by Phoenix some years ago, but they are the same for the Atari. We have had these for years, but nobody ever asked for them so we thought there was no interest in them, we where wrong... ;-) Window Commands Alt-A Set adress Alt-B Set breakpoint Alt-E Edit view Alt-G Goto source line Alt-L Lock to expression Alt-P Print window Alt-R Register set Alt-S Split window Alt-T Change type Alt-W Widen window Alt-Z Zoom window Shift-. Open view Shift-, Close view . and , Next/previous window Esc Update all windows Tab Activate next window Alt-1 to 5 Activate window 1 to 5 Breakpoints Ctrl-A Breakpoint after Ctrl-B Simple breakpoint Ctrl-K Kill breakpoints Ctrl-X Stop executing Alt-B Set breakpoint U Run until Help Show help and breakpoints Loading and Saving Ctrl-L Load program A Load ASCII file B Load binary file S Save binary file Executing Programs Ctrl-R Return to program / run Ctrl-S Skip instruction Ctrl-T Trace instruction Ctrl-Y Single step Ctrl-Z Single step R Run (various) Searching Memory G Search memory (get a sequence) N Find next Miscellanous Ctrl-C/Alt-Q Exit MonST Ctrl-Q Quit a program Ctrl-P Preferences Ctrl-U Unload symbols Alt-O or O Show other bases D Change drive & directory H Shows history buffer I Intelligent copy L List labels M Modify adress P Dissassemble to printer/disk V View other screen W Fill memory with [7] Publication of Contents --------------------------------------------------------------------------- Other non-profit magazines and/or organisations are free to use, quote, or copy parts of the contents of the news letters as long as the mailing list is not mentioned anywhere and the material is not used against Vectronix in any way what so ever. Source may be refered to as "Vectronix", but not the list. We also ask you to inform/contact us if you're planning to use the information somewhere, this only for the purpose of our information. --------------------------------------------------------------------------- The Vectronix News Mailing List (c) 1997 Vectronix, All Rights Reserved.