----------------------------------------------------------------------------- XX XX XXXXXX XXXXXXX XX XXXXX XXXXXXX XX XX XXXX XX XX XX X XX X XXXX XX XX XX X XXX XX XX X XX XX XX XX X XX XX XX XX XX X XXXX XX XX XXXXXX XXXXX XXXX XX XX XX XX XXXX XX XXXX XX XX XX XX XX X XXXXXX XX XX XX X XX XXX XX XXX XX XX X XX XX XX XX XX XX XX X XX XX XX XX XX XX XXXXXX XXXX XX XX XXXXX XXXXXXX XX XX XXX X XX ----------------------------------------------------------------------------- Some emails we got for HackStop... We think they are of popular interest Edited by ROSE SWE and Stonehead ----------------------------------------------------------------------------- > 1) HS/86 1.20 caused no troubles to my Soft-Ice (a bit modified 2.64). bad, hs is "generic anti soft ice" designed :) > 2) HS/386 1.20 caused freeze of Soft-Ice (I'll have a look why it > did that) that's ok :) (design goal :) > 3) Unprotector for shareware HS86+386 1.19 (which I had by hand) was > very easy to write (another 20 minutes). Modifying it for the > registered version won't take much longer. I suppose that the same > applies for 1.20. There is too little variability in the protection > envelope, so after passing it once, it is no problem to pass it are you speaking about an generic unpacker for HS¦ed files or for dumping HS386.EXE itself? > 1) I don't know whether this will have any effect, what happens if the > original code (the program you protected with HS) is executed at > different places in memory each time ? For example, based on some > random value (mem[46c] or port[40], etc.) you move the program from > one segment to another one (and modify the segment registers as > necessary). Thus, if the unprotector takes two memory dumps, the > program will be at different addresses. That's an idea Stonehead already tested 18 months before and failed, because it is to incompatible for most applications (PSP Shifter Shield). > 2) One-instruction decryption (as in TraceLock). The code runs with > TF=1 and each time the instruction is executed, it is encrypted and > the next one is decrypted. Would be nice, but I think has not that great benefit of security versus implementation and compatibility risk on the other hand. That's only effective against single step debugging. And there are a lot of other oppertunities in HS to catch a hacker doing single step debugging. > 3) What about to use something similar to Level3 phase 1 decryptor > (the almost-random linear code) ? I am not sure how the real implementation of this should look like, but see 3.) - HS is currently the most compatible protector known, why shall we made risky enhancements that really doesn't stop a "guru". ("Ah, look a running line" -- rand0m in 1995) > PS. I think you might know where can one find the latest versions > of these protectors: > Adflt, Ciphator, Crypt-LS, DS-Crypt, ExeManager, FSEs, JMCE, Secure > (Warezak's), Spirit and SuckStop Best place is www.suddendischarge.com or the "playtools" site (haven't the url by hand). > That's an idea Stonehead already tested 18 months before and failed, > because it is to incompatible for most applications (PSP Shifter > Shield). More Zenix: Actually, he got it about to work in FSE. But it is quite hard to find a memory allocation algorithm that will work with every application under every operating system. I had severe trouble, even with pure DOS. Several applications just wouldn't work. Pure Turbo Pascal code like CUP 1.2 was hardly a problem, but any program which resizes itself is. I can still use some help. I posted my test code (using Mess 1.30) to some people, I don't currently have it online. After that I'm back from my holiday (next week I'm in France), I could do some searching. > > 2) One-instruction decryption (as in TraceLock). The code runs with > > TF=1 and each time the instruction is executed, it is encrypted and > > the next one is decrypted. Mess already did running line decryption, which is nicely traced by any 386 debugger nowadays. There's one "but": Win95 seems to skip the last TF=1 after turning it off with popf on some machines. Therefore, the command after popf must be a NOP or something like that. (Running line decryption is a school example of dirty coding, by the way.. :) > - will be new HS fully polimorphic and Edump II resist ? > (also think that Edump sources can be modified - anti-Edump method have > to be universal ... ) I hope that Christoph gives me a good eDUMP trick to include into HS. Polymorphism isn¦t planed yet. Its a bit difficult, because CRC32 is used over code fraqments. > - How someone can join HS project ? You? Requirements are very good asm coding skills and the ability to compile with MASM 6.xx the sources. > - Will HS become free ? I will made HS free for non commercial use (freeware/GNU). But commercial use will still require a registration. WG> Just being in the middle of developing my very first shareware utility, I WG> was thinking about some kind of protection, and fortunately it seems like WG> your proggy could be the answer. I read the documentation several times, WG> and it is not clear to me what you mean "Commercial Usage", the WG> registration of which is 70DM. If I write a shareware program, protect it WG> with HackStop (after registering, of course) and disrtibute it, is that WG> commercial usage? That's right: If you distribute HackStop'ed files you'll need a registration of HackStop. Well you can use the normal "registered" or the "personal" version of it. (BTW: I will remove this sentence, it's confusing) >> Thanks! What version do you test? HS 1.13 will be available in a few days! WG> I experimented with version 1.11. I am looking forward to take a look at WG> the new version. Where can it be downloaded from? If you send a short mail to RalphRoth@gmx.net you will be added to the Hackstop distribution list, receiving Antivir stuff as well from me. You'll get new versions via email then. You can get it from several other adresses and BBS's too, see ROSEBBS.TXT WG> Also, one more question. I have a good friend who would like to know if WG> there is a Windows version of HackStop. Or are planning to develop it? Maybe, but you can not encrypt Windows Resource files. And there are different file formats between Win 3.0, 3.1 and Win9x/NT. So if I plan to develop a HackStop/Win version it will be only for the Win32/NT file format. VT> I got WWPACK 3.05 beta 4, and I saw that it uses some anti-debuggin' VT> tricks! Do you think is better to use them before HackStop? Nope, most of the Anti-Debugging tricks are taken from HackStop. There are a lot of unpackers for WWPack, at least you can use CUP/386 or UPC too. ID> I tried using the shareware version in a DOS box under Windows 95 ID> but it hung my machine. I was however able to use it on DOS 6 Let me guess: You use HackStop 1.17b4 or below? I fixed a serious "segment violation" bug in HackStop'ed EXE files, which triggers W95 and NT :(( During the beta testing of HS 1.19 I have become pretty sure that HS 1.18b80 wasn't perfectly bugfree either. HackStop 1.19 will be stable. ID> There is only one other concern. My program makes use of Int1 and ID> Int3 interrupts and I am worried that the HACKSTOP program will ID> interfere with my own. Is this the case or do you release these ID> interrupts when the protected program is allowed to run? Sure, everything will be restored _after_ HackStop has done its job! If you have INTVIEW.EXE included with V Communications' Sourcer, compare its output to a HSed INTVIEW.EXE. There should be no difference. ID> Can you tell me how I can obtain a copy of radfaq from the WWW or ID> ftp. I loaded a copy from ID> http://www.smoss.org.za/prog/antihack.htm but the rar file ID> appeared to be corrupted. A search failed to find it anywhere else. 1.) It's a rather old version 2.) Try to get the newest version at SAC ftp (see ROSEBBS.TXT) ID> Please ignore my previous email about problems with Win95 I ID> realise now what the problem is. ID> I was running on my development machine and it never occurred to ID> me that just by having SoftIce loaded in my autoexec file would ID> cause hs.exe and any protected files to crash. Ok that's true.... HackStop doesn't like SoftIce to be loaded.... :) HackStop is incompatible with SoftIce :) ND> I'd like to register HackStop (the 30DM method). How much would it be That's fine :) ND> in USD? Can I send it to you in a registered envelope? About 20 USD... I see you're from Hungary... so if you want you can also send me the mount in Swiss Fr. (20 SFr) or in "Oesterreiche Schilling" (200 Sch)... You don't need to use a registered envelope - but it's safer! ND> Can I sell my program protected by HackStop if I register it? Sure all your programs protected with HS (but not HackStop.EXE itself)! AB/b/> I'd like to ask you if you could send me some of your executable files AB/b/> protection/unprotection programs that you haven't released (e.g.: AB/b/> REC) or if you could send me some sources in this subject. No i can't... it's policy NOT to release source code. Even REC.EXE is unavailable to the majority... only for registered users! All unpackers can be downloaded at SAC ftp, see ROSEBBS.TXT SE> Now, will you be doing a PE protector? At the moment: nope. I feel we can do more creative things than ripping excellent UCF code, furthermore wasting time on open standards is much more fun than discovering Microsofts PE secrets. If Windows will ever become a good operating system, making a protector is even more stupid because the combination of secure and compatible ring3 software protection should then not be possible at all. CG> Trap is better than HackStop. You fix your documentation too? R> Hey Stonehead, why did you actually join the HS project? Dos R> protectors are dead! Windows ones too - Random finished his work on PECrypt as well (it will probably stay the best PE morpher for years if it wasn't that Jibz would keep APLib updated :)) In a perfect OS, software protection doesn't exist because a protector exploits bugs by definition. I have already been mad enough to code Mess and it has been a lot of fun to help Rose. If you have a cool idea for a big program, I really advise you to ask a friend to code it together - it's great! Hope you like my changes to HS - it seems not much, but that was exactly the target. VT> Is HackStop still not unpackable? HackStop 1.19 is probably unpackable by GTR. Furthermore we have not developed a good method to detect EliCZ' EDump yet. But for some time we can say that these tools aren't easy enough to use for mortal people :) The nasty thing is that an unpacker just claims to work on one specific platform, and that a protector is supposed to work everywhere - and still kicking those unpackers. On the other hand, that's what keeps it exciting. Yes, HS86-protected files *do* run on 8086s :) > well i have visited your webpage and saw your great work. > i just wanna know something that what is the most safer "exe" > packer still exist on earth. When speaking about DOS (MZ) protector I think the best protector is HackStop. Sure there are a lot of "better/advanced" protectors, but they simply crash on Win/NT and Win/2000 :) Safe packers does not exist. Simply use UPX 1.20 (IMHO the best) and protect afterwards such files (you can use my hackupx)... [to be continued]