Externe Symbole in statisch gelinker Bibliothek möglich

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.

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.