[Delphi] Registracny kluc?

Ako by som mohol aplikaciiu odomykat klucom? Budem mat list vygenerovanych klucov a nenapada ma ako mam dosiahnut kontrolu v aplikacii ci je ten kluc spravny. Samozrejme ze do aplikacie nestrcim zoznam 20 klucov a nebudem prechadzat zoznam.

Desktopka? Ja by som to ulozil do nejakej lightweight databazky ako SQLite kde by som mal ulozene nejake hashovane hodnoty toho zoznamu a tie by som porovnaval so zadanym klucom ktory by som dodatocne aj kryptoval podla struktury databazy.

ty myslis ze mat na webe hashovanu DB klucov, aplikacia posle kluc na web, ten prebehne zoznam a odosle tru/false?

Ide o shareware, klasika, trial a potom treba kluc. No ja by som sa len chcel vyhnut tomu aby som do programu strcil zoznam napr 100 klucov. Ono by bolo najlepsie to generovat a neobmedzovat to takto zoznamom.

A predpokladajme ze ten program ma fungovat aj bez netu. Cize riesit to externe cez web nechcem. 1 kluc = 1 user. To je tiez dovod preco by som tam nechcel strkat zoznam a porovnavat (sifrovane).

Nie, myslim ze ta SQLite ma byt priamo sucastou programu. Ten zoznam bude v databaze (v pamati nepristupnej userovi) a hodnoty nebudu stringy ale kryptovane kluce, ktore sa tou kryptovaciou funkciou budu spatne porovnavat.

Inak je to bezpecnejsie mat ako pises na webe, ale ak chces aby to pracovalo offline tak musis aj takto ...

Mozno niekto pride s niecim lepsim, ale ja by som to zrejme riesil takto.

PS : Ta SQLite je len priklad. V principe sa jedna o embedded database, co to je a ako sa to pouziva najdes napriklad na tejto adrese : http://en.wikipedia.org/wiki/Embedded_database

Akékoľvek generovanie alebo kontrola správnosti sériového čísla (alebo inej formy kľúča) sa dá v kóde vyhľadať. Dobrý druh ochrany je napríklad: po spustení aplikácie užívateľ zadá kľúč, ktorý sa použije na dešifrovanie DLL knižnice, z ktorej budú neskôr volané funkcie. Ak bol kľúč nesprávny, DLL nebude použiteľná. Žiadna kontrola tam neprebieha, takže úspech dešifrovania ja takmer nemožný (jediný úspech je vlastne vtedy, ak správny kľúč víjde "von" medzi verejnosť). No tu je zas nevýhoda iba jedného kľúča a ty zrejme chceš viac kľúčov. Tie sa ale kdesi v kóde musia porovnať a potom sa spustí aplikácia. Cracker buď nájde generovanie alebo jednoducho zmení jedinú inštrukciu, kde sa kontroluje správnosť (preto rozhodne nepouži niečo ako "if (generovanykluc = spravnykluc)" ale buď ho rozdeľ na viac časti alebo proste nejaký iný algoritmus).

Forty- dik za tip. Ale tomuto som sa chcel vyhnut. Pretoze dajme tomu ze tam strcim 100 klucov a stiahne si to 150 ludi )) kluce sa minu :o). Preto som to chcel riesit generovanim ale hmm. Asi to fakt len na ten sifrovany zoznam spravim

Fico, ani ta metoda nieje nepriestrelna, staci z programu zistit algoritmus decryptovania a nasledne bruteforce sposobom skusat rozne kluce , kedze dll musi mat predpisanu hlavicku je dost lahke overit ci bola dll spravne decryptovana. nepriestrelna metoda ani neexistuje, ved keby bola tak, neexistuje tolko warezov pokial ide o shareware tak decryptovanie nejakej dll je asi nepouzitelne lebo ta dll musi byt funkcna aj s trial klucom obmedzeny cas. jedine zeby trial verzia mala iba ciastocnu funkcionalitu a iba funkcie dostupne vo full verzii by boli obsiahnute v cryptovanej dll.

ono, neexistuje nepriestrelna metoda, otazka je, co sa tomu najviac priblizuje

Ako tvoj program bude vedieť, koľko kľúcov je v obehu, ak má fungovať offline ??? (ak som to pochopil správne a chceš na každého usera použiť práve jeden kľúč).
Už keď chceš pre každého usera špecifický kľuč, tak sa to rieši napríklad tak, že user zadá svoje meno a podľa tvojho algoritmu sa z mena vygeneruje kľúč, ktorý sa porovná s tým, ktorý mu ty zasleš pri registrácii.


Aj keby útočník zistil algoritmus dekryptovania, ak použiješ dostatočne dlhý kód, nie je šanca aby to dešifroval minimálne do konca tohto roka. A ty vôbec nemusíš meniť hlavičku, môžeš šifrovať iba stred, alebo všetko, je to proste na tebe.

vacsina softov to riesi tak ze vygenerovane kluce maju s pouzitim urciteho algoritmu rovnaky hash a ten je ulozeny priamo v kode. nieco podobne ako MD5 pri urcitej dlzke hashovanej hodnoty uz nedokaze zabezpecit jedinecnost vystupneho kratkeho hashu, takze niekolko hodnot na vstupe ziskava rovnaky hash

ten druhy citat nieje moj ale neva . Fico ano. Ale tak to robit (generovat na zaklade mena) z urciteho dovodu nebudem. Pretoze tie kluce budu uz pevne predgenerovane. Ale uz viem ako. Budem kluc delit na casti a kontrolovat na neaku podmienku. Tak sa aspon vyhnem zoznamu klucov v aplikacii. Reverznut sa to da vzdy a nerobim autocad cize naco mega zlozite opatrenia.

ano tak som to chcel, ze si jednosmernou sifrou vygenerujem zoznam a ulozim do aplikacie. No a ked zaslem kluc (z ktoreho to bolo povodne generovane) program to znova prevedie a porovna. Ale je to obmedzene no

na oklamanie neznaleho nepriatela dobre, inak uplne nanic. Tak ci tak budes musiet mat nejaky zoznam klucov, ktore budu musiet mt nejaku vlastnost, cim spravis cracknutie o trochu zlozitejsim, no rataj s tym, ze bez poriadnej antidebugovacej metody to aj tak nebude mat zmysel.

Ako by ste zlomili ten moj navrh? Nechcem vyryvat, ale zaujima ma to.
Predpokladajme funkciu databazoveho jazyka s nazvom HASH (nieco ako MD5 ale pokrocilejsie).

Teraz napisem pseudokod. V delphi som uz dlho nerobil tak to bude nejaka Java :

bude po disassemblovaní vyzerať nejako takto:


Stačí zmeniť jedinú inštrukciu (jg na jmp a na dané návestie so správnym číslom sa odskočí aj pri nesprávnom serialovom kľúči) a cracker sa ani nezapotí.

presne tak, cital som crack manualy no a fakt sa to da lahko, jedine co ma napada je "zbordelizovat" kod ,sifrovat volania, pchat falosne funkcie, skakat v kode ako sa to robi pri malwari aby ho bolo tazko debugovat ale ... to je pes a macka. A inak tu databazu nechcem hlavne kvoli tomu ze je tam konecny pocet klucov.

Najlepšie bude použiť dobré anti-debuggovacie ochrany, ako ti poradil stopa. Zameraj sa hlavne na detekciu aktívneho debuggera a dump programov (ktoré skopírujú tvoj kód priamo z operačnej pamäte). Ak crackerovi zneprístupníš spustenie tvojho programu v debuggeri, stáva sa bezmocným. Ďalej použi nejaké PE-kompresory, ktoré ti okrem zmenšenia aplikáciu aj zašifrujú.
Samozrejme skúsený programátor to obíde aj tak, ale začiatočníci sa väčšinou po pár neúspešných pokusoch vzdajú.

myslis iffdebugerpresent? to je skor vtip ako odradzanie ale jasne, nieco tam supnem, dik za rady

to nie, to je zbytocne, to sa obide zmenou 1 bitu v pameti, skor som myslel nieco zlozitejsie, na nete je toho kopa. Napr peter ferrie mal seriu pdf o metodach, staci hladat

Rozumiem a ako sa z vykompoilovaneho execka dostanes k assembly kodu ? Normalne sa to da debugovat a vsetko vidis ?
Alebo ako by si sledoval vykompilovany javacky bytecode?

normaly exe obsahuje strojovy kod, ktorý je možné disassemblerom previesť jednoducho na Assembler. Neviem ako to funguje v javy, ale o moc zložitejšie to nebude, mam dokonca pocit, že tam je ten kod priamo prítomný a stačí ho hex editorom previesť na znaky, ale to sa mi len zdá, nemám ako vyskúšať.

EXE súbor má presne stanovenú štruktúru --> DOS hlavička, úsek pre krátky DOS program (kde je uložená tá hláška, že tento program pobeží iba v DOSe), PE-hlavičku, tabuľku sekcií a jednotlivé sekcie. Ďalej si musíš uvedomiť, že assebmler je niečo ako synonymum strojového jazyka, je to len niečo zrozumiteľnejšie, ako jednotky a nuly. A teda ak niečo skompiluješ a vytvorí sa z toho exe modul, všetok kód (je jedno aký jazyk sa použil) sa prevedie do binárnej podoby do toho exe na určité miesto v jeho štruktúre. A disassemblovaním sa vlastne zo štruktúry vyčíta, kde v súbore začína kód programu a od tejto adresy sa pekne vypíšu všetky inštrukcie v assembleri (každá inštrukcia je zdokumentovaná a vie sa, aké má binárne vyjadrenie).

Forty, ide o pouzitu db. ak chces trvat na SQLite tak ta vyzaduje externu sqlite.dll ktora je embeded databazou spolu so suborom dat. sikovnejsi koder by si naprogramoval vlastnu dll ktoru by podhodil miesto sqlite.dll a ta by vkazdom pripade pri dotaze select count(*) ... vratila potrebne data rovnajuce sa spravnemu heslu. dalsi sposob je priamo napadnut obsah databazy a to som sa nedostal este ku crackovaniu exe

programovanim vlastnej dll by to sudny clovek neriesil, co ak by vyuzival viacere funkcie z tej povodnej. Ako uz bolo spomenute, nech by spravil hviezdne, ba hoci aj slnecne kontrolovanie serialu, je zbytocne pokial nespravi poriadny antidebug, mnoho kvalitnych komercnych ochran na to zabuda a potom to tak vyzera.

bla bla bla, uroven ochrany je presne taka vysoka na aku si ju ceni tvorca software. ako programator mozem dlabat vrazat nehorazne prachy za nepriestrelny ochranny system ked na samotnom softe zarobim podstatne menej, radsej znizim cenu tak aby pripadny cracker nemarnil cas prelamovanim mojej ochrany. toto pravidlo plati dvojnasobne v pripade specifickeho softu ktory je zaujimavy pre malu skupinu uzivatelov. ide hlavne o softy uctovnickeho charakteru ktore niesu masovo ziadane a pre crackerov nezaujimave. zato softy typu adobe photoshop , to je ina liga , o taky soft je podstatne vacsi zaujem. mam dojem ze ani soft ktory chce chranit HA2 asi nepatri medzi soft masoveho zaujmu a ani jeho cena asi nebude taka vysoka aby ho bolo nutne chranit nejak brutalne nepriestrelnou silou.

aby som nezakladal iny topic ked sa tu uz tak pekne diskutovalo. Viete mi poradit ako to dat, pripadne kam do registrov(info o registracii ci je alebo nieje)? Ako sa to bezne robi etc

Keď to chceš určite týmto spôsobom, tak takto:

Ale je to jednoduché vystopovať a upraviť, ak tam máš čisto informáciu o registrácii ...

No nie urcite tymto, rad si necham poradit ako by to bolo co najlepsie. Ale napada ma len takto + neako to prepojit so zapisom aj do neakeho suboru nech to nieje len tak obiditelne zmenou reg hodnoty.

ved tak či tak kontroluješ platnosť kódu, nemôžeš ho uložiť priamo do registrov a zakaždým porovnať jeho platnosť? Ked si niekto kúpi a dá licenciu ďalej, aj tak nemôžeš nic spraviť, takto si zabezpečíš aspoň 1 predanu kópiu.