<div dir="ltr">i would like to add that in this package the focus is more on binary obfuscation rather than source-only obfuscation<br>i.e. if you ship some software that contains some algorithm that you want to hide from a reverse-engineer<br>
the basic idea is to make it hard to analyze the code and reconstruct the algorithm even if it passes through a compiler and regardless of optimizations it may apply<br><br><div class="gmail_quote">On 21 November 2010 02:18, Francois Pichet <span dir="ltr"><<a href="mailto:pichet2000@gmail.com">pichet2000@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">On Sat, Nov 20, 2010 at 7:00 PM, OvermindDL1 <<a href="mailto:overminddl1@gmail.com">overminddl1@gmail.com</a>> wrote:<br>

> Well since no one else replied, and I think it is due to this question<br>
> I am about to ask, why would you want to obfuscate C code?  It is hard<br>
> enough to read as it is, want to make it more readable, not less<br>
> readable, so what is the purpose?  And do not give me a reason about<br>
> needing to make code harder to read, just distribute a library then,<br>
> not code, or change your license.<br>
<br>
</div>Gimpel software ships FlexeLint for C/C++ as obfuscated code so you<br>
can recompile it on your host without (easily) reverse engineer it.<br>
<br>
Sometimes shipping a library is not practical if your customers are<br>
using all kind of weird platforms, ABIs and compilers. That's why<br>
almost all C++ libs ship with the source.<br>
</blockquote></div><br></div>