CyberRax' LaMe CoM DuMPeR ver. 1.01   by Independent (IND)

-*-*-*-*-*-*-*-*-*-*-*-* aNoTHeR oF THoSe MaNuaL-THiNGZ *-*-*-*-*-*-*-*-*-*-*- After spending the night coding (again), I, CyberRax, am now proud to present: -=-=-= CyberRax' LaMe CoM DuMPeR ver. 1.01 =-=-=- "the greatest/lamest dumper there has ever been" Introduction ------------ Here it is, my first unprotector: LaMe CoM DuMPeR. What's that? It's an unprotector that removes any kind of protection from COM files. Basically this little utility is a generetic memory dumper (see the 'Technical stuff' chapter). It's REALLY lame (not the idea of a dumper but the way I do it :) You can get rid of protection added for example by ROSE SWE's HackStop with this little toy. Why would you want to do that? Well, I can think of exactly three reasons why anyone should want to remove the protection with an unprotector: 1) you want to archive your files (the compression is usually better when no executable-compressor has been used on the files before), 2) you want to write an unprotector yourself and the decryptor of a scrambler is too tough for you so you go against the main executable (the easiest way to find out how the decryptor works is to find out how the encryptor works, especially coz there's usually no big playing around to set up the encryption-key, but better protectors have independent traps inside their code), 3) you get a cool/small/fast utility which you use every day and it turns out that some d*** has crypted it FIVE times with the slowest/biggest wannabe-protector there is so the load time and the size of the prog have trippeled. Maybe there's other reasons too but I can't think of any. Yes, a good reason to WRITE an unprotector is coz you want to see if you can break some specific protection, but to USE a deprotector? I find that unpackers are software that are written because of the writing itself. But let's get back to the name of this piece of code that you hold in your hands. If it's really so lame the then why did I wrote it at the first place? There are 5 reasons: 1) I had nothing better to do at the moment when I began writing this proggy; 2) I wanted to see if I can crack HackStop's protection; 3) I'm using SPHINX C-- and I want to make it more popular (there's exactly 1 assembler command in LCDUMP.C--, the rest is pure C--, so you see: it's really a powerful language); 4) just wanted to show all those who are writing protectors: sometimes really simple methods can defeat your brilliant traps; 5) and I also want to show all those beginners (like me) who are afraid of writing an unprotector coz they think it's too hard: IT AIN'T! Usage ----- Really simple: LCDUMP FILE.COM (for some strange reason are all my programs easy to use :) The COM extension has to be included. The unprotected program will be in DUMPED.COM. If there's already a DUMPED.COM in the current directory then it will be overwritten (and there won't be any warning about it). The program creates 2 temporary files of which 1 will be executed. If you have a TSR that askes before a 'strange' file will be run (TbCheck for example) than answer 'Y'es, 'N'o or 'C'ontinue (depending of your TSR) to let this program operate. You should note that LCDump executes the whole protected program so you SHOULD NOT UNPACK VIRUSES (even if this prog can do that). Limitations ----------- Because this is still a LaMe product then there are several limitations: 1) this unprotector is for COM files and even if you can crack with it the protection of EXEs then the unprotected file will be unexecutable, this means when you run the DUMPED.COM that has been created from an EXE then your computer will probably crash (see the next chapter), 2) starting with this version LCDump will need atleast DOS 3.0 and a 286 to work (if someone REALLY wishes so then I could recompile this program without the 'use286' option but I REALLY doubt if this ever happens :), 3) the prog sets DOS memory allocation strategy to first fit and doesn't restore what was there before (I really don't think there's ANY trouble with that, but who knows...). Technical stuff --------------- Aa, yeah, the technical stuff. There are basically 4 types of unprotectors: 1) unpackers, 2) tracers, 3) emulators, 4) memory dumpers. It's actually sometimes quite hard to tell if we have a dumper, tracer or emulator (better unprotectors can use all those methods). Mostly unpackers first identify the used protector, load the program and run it until the protecting part has decrypted/unpacked the program, then they just write the prog back to disk. Unpackers can be divided into two classes: generetic and ungeneretic. Generetic unpackers are basically designed to unpack every program, but mostly they aren't so good. Ungeneretic protectors are ment to crack the protection of a specific protector. Tracers, on the other hand, don't identify the protector (usually), they load the program and break after every instruction. They do that as long as the cotrol is given to the original program, then the original unencrypted program is written to disk. Emulators do the same, but they don't execute commands, they just emulate them. Memory dumpers usually set breakpoints or hook the timer interrupt and make 'snapshots' of program. As you see there are a dumping-process by all methods, so basically all unprotectors are dumpers. So how does LaMe CoM DuMPeR work? It exploits the fact that DOS doesn't clear the used memory after the program has terminated. Also, this unscrambler uses a neat (yeah right) trick to bypass protectors that don't allow to set breakpoints in their code. First the dumper creates a temporary program and executes it. This is only necessary to find out WHERE in the memory will the program exactly be executed (if someone knows how to find out in which segment DOS's EXEC (4Bh Int21h) executes the program from inside the parent, let me know!). After that this segent is filled with NOPs (this way we can determine the size of the program in memory). After THAT the protected program will be executed. When it terminates then the control is passed to the parent program, in our case LCDump, which just searches where the line of NOPs begins and writes the bytes from offset 100h to this spot to file (I told you I used a REALLY lame method :). Why to we need that? you may ask. Well, this way we can unpack compressors. Let me explain a little bit closer. The difference between a compressor and a protector is that the first makes the file smaller and the other makes it bigger. Atleast that's what happens with the file on disk. When you run the program, then, when it's compressed, it will be expanded in memory, so it will be larger than on the disk. A protected file on the other hand will be the same size in memory as it was on the disk. So there's no problem writing it back to disk, the whole program plus the decryptor will be written. It's just that the decrypting-part won't get control because (mostly) the 'protected one' shouldn't have any knowledge about the eXistenZ of the 'guardian angel', so the protector has done it's best to prevent ANY disinterference with the program after it has decrypted it (and that's allready happened). It will be just 'dead code' at the end. But compressed COMs? We just have to find out the real size of the file. As you saw, I eliminated the problem with searching for NOPs, but offcourse there are more elegant ways to get the size. And what about EXE files? The main difference between an EXE and a COM is that the first one has a header. This header won't be loaded into the memory, but DOS will load the rest of that EXE into memory accourding to the information in header. Yes, when you let LCDump unprotect an EXE then it will create DUMPED.COM, but the problem is that the file won't be a COM but a EXE without a header. So you shouldn't unprotect EXEs, even if there's a REALLY little chance, that LCDump will crack the EXE. This works (atleast sometimes) when an EXE is actually a converted COM (I discovered that when I, forgatten that I'm dealing with an EXE now, tried to unprotect a ex-COM that was converted with ROSE's COM2EXE, encrypted then with A. D. Jones' EPW 1.2 and as last protected with ROSE's HackStop 1.19/386. I also tested some COMs that were converted with Fabrice Bellard's COMTOEXE and packed with LZEXE 0.91 by the same author. The unpacked program worked flawlessly). Still, sometimes the program won't be unprotected correctly. So when you unpack a file with LCDump then look at the DUMPED.COM carefully: are there the textstrings that the prog usually displays? Also look at the end: does a message end at half of the word? If so then the LCDump has messed up. You should actually use LCDump as the last one, in case everything else fails (there are lots of unprotectors and some of them REALLY WORK :) As you see, LCDump is a generetic unprotector (in it's own lame way :), that means it can crack ANY kind of protection (yeah right, keep on thinking that :) Maybe you're thinking of writing an unprotector yourself. Then you could enchance my program. You could do that just by adding some code that gets rid of the decryptor at the end of the file. Or you could write an add-on that traces through LCDumped code to find out where the program actually ends. That's it, coz the idea behind LCDump ain't actually SOOOOO lame (atleast I think so), just the way I realized it... Tested ------ My collection of protectors/online-compressors is even smaller than the debugger/emulator/tracer/unprotector collection, but I tested LCDump on: ROSE SWE's HackStop (1.0, 1.15, 1.19 build 217) - cracks ROSE's HackStop/386 1.19 build 217 - cracks Nowhere Man's CRYPTCOM - cracks All versions of LCCrypt (by me :) - cracks (darn! this means my little LaMe CoM eNCRyPToR ain't uncrackable anymore, total BS! :) ROSE's COM Crypt II/286 (1.09, 1.12, 1.13, 1.16) - cracks ROSE's VSS 1.00 - it's actually against viruses, so the fact that LCDump cracks it doesn't mean anything. N0Ps Shit Protector 0.002▀ - cracks (well Ralph, it looks like unCOM ain't anymore the only one that can beat this protector :) ROSE's R-Crypt 0.91 - cracks Alan D. Jones' EPW 1.2 - does something but because the decryption ain't final without the right password then you still can't crack EPWed files (and if you know the password then you don't need this toy :) UPX 0.70 - unpacks Fabrice Bellard's LZEXE 0.91 - if the EXE is a converted COM then unpacks, else... Prominence's COMPACK 4.5 - unpacks Todor Todorov's PGMPAK 0.13 - fails, coz the packed file ain't a COM anymore but an real EXE (even if the extension remains COM) Teddy Matsumoto's DIET 1.44 - unpacks (both COM and EXE output) ROSE's Super COM Cryptor 1.03 - fails, but coz I have only 1 file then I can't tell if the problem's in the unprotector or in the protection :( PKWARE's PKLITE 1.03 and 2.01 - has no problem Dismember's CRYPT - have no idea coz I don't know where the disk with this protector is :( As you see, at this moment LCDump, in it's whole lameness, kicks almost EVERY protector/compressor I have. And I think that RSCC will be generally defeated by LCDump. As you see, lots and lots of scramblers are missing but I really belive that this little wannabe-unprotector will crack ALL COM cryptors (and I mean cryptors, that don't ask for password and output a real COM) that exist at this moment (OK, maybe there are a few better ones that are uncrackable). So, maybe you think now... ...how can I defeat LCDump? --------------------------- Maybe you want to write a protector yourself or just wonder how the f*** do you kick LCDumps ass. There are several ways. First, use REAL EXEs (converted ones COULD be unprotected). Second method: your protector might hook Int 22h, which will be called when the program terminates. Then the decryptor-part could clean the memory or overwrite the area with something (for example with code that displays "F*** YOU" or you could juss overwrite some bytes so the generated DUMPED.COM will crash). Third method: your scrambler could search the MCBs for LCDump, but this would make the added part bigger, also the user could rename this utillity. Fourth way: you'd have to find a simple method how to make sure if the program's running under LCDump and if so then you'd just terminate. This little proggy would claim then that it has unprotected the prog (or atleast it thinks so :), even if it's not true. Fifth way: your decryptor could copy the scrambled program to another part of the memory, decrypt it and execute it there by a JUMP FAR or CALL FAR. After the termination only the protected file will be written to disk. Sixth method: the proggy could swap to XMS and EMS (it should be compressed first). Seventh way: don't hook int 22h but swap some code in memory or recrypt the whole program again before you terminate, but this needs the cooperation of the program and protector. But actually you don't have to worry about LCDump, coz there won't ever be many (if any) hackers who use such a LAME (in the very sense of this word) tool, especially coz it's limited to COMs (atleast now >-) The past -------- The official history of CyberRax' LaMe CoM DuMPeR: Version 1.0 released on 1st of January, 2000 * Initial release * The outputfile was EXACTLY the same size as the protected files, so compressors were not supported Version 1.01 released on 3rd of January, 2000 * Added compressor support * Now DOS memory allocation strategy is set to first fit * Compiled the program with option to shorten codesize though the usage of 286 instructions, so now LCDump will need atleast a 286 to work * Almost added the check to determine if the file is an EXE but as some COMs that have been converted may still be recovereble then this check remains an 'almost' * Added some new ways in the documentation of how to defeat LCDump The future ---------- For some reason most software that's not written by a big byrocratic company has this little section of 'those features will be added in the future' in it's documentation. I understand it by shareware, but to include it by freeware... Anyway, my one-man-group ain't big and I hate byrocraty, so: + Code optimization to decrease the size of LCDump + Maybe EXE support + If I figure out how to get the segment address of loaded program without a temporary file then I'll defenitly add the code to do so + Would like to test this unprotector with other scramblers and report the results (you could help me by that) + Maybe some things done more elegant :) Credits and greets: ------------------- Several people (and not just people) have helped me to write this program and because NONE of them is aware of that then I shall tell 'em: Ralph Roth from ROSE SWE - I actually just wrote this proggy to see if I can crack your marvelous HackStop. Also, I had so many scramblers to test because I had your UnTiny Package (where are almost no unprotected files). Besides that, I got a lot from the documentation of HackStop Stone Peter "SPHINX" Cellik - well.......C--..........it's just... Ben Castricum - I first had the idea to write an unprotector when I got your awesome UNP Dan Rollins - you have NO idea how many times I run TECH Help! Ralf Brown - for his Interrupt List (which I couldn't use coz mu 2nd computer where this list laied had a little HD crash and I haven't had the opportunity to get a new copy from Internet) Gerardo Maiorano - I had quite some looks at the source of your CLOCK (I had first the idea of hooking Int 22h) SEN - I don't know what would I do without HIEW VIVA Television - good music most the time I was coding Radio SKY Plus - did the same The guys at Dark Corner.ee - most of my compressor-stuff is from your site. Ka0t and Rand0m - I choosed the text output format of LaMe CoM SeRieZ thanx to your programs E-Mail and other stuff ---------------------- Well, that's done now, you have reached the end of this manual (which actually should have been ca. 2kB). You can check if this textfile and the executable are as when they were when I packed them. Just execute PGPK -A LCDUMP.TXT to store the following public keyblock into your PGP public keyring. Then execute PGP again to verify that CRCHECK.TXT (created with ROSE SWE's CrCheck) is unaltered. If that's so then run CrCheck to check the validaty of the other files. -----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 [email protected] If you find a bug, you have some suggestion, you find a protector which I haven't mentioned but LCDump can crack (or can't), you discover that this unpacker doesn't work with some programs or acts differently under some configuration, you deside to write an add-on, you LOVE my deprotector or you want to say how lame this program actually is than mail me certainly. Oh yeah, forgive me my bad english... CyberRax the Hacking One of -=-=-= CyberRax Programming =-=-=- "just a sick dude" January 3rd, 2000, Tootsi, P„rnu County, Estonia -*-*-*-*-*-*-*-* i HoPe i DoN'T HaVe 2 Do aNy oF THeSe aGaiN! *-*-*-*-*-*-*-*-