Compilereinstellungen gegen Cracks?

[sirius]

Auch TObject, jedes Record, jedes Array...quais alles hinter "typE" bekommt ein paar Typeinformationen, welche mindestens den Namen und eine Kennzahl beinhalten. Bei Klassen natürlich noch ne ganze Menge mehr. Die Compilerschalter, die du meinst, beinhalten die Verfahrensweise zu allen published Deklarationen, die auch mit Namen, etc abgleget werden können (Methoden auch mit Parametern)

[ddcool]

@stoxx:

Also ich kenne ein Crack für ein Dongleprogramm was sogar recht bekannt ist. FruityLoops ist eine Software um Musik zu produzieren. Sie benötigt ein USB Dongle, also was machen? Cracken ist bei der Software ziemlich aufwendig, laut einigen Foren. Was haben die pfiffigen jungs gemacht? Einfach nen Dongle-Emulator geschrieben, der ein USB-Port mit dahinterliegendem Dongle vorkaukelt. Wie die das geschafft haben, kp. Aber ist schon ne Glanzleistung.


Grüße

ddcool

[himitsu]

Also es in den Optionen ganz abzuschalten war mir zu umständlich, da ich es ja zum Debuggen brauche, also direkt im Code:

Delphi-Quellcode:

{$IFDEF Debug}
  {$OPTIMIZATION   OFF}
  {$DEBUGINFO      ON}
  {$LOCALSYMBOLS   ON}
  {$REFERENCEINFO  ON}
  {$DEFINITIONINFO ON}
  {$ASSERTIONS     ON}
{$ELSE}
  {$OPTIMIZATION   ON}
  {$DEBUGINFO      OFF}
  {$LOCALSYMBOLS   OFF}
  {$REFERENCEINFO  OFF}
  {$ASSERTIONS     OFF}
{$ENDIF}

und davor noch

Delphi-Quellcode:

{$DEFINE Debug}    // Debugmodus an
// oder
{ $DEFINE Debug}   // Debugmodus aus

tja, sonst hab ich NonVCL gearbeitet und prüf eigentlich nur noch ob en Debugger läuft ... mehr schützen geht zwar bestimmt irgendwie,
aber wie hier schon geschrieben wurd ... oftmals nur mit viel Aufwand.

und NonVCL wird auch nur verwendet, damit die Datei möglichst klein ist und da so auch ohne Fremdkomponenten Unicode zur Verfügung steht und ich eh schon viel direkt mit der WinAPI arbeite.

[Luckie]

@himitsu: Das wirkt sich aber nicht auf die größe der resultierenden Exe-Datei aus oder?

[himitsu]

NonVCL schon ... weißte ja selber

Das Andere ( {$IFDEF Debug} ...) ein wenig ...
es fehlen halt die Debuginfos ($DebugInfo, $LocalSymbol, $ReferenceInfos) in der EXE.
Und gerade die Debuginfos machen es ja wohl gleich um Einiges leichter etwas zu cracken?


Für die VCL gibt es dann noch so nette Disassembler, wo dann zwar meist immernoch der Code in Assembler vorliegt, aber immerhin schön auf die Klassen verteilt.


PS: über AntiCrack findet sich auch noch einiges, was teilweise erhöten Schutz versprechen soll.
Aber erstmal kostet der meißt etwas und ob es dann wirklich was bringt ... k.A. Testversionen von sowas gibt's ja kaum.
Und wenn alle den selben Schutz verwenden, dann wird der auch bestimmt recht schnell geknackt.


Wie gesagt, abgesehn von 'nem winzigem Antidebuggerschutz hab ich mir eigentlich alles gesparrt, da mir der Aufwand dann doch höher vorkam, als das vermutliche Quentchen mehr Schutz.
(hab da schon etwas mit Olly gequatsch und er meinte, daß viele unfähigen HobbyCracker das Programm laufen sehn müssen, um zu kapieren was passiert und wenn da ständig mein programm in ihrem Debugger verreckt, dann werden die erheblich ausgebremst und verliehren womöglich die Lust weiterumachen )


Gegen einfaches Cracking sind meine Anwendungen auch "ausversehn" geschützt.
Programmdatei auf "Fehler" prüfen
einfach nur ein/zwei Bytes ändern ist nicht ... man muß schon noch den Hash anpassen
(also gegen einen Profi bringt es nichts, aber es ist ja eigentlich auch nur für unbeabsichtigte Fehler gedacht)


PS: bei Suchwörtern wie schützen oder [dp]anticrack*[/dp] findet man hier auch so das eine oder andere Programm/Codeschnipselchen was hilfreich sein könnte.

[Tyrael Y.]

Ich finde auch, wie in dem Thread schon angedeuet, daß es sich in 99% der Fälle nicht lohnt ein Programm "cracksicher" zu machen.

Der ganz einfache Grund wurde schon genannt.

Wer ein Crack für dein Programm sucht, wäre nie bereit gewesen, dafür Geld auszugeben.
Alle anderen werden es eh kaufen, damit sie auch Support usw. haben.

Wenn einer der dein Programm eh nicht kaufen würde sich einen Crack besorgt und dein Programm nutzt, könnte er wie auch immer, zb beruflich, genau dein Programm professionell benötigen udn wird genau in diesem Moment dein Programm doch kaufen, weil er es schon kennt und es erfolgreich eingesetzt hat.

Man kann natürlich darüber diskutieren, ich sehe in dem allermeisten Fällen ein Programm cracksicher zu machen als Geldverschwendung an.