-----------------------------------------------------------------------------
    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 HSed 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 isnt 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]
