gEDA-dev: Verilog Obfuscator

[Trevor & Jenny Williams]

Not sure if this helps, but I just ran across HDLObf off of SourceForge
(http://sourceforge.net/projects/hdlobf).  Looks like the timestamp on the
last release is a bit old (2004) but it may be useful (or at least a good
start to writing a new tool).

Later,
Trevor Williams


----- Original Message -----
From: "Tim Freedom" <tim_freedom at yahoo.com>
To: "gEDA developer mailing list" <geda-dev at seul.org>
Sent: Tuesday, July 11, 2006 7:33 PM
Subject: Re: gEDA-dev: Verilog Obfuscator


> --- John Sheahan <jrsheahan at optushome.com.au> wrote:
> > Tim Freedom wrote:
> > > Beyond 'vo' [1] which is a free tool (not open sourced so can't
modify,
> > > enhance, fix, tweak, etc) are there any other alternatives out there ?
> > >
> > > Has anyone spent the time to code-up a perl script to do the job that
> > > they're willing to share with the community ?
> >
> > testbench, RTL or gate?
>
> RTL and gate (can't see a need for TB just yet though in some
> instances testbenches are requested off-site in which case obfuscating
> that code in order not to reveal any internals might be warranted).
>
> > Hierarchical as well as flat?
>
> It would be nice to have both - along the same lines it can dump into the
> same number of files and filenames and/or simply concat all the files into
> a single out_file.v to further "muddy-up the waters".
>
> > supporting references into distant modules?
>
> Nah, though that would come-in handy for testbench related issues.
>
> > I wrote something for mangling vcd names (vcd_mangle) once, was
> > trivial. Gate would not be particularly difficult, particularly
> > flattened gates. (which might suffice for vendor test cases, for
> > example) The role for a testbench mangler is not clear to me.
>
> Yeah, the idea in principle seems simple enough yet one would have to
> code-up a pretty intense parser (almost akin to a linter) in order to
> really do this properly (IMHO) and that takes time.  The script/program
> would need to source an external "template" (or some seed or something)
> so that reverse engineering the output would be more difficult (part
> of the mystery of what the current for-fee tools do is hidden by virtue
> of these tools being binary).  The top-level module's I/O and name would
> also have to be intact since it is the interface others will be attaching
> to - furthermore, the script/program would ideally also munge any
synthesis
> constraints to properly modify them for the new obfuscated signal names
> though this is not a real requirement for most at the moment.
>
> I'm just surprised no one has done this already, though something tells
> me its already implemented and available somewhere...  A linter with an
> obfuscate/hide output option would have been ideal.
>
> Regards,
>
>  .tf.
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
> _______________________________________________
> geda-dev mailing list
> geda-dev at moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev