Hey zusammen, hab ein mehr oder weniger großes Problem :p Ich mach zurzeit ein duales Studium sprich Studium + Ausbildung und bin im 3.Lehrjahr sitze also an meiner Bachelorarbeit. Mein Chef hat mir als Thema vorgeschlagen, für die Firma ein eigenes Donglesystem zu entwickeln. Als Grundlage für die Software-Entwicklung würde ein MSP430f5529 dienen. Da ich jedoch noch nie so Hardwarenah programmiert habe würde ich gern wissen was ich mir dafür aneignen muss. (Ich besitze Grundlegende Kenntnisse in C/C++) Habe kürzlich ein Buch über Mikrocontroller überflogen und erkannt, dass es nicht gerade simpel ist. Könnte mir eventuell jemand eine Übersicht geben was ich zu tun bzw. anzueignen habe? Das ist echt komplettes Neuland für mich (Bitte keine Kommentare wie: Lass es sein, das ist zu viel) Wäre sehr, sehr dankbar!!
Daniel Terßen schrieb: > Da ich jedoch noch nie so Hardwarenah programmiert habe würde ich gern > wissen was ich mir dafür aneignen muss. (Ich besitze Grundlegende > Kenntnisse in C/C++) Du beantwortest dir ja deine Frage mehr oder weniger ohnehin selbst. Du brauchst grundelgende Kenntnisse in hardwarenaher Programmierung mit dem MSP. > Habe kürzlich ein Buch über Mikrocontroller überflogen und erkannt, dass > es nicht gerade simpel ist. Ohne Schweiß kein Preis. > Könnte mir eventuell jemand eine Übersicht geben was ich zu tun bzw. > anzueignen habe? Erst mal musst du den MSP grundsätzlich programmieren können. Als Zwischeneinlage und um ein wenig Sicherheit zu erlangen, würde ich mal ein wenig Zeit mit ein paar LED verbringen und die zum Leuchten, Blinken, etc. bringen. Wenn du dann ein wenig Sicherheit hast, musst du ergründen wie die USB Kommunikation mit einer PC-seitigen DLL funktioniert und da Datenübertragung hinkriegen. Da kommt dir jetzt deine Erfahrung mit den LED zu gute, denn die sind dein Ausgabemedium, mit dem du kontrollieren kannst, ob der µC auch das verstanden hat, was der PC haben wollte :-) Tja. Wenn das dann steht, dann musst du dir überlegen, wie du deinen Dongle-Schutz realisieren willst. Um dann zum Schluss zu kommen, dass man das ganze auch wegwerfen und kaufen kann. Ist a) billiger b) zuverlässiger und c) funktioniert dann auch wirklich als Dongle, der von Gretchen Müller nicht so einfach ausgehebelt werden kann. Es hat schon seinen Grund, warum bei den Marktführern in dieser Szene, INgenieure sitzen, die das schon seit Jahren (Jahrzehnten) machen und wissen was sie tun. Deren Wissen eigenst du dir nun mal nicht in 3 WOchen an. Und dabei rede ich nicht von der Programmierung an sich, sondern von den Schutzverfahren. Denn was hilft dir ein Dongle, wenn jeder Nasenbohrer ihn in 20 Sekunden mit 3 Mausklicks aushebeln kann?
Hallo! In welcher Programmiersprache entwickelt denn die Firma ihre Software? Dort musst du dein Donglesystem ja einbinden. D.h. das ist die erste Baustelle. Dann ist Verschlüssselung eine weitere Baustelle, der (das?) Dongle soll ja nicht eine einfache Seriennummer tragen, die mitgelesen werden kann. Die PC-Seite schickt beispielsweise einen zufälligen Datenstrom, der Dongle verschlüsselt ihn und schickt ihn zurück. Der PC-kann jetzt mit seinem eigenen Schlüssel erkennen, ob der Dongle der richtige ist. Wenn die Kunden verschiedene Varianten mit mehreren Optionen bei euch kaufen, gehören noch eine Seriennummernverwaltung und ein Versionsmanagement dazu. Du hast also eine Menge Arbeit vor dir.
Hab mit MSP nicht so viel erfahrung. Wurde dir aber einen Pic18f2550 empfehlen, da du mit minimalen Aufwand die Schaltung hin bekommst und bei Microchip schon ne fast fertige Software liefert für den USB Treiber den du mit minimalen C Kenntnissen relativ schnell angepasst hast.
Was studierst Du denn eigentlich? Ich würde erstmal vorschlagen: - C richtig lernen! - ein MSP430 Launchpad für die ersten Gehversuche besorgen - http://processors.wiki.ti.com/index.php/MSP430_LaunchPad_%28MSP-EXP430G2%29 durcharbeiten Wenn Du dann einigermaßen vertraut mit C und dem µC bist, kannst Du mit USB die nächsten Baustelle anfangen. Dann weißt Du zwar, wie Du mit dem µC umzugehen hast, die eigentliche Aufgabe steht allerdings noch aus...
Martin H. schrieb: > Ich würde erstmal vorschlagen: > - C richtig lernen! und zwar auf dem PC - da hat man bessere Debugmöglichkeiten.
So also ich versuche mal die meisten Fragen zu beantworten^^ Ging ja ziemlich flott! Also ich mach zurzeit ein Matse Studium(Mathematisch technischer Softwareentwickler) und sitze grad an meiner Bachelorarbeit. Das Launchpad liegt bereits vor, wie oben genannt ist es das MSP430f5529. Ich denke dass es erstmal egal ist wie sicher der Schutz ist. Wird wahrscheinlich erstmal auf eine Wortverschlüsselung mit irgendeinem Schlüssel hinauslaufen. Mir wäre es wichtig erstmal die Kommunikation zwischen PC und µC hinzubekommen. Mein Mentor hat mir gesagt, ich solle mich erstmal um die Kommunikation kümmern sprich Treiberentwicklung, schauen ob es schon vorgefertigte Treiber gibt usw. Habe herausgefunden, dass es von Windows das WDF (Windows Driver Framework) gibt wo man eventuell schon einen passenden USB-Treiber gibt. Was für Treiber brauche ich überhaupt? Die Programme, in die der Softwareschutz eingebaut werden soll werden hier hauptsächlich in C++ geschrieben. (Der Schutz wird so auch nciht einfach übernommen, das ganze wird später noch überarbeitet usw. mir geht es nur erstmal um meine Bachelorarbeit) Ich habe mir 2 Entwicklungsumgebungen für die Programmentwicklung für µC angeschaut und mal ausprobiert: Einmal das Plugin für Eclipse, was ein bisschen aufwändig ist(schwirren immer noch ein paar Fehlermeldungen herum) und IAR mit einer Testlizenz. Habe auch schon ein paar Codebeispiele ausprobiert bzw ein wenig herumexperimentiert. Denke hier ist erstmal das wichtigste, zu wissen WIE man WAS anspricht
Ich wuerd auch zu einer vorgaengigen Simulation aufm PC raten. Als Dongle kann man ja einen selbstaendigen Thread nehmen, dann Daten zu und von dem Thread senden. Die Thematik ist eher anspruchsvoll. Ein nettes Projekt, von dem der Chef zwar ein paar Erkenntnisse, aber kein fertiges Produkt erwarten kann. Die ersten Fragen : -Muss ein Dongle zu einem PC passen, oder ein Dongle zu allen PC? -Kann das Dongle etwas funktionales beitragen, oder koennte man als Angreifer einfach Einsprung und Return in den Dongle-Hier-Code kurzschliessen. zB indem man eine Verarbeitungsstufe in den Dongle auslagert. Bei kurzgeschlossenem Dongle waeren die Resultate dann eben falsch. Zur Hardware. Das Einfachste wird wohl ein USB-to-Serial am Controller sein. Dann erscheint der Dongle als Serial port.
Ok ich werde mir jetzt als erstes mal die Grundlagen über USB zu Gemüte ziehen. Habe die Buchempfehlung USB Complete Fourth Edition von Jan Axelson bekommen und werde mal sehen ob mir danach einige Dinge klarer erscheinen.
Wenn Du schon soweit bist, würde ich Dir vorschlagen, das Ganze als "Generic HID" am USB laufen zu lassen. Das hat den Vorteil, dass Du ganz ohne Treiber auskommen kannst - bzw. sind die Treiber in so gut wie jedem OS bereits integriert. Man hat dann zwar bloß jeweils einen Endpoint mit 64Byte pro Richtung, für die Anwendung sollte das aber ausreichend sein.
Schau Dir mal libusb an. Damit kannst Du USB Geräte OHNE Treiber ansprechen. Vorteile: - Keine Treiberinstallation notwendig - Keine Treiber-Programmierung für verschiedene Betriebsysteme und Versionen notwendig - Unterstützt (im Gegensatz zu WDF) zahlreiche Programmiersprachen - Keine Notwendigkeit, sich mit WDF auseinander zu setzen - Registriert keinen virtuellen seriellen Port, dessen Nummer Du erstmal herausfinden musst. Schau Dir als Beispielanwendung den ISP Programmer von fischl.de an. Der ist sehr gut dokumentiert und kann über die libusb angesprochen werden.
Als Einzelkämpfer kann man heute nicht mehr eine Software anfangen, für die es schon lange professionelle Lösungen gibt. Man hat dann einen Rückstand von mehreren 100 Mannjahren. Also falls man es sogar bis zum Funktionieren schaffen sollte, dann bestenfalls auf dem Niveau von vor 20 Jahren. Wenn ich mal zurück denke, der Keil C51 Dongle von 1995 war aus heutiger Sicht lächerlich einfach programmiert und im nu geknackt. Und das Knacken war sogar legal, da die Dongle unter Windows-NT nicht mehr liefen. Das größte Problem ist aber das Verweben der Applikation mit der Dongle-Software. Man muß verhindern, daß der Hacker einfach den Debugger laufen läßt und einen Breakpoint auf die Abfrage setzt, um dann mit einem Patch einfach die Abfrage zu überspringen. Es nützt die beste Verschlüsselung nichts, wenn sie nirgends mehr aufgerufen wird.
Eben deshalb sollte man eine gewisse Funktionalitaet vom Dongle ausfuehren lassen. Ich hatt mal so eine Applikation da wurde der Hashwert fuer die Meldungen einer Kommunikationsapplikation vom Dongle gerechnet, natuerlich nicht 1:1, sondern codiert uebertragen, wenn der Dongle nicht dran ist, stimmt der Hash wert nicht, und die Applikation kann nicht kommunizieren. Bis der Benutzer diese Funktionalitaet nachgebildet hat, hat er den Dongle resp die Applikation vier mal gekauft.
Daniel Terßen schrieb: > Ich denke dass es erstmal egal ist wie sicher der Schutz ist. Wird > wahrscheinlich erstmal auf eine Wortverschlüsselung mit irgendeinem > Schlüssel hinauslaufen. > Mir wäre es wichtig erstmal die Kommunikation zwischen PC und µC > hinzubekommen. Mein Mentor hat mir gesagt, ich solle mich erstmal um die > Kommunikation kümmern sprich Treiberentwicklung, schauen ob es schon > vorgefertigte Treiber gibt usw. Habe herausgefunden, dass es von Windows > das WDF (Windows Driver Framework) gibt wo man eventuell schon einen > passenden USB-Treiber gibt. Wenn in der Bachelor-Arbeit etwas mehr stehen soll als der (Teil eines) Treiber, würde ich das WDF ganz schnell wieder vergessen. USB HID wäre wohl das einfachste. Beispiele gibt's im http://www.ti.com/tool/msp430usbdevpack
Moin Worauf sollst du denn ein besonderes Augenmerk bei deiner Arbeit legen? Auf die Kommunikation zwischen Dongle und PC, die eigentliche Methode des Sicherungsmechanismus, die Programmierung des Mikrocontrollers... Darfst du z.B einfach eine USB-2-UART Bridge verwenden, um die Kommunikation zwischen Dongle und Betriebssystem des PCs kompatibel und einfach zu gestalten? Gruß Pinguin
Vielleicht nicht Teil einer formellen Ausbildung, Teil der Praxis ist es aber eigentlich immer zwischen Zukaufen und Selbstmachen (Make or Buy) zu entscheiden. Überleg Dir nen paar Argumente dafür und dagegen. Nen paar Ideen: - Kosten pro Stück - Entwicklungskosten - Lerneffekt an der "richtigen" Stelle weil man in diese Richtung in Zukunft noch mehr entwickeln möchte - Einige spezielle Funktionen gibt es nicht zu kaufen - Erreichbares Sicherheitsniveau - Kompatibilität mit unvorhergesehenen Einsatzszenarien beim Kunden (spezielles OS, viele Dongles gleichzeitig, Terminalserver, Virtualisierung,...) - Langfristiger Pflegeaufwand (neue Versionen von Windows etc.) - Wie leicht kann die Pflege und Weiterentwicklung an einen Kollegen weitergegeben werden wenn Du mal nicht verfügbar bist? Wenn nicht ganz spezielle Funktionen benötigt werden, finde ich daß nicht viel für das Selbermachen spricht. Und eine Arbeit zu machen, die nachher für die Schublade ist, erhöht nicht gerade die Motivation. Besprich das Thema (inkl. den Argumenten) daher vielleicht nochmal mit Deinem Chef.
Ich kaufe prinzipiell NICHTS mehr, was irgendwie verdongelt ist, absolutes ko-Kriterium. Es macht(e) mir als Anwender immer nur Schwierigkeiten (neuer PC, neues Betriebssystem). Damit muss ich mich nicht rumärgern. Die wirklich kriminellen Nutzer kann man damit eh nicht schrecken, eher im Gegenteil. Einen gewissen Reiz hat es ja, das zu knacken. Die ehrlichen Kunden dagegen werden bestraft mit Problemen, die sie nicht haben wollen. PS: alle meine Software ist entweder Freeware oder gekauft.
>Man muß verhindern, daß der Hacker einfach den Debugger >laufen läßt und einen Breakpoint auf die Abfrage setzt, um dann mit >einem Patch einfach die Abfrage zu überspringen. Wenn, wie schon geschrieben, eine gewisse (nicht zu simple) Funktional. in den Dongle gelegt wird, dürfe das knacken fast unmöglich sein, denn an die Software im Dongle (uC) selbst kommen Dritte dann ja nicht mehr ran.
>dürfe das knacken fast unmöglich sein
dass dem nicht so ist sieht man ganz einfach indem man in einschlägige
Foren geht und sieht was da an Geknacktem im Umlauf ist.
Vielleicht kann man da zumindest ein paar Fehler die man nicht machen
soll.
Zu Debuggern - da gibt mWn einen der als Hypervisor läuft. Wie man sowas
erkennen soll ???
heinz schrieb: > Zu Debuggern - da gibt mWn einen der als Hypervisor läuft. Wie man sowas > erkennen soll ??? wenn man das Knowhow hat geht das schon, such mal nach Red Pill. Den Hypervisor als solchen zu erkennen hilft Dir aber nix wenn der Kunde das Produkt nachher virtualisiert laufen lassen will - und wenn die Investition größer ist, fordert der Kunde das natürlich damit er die Software nicht wegwerfen muss, nur weil es für die neueste, vom Programm noch unterstützte Windows-Version keine Hardware mehr gibt. Daher musst Du also nen "guten" von nem "bösen" Hypervisor unterscheiden können. Könnte man evtl. über Timing-Analysen machen. Wenn der Debugger zu lange braucht weil der User gebreakt hat, läuft ein Timer im Dongle weiter und das Programm kann das erkennen und aussteigen. Das Verhalten kann man dann natürlich noch verschleiern damit der Hacker das nicht sofort bemerkt. Ich glaube sowas geht dann aber schon ein wenig über das Niveau von ner Bachelorarbeit hinaus. Es könnte sowas aber durchaus bei kommerziellen Dongles berücksichtigt sein.
>>dürfe das knacken fast unmöglich sein >dass dem nicht so ist sieht man ganz einfach indem man in einschlägige >Foren geht und sieht was da an Geknacktem im Umlauf ist. Wie soll man die Funktionaliät im uC (nicht aufm PC) knacken, wenn man nicht da dran kommt, bzw nicht in den uC reinsehen kann? Man müsste die Funktionaliät (nicht die Kommunikation zwecks verschlüsselter Werte-Übergabe) complett nachbilden, quasi neu schreiben. (Bei .net (aufm PC) kommt noch dazu, dass alles sozusagen sogar im Quellcode (!) vorlieget, wegen IL)
Ich gehe mal davon aus, daß man sich schon über Anbieter von Dongle und andere Artikel informiert hat, z.B.: http://www.matrixlock.de/ http://www.emsec.rub.de/media/crypto/attachments/files/2011/04/hardwarebasierter_softwareschutz.pdf http://www.kopierschutzsysteme.de/index.php?sid=0f11171e3d524aea1e50656a98ef9bca Damit kann man schon einschätzen, daß der Hammer auf diesem Gebiet sehr hoch hängt.
In dem obigen Artikel der Uni Bochum (http://www.emsec.rub.de/media/crypto/attachments/f...) wird nichtmal erwähnt, die Funktionaliät (oder ein Teil davon) in den Dongle zu legen.
Der Artikel hat ja auch schon 10 Jahre auf dem Buckel. Ich habe nicht recherchiert, das sind einfach nur die ersten Google-Treffer.
T. roll schrieb: > Eben deshalb sollte man eine gewisse Funktionalitaet vom Dongle > ausfuehren lassen. Ich hatt mal so eine Applikation da wurde ... > Bis der Benutzer diese Funktionalitaet nachgebildet hat, hat er den > Dongle resp die Applikation vier mal gekauft. Es gibt Leute, die die Software gar nicht kaufen wollen, sondern einfach nur Spass am Knacken eines Dongles haben... MCUA schrieb: > Wie soll man die Funktionaliät im uC (nicht aufm PC) knacken, wenn man > nicht da dran kommt, bzw nicht in den uC reinsehen kann? Wie "nicht dran kommt"? Du kannst z.B. "einfach" das Gehäuse eines uC wegätzen und den Silizium-Chip direkt kontaktieren. Was? Zu kompliziert? Lass dir gesagt sein: nur beim allerersten Mal...
"Mein Chef hat mir als Thema vorgeschlagen, für die Firma ein eigenes Donglesystem zu entwickeln." Als Chef würde ich keinen Mitarbeiter mit der Entwicklung eines sicherheitsanfälligen Systems (für die eigene Firma!!!) beauftragen, der bereits nach dem Überfliegen eines Buches über Microcontroller dasteht wie der Ochs vorm Berg. War nicht böse gemeint, aber so wirst Du Dich bestimmt gefühlt haben. Ich würde ein anderes Projekt empfehlen.
Stefan Frings schrieb: > Schau Dir mal libusb an. Damit kannst Du USB Geräte OHNE Treiber > ansprechen. Nein, einen Treiber brauchst du trotzdem noch, denn er stellt die Verbindung zur Hardware her. Allerdings bringen alle nicht-Windows-Systeme einen generischen USB-Treiber mit, über den die libusb ansetzen kann, damit braucht man auf diesen erstmal keinen speziellen Treiber mehr. Leider hat Windows keinen derartigen Treiber zu bieten, sodass man dort immer noch einen Treiber mitschleppen muss, auf den die libusb dann aufsetzen kann. Allerdings gibt es eben auch unter Windows zumindest einen relativ generischen Treiber: HID, der krallt sich eine ganze Klasse und ist immer installiert. Wenn nun das einzige Werkzeug ein HID- Treiber ist, dann sieht halt plötzlich jedes Werkstück wie ein human interface aus …
>> Wie soll man die Funktionaliät im uC (nicht aufm PC) knacken, wenn man >> nicht da dran kommt, bzw nicht in den uC reinsehen kann? >Wie "nicht dran kommt"? >Du kannst z.B. "einfach" das Gehäuse eines uC wegätzen und den >Silizium-Chip direkt kontaktieren. Was? Zu kompliziert? Lass dir gesagt >sein: nur beim allerersten Mal... Ja, geht schon, ist aber im Vergleich zum Debuggen weitaus aufwändiger, und nach lange nicht Jeder wird das machen (können/wollen)!! Jedenfalls ergibt sich doch ein gewisser Sicherheitslevel (wie ja auch bei reinen uC-Systemen, oder PLD mit gesetzter Fuse, oder FPGA mit Crypt) wenn man ans IC von aussen so nicht heran kommt. (Die DDR hatte auch x86er-Gehäuse abgeschliffen) Aber selbst wenn man herankommt, hat man ja den ASM-Code des jeweiligen uCs vor sich, und nicht den vom PC(CPU), also ist selbst dann noch eine weitere Hürde vorhanden. (viell. würde er dann versuchen, den ganzen Dongle nachmachen zu wollen oä) Alles ne Frage des Aufwandes.
Also ich gehe mal davon aus, dass es deinem Chef auf das ankommt, was der Mikrocontroller mit dem Computer macht und du in deiner Arbeit nicht das Rad neu erfinden sollst: Der Mikrocontroller muss einfach den Computer erreichen und in dem Fall würde ich dir wie alle anderen auch zu der HID-Lösung raten. Mit dem Controller wird über ein paar Busleitungen der "Adapter" für den USB-Anschluss verbunden, sodass du in deinem Programm auf dem Mikrocontroller das Übertragungssystem nutzen kannst, was der Controller dir zur Verfügung stellt und was auch in seiner Dokumentation ausführlich beschrieben ist. Der "Adapter" (oder politisch korrekt: Die Bridge) wird vom Computer als HID erkannt und dementsprechend sind die Treiber auch schon vorinstalliert (selbst Android-Systeme können damit umgehen) und so kannst du mit deinem Computerprogramm sehr einfach und komfortabel das empfangen, was du mit dem Mikrocontroller so komfortabel abgeschickt hast, weil der Adapter das Geschwätz vom Mikrocontroller in den USB-Standard verpackt. Das wäre so hardwaremäßig relativ einfach und du muss dich nicht hinsetzen und irgendwelche USB-Übertragungsstandards mühselig in den Controller packen, sondern kannst dich auf das konzentrieren, was Dongle und Computer machen, und nicht wie sie es machen. Als Beispiel: http://shop.myavr.de/Bauelemente%20und%20Controller/myUSBtoUART.htm?sp=article.sp.php&artID=200024 Mit dem Ding habe ich die ersten Gehversuche in der Kommunikation Computer zu Controller und umgekehrt gemacht. Am Linux-Rechner wurde das Ding sofort erkannt und ich konnte echo mit einer Pipe zum seriellen Gerät zum Senden und cat zum Empfangen benutzen. Bei Windows sind wohl leider noch Treiber nötig. Habs aber nicht ausprobiert. Sowas brauchst du als Bridge. Nur muss deine als Eingabegerät und nicht als serielles Gerät erkannt werden, damit die Treiber da sind. ALso. Ich hoffe ich konnte dir helfen und du denkst jetzt nicht "Was will der Penner, hält der mich für blöd, das wusste ich schon alles." Das denkt irgendwie dauernd jemand über mich. Gruß Joschua
Thread beobachten
Seitenaufteilung abschaltenBitte 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.