EXECryptor reaches version 2.1.21

Many people are waiting for the next release of your great product,
and you are ready to release. You want users to use your program and
to pay for it, as all companies do. But you also know, there's many
people who doesn't want to buy your product but want to crack it and
offer it free to others. So, you are looking for strong and unbeatable
protection against these graceless thieves ... We have heard you, and
your wait is over.

EXECryptor is a powerful software tool that provide developers with
software protection from reverse engineering, analysis, modifications,
and cracking. Its main difference from other protection tools is a new
and unique metamorphing code transformation technology.

With EXECryptor the protected code block is not just packed or
obfuscated like many other packers, but also disassembled into
nondeterminate transformations, effectively scrambling the visible
logical code structure and making it impossible to reverse. After the
code transformation, it remains executable and working as it is
supposed to but it cannot be analysed, modified, or circumvented.

It is not just a question about code encryption but also code
transformation. You can optionally wrap additional parts of your code,
at a source code level, in special flags which then transform into
virtually impossible code to trace, crack, or bypass. Protected code
blocks are never 'decrypted' during execution they remain in their
transformed code state. Code restoration becomes an NP-hard problem.

EXECryptor has the innovative very powerful antidebug, antitrace and
import protection features to stop the latest cracking software.

EXECryptor allows to use short registration keys of 12/16 characters
long, based on a new generation of our HardKey algorithm,
cryptographically strong ultrashort digital signature.

The power of software protection with EXECryptor is proved out in
practice: despite numberous cracking attempts and challenges, the
EXECryptor's 2.x series has not been cracked since its inception in
July of 2004.

In addition to its advanced protection features, EXECryptor allows you
to compress the code and resources of your application. EXECryptor is
able to protect any 32bit PE executable file (exe, dll, bpl, vxd,
wdm).

It has been tested with W95/98/ME/2000/NT/XP/2003. SDKs are available
for Delphi, C++Builder, Microsoft Visual C++, LCC, PellesC, Visual
Basic, PowerBASIC, IBASIC, PureBasic.

What's new in this version :
- added sdk and example for IBasic
- improved antidebug and antitrace.

For more information please see our webiste: http://www.strongbit.com/

SoftComplete Development wrote:
[...]

Same ol' spam, same ol' BS. Looks like you learnt not to spam sci.crypt
though.

Michael Brown wrote:
> SoftComplete Development wrote:
> [...]
>
> Same ol' spam, same ol' BS. Looks like you learnt not to spam sci.crypt
> though.
>

What happens if he does ?

"Scott Moore" <samiamsansspam> wrote in message
news:khd2
> Michael Brown wrote:
> > SoftComplete Development wrote:
> > [...]
> >
> > Same ol' spam, same ol' BS. Looks like you learnt not to spam sci.crypt
> > though.
> >
>
> What happens if he does ?
>

It would be an incentive to crack it in a matter of weeks, or even days when
the right tools are at hand. SCD's claims are arrogant and show that they do
know little about encryption. Encryption assumes that either you rely on
security by obscurity (meaning you keep your encryption method secret) or
you assume the method is known and rely on a key to prevent decoding the
message (in this case the program).
Either way the program has to include the machine code, the method, and the
key, otherwise no CPU would be able to decode and run it. The key is under
the mat!
IMO we won't have a perfect software protection for a long time, probably
not before quantum computers come true. (hardware protection like dongles
are no good either)

On Sun, 03 Jul 2005 15:49:18 GMT, "steven" <stevenPANTSvh>
waffled on about something:

>"Scott Moore" <samiamsansspam> wrote in message
>news:khd2
>
>It would be an incentive to crack it in a matter of weeks, or even days when
>the right tools are at hand. SCD's claims are arrogant and show that they do
>know little about encryption. Encryption assumes that either you rely on
>security by obscurity (meaning you keep your encryption method secret) or
>you assume the method is known and rely on a key to prevent decoding the
>message (in this case the program).
>Either way the program has to include the machine code, the method, and the
>key, otherwise no CPU would be able to decode and run it. The key is under
>the mat!
>IMO we won't have a perfect software protection for a long time, probably
>not before quantum computers come true. (hardware protection like dongles
>are no good either)

I agree that off the shelf protection is a bad move. It's kind of like
all car manufacturers using the same key.

As for encrypted keys, you can do quite a bit with them. For a start,
the application only has the ability (and public key) to open your
encrypted licence file, it won't help them create a new one. The
private key is still private. What you do with the unencrypted data is
the trick.
First, some of it can be a checksum, just to prevent false attempts to
unlock your application. The rest you can take and use for crucial
values in your code, or even as bits of the code.

You can have quite a field day with that. Self modifying code is
always fun.

Dodgy.

Dodgy wrote:
>> You can have quite a field day with that. Self modifying code is
> always fun.

Yes, but when you buy some of these tools, you can't know if the
developers are a bunch of simple programming clowns or if they true
cryptography scientists or what.

These guys for instance, they spam the newsgroups with their ads. That
makes them look like a couple of hobbyists, writing some light weight
cryptography tools.

They do have a lot of convincing sentences like "...the code block to
protect is disassembling and becomes a subject of nondeterminate
transformations..", but this gives me no hint if they for instance have
that self modifying code schema in use.

On their ordering page their products look more or less like usual
EXE-compressor (encryptor) tools. And the second product, 'Hard key
Licence manager' offers a widely used method of protecting the app by
contacting to a licensing server on web.

Finally, the famous last words of these software protection gurus, on
their own registration page: http://www.strongbit.com/order.asp

"Our Software is available for FREE downloading and using
for trial period. When this period expires you must
register our Software (by making the registration payment),
or stop using our Software and uninstall it from your
system. "

Kind of funny.<g> They have not been able to write an air tight
software protection even to their own products, so that it is unusable
and won't run after the trial period. But also they have to kindly ask
you to stop using the product, if you ain't gonna pay for it:)
HH

The ideas you propose is one people thought of long ago and one that
was dismissed just as the thought began to move around the ether of
the thinkers mind.

The general situation is as follows:

Embed a public key into your application via source code or some other
means. Clients buy licences off you, you encrypt the licences with the
private key of the public and e-mail out. maybe some auth and some
other levels of encryption, maybe establish a public key from the
client application etc...

The client app gets this lic or whatever uses the embedded public key
and decrypts it.

First mistake, the decrypted data is now in memory. second mistake
once the first mistake is seen one can encrypt the plain text lic file
with another generated private-public key pair. replace the embedded
public key with the new public key and Bob's your uncle.

The application has CRCs for checking the public key? just find the
cmp and either trace back see what the value of the CRC it is trying
to check for, and replace or simply nop the cmp.

There are actually more ways of getting around such things.

Another form of this security is to assume in the future every CPU
will have a public and private key. the OS will have an API for
extracting the public key of the CPU. The CPU can take machine code
etc encrypted with its public key and executed. It can take memory
from ram which is previously been encrypted by its public key and
execute it.

The idea is that when you go to buy a piece of software, you provide
the retailer with your CPU's public key and then they encrypt their
application etc with the CPU's public key.

The problem here is you could give them any public key with which they
would encrypt their software with, and then you could use the relevant
private key to decrypt it. A solution to this could be having a sort
of verification server, where every processor manufacturer stores the
public key of every CPU it has generated on this server with an ID.

All the software retailer has to do is query this authority server for
the public key you provided, if its not there they say "no sale to you"

How do you get around this?

well there are as always a few ways

1.) setup a mock processor company and get your keys on the main server
2.) hack the main server etc...
3.) chosen message attack

The last one is pretty interesting, you basically write a program that
will alloc memory but store specific data in the alloc'ed memory. ie:
all 1s or 0s or patterns there of. Encrypt the program with your CPU's
public key so it gets executed in encrypted mode.

Using this you could in theory implement a much much less than brute
force attack on the CPU simply by analysing how the CPU encrypts the
data in memory...




Arash Partow
__________________________________________________ ______
Be one who knows what they don't know,
Instead of being one who knows not what they don't know,
Thinking they know everything about all things.
http://www.partow.net

Arash Partow wrote:
[...]
> The idea is that when you go to buy a piece of software, you provide
> the retailer with your CPU's public key and then they encrypt their
> application etc with the CPU's public key.
>
> The problem here is you could give them any public key with which they
> would encrypt their software with, and then you could use the relevant
> private key to decrypt it. A solution to this could be having a sort
> of verification server, where every processor manufacturer stores the
> public key of every CPU it has generated on this server with an ID.

A better solution, and one proposed by TCPA IIRC, is the typical chained
certificate scheme. Basically, you CPU has
{} A private key
{} A public key
{} A signature from AMD saying that the public key is "good"
{} AMD's public key
{} A signature from TCPA saying that AMD's public key is "good" (ie: AMD is
one of them)

A query to the software writers' licencing server has all but the private
key (obviously). The software manufacturers only have the TCPA public key,
but they can then verify AMD's public key is valid. Then, they can use AMD's
public key to verify that the CPU's public key is valid. This is all done on
the licencing server, at which point it sends back code encrypted with the
CPU's public key (sort of, there's a few tricks used because public key
crypto is sloooowwwww). This code can then only be executed by your
processor.

An alternative, also provided by TCPA, is a so-called protected execution
environment. I can't remember the implementation details so won't try and
make a fool of myself, but essentially you instead produce generic
"protected" code. This code is executed by the CPU using protected memeory;
it cannot be stepped through and cannot have its protected working set
inspected. Again, you can implement quite trivial serial number validation
(such as a truncated MD4 hash) and it will be, for all intents and purposes,
impossible to break. The only way to break such a protected application will
be to inspect inputs and outputs to the protected code and write your own
code that does the same. This could be quite non-trivial if
important/significant parts of the program are inside the protected code
block as well. Basically, with CPU-based TCPA, the software protection
battle is over with the crakers losing. Unfortunately, TCPA and similar
schemes can (and almost certainly will) be abused by majority-market vendors
(*cough*Microsoft*cough*) to prevent competition though tricks like vendor
lock-in.

[...]
> 3.) chosen message attack
>
> The last one is pretty interesting, you basically write a program that
> will alloc memory but store specific data in the alloc'ed memory. ie:
> all 1s or 0s or patterns there of. Encrypt the program with your CPU's
> public key so it gets executed in encrypted mode.
>
> Using this you could in theory implement a much much less than brute
> force attack on the CPU simply by analysing how the CPU encrypts the
> data in memory...

Interesting, but completely useless. Any halfway reasonable cryptographic
system (ie: the systems they will be using in TCPA) can withstand this
attack and far more.

>> Interesting, but completely useless. Any halfway reasonable cryptographic
>> system (ie: the systems they will be using in TCPA) can withstand this
>> attack and far more.

All I can say is that is method will be used to break the DRM abilities
of any CPU that attempts to use it. I don't see any way around it...
Decent, half-way decent, not decent, it wont matter. The chosen message
attack will be the Achilles heal of all processor embedded DRM
solutions.

I talk in absolutes because I see it coming, what happened with CSS is
nothing compared how dismally this new kind of DRM will fail...

I hope to do a search in a few years time and find this post the day
slashdot or whatever its equivalent will be, makes a post about some
16 year old nerd in some obscure corner of the world coming up with an
app that will extract your CPU's public key.



Arash Partow
__________________________________________________ ______
Be one who knows what they don't know,
Instead of being one who knows not what they don't know,
Thinking they know everything about all things.
http://www.partow.net

Arash Partow wrote:
>>> Interesting, but completely useless. Any halfway reasonable
>>> cryptographic system (ie: the systems they will be using in TCPA)
>>> can withstand this attack and far more.
>
> All I can say is that is method will be used to break the DRM
> abilities of any CPU that attempts to use it. I don't see any way
> around it... Decent, half-way decent, not decent, it wont matter.

First of all, the attack as you described it does not make sense. The
instructions executable by the CPU in secure mode will be well known and
documented. What you are trying to do is extract the CPU's private key. The
attack along the lines of your description which makes the most sense is to
feed various bit patterns to the CPU and see what the corresponding
decrypted code is by seeing what it does.

This is weaker than a chosen plaintext attack. A chosen plaintext attack
would be you feeding the encrypted code to the CPU and seeing exactly what
it decrypts to, not just what it does when decrypted. Modern algorithms are
completely secure against this attack, unless you happen to have a quantum
computer lying around in your basement.

> The
> chosen message attack will be the Achilles heal of all processor
> embedded DRM solutions.
>
> I talk in absolutes because I see it coming, what happened with CSS is
> nothing compared how dismally this new kind of DRM will fail...

CSS was broken because it was a weak algorithm, was implemented in software,
and was in essence security through obscurity. TCPA is a cryptographically
strong, system, and implemented in hardware.

> I hope to do a search in a few years time and find this post the day
> slashdot or whatever its equivalent will be, makes a post about some
> 16 year old nerd in some obscure corner of the world coming up with an
> app that will extract your CPU's public key.

The thing is, with TCPA you won't need to use public key cryptography. You
can use symmetric crypto, such as a truncated secure hash. For example, a
registration key could consist of a 28-bit counter, and a 64-bit
"signature". This would end up being about 20 characters total. To validate
the key, you would do SHA1("Secret 256-bit string" | counter), take the
leftmost 64 bits, and compare to the provided "signature". In a traditional
software setting, this would never work, as the magic string can be easily
pulled from the program. However, with the magic string kept secret, it
would take, on average, 2^64 attemps to get a valid key since truncated SHA1
is still secure in this setting (the collision attacks do not matter in this
case).

It's always possible that as particular implementor will screw up their
protection allowing it to be broken (buffer overruns and the like). However,
given the time and effort put into the system so far, and the details of the
system released so far, I think it's very unlikely to be fundamentally
flawed like CSS.

The most likely attacks will be on the hardware itself. It's not impossible
that a well-connected (and financed and patient) attacker will be able to
reverse-engineer the CPU itself and extract the private key. Such things
have been done before, and are the reason why smartcard manufacturers put so
much effort into tamper-proofing their chips. A 90nm (or smaller) chip would
be exceedingly difficult to reverse engineer just purely from the scale of
the thing, but there are systems capable of doing it.