Vahunz is a tool to replace meaningful names within several source files by unreadable garbage. For example, a function name like read_input_file() could be replaced by g7b() or something as useless.
Additionally, it removes comments and indention.
Supported languages are C, C++ and Java.
Vahunz is freeware, which basically means you do not have to pay for using it, and you also can redistribute it under certain conditions.
Vahunz and this documentation are copyright 1998 by Thomas Aglassinger <agi@giga.or.at>. All rights reserved.
There is no warranty for the program, to the extent permitted by applicable law. Except when otherwise stated in writing the copyright holder and/or other parties provide the program "as is" without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The entire risk as to the quality and performance of the program is with you. Should the program prove defective, you assume the cost of all necessary servicing, repair or correction.
In no event unless required by applicable law or agreed to in writing will any copyright holder, or any other party who may redistribute the program as permitted above, be liable to you for damages, including any general, special, incidental or consequential damages arising out of the use or inability to use the program (including but not limited to loss of data or data being rendered inaccurate or losses sustained by you or third parties or a failure of the program to operate with any other programs), even if such holder or other party has been advised of the possibility of such damages.
The author has no obligation to provide maintenance, support, updates, enhancements, or modifications.
For problems and comments, contact the author, but please check Bugs, Problems and Limitations before. Thank you.
For many programmers, there is no need to give the source code for one of their programs to anybody else. These will have no use for Vahunz at all.
Some programmers think that distributing the source code is a great idea, as other people can contribute to it. These also will have no use for Vahunz at all.
But several programmers often think about giving the source code to some other person, so he can compile a binary for another system. However, very often you do not trust such persons, and giving the source to one such person can be the same as uploading it to a public site.
Also very often people do not want to put their source code under
some license like the GNU GPL, as they know what is going to happen:
vast amounts of incompetent Unix-fossils will rape their source,
extending it in the brain-dead way they are used to write programs.
They will make it compatible to late 70-ties standards, so it will
compile with virtually every shabby compiler ever created since the
stone-age. They will make it conformant to the ridiculous GNU coding
standards and the messy and unreasonable disk structure widely used
for Unix-systems (with /bin/, /usr/man/
etc.) . They will clutter the source with loads of
#ifdefs, making it completely unreadable for the original
programmer. And many other nasty things certain people do not
like.
If you are among these people, Vahunz is for you.
The basic idea of Vahunz is to take your original source, which usually is reasonably commented, well indented and has meaningful names for variables and functions, and convert it to one which has not.
Removing comments and indention is a quite easy task, and works fully automatic.
Translating meaningful names in a sequence of seemingly random
characters, especially when these names are shared within several
source files, takes a bit more effort. Furthermore it does not make
sense to turn all names into garbage, as for example
printf() in a C-source is a standard function not written
by the programmer, but provided in an external library.
The best way to do this would be to write a converter that does the pretty much the as the same original compiler, and knows all the time if a name is a variable, function, constant or something else. Unfortunately, this would have been too much work.
Therefore, Vahunz takes a different approach. Basically, there are two passes:
The first pass scans all source files for names, and collects them.
The user can choose what to do with every name. For example, he can
tell Vahunz to leave the standard function name printf
untouched, but translate all occurrences of the self-written
read_my_file into garbage.
In this context, garbage means an algorithmically created,
unreadable name like for example g7b. All instances of
read_my_file will be replaced by g7b
within all source files being part of the program.
The second pass reads all the source files again, but also simultaneously writes them to a different directory under the same name. But in the copy, all comments and indention will be gone, and all names will be garbled as requested by the user. This process is called vahunzation.
To run Vahunz, you will require an Amiga running at least AmigaOS 2.04, being equipped with an 68020 CPU. Memory requirements depend on the number and size of input files, but 1MB of free memory usually should be more than enough.
Installation itself is easy: simply copy the Vahunz binary to a
directory within your CLI-search path, for example c:,
and store this manual somewhere where you will find it again, for
example in help:.
Vahunz is a CLI-only tool, but this should not cause any trouble for somebody who has written a source code in any of the supported languages.
The next paragraphs will describe how to actually verhunz a little example program consisting of only a few source files. All terms and techniques will be described when they are used first.
The source files used during this tutorial can be found in
vahunz/example. To perform all the steps, you will have
to open a CLI and set its current directory to
vahunz/example.
For most options, default values will be used, to make the whole process easier to understand. You can set several options to modify the behavior of Vahunz, but they will not be described in the tutorial, but in the reference section later on.
sepp.c, which holds main()
older.c, which holds grow_older(), a function
called by main() in sepp.c
older.h contains a prototype for grow_older()
and is included by sepp.c
Makefile, which is a simple
makefile describing how to compile the whole program for
make. This will not be touched by Vahunz.
First, you do not need to compile the example program to continue with this tutorial.
If you really want to, you will need a make-tool and an ANSI-C
compiler with a cc-like calling-syntax. By default, the makefile is
designed for gcc, but you can easily change the symbol
CC to dccor whatever, if you like.
Any more details would be out of scope.
The program itself does nothing remarkable: it simulates a guy named Sepp and lets him grow older until he dies. The output will look like:
Sepp grows older. Sepp is 79 years old. Sepp grows older. Sepp is 80 years old. Sepp grows older. Sepp is 81 years old. Sepp grows older. Sepp is 82 years old. Sepp grows older. Sepp is 83 years old. Sepp died.
There are a view variables and functions, and it should be straight forward what is going on, even when you are unfamiliar to C.
First of all, Vahunz needs to know which source files it should touch.
By default, it looks for a file named vahunz.files, which
will have to contain all filenames relative to the current directory.
Each filename has to be in an own line.
list >vahunz.files (#?.c|#?.h) lformat="%p%n"This will create
vahunz.files with the following content:
sepp.c older.c older.h
Note that the %p in LFORMAT (for "path")
would not have been necessary in this case, as there are no files
located in any deeper sub-directories. However, it also did not cause
any harm, and you should provide it when creating the file list using
list.
More complex programs than this simple example often reside within
several directories, and then you will need to specify the full path
relative to the current directory. And this is exactly what
%p does.
Of course you can also create the file list manually, but this will usually take longer and is more error-prone.
vahunzThe output should look like this:
vahunz - Make source code unreadale. Version 1.0 (10.2.98), (C) Thomas Aglassinger 1998 building name list sepp.c older.c older.h The name list has been written to `vahunz.names' and should be modified now.Although the program suggest to modify the name list right now, we are going to do this a bit later. Therefor, the contents of
vahunz.names should look like this:
EXIT_SUCCESS age exit grow_older main name print_sepp printf sepp_age sepp_name stdio stdlib
These are all names Vahunz could find within the source files specified in the file list, omitting language specific keywords and names shorter than three characters - these are considered to be already unreadable.
Note that the first column entirely consist of blanks. Do not touch anything yet.
As the name list now exists, Vahunz is ready to transform the
files. With the command line option --output you can
specify a directory where the vahunzed files should end up. If you do
not specify one, t: will be used.
In this tutorial, for some reason it seems convenient to store the
vahunzed sources in ram:vahunzed. Therefor enter:
vahunz --output ram:vahunzed
There is no need to create the directory first, as this will be done automatically when the first file is attempted to be written to it.
The interesting part of the output should look like this:updating name list sepp.c older.c older.h building vahunzed name list in memory 0 names vahunzed writting vahunzed files ram:vahunzed (created) ram:vahunzed/sepp.c ram:vahunzed/older.c ram:vahunzed/older.h All files have been vahunzed.
It tells that all source files have been rescanned and the name list has been updated, in case there would have been any new words since the creation. Of course, there weren't any yet, but its good to know that Vahunz takes care of this.
It then states that "0 named vahunzed" which means all
the names are still meaningful. However, if you take a look at for
example ram:vahunzed/sepp.c, you will notice that all the
comments and indention is gone.
To tell Vahunz to replace a meaningful name by some garbage, you
have to mark the first column in vahunz.names with a
"+". Load this file in your editor, and modify it so that
it looks something like this:
EXIT_SUCCESS +age exit +grow_older main +name +print_sepp printf +sepp_age +sepp_name stdio stdlib
Take care that you only change lines with names
you have created, and are not a function or constants
declared somewhere in the standard library, like for example
printf or EXIT_SUCCESS. The same applies to
main and stdio, as for obvious reasons the
program will not compile anymore when these names are garbled.
vahunz --output ram:vahunzedThe output now has changed a bit. Most remarkable, now tells:
6 names vahunzed
The 6 apparently corresponds to the number of "+" in
vahunz.named. If you now look at ram:vahunzed/sepp.c,
you will see that it looks a bit different as before. For example,
the original main() was:
int main(void)
{
while (sepp_age < 83)
{
grow_older(sepp_name, &sepp_age);
print_sepp();
}
printf("\n%s died.\n", sepp_name);
exit(EXIT_SUCCESS);
}
The vahunzed version might look like this:
int main(void)
{
while (g8b < 83)
{
z3v(v63, &g8b);
f_v();
}
printf("\n%s died.\n", v63);
exit(EXIT_SUCCESS);
}
The names do not necessarily have to look like this, as they are
created randomly on every invocation. In this case, for example
grow_older has been renamed to z3v.
When creating the names, Vahunz will take care that the do not already exist for another substitute, and are also not used within the names of original source. Usually they will have only three letters, but if there are many names to garble, they can also become longer.
But the best part: you can now copy the Makefile to
ram:vahunzed, recompile the program and execute it. You
will notice that it still does the same as before.
This finishes the tutorial. The remaining part of this manual is intended to be used as a reference.
There are a view command line options available. This is a short description of them. Most are used to influence the output or to change the source for getting the file list etc.
All options have a long and a short form causing the same effect.
There both flags (like --comment) and options requiring
an additional argument (like --output). You can not
concatenate several flags, read instead of -ci you will
have to specify -c -i. Option names are case
sensitive.
If this flag is enabled, Vahunz will only display a short message about usage and possible command line options, and exit immediately.
Base name for supporting files. The respective extensions
.files and .names will be appended
automatically to this name.
The default is vahunz, which will expect the file
list in vahunz.files and the name list in
names.files.
Preserve indention, and do not remove unneeded white space from the output files.
The output directory for the vahunzed files. If it does not already exist, it will be created, and also further recursive sub-directories. Of course, the device itself has to exist.
The default is t:, which will normally cause the
output files to vanish after a reset.
Shut up - do not display header message, do not show which file is currently processed and all the other things. Error messages will still show up.
On every run, Vahunz will automatically rescan all sources, and update the name list. If there are any new names found, the will have a asterisk (*) as first column. Vahunz will treat such names same as if they would have as if they would have a blank as first column.
This asterisk is only for your information. After having done several modifications to your sources, you can easily load the name list again into you editor and scan for asterisks, and then think about every new word whether it should be vahunzed or not. Simply replace the asterisk by a blank or a plus (+).
You do not have to scan for asterisks after every invocation of Vahunz, as they are preserved until the next head crash of the storage device, if you do not replace them.
If for some reason a line in the name list gets invalid, it will be ignored, and a warning will be displayed. The program will continue to execute.
They only negativ result of this could be that a name intended to be vahunzed will be preserved.
In both list, empty lines are simply ignored without any further notification
Here are a few technical details for those who are interested in such things. If you skip these paragraphs, you are not going to miss anything important for the usage.
Internally, Vahunz uses a simple data structure, which tells for every name what to do with it. For every name, an instance of this data structure is floating around in memory.
There are two lists which might link to these unconnected items: One list contains all names retrieved from the source files, and another contains only those which really should be garbled.
The data structure used to maintain those list is an AVL-tree, a flavour of binary trees that avoid to degenerate into linked lists. I did not write it myself, but used it from aminet:dev/c/BinaryTrees.lzh.
If there is a problem not covered within this section, or you found a bug, write to email address mentioned in the section Author, Copyright and Disclaimer. This also includes problems with the manual, for example if something does not work as described.
Always include the version number when reporting such things. You
can obtain it either invoking vahunz --help and read the
header line, or with the commend version as usual.
The major problem of course is that if you have used the same name for different things in your source code, or you decide to vahunz a name you should not, it is easy to end up with vahunzed files that do not even compile. This program is not idiot proof, because this would required to implement huge parts of those things full compilers do.
When removing the indention, there are still some blanks or empty lines left. This mostly has to do with replacing comments by one blank, as the ANSI-specifications requires this, and the parser does not remember if there already was a blank before the comment started. But the whole feature is of minor importance anyway, as there are numerous tools around to restore indention. It is mostly useful as a compression algorithm.
When vahunzing Java-sources, you will have to take care, that the main class name of a source still matches the filename and such things.
You must not modify files during vahunzation. For example, you can change a source after the first pass, when all names have already been retrieved. If now a unknown name shows up in the second pass, Vahunz can no more ensure that a garbled name will be the same as the new unknown word, and will abort with an error.
There are also a limited line length when reading the lists for names and files. Currently this is 1023, which should be sufficient to read most identifiers and filenames. If a line is to long, the program aborts. C-strings suck.
The number of names and files is only limited by the available memory. The source files do not have any limitations concerning the line length, as the are read character-by-character.
Currently I do not plan to extend this program in any way, as it does exactly what I want it to do, in reasonably fast way.
Obvious extensions could be to support other programming languages. However, this would make the source much more error prone, so at the moment I do not think this is a good idea.
One thing that could be interesting is commonly referred to as "The Great Renaming". During the life-cycle of a program, you often end up with inconsistent names, and you want to replace them by something more proper, but hesitate to do so as 20 other files actually use a specific function. And there are several function names that should be renamed... Modifying Vahunz in a way that it supports not only randomly created, but also user specifiable names is not that much work.
Another feature could be to display some statistics about how many names have been replaced etc.; but actually nobody really cares about that, so it's something for a rainy weekend.
Maybe if there is some interest, I release the source code, so you can compile it under other systems, too - it's mostly ANSI-C, with some stuff to create directories. But currently I too lazy to put the source directory and the Makefile in a state it is useful for anybody else than me. Of course, a potential source release will be vahunzed. As I mad some bad experience in the past with source releases, this is not very likely at the moment.