Der Normalfall: In den Objects sind externe Symbole (Platzhalter), diese werden vom Linker aufgelöst und mit echten Speicher-Adressen ersetzt. Z.B. call mod_A_function_1 call mod_B_function_1 nach dem Linken: call 0xAE0064 call 0xAE0164 Nun der Spezialfall: Ich möchte bestimmte externe Symbole im ersten Linkvorgang unbestimmt belassen und andere auflösen. Z.B. call mod_A_function_1 call mod_B_function_1 nach dem Linken: call 0xAE0064 call mod_B_function_1 (extern) In einem zweiten Linkvorgang sollten dann die externen Symbole aufgelöst werden. Hintergrund: Ich möchte statt gegen einzelne Objects zu linken gegen eine vorgelinkte Lib linken, welche nur noch die Symbole enthält, die auch meine Lib betreffen. Konkret geht es hier um Know-How Schutz. Offiziell darf ich die einzelnen Objects meines Parterns nicht mehr erhalten - eine Alternative Möglichkeit wäre das vorgeschlagene Verfahren. Nun meine Frage: Ist dies überhaupt möglich? Und falls ja, gibt es dafür einen Fachausdruck? Danke Euch!
Servus würde mich auch interessieren. push Grüße aus Niederbayern
turboLoader schrieb: > In einem zweiten Linkvorgang sollten dann die externen Symbole aufgelöst > werden. Das machst du doch ständig. Wenn dein Projekt aus mehreren Modulen besteht, werden die jeweils in einzelne Objekte übersetzt. Anschließend werden die Objekte deines Projektes statisch zusammengelinkt. Was bis dahin auflösbar ist, wird auch aufgelöst. Es steht dir natürlich frei, einzelne dieser Objekte vorab schonmal zu größeren Objekten zusammenzulinken. Oder mehrere Objekte zusammen in eine statische Bibliothek zusammenzuziehen (üblicherweise mit dem Archiver 'ar'). Den Rest, also faktisch externe Symbole, werden beim Programmstart vom dynamischen Linker aufgelöst.
turboLoader schrieb: > Ich möchte bestimmte externe Symbole im ersten Linkvorgang unbestimmt > belassen und andere auflösen. Ich bin nicht sicher, ob ich das richtig verstehe, aber ist das nicht der normale Vorgang einer Library-Erstellung? Man linkt eine Reihe von Modulen zusammen, dabei wird aufgelöst was eben auflösbar ist und der Rest bleibt extern. Das Ergebnis wird als Library gespeichert. Den Vorgang kann man beliebig wiederholen, möglicherweise ist dazu eine Software nötig, die die Bezeichnung "Librarian" oder so trägt. Aber auch mit dem Linker müsste es möglich sein, eine Library und einige Module zusammenzulinken und das Ergebnis wieder als Library zu verwenden. Gruss Reinhard
Hallo Sven P., Hallo Reinhard, schon mal vielen Dank für eure Antworten. >Das machst du doch ständig. >Wenn dein Projekt aus mehreren Modulen besteht, werden die jeweils in >einzelne Objekte übersetzt. Anschließend werden die Objekte deines >Projektes statisch zusammengelinkt. Was bis dahin auflösbar ist, wird >auch aufgelöst. >Es steht dir natürlich frei, einzelne dieser Objekte vorab schonmal zu >größeren Objekten zusammenzulinken. Oder mehrere Objekte zusammen in >eine statische Bibliothek zusammenzuziehen (üblicherweise mit dem >Archiver 'ar'). Genau, mir geht es darum, dass die Vorab-Version ("Fremd-Lib") schon mal auf echte Memory Adressen statisch gelinkt wurde ... Die "Einsprungadressen" in der Lib zu "meinen" Funktionen (in meiner Lib) sollen dann aufgelöst werden. Vielleicht ist es noch etwas abstrakt was ich möchte bzw. definieren will ... Früher war es so, dass wir vom Zulieferer Objects erhalten und unsere Lib in einem finalen Gesamt-Build zusammen gefügt haben. Dies geht aus Know-How Schutz Gründen von unserem Zulieferer nun nicht mehr, da er Angst davor hat, dass wir seine Lib reverse-engineeren. Nun versuche ich einen Gegenvorschlag zu definieren, wie wir dennoch diesen "Gesamt-Build" selbst ausführen könnten. Der Vorschlag des Zulieferers ist es, dass nur noch er diesen Gesamt-Build durchführen kann. Evtl. wird es jetzt etwas klarer ... im Grund würde ich gerne das "fertige" S19 File mit unserer Lib "patchen" ... wir dürften dann nur in vordefinierten Speicher Sections unsere Code / RAM usw. ablegen. Evtl. funktioniert das auch gar nicht was ich mir da vorstelle! >Ich bin nicht sicher, ob ich das richtig verstehe, aber ist das nicht >der normale Vorgang einer Library-Erstellung? Man linkt eine Reihe von >Modulen zusammen, dabei wird aufgelöst was eben auflösbar ist und der >Rest bleibt extern. Das Ergebnis wird als Library gespeichert. Den >Vorgang kann man beliebig wiederholen, möglicherweise ist dazu eine >Software nötig, die die Bezeichnung "Librarian" oder so trägt. >Aber auch mit dem Linker müsste es möglich sein, eine Library und einige >Module zusammenzulinken und das Ergebnis wieder als Library zu >verwenden. Aber auch beim "Auflösen" werden ja nur relative Adressen hinterlegt? Keine absoluten Speicheradressen? Dies geschieht doch nur beim "finalen" Build? Genau, "unsere" Lib besteht auch aus mehreren Objects, die wir dann im finalen Build mit den zulieferer Libs zu einem großen Ganzen zusammenfügen. Gibt es eine Möglichkeit die Lib des Zulieferers so zuschützen, dass ein Dissasemblieren von unserer Seite nicht mehr möglich wäre, wir aber dennoch in der Lage wären einen Gesamt-"Exe" zu bauen? Danke Euch.
Um nicht lange drum rum zu schwafeln.... ;-) Der Zulieferer macht die Basis-Software, die Treiber, die Kommunikation, spezielle Systemnahe Applikationskomponenten... und wir machen die globale Applikationslogik... 2 getrennte Firmen.... spezielle Applikationskomponenten des Zulieferers enthalten allerdings Teile in die wir nicht unbedingt hineinschauen sollen... z.b. wie bestimmte Regler etc. gelöst sind ...
turboLoader schrieb: > Dies geht aus Know-How Schutz Gründen von unserem Zulieferer nun nicht > mehr, da er Angst davor hat, dass wir seine Lib reverse-engineeren. Dann wäre es dringend an der Zeit, entweder den Zulieferer über seine schwachsinnige Ansicht aufzuklären oder einen anderen Zulieferer zu finden... Wo genau sieht denn der Zulieferer den Unterschied zwischen einem Objekt, welches er euch (wie früher) liefert und einem S-Record-File (S19), welches er euch nun liefern möchte? Disassemblieren kann man nämlich beides mühelos. Es ist doch übliche Praxis, Bibliotheken auszuliefern. Natürlich kann man beim Linken z.B. ein paar Sektionen für 'euren' Code freihalten. Der Zulieferer müsste dann z.B. an Stubs springen. Das sind leere Funktionen, die im Assembly z.B. nur aus dem Rücksprung bestehen. Solche Stubs kann man wiederum beim Linken auf feste Adresse legen (so wie man z.B. manchmal Interrupt-Serviceroutinen an feste Stellen legt), sodass das Programm vollständig gelinkt werden kann. Da diese Adresse ja bekannt ist, kann man den Rücksprung nachher gegen einen Sprung in 'eure echten' Routinen patchen. Nun mag ich mich wiederholen, wenn ich diese Vorgehensweise für Blödsinn halte. Ich finde, irgendwas stimmt in eurer Gesamtkonstruktion inklusive Zulieferer nicht so richtig.
Üblich ist in dem Umfeld, zweischrittig zu linken. Der erste Link ist ein "relocatable" Link (-r bei GNU Binutils), die sich nicht über nicht-aufgelöste Symbole beschwert. Der zweite Link ist dann der "final" Link.
turboLoader schrieb: > Gibt es eine Möglichkeit die Lib des Zulieferers so zuschützen, dass ein > Dissasemblieren von unserer Seite nicht mehr möglich wäre Nein, das ist grundsätzlich unmöglich - ihr habt von ihm in irgendeiner Form ausführbaren Code bekommen, den kann man immer disassemblieren, wenn man ihn ausführen kann - wenn nicht ist er nutzlos. Geschützt ist der Code erst, wenn er in einem internen Flash-Speicher untergebracht und nicht mehr extern lesbar ist, und dazu braucht man nicht nur den final build, sondern den fertig programmierten Chip. Ist bloss schade um Zeit und Gehirnschmalz, die ihr dafür investiert. Gruss Reinhard
Danke für eure Posts! ;-) Zulieferer wechseln geht leider in dieser Domäne nicht... ;-) die haben da ziemlich den ganzen Markt aufgekauft und sind momentan fast ausser Konkurrenz... Wir entwickeln modellbasiert, deshalb sind wir bis auf die pragmas im Code nicht besonders hardware-nah unterwegs ... Nach meiner bescheidenen Meinung dachte ich immer, dass "Object-Code" leichter zu dissasemblieren ist als die Funktion aus dem s19 File heraus zu extrahieren ... Die Objects / Libraries bündeln zumindest die funktionalen Blöcke schon mal in logische Einheiten ... D.h. kurz zusammengefasst: - Wenn wir am Ende noch ein s19 File erhalten - welches wir erhalten müssen(!), da wir die SW selbst flashen müssen, dann macht es aus Know-How Schutz Gründen keinen Unterschied, ob wir Libs / Objects oder eben dieses s19 File erhalten? Danke Euch!
Hmm, wenn dein Zulieferer irgendwie einen besonderen Schutz für seinen Code will, dann ist es doch eigentlich nicht deine Aufgabe, führ ihn einen solchen zu finden und ihm zu sagen, wie der aussehen soll.
turboLoader schrieb: > Wenn wir am Ende noch ein s19 File erhalten - welches wir erhalten > müssen(!), da wir die SW selbst flashen müssen, dann macht es aus > Know-How Schutz Gründen keinen Unterschied, ob wir Libs / Objects oder > eben dieses s19 File erhalten? Nein, macht quasi(...) keinen Unterschied. Was passieren könnte: In die Objekt-Dateien/Libs kann man noch Symbole einbetten. Dabei kann es sich einerseits um Debug-Symbole handeln, aus denen man möglicherweise seine Schlüsse ziehen kann. Die Debug-Symbole kann man aber herausstrippen. Andererseits müssen ja noch die Symbole vorhanden sein, mit denen später gelinkt wird. Die kann man sinnigerweise schlecht entfernen, bevor gelinkt wurde. Man kann die aber auf das nötige Minimum reduzieren, indem man zuvor alles 'schützenswerte' relozierbar verlinkt und dann im Anschluss nur noch ein paar Symbole als Einsprung im Objekt belässt. Sobald du dein s19-File hast, hast du ausführbaren Code. Den kann man immer disassemblieren. Entsprechende Werkzeuge dröseln dir das dann möglicherweise auch noch in ein Call-Diagramm auf usw.
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.