+HCU Millennium Strainer: 26 July 1999 "Here it is!"
THE MILLENNIUM STRAINER
26 July 1999
Dear readers, I'm proud to introduce the Millennium strainer, for the +HCU 2000
courses. I know that we are late: due to the problems that are listed elsewhere
we have had a three-months delay in
the presentation of the strainer this year. I would tehrefore propose that all your
for admission should be presented either to +Aesculapius, to +ORC,
to +Greythorne, or to me BEFORE THE 15 December 1999, so that you will have four
months and two weeks to solve the strainer and we will have some time for the evaluation
of all results. We hope that +ORC will send his contribute very soon, but we
will anyway publish the fourth challenge of this strainer before the end of August.
millen1.htm: Presentation of the Millennium strainer by +Aesculapius
aescu_mi.zip: This is the program "aescul.exe":
a little demonstration of how we can cripple any
debugger even if it runs as a device driver like SoftICE (R), or dwells
in the silicon world as an application-level one, like the rest (except
It is not necessary to underline the importance of this strainer and of these
studies. You know it already very well. I know in particular that protectors awaited
impatiently a challenge like the first and third ones of the Millennium Strainer:
"Anti-debugging & Decompiling Techniques". As everything (all valid solutions) will
as usual be presented in december, both those that took part to the strainer and those
that could not solve it will benefit from it. Which is good: infact we are interested in the evolution of even more
good anti-decompiling techniques. So, what can I say more: enjoy!
Reverser's first "placeholder", May 1999
I published the "tn3270" strainer-idea, that you'll find below on my main messageboard on the last day of April 1999, since
the +HCU has always published a strainer in April and notwithstanding the disarray for the
the syn-attacks against my site, +gthorne's new daughter and the disappearence of +Aesculapius,
I wanted to "keep up one of the few reversers' traditions we have".
Things have changed
for the better at the moment: my new fortress is
holding well against all sort of attacks, and http://www.fravia.org will
be redirected there very soon. +Aesculapius reappeared with lessons and tasks (restricted for +HCUkers) and
a new +HCU Linux page is developing nice thank to +Rezident. Moreover,
consider the following as just one of the
As you all know the intent of the +HCU is NOT to form a 'cracker' group. Our little "+" don't mean at
all that we are "better" than anyone else, in fact there are excellent
reversers in many groups that
could teach us quite a lot, if they cared to. Yet we strive for knowledge and
we spread reversing knowledge like
few others do, following old +ORC's tradition and steps. Our aim
is simply to put together, somewhere on the web,
protectors, coders, reversers and crackers of a specific kind: people able not only
to learn but also to teach all the many techniques
that can be useful in this more and more electronic life of ours. Secret codes with secret meanings
abound more and more, as
we very well know, and
not only inside software. It is time to reverse at least some of them, it is time to explain, and
it is always time to learn. Building on the shoulders of
each other we will go forward, reversing more and more,
learning and explaining, teaching and understanding,
towards what I hope will be
a better world, or at least a world we will understand better.
reverser+ May 1999
+Greythorne, May 1999
regarding the strainer idea in itself
i noticed it was mentioned that people working together made not a good strainer
what needs to be noted is that my suggestion was that people submit strainers - and then after they are all in, then graded and members allowed in, THEN AND ONLY THEN are the hcuers to collaborate and make a combined project out of it
now this of course assumes that people are working on the idea and not deciding that this is not a good strainer
and no mammon_ i wasnt stealing your idea ;) i found it in a macro virus actually as well - it was a dropper that echoes to debug.com just like you do (but i agree 100% that to steal it is not doing ones own work ;) *poke poke!*
what i want to see are people who want to get into areas they have not before truly mastered, in order so that the corporate world does not run the lives of us all
this is why the hcu exists in the first place
hacking and cracking are both in the agenda from day 1 (just read some of +orc's propaganda.. quite humourous and a bit much at times but getting past that, the point was made) --- reversing big brother requires more than 'jnz/jz good code' but getting around the machines and software remotely as well as the ones on your desks
personally, i would love to see some ideas as well - i am open to the idea of someone coming up with a project idea, planing it and attacking it (for those of you who have been to grad school you may be familiar with the idea)
this means that it has to be ratified by the hcu of course
the reason i suggest this is that sometimes there are great ideas that are missed, and also there are topics that as you may guess from reading the other messages on this topic - may not be interesting to the people posting for whatever reason
instant access was a rough one - i definately agree, and i for one spent months working on it when i had the chance -- part of which because it wasnt exactly the clearest english for that matter but then technical documents are never extremely clear anyhow
in another life i might have been a linguist rather than a computer type, but then thats why i write well, and tend to not get the greatest 'grades' on my technical drafts -- to much clearer to read than the professorial types like (if it's readable it doesnt belong in a computer science classroom...)
but anyway, i would love to see some ideas, and i would also love to see what comes of the original strainer idea posted above
much of the reason hcu has been slow going lately is communication - finally
egroups has fixed their size problem and we can now use it for hcu mail lists
(some lists being the primary method we have been using until these last few
months when servers changed and well, now things are automated in such a way
that time can again be on our side)
it takes work to make an organization live, and though that term applies loosely to hcu - which is made up of lone wolf types with a desire to learn, members do need to think of challeneges
if i were to make the most of a suggestion to those of you who are new and wish to get better at cracking, and in preparation for hcu classes, GET FAMILIAR WITH WIN32 ASM - if you can write programs in it, you have a serious step up on cracking win32 apps. So much has happened lately to make this easy, that it is important to learn it.
well, before i go into anything else, and before i have any more coffee, i am done for now 8^)
please post any responses on reverser's main messageboard, i would love to hear your ideas - or get on the hcuml and post there, the list is only newly running again and it takes usually a few weeks to get back on track
Quite a negative judgment of reverser's and Steinowitz proposal :-(
As you will read below,
+Aesculapius is preparing the "real" Millennium strainer, so we will see what we do with this
proposal of ours. I still think, Olorin notwithstanding :-) that meddling with the TN3270
protocol is quite an interesting
endeavour... raeders will judge!
Disclaimer - This is only opinion, although it contains references useful to anyone attempting
Firstly, what has been set is nothing more than an over elaborate
implementation of back door programs such as Back Orifice, NetBus and Unix rootkits.
remote execution section totally relies on the ability beforehand to either trick a user into
running a trojanned program, or having access to the computer beforehand.
REserver.exe and REclient.exe other than BOserver.exe and BOclient.exe with a tn3270 added on for
no particular reason. "Use the TN3270 protocol for this and you'll be able to use this as a full
shell account! And you don't need passwords to verify your access to the server" - Oh wow.
Unlimited access without passwords. That sounds just like the rootkits that any decent security
site carries, eg packetstorm, before antionline shut them down. Luckily for antionline, they got
a copy of all the files first, at www.anticode.com. You
can find rootkits and telnet servers to sit on a port there.
Using previously configured
associations between a web browser, windows, and the command line represents little more than an
overly complicated set of interfaces, better suited to a GUI or simply executing the
Rewriting a tn3270 client, an interface developed for IBM mainframes from scratch
has bugger all to do with reverse engineering and nothing to do with good programming practice.
Save yourselves the trouble, and checkout http://www.geocities.com/SiliconValley/
Peaks/7814/ for a windows client with complete source, and http://www.hgsys.demon.co.uk/linux.htm for a
linux client and source.
For further information about tn3270, checkout http://www.tn3270.com/ or http://www.ci
Hmmm, to make things
tricky, lets throw in a little regular expression and pattern matching. Yawn.
to to a remote workstation just once, why would you install a tn3270 server? On a non-standard
port? Just install the personalized version of BO2K. Virtually each server is unique, running on
a different port with a different protocol, and responding to different types of encryption and
pass-phrases. Nothing is defaulted.
The last section - The only part to have any real
reversing content, taking telnet.exe and adding in the ability to parse the commandline so that
not only the host and port are recognized, but an optional extra parameter that represents the
command to be executed. Hmmmm telnet to a telnet server, and execute a command. BUT *and this is
the tricky bit* put that command on the command line. Oh, and do it purely in assembly while
working with a pre-built executable. That'll be some patch.
Since when did the HCU become
a bunch of extremely inefficient hackers, writing ridiculously over complex back doors and
+HCU Millennium Strainer ~ Part 1
Remotely Executing on the Web
Steinowitz (and reverser+), May 1999
Since reverser+ is very busy with rebuking the attacks
on reverser.org, he asked me to write down how the
Millennium Strainer should be. Both reverser+ and I think
that Reverse Engineering on the web is the future,
therefore, this strainer is about Remotely Executing.
While cracking software appz is done by the dozens of
crackgroups which exist at the moment, elite reverse
engineers like +HCUkers should move on to where the
future is: the Internet.
Because of this, the +HCU strainer should not only
test your reverse engineering skills. An elite reverse
engineer needs knowledge of coding, reverse
engineering and the Internet. This strainer
requires you to know quite a lot about all three.
Let's proceed with the assignment!
The main objective of this strainer is to make it
possible to run any executables you choose on a target
machine where you have had access. Let me explain to
you how this should work.
- To make it possible to run any executables on a
target machine, you should write two executables
(REserver.exe and REclient.exe).
- Write these executables in C, using ANSI C
functions where possible to make your programs as
portable as possible.
- REserver.exe should run on the target machine,
accept any connections requested by REclient.exe and
then execute what REclient.exe orders.
- REserver should then catch the output of the
program (and the exit code of the program) and send it
back to REclient which shows it to the user.
- When you enter tn3270:// in your browser's address
textbox, Windows will automatically start Telnet.
- The TN3270 protocol is a rarely used telnet-like
protocol, invented by IBM.
- Re-associate the protocol with REclient.exe.
- Then, REclient.exe should be executed by entering
would run 'C:\Batchfiles\Run.bat' on a Windows system
would run '/bin/cat /etc/passwd' on a UNIX system
- Decoding/encoding works like this: slashes (/) are
replaced with .s, backslashed (\) are replaced with
.b, colons (:) are replaced with .d, all other special
characters (non-alphanumerical) are replaced with a
dot followed by their hexadecimal ASCII codes (for
example, a point becomes .2E and a space becomes .20).
- REclient should decode the argument passed to it
by the browser, connect to REserver running on the
target machine and make REserver start the executable
requested by its user.
- Find the specifications of the TN3270 protocol and
implement it in both your server and client.
- If you managed to do all this, you should proceed
implementing another function. Before, I only talked
about catching the output of a program and sending it
to the client, but what when I want to run /bin/bash
or command.com? Indeed, we should also allow users to
provide information (or new commands in case of a
shell) to the executables running on the target
machine. Use the TN3270 protocol for this and you'll
be able to use this as a full shell account! And you
don't need passwords to verify your access to the
server (providing REserver.exe is running)!
- REserver should be able to handle more than one
connection at the same time (with a maximum of 10).
- Think about how you can make sure that REserver is
always running on a target machine! Think about adding
a RunServices key to the Windows registry. Besides,
for UNIX systems, you could write a sh script which
checks if REserver is still running. Set a crontab for
this sh script and you're settled even when your UNIX
- Don't forget to implement decent error trapping
A complete solution should at least cover solutions
for both Windows 95/98 systems and UNIX
systems. Read 'Portability' for more info on this.
After coding all this and testing it well, it's
obvious that this isn't as easy-to-use as it should
be. What we need are a couple of decent interfaces
which make it really easy for users to use REclient.
Encoding commands like the examples I gave is easy to
do, but I don't want to be forced to look up the
hexadecimal ASCII codes for all kinds of special
characters. Let's describe a couple of interfaces you
should make it you want to do it perfect. I would
waste time if I would explain to you why these
interfaces should be web-interfaces. :-)
If you don't know how to make webpages with
standard HTML tags: learn it right now! Don't you dare
to use M$ FrontPage (or any other WYSIWYG HTML editor)
for this assignment, because that would be a serious
Notepad or pico/gvim is good enough for our
Alright, write a webpage where a user could enter
1) hostname/IP of the target machine and 2) the
executable which REserver should start. When this user
hostname/IP and command to execute in the URL format I
tn3270://target_machine/encoded_command. Change the
browser's location to this new URL and your
REclient.exe will do what it should do... (If you
re-associated the TN3270 protocol with it!)
Interface 2 - Perl
Write a Perl CGI script which does exactly the same
that it should be a CGI script! (Thus: it shouldn't be
executed as a program from your command prompt. If you
don't have installed Perl on your local workstation,
you could install your script on a webserver where you
have CGI permissions. Don't forget that you'll still
need REclient.exe installed on your local
Note If you're a real +HCUker, you also
write Perl scripts which do exactly the same as
REserver.exe and REclient.exe! Believe me, that it's
easy if you finished your C version and know something
about the differences between C and Perl!
Interface 3 - C (again)
Last, but not least, one more web-interface. As a
matter of fact, this one isn't just an interface. This
one should be both web-interface and REclient
in one. I think you already understand what I mean
with this. No? Ok, read on and you'll understand!
I started this essay writing that the Internet will
become more and more important for all elite reverse
engineers who want to keep up with the best.
Therefore, for those who don't already know all about
this, it's getting time to learn everything about CGI
programming. Remember: you can't reverse engineer if
you can't engineer! Why did you learn coding in
assembly? Indeed, you couldn't reverse engineer
without it! That's why this strainer also requires you
to know quite a bit about the Internet and CGI, a.k.a.
Common Gateway Interface. And since most servers are
UNIX-based platforms, it's also getting time for all
those Bill Gates-people to shutdown Windows, restart
with some UNIX platform and see how long a system can
be stable without restarting at all!
Remotely executing whatever you want sounds good,
but remotely executing whatever you want by ordering a
remotely hosted client to arrange this sounds even
better! I really hope you can follow my deep thoughts.
If you don't: get a glass with your favourite
cocktail, sit back and relax, enjoy your drink and
think about it. Believe me: it'll work! :-)
For those who didn't already understand: write a
CGI program in C which provides your with a
web-interface. When you enter data in the
web-interface and submit it, the CGI program should
behave as it were REclient.exe. All output should be
correctly formatted HTML code. This CGI program should
be installed on a webserver where you have CGI
permissions. To prevent unauthorised users from using
this interface, you should implement a password
protection. Write another CGI program in C which the
system administrator (you) can use to add/remove users
to the user list. Passwords should always be stored
in an encrypted format.
When I'm allowed to login on a UNIX system called
target.com only once, I can upload the source of
REserver, compile the program and run it. At that
point, I have unlimited access.
I installed the REinterface CGI program I wrote in C
on my ISP's server, www.myISP.com. I can now access
this by surfing to
http://www.myISP.com/~switz/REinterface. A nice
interface appears on my screen. I enter the name of
the target machine, target.com. I also enter the
command I want to run on the target machine: '/bin/cat
/etc/passwd'. Furthermore, I enter my login name and
password. After I did all that, I click the button. A
couple of moments later, the output appears on my
screen: the contents of the file /etc/passwd! (And, of
course, if the system admin of target.com configured
his system well, I will only see 'No access to
/etc/passwd' or an almost empty (shadowed) password
file, but our REinterface and REserver work fine and
that's the main point!)
Please note: This REinterface sure is a nice
piece of web engineering, but you cannot
provide any input to the executable after it started.
For example, you can't provide any commands to
'/bin/bash' or 'command.com' after you started it! A
large benefit of this interface is that you don't need
to install REclient.exe on your local machine: you can
use this interface from wherever you are, provided
that you have access to the Internet.
Reversing M$ Window$ Telnet
When you are able to accomplish everything above,
you have proved that you have knowledge of both coding
and the Internet. But you're not ready yet, no way! A
Millennium Strainer isn't something which you solve in
a couple of days! Take your time...
Some time ago, I wrote that telnet.exe is the
program normally associated with the TN3270 protocol.
Well, how about using that?? Notepad.exe has been the
target of many reverse engineers: I have seen several
Notepads with added functionality. I think that the
standard M$ Window$ 95/98 Telnet executable is at
least as interesting: a full reverse might be a very
good exercise. However, that's not the objective of
this strainer. Combine the section 'Remotely
Executing' with what I just wrote and you'll
understand what you're to do next.
When you arrive at this point, you already have
written REclient.exe and you have written several
web-interfaces. But there's one more client we want:
use your reverse engineering skills to create a client
out of telnet which you can use in combination with
the same REserver as you used in all cases before.
Yes, you're totally right when you conclude that you
only have to code one server, but quite some
Dive deep into telnet.exe. All code needed to
communicate with a target machine is already
available, but where is the code you need to modify?
Micro$oft helped you a great deal by leaving so much
wasted space in the executable: there's quite some
room to add your own code. However, I wouldn't be
surprised if it would be necessary to add more.
Here are some ideas about what you could try to
achieve with telnet.exe.
- Don't associate the TN3270 protocol with
REclient.exe. Instead, modify telnet.exe in such a way
that it starts REclient.exe when telnet is started
with an argument starting with tn3270://. (Telnet
immediately closes.) It's not an efficient way of
associating the TN3270 protocol with REclient, but it
proofs that you know something about reverse
engineering. When telnet is started with a normal
telnet:// argument, normal communication should
- You could also try to make telnet.exe work as
REclient.exe. As I said before: many functions
necessary for communication are already present.
(Check out the differences between the telnet and
tn3270 protocol if you managed to implement the tn3270
protocol in your REserver!)
- When you try to make telnet.exe work as
REclient.exe, you could choose to replace functions
not needed anymore. But you could also choose to keep
it possible to use telnet.exe as your 'normal' telnet
- Finally, I always find it very annoying that
telnet.exe only knows a couple of 'standard' ports:
telnet, daytime, echo, qotd and chargen. Get a list
with standard ports and add those ports of which you
think they are useful to add. (Don't forget to add the
port of your REserver! And don't forget that
connecting to that port doesn't work like a normal
The more you do, the better! Just do what you think
you are able to do. The other parts of the Strainer
are pretty straight-forward. You should use your
imagination (and Zen skills!) with this part: think of
what you think would be a nice change to
telnet.exe, as long as it is related to the rest of
Since it's almost getting time for you to start
with this assignment, I'll mention a couple ideas of
things you could do to achieve a better final result.
When you send in your results of this assignment, only
sending (commented!) source codes, binaries and
scripts isn't enough. Why did you do what you
did? And how did you do it? Answer those
questions in one or more essays about the development
of your results. And since we may assume that you
don't develop your final 'product' out of nothing, it
probably wouldn't be a bad idea to include some
pre-final versions of your programs. Think about
I already mentioned that you should at least make
it possible to compile REserver and REclient (and
REinterface!) under both UNIX and Windows. To make
your programs that portable, you need to use ANSI C
functions as much as possible. There are some
functions, however, which you'll need, but are not
portable. Since we don't want multiple versions of
source and header files for Windows and UNIX, you'll
have to think of something else. The solution is easy:
use some preprocessor directives and a Windows/UNIX
Since there are always differences between C
compilers, it could happen that you were able to
compile your executables under both Windows and UNIX,
but anyone else trying to do the same (with another
compiler) could have troubles compiling. To avoid
this, don't forget to mention which compilers and
operating systems you used. Include all version
I already wrote this before, but I can't repeat it
often enough: the more you do, the better.
Furthermore, you should work slow and basic. Don't try
to do everything at once, because you won't succeed if
you do it that way. Completing an assignment like this
requires knowledge, patience and a little Zen. But I
think it's even more important to show that you are
willing to learn and that you're capable to do so.
A journey of a thousand miles is started by
taking the first step.
-- Chines proverb
Civilisation advances by extending the number of
important operations we can perform without thinking
-- A.N. Whitehead
After these wise words, there's not much left to
say. You should solve and send in the strainer before
mid-September, as usual. If you think you're ready
before September, I really think you haven't done
enough, even if you did everything I mentioned in this
essay. There's so much else you could do to make it
even better! (Think of a good name for your project!)
Use the time you have!
I'm really anxious to see the results: I can hardly
wait till reverser publishes the results on his website.
(That will take some time though.) In the mean time,
I'll see if I have enough time to complete this
+reverser and Steinowitz
Mail +reverser at reverser_(at)yahoo(dot)com if you have any questions
concerning this +HCU Remote Execution Millennium
Master +Aesculapius intents
16 July 1999
> By all means, +Aescu.
> The surrogate of a strainer I have posted on my site
> was just intended as a "place-holder".
I'm glad; you'll have the strainer in one week
(maybe less than that) because I
need to polish some minor aspects of it. The targets
will be: Challenge 1: CodeSafe v.
3.1, Challenge 2: CuteFTP v. 3.0.2, Challenge 3:
Restorator 2.5 (possibly, I'm still
thinking on this one), Challenge 4: I'm thinking in
leaving this space empty with a
note to +ORC in case he wants to contribute, if he
doesn't answer I'll include a fourth
target (Cdrwin 3.7d).
Challenge 1 will require knowledge in PE header
layout, Structured Exception
Handling, Debug API Set and SoftICE detection tricks.
Challenge 2: Undefeated until now. Server
authenticated. It will require knowledge
on WSA, CRC, and internet protocols.
Challenge 3: Tough target and a great tool.
Challenge 4: CDRWIN 3.7d (if +ORC does not send
or any of +you doesn't want to
propose an alternative target). Cdrwin key system has been defeated
by only two crackers in the world
after 4 years of attempts (I was the first one, the
other guy is retired from
So the strainer is tough, but not that tough and
it will explore almost every
attribute a cracker worth of entering the +HCU should
have. Internet use will be
> If you want to start, beside sending me the new strainer
> (we'll postpone the admission frist accordingly),
> you could send me your first lesson for the '99 levy: I'll
> open a password protected part of my fortress so that +Hcukers
> only (or almost, but those that will anyway find their way
> there will be also pretty good AFAICJ :-) will thus partecipate
> and give their precious feed-back. If you prefer an emaillist
> approach just tell me, I'm sure that +Zero and +Malattia
> would gladly take care of that.
Whatever, the page with password and participation
of some important personalities
(not necessarily all of them belonging to the +HCU) is a good
I'll send you my first lesson in about two days
(it is ready, but I need to polish the
> Happy to have you back on board.
> Lotta things to do.
> Let's sail and reverse along!
> Later, +brother
nice to see you too...
20 JULY 1999
Here goto99co.htm the entrance to the +HCU 1999 courses, by
+Aesculapius and other older ones :-)
VoxQuietis' critics (July 1999)
An intersting point: secrecy as cause of decline. I partly agree,
with VoxQuietis, actually. I think I don't need to demonstarte that I don't
like at all the idea of keeping any sort of
knowledge "inside a box". Unfortunately we have until now found no other
way to speed up work on some
'delicate' matters without giving at the same time ammunitions for
the lamest sort of hacking & cracking to all the "script lamerkids" out there.
Actually the "strainer" idea itself - take a look at this
year strainer, for instance - is IMO
a good way to go public and keep restrict AT THE SAME TIME.
Dear reversing colleagues,
There is a long thread on accessing the "secret" HCU
which proves a vast interest in the topic, irrespective of
the fact that some
people, which are insiders of course,
are quite reluctant having such a topic discussed
Nevertheless the interest is here, as the previous discussion
shows, and, in my
opinion, it is a interesting one, since
quite a couple of things are treated, that all the
of this messageboard are interested in:
The HCU pages are supposed to
contain information on S/W
reverse engineering. They are hidden. So the basic insticts
every reverser around will be trigged by the mere presence
of these pages.
other hand one should ask oneself, what is the actual
matter of both the HCU pages, this
year's strainer, and a
possible hacking of the HCU pages? And that's were reflection
comes in, which here usually is called "reality cracking".
I think we all could agree
that "cracking" or "S/W reverse
engineering" more or less is targeting on the inner working
of your own computer. Maybe there is a little bit of warez
stuff, too. But in the long
run, people are studying at
Reverser's, or at HCU, since they are compelled by the
undercover actions of S/W, e.g. by M$ mm256.dat or word
unique user ID. And of course
there is the fascination of
exploring the way someones computer works.
It should be
clearly stated, that this interest is very much
different from the classical "hacker", who
usually gets is
satisfaction from sniffing inside remote computers. Thus the
more interested in transmission protocols than in
recovering S/W flow of operation.
And that's the point, where this year's strainer comes in:
Reverser's challenge is much
more hacking oriented than all
the strainers were in the past. To put it bluntly, the 1999
strainer will attract a person interested in hacking more
than ever. Thus it should be
obvious, that hacking the
HCU pages directly, i.e. without solving the strainer,
an attractive solution.
But still the question is not answered, what would be the
price of hacking the HCU pages, i.e. what kind of information
will be located within the
essays/courses. Well, its easy
to speculate on that, but who does really know ...
principle of sharing knowlege ultimately would demand
to publish all the essential
informations. And it would
ask for a quick publication, because even to withhold
information temporarily finally would damage the ethic
constitution of this community.
So it is evident, that secret information in the long run
would give the root of
declination of the HCU. Of course
actually there are no signs that things allready started
to move to this direction. But whenever there are things
kept away from the public's
eyes, there is an inherent
danger of something I'd like to call the "Freimaurer-syndrome".
Remember that the Freimaurer long time ago tried to advance
democracy (or at least some
democratic issues, as free
speech) within secrecy. We all know, where this approach
ended. And we all know, that it due to the internal construction
needed to end like it
You'r deep inside reverser's pages of reverse engineering
Is reverse engineering illegal?