2017-01-06 2 views
0

Nachdem ich thesequestions gelesen habe, bin ich auf der Suche nach weiteren Details zur Steuerung der Reihenfolge der Symbolauflösung.Lösen von Symbolen unterschiedlich in verschiedenen dynamisch geladenen Objekten

In meinem Problem habe ich Haupt ausführbare exec. exec verknüpft dynamisch mit a.so und c.so. a.so verweist dynamisch auf b.so. b.so ruft die Funktion foo auf, die normalerweise von c.so bereitgestellt wird, aber in diesem Fall wird auch von exec bereitgestellt. b.so funktioniert nur mit c.so Implementierung von foo.

Ein Diagramm der Situation:

exec  (foo caller and provider) 
    | \ 
a.so | 
    | | 
b.so | (foo caller) 
    |/
c.so  (foo provider) 

ich nur die Kompilierung/Quelle a.so steuern kann, und ich verlinke a.so-exec mit LD_PRELOAD.

würde ich Anrufe foo in exec gerne s Implementierung exec zu lösen ‚zu c.so s Implementierung und Anrufe in b.so lösen‘. Ist diese Art von Ding mit unterschiedlichen Symbol-Lookups in verschiedenen Objekten möglich?

Antwort

0

Leider gibt es keine Möglichkeit, die Symbolauflösung auf der Ebene pro Bibliothek zu optimieren, so dass es nicht einfach ist, dies zu erreichen.

Wenn foo tatsächlich in ausführbarem Haupt implementiert (nicht nur copy-relocated es) gibt es nichts, was man tun kann, weil Symbole aus dem Haupt Executables die höchste Priorität bei der Auflösung erhalten (es sei denn, Sie mit letztlich Hacky Runtime-Patching von GOT ok sind die du bist nicht).

Aber wenn

  • foo in c.so implementiert
  • und Sie sind verzweifelt genug

Sie könnten folgendes tun:

  • get Absenderadresse innerhalb Interceptor in a.so (verwenden Sie __builtin_return_address)
  • Spiel gegen Grenzen b.so
  • je nach Ergebnis (aus /proc/self/maps erhalten werden), entweder tun spezielle Verarbeitung (wenn der Anrufer im b.so ist) oder nach vorne Aufruf RTLD_NEXT

Diese von Natürlich hat offensichtliche Einschränkungen z funktioniert nicht, wenn b.so die Funktion von einem anderen d.so aufruft, das dann foo aufruft, aber es kann in vielen Fällen genug sein. Und ja, ich habe diesen Ansatz in der Praxis gesehen.

+0

Wie könnte ich das mit '' dlsym'' machen? Ich sehe, wie '' a.so'' auf '' c.so'' '' foo' 'mit' 'dlsym'' verweisen kann, aber gibt es eine Möglichkeit,' 'dlsym'' zu verwenden, um' 'zu machen 'b.so'' benutze es? –

+0

Entschuldigung, habe die Frage falsch gelesen. Ich habe die Antwort aktualisiert, hoffentlich ist es jetzt hilfreicher. – yugr

+0

danke für die Bearbeitung! Alle Abhängigkeiten gehen jedoch nur abwärts in das Diagramm ('' a.so'' ruft nur in '' b.so ''), was bedeutet, dass der '' __builtin_return_address'' Trick nicht funktioniert. Es sind auch separate Implementierungen von '' foo'' in '' exec'' und '' c.so''. Gibt es irgendwelche Ressourcen auf GOT Hacking (das ist keine Straße, die ich hinuntergehen will, aber ist etwas, über das ich gerne erfahren würde)? –

Verwandte Themen