Time of Death

[Tim Haughton]

Hi all, it's got to that time again where I'm about to call "time of death" on Eziriz. No update in a year, no communication.

What's the most recent communication you've had from Denis?

Tim

[Paul]

No communication at all after numerous tries since November 2010. I'm
now using Infralution.

Regards,
Paul

[Michel de Champlain]

Hi all,

I've been using Eziriz since many years, the support was not an issue for
me since my app (compiler and VM) are written with features of .Net 2.0
(I had, and still have no need for the recent .NET features).
In other words, I have a .Net Reactor license 4.1.0.0 (2009).
The only disadvantage, the full obfuscation with Eziriz was slowing
down quite noticeably my executable apps (.exe).

Maybe with this "kiss of death", it is time to find a better
solution for an obfuscator...

My question: For those who has experienced other products, any
excellent replacements out there? Infralution seems offering a
different avenue
in encrypting instead of obfuscating... any reviews to support their
claims in better protecting intellectual properties (IPs).

Many Thanks in advance for good pointers or references!!

Michel de Champlain, Ph.D.
CTO, Chief Scientist
DeepObjectKnowledge Inc.
DeepObjectKnowledge.com

md...@DeepObjectKnowledge.com

Michel is the creator of B# (www.BSharpLanguage.org),
built for today's embedded system developer in mind.

---------

"The B# language is a personal project to introduce modern
programming techniques to the embedded system programmer who like me,
has sought a better way to develop applications which are portable,
reliable, and reusable and who does not wish to sacrifice size, speed,
and simplicity to do so. Begun nearly 25 years ago, B# and its virtual
machine have evolved over the years to meet these criteria with the ongoing
support of seminar participants, colleagues, and industry.

I understand and empathize with the programming frustrations of the
embedded system programmer. I hope that my efforts go a long way to
making the implementation of small footprint embedded systems a more
pleasurable and productive pursuit."

Cheers,

--- Michel

Quoting Paul <paulp...@yahoo.fr>:

> --
> You received this message because you are subscribed to the Google
> Groups ".Net Reactor Support" group.
> To post to this group, send email to net-react...@googlegroups.com.
> To unsubscribe from this group, send email to
> net-reactor-sup...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/net-reactor-support?hl=en.
>
>

[Glen Harvy]

Hi,

I have been using .Net Reactor for years and it was and still is the
best tool for protecting your software given it's pricing. It has stood
by me with the leap from .Net2 to .Net4 as well as many many code revisions.

I have also recently been convinced that obfuscation as a method of
protecting IP is almost a waste of time and effort. Don't get me wrong,
I have spent years writing my pet project and hate the thought of
someone using MY code for free. Nevertheless, the effort they would need
to take to actually use the code would be better spent on improving the
code. The code itself is something any competent programmer would
already know about and use. The structure of my code may well create a
lot of mirth.

The decision regarding obfuscation was not taken lightly nor without a
good deal of thought. The ability to start using AOP finally tripped the
balance as in my case AOP was severely limited by the obfuscation process.

Having taken the above decision I still wanted to protect my IP
particularly from student hackers and the like. So after disabling
obfuscation in .Net Reactor I made sure that Anti-ILDASM worked and it
does. ILSpy, JustDecompile and a number of other ILDASM tools all failed
to show the contents of my methods.

Some of my code includes hard-coded passwords so I selected String
Encryption and added the specific strings I wanted encryted to the
inclusion list. I'm pretty sure the US Government will be able to
unencrypt it, if not WikiLeaks will certainly be able to achieve it but
I can live with that.

Strong Name protection and code signing add further safeguards.

Naturally, .Net Reactors licencing system has never let me down. Well
there was one time but that was because the documentation for .Net
Reactor was poor however one quickly learns.

I really don't know what 'Time of Death' is supposed to mean but I can
see myself using it until such time as an OS or .Net5 no longer works
with it. Even then, I wouldn't be surprised to see a new release from
Eziriz.

As a method of protecting and use of your software, I still believe .Net
Reactor without any support is worth the money.

Regards,

Glen Harvy.

[Tim Haughton]

On 18 March 2012 21:40, Glen Harvy <glen...@gmail.com> wrote:

I really don't know what 'Time of Death' is supposed to mean but I can see myself using it until such time as an OS or .Net5 no longer works with it. Even then, I wouldn't be surprised to see a new release from Eziriz.

As a method of protecting and use of your software, I still believe .Net Reactor without any support is worth the money.

Hi Glen, I've always felt a great degree of sympathy for Denis. I speak from experience when I say that being a 1-man software company isn't easy, and he has a couple of products that most 1-man software companies would kill for. So when I set up this group, it wasn't out of frustration, it was really just a way of lending a hand to a fellow micro-ISV'er.

I started using Reactor in 2007 for a consultancy gig I think, and use Intellilock for my own products. And like you say, they work, and they work well. I don't need support really, I'm familiar enough with the tools, but I need to know that the products are still "alive", simply because when you have thousands of users worldwide, and you have built a licensing system around Eziriz, if it stops working for some reason, I would be in a difficult position.

Even if I go with something like Babel, I would end up writing my own licensing mechanism anyway, so perhaps I will simply not rely on the Eziriz licensing. Obfuscation is, after all, something that is much easier to change than a licensing mechanism.

Tim

[Paul]

Hi,

I was actually quite happy with Intellilock which was a great all in
one package for the price. I was initially using it to protect my
assemblies and eventually was going to use it for licencing. The only
support I needed was moving it to my new computer. When I didn't get
any reply that slowly triggered off the search for something else. I
didn't want to get stuck with a dead product.

Michel,
As for Infralution, they use encryption to protect assemblies. DLLs
are added to a bootstrap project as encrypted resources. JustCompile
and ILSpy can't read the encrypted files. I like it, at first it was a
bit difficult to adapt to, but no obfuscation actually makes it easier
for me to use. From what I understand, their philosophy seems to be
that you're better off spending more time on your actual app than
trying to protect it in so many different ways. The encryptor seems to
be enough for me, plus I don't think theres a 100% protection system.
There are some people on their forums that use obfuscation and then
Infralution encryption which may be over the top. Its a bit more
expensive because licencing and encryption are separate packages.

Hope that helps,
Paul


On Mar 19, 10:50 am, Tim Haughton <timhaugh...@gmail.com> wrote:

[Tim Haughton]

The problem of course with *just* encrypting the files, is that they need to be decrypted in order to be loaded into the runtime. And as soon as they're decrypted and loaded, they can be dumped back out.

If you want an interesting way to package assemblies, you can try this:

http://richarddingwall.name/2009/05/14/wpf-how-to-combine-mutliple-assemblies-into-a-single-exe/ 

Works fine with WPF too. This method could be quite easily coupled with a roll-your-own encryption.

But as you correctly point out, all these techniques are breakable. It's just a matter of inconveniencing the attackers.

Tim

[Andrew McKay]

One of the possible "benefits" from this situation could be that the bad
guys might persuade themselves that there's little point sacrificing
their time trying to crack a protection scheme which has clearly lost
the will of the user community, and which has few followers in the
marketplace.

I feel that it is a pity that the author has chosen to take such a back
seat with supporting their products. He is obviously a talented
individual and could easily earn some big bucks from his efforts. There
may be reasons which we are not familiar with to explain the situation -
he could potentially be facing some real life hardships for example.
However it might also be that he finds interfacing with customers to be
a major challenge and thus avoids doing so. If that were the case then
it's a pity he hasn't been able to work with someone who could handle
the customer stuff.

A

I use BullGuard to keep my computer clean.
Try BullGuard for free: www.bullguard.com

[Tim Haughton]

On 19 March 2012 13:54, Andrew McKay <and...@kazmax.co.uk> wrote:

He is obviously a talented
individual and could easily earn some big bucks from his efforts.

I've consistently thought that he should double his prices and hire a full time guy who is split between support and development. Most micro-ISVs are talented developers, and lousy businessmen :)

Tim

[Andrew McKay]

> I've consistently thought that he should double his prices and hire a
full time guy
>who is split between support and development. Most micro-ISVs are talented
>developers, and lousy businessmen :)

I can't remember the actual numbers now, however one of the early things
I learnt (okay, heard) from being a member of the ASP as told by people
who earn some serious big bucks within the shareware industry went along
the lines that 25% of the time should be spent developing, 25% on
general admin/support, and 50% on marketing.

The problem with being a techie is that marketing is something which can
typically be seen as a timewasting exercise. However the logic speaks
for itself - if you have the world's best product and no-one knows about
it then your sales are guaranteed to be poor. On the other hand, if you
have an average product which everyone has heard of then sales could be
quite healthy. You only need to look at some products offered by big
name companies to see that.

A

[Paul]

Tim,

Thats the down side, which is why some people obfuscate and encrypt.
But doing both seems to cause headaches for those people. Which brings
us back to why Intellilock was so convenient.

Paul

On Mar 19, 2:45 pm, Tim Haughton <timhaugh...@gmail.com> wrote:
> The problem of course with *just* encrypting the files, is that they need
> to be decrypted in order to be loaded into the runtime. And as soon as
> they're decrypted and loaded, they can be dumped back out.
>
> If you want an interesting way to package assemblies, you can try this:
>

> http://richarddingwall.name/2009/05/14/wpf-how-to-combine-mutliple-as...

>
> Works fine with WPF too. This method could be quite easily coupled with a
> roll-your-own encryption.
>
> But as you correctly point out, all these techniques are breakable. It's
> just a matter of inconveniencing the attackers.
>
> Tim
>

[Ivan Borges]

On Sun, Mar 18, 2012 at 6:40 PM, Glen Harvy <glen...@gmail.com> wrote:

Hi,

Having taken the above decision I still wanted to protect my IP particularly from student hackers and the like. So after disabling obfuscation in .Net Reactor I made sure that Anti-ILDASM worked and it does. ILSpy, JustDecompile and a number of other ILDASM tools all failed to show the contents of my methods.

 

Hi Glen. 

 

Have you tried de4dot? ( https://github.com/0xd4d/de4dot )

 

If so, were you able to protect your assembly (obfuscated by .Net Reactor or Intellilock) against it?

 

[Glen Harvy]

No, I haven't tried de4dot. I no longer obfuscate my code either.

[Ivan Borges]

But that thing will also break Anti-ILDASM, since it will read all the contents of your methods.

[Glen Harvy]

Hi Ivan,

So you have used de4dot to read unobfuscated but anti-ildasm protected
code. Is that what you are saying?

If so, what did you learn from the code you read? Was de4dot able to
read or decrypt the encrypted strings?

On 22/03/2012 4:27 AM, Ivan Borges wrote:
>
> But that thing will also break Anti-ILDASM, since it will read all the
> contents of your methods.
>

[Ivan Borges]

Yep, that is correct. I tried it on one of my applications protected by Intellilock.

It got all back to orginal, I tested opening the .EXE it produced with Reflector and could read everything. It was really disappointing, to say the least... I have been evaluationg other products, since we won't probably get any update from Eziriz, who could work this out and release an update to avoid this tool. The lesson I got from this situation is that you want to work with an obfuscator/encryptor product coming from a company that will keep a close eye on things like this and the produce an update the soonest. It is an endless job...

[Glen Harvy]

So let me get this right - If I start to obfuscate my code again then
de4dot will not be able to un-obfuscate it? Like for the foreseeable
future, de4dot will not be able to deobfuscate my code? Or are you
saying it doesn't matter what I do because de4dot can deobfuscate code
obfuscated with .Net Reactor now.

I'm beginning to understand why most people don't bother with
obfuscation at all. Seems like a waste of time to me.

[Ivan Borges]

If you start obfuscating your code now using current version of .Net Reactor, de4dot will break it. If we had Eziriz working on it and releasing a new version to avoid what de4dot does, we could probably carry on with this fight.

So, you are right, it doesn't matter what you do now with .Net Reactor.

That is why I think that if we work with some company that will keep supporting the product and its user base, it might not be a total waste of time... :-)

We know there isn't a 100% solution on IP protection, so the only way of having any sort of peace of mind is to make the thieves' lives the most difficult possible.

[Glen Harvy]

I don't exactly come to the same conclusion that you do.....

If .Net Reactor is updated later today, I would guess de4dot could
probably be updated tomorrow and by the day after we are all back to
square one.

From what you have told me, for some time now, my software that was
protected with obfuscation by .Net Reactor has been able to be cracked
by at least de4dot and I suspect may also have been able to be
deobfuscated by other similarly designed hacking tools. To me, the horse
has already bolted.

I fear you are never going to have peace of mind.

Now would you like to start another thread but this time with regards to
.Net Reactor's other excellent function - Licencing protection. Is that
a waste of time as well now I suppose.

[Ivan Borges]

Well, I guess I did say "it is an endless job".

Nope, never thought I would have total peace of mind, but wouldn't mind have the most possible.

And about the new thread, not the case, it would be worthless. I just wondered if you had come with some kind of solution for the de4dot disassembler, since you seemed to be so sure about the ILDASM protection. As this doesn't seem the case, I will carry with life the way it is...