-*-*-*-*-*-*-*-*-*-* THiS ReaLLy CRueL THiNG CaLLeD MaNuaL *-*-*-*-*-*-*-*-*-*- Well, I, CyberRax, am back and I present: -=-=-= CyberRax' LaMe CoM eNCRyPToR ver. 1.12 =-=-=- "as lame as it may be, it still rules!" IT'S BACK! ---------- Yes, CyberRax' LaMe CoM eNCRyPToR is back and rocks more than ever. But let's start from the beginning. So what is LaMe CoM eNCRyPToR? It's a COM protector, that keeps crackers/pirates away from hacking/cracking/disassembling/reverse engineering/pirating your precious programs (atleast that's what a REAL protector should do). As the name says, my little scrambler is REALLY lame. But what does LCCrypt exactly do? It encrypts the given file and attaches a little decryptor that will decrypt the original program in memory. You can hide for example text strings in your program, so others won't see them with a hex-editor. It's as you had ciphered your COM with PGP, just it will run and is MUCH easier to crack than PGPed files. So why the f*** did I wrote this so called protector at the first place if it's so lame? There are 4 reasons: 1) maybe someone includes this proggy in his/her unprotector and mentiones my name (yeah right); 2) to encourage YOU, dear reader, to write a generetic unprotector that can handle anti-debugger/tracer-code and double encryption; 3) I wanted to see if I can defeat TbScan's heuristic scanning; 4) I use SPHINX C-- and I want to populize it. Let me explain the writing reasons little closer. The first one is really simple. But the second one. The decryptor generated by this program has 3 (well, actually 4) little o' traps (and I wouldn't name 2 of them traps) and I was REALLY surprised, when I discovered, that NO unprotector that I have could break the protection of the large decryptor model (maybe CUNP can but for some strange reason it crashes on my PC). ROSE Softwareentwicklung's unCOM was the only one that could get rid of version 1.0, but even this awesome unprotector fails on this release. Ain't that just great! The third reason is really simple too: the decryptor generated by previous versions of this protector triggered TbScan's heuristic scanning (maybe other AVs too) and this anti-virus program declared that the file is infected vith a virus. I just wanted to get rid of that (and I did it, hihi). Now the fourth reason: SPHINX C--. I know, I know, Peter "SPHINX" Cellik has stopped the developement of C--, but it's still a MARVELOUS programming language and there are still some sick dudes who use DOS and/or are (atleast) programming for this OS. And C-- is THE thing for you! This program has been entirely programmed in C-- (with a little help of inline assembly :) and compiled with version 0.203 (PS! If anyone knows where to get a newer version, contact me). Usage ----- Really simple: LCCRYPT file.com [/S] /S - create a smaller decryptor without any anti-hacking-code The COM extension has to be included. The /S (or /s) parameter is optional (see the next chapter about large and small decryptor model). First will LCCrypt change the extension of the given file to BAK. If a file with the same name and the extension allready exists then this little proggy here will terminate. By this way there's no chance for this protector to overwrite the backup. If you use TbFile or something similar then be ready to answer 'Y'es, 'N'o or 'C'ontinue (depending on your TSR) to let LCCrypt rename the file. It's actually possible that some anti-virus program thinks the protected file is infected (because of the encryption), but I haven't countered such a program. Large and small decryptor model ------------------------------- Starting with version 1.11 you have the opportunity to choose between a smaller and a bigger decryptor (the part that restores the original program in memory). Let me first tell you about protectors. There are basically two types of protectors: so called online- and offline-protectors or protectors and scramblers. The main difference between them is the generated decryptor. By scramblers the decryptor just decrypts the original program in memory and nothing more (usually). That's why scrambler-decryptors are quite small. They hide the text strings in programs and they also make it harder to disassemble the program. It's logical coz when you disassemble (the process of translating the program from machine-language to assembler-language) a encrypted machine-language command, then there will be an another (wrong) assembler command. But I have to warn you. Usually someone who can use a disassembler (or even has one) is smart enough and can crack this kind of protection by simply using a debugger and decrypting the program first. Just for these cases exist protectors. Decryptor generated by a protector includes anti-debugger and/or anti-tracer code, sometimes even anti-emulator code, so when you try to explore the program with a debugger or you're unprotecting it with a tracer, then the debugger/tracer will stop or crash. The program is encrypted and if you try to disassemble it then the result will be the same as by scramblers. As you see, a protector is basically a advanced scrambler, which has more tricks to protect your program. And because of those tricks the decryptor is larger (even 100 and more times). But let's get back to the decryptor models used by LCCrypt. The large model (which is used by default) is a protector-decryptor, that means it has some anti-debugger/tracer-code. The small decryptor model on the other hand has no anti-code, so it's a scrambler-decryptor. Size of the decryptor depends on 2 things: the used decryptor model and the original size of the program. The sizes are: Decryptor model ³ File size in bytes ³ Decryptor size in bytes ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ 130 or less ³ 19 ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Small ³ 255 or less ³ 23 ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ 256 or larger ³ 24 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ 130 or less ³ 62 ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Large ³ 255 or less ³ 66 ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ 256 or larger ³ 67 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Besides the anti-hacking-code part the decryption is a little bit different: by large decryptor it's word encryption, by small model byte encryption. This means that by large model are 65535 and by small 255 different possibilities. Also, by large model the program will use double encryption and also the decryptor will be encrypted. Nothing from that will take place when small mode is used. I added the small decryptor only coz I wanted to write a shorter decryptor than 26 bytes (I think the decryptor could be shortened by some bytes but I don't know where I could cut these bytes). If you're planning to write an unprotector then the easiest way to make certain that LCCrypt is used on the file is to examine the 2 last bytes which will be ':)' (it's so by large model, small model has no indicator like this). Limitations ----------- This version (or actually the whole program) is for testing purposes only so it has several limitations: 1) the size of the file that is being crypted must be atleast 3 bytes; 2) this program is not ment for EXE files so better don't risc crypting them (actually the program won't proceed if it finds that the file is an EXE); 3) you shouldn't crypt the ENUM COMs that come with Winblows 95, coz they have a little selfcheck and they won't probably work after scrambling (I think so, I haven't tested); 4) the prog won't scramble files that are bigger than 65000 bytes; 5) beginning with this version LCCrypt will need a 286 and DOS 2.0 to work (I don't think there's anyone who has a computer lower than 286, but if someone really has such a computer and he/she REALLY wants then I could recompile the prog without the 286 option). Tested ------ My collection of debuggers/tracers/unprotectors/emulators is really small (I hope this will change quite soon), but I tested LCCrypted files with the following programs (first is large, then small model, if there's only one line then it applies to both decryptors): Borland's Turbo Debugger 2.01 - crashes has no problem steping through the program Microsoft's MS-DOS DEBUG - dosn't perform the first decryption properly so there's nothing meaningfull coming out... debugs properly Ben Castricum's UNP 4.11 - thinks the file is not protected UNP in trace mode - stops or crashes unprotects the program Pablo Carboni's X-TRACT 1.51 - 'No known program found!' TSEP's UnLite 1.6 - stops defeats the protection Rand0m's X-C0M - crashes cracks the protection, but the size calculation is buggy X-C0M/386 - crashes the protection's no problem but the size of the unprotected file is still TOO large ROSE's UNComBat - can't unprotect the file unprotects but the size... ROSE's unCOM 1.21 - doesn't think the file is protected (a real disappointment by the small mode) ROSE's CUNP - couldn't test coz all versions of CUNP crash on my PC ThunderByte BV's TbClean 8.09 - 'uncleanable' cleans well ROSE's deCOM 1.26/386 - stops unprotects ROSE's RVK/386 1.27 - claims that it has cleaned the file, but this ain't true and the 'cleaned' file will crash cleans the file as it should Ady's X-Open 3.20 - find's no known program (and coz I own a not registered version then I can't test the generetic COM extractor) ROSE's unROSE/386 0.21 Beta - 'Not packed/relocated with a known packer!' As you can see there are many unprotectors missing and that's why I can't tell if they kick LCCrypt's protection, but I'm quite sure that some of them do. Also I didn't test LCCrypt on any machine besides mine. So you, dear reader, are asked to be a tester for this little program. If you for example discover, that LCCrypt doesn't work with some programs or acts differently under a different configuration, then contact me. You'll find my e-mail address below. At this moment this protector has been tested on a Cyrix 486DLC/40MHz with MS-DOS 6.22. If your computer has a different configuration (and probably it has) then would it be totally cool if you'd send me a mail describing your machine and how this little wannabe-protector worked (as you see I haven't tested it even under Winblows (PS! I'm NOT writing wrong, that's just what I think about this mammut-"wanna be an OS"-program)). And if you have a unprotector that beats or atleast identifies this lil' o' cryptor (for example, unCOM identified version 1.0 as CryptCom/Moshe), let me know. Conclusions ----------- As it looks, LaMe CoM eNCRyPToR ain't actually SOOOO lame. I still don't recommend to protect your files with this program. Or atleast you shouldn't use the program on files that 'go into the wide world', especially with the small decryptor. If you want to crypt personal COM files on your home PC, where there's little chance that a hacker/cracker gets to them, then go ahead. If you want to give your files to others then use a REAL protector like ROSE SWE's HackStop or get the source of KA0T's SuckStop, enhance it a little bit (you may do this as long as KA0T's copyright message is present in the file), compile and use it on your files (the enhancing should be done to beat the existing SuckStop removers). The past -------- This is the history of CyberRax' LaMe CoM eNCRyPToR: Version 1.00 released at 25th of December, 1999 * Initial release * Had a simple XOR encryption with some anti-debugger/tracer-code in the decryptor (the anti-hacking-code has remained EXACTLY the same) * Only one of my unprotectors, ROSE's unCOM, defeated the protection Version 1.1 released at 28th of December, 1999 * Added double encryption to beat unCOM (and I defeated it, hihihi) It's even better: unCOM thinks now there is no protection at all! * Decreased the size of decryptor by 4 bytes * Recoded the encryption process, now it's being done in memory This way I got rid of the delay by crypting bigger files and there's fewer writings into the file, making so the program faster * Addes JMPS support (this means that the jump command by files smaller than 128 bytes will take 2 bytes instead of 3, also the 3rd byte won't be recovered, saving so 4 bytes by the decryptor) * Added the message of file being closed Version 1.11 released at 29th of December, 1999 * Added the opportunity to use the SMALL decryptor model which creates a max. 24 bytes decryptor. * Added the check if the file is really a COM (actually if it's not an EXE) * Now LCCrypt won't crypt files larger that 65000 bytes * At the scrambling process there aren't as much text output anymore. * Now it's not possible that the encryption key is 0 or the 2 keys are the same * Added the 'file is an EXE/too big' messages Version 1.12 released at 2nd of January, 2000 * Added a second decryptor (19 bytes) to large model that unscrambles the real decryptor (credit for that goes to HackStop's decryptor) This beats TbScan's heuristic scanning (no more false alarms about LCCrypted files being infected!) * Now a backup is created (this was mainly against TbFile that accused this protector to act like a virus) * Some changes in the output of LCCrypt * Removed attribute-wiping because it's not needed anymore. The future ---------- It's a quite old tradition, and I'm gonna follow it. That's what's coming in a future version (assuming there will ever be a next version): + Code optimization to improve the size and speed of LCCrypt itself and of the generated decryptor (I wonder how I'm gonna do that by small model :) + More anti-debug/tracer/emulator-code (actually not just more, but REAL) + Better encryption (maybe tripple encryption or variable ADD/SUB instead of that second XOR (had this already but there were some problems)). LaMe CoM eNCRyPToR will (probably) never be able to crypt EXE files, coz this is still a tryin'/learnin'-ware and I'm planning to write another protector which will be far more advanced. This scrambler will also never include a polymorphic engine, coz that's gonna be the speciality of that other protector. If you have an idea of what I should include in a future version then contact me defenitly. Credits and greets ------------------ The usual greetings section: Peter "SPHINX" Cellik - for his awesome programming language C-- Ralph Roth from ROSE SWE - my personal coding god! I used a trap from CUNP's source, thanx. I just wanna say: keep on the good job! Nowhere Man / NuKE WaReZ - CRYPTCOM was the first scrambler I ever had and I got the basics also from this protector Ben Castricum - UNP was the first unprotector I got and it's still the best I have Hanno Boeck - for his EXE Mailing List David and The Archivist - Sudden Discharge rulez, also you were the ones thanx to whom I decided to code a scrambler SEN - for his HIEW, the funkiest hexeditor ever (this program is FAR MORE than just a hex editor). Rand0m and Ka0t - I choosed such text output format thanx to your programs. E-Mail and other stuff ---------------------- Well guys, this was the manual (if I may call it so) of LaMe CoM eNCRyPToR, a simple COM wannabe-protector. You may check if this and the executable file in this archive are as they were when I packed them. Just execute PGPK -A LCCRYPT.TXT to store the following public key into your PGP public keyring (actually you shouldn't keep there such unnessecary crap as MY key) and validate then if CRCHECK.TXT (created with ROSE SWE's CRC-generating/validating utillity CrCheck) is unaltered. Then execute CrCheck (if you don't have it, get it!) to verify the contents of the other files. If PGP shouts 'Bad signature' or CrCheck yells 'Changed!' then delete the archive, download it again and if it's still bad, then get it from a different source. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGPfreeware 5.0i for non-commercial use mQENAzgXS2cAAAEIAL63BN4q4il+3zn2mbcN81f2gmUz6X7Rk70hoeM+OpR+Vs3M QGidYuZXjRykOt1zRjOj9myLIqRvuguPE1P5jnLa6fbz2cZF/pc6FsN+Jr1O3bzk tgZcflPcxYygEfdxoAwXfMsiPiEAzV1TZ7Ugl+hIyhnMKk/77VWRo6VgYcfJIs1z AsLggh/g/16SrzOKQBV8Xb0upvbL6AtM4/nKQ80bEFHBQSmmxAYMl1NGXHcglnIg 7ahJcV9FJtEQ02GXpsK7RKmMiiw1Xru3ecv+haa6ZMWz8kQC01xOT0d2tIGgOWCs 8SfFT4FLyr9cxCA2m5JB30sE7vrYg6FNwk43AbEABRG0LUN5YmVyUmF4IHRoZSBI YWNraW5nIE9uZSA8Y3liZXJyYXhAeWFob28uY29tPokBFQMFEDgXS2eDoU3CTjcB sQEBO48H/iDPxnl8rnW/YeTG6EraYXJn8k3aYqPb1BUwJHTCrMqjmo77efaxyioN J2vjpmS51XyHwQhMYg5Z0yuHRETJhxATN31zuQcZ81Xe5kghaKnKV6NdzhfZkNVc wlmaVot9/c9nXgvGxW9fTV+Tb5Y+5xVrmy8JgYhH5VIIVxSiv8M3FKG6I/rGb6/N QNuMupDEVO+bdFFrTTrPoU9MyIejF1IPt7Lk/TCwwc9i6LvWs0lkce86QlrbiGRy 2nzf3g2n8RXlTf/nADh8SI2LA6P4rLFFoH+Wq2EwOrX1kOO1gzL3adhXzK2tdxdG iy3asNGodyCju04wHoYbIARpa8L2qWmJARUDBRA4F12meJM/nPQWOcMBAQeyB/oC sj8F8N4bMoc2krrjgwRz3f1Uc0NWUgT9u65OcG13s0laHyg0UEWdL3pN2RxWAMw7 l6SPFHo8wWN9+PWtCvpB+r9CYmxLLZjyFvZp5+8d9pZL1EC7zPZTXk/40BpTRVHb yvGpx1X9fsOoPk/QXdLBhr+DLtrL8v1eYKrChsBNTXl5o6enn3ZgzcZXXY5K0NAy 4V7LPu+iPYRVcdffLuMCVXZACcUWuXMerj3gVFeJgVgiiXssiNl41LNwBBwkN6ic IU72BE9axub0SB1SI2vmViQ4eXkBwl8gn841qbgjCG/4++h4U1ghkrzrK2PYCmty XIks/g/17F5uFn8Uev3/iQB1AwUQOBdsjqfc1BX18rDNAQHZ/AL9HW5lF/t9ooBl O5+S2i2B7O79umrvAvrP3DNDjck//+rq21BFGAcSttDOu88S0javHlwvnzNJ+i1n ZSpurkE+fy3LK7NRdSJ3nL3yK5DjeZqIcLHgBw3oS7uj4sImFkjhiQEVAwUQOBdw dH8iCojdvXTnAQEUgggAmHjaymYD3G4Ok0FM3sjOJQxZnprUWPDYdZ4EkXX4xuR2 p70xSEYIVWDGql0E44Am6VxGRXK/6NoeDrvwgS5GVxJ7W74ScYBEEGmIcfZbC3YE X6EEwWq2byye6hY5NpxyQTpe7ugSsjD3pq+ofL4bJScWs0960Ye0XPJjzLBOf17/ PtYVM7qpKvQpHQnqbXALt1Psbub2yMtz7RvgPEVOUSUVUH0LQXMe6JHUc2oxyZmE xDZEtaiqklP4kq+22N7+0AVkARle4he45nEumYSf+C1K7d9EvbippdRJgNkpLFr5 VZ1nNYiiaeriNW3b55MATt5WKxvJmgXQ+bn8dSHx/Q== =iSu+ -----END PGP PUBLIC KEY BLOCK----- If you want to contact me for some reason then mail me at cyberrax@yahoo.com If you like this program (or you hate it), you find a mistake in this documentation or disagree with something, you have a thought or suggestion, you find a bug or anything else then feel free to mail me. Oh yeah, forgive me my bad english... CyberRax the Hacking One of -=-=-= CyberRax Programming =-=-=- "just a wannabe cipherpunk" January 2nd, 2000, Tootsi, P„rnu County, Estonia -*-*-*-*-*-*-*-*-*-*-*-*-* So, THiS iS DoNe NoW *-*-*-*-*-*-*-*-*-*-*-*-*-*- -*-*-*-*-*-*-*-*-*- aND you ReaLLy ReaD THe WHoLe MaNuaL? -*-*-*-*-*-*-*-*-*