Taal van cracks/keygens

[Verwijderd]

Neeh ik ben niet zo lame dat ik een keygen of crack wil maken. Maar ik vraag me wel af hoe die progjes zo super klein komen. Omdat ik soms ook wel een progje wil maken met 1 dialog/form/panel en dan heel C++ uit de kast moet trekken om een supersimpel progje te coden, en dan heb je nix bijzonders en istie nog 500kb terwijl die dingen 33kb zijn. Voor de duidelijkheid ik heb het dus over progjes met een GUI en niet die DOS dingen.

Dus in welke taal worden die krengen meestal geschreven?
Thx

[Verwijderd]

Heeft niks met de taal te maken, maar met de manier waarop je het gebruikt. Ik weet niet hoe het in VisualC++ of zo gaat, maar Delphi maakt standaard ook best grote progjes. Als je echter niet de standaard forms en zo gebruikt, maar alles opbouwt met Windows API calls, wordt het programmaatje weer heel erg klein. Kost wel wat tijd vergeleken met RAD.

[edit]
Dan krijg je dus in plaats van klik-edit-klik-knop een rits code:

code:

procedure CreateControls;
var
  hControlFont: HFONT;
  lfControl: TLogFont;
begin
  // Create all controls (Edit1, Button1)

  // See the help file for a description of the style flags
  Edit1 := CreateWindowEx(WS_EX_CLIENTEDGE, // Extended style
    'EDIT', // EDIT creates an edit box
    'Edit1', // Name of window - also the text that will be in it
    WS_CHILD OR WS_VISIBLE OR ES_AUTOHSCROLL OR ES_NOHIDESEL, // style flags
    8, 16, 160, 21, // Position and size
    MainForm, // Parent window
    0, // Menu - none because it's an edit box(!)
    HAppInstance, // Application instance
    nil); // No creation data

  Button1 := CreateWindow('BUTTON', // BUTTON creates an button, obviously
    'Show Message', // Name of window - also the text that will be in it
    WS_CHILD OR WS_VISIBLE OR BS_PUSHBUTTON OR BS_TEXT, // style flags
    8, 40, 96, 25, // Position and size
    MainForm, // Parent window
    0, // Menu - none because it's a button
    HAppInstance, // Application instance
    nil); // No creation data

  // Set up the font
  { Calculate font height from point size - they are not the same thing!
    The first parameter of MulDiv is the point size. }
  lfControl.lfHeight := -MulDiv(8, GetDeviceCaps(GetDC(0), LOGPIXELSY), 96);
  lfControl.lfFaceName := 'MS Sans Serif';

  // Create the font
  hControlFont := CreateFontIndirect(lfControl);

  // Tell controls to set their fonts
  SendMessage(Edit1, WM_SETFONT, hControlFont, 1);
  SendMessage(Button1, WM_SETFONT, hControlFont, 1);
end;

[The - DDD]

Als je rechtstreeks op de api progged in C++ moet je is naar deze defines kijken:
WIN32_LEAN_AND_MEAN
WIN32_EXTRA_LEAN
VC_EXTRALEAN

[Verwijderd]

nix met de taal te maken, scheelt denk ik al snel wat kb's per taal..
Ik denk dat die mensen die cracks schrijven weten welk register / adres / whatever moeten veranderen.
Als je dat weet kan je in Assembler toch een redelijk kleine progje maken

[stylee]

Kelso: Neeh ik ben niet zo lame dat ik een keygen of crack wil maken...

[ot] Ten eerste, ik vindt het absoluut niet lame dat je zo een crack maakt/kan maken. Er is een hoop denkwerk, ervaring en begrip van programma's nodig om zoiets te kunnen maken. Daar heb ik dus echt wel respect voor. Dat mensen het af en toe (ik ook!) voor minder leuke doeleinden gebruiken is een ander verhaal.

Maar ik vraag me wel af hoe die progjes zo super klein komen.

C, assembler, etc. Het meeste is hiervoor al gezegd. Ipv. RAD tools te gebruiken zul je direct de API's (of hardware) aan moeten spreken.

Wil je echt versteld staan van kleine bestandsformaten, neem dan eens een kijkje bij de demoscene. Als je dacht dat een GUI in een .exe van een paar kb klein was ....

[Verwijderd]

ik denk dat ze die in win32asm maken, dus assembler waar ze de api van windows in oproepen

[Verwijderd]

Als je met visual c++ compileert moet je alsje prog werkt op release en niet op debug compileren, scheelt een aantal bytejes

[Sponz]

Op vrijdag 22 februari 2002 21:59 schreef rremzie het volgende:
Als je met visual c++ compileert moet je alsje prog werkt op release en niet op debug compileren, scheelt een aantal bytejes

Als je het nog wat kleiner wil kun je ook gewoon in C windows apps maken, lcc (http://www.cs.virginia.edu/~lcc-win32/ ) maakt hele kleine exe's.
Wel een vorm van zelfkastijding, zo windows programma's maken maar ja das mijn mening.

[Verwijderd]

Op vrijdag 22 februari 2002 21:46 schreef stylee het volgende:
Kelso: Neeh ik ben niet zo lame dat ik een keygen of crack wil maken...

[ot] Ten eerste, ik vindt het absoluut niet lame dat je zo een crack maakt/kan maken. Er is een hoop denkwerk, ervaring en begrip van programma's nodig om zoiets te kunnen maken. Daar heb ik dus echt wel respect voor. Dat mensen het af en toe (ik ook!) voor minder leuke doeleinden gebruiken is een ander verhaal.

Ik heb het over het maken, nou dat vinnik niet zo bijzonder eik maar wel het uitzoeken van de code/routine die het progje doet om de key te verifieren... Dus even voor de duidelijkheid ik vind het knap als je uit een binear progje(of een regcode of hoe ze het dan ook doen) de code kan peuteren die zorgt dat je de routine weet, maar dan vind ik dat je al genoeg 'proof of concept' hebt gedaan als je 1 key uitrekend. Dus maak er geen progje van, laat het mensen lekker zelf uitzoeken. Aan de andere kant vind ik ook dat programeurs een betere beveiliging op hun software mogen gooien, maarja.

Trouwes thx ppl ik ben nu flink bezig tutorials en examples te vergaren over API programmeren. Thx voor het duwtje in de goede richting.

[Soultaker]

Op vrijdag 22 februari 2002 22:06 schreef Sponz het volgende:
Als je het nog wat kleiner wil kun je ook gewoon in C windows apps maken, [knip/]
Wel een vorm van zelfkastijding, zo windows programma's maken maar ja das mijn mening.

Ik vind het gebruik van de Windows API nog wel meevallen. Een applicatie in Win32 assembly maken, dat is pas een martelgang! (Wel leuk om eens gedaan te hebben, though. Je moet het alleen niet te ingewikkeld willen maken).

[Glimi]

Op vrijdag 22 februari 2002 21:46 schreef stylee het volgende:
Kelso: Neeh ik ben niet zo lame dat ik een keygen of crack wil maken...

[ot] Ten eerste, ik vindt het absoluut niet lame dat je zo een crack maakt/kan maken. Er is een hoop denkwerk, ervaring en begrip van programma's nodig om zoiets te kunnen maken. Daar heb ik dus echt wel respect voor. Dat mensen het af en toe (ik ook!) voor minder leuke doeleinden gebruiken is een ander verhaal.

[knip]

Volgens mij was dat maken van die no-cd cracks niet zo bijster moeilijk. Het idee was (geloof ik, val me er niet op aan ) De CD moet eens aangesproken worden en als je die check altijd true laat retourneren is het snel gecrackt.

Het is natuurlijk wel moeilijker als hierboven, maar een met wat ervaring en tutorials kom je er al snel

[.oisyn]

als je op het eind dan ook alle onzin uit je executable hebt geperst en je m echt niet kleiner krijgt, dan is het de taak van een packer om m NOG kleiner te maken

een erg populair proggie hiervoor is UPX die echt heel veel verschillende soorten exe's kan inpakken (16-bits DOS exe's, djgpp exe's, win16, win32, etc.)

[.oisyn]

Op vrijdag 22 februari 2002 22:42 schreef Glimi het volgende:

[..]

Volgens mij was dat maken van die no-cd cracks niet zo bijster moeilijk. Het idee was (geloof ik, val me er niet op aan ) De CD moet eens aangesproken worden en als je die check altijd true laat retourneren is het snel gecrackt.

Het is natuurlijk wel moeilijker als hierboven, maar een met wat ervaring en tutorials kom je er al snel

je vergeet even het feit dat de programmeurs van het originele programma hier ook wel aan denken, en dus soms ook die CD checken met een gigantische omweg, zodat het kraken een stuk moeilijker wordt gemaakt

[reddog33hummer]

Op vrijdag 22 februari 2002 22:42 schreef Glimi het volgende:
Volgens mij was dat maken van die no-cd cracks niet zo bijster moeilijk. Het idee was (geloof ik, val me er niet op aan ) De CD moet eens aangesproken worden en als je die check altijd true laat retourneren is het snel gecrackt.

Het is natuurlijk wel moeilijker als hierboven, maar een met wat ervaring en tutorials kom je er al snel

Volgens mij vergeet je weven dat de meeste spellen daarna ook nog een CRC check hebben om te kijken of dat klopt en een controlle routine daarop om te zorgen dat die werkt... enz.

En soms werken ze met variabele spring addressen .

Het address van de link van de CD spring je + 6 naar dat alternatieve address nu, zo wordt het al weer een stuk leuker.

[Glimi]

Op vrijdag 22 februari 2002 23:00 schreef OiSyN het volgende:

[..]

je vergeet even het feit dat de programmeurs van het originele programma hier ook wel aan denken, en dus soms ook die CD checken met een gigantische omweg, zodat het kraken een stuk moeilijker wordt gemaakt

Op vrijdag 22 februari 2002 23:11 schreef reddog33hummer het volgende:

[..]

Volgens mij vergeet je weven dat de meeste spellen daarna ook nog een CRC check hebben om te kijken of dat klopt en een controlle routine daarop om te zorgen dat die werkt... enz.

En soms werken ze met variabele spring addressen .

Het address van de link van de CD spring je + 6 naar dat alternatieve address nu, zo wordt het al weer een stuk leuker.

Inderdaad wat vergeten jah (eigenlijk niet weten maarjah, vergeten staat liever) Bedankt voor de aanvulling

Hmmz nu ik dit zo zie staan, begrijp ik ook weer dat het niet zo simpel meer is Zo lijkt het zorgen dat die CRC ok is me een hels karwei. Naja weet ik gelijk weer dat ik er niet l337 genoeg ben om cracks te schrijven

[Soultaker]

Op vrijdag 22 februari 2002 23:51 schreef Glimi het volgende:
Hmmz nu ik dit zo zie staan, begrijp ik ook weer dat het niet zo simpel meer is Zo lijkt het zorgen dat die CRC ok is me een hels karwei. Naja weet ik gelijk weer dat ik er niet l337 genoeg ben om cracks te schrijven

In het geval van een CRC lijkt het me niet zo (heel) moeilijk. Meestal zal 't dan ook om een cryptografisch hash gaan, waarbij het bijna onmogelijk is om nieuwe data te genereren die aan dezelfde waarde voldoet. De strategie zal meestal ook niet zijn om de programmacode weer kloppend te krijgen met de formule waarmee vergeleken wordt, maar ofwel het genereren van een nieuwe formule ofwel het uitschakelen van de hele controle. Dat is over het algemeen weer niet zo moeilijk. Uiteindelijk komt het er vaak gewoon op neer dat elke stap die door de softwareontwikkelaar genomen is, ook door de cracker genomen moet en kan worden.

[Verwijderd]

Als je bij VisualC[++] direct van de Win32 api gebruikt maakt, dan maakt het niet zoveel verschil met de C++ en ASM versies. Bij die crack-programmatjes is de code vaak niet zo moeilijk; bijvoorbeeld op een aantal plaatsen wat bytes aanpassen, maar om op het punt te komen welke bytes je aan moet passen is de moeilijkheid. Omdat je eigen geschreven code dan niet erg groot is maakt het relatief gezien niet uit of je nu 5 Kb aan "eigen" binaire code hebt in VC of maar 1 met asm ten opzichte van de code die meegebakken wordt om het een win32 programma te noemen.

Als er wel veel verschil tussen zit, dan is het enige wat ik me verder nog kan indenken dat VC misschien uitgebreide resources meebakt (locale, compile-date, compiler, misschien een icoontje, etc) en dat bij asm dat weggelaten wordt?

mij vergeet je weven dat de meeste spellen daarna ook nog een CRC check hebben om te kijken of dat klopt en een controlle routine daarop om te zorgen dat die werkt... enz

Veel spellen hebben plaatsen ook hun files in een grote file van een aantal honderden MB's waarbij ze zelf de layout van zo'n file bepaald hebben. Als je daar nu bepaalde code van een spel in een dll zet (code die niet vaak maar wel regelmatig wordt uitgevoerd maar wel essencieel is voor het spel) + de cd-check code, deze in die file zet, en vervolgens dit runtime importeerd in je executable dan wordt het al een stuk lastiger

Wat doen van die crackers eigenlijk wanneer voor de crack er code op een bepaalde plaats aan de executable toegevoegd moet worden? Want dan veranderen vervolgens toch allerlei adressen in je code?

[whoami]

Bwah, met een RAD omgeving kan je ook best kleine exe's maken. Ik ben bezig met een progje in C++ Builder en m'n exe is nu 109kb. Best wel klein eigenlijk want het bestaat wel uit meer dan 1 form.

Als je in Delphi of CBuilder build zonder run-time components scheelt je executable ook al weer heel wat in grootte.

Die kleine progjes hebben misschien ook nog wel DLL's enzo nodig, dus moet je die kleine exe wel een beetje relativeren.

[TheOneLLama]

Op vrijdag 22 februari 2002 21:59 schreef rremzie het volgende:
Als je met visual c++ compileert moet je alsje prog werkt op release en niet op debug compileren, scheelt een aantal bytejes

Dat zou je toch niet alleen met cracks en cdkey progjes moeten doen denk ik zo

[TheOneLLama]

Op vrijdag 22 februari 2002 21:51 schreef Awooe het volgende:
ik denk dat ze die in win32asm maken, dus assembler waar ze de api van windows in oproepen

Vroeger was ASM inderdaad de standaard voor dit soort dingen, ik denk dat sommige crack proggers hier ook mee zullen werken nog. Maar bv een keygen is dat echt niet meer nodig.. je ziet dat steeds meer mensen van die dingen maken, en de nieuwere zullen daar ook C en sommige C++ voor gebruiken..

[Verwijderd]

Misschien dat bij het schrijven van die progjes de keuze voor asm meer een psychologische keuze is...

[grhmpf]

Op zaterdag 23 februari 2002 10:39 schreef whoami het volgende:
Bwah, met een RAD omgeving kan je ook best kleine exe's maken. Ik ben bezig met een progje in C++ Builder en m'n exe is nu 109kb. ...

Die kleine progjes hebben misschien ook nog wel DLL's enzo nodig, dus moet je die kleine exe wel een beetje relativeren.

Precies de dll's die je bij builder standaard moet hebben (als je niet statisch linkt) zijn ongeveer 1,5 meg. Dat zijn die vclnogwat.bpl gevaartes. Als je wel statisch linkt dan krijg je een builder exe niet veel kleiner dan 400 kb dacht ik. Hoe dan ook is het een keuze tussen kleine exe's en snel ontwikkelen (en heeft niet iedereen een 10 gig schijf minimaal ?)