Fórum [Vamos debater] Não quero ser crackeado... #186858

Mas pelo simples fato de excluir este arquivo, o sistema estaria com mais 30 dias de uso =P

Bom gente a um tempo atras circulos em um grupo de discusao umas
dicas para evitar ser crackeado, ai vai:


----- Original Message -----
From: Walter Chagas (Desenvolvimento)
To: Undisclosed-Recipient:;
Sent: Wednesday, March 12, 2003 9:31 AM
Subject: [delphi_linhadecodigo] Off Topic - Proteja seu software: dicas e recomendações


Muita gente nas listas procuram informações a respeito de proteção de
software contra pirataria. Eu encontrei este arquivo no delphi About e o
traduzí. Creio que interessará a todos. Perdoem-me se minha tradução não
condizer.



Proteja seu software: dicas e recomendações
Fonte:
http://delphi.about.com/gi/dynamic/offsite.htm?site=http://www.scalabium.com
/articles/protection.htm

Traduzido por mim mesmo
----------------------------------------------------------------------------
----

1. Nunca crie uma função separada para conferir o registro do programa.
Sempre coloque o código de verificação em algum procedimento importante que
é requerido para seu programa. Se o crack tentar desabilitar este
procedimento, seu programa não trabalhará corretamente.

2. Nunca dê um nome significativo para o procedimento que contém a
verificação (como IsValidSerialNumber, IsTrialExpired ou IsValidUser). Mude
o nome da F2CA e não se esqueca do rule#1.

3. Se seu código retornou uma mensagem que não é o número de série válido ou
username, então não tente na mesma hora mostrar uma mensagem de advertência.
Guarde esta informação em algum lugar e somente mostre-a depois (melhor
depois de uns dias).

4. Use no projeto, alguns algoritmos diferentes de validação. Eu quero dizer
que você pode gerar um código de ativação que use dois, três ou mais
algoritmos. Permita validar seu código em poucos procedimentos. Se o cracker
achar um procedimento de validação então que ele só achou uma parte dela.
Você pode conferir uma parte diferente do número de série em outros dias do
mês ou melhor ativar esta validação após alguns tempo do primeiro recibo de
validação. Neste caso o cracker achará um código e publicará mas seu
programa só vai trabalhos alguns dias. Localizar todo o código de programa
ou passar muito tempo vasculhando-o será uma tarefa dura para qualquer
Cracker.

5. Se você usar algum método para geração de número de série de username,
então inclua uma pausa de poucos secundos depois da entrada do username
antes de processar. Se o cracker usar um programa de força bruta, esta
tarefa levará muito tempo adicional e a tarefa de quebrar a proteção será
quase que impossível.

6. Não use chaves curtas. Claro que, dependendo do algoritmo de
criptografia, sua chave deverá ser longa. Melhor gerar alguns Kb de chave
(não esqueça de enviar instrução sobre a chave que entra) que use um gerador
de chave para 10 caráteres com símbolos literais standards.

7. Não armazene o algoritmo ou a chave geradora em seu código. É tecnologia
ruim quando o usuário digitar o nome e número de série, e depois disto, você
correr o próprio algoritmo para cálcular consecutivamente o número serial do
usuário. Melhor trabalhar um pouco com a mistura de magia e da tecnologia
Hash. Um crack poderá criar o própria chave-geradora sem qualquer remendo de
seu arquivo exe original.

8. Armazene os números de série ou os check-sum em lugares diferentes.
Também não esqueça que estes lugares devem ser escondidos ou de difícil
acesso. Por exemplo, date/time de criação de arquivo, linha invisível
adicional de pixels em bitmap, primeiras letras de um registro no banco de
dados, etc. Também não se esqueça de algoritmos únicos para encriptar estes
códigos seguros - não use o mesmo algoritmo para qualquer estes lugar
escondidos.

9. Não use algoritmos de criptografia triviais. O XOR não é uma escolha boa.
Melhor usar MD5, RSA, BlowFish, GOST etc

10. Se seu software de testes (Trial, Demo) só deverá estar disponível por
30 dias, então não tente usar o recurso de hora/data do sistema. Melhor usar
um hora/data de alguns arquivos do sistemas (SYSTEM.DAT ou DA0, BOOTLOG.TXT,
AUTOEXEC.BAT etc). Também não esqueça que, adicionalmente, você pode criar
um próprio arquivo oculto em algum lugar do SO durante instalação e usa a
data e a hora deste arquivo.

11. Criptográfe todas as strings na área de resources que mostrarão que
aquele é uma avaliação ou expira com o tempo. Você tem que desencriptar isto
em Run-time ou gerá-las dinamicamente.

12. Para enganar o Cracker: Adicione algum código falso com chamadas
externas e estranhas em procedimento de validação. Isto aumentará o tempo de
quebrar o exe porque o crack terá que encontrar ´a mina de ouro´ no lixo.

13. Se você for especialista em desenvolvimento, tente criptografar algumas
partes do código em exe/dll e desencriptar isto em run-tie. Use métodos
diferentes de código que confere - checksums...

14. Tente usar uns nomes malucos ou ilegíveis de procedimentos (D1FA12, B123
etc) ou use uns nomes como funções de sistema - GetWindow, MOUSE_EVENT_A,
KeyboardLayoutW etc. Também você pode usar os nomes de alguns procedimentos
que são populares em sua linguagem de programação (claro que, se a linguagem
suportar um mesmo nome de um procedimento para diferetes units ou módulos
diferentes).

15. Se sua linguagem de programação suportar isto, então use o run-time para
a associação aos eventos. Por exemplo, no Borland Delphi/C++Builder você
pode escrever um código de validação em procedimento que será nomeado ao
evento OnClick de algum botão. É ruim porque o nome deste procedimento será
armazenado em recursos e pode ser removido em qualquer editor de recurso.
Melhor nomear um procedimento ao evento em run-time.

16. Se você puder, não habilite algumas características estendidas na versão
Demo / Trial. Melhor remover isto da versão (Uma versão incompleta) e depois
que o cliente se registrar, ele recebesse o outro programa completo.

17. Freqüentemente libere versões novas ou atualizações. Claro que, não
esqueça de mudar o método de validação (pelo menos um) em cada liberação.

Você tem que entender que qualquer software pode ser quebrado. E qualquer
software será quebrado se seu programa for bom e custo de rachar tempo é
menos que sua taxa de licença.

Se você acha que seu software foi crackeado, não se apavore. Em qualquer
situação você tem que buscar uma inovação para isto. Nesta situação você tem
que entender que seu software é muito bom no mercado mesmo com com o crack
que quebrou a proteção, agora é melhor você. É como um jogo - você liberou
uma proteção nova, e ele terá que quebrar isto. O próximo passo é seu: você
tem que mudar a proteção e tem que adicionar alguma surpresa escondida para
seu oponente - algoritmo de criptografia novo, escondê-lo em outros lugares,
etc. é uma vida.

Adicionalmente

Também eu quero dizer o seguinte: a proteção é parte muito importante do
processo de desenvolvimento, mas não perca muito tempo nisto. Se você
concentrar na proteção e se esquecer das funcionalidades do programa, seu
software nunca será quebrado. Mas não é esta a razão de uma proteção boa,
seu software deve valer este tempo que você passou em proteção. (Entenda,
ele tem que ser muito bom mesmo para compensar tamanha proteção).

O usuário final necessita de uma boa solução para seu problema e um bom
suporte para as dúvidas sobre as características e novidades da versão. A
sua proteção deve ficar em segundo plano. Existem muitas proteções em chaves
de hardware (Hardlock) ou métodos de confirmação pela Internet (Ativação
semelhante à do Windows XP) que poderão se tornar um incômodo para seus
clientes. Neste caso você poderá perde-los por pura paranóia de pirataria.

E não se esqueça da privacidade de seu clienteo - você não pode permitir que
alguns dados sejam personalizados sem permissão. Não importa que precise de
proteção para isto.

----------------------------------------------------------------------------
----

Copyright© 1998-2001, Scalabium. All rights reserved.
webmaster@scalabium.com
January 15, 2001

Boas dicas. Obrigado :D

Trava de Segurança por porta serial, paralela, usb...



[url]http://www.proteq.com.br/[/url]

Eu nunca usei proteção via hardware (hard-lock), mas quem usou diz:

[/quote:afb6ff2582]

Não vejo problema com interferência no software. Você criaria a rotina de verificação, seja na inicialização do sw, abertura de módulos, de segundo em segundo. Logicamente que quanto mais verificações, mais recursos utilizados.

O Hard-Lock não tem fonte de energia e não dispara pacotes no sw, simplesmente ele tá lá pra ser verificado quando convier.

Achei esse texto e achei interessante as dicas dele. Meu ingles é fluente e por isso entendi tudo e achei muito interessante. Foram dicas de crackers profissionais.
Aí vai:



I would like to stress that this FAQ is not my work. Unfortunately I can not remember which site I d/l the original HTML file from. I left the file and all text in it exactly as I d/l´ed
it except for converting it to TXT format.

===========================================================

Anti cracking FAQ
How to make cracking your programs a little harder


-----------------------------------------------------------------

Finding out that the program on which you worked for months or
years has been cracked can really hurt and demotivate.
For me as a Shareware programmer, the reason has never been that
I´ve lost a few cents (I don´t want to do propability
calculations here, it might hurt even more..), no, it was simply
that I´ve always tried to hold my programs as cheap as possible
to make them affordable for everyone, even for students or
freeware programmers.

Somehow I can understand the fascination of cracking programs (if
you are absolutely intolerant about software crackers and
hackers, please excuse, but one of my educations is
Psychotherapy, and I´m always searching for reasons...) -
cracking a restricted software program must be like solving a
(sometimes very tricky) riddle, and you might get addicted to the
feeling of solving them (I´ve found that when I saw my
grandmother doing crossword puzzles all over the time for some
months). The problem is (but at the latest, now we come to the
undoubtedly illegal part of the ´game´): it doesn´t really
satisfy the cracker if he is the the only one who knows about his
´genius´...thus, he has to spread the news. He has to publish his
´crack´ (just see most crack packages: in most cases they just
consist of: 1. the cracking utility 2. a short description 3. a
big file containing claims that the producers are nothing less
than the greatest ones on Earth and that the cracked program is
another one which could not stop them with ´its lame protection
scheme´.)
But now the fun is completely over: by giving out this (let´s try
to be fair: ´study of feasibility´) to other people, by spreading
it via Websites, newsgroups, mailing lists, anonymous FTP, CDROM
´abonnements´ and whatever, they clearly damage the business of
everyone who puts time and energy in their software product. Even
if we assume that typical crackers wouldn´t have bought your
product under normal circumstances: spreading the ´crack´ IS
criminal and no one could claim that none of the receivers or
downloaders would never have bought it. It´s just like if someone
hands out copies of the key to your car on the marketplace - and
it doesn´t really matter if he does that for money or not.

In earlier days, I have never put real energy in protecting my
programs against cracking, but after finding several cracks for
them around, I thought to myself: why make it too easy? As a
programmer, of course I know that no - really: NO! - program can
ever be crack-safe, and I know that of every interesting program
sooner or later cracks (or at least pirated or illegally copied
versions) will be around, but at least I could try to avoid the
worst mistakes.

Most of the typical ´high language´ programmers don´t know
Assembler anymore, so the ´protection ideas´ they use are in most
cases quite weak.
I don´t know much about Assembler myself, so I decided to open my
eyes and started to collect anti-crack protection tips wherever I
found them. Also I did my best to ´learn from the other side´ ..
many of the tips you can find here I´ve found by studying the
typical cracking techniques, the various ´cracking guides´ around
the web and by reading protection tips given even by professional
crackers themselves (some of them generously give us tips to
increase their challenge). Well, I hope I´ve learned my lessons
well enough, but also want to share my experiences with you on
this page.
Some rules given here were already stated in various essays on
other sites, but are listed here for completeness. Many of these
apply especially to windoze, but can be ´ported´ to other OS´es
or anywhere else.

PLEASE:

* This FAQ is brand new. If you think that I´ve missed some
points or useful tips a typical Delphi programmer could
easily add to his/her programs to improve protection, please
let me know. If you allow it, I´ll add it here, otherwise
I´ll inform you about my experiences with it.
* Don´t ask me questions - might be that I´m simply too
overburden to answer.
1) As mentioned, I don´t have much knowledge of the
low-level stuff.
2) I can´t send you demo sources, since I don´t have
anything ready for a publication. If I have something, you
will read it here.
3) Finally, I will not provide anyone with any of the URLs
where I´ve found (or found out) some of these tips. Please
understand, but this is a site dedicated to programming, but
not to provide ´step-in´s´ to available cracks or even to
´Cracker hunting´. Find more generic tips about
crack-protection at my Delphi Tips page.

-----------------------------------------------------------------
But finally, here is ..
How to make cracking your app a little bit harder:
(tips are not sorted by importance)
-----------------------------------------------------------------

* Never use meaningful procedure names such as

function RegistrationOK: Boolean;



How intelligent and complex your code inside this function
might ever be - an experienced cracker will just take about
10-20 seconds to remove it. Believe it or not.
Alternatively, place some required code for your program in
such a function. If the cracker disables the function, your
program would produce incorrect results, for example.

* Never use meaningful file names such as License.Dat. Why,
you say? Please start reading here.

* Play with asymetric encryption. Just using unusual filenames
is often not enough. Good encryption, of course, could keep
the cracker busy for months (if he likes).

* Add long delays. Don´t warn the user right after a violation
is made. Wait later, maybe until the next day or two
(crackers hate that).

* Add short delays. Pause a second or two after a password
entry or to your other checking routines to make brute force
cracking unfeasible. Simple to do, but rarely done.

* Use checksums in DLL´s and in the EXE. Have them check each
other. Far away from ´safe´, but it just makes it harder to
crack.

* Self-heal your software. You know, things like the error
correction modems and hard drives use. The technology has
been around for years, and no one uses it on their software?
The best thing about this is that if the cracker used a
decompiler, they may be looking at a listing that is no
longer valid.

* Patch your own software! Change your code to call different
validation routines each time. Beat them at their own game.

* Store serial numbers in unlikely places like as a property
of a database field. Often heard and read: ´..give it a DLL
file name and store it in the System directory.´ Too often
heard, don´t use it. ;-)

* Store serial numbers in several places.

* Don´t rely on the system date. Get the date of several
files, like SYSTEM.DAT, SYSTEM,DA0 and BOOTLOG.TXT and
compare them to the system date. Require that the time be
greater than the last run (but keep in mind that many users
might do Y2K-checks these days).

* Don´t use literal strings that tell the user: ´Sorry, but...
(whatever).´ These are the first things to look for. Build
strings dynamically or encrypt them.

* Flood the cracker with bogus calls and hard-coded strings.
Decoys are fun.

* Don´t use a validation function. Every time you validate the
user, write your validation code inline with the current
process. That just makes more cracking for the cracker and
bewares of just NUL´ing out your routine.

* Use ´reserved´ names. When using hard-coded keys or
passwords, make them look like program code or function
calls (i.e., ´73AF´ or ´GetWindowText´). This actually works
very well and confuses some decompilers.

* No ´disabled´ features. If your program doesn´t save data in
´crapware´ edition, don´t include a ´grayed´ menu item. No
saving means no saving. That´s it.

* Avoid nags. The only way to tell the user that he is
unregistered should be in the ´about´ dialog. This latter
should be created dynamically for security reasons. 2
reasons: some programmers have the philosophy that
nagscreens are making enemies among your customers, which
would then really be very stupid. The possibly more
important reason is that nagscreens invite
reverse-engineering your code and often directly leads to
your protection code.

* Update often. Frequent updates mean: frequently changing
code, so the typical (simple) crack which is just patching
hard-coded byte positions, will possibly already be outdated
when published. Also prevent uploading them to public
servers, so that you have better control about where your
app sits around and people don´t find older versions the
cracks can still use. Yes, this doesn´t prevent pirates from
including the version to the crack package, but IF they do
so, you can at least contribute to filling up their
harddisks.

* Finally, take some time to think about protecting your
software. Is it really worth the protection? Wouldn´t it be
better to improve your software, rather than improving
protections? The problem of protecting software vanishes if
no one will use your software. Don´t overestimate your
work´s ´importance to the world´.

-----------------------------------------------------------------
More tips you might take into consideration:
-----------------------------------------------------------------

* Use a serial which is several KB long of arithmetical
transforms, to drive anyone trying to crack it insane. This
makes a keygenerator almost impossible - Also, brute force
attacks are blocked very efficiently.

* Caution with the Runtime libary! Use it fully when writing
the beta versions, in the final release rewrite some
functions at least to make crackers life harder.

* Mangle data. Protection that mangles data is usually a good
one.
Example: Imagine a charting program .. e.g., just disabling
printing and later on enabling it basing on some
registration# is the most often committed suicide. Let your
thingo print. When creating data structures for printing,
mangle them in some way. Unmangle them just before printing,
using reg or something other for that purpose. Even more,
make this mangling subtle. Assume that you´ve got a pie
chart to print. Don´t alter anything, but add some not too
big random numbers to values of data series - this is
mangling then. The chart will look ´not that bad´, but will
be otherwise unuseable (if the changes are random and on the
order of 20¬, for example). Finding such protection, if its
connection with reg# is not self-evident can take much time.
One has to delve inside your data structures and find that
dreaded mangling and unmangling code.

* Traps. A method I´m not sure about, but I have heard some
apps are using it: do a CRC check on your EXE. If it is
modified then don´t show the typical error message, but wait
a day and then notify the user using some cryptic error
code. When they contact you with the error code, you know
that it is due to the crack. Be aware: such traps could also
be activated due to virus infection or incorrect downloads.
Imagine the possible aftereffects if you are blaming your
potential customer for software piracy.
* Don´t rely on ´EXE-packers´. For almost any tool which
compresses EXE files (Shrinker, WWPack32, NeoLite - to list
the most popular ones) there´s an uncompressor around, so
compressors capable for software-protection should at least
support configurable encryption. Unpackers for the above
(and other) tools are not very wide-spreaded, however, don´t
rely on them as your program´s one and only ´protection´!

-----------------------------------------------------------------
Advanced tips ..given by assembler freaks.
-----------------------------------------------------------------

* The rcr/rcl trick
If a rcr/rcl is performed on a value, it becomes much more
of a pain to crack - you can´t reverse it with by negating
it´s effects without knowing what the value of the carry
flag was before the original operation. If the carry flag is
created as a result of some other pain in the neck
operation, you are probably onto a winner.
* Stick conditional jumps in. Everywhere.
Conditional jumps are not fun to reverse engineer. No loops,
but jumps which conditionally bypass/include portions of
your wonderful key manipulation code. There is no easy
inverse operation to be performed here.
* Use portions of the code as magic number tables.
(preferably critical sections). You have no idea how
annoying this can be, if you´re like most crackers and like
to change things around using softice (a popular cracking
tool).
* Play with the cracker´s mind.
This one is fun :-) Stick series of nops in, as though you
were doing self-modifying code (oh my god! what the heck!
nops? Aha! Self-modifying code! Idiot spends next three
years trying to find the code that should be there.). Pepper
the code with junk instructions. Cut the code up into little
pieces and put them all over the executable, with
(preferably conditional) jumps between them. - Anything
which you would find a pain in the neck.
* Detect SoftIce. Early.
Now crash the computer. You can crash a pentium or a pentium
with MMX even without a vxd by the opcode: F0 0F C7 C8
(illegal form of cmpxchg8b instruction with lock prefix).
Beyond that, we have to resort to the tried and true
methods. Using a vxd, take the CPU out of protected mode.
Windows doesn´t like that. Wonder why? .. On the other hand,
* Don´t loose too much time on writing anything that will kill
disassemblers or debuggers.
Doing it is worthless, believe me, people who made them or
others will soon find the way around, so shift your interest
to more important stuff. Just do things which are easily and
fast to afford, like the above tip.



-----------------------------------------------------------------
Special on Delphi VCL cracking
Quoted from a helpful cracking tutorial - just read and learn
from it!
-----------------------------------------------------------------

´Let´s learn something about the innards of new Borland´s
programming tools. This knowledge will allow us to speed up
cracking sessions, as will teach shareware programmers who use
Delphi to be more careful and not to happily expose their
´secrets´ to curious eyes B) [..]

VCL stands for ´visual component library´, a library used by
recent Borland visual languages as Delphi and BC++ Builder.
These environments use a proprietary resource format, that appear
as ´RCDATA´ when listed by Resource Workshop. These resources
contain ´forms´. In Delphi jargon, forms are the windows of the
program. All the info about their design is stored there. When a
typical Delphi app is starting, the initialisation code creates
the forms, loading the required information from the resources.
Sometimes this loading is deferred - forms that aren´t used very
often are created and destroyed as needed.
This system is the best and the worst of Delphi. It allows a very
fast way of programming but, for full-length apps, it can slow
down the loading.

The really interesting part of this information is that the
address of the routines - called in response to user interactions
with the elements of the form - are bound at run time by name. So
knowing these names we can find the appropriate addresses!

If you have cracked any Delphi apps, you have surely experienced
the long chain of calls inside the library, from the breakpoints
on the API calls to the ´do something´ code. I hoped that these
addresses could help in pinpointing the relevant code.´

[..describes his installation of a quite well-known Delphi-writen
application..] I cracked it completely and without problems, as
you are about to see :=) After first installation the weeks
passed and I hadn´t had the time to work on it... when I started
it, I found a nasty ´Your evaluation period has expired´ message
:-(

The first step is to gather the information about the target exe
with a resource or form spy tool. You may be tempted to
investigate TVALIDATORDLG, the form where the user name and
registration key is obviously input. But all you´ll find is a
mere dialog. The real work is accomplished from its caller:
TSPLASHFORM. This is the nag window that appears at the beginning
of the program, as well as when it´s shutting down and from the
Help->About menu.

You can select TSplashForm and look at the text representation of
it. A lot of information about the buttons and labels will
appear. Let´s concentrate on the following part, near the end:

object RegButton: TButton

Left = 200

Top = 176

Width = 97

Height = 25

Caption = ´Register´

TabOrder = 1

OnClick = RegButtonClick

end

What´s that? This is the button with the caption ´Register´. You
can see its size, position... and something with a suggestive
name: ´OnClick´. ´OnClick´ tells us the name of the routine
invoked when the user presses this button. Once we have the name
(yes, ´nomen est omen´ :) we can search for the address of this
routine. This is because the routine is bound to the button at
run time by name.

Using a hex editor, I looked for ´RegButtonClick´ and I found it
twice. The second occurrence is the resource itself, the first is
within an address table:

000A4990 ____ ____ ____ BC57 4A00 0E52 6567 4275 ______.WJ..RegBu

000A49A0 7474 6F6E 436C 6963 6B__ ____ ____ ____ ttonClick_______

Now look at the magic numbers before the name. There is a byte
(´0E´) indicating the length of ´RegButtonClick´ (14 characters)
and before that an address: 004ABC57.

Some disassemblers seem to think that file is too long and it
doesn´t disassemble this portion of the exe correctly - however,
with a special tool we can bpx on this and... right! It stops at
the point just when we push the button.

A couple of instructions forward you´ll find a CALL. Tracing into
it you´ll find a ´standard stack frame´ in 44ECC8:

0044ECC8 55 push ebp

0044ECC9 8BEC mov ebp, esp

.

This is the kind of thing expected at the beginning of a high
level routine, made by the application programmer. We have
avoided the whole chain of library calls through the VCL from
Windows notifications, and landed in the right place!
From this point, there are some calls you can easily test by
setting breakpoints on them - you´ll find that their purpose is
to show the dialog asking for the user name and registration key.
Then, the key is calculated from the user name and compared with
the one the user entered. You can enter the name you choose, and
anything as the key, after BPXing 44ED69. Here, a call to a
routine compares two strings. D EDX will show the fake key you
entered and D EAX will show the correct calculated key. Easy,
isn´t it? A ten minute crack by a beginner!!

[description about spying the key generator routine comes next.
It´s been an average routine of about 10-20 Object pascal code
lines.]

How this way of cracking can be avoided?

Read my tips above. The basics are: don´t use automatic methods
created by double clicking on the button or the object inspector.
Write your code somewhere else in your program, preferably in
another module, and bind it to the button using code such as:

RegButton.OnClick := RegButtonClick;

Of course you´ll need to enter this code after the form is
created and before it´s called. Best if it´s rounded by a lot of
unrelated stuff. This won´t necessarily prevent your program from
being cracked of course, but things will not be as easy as you
have seen in the lines above O:)

-----------------------------------------------------------------
Notes on registration numbers
(if you can´t avoid them)
-----------------------------------------------------------------

* balance between security, feasiblity, programmability and
end-user headaches
* Too long, non-alphanumeric Reg#´s tend to be continuously
entered badly. Think about requiring to enter a verification
field (as commonly used with passwords) or, at least,
provide a ´non-persistent´ Reg entry field so that the user
will rewrite the Reg each time, possibly correctly at last.
Many people will just ´glance-compare´ the entered Reg and
the one (possibly) emailed to them, arriving at the final
thought that they did enter it correctly, whereas the font
is too small or they are too tired to notice that this ´1´
and ´l´ have been interchanged (in a reg like
´l83jjd_0)pH1lTe´ )
* Refrain from any user feedback. The Reg entry box should
accept strings of any length, without any validation. Don´t
give crackers the knowledge about the type of your Reg# - if
you do ´online-verification´ which shows that it´s 10 chars
long or that is contains only uppercase chars helps - so
don´t help them!
* Calculate the number of potential users! There´s nothing bad
like if you have to update 9,999 users because you didn´t
expect that there might be 10,000 of them and have to shoot
out a new version which is capable for these Reg´s...
* If your Reg is 10 numbers long, there are 10^10 possible
Reg´s. But since your app might find let´s say only 10^4
(10´000) users, you should invent an algorithm that assigns
each one of 10^4 users one of 10^10 reg´s, and does it
somewhat uniformly. This prevents people and programs (some
.vxd based ´macro´ players, for example) to be used for
brute force approach. If there are only 10^4 users and you
allow 10^9 ´valid´ Reg#s out of 10^10, on average each 10th
Reg tried brute-force will be valid, whereas on the case of
10^4 prospective users, that many valid reg´s and space of
10^10 Regs, on average only each 10^6th Reg tried brute
force will be valid. Ever calculated how much time it would
take to brute-force search 10^6 numbers, even using a fast
machine and extremenly fast macro player (keystroke
generator simulating Reg entry and checking for results)?
* the assignment operator that assigns User to Reg shouldn´t
be trivial, and it´s implementation should be done in
Assembler by someone experienced both in Maths and
Assembler. Remember that Delphi still allows you to directly
use ASM code in your source! Then, check your operator.
create graphs of how it works. Understand your own work,
especially its drawbacks and vulnerabilities
* Be inventive. Don´t use anything that seems simple, quick
and effective unless you´ve come with something like
Einstein´s relativity theory, your approach is yes, simple,
yes, quick, but no, not effective, and yes, easy to crack.
I´m sorry, but we aren´t geniuses and developing a good
protection scheme takes some time.

Just some thoughts..
:-)
Richey

Again: please e-mail me if you have tips or suggestions !
If you want to support my work on this page or simply say
´thanks´ for opening my treasure box to you, I´d be happy if you
would register one of my apps!
Based on your support, page will be updated frequently! Last
update: 29-Sep-98

-----------------------------------------------------------------
Copyright ) 1998 by Richard Fellner. All rights reserved.
[[Image] /10´98]
[Image] Do not copy to other sites or include in commercial
compilations without the written authorization from the
author.
-----------------------------------------------------------------

Bom, como sabemos, não existe uma proteção 100¬ confiável. Pensando nisso passei a desenvolver proteções para versões ´trial´ dos meus programas, já esperando que eles sejam crackeados.
Simplesmente juntei mais ou menos 30 métodos de proteção diferentes, que vão desde gravar dados no registro, gravar em arquivos e DLL´s, etc, e bolei uma função que verifica a data do sistema, e de acordo com um periodo pre-definido, o programa usa uma determinada proteção.
Por exemplo:

´Se a data = 28/11/2003 à 14/12/2003 ou 23/03/2004 à 12/04/2004 então
usar a proteção 1´
´Se a data = 15/12/2003 à 03/01/2004 ou 10/02/2004 à 22/03/2004 então
usar a proteção 2´
´Se a data = 04/01/2003 à 09/02/2003 ou 20/05/2004 à 12/06/2004 então
usar proteção aleatória´
E assim por diante...

No caso do cracker quebrar uma das proteções (a que estiver ativa quando ele tiver mexendo no programa), e distribuir o programa, após alguns dias será usada outra proteção.
Alguns poderão perguntar: E se o cara sacar o esquema e alterar a função que verifica a data ? Bom... me preocupei em espalhar pelas áreas principais do programa várias funções diferentes que fazem esse trabalho, o que vai dificultar ainda mais o trabalho.

A idéia foi criar uma grande teia, que faça o cracker ´andar em círculos´. Realmente foi a solução que achei, e até agora deu certo.
Programo há 4 anos um software que já está na 4ª versão. Todas as versões ´trial´ anteriores foram crackeadas em menos de 3 meses após o lançamento. Nesta nova versão, perdi algumas semanas de trabalho programando essa proteção, mas valeu a pena porque até agora (9 meses do lançamento) ainda não conseguiram crackear.

Muito bom Lenin!
Eu estive estudando como crackear programas, e é bem interessante o modo como crackeiam. E é muito fácil também. Só exige um pouco de conhecimento em assembler. Mas é claro que é para adquirir mais conhecimentos na area Anti-Cracking. Posso te perguntar que programa é esse seu?

nildo,
Por razões óbvias não posso divulgar o nome do software, não seria muito inteligente, já q acabei passando mais ou menos o segredo. O que posso te dizer é que é um soft p/ orçamento e planejamento de obras de engenharia.

Entendo. Mesmo assim muito obrigado pelas dicas

/////////////////////////////////////////////////////////////////////////////
Você pode gravar um registro no banco de dados, quando chegar a data de expiração, o programa vai verificar se existe aquele registro, se existir vai pedir uma senha para continuar funcionando...na hora em que gravar o registro o programa cria um arquivo oculto sem extensão.....mesmo que o cara reinstale o programa, não saberá se existe aquele arquivo oculto, que o programa tb verifica.....só mesmo descompilando para saber para onde aponta o programa,,,,só que aí não é qualquer um que consegue.
Por: Luciano(luckirn@bol.com.br)
/////////////////////////////////////////////////////////////////////////////

Sobre salvar algo no banco de dados não é viável, pois meu programa não usa Banco de dados hehehe

Bom, eu facilmente consegueria descobrir estes métodos como criar arquivinhos ocultas e não precisaria nem descompilar para isso. Existe um utilitário que se chama FileMon (file monitor) que me mostra toda a atividade de arquivos que certo programa está tendo. Por exemplo:
Processo: MeuPrograma.exe | Ação: OpenFile | Arquivo: arquivinho.txt.

Outra maneira que eu poderia utilizar para desvendar, é utilizando Disassembler (w32Dasm) . Para isso eu ignoraria atravez do HView (Hacker view) mexendo por assembler a verificação. Então se o código é assim:

If AlgumaCoisaQueIndiqueQueSouRegistrado then
......

por
If not (AlgumaCoisaQueIndiqueQueSouRegistrado) then
......

isso é muito facil de ser feito. Acho que o melhor método é aquele de usar uma verificação a cada intervalo de datas.

Como já foi dito anteriormente, para cada tipo de peixe usa-se uma isca diferente.

No seu caso Nildo, como seu aplicativo é backup, supõe-se que o usuário está fazendo cópia de segurança de arquivos importantes e atuais. Caso os arquivos não se enquadram nessa classificação não teria motivo de fazer backup.

Todo arquivo tem sua data de criação/atualização, então cheque todos os arquivos e verifique se algum tem a data superior ao sistema operacional, se houver com certeza a data foi alterada.

Agora um comentário pessoal, todos os métodos passados aqui foram de certa forma burlados por soluções hackers, ou seja nada é seguro, se você inserir no seu código algo como ´if qualquercoisa = algumacoisa´ e o hacker pode alterar para ´if not (qualquercoisa = algumacoisa)´. Então venda seu aplicativo com os fontes, pois de qualquer forma o hacker vai ver o seu código e alterá-lo.

Mesmo que não crackeie, ele terá condições de fazer um sistema de backup igual ao seu, ou melhor. Então porque perder tempo crakeando algo que ele poderia fazer?

As soluções de proteção por data aplicam-se a sistemas comerciais que temos que fazer o balancete do mes os pagamentos de duplicatas e cálculos de juros, que torma impossível mexer na data do sistema.
(você não pode fechar um mês que nem começou).

Outra coisa, se o código fonte é visível para um hacker e ele entenderá tudo, porque uma empresa pagaria pelo seu sotware e um hacker para descompilá-lo e alterar o algoritmo?

Algum hacker já descompilou o Windows ?
Não se ofenda Nildo, mas acho que não vale a pena descompilar um aplicativo de backup, tenho um sistema de gerenciamento de rodovia orçado em 120 mangos e não estou preocupado se vão crakear ou não, qualquer modificação de virgula, eles precisarão de mim.

PS. Gostaria de ver seu aplicativo, mande uma versão pra mim se possível ou fotos dele. (não vou crakear, é só curiosidade, hehe).

Okama, estou terminando-o. Quando acabar eu te envio o link para download.

Ps.: Um programa de backup nao vale a pena descompliar. Mas baixei todos os programas de backup que achei pela frente e na minha opinião (e na de meu chefe) nenhum faz o que o meu está atualmente fazendo.

Mas ainda falta muito para acaba-lo

Obrigado pelas dicas