Self validerende binaries?

Question

My vraag is redelik eenvoudig:Jy is 'n uitvoerbare lêer wat "Toegang verleen" of "Toegang geweier" uitvoer en bose persone probeer om jou algoritme te verstaan ​​of jou binneste te pleister om jou heeltyd te laat sê "Toegang verleen".

Na hierdie inleiding wonder jy dalk baie wat ek doen.Gaan hy Diablo3 kraak sodra dit uit is?Ek kan jou bekommernisse kalmeer, ek is nie een van daardie klappers nie.My doelwit is crackmes.

Crackmes kan gevind word op - byvoorbeeld - www.crackmes.de.'n Crackme is 'n bietjie uitvoerbare wat (meeste van die tyd) 'n bietjie algoritme bevat om 'n reeks te verifieer en "Toegang verleen" of "Toegang geweier" uit te voer, afhangende van die reeks.Die doel is om hierdie uitvoerbare uitset die hele tyd "Toegang verleen" te maak.Die metodes wat jy toegelaat word om te gebruik, kan dalk deur die skrywer beperk word - geen pleister, geen demontering - of behels enigiets wat jy kan doen met 'n binêre, objdump en 'n hex-redigeerder.Crackmes is een deel van die pret, maar as 'n programmeerder wonder ek hoe jy moeilike crackmes kan skep.

Basies dink ek die crackme bestaan ​​uit twee hoof dele:'n sekere reeksverifikasie en die omliggende kode.

Dit is baie moontlik om die reeksverifikasie moeilik op te spoor deur slegs samestelling te gebruik, ek het byvoorbeeld die idee om die reeks te neem as 'n inset vir 'n gesimuleerde mikroverwerker wat in 'n sekere toestand moet eindig om die reeks aanvaar te kry.Aan die ander kant kan 'n mens goedkoop groei en meer leer oor kriptografies sterk maniere om hierdie deel te beveilig.Dit moet dus nie moeilik wees om dit moeilik genoeg te maak om die aanvaller te probeer pleister nie.

Die moeiliker deel is egter om die binêre te beveilig.Kom ons aanvaar 'n volmaak veilige reeksverifikasie wat nie op een of ander manier omgekeer kan word nie (natuurlik weet ek dit kan omgekeer word, in twyfel, jy ruk dele uit die binêre wat jy probeer kraak en gooi ewekansige reekse daarna totdat dit aanvaar word).Hoe kan ons verhoed dat 'n aanvaller net spronge in die binêre ignoreer om ons binêre enigiets te laat aanvaar?

Ek het 'n bietjie oor hierdie onderwerp gesoek, maar die meeste resultate oor binêre sekuriteit, selfverifiërende binaries en sulke dinge eindig in artikels wat aanvalle op 'n bedryfstelsel probeer voorkom deur gekompromitteerde binaries te gebruik.deur sekere binaries te onderteken en daardie handtekeninge met die kern te bekragtig.

My gedagtes bestaan ​​tans uit:

• kontrolering van eksplisiete liggings in die binêre om spronge te wees.
• kontrolesom dele van die binêre en vergelyk kontrolesomme wat tydens looptyd bereken is met dié.
• het positiewe en negatiewe looptydkontroles vir jou funksies in die kode.Met newe-effekte op die reeksverifikasie.:)

Kan jy aan meer maniere dink om 'n moontlike aanvaller langer te irriteer?(natuurlik kan jy hom nie vir ewig weghou nie, een of ander tyd sal alle tjeks verbreek word, tensy jy daarin geslaag het om 'n kontrolesom-generator te breek deur die korrekte kontrolesom vir 'n program in die program self te kon insluit, hehe)

Answer 1

Jy is besig om in "Anti-omkeer tegnieke" te kom.En dit is basies 'n kuns.Erger is dat selfs al stamp jy nuwelinge, daar is "anti-teen-omkeer-inproppe" vir Olly en IDA Pro wat hulle kan aflaai en baie van jou teenmaatreëls kan omseil.

Teenmaatreëls sluit in ontfouteropsporing deur lokvalontfouter-API's, of die opsporing van 'enkelstap'.Jy kan kode invoeg wat nadat jy 'n ontfouterinbraak opgespoor het, aanhou funksioneer, maar heelwat later in die program op willekeurige tye begin optree.Dit is regtig 'n kat-en-muis-speletjie en die klappers het 'n beduidende oorhand.

Uitteken...http://www.openrce.org/reference_library/anti_reversing - Van wat daar buite is.

http://www.amazon.com/Reversing-Secrets-Engineering-Eldad-Eilam/dp/0764574817/ - Hierdie boek het 'n baie goeie anti-omkeer inligting en stap deur die tegnieke.Goeie plek om te begin as jy in die algemeen besig is om te reverse.

Answer 2

Ek glo hierdie dinge is oor die algemeen meer moeilikheid as wat dit werd is.

Jy spandeer baie moeite om kode te skryf om jou binêre te beskerm.Die slegte ouens spandeer minder moeite om dit te kraak (hulle is oor die algemeen meer ervare as jy) en laat dan die kraak los sodat almal jou beskerming kan omseil.Die enigste mense wat jy sal irriteer, is daardie eerlike mense wat deur jou beskerming verontrief word.

Sien seerowery net as 'n besigheidskoste - die inkrementele koste van seerowersagteware is nul as jy verseker dat alle ondersteuning slegs vir betalende kliënte gedoen word.

Answer 3

Daar is TPM-tegnologie: tpm op wikipedia

Dit laat jou toe om die kriptografiese tjeksomme van 'n binêre op spesiale skyfie te stoor, wat as eenrigtingverifikasie kan dien.

Let wel:TPM het soort van 'n slegte rap omdat dit vir DRM gebruik kan word.Maar vir kundiges in die veld is dit soort van onregverdig, en daar is selfs 'n oop-TPM groep wat Linux-gebruikers toelaat om presies te beheer hoe hul TPM-skyfie gebruik word.

Answer 4

Een van die sterkste oplossings vir hierdie probleem is Trusted Computing.Basies sou u die toepassing enkripteer en die dekripsiesleutel na 'n spesiale skyfie (die Trusted Platform Module), Die skyfie sal eers die toepassing dekripteer sodra dit geverifieer het dat die rekenaar in 'n "vertroude" toestand is:geen geheue kykers/redigeerders, geen ontfouters ens.Basies sal jy spesiale hardeware nodig hê om net die gedekripteerde programkode te kan sien.

Answer 5

Dus, jy wil 'n program skryf wat 'n sleutel aan die begin aanvaar en dit in die geheue stoor, en dit dan van skyf af haal.As dit die regte sleutel is, werk die sagteware.As dit die verkeerde sleutel is, val die sagteware ineen.Die doel is dat dit vir seerowers moeilik is om 'n werkende sleutel te genereer, en dit is moeilik om die program te pleister om met 'n ongelisensieerde sleutel te werk.

Dit kan eintlik bereik word sonder spesiale hardeware.Oorweeg ons genetiese kode.Dit werk gebaseer op die fisika van hierdie heelal.Ons probeer om dit te hack, dwelms te skep, ens., en ons faal jammerlik, gewoonlik skep ons tonne ongewenste newe-effekte, want ons het nog nie die komplekse "wêreld" waarin die genetiese "kode" ontwikkel het om te funksioneer ten volle omgekeerd gemanipuleer nie. .Basies, as jy alles op 'n algemene verwerker ('n algemene "wêreld") laat loop, waartoe almal toegang het, dan is dit feitlik onmoontlik om so 'n veilige kode te skryf, soos gedemonstreer deur huidige sagteware wat so maklik gekraak word.

Om sekuriteit in sagteware te bereik, sal jy in wese jou eie genoegsame komplekse platform moet skryf, wat ander heeltemal en deeglik sal moet reverse engineer om die gedrag van jou kode te verander sonder onvoorspelbare newe-effekte.Sodra jou platform egter omgekeerd ontwerp is, sal jy terug wees na die eerste plek.

Die vangplek is dat jou platform waarskynlik op gewone hardeware gaan werk, wat jou platform makliker maak om te reverse engineering, wat op sy beurt jou kode 'n bietjie makliker maak om te reverse engineering.Dit kan natuurlik net beteken dat die balk effens verhoog word sodat die vlak van kompleksiteit wat van jou platform vereis word, moeilik genoeg is om te reverse engineering.

Hoe sal 'n voldoende komplekse sagtewareplatform lyk?Byvoorbeeld, miskien na elke 6 optelbewerkings, gee die 7de optelling die resultaat vermenigvuldig met PI gedeel deur die vierkantswortel van die log van die modulus 5 van die verskil van die totale aantal aftrek- en vermenigvuldigingsbewerkings wat uitgevoer is sedert stelselinitialisering.Die platform sal onafhanklik van daardie nommers moet tred hou, net soos die kode self, om die korrekte resultate te dekodeer.Dus, jou kode sal geskryf word op grond van kennis van die komplekse onderliggende gedrag van 'n platform wat jy ontwerp het.Ja, dit sal verwerkersiklusse eet, maar iemand sal daardie klein verrassingsgedrag moet omkeer en dit in enige nuwe kode moet herontwerp om dit behoorlik te laat optree.Verder sal jou eie kode moeilik wees om te verander sodra dit geskryf is, want dit sal ineenstort in onherleibare kompleksiteit, met elke reël wat afhang van alles wat voorheen gebeur het.Natuurlik sal daar baie meer kompleksiteit wees in 'n voldoende veilige platform, maar die punt is dat iemand jou platform sou omgekeer het voordat hulle jou kode kon omkeer en verander, sonder aftakelende newe-effekte.

Answer 6

Goeie artikel oor kopiebeskerming en beskerming van die beskerming Hou die seerowers by die baai:Implementering van kraakbeskerming vir Spyro:Jaar van die Draak

Die interessantste idee wat daar genoem word en wat nog nie genoem is nie, is deurlopende mislukkings - jy het kontrolesomme wat 'n enkele greep verander wat veroorsaak dat 'n ander kontrolesom misluk.Uiteindelik laat een van die kontrolesomme die stelsel ineenstort of iets vreemds doen.Dit laat pogings om jou program te seerower onstabiel lyk en laat die oorsaak ver van die ongeluk voorkom.