Ein neuer Kopierschutz

[niwax]

DosAmp schrieb:  Gerade der Punkt „Maus“ ist ja wirklich ein Failgriff. Wenn mal meine USB-Maus kaputt ist und ich nur noch eine serielle (:oO3 oder gar keine Maus mehr besitze und per Tastatur-/Joystickeingabe navigiere, würde die Routine schon versagen.

Der übliche DRM-Mist beschränkt sich meistens auf BIOS, Festplatte, RAM und OS, wobei letzteres bei plattformübergreifenden Anwendungen als erstes unter den Tisch fällt.

Also, ich mach - wie schon gesagt -wahrscheinlich noch ne Toleranz rein, wg. Plattformübergereifen etc: Das ist doch gerade der Sinn: man will nicht, dass sich jemand das Programm auf nen anderen PC zieht, also schaut man nach, ob die Umgebung noch die selbe ist. Was ist da das Problem?

@oreissig Also: Er baut sich mehrere Hashs, die insgesamt 2048 bit groß sind. Dann nimmt er sich aus dem Code des Programms nen bis zu 19000-Bit Key, mit dem dann der Hashh verschlüsselt und in ne Datei gespeichert wird. Das ist nötig, damit man nicht nem anderen Programm den gleichen Hash unterschieben kann. nBlow nenne ich angelehnt an BlowFish, weil es das gleiche Konzept verfolgt - aufblähen mit Müll, aber mit nem anderen Ansatz: zuerst wird das erste Byte der Daten mit dem ersten Byte des Passworts per XOR verknüpft, dann wird eine Anzahl von Müll-Bytes eingefügt, die auf dem zweiten Byte des Passworts basieren, dann geht immer so weiter, mit dem zweiten Byte der Daten und dem dritten+vierten Byte des Passworts usw...

[oreissig]

niwax schrieb:  Plattformübergereifen etc: Das ist doch gerade der Sinn: man will nicht, dass sich jemand das Programm auf nen anderen PC zieht, also schaut man nach, ob die Umgebung noch die selbe ist. Was ist da das Problem?

i.d.R. gehts bei nem Kopierschutz darum, dass es nicht kopiert wird das muss nicht unbedingt bedeuten, dass die programmausführung an einen Rechner gekettet wird

niwax schrieb:  Er baut sich mehrere Hashs, die insgesamt 2048 bit groß sind. Dann nimmt er sich aus dem Code des Programms nen bis zu 19000-Bit Key, mit dem dann der Hashh verschlüsselt und in ne Datei gespeichert wird. Das ist nötig, damit man nicht nem anderen Programm den gleichen Hash unterschieben kann.

was sind das alles für hashes? warum wird das dann so groß gemacht?
nagut, am wichtigsten ist vll die frage: wie gehts dann weiter? man hat quasi einen key, der sowohl programm als auch rechner beinhaltet, wie funktioniert dann der eigentliche schutz?

niwax schrieb:  nBlow nenne ich angelehnt an BlowFish, weil es das gleiche Konzept verfolgt - aufblähen mit Müll, aber mit nem anderen Ansatz: zuerst wird das erste Byte der Daten mit dem ersten Byte des Passworts per XOR verknüpft, dann wird eine Anzahl von Müll-Bytes eingefügt, die auf dem zweiten Byte des Passworts basieren, dann geht immer so weiter, mit dem zweiten Byte der Daten und dem dritten+vierten Byte des Passworts usw...

hm, würd gern mal den code dazu sehn, mit etwas zeit werd ichs mir irgendwann mal genauer anschauen

[niwax]

Der Code:
EDIT: Sehe grade, dass das die ganzen einrückungen löscht, nochmal:

Spoiler anzeigen

Code:

Verschlüsseln:
    Function Check() As Boolean
        Dim P() As Byte, T As String, C As String, X() As Byte, Z As Integer
        Try
            P = My.Computer.FileSystem.ReadAllBytes(Application.ExecutablePath)
            X = My.Computer.FileSystem.ReadAllBytes(Application.StartupPath & "\nanticop.y")
            Z = 0
        Catch ex As Exception
        End Try
        T = ""
        Try
            For I As Integer = 0 To 127
                T = T & Chr(P(I) Xor X(Z))
                Z += 1
                Z += P(I + 128)
            Next
        Catch ex As Exception
        End Try
        C = GetHash()
        MsgBox(C & vbCrLf & T)
        Return (C = T)
    End Function

Entschlüsseln:
    Sub Generate()
        Dim P() As Byte, C As String, X() As Byte, Z As Integer
        P = My.Computer.FileSystem.ReadAllBytes(Application.ExecutablePath)
        ReDim X(KeyLen() \ 8)
        C = GetHash()
        Z = 0
        For I As Integer = 0 To 127
            X(Z) = P(I) Xor Asc(C(I))
            Z += 1
            Randomize()
            For J As Integer = Z To Z + P(I + 128)
                X(J) = CInt(Rnd() * 254)
            Next
            Z += P(I + 128)
        Next
        My.Computer.FileSystem.WriteAllBytes(Application.StartupPath & "\nanticop.y", X, False)
    End Sub

[Blue]

Ich hab mal ne ernste Frage, wie kann man nur ein Kopierschutz programmieren?

[Sje]

Ich schließe mich da Blue an, wenn ich Programme schreiben könnte würde ich sie als OpenSource veröffentlichen.

[Blue]

Sje schrieb:  Ich schließe mich da Blue an, wenn ich Programme schreiben könnte würde ich sie als OpenSource veröffentlichen.

Jo.

Und so können andere noch mit dran Entwickeln und Fehler ausbessern oder gar tolle Features reinbringen. Wenn alle so denken würden, hätten wir gar kein Problem mehr

[Dirk]

Ich schätze mal es ist auch eher als Fingerübung zu sehen. Beim Butter&Brot programmieren interessiert kaum jemand der quellcode. hatte nur einmal, das einer aus dem forum hier mal nen kalender von mir gebrauchen konnte. war aber auch java und hatte ins jar den code auch gleich reingeworfen.

[gandro]

Es gibt drei Gründe, warum als kleiner Programmierer Quellcode veröffentlichen eine gute Idee sein kann:

- Sicherheitsanalyse. Es gibt viele Leute, die sich für Sicherheitskram interessieren und daher auch einfach aus Spass mal deinen sicherheitskritischen Quellcode durchlesen und dir Tipps geben können, was da kaputt sein kann. Bei geheime Algorithmen finden auch Analysen statt und es werden Lücken gefunden (z.B. Skype), nur gibt dir dann keiner Verbesserungsvorschläge.

- Nützlichkeit. Ab und zu schreibt man ja auch Programme, die nützlich sind und von anderen verwendet werden. Da kommt es dann gerne vor, dass da jemand selber noch eigenen Krams hinzufügen will.

- Lernen. Lernt man Programmieren oder lernt man eine neue Sprache, dann kann es sinnvoll sein, die ersten eigenen Programme hochzuladen, damit Leute mit Erfahrung einem Tipps geben können.

[oreissig]

wie gandro bereits sagte gibts da schon ein paar ernsthafte Vorteile, aber im Endeffekt seis doch jedem selbst überlassen und hier auch nicht Gegenstand der Debatte

den algo hab ich mir jetz noch nich genau angeschaut, mir sind nur fix paar sachen aufgefallen:

• visual basic? uff lang ists her
• weiß nich genau, wie exception handling da gemacht wird, aber für mich siehts so aus als fängst du in paar blöcken einfach alle möglichen exceptions und behandelst sie danach nicht. das nennt man pokemon exception handling "if you gotta catch em all"
  besser: wirklich nur das catchen, was auftreten kann (also wohl die klasse der IOExceptions oder besser noch genauer) und diese natürlich auch behandeln (z.B. abbruch oder weiterwerfen)
• warum resized du in der 2. Methode X direkt nach dem deklarieren?
  resizen ist so mit das schlechteste und langsamste, was man mit einem array tun kann
• sämtliche variablen mit einem einzigen Buchstaben zu bezeichnen scheint ne alte Basic-Angewohnheit zu sein, die sich bis heute durchzieht...vll könnte man über aussagekräftigere namen als P, T, C, Z usw nachdenken
  

[gandro]

Was macht eigentlich GetHash()? Ist ist ja wohl kaum Hashtable.GetHash Method (System.Collections) ?