Kortom, ja, u kunt het uitvoerbare bestand wijzigen, een debugger gebruiken, enz. om de logica van de code die wordt uitgevoerd te wijzigen.

Maar dat is misschien niet genoeg.

Om uw voorbeeld van ".zip-wachtwoorden" te gebruiken, gebruiken wachtwoordbeveiligde archieven het wachtwoord om een ​​coderingssleutel af te leiden. Tenzij u een correct wachtwoord opgeeft, zal de gegenereerde sleutel onjuist zijn, en zelfs als u deze wijzigt om een ​​verkeerde sleutel te gebruiken, zal het het ZIP-bestand niet met succes ontsleutelen.

Een ander scenario zou een setuid-uitvoerbaar kunnen zijn dat draait met hogere privileges. Je zou het onder een debugger kunnen draaien, of het naar je gebruikersaccount kopiëren en wijzigingen aanbrengen, maar het enige dat hierdoor wordt bereikt, is het uitvoeren met de machtigingen van je gebruiker, waardoor de exploitatiemogelijkheden worden omzeild.

Nou, uw perceptie van .zip-wachtwoorden is niet juist. De benadering, die ook door veel andere programma's wordt gebruikt, is om altijd een decoderingsalgoritme uit te voeren en een resultaat te verkrijgen, voordat het programma zelfs maar de beslissing "goed of slecht wachtwoord" heeft bereikt. De truc is dat de decodering rotzooi oplevert voor elk wachtwoord behalve een goed wachtwoord dat "magisch" (of liever - wiskundig) de juiste gegevens berekent. Dus het programma weet niet wat het goede wachtwoord is.

Het "goede of slechte" moment dat je wilt hacken, controleert alleen of het resultaat onzin is. Het heeft niet veel voordelen om dat op te heffen.

Ja en Nee.

Aangezien nog niemand een echt (niet-computergerelateerd) voorbeeld heeft bedacht, heb ik ' Ik zal het hier proberen:

Stel je voor dat je probeert aan boord te gaan van een vlucht. Je hebt een instapkaart nodig, anders laten de beveiligingsmedewerkers je niet door. Als je toegang hebt tot het systeem en je kunt het aanpassen (stel dat je de CEO bent), kun je dan de beveiliging omzeilen? Ja! Je kunt:

• De beveiligingspersoneel verwijderen (verwijder de volledige authenticatiecomponent)
• De jongens vragen iedereen binnen te laten (verwijder het vinkje 'als passagier een geldige instapkaart heeft' )
• Vraag de jongens om toegang te geven als iemand een speciale instapkaart presenteert (voeg een nieuwe validatieregel toe om valse inloggegevens toe te staan)

Nu, een ander scenario : een heleboel kluizen staan ​​in een bank. Om een ​​kluis te openen, heb je een fysieke sleutel nodig om het slot te draaien.

Kun jij de vorige truc halen? Ja dat kan, maar het helpt niet. Het is niet alsof de beveiligingsman die daar staat toegang heeft tot alle kluizen - hij heeft niet de sleutel van een van de kluizen. Je kunt hem in elkaar slaan, maar hij bezit niet alleen wat nodig is (de fysieke sleutel) om de sloten te openen.

Je kunt proberen het slot te pakken (brute-forcing), maar het zou ook extreem tijdrovend zijn (de wiskunde van moderne coderingssleutels zegt dat je enkele miljarden jaren nodig hebt om het te ontgrendelen, zelfs als alle computers ter wereld het voor je doen). Dus daar ben je - in dit ontwerp (gegevenscodering) is de enige manier om de opgeslagen gegevens te verkrijgen, het gebruik van een sleutel, waardoor het onmogelijk is deze te omzeilen.

Natuurlijk, software kan doen wat je programmeert.

Als een triviaal voorbeeld, als ik een Python-programma kreeg dat op een wachtwoord controleerde:

  password = raw_input ('Voer je wachtwoord in:') if password! = 'oh-so-secret': sys.exit (1) do_secure_thing ()  

Ik zou het eenvoudig kunnen veranderen in maakt niet uit wat het wachtwoord is:

  wachtwoord = raw_input ('Voer uw wachtwoord in:') do_secure_thing ()  

(In dit geval kunt u ook kijk gewoon wat het hardgecodeerde wachtwoord in platte tekst is en voer het in.)

Met binaire applicaties moet u ze decompileren voordat u de broncode kunt wijzigen, maar er zijn tal van decompilers voor veelgebruikte talen.

Dit is waarom codeondertekening bestaat.

Als dit niet uw eigen systeem is, zijn uw opties misschien wat beperkter. Op de meeste Unix-achtige systemen worden uitvoerbare bestanden over het algemeen opgeslagen met alleen-lezen en alleen-uitvoeren machtigingen voor niet-rootgebruikers; dus als u geen root bent, kunt u het doeluitvoerbare bestand niet wijzigen. Er zijn andere, minder directe methoden die u kunt proberen, maar als die niet slagen, wilt u naar een andere vector gaan.

Een keylogger registreert bijvoorbeeld de wachtwoorden die de gebruiker invoert, zodat u ze opnieuw kunt gebruiken later zelf.

Een andere aanvalsmethode waarbij de bron van een programma niet hoeft te worden gewijzigd, is door het laadpad van de dynamische bibliotheek zodanig te wijzigen dat het programma een door u geschreven bibliotheekoproep gebruikt in plaats van die verwacht het. Als ze een externe, dynamisch geladen bibliotheek gebruiken voor wachtwoordbeheer, en die bibliotheek heeft een functie verify_password () die een boolean retourneert, kun je je eigen verify_password () schrijven dat geeft altijd true terug, en laad dat in plaats daarvan.

Het echte verschil dat het antwoord verandert van "ja" in "nee" is of het wachtwoord eigenlijk geen wachtwoord is, maar een coderingssleutel. Als de gegevens gecodeerd zijn, maakt het niet uit wat externe programma's doen - de gegevens worden nog steeds gecodeerd totdat het decoderingsalgoritme de juiste sleutel heeft gekregen.

Stel dat u een app heeft die gegevens opslaat in een tekstbestand (of een kleine database), maar om het bestand vanuit de app te openen, moet u een wachtwoord invoeren of een speciaal proces gebruiken. U kunt het tekstbestand (of db) eenvoudig openen vanuit de bestandsmap met behulp van het besturingssysteem (geen reverse engineering vereist). Vroeger gebeurde dit veel in oudere programma's (vooral games).

Daarom nemen apps die hopen veilig te zijn, maatregelen om de gegevens van het besturingssysteem zelf te beschermen. Zoals het versleutelen van de gegevens of het versluieren van de gegevens om het gebruik ervan moeilijk te maken.

Het hangt af van hoe de software XYZ het wachtwoord gebruikt om de gewenste actie te produceren en met welk type gegevens het werkt.

Als we kijken naar het abstracte algoritme van het XYZ programma zou het zijn:

1. Vraag de gebruiker om het wachtwoord in te voeren.
2. Doe iets met het wachtwoord dat door de gebruiker is ingevoerd.
3. Produceer gewenste output (of voer gewenste actie uit).

Uw vraag kan dus worden beperkt tot stap # 3 :

Is het mogelijk om gewenste uitvoer te produceren (of een actie uit te voeren) zonder het programma XYZ te gebruiken?

Er zijn hier veel varianten mogelijk, maar het belangrijkste is dat de software XYZ voert bepaalde stappen uit om het resultaat te produceren.

Als iemand een programma ABC kan maken dat hetzelfde resultaat kan produceren in een redelijke hoeveelheid zonder dat een wachtwoord nodig is, kan de XYZ worden omzeild.

Dat zou erop wijzen dat de volledige " bescherming 'is geïmplementeerd in het programma XYZ zelf.

Als het maken van een dergelijk programma ABC niet mogelijk is, is de bescherming afhankelijk van een algoritme dat de wachtwoord ongeacht welk programma het probeert te gebruiken .

Voorbeeld 1 : een onbevoegd OS-account kan geen wachtwoord instellen voor een andere gebruiker, omdat het afgedwongen door het besturingssysteem. Het besturingssysteem is in dit geval dus XYZ . Maar men kan de computer opstarten vanaf een opstartbare schijf en het bestand met wachtwoorden overschrijven, omdat het originele besturingssysteem op dit moment niet werkt en daarom de bescherming niet kan afdwingen. We waren dus in staat om een ​​gewenst resultaat te produceren zonder het programma XYZ te gebruiken.

Voorbeeld 2 : in het tweede voorbeeld is de systeemschijf van het besturingssysteem correct versleuteld met een sterk crypto-algoritme. Als we de computer opstarten met een opstartbare schijf in een poging het originele besturingssysteem te omzeilen, zullen we ontdekken dat we ons doel niet kunnen bereiken, omdat we geen toegang hebben tot het bestand met wachtwoorden. Het bevindt zich op een partitie die eerst moet worden ontsleuteld, maar we kennen het wachtwoord niet. Een poging om het decoderingsproces met brute kracht te forceren zou niet snel het gewenste resultaat opleveren, daarom was het in dit geval niet mogelijk om het programma XYZ of enig ander programma met vergelijkbare functionaliteit te omzeilen, omdat de onderliggende gegevens vereisten het wachtwoord .

Het zip-wachtwoord is geen voorbeeld van wat u denkt. Maar veel dingen zijn , in het bijzonder "proef" -versies die beperkt zijn in tijd of functieset.

Ik herinner me een paar artikelen in een programmeermagizine (mogelijk Computertaal ) waarin wordt uitgelegd hoe je dat moet doen en hoe je pogingen om dat met je code te doen kunt dwarsbomen.

Ik ken gevallen waarin het letterlijk was zo simpel als het vinden van de vergelijkingsverklaring en het veranderen van de sprongvoorwaarde - dat wil zeggen, het veranderen van één byte - om de echte controle te omzeilen.

Dit is soms nu het geval als de auteur eenvoudigweg schreef de regel code als onderdeel van het programma. Maar voor activeringssleutels en dergelijke is er een hele industrie ontstaan ​​en de auteur kan een kit toevoegen die de eigenlijke test versluiert en het moeilijk maakt om het programma te laten functioneren als er wordt geprobeerd het te gebruiken met behulp van veelgebruikte technieken die bekend zijn bij de foutopsporingscode van een programmeur. .

Het hangt allemaal af van hoe het systeem werkt bij het decoderen van het wachtwoord.

Je stelt je een heel basaal wachtwoordsysteem van het "inlog" -type voor dat zou kunnen worden geïnfiltreerd. Zoiets als ZIP-bestanden en websites gebruiken echter verschillende methoden om mensen te bestrijden die het systeem alleen bewerken om het te dwingen het wachtwoord te onthullen.

Eén manier is het gebruik van MD5 samen met 'salt' om de beveiliging te vergroten - dit werkt op basis van het feit dat het wachtwoord wordt omgezet in een onherkenbare code die niet kan worden teruggedraaid - een eenvoudig voorbeeld van wat er gebeurt is als volgt

Systeem vraagt ​​om wachtwoord - bijv. PASSWORDSysteem voegt 'salt' toe aan wachtwoord - bijv. 1234 (wachtwoord is nu PASSWORD1234) Systeem gebruikt MD5 voor het wachtwoord met salt - de meeste mensen zullen weten dat PASSWORD op zichzelf de MD5-code zal genereren 319f4d26e3c536b5dd871bb2c52e3178 maar met het "1234" -zout toegevoegd aan het wachtwoord wordt de MD5 nu 579f276ad2a77e3ad --1698 een totaal andere code.

Op dit punt heeft het systeem nog steeds niet gecontroleerd of dat wachtwoord al dan niet geldig was, het geeft deze nieuwe code vervolgens door aan een ander gedeelte van het programma dat beslist of de MD5-code al dan niet komt overeen met wat wordt verwacht als het doet het toont het bestand (het initiële wachtwoord is al lang uit het geheugen gewist).

Iemand die dit type wachtwoord wil infiltreren, moet het initiële wachtwoord verkrijgen dat is ingevoerd eerst, en later nagaan of het programma het openen van het bestand toestond. Op een stuk software op een computer is het misschien mogelijk om het wachtwoord te verkrijgen en later te controleren of het bestand is geopend en het wachtwoord op deze manier te krijgen, maar als het wachtwoord als een MD5 + salt naar een andere server wordt verzonden ( bijvoorbeeld via javascript en PHP) wordt het een stuk lastiger omdat een computer het wachtwoord in het geheugen heeft dat het converteert en de php-server alleen het md5 + salt-wachtwoord heeft dat niet kan worden teruggeconverteerd.

Bovendien is een andere methode die wordt gebruikt om het wachtwoord op de een of andere manier in de gegevens te coderen, zo werken zip-bestanden, ik heb bijvoorbeeld een bestand met de volgende tekst ...

de snelle bruine vos springt over de luie hond

Ik geef hem een ​​eenletterig wachtwoord van! ok ik weet dat het een beetje simpel is, maar dit is een eenvoudig voorbeeld - de computer zou dat kunnen converteren! in zijn ASCII-equivalent en trek de ascii-code van elke letter ervan af om deze te coderen - de ascii-code voor! is 33 en de ascii-code voor t is 116 en 116-33 = 83 wat de ascii-code is voor een hoofdletter S, dus wanneer de gegevens worden versleuteld, wordt de bovenstaande regel opgeslagen als

SGD PTHBJ AQNVM ENW ITLOR NUDQ SGD K @ YX CNF

als iemand dit bericht probeert te ontsleutelen, weet je niet of ze het juiste wachtwoord hebben of niet - als ze het wachtwoord # invoeren in plaats van! ze krijgen het volgende bericht terug.

vjg swkem dtqyp hqz lworu qxgt vjg nc | {fqi

wat nergens op slaat - dus de meeste systemen controleren de geldigheid van een wachtwoord, maar ze veranderen het wachtwoord in eerste instantie zodat het niet kan worden gehackt door iemand die het resultaat alleen maar omleidt - de enige keer dat dit soms mislukt is wanneer iemand zijn eigen nepwebsite of -programma maakt en de gebruiker ertoe aanzet om in eerste instantie zijn wachtwoord in te voeren in het nepprogramma of de website en natuurlijk komen veel websites daar nu zelfs aan om door authenticatietokens te gebruiken die speciale wachtwoorden genereren die slechts ongeveer 5 minuten per keer geldig zijn (bijvoorbeeld de HSBC smart key).

De vraag heeft verduidelijking nodig. Uw begrip van hoe een met een wachtwoord beveiligd zipbestand wordt gelezen, is onjuist. Zoals anderen hebben opgemerkt, is een zipbestand versleuteld (de gegevens worden versleuteld) en is het wachtwoord de sleutel om te ontsleutelen.

Wat je beschrijft (een omleiding van code-uitvoering via reverse engineering van de codestroom) zou werk om de "toegangscontrole" die door het programma wordt afgedwongen te omzeilen.

Dus, op uw oorspronkelijke vraag:

Is het mogelijk om softwarelogica te wijzigen om het commando uit te voeren in plaats van een ander commando? Als dat zo is, kan niets tegen kraken worden beschermd?

Het is zeker mogelijk om de softwarelogica te veranderen om commando's uit te voeren, waarbij de toegangscontrole wordt omzeild om iets te doen wat het programma anders zou kunnen doen, via reverse engineering. Dat ondersteunt echter niet uw tweede bewering dat "niets tegen kraken kan worden beschermd". Het versleutelde zipbestand is een mooi voorbeeld van waar je controle over de code je niet de inhoud van het bestand oplevert.

In dat geval is de sleutel geen poortwachter die je belet een codepad uit te voeren, maar eerder een vereiste component om bij de platte tekstgegevens te komen. Niets te maken met programma flow control.

Dit wordt in feite kraken genoemd en kan worden gedaan met een debugger. Er zijn voorwaardelijke sprongen zoals je, jne, jnz enz. Die kunnen worden uitgeschakeld om dit te bereiken. Lena's omkerende tutorials over tuts4you zouden een goed begin moeten zijn.

Het proces dat het beste kan worden omschreven als 'reverse engineering', is een timingaanval, waarbij de tijd wordt geanalyseerd die nodig is om een ​​wachtwoord te verifiëren. Het is inderdaad mogelijk om de verwerking van een algoritme te vertragen en te tellen hoeveel processortikken er nodig zijn om een ​​wachtwoord te weigeren. Naarmate u meer letters correct raadt, duurt het langer om ze te verwerpen, zodat u zich kunt laten leiden bij uw gissingen.

Dit is niet alleen een hypothetische situatie; deze aanval is gebruikt tegen SSL en sommige versies van Unix.