Hallo miteinander, ich muss einem Kunden einen Hardwareprototypen zuschicken und ihm dann weitere Firmwarestände zukommen lassen. Ich möchte natürlich nicht, dass der Kunde das Hexfile in die Finger bekommt. Einen Bootloader zu integrieren (Microchip DSpic) wäre mir für die einmalige Aktion jetzt zu aufwändig. Ich überlege ihm ein Programmiertool (ICD4) mitzuschicken und per Teamviewer das Ganze remote auf seinem Rechner zu erledigen. Mit der Teamviewer-Dropboxanbindung könnte ich verhindern, dass er an das File kommt. Hat jemand eine bessere Idee? Es darf schon was Kosten, aber muss nicht gleich eine 1-jährige Teamviewer-Lizenz sein... Gruß, Alexander
Bau einen verschlüsselten Bootloader und schick ihm ein Hex, dessen Inhalt nur der Chip lesen kann. Ein ICD4 ist nur leicht überzogen, ein PicKit o.ä. sollte es vieleicht auch tun, aber TV gewerblich kostet derbe Geld. Achja: weitere Infos über Prozessor und Hardware sind unerwünscht. Nachher ist noch eine Speichermöglichkeit vorhanden/möglich, die das alles total einfach macht.
Wenn der Kunde es wirklich will, und sich damit auskennt, wird er in der Lage sein, die Daten bei der Teamviewer-Lösung abzufangen. Eigentlich bei jeder Lösung, die über seinen Rechner läuft, bzw., auf die er physischen Zugriff hat. Auch würde ich, wenn ich Kunde wäre, mich mit Händen und Füßen dagegen wehren, dass Teamviewer auch nur auf meine Maschine gelangt. Aber soll ja durchaus auch Leute mit anderem Sicherheitsverständnis geben.
Jack V. schrieb: > Wenn der Kunde es wirklich will, und sich damit auskennt, wird er in der > Lage sein, die Daten bei der Teamviewer-Lösung abzufangen. Das ist bei uns z.b. so. Wir haben einen isolierten Rechner bei dem wir alle Datenverbindungen, die wir nicht aufbrechen können, erst einmal blockieren. Sollte der TO aus einer Dropbox dann eine HEX-Laden, so geschieht das schonmal intern unverschlüsselt und gespiegelt. So haben wir schon öfters die aktuelle Firmware eines Steuerungsrechners bekommen die wir dann auf andere baugleiche Maschinen verteilt haben. Dabei ging es uns nicht um das "HEX" sondern um die Arbeitszeit der Firma, weil diese uns das Hex (eigentlich war es .bin) nicht selbst auf die Maschinen aufspielen lassen wollte. Nach der ersten Maschine hatten wir das und unser Azubi in der IT hat das dann im Parallelbetrieb durchgeführt.
Hm, wo ist den das Problem das der Kunde das .hex File bekommt? Entweder es gibt einen Vertrag, dann bekommt der Kunde eh das fertige .hex File. Wenn der Kunde aber nur mal testen will, würde ich mir das ganz genau überlegen ob ich mir hier soviel Mühe mache, weil hier meistens eh nix dabei rauskommt. mfg Gast
_Gast schrieb: > Entweder es gibt einen Vertrag, dann bekommt der Kunde eh das fertige > .hex File. Wenn die Hex für eine bestehende Steuerung für den Kunden angepasst wird, bekommt der Kunde trotz Vertrag kein Hex. Allerhöchstens einen Schaltplan aber kein Layout.
Gibt es einen Kanal auf dem FW Updates regulär auf das Gerät kommen? Dann wäre das der logische Weg. In diesem Fall würde ich das Hexfile mit einem Key verschlüsseln. Dieser Key existiert nur bei dir und in dem Teil der Firmware die den Update Kanal bedient. Natürlich muss ein Auslesen der Firmware entsprechend gesperrt sein. Wie der Key genau aussieht bleibt einzig deiner Fantasie überlassen. Ich habe sowas beispielsweise schon mit Kombinationen aus chipserial no und Firmenname realisiert. Relativ einfach zu implementieren ist z.b TEA in Verbindung mit einem 128 Bit Schlüssel. Auf Wiki ist das ganz gut erklärt. Es lohnt sich übrigens da etwas Zeit zu investieren... Sowas braucht man immer wieder. Thomas
Die Standardlösung ist wohl der entschlüsselnde Bootloader. Wenn der Kunde ohnehin nicht viel Energie in die Anylyse stecken würde und es ehr um Obfuscation statt Verschlüsselung geht kannst du ihm ggf auch ein Firmwareupdatetool bauen das entschlüsselt und hochlädt.
Alex4WAG schrieb: > Hat jemand eine bessere Idee? Während man mit der Bahn fährt kann man wunderbar arbeiten :-)
Raph schrieb: > bekommt der Kunde trotz Vertrag kein Hex. Allerhöchstens einen > Schaltplan aber kein Layout. 1.Wenn ich Kunde wäre, würde ich solchen Müll nicht kaufen. Wenn dieser Lieferant keine Lust mehr hat oder pleite ist kann ich meine Maschine dann wegwerfen? 2.Remote habe ich schon viel erfolgreich erledigt. Es ging aber manchmal auch was schief. Wenn Du dann persönlich nach Omsk in die Fußlappenfabrik fahren mußt, um einen Bootlader zu reparieren, könnte das sehr lange dauern! Man sollte deshalb einen Bootlader "mit Rettungsboot" konstruieren wenn man alles aus der Ferne lösen muß!
Wenn Euer Kunde nur etwas Ahnung hat und nicht gerne mit offener Hose herum läuft, so wird er wohl zu einer Remote Verbindung "nein" sagen. Ich auch! Übrigens: Hast Du Dir mal angesehen, was man mit einem Hex-File anfangen kann? Für den Aufwand hieraus etwas zu machen, bei dem man mehr als ein Byte ändern kann, kann man eine Neuerstellung des Programms ins Auge fassen. Noch ein Übrigens: Viele Poster hier im Forum haben Angst um "Ihre" Schöpfungen. Sind die wirklich so einmalig oder ist der Faktor "Einbildung" übermächtig?
:
Bearbeitet durch User
Danke für die vielen Antworten. Ich werde wohl doch einen verschlüsselten Bootloader bauen müssen. Es geht hier um Produktentwicklung, die ich normalerweise im Haus in Ruhe machen kann. In diesem Fall geht das leider nicht. Wenn der Bootloader crasht, ist das erstmal kein Problem: meine Baugruppe raus und alles ist wieder okay. Der Kunde bezahlt nachher auch nur das fertige Produkt, nicht die Entwicklung. Gruß, Alexander
oszi40 schrieb: > Raph schrieb: >> bekommt der Kunde trotz Vertrag kein Hex. Allerhöchstens einen >> Schaltplan aber kein Layout. > > 1.Wenn ich Kunde wäre, würde ich solchen Müll nicht kaufen. Wenn dieser > Lieferant keine Lust mehr hat oder pleite ist kann ich meine Maschine > dann wegwerfen? Eine verständliche Einstellung. In der Realität wird man dann aber schon bei der grundlegenden IT-Infrastruktur hohe Aufwände haben, um sich diesem Ziel zu nähern. In der betrieblichen Realität, wo Zeit Geld ist, wird man hier sehr oft Abstriche machen. Und wenn man mal eine Maschine nach Jahren wegwerfen muss, dann sollte man das auch überleben.
Jan H. schrieb: > Und wenn man mal eine Maschine > nach Jahren wegwerfen muss, dann sollte man das auch überleben. Einen kaputten 17er Schlüssel kann man wegwerfen weil man schnell Ersatz hat. Bei einer speziellen Maschine für 100k€ oder stündlichen Produktionsausfall für xx Leute sieht die Welt schon anders aus! Alex4WAG schrieb: > Ich werde wohl doch einen verschlüsselten Bootloader bauen müssen. Dann mache möglichst 2 Teile. Teil 1. Hinweis auf Version und Teil 2 den Rest. Das hat den Vorteil daß der Kunde oder die Putzfrau Dir Hinweise geben kann ob schon was gestartet ist und "nur die Version 4717.1 hängt".
> werde wohl doch einen verschlüsselten Bootloader bauen müssen.
Muß man nicht unbedingt, wenn man die Firma+Maschinennummer einbrennt
und dann irgendwie prüft.
oszi40 schrieb: > Einen kaputten 17er Schlüssel kann man wegwerfen weil man schnell Ersatz > hat. Bei einer speziellen Maschine für 100k€ oder stündlichen > Produktionsausfall für xx Leute sieht die Welt schon anders aus! Ein verschickbarer Prototyp ist eher der 17er-Schlüssel als die 100k€-Maschine. Ich kenne aber auch Maschinen, wo du an die 100k noch drei Nullen und ein bisschen was anhängen kannst. Auch dort gibt's nicht alle Sourcen dazu, sind schließlich genug Betriebsgeheimnisse (OK, viel dann ist jetzt nicht nobelpreisverdächtig) drin.
Jan H. schrieb: > Auch dort gibt's nicht > alle Sourcen dazu, sind schließlich genug Betriebsgeheimnisse Kann ich verstehen aus Herstellersicht. Habe aber leider schon einige Firmen erlebt, die es heute nicht mehr gibt. Die Lage verschlimmert sich sowieso durch immer kurzlebigere Software und Zertifikatslaufzeiten. Soll man deswegen alle Maschinen wegwerfen??? Wegen ein paar Wattestäbchen machen die Grünen einen Aufstand, bei teuren Maschinen nicht?
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.