mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Programm schützen


Autor: Robert Geierstanger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
als Unwissender wüde ich gerne mal eine Frage stellen.
Ist es möglich ein fertiges Programm für einen Atmel-Controller so zu
schützen dass es nur für eine gewisse Anzahl an Chips verwendet werden
kann?
Der Hintergrund: Wenn man mit einem Plan für eine Platine und dem
Programm für den Controller zu einer Fertigungsfirma geht, haben die
alle Unterlage diese Platine auch nacher noch fertigen zu können.
Wie kann ich also ein Controller Programm vor der Weiternutzung
schützen? Geht das überhaupt oder wie wird das sonst gemacht.

Gruß
Robert

Autor: Ernst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Anzahl der Kopien kannst Du nicht einschränken.

Lösungen:
 - Fertigungsfirma vertrauen
 - Controller selber programmieren, und die LOCK-Fuses setzen

/Ernst

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
danke erstmal Ernst.
Aber den Firmen in China zu vertrauen ist nicht immer leicht.
Und selbst programmieren ist ein großer logistischer Aufwand den ich
vermeiden will.

Gruß
Robert

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
jeder seriöse Fertiger behandelt Kundendaten absolut vertraulich. Ein
einziger Fall von "Veruntreuung" kann den Ruin der Firma bedeuten.Ich
glaube, du leidest da ein wenig unter Verfolgungswahn.
Ansonsten, wie schon gesagt, fertig gebrannte Controller liefern oder
die Software erst nach Bestückung draufspielen.

Autor: Ernst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und hier einen Schwung Controller programmieren, und zur Bestückung nach
China Liefern?

Oder Platine mit ISP-Anschluss ausstatten, Platine mit leeren
Controllern bestücken lassen, und die Geräte hier programmieren?

Ansonsten, wenn das Programmieren in China erfolgen muss:

kleine Public-Key check-routine in den Code einbauen, die eine Signatur
im Eeprom prüft und ansonsten den Start verweigert.

Je nach Geräteart: Signatur bei Auslieferung (+ Seriennr) ins Eeprom
brennen, oder bei Computer-Hardware bei Treiberinstallation mit
Freischatcode-check...

Ist aber kein wirklicher Schutz, so eine Routine aus einem .hex file
rauszunehmen ist eher trivial.

/Ernst

Autor: testerjoe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich China wär ich da auch sehr vorsichtig.
Bleibt also nur selbst programmieren oder vorprogrammierte µC's
besorgen und nach China schicken (lassen)!

Autor: testerjoe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da war der Ernst schneller...

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alternative:

10 cent mehr ausgeben und nicht in China fertigen lassen.

Es gibt zum Beispiel auch in Deutschland Bestückungs/Herstellungsfirmen
...

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, lustig. So langsam bekommen sie alle kalte Füße, dsa Know-How nach
China zu tragen...

Was der Volksmund schon lange wuste, kommt nun so langsam auch in den
Köpfen der "Entscheider" an.

Autor: Eckhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

müssen ja schon ein paar mehr chips sein wenn sich das mit China ohnen
soll.
Da würde ich mal darüber nachdenken die gleich maskenprogrammiert zu
bestellen. Dafür muß man dann natürlich seinem Hersteller vertrauen
können.

Eckhard

Autor: GMB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kenne selber Leute, die an Chinesen verkauft haben, die haben dann
über eine Kalenderfunktion alle "nicht-legalen" Kopien der Software
nach 6 Monaten "abstürzen" lassen, auf einmal kamen die Chinesen dann
"hintenrum", als die nämlich an der TU Aachen angefragt hatten, die TU
Aachen aber auch nur die eine Person kannte, und diese angeschrieben
hatte. Blöderweise war diese eine Person der Entwickler der
Geräte...ich würde den also auch nicht vertrauen... ;-)

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
die Alternative Deutschland kostet wohl einiges mehr als 10 Cent,
leider!!!!
Ich würde das gerne hier machen, aber dann kauft das Zeug keiner mehr.
Mit chinesischen Anbietern arbeite ich schon auf einem anderen Gebiet
zusammen, daher weiss ich wie das läuft. Die bauen das gleiche Teil
dann für jeden der es haben will.
Gruß
Robert

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Die bauen das gleiche Teil dann für jeden der es haben will.

Das ist dann wohl der Preis für billig...billig...billig. Die
Stückzahlen bringens.

Sven

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine gerade im Bereich der Software praktizierte andere Möglichkeit des
Kopierschutzes ist es, die Software so grottenschlecht zu machen, daß
sie keiner haben will ...

Autor: Lokko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja genau... ne grottenschlechte V0.1 drauf und dann n Update anbieten.

Beim Update muss man sich als rechtmäßiger Kunde mit der
"seriennummer" anmelden und bekommt das Update nur, wenn man
verifiziert wurde.

Sind wir da nicht fast bei dem Kopierschutz von Windoof ?!?!

Autor: MicroMann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oder Studenten auf 400,- Euro Basis beschäftigen, die die uC
vorprogrammieren und locken.

Dürfte dann auch bezahlbar bleiben, ist sicher, und hilft denen die es
brauchen können ;-)

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Chinesen nur den Bootloader geben der nur
verschlüsselte/zertifizierte Daten brennen kann. Die fertigen Platinen
dann beim Treibersetup mit der eigentlichen Software updaten.

Gruß Hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso, ein Reverse Engineering des Bootloaders bringt dann nichts mehr
wenn die verschlüsselten Programmdaten beim Setup ihren eigenen
Entschlüsselungsschlüssel mit senden. D.h. im Grunde ist das
eigentliche Program quasi doppelt verschlüsselt. Ein Schlüssel ist im
Bootloader schon enthalten, der andere wird durchs Setup mitgeliefert.

Gruß Hagen

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen:

Dein Idee funktioniert nicht.

Der gemeine Chinese hat den Bootloader. Er kann ein Exemplar vom
fertigen Produkt regulär kaufen/besorgen und dem Treibersetup einen
echten Bootloader vortäuschen und die eigentliche Software abfangen.

Egal, wie oft Du verschlüsselst, egal wie kompliziert, egal wie
raffiniert, dieses Problem lässt sich nicht lösen.

Mit ein wenig logischem Denken wird auch klar, warum.

Die einzige Möglichkeit besteht darin, das Ding nicht in China
programmieren zu lassen.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> oder Studenten auf 400,- Euro Basis beschäftigen, die die uC
> vorprogrammieren und locken.
>
> Dürfte dann auch bezahlbar bleiben, ist sicher, und hilft denen
> die es brauchen können ;-)

Das hälst du für sicher? Einige Studenten nehmen gern mal alle Software
mit, die sie kriegen können. Man weiß ja nie, wozu man's mal brauchen
kann.

@Hagen:

> Der gemeine Chinese hat den Bootloader. Er kann ein Exemplar vom
> fertigen Produkt regulär kaufen/besorgen und dem Treibersetup
> einen echten Bootloader vortäuschen und die eigentliche Software
> abfangen.

Nicht, wenn zusammen mit dem ersten Einspielen der eigentlichen
Firmware ein initialer Schlüssel mitgegeben wird, der im
Mikrocontroller gespeichert wird und für alle weiteren Zugriffe
benötigt wird.
Upgrades der Firmware werden nur in verschlüsselter Form ausgegeben. So
kann der Chinese mit dem Bootloader nix anfangen.

Autor: Stefan Kleinwort (_sk_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und der Endtest wird dann auch gleich in China gemacht?

Wenn die Geräte hier ausgepackt wern müssen, dann kann man auch gleich
die richtige Software hier draufspielen.

Apropos Bootloader:
einfach 2 Bootloader verwenden .. der erste hat keine Verschlüsselung,
sondern erlaubt nur das Einspielen des eigendlichen Bootloaders im
Testfeld über die RS232 (oder was-auch-immer). Der eigendliche
Bootloader hat Verschlüsselung zum Download der Applikationssoftware.

Übrigens teile ich die Meinung von Rufus: in vielen Fällen dienen die
Lock-Bits wohl eher dem Vertuschen von Pfusch-Code.

Gruß, Stefan

Autor: ralf123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich arbeite bei einem Lohnbestücker. Wir programmieren auch für unsere
Kunden Atmel µP's. Wir verwenden von www.e-lab.de die
Programmiergeräte und Software. Diese Software verschlüsselt das
Programm und bietet die Möglichkeit die Anzahl der Programmzyklen zu
begrenzen. Die Programme können so sicher per Email verschickt werden.

Genau das was du suchst...

Autor: Ernst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch wenn das Programm bis in den Programmieradapter hinein
verschlüsselt ist, die Übertragung in den AVR ist es nicht.

Also einfach mitlauschen. Wie die so erhaltenen Daten zu interpretieren
sind steht haarklein im Datenblatt, ist also auch kein Aufwand das
Programm auf diesem Wege zu klauen.

/Ernst

Autor: ralf123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ernst:

Da könntest du Recht haben... die Idee ist mir noch gar nie gekommen.
Allerdings hatte ich auch noch nie das Bedürfniss ein Programm zu
klauen ;-)
Das Programm kann dann aber nur 1:1 übernommen werden, oder? Änderungen
sind ja nicht möglich da man das Programm ja nicht in Klartext
(Assembler) hat, richtig?

Autor: Ernst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Assembler-Quelltext kann man sehr leicht wieder rausfinden, ASM
ersetzt ja praktisch immer nur einen Befehl durch den zugehörigen
Opcode, das ist leicht unzukehren.

Schwieriger wirds dann schon die Struktur wieder rauszuholen, z.B. was
war eine Subfunktion, wo läuft die schleife etc...

Richtig gemein wirds bei Optimiertem C-Code, den Orginalcode kriegt man
nicht mehr, aber kleine Patches/Änderungen sind da auch auf ASM Ebene
möglich.

Lies mal:
http://www.ccc.de/hackabike/index_de.html

Die haben zwar das Binary über ne vergessene Lock-Fuse bekommen, aber
wenn man das erstmal hat ist das vorgehen identisch.

/Ernst

Autor: Manuel B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(entfernt)

Autor: ralf123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ernst:

Interessanter Beitrag - Danke :-)

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Software einfach mitnehmen und Lockbits umgehen sind zwei völlig
verschiedene Dinger.

Und setz mal eine Vertragsstrafe in China durch...

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In de.sci.electronics läuft gerade ein Thread zu dem Thema Fertigung in
China.

Einfach mal ein paar tausend Platinen zusätzlich durchlaufen zu lassen
oder jemanden auf das Knacken eines Controller anzusetzen sind doch
zwei völlig verschiedene Ansätze. Woher soll eine
0815-Fertigungsklitsche denn das Knowhow zum Knacken eines Controllers
haben? Mit einfach Anschließen und Auslesen ist es nicht getan, man
müsste bei zig verschiedenen Typen auf dem Laufenden sein, usw.
Vielleicht kann sich die Firma das einkaufen, aber lohnt sich die ganze
Sache dann noch, oder hätte man die paar kByte Assemblercode nicht
gleich selber schreiben können? Schutz misst man in $, nicht in %.

Autor: 3 Newton (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich habe eine Weile mit Chinesen gearbeitet, die hatten auch
Kontakt in diese Brache. Ich würde einen hier programmierten Controller
verwenden, und zwar einen der neuen von Atmel. Da ist das Auslesen und
knacken deutlich aufwendiger und teurer als bei den alten. Die habe
auch spezielle Security Controller.

Was ist es denn für ein Produkt? Lohnt sich der Aufwand?

3N

Autor: 3 Newton (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achja, die Geschichte um die es damals ging war die, das die Chinesen
den Code geklaut haben, das Programm und gerät etwas verbessert haben
und den Hersteller hier in Dtl. in den Ruin getrieben haben.
Unrechtsbewusstsein dafür existiert übrigens nicht, ich würde in China
NIEMANDEM vertrauen. Es ist ein altes Händlervolk, was gelernt hat wie
man die anderen über den Tisch zieht. Wenn man aber vorsichtig ist wird
es auch kein Reinfall, in fast allen Fällen haben wir mit Unvorsicht zu
solchen Sachen beigetragen. Transrapid etc...

http://de.wikipedia.org/wiki/Strategem


3N

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Egal, wie oft Du verschlüsselst, egal wie kompliziert, egal wie
>>raffiniert, dieses Problem lässt sich nicht lösen.

Alles lässt sich lösen ;)

In diesem konkreten Falle liegt das eigentliche Problem in den
Anforderungen des Fragestellers. So lange er nicht mindestens EINEN
Arbeitsschritt vorsieht in dem ER und nur ER die Kontrolle hat, wird
das niemals funktionieren.

Das mit dem Bootloader würde funktionieren wenn er nur einen
Arbeitschritt vorsieht bei dem seine Firma diesen Bootloader
serialisiert. D.h. der Bootloader im AVR bekommt zuhause in der eigenen
Firma oder in einem Unternehmen seines Vertrauens die Schlüssel
programmiert.

Er könnte also die Chinesen beauftragen die Teile zu produzieren und
den Bootloader aufzuspielen. Eine andere Firma oder seine eigene hat
den Auftrag diesen Bootloader zu serialisieren.

Es gäbe da aber auch noch eine Hardwaremäßige Lösung. Informiere dich
bei Dallas und ihren Kryptochips. Die haben kleine schnuckelige Teile
in MSOP8 / SO8 die geschützte Serialnummern sammt Ver/Entschlüsslung
zur Verfügung stellen.

So ein Ding kommt aufs Board. Wichtig ist nur das man bei Dallas zb.
1000 solcher Chips bestellt die innerhalb EINES ganz eigenen
Serialnummernbereiches liegen. Dallas stellt dann sicher das keine
ANDERE Firma diesen Nummernbereich mehr bekommen kann. Da dieser
Nummernbereich, bzw. durch Dallas vorprogrammierte Schlüssel nur der
eigenen Firma bekannt ist wird einfach die Software damit
verschlüsselt. Der Bootloader im AVR lässt die Software nun durch den
Chip von Dallas vorentschlüsseln. Das funktioniert dann aber nur wenn
der Dallas Chip vorher die Daten authentifiziert hat.

Man kann also nicht mehr den Datenaustausch zwischen AVR und Dalles
Chip abhören, bzw. man kann schon aber das bringt nichts da die
Kommunikation zwischen den Chips selber wieder verschlüsselt wurde. Das
erfolgt dann aber diesesmal live mit einem authentifiziertem Verfahren
und neuen Schlüsseln.

Ergo: die eigene Firma hat einen Arbeitsschritt, nämlich die
Bereitstellung der Authentifikations-Chips an Dallas abgetreten und muß
dieser Firma vertrauen. Die Chinesen kommen zwar auch an solche Chips
ran aber nicht an 1 zu 1 identische Chips mit den gleichen internen
Seriannumern und Schlüsseln. Genauer gesagt: die Chinesen verbauen
diese Chips wissen aber nicht welche Keys darin enthalten sind.

Im Endeffekt ziemlich viel Knowhow und Aufwand der die 10 Cent pro
Platine wohl wieder auffressen wird.

Gruß Hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Davon mal abgesehen: Warum nicht gleich bei Atmel 1000 vorprogrammierte
Chips einkaufen ? Ich dächte ich hätte bei Atmel gelesen das die auch
die Chips vorprogrammieren können.

Gruß Hagen

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Schutz misst man in $, nicht in %."

Ich denke mal, das bringt es auf den Punkt und erübrigt alle weiteren
Diskussionen.

Zuallererst muß man sich Gedanken machen, wie groß ist der Gewinn, den
man mit dem Produkt erzielt.

Und erst dann kann man überhaupt anfangen zu überlegen, welche
Kopiererschwermaßnahmen wirksam genug sein werden.


Oftmals ist es eh sinnvoll, erstmal eine Testsoftware draufzuspielen,
mit der nur Hardwarefehler erkannt werden können und erst danach dann
die eigentliche Funktionssoftware.


Peter

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen:

Klar, man kann es beliebig kompliziert machen.

Nur: Wenn ich selbst noch Hand anlegen muss, um irgendetwas
aufzuspielen, dann kann ich auch gleich das komplette Programm
aufspielen und anschließend den Ausleseschutz aktivieren. Dann brauche
ich mir überhaupt keine Gedanken um Verschlüsselung zu machen.

Autor: 3 Newton (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dock, kann man immer noch knacken. Gibt einige chinesische Firmen die +-
alles knacken.

3N

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rein mal aus Sicht der Kryptographie, da das das ist wovon ich Ahnung
habe.

Die Behauptungen "man kann alles knacken" ist schlichtweg falsch.
Mathematsich gesehen ist dies zwar richtig, aber nur wenn man praktisch
gesehen unendliche Zeit und unendlich große Resourcen zur Verfügung hat.
Das ist aber schon immer ein Problem der Mathematiker gewesen, das sie
infinitiv denken und nicht finitiv wie ein Praktiker.

Praktisch gesehen ist ein sauber konstruiertes kryptographsiches System
von keinem zu knacken. Nicht vdurch Big Brother, von keinem
Ausserirdischen, keinem Menschen und auch keiner technisch denkbaren
Machine. Nicht umsonst ist die Kryptographie und Kryptologie eine
WISSENSCHAFT und keine Hexerei.

Aber stellt sich die Frage was denn ein sauber konstruiertes
kryptographisches System überhaupt ist, bzw. welche wichtigen
Grundbedinungen es erfüllen muß ?

Als allererstes muß im Protokoll der Benutzung des Systemes es immer
einen Zeitpunkt geben der sicherheitskritisch ist. Ganz einfach heist
das: Der Zeitpunkt der Eingabe der PIN am Bankautomaten ist ein
kritischer Zeitpunkt. Wenn dieser NICHT sicher ist dann fällt das
gesammte System insich zusammen.

Und exakt das trifft auch hier zu, der Zeitpunkt an dem es kritisch
wird. Dazu gibts nun 4 Vorschläge:

1.) selber brennen in eigener Firma
2.) durch Atmel die Chips brennen lassen, schon beim Einkauf
3.) den kritischen Zeitpunkt verlagern, also Dallas Chips nehmen und im
Setup brennen
4.) den Chinesen vertrauen

Wogegen ich mich aber immer wieder verwehre sind Aussagen das ALLES
knackbar ist.

1.) stimmt dies einfach nicht
2.) und selbst bei einem absichtlich schlechtem kryptographischen
System würden 99.99999999% der Menschen es immer noch nicht schaffen,
weil einfach die Erfahrungen fehlen
3.) es gehört also immernoch eine gehörige Portion Knowhow dazu um
einerseits ein System sicher zu bekommen oder andererseits selbst ein
schwaches System knacken zu können.

Als ob es mal eben so einfach für den Rest der Welt wäre mal eben 2^64
Schlüssel druchzuprobieren. Bevor man sowas behauptet sollte man sich
erstmal hinsetzen und auf einem Zettel aufschreiben was 2^64 eigentlich
bedeutet ! Und sichere Systeme fangen erst bei 2^128 minimal an sicher
zu werden. Man sollte sich fragen wieviel mehr nun 2^128 im Vergleich
zu 2^64 ist. Einfach mal ausprobieren und auf den Zettel die Zahl 2^64
einfach 2^64 mal draufkritzeln. Ich frage dann mal in 50 Jahren nach
wieweit derjenige gekommen ist.

Jetzt könnte das Argument des Praktiker kommen: Na da knacken wir doch
die Fusebits des AVRs, schleifen das Ding einfach ab und schauen mal
mit der Lue nach ob wie den Schlüssel irgendwo im Silizium da finden
können. Ja technisch machbar mit entsprechendem Geld. Aber das macht
die verschlüsselt gespeicherten Daten immer noch nicht knackbarer. Den
diese bestehen nicht aus Silizium sondern reiner Information.

So, sorry muste mal raus ;)

Gruß Hagen

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Praktisch gesehen ist ein sauber konstruiertes kryptographsiches
> System von keinem zu knacken.

Das ist nicht die Praxis, sondern die Theorie. Das System selbst mag
nicht zu knacken sein, aber oft genug lässt es sich durch Bugs in der
Umsetzung umgehen. Und es gibt bekanntlich keine bugfreie Software.

> Jetzt könnte das Argument des Praktiker kommen: Na da knacken wir
> doch die Fusebits des AVRs, schleifen das Ding einfach ab und
> schauen mal mit der Lue nach ob wie den Schlüssel irgendwo im
> Silizium da finden können. Ja technisch machbar mit entsprechendem
> Geld. Aber das macht die verschlüsselt gespeicherten Daten immer
> noch nicht knackbarer. Den diese bestehen nicht aus Silizium
> sondern reiner Information.

Sobald man die Fusebits geknackt hat, kann man die Informationen doch
einfach wieder auslesen.

Autor: lars (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wozu ein aufwendiger und teurer Kopierschutz?

Wenn es ein Nischenprodukt ist und einen überschaubaren Kundenkreis
anspricht, sollte man sich auf genau die Wüsche dieser Kunden
spezialisieren.
-> Marktanalyse

Ein wirklich effektiver Kopierschutz ist Service. Ein Handbuch mit dem
der Kunde wirklich etwas anfangen kann, währe ein Anfang. Investiere
lieber in die Übersetzung...

Anpassung des Gerätes an die Kundengegebenheiten, neue oder zusätzliche
Produkte sind weitere Punkte. Die kann man dann z. B. immer dann
Präsentieren, wenn die Konkurrenz mit dem Plagiat fertig ist.

Autor: jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das ist nicht die Praxis, sondern die Theorie. Das System selbst mag
> nicht zu knacken sein, aber oft genug lässt es sich durch Bugs in
der
> Umsetzung umgehen. Und es gibt bekanntlich keine bugfreie Software.

Auch dies ein unausrottbares Gerücht. Nur weil Microsoft und Konsorten
denken, dass es niemanden interessiert, ob ihre Software einmal pro
Monat oder einmal pro Stunde abstürzt, heißt dies nicht, dass dies für
alle gilt. (Und obwohl ich es selber nutze gilt dies uneingeschränkt
auch für Linux)

Man kann es einerseits mit sauberer Programmierung versuchen, z.B.
NASA, die trotz einiger Abstürze eine extrem geringe Fehlerzahl in
ihrer Software hat, oder wenn man wirklich sicher gehen will:
Formale Verifikation:
http://en.wikipedia.org/wiki/Program_verification

Und für den praktischen Beweis, dass es bugfreie Software gibt:
"Hello World" ansehen.
Dies ist wirklich ernst gemeint! Genau auf diese Art und Weise zeigt
man die Korrektheit von großen Programmen und so werden auch Dinge in
der Mathematik bewiesen.
Man beweist die Korrektheit kleiner Unterprogramme (bzw. in der
Mathematik Hilfssätze und Grundlagen) und arbeitet sich immer weiter
vor, wenn ein paar Leute unabhängig voneinander sich die Sache
angeguckt haben, dann kann man davon ausgehen das es korrekt ist.
Fehler können sich natürlich immer mal wieder einschleichen, aber
irgendwann ist halt auch der letzte gefunden, weswegen Beweise
wichtiger Sätze in der Mathematik heute fehlerfrei sind.

Da dies aber nicht billig zu erreichen ist, verzichtet man bei der
Programmentwicklung darauf, dies heißt aber nicht, dass es keine
bugfreie Software gibt

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Man kann es einerseits mit sauberer Programmierung versuchen, z.B.
> NASA, die trotz einiger Abstürze eine extrem geringe Fehlerzahl in
> ihrer Software hat,

Das habe ich nicht bestritten. Fehler gibt's aber trotzdem, wie du ja
selbst schreibst. Überleg mal, was die für ein Budget haben und was für
Leute daran arbeiten. Wenn die es nicht fehlerfrei bekommen, wer dann?

> oder wenn man wirklich sicher gehen will:

Und du glaubst, die NASA will nicht "wirklich sicher gehen", wenn ein
100M$-Projekt ins All geschossen wird?

> Formale Verifikation:
> http://en.wikipedia.org/wiki/Program_verification

Diese ist für alles außer Trivialprogrammen mit extremem Aufwand
verbunden.

> Und für den praktischen Beweis, dass es bugfreie Software gibt:
> "Hello World" ansehen.
> Dies ist wirklich ernst gemeint!

Ok, ich schränke ein: Es gibt keine fehlerfreien Programme, die etwas
sinnvolles tun.

> Man beweist die Korrektheit kleiner Unterprogramme (bzw. in der
> Mathematik Hilfssätze und Grundlagen) und arbeitet sich immer
> weiter vor,

Das wird schwierig, das für alle Teile und auch für deren Interaktion
miteinander zu beweisen.

> wenn ein paar Leute unabhängig voneinander sich die
> Sache angeguckt haben, dann kann man davon ausgehen das es korrekt
> ist.

Das ist aber keine formale Verifikation. Das ist Code-Review.

> Fehler können sich natürlich immer mal wieder einschleichen, aber
> irgendwann ist halt auch der letzte gefunden, weswegen Beweise
> wichtiger Sätze in der Mathematik heute fehlerfrei sind.

Es gibt aber einen Unterschied zwischen einem formalen Beweis und einem
Test. Beweise mal, daß eine komplexe Software in absolut jeder
denkbaren und undenkbaren Situation immer korrekt funktioniert. Das
Ausprobieren mit jeder Menge Testdaten ist kein formaler Beweis.

Autor: Ernst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun, jedes Programm enthält mindestens einen Fehler, und lässt sich um
mindestens eine Anweisung kürzen.

Daraus beweisen wir mittels Induktion:

Jedes Programm lässt sich auf eine Anweisung reduzieren, die nicht
funktioniert.

/Ernst

Autor: Ernst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen:
"Bevor man sowas behauptet sollte man sich
erstmal hinsetzen und auf einem Zettel aufschreiben was 2^64 eigentlich
bedeutet ! Und sichere Systeme fangen erst bei 2^128 minimal an sicher
zu werden. Man sollte sich fragen wieviel mehr nun 2^128 im Vergleich
zu 2^64 ist. Einfach mal ausprobieren und auf den Zettel die Zahl 2^64
einfach 2^64 mal draufkritzeln. Ich frage dann mal in 50 Jahren nach
wieweit derjenige gekommen ist."

Fertig ;)

2^64 == 18446744073709551616
2^128 == 340282366920938463463374607431768211456

2^128 / 2^64 == 18446744073709551616 (wer hätts gedacht? :))

Ist jetzt auch nicht sooo schwer die auf Papier abzuschreiben, nur das
händische Ausrechnen....

Ansonsten hast du natürlich recht mit deinen
Kryptographie-Ausführungen, solang wir noch keinen 128Bit
Quantencomputer haben...

/Ernst

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein wichtiges Kriterium für "Sicherheit" in der Kryptographie ist die
Beweisbarkeit das es sicher sein muß. Dies gilt nicht nur auf die
Algorithmen die angewendet werden sondern eben auch für deren
Implementierungen. Gute Algorithmen haben immer auch Sub-Algorithmen
enthalten die die erzeugten Resultate verifizierbar machen. Das ist
also so als ob man eine Software schreibt die an vielen Stellen die
eigenen Resultate auf Plausibilität überprüfen kann.

Es bleibt immer noch ein Restrisiko, aber auf Grund der eh schon hohen
Wahrscheinlichkeitsschranken die in der Kryptrographie üblich sind
werden solche Fehler mit < 1/2^128 Wahrscheinlichkeit auftreten, also
defacto niemals.

Und es kommt ein Vorteil hinzu. Die meisten kryptographischen Verfahren
reagieren bei einem Bit-Fehler wie eine "Ales oder Nichts"
Verschlüsselung. D.h. sollte ein Fehler auftreten so ist die Sicherheit
fast nie gefährdet sondern nur die Datenintegrität beeinträchtigt.

Aus meinen Erfahrungen heraus, mit wirklich sicheren Systemen, kann ich
meiner Meinung nach ernsthaft behaupten das gute Systeme niemals
knackbar sein werden solange
a) es keine neuen und umwälzenden mathematischen Erkenntnisse
vorliegen
b) gerade solche Systeme strengsten Wartungsmaßnahmen unterliegen die
gerade auf die Erkennung möglicher Ausfälle hin optimiert sind
c) ein Knowhow und Kapital in 6-8 stelliger Höhe nötig wird

Der Aberglaube der meisten Menschen das man alles knacken kann ist
einerseits durch die wahnsinnige Überwertung in den Medien von
angeblichen Hackeraktivitäten zu suchen. Das fördert die Basis für die
gewollten Entscheidungen der Politiker die Freiheiten einzuschränken,
und mehr nicht !

Die Wissenschaften beweisen eindeutig was anderes.

Gruß Hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Enrst:

sorry du hast mich wohl falsch verstanden, du sollst

18446744073709551616 mal 18446744073709551616 auf einen Zettel
schreiben.

Bisher hast du nur EINMAL auf dem Zettel 18446744073709551616 stehen.
Erst wenn du es 18446744073709551616 mal egschrieben hast hast du 2^62
erreicht. Danach kannst du anfangen 18446744073709551616  solcher
Zettelhaufen vollzukritzeln und hast dann den Wertebereich von 2^128
von heutigen Schlüsseln erreicht.

Gruß Hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ansonsten hast du natürlich recht mit deinen
>>Kryptographie-Ausführungen, solang wir noch keinen 128Bit
>>Quantencomputer haben...

Irrelevant!

Wenn der Aufwand der Ver-schlüsselung 1 beträgt und man aber
mathematisch beweisen kann das der minimalste Aufwand was zu
ent-schlüsseln > 1 ist dann ist die Kryptographie in JEDEM Falle
sicher. Es hängt dann alles nur noch davon ab das man die Schlüssel
ausreichend groß auswählt.

Als wenn selbst ein Rechner mit Zeit 1 entschlüsseln könnte so würde
man nur < 1, zb. 0.5 der Rechenzeit benötigen um zu verschlüsseln.

Gruß Hagen

Autor: jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Und du glaubst, die NASA will nicht "wirklich sicher gehen", wenn
> ein 100M$-Projekt ins All geschossen wird?

Die NASA hat auch ein Budget und es sind z.B. Fehler passiert wie:
Wir haben hier ein Programm für Rakete X, lasst es uns einfach für
Rakete Y nehmen, uups, die verhalten sich ja ganz anders ... BUMM.

>> Formale Verifikation:

>> http://en.wikipedia.org/wiki/Program_verification

> Diese ist für alles außer Trivialprogrammen mit extremem Aufwand
> verbunden.

Zugegebenermaßen ist es noch relativ schwierig, ABER es wurde auch noch
nicht sehr viel auf diesem Gebiet gearbeitet und Fortschritt braucht
Zeit. Am Anfang waren ICs mit Integrationsdichten wie sie heute
erreicht werden unvorstellbar.
Es gibt deswegen auch Programme die mit ein bisschen Hilfe einen Teil
der Verifikation automatisch erledigen (und die auch ihrerseits
verifiziert wurden).
Es gibt übrigens Aussagen in der Mathematik (merkt man, dass ich
Mathematiker bin? ;) ) die nur mit Hilfe von Programmen bewiesen
wurden, z.B. der Vier-Farben-Satz
http://de.wikipedia.org/wiki/Vier-Farben-Satz


> Ok, ich schränke ein: Es gibt keine fehlerfreien Programme, die
> etwas sinnvolles tun.

Ein Satz der uneingeschränkt gültig ist, weil man einfach "sinnvoll"
so definiert wie man will.
Nimm zum Beispiel einen einfachen Taschenrechner der Integer-Zahlen
multipliziert, addiert und subtrahiert. Wenn man den Zahlenbereich
einschränkt ist dies schon ein "sinnvolles" Programm und sehr einfach
komplett fehlerfrei zu kriegen


>> wenn ein paar Leute unabhängig voneinander sich die
>> Sache angeguckt haben, dann kann man davon ausgehen das es korrekt
>> ist.

> Das ist aber keine formale Verifikation. Das ist Code-Review.

Da hab ich mich wohl missverständlich ausgedrückt, ich meinte:
Ein paar Leute sollten diese formale Verifikation machen, denn auch in
Beweisen können Fehler auftreten, nur das diese eben bei sauberen und
detaillierten Beweisen sehr unwahrscheinlich sind.

Ein Code-Review heißt ja einfach nur, dass sich jemand mal den
Sourcecode anguckt, das ist im Allgemeinen vielleicht gut ein paar
einzelne Fehler zu finden, aber selten um wirkliche Fehlerfreiheit
herzustellen.



> Es gibt aber einen Unterschied zwischen einem formalen Beweis und
> einem Test. Beweise mal, daß eine komplexe Software in absolut
> jeder_ denkbaren und undenkbaren Situation _immer korrekt
> funktioniert. Das Ausprobieren mit jeder Menge Testdaten ist kein
> formaler Beweis.

Deswegen gibt es ja gerade die formale Verifikation, dafür muss man ja
nicht alles durchrechnen, sondern man teilt die möglichen Zustände auf
und zeigt separat, dass das Programm für die Klasse von Eingangsdaten
korrekt ist.
Zum Beispiel zeigt ja vollständige Induktion die Korrektheit einer
Aussage für unendlich viele Eingangsdaten, obwohl man ja prinzipiell
nur endlich viele überprüfen (testen) kann (bzw. könnte, dafür hat man
es ja bewiesen).

Ich kann natürlich schlecht ein Beispiel für eine vollständig korrekte
Software geben, weil es so etwas momentan nicht gibt, dies liegt zum
Teil auch daran, dass immer noch Dinge wie C++ benutzt werden, die
genügend Seiteneffekte haben um alleine damit Bücher zu füllen. Das
kaum jemand Memory Management wirklich beherrscht sieht man ja an der
Menge an Buffer Overflows, aber dies liegt eben nicht an der
prinzipiellen Unmöglichkeit.

Vielleicht entwickelt sich ja Coyotos brauchbar:
http://www.coyotos.org/

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich frage mich die ganze Zeit, was Robert entwickelt hat, dass sich
diese Diskussion über "böse" Chinesen (ein Kumpel von mir ist ein
Chinese...konnte bei ihm nur bösen Durst nach Bier etc feststellen)
und Kryptographien entwickelt hat.
Hat er sich inzwischen eigentlich wieder gemeldet?

Was ich eigentlcih viel interessanter finde: Er lässt in China
fertigen, weil es dort billiger ist, hat aber Angst, dass seine
Erfiindung da "die Runde macht". Wenn ihm etwas daran liegt, sein
geistiges Eigentum zu behalten, sollte es es ihm Wert sein, die
"paar" Kröten mehr in eine deutsche (von mir aus auch europäische)
Firma zu investieren, denen er eher auf die Füsse steigen kann. Das ist
diese "Aldi-Mentalität", dass alles, was billig ist, und genauso
aussieht, wie die teueren Sachen, mindestens genauso gut, wenn nicht
sogar besser ist. Billiges bezahlt man immer doppelt.

Autor: Ernst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nicht irrelevant.
Mit einem Quantencomputer mit der entsprechenden Anzahl QBits kann ich
jedes Problem in P in Konstanter Zeit Lösen.

Du verschüsselst mit 1024 Bit, ich probiere alle 2^1024 möglichen
Schlüssel GLEICHZEITIG aus, und nehme den der passt.

Ein Quantencomputer ist also sowas wie die "Unendliche Zahl Affen an
unendlich vielen Schreibmaschinen". Einer von denen wird zufällig
deinen geheimen Schlüssel erraten.

/Ernst

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry Rahul noch ein Kommentar von mir:

Falls unser Universum wieder implodieren sollte dann beträgt die
Lebenszeit des Universum ca. 2^61 Sekunden. (Bruce Schneier
"Angewandte Kryptographie").

Wenn Ernst pro Sekunde einmal 18446744073709551616 auf einen Zettel
schreibt von 2^64 mal dann wird er mit absoluter Sicherheit den Urknall
des nächsten Universum miterleben müssen.

So, nur mal so was 2^64 eigentlich für eine Zahl ist.

Gruß Hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Doch irrelevant:

den ich setze unendlich viele Affen daran einen unendlich großen
Schlüssel zu benutzen. Wenn der Aufwand der verschlüsselung 1 beträgt
und die der Einschlüsselung > 1 dann benötige ich also unendlich * 1
und du unendlich + unendlich * x mal länger.

Pure Theorie, in der Praxis ist heutige Kryptographie sehr wohl
sicher.

Gruß Hagen

Autor: Ernst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hagen, dummerweise hilft dir ein unendlich langer Schlüssel nichts, um
einen endlich langen Klartext zu verschüsseln. Bei gleicher Bitzahl ist
Schluss, womit wir beim (auch theoretisch beweisbar) sicheren OTP
angekommen wären. (Die lustigen Missgeschicke der Russen beim
OTP-Verschlüsseln lassen wir mal außen vor).

Ein OTP ließe sich zwar auch mit nem Quantencomputer in konstanter Zeit
entschlüsseln, nur bringt mir das nichts weil ich keine Möglichkeit hab
rauszufinden, welcher der vielen verschiedenen möglichen Klartexte nun
der richtige ist.

/Ernst

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen:
Und das geht alles mit einem AVR?
Was haben Affen damit zutun?
Wie gut, dass ich nie Interesse hatte, Mathematik zu studieren.
Für mich bedeutet Mathematik einerseits "Rechnen"/Werkzeug für
Ingenieure, andererseits aber auch "ein Kapitel in meinem Leben, dass
man als Erfahrung abhaken möchte".

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sind nicht die meißten Systeme durch Spionage und Verrat genackt
worden?

...

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, und noch viel mehr durch die Dummheit der Benutzer,siehe Enigma.

Die wenigsten sind "geknackt" worden auf Grund neuerer mathematischer
Erkenntnisse oder technologischer Meisterleistungen. Der letzte große
Schub in der Kryptologie war die Entdeckung der differientiellen
Kryptoanalyse vor nunmehr 30 Jahren. Mit ihrer Hilfe wurde der letzte
mathematische "Rest" beim Knacken von Enigma erledigt. Seitdem gelten
Streamcipher nicht mehr als so sicher.

Es ist vom finanziellen Aufwand einfacher
a) einen Verräter zu bezahlen
b) denjenigen dessen Daten man haben möchte zu kaufen
c) denjenigen dessen Daten man haben möchte zu entführen, dessen
Familie zu foltern etc.pp.

Gruß Hagen

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
könnte interessant sein:
http://www.cl.cam.ac.uk/~sps32/mcu_lock.html

Bezüglich der Möglichkeit dass ein Student die Chips brennt und die
Firmware behält: Ich denke der Schaden in diesem Fall läge bei nahe
null da ihm die Firmware ohne Schaltplan/Produktionsstätten kaum was
bringen wird. Er darf den nur nicht der chinesischen Fertigungsfirma
zukommen lassen.

Bei der ganzen Kryptographie: Da ja anscheinend ein AVR zum Einsatz
kommen soll, habt ihr schon mal berücksichtig dass ein Bootloader doch
nur sehr begrenzt Platz für derartige Routinen bietet?

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn er auch noch Sozialpädagoik-Studenten anlernt, dann ist die
Wahrscheinlichkeit, dass die damit überhaupt etwas anfangen können
minimal...Somit auch wenig Interesse daran haben, den Code
mitzunehmen...

Autor: Olaf_K (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>habt ihr schon mal berücksichtig dass ein Bootloader doch
nur sehr begrenzt Platz für derartige Routinen bietet

Das geht wirklich, siehe AVR230, AVR231 (3DES oder AES-Bootloader mit
max. 2K Speicherverbrauch).

MfG Olaf

Autor: Bastian S (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mmh, also als studierter Informatiker muss ich auch mal meinen Senf dazu
geben:

1. Es ist möglich, bugfreie Software herzustellen.
2. Es gibt bugfreie Software. Auch welche, die einen wirklichen Nutzen
ergibt.
3. Es ist PRAKTISCH NICHT IMMER möglich dies auch zu beweisen.
4. Und bevor hier wieder diskutiert wird: Punkt 1 ist nicht bewiesen,
sondern ein sog. Axiom. (Axiom (v. griech.: tà tôn progónon axiómata =
als wahr angenommener Grundsatz) nennt man eine Aussage, die
grundlegend ist und deshalb nicht innerhalb ihres Systems begründet
werden kann bzw. muss.).


q.e.d. (quod erat demonstrandum)

so long
8astian

PS: Noch was zum diskutieren:
Ich meine, ich hätte mal folgendes gelesen:

Wenn es nicht möglich wäre, bugfreie Software herzustellen, wäre es
auch nicht möglich, verbugte Software herzustellen (auf Grund dessen,
dass man Bugs nicht definieren könnte), also dürfte es keine Software
geben.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was nützt mir bugfreie Software, wenn die Hardware fehlerhaft ist.
Ich glaube kaum, dass die Hersteller jeden einzelnen Controller 100%
testen.

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wegen bugfreier Software:

Theoretisch lässt sich Software ohne Bugs wunderbar herstellen.
Entweder durch mathematische Methoden (Beweis etc.) oder durch
entsprechende organisatorischen Methoden (Strenge
Schnittstellendefinitionen) etc.

Aber leider haben diese Ansätze alle ein entscheidendes Problem:


Punkt 1.) Faktor "Mensch".

Wenn eine Software nur ausreichend groß ist, ist die Wahrscheinlichkeit
auch entsprechend hoch, dass dementsprechend viele Bugs enthalten sind.

Ein Mensch kann problemlos einen mathematischen Beweis oder einen
Algorithmus auf Papier schreiben, der ohne irgendeinen Zweifel korrekt
ist.

Danach fangen die Probleme aber schon an: Wenn ein Mensch nun einen
Algorithmus ausführen muss, sei es manuell mit Papier und Bleistift,
oder automatisch in dem er diesen abstrakten Algorithmus in eine
Maschinensprache übersetzt, kann dieser Mensch Fehler machen.

Die Wahrscheinlichkeit, dass ein Mensch Fehler macht, steigt mit der zu
bewältigenden Aufgabe. D.h. wenn die zu lösenden Aufgabe nur groß genug,
ist die Wahrscheinlichkeit dass der Mensch Fehler macht, sehr hoch.

Ergo: Menschen können Fehler machen, und werden Fehler machen.


Punkt 2.) Bug ist nicht gleich Bug.

Man sollte zusätzlich auch bedenken, dass bei den Bugs ein
Evolutionsdruck herscht und nur die fiesen, hinterhältigen und schwer
zu finden Bugs überleben.

Denn alle trivialen oder großen Bugs werden während der
Softwareentwicklung oder im Betrieb sofort oder schnell gefunden. Diese
Bugs haben kaum eine Chance zu überleben.

Die Bugs die allerdings nur in ganz bestimmten Situationen auftreten,
werden in der Regel kaum oder nie entdeckt, da eben die relevanten
Situationen, bzw. Zustände, im Programm nur sehr selten oder in der
momentanen Software-Benutzungs-Praxis oft nie auftreten.

Ergo: Software enthält mit relativ geringer Wahrscheinlichkeit grobe
Schnitzer die sofort zu Tage treten, aber dafür mit hoher
Wahrscheinlichkeit Fehler die nur in bestimmten Situationen auftreten.


Punkt 3.) Reale Welt

Softwareentwicklung findet heute praktisch nie im Vakuum statt. Jeder
Programm muss sich auf Compiler, Bibliotheken, Betriebssystem und
Hardware verlassen, die alle mit hoher Wahrscheinlichkeit Fehler
enthalten.

Das heisst: Selbst wenn das eigentliche Programm fehlerfrei ist, kann
es in Verbindung mit Bibliotheken, Betriebssystem und Hardware dennoch
fehlerhafte Ergebnisse produzieren.


Fazit der 3 Punkte:

In der Praxis ist es nahezu unmöglich, fehlerfreie Software zu
schreiben. Die Wahrscheinlichkeit, dass irgendwo ein schwer zu
entdeckender Bug lauert, ist sehr hoch. Dieser Bug kann auch erst durch
falsches Funktionieren von Betriebssystem oder Hardware verursacht
werden.

Aber die Erkenntnis bleibt: Software enthält Fehler.

Als logische Konsequenz ergibt sich darauf:

Wenn man die Fehlerfreiheit in der Praxis, in der realen Welt nicht
garantieren kann, muss man mit Fehlern leben. D.h. man muss für den
Fehlerfall planen und ein Fehlermanagement betreiben.

Und genau das wird ja gemacht. Betriebssystem existieren, um
verschiedene Programme gegeneinander abzuschotten. Laufzeitumgebungen
und Programmiersprachen werden so gestaltet, um Fehler effektiv
erkennen zu können und darauf reagieren zu können. Code wird
wiederverwendet, um die Wahrscheinlichkeit für neue Bugs zu minimieren,
usw.

Nichts desto trotz sollte das Ziel jeder Softwareentwicklung sein,
möglichst absolut fehlerfreien Code zu schreiben.

Doch wer daraus ableitet, dass sein Programm niemals Fehler enthalten
könne, ist ein Narr.

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
dass Alles irgendwie zu knacken ist das ist schon logisch.
Es sollte eben nur ein Schutz sein der nicht ganz einfach zu umgehen
ist in dem man eine Kopie macht und dann sämtlich Unterlagen hat um die
Produktion weiter zu machen.
Es ist schon ein Problem wenn man alle wichtigen Unterlagen an eine
Firma weitergibt. Besser wäre es die Pläne für die Hardware an eine
Firma zu geben und die Softwar bei einer anderen Firma erledigen zu
lassen. So hat keine Firma alle Unterlagen.

Das ist wohl die beste Lösung.

Gruß
Robert

Autor: Arno H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du nicht mindestens genauso viel Gehirnarbeit in das eigentliche
Produkt gesteckt hast wie in den Kopierschutz, ist es das eh nicht
wert.
Wenn irgendwelche Probleme mit dem Kopierschutz dem Komfort bei der
Bedienung / Benutzung hinderlich sind, wirst Du auch nicht allzuviel
davon verkaufen.
Da sollte schon eine vernünftiges Verhältnis vorhanden sein. Wenn man
sich so auf den Kopierschutz versteift, leidet meistens das Produkt
darunter und wird minderwertig (wenn es das nicht schon ist).
Eine weitere Absicht, die ich nicht unterstelle, ist das man verhindern
möchte, dass jemand anders herausfindet, dass man selber alles nur
geklaut hat.
Arno

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.