AW: Software gegen API-Zugriffe von aussen schützen?
Nicht möglich!
|
AW: Software gegen API-Zugriffe von aussen schützen?
Das ist mehr oder weniger die Wahl zwischen Strick und Pistole:
Das Ding wäre mehr oder weniger ein Forschungsprojekt mit ungewissen Ausgang :stupid: |
AW: Software gegen API-Zugriffe von aussen schützen?
Zitat:
Snagit ist eine Screenshot Software. Alles was du auf den Screen bringst, kann auch gescreenshottet werden, nichts anderes macht Snagit oder jedes andere beliebeige Screenshot-Programm. Die Frage die du dir stellen solltest ist, was du erreichen willst. Du willst Datendiebstahl verhindern. Gut. Aber wer sollte denn die Daten stehlen? Eine Schadsoftware? Du gehst doch nicht ernsthaft davon aus, dass deine Software auf kompromittierten Systemen läuft, oder? Wer könnte noch die Daten stehlen? Derjenige der an dem Arbeitsplatz arbeitet? Der kann aber auch sein Handy benutzen und den Screen abfotografieren. Die Frage ist, wie weit du gehen willst? Du willst Screenshots per Printscreen verhindern. Das geht noch relativ einfach. http://labnol.blogspot.de/2004/08/disable-print-screen-key-in-windows.html Aber selbst mit dem Windows-Snipping Tool kann man das schon wieder umgehen. Um das Ganze halbwegs dicht zu machen, müßtest du auch sämtliche Screencaptue und Screencam Programme blocken. Dabei wünsche ich viel Gluck und Spass. Darum die Frage nach Sinn und Unsinn. Bitte nicht falsch verstehen. Aber Sicherheit und Windows passen einfach nicht zusammen, besonders nicht auf dem Level, das du anstrebst. |
AW: Software gegen API-Zugriffe von aussen schützen?
Zitat:
Zitat:
Zitat:
Also es geht hier nicht darum, dass ein Otto-Normal-Anwender sich mal was ausdruckt oder sowas, sondern um professionelle Piraterie, mit der Absicht die Daten aus dem System zu extrahieren, die Hardware auseinander zu nehmen und zu kopieren, um eine billige Kopie zu erschaffen. Das wollen wir so gut wie möglich erschweren oder gar verhindern. Und unser Problem besteht nebenbei nicht nur auf Software- sondern auch auf Hardware-Ebene, da unser System mit einem eigenen Set an USB-Geräten ausgeliefert wird. Die Frage ist nicht, wie weit ich gehen will, sondern was im vernünftigen Rahmen möglich ist. Wie schon gesagt: Mir ist völlig bewusst, dass man keinen 100%igen Schutz bieten kann und ein Angreifer einfach eine Screen-Capturing-Software laufen lässt, die Texte per OCR extrahiert und die Bilder (die es zB zu den Texten geben kann) ausschneidet. Wo ein Wille ist, ist mindestens auch ein Weg. Andererseits können wir auch nicht einfach sagen, dass wir garnichts machen. Ich hoffe du verstehst mein Problem. :P Zitat:
Statt zu verhindern, dass man Controls ausliest, kann man "einfach" untypisches Verhalten blockieren. Zum Beispiel: - Wie oft ändert ein Benutzer die Datenbank-Kategorie, um sich was anderes anzuschauen? Sicher nicht mehr als 1x in 5 Sekunden. Und wenn er das doch öfters als X Mal macht, stimmt was nicht. - Wie oft führt ein Benutzer eine Analyse über die Hardware (mit geänderten Anfrageparametern) durch? Sicherlich auch nicht öfters X Mal pro Minute bzw. X Mal sofort immer wieder hintereinander. Wenn doch, stimmt was nicht. - Usw... Ich denke in die Richtung könnte man wirklich was machen. :thumb: |
AW: Software gegen API-Zugriffe von aussen schützen?
Zitat:
|
AW: Software gegen API-Zugriffe von aussen schützen?
Zitat:
|
AW: Software gegen API-Zugriffe von aussen schützen?
Wenn die Daten an sich tatsächlich so unglaublich wertvoll sind, dann ist es allein schon der völlig falsche Ansatz, diese komplett als Datenbank auszuliefern. Egal ob letztere symmetrisch oder assymetrisch verschlüsselt ist, in beiden Fällen muss zwangsläufig der Schlüssel ja beim Endnutzer vorliegen, und damit führt der einfachste Weg nach wie vor darüber, die Datenbank an sich zu entschlüsseln. Kein Screen-Scraping nötig, dann habe ich einfach ALLES.
Meiner Meinung nach wäre der wesentlich sinnvollere Weg, die Daten auf einem Server bereitzustellen, und API Request mit den Lizenzen der Nutzer zu signieren. Dann hat man exakte Kontrolle darüber, wie viele Daten pro Lizenz und pro Zeiteinheit abgefragt werden können. Der Nachteil an der Sache ist natürlich der online-Zwang. |
AW: Software gegen API-Zugriffe von aussen schützen?
Zitat:
Wenn also ein Chinese deine SW bzw. den Inhalt der DB klauen will, dann holt er sich 100 Landarbeiter (oder 1000), setzt die an deine SW und jeder schreibt etwas anderes ab. Gar-kein-Problem für die. Die unterhalten ja auch 1000 Leute, die WoW spielen, um dann irgendwelche Punkte zu verticken oder virtuelle Waren. Ich kann mir vorstellen, das die noch nicht einmal auf die Idee kämen, die SW per Screenshot abzukopieren, denn direkt Abschreiben geht eh schneller und ist billiger, als dann ne OCR-SW zu nehmen. Das Einzige, was einen Plagiator davon abhält, dein Produkt zu kopieren, ist die handwerkliche Qualität, die es benötigt, das Produkt herzustellen. Denn *das* muss erlernt werden und geht auch mit Manpower nicht von jetzt auf gleich. Aber selbst hier holen die Chinesen auf und produzieren durchaus beachtliche Qualität. Tipp: Sucht euch einen Partner in China, der Verbindungen zu den Triaden hat. |
AW: Software gegen API-Zugriffe von aussen schützen?
Zitat:
Ich weiß nicht, wie die Netzinfrastruktur in China aussieht, aber ein anderer Nachteil wäre hier wohl auch die flächendeckende Verfügbarkeit von genügend Bandbreite und Netzstabilität. Zitat:
Edit: Aber du hast wirklich recht. Es ist eigentlich absurd zu denken, dass ein Plagiator in China die technische Herangehensweise als erstes wählt, wenn das Land so vor Überbevölkerung und Staatsherrschaft strotzt, dass man an jeder Ecke Leute von jung bis alt findet, die sich für 'n Hungerlohn 18 Stunden am Tag vor den Computer setzen, um in WoW Gold und Items zu farmen oder Sachen abzuschreiben ... :pale: Zitat:
Zitat:
|
AW: Software gegen API-Zugriffe von aussen schützen?
Zitat:
Delphi-Quellcode:
Ich habe nun die Bezüge auf ThemeMgr.pas entfernt und nun kommt Compilerfehler ".exe kann nicht erstellt werden. Na toll.
{$ifedf COMPILER_7_UP}
Error: Delphi versions upper 7 have their own thememanger. You must remove the ThemeManager from the project for proper copmpilation. {$endif} Optimal geschützt der Mystix Editor. Optimal vor illegaler Veränderung abgesichert. Auch wenn Experten den sich zumLaufen kriegen werden. Bloß, habe ich in derselben Zeit nicht auch, übrigens mit den wirklich ansprechend aussehenden SPTBX KOmponenten oder mit den nun mal schon installierten Jedis das Editor Layout neu gebaut, einschließlich der Implementierung der Funktionen "Suchen", "Ersetzen", "Gehe zu Zeile" sowie der Clipboardfunktionen???? Wenn schon ein Softwareschutz soooooo sinnlos ist, dann macht es bitte wenigsten auf dem Gebiet der im Quelltext frei verfügbaren Software den interessierten Nutzern leichter setzt nicht schwierig zu installierende oder womöglich noch kostenpflichtige Koponenten voraus. Ausgenommen die Delphi Standard Komponenten. Die Jedis sind zudem nur schlecht dokumentiert und so für mich eher Ballast als nützliche Komponentensammlung. Auch ich habe, wenn auch in der Regel nur mitgelesen, wie ich jetzt auch wieder tun wollte, bis ich diesen Beitrag hier fand, die Geschichte mit Delphi Portable mit Interesse verfolgt. Und daher habe ich für mich beschlossen, die portable Version von Turbo Delphi zu nutzen, erweitert um die Teile, die zwar ohne .NET vorauszusetzen im Original, jedoch nicht in der im Internet verfügbaren englischen Version enthalten sind. Bereichert um den XRefactor aus der DP und ESSModel zur Modellunterstützung. Daher wollte ich eigentlich nicht noch in D7Per die Jedis noch mal installieren und den anderen Ballast dazu, um Mystix vielleicht doch noch zum Laufen zu kriegen. Bringt jetzt auch nix mehr, denn nach all dem Stress ist eine Weiterentwicklung dieses Projektes nur noch kommerziell möglich. Im Preis wäre dann aber auch der Anschaffungspreis für einen neuen fett ausgestatteten PC mit mindesten 4GB RAM, SSD Festplatte, etc. plus aktuelle Softwareentwicklungswerzeuge, abhängig von zukünftigen möglichen Projekten zwingend enthalten. Somit wird so eine Entwicklung für eine neue IDE wohl kaum sinnvoll sein, wenn mir da die IDEs von MS, einigen OpenSource-Entwicklern oder auch von Emba ansehe. Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:35 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz