OpenSSL Konfiguration von AVM erraten

olistudent

IPPF-Urgestein
Mitglied seit
19 Okt 2004
Beiträge
14,787
Punkte für Reaktionen
13
Punkte
38
Hi.
Aus gegebenem Anlass würde ich hier gerne rausfinden, wie wir die OpenSSL Konfiguration von AVM erraten können. Wenn AVM Patches anwendet, dann dürfte das natürlich schwierig werden.
Die Alternative wäre, dass wir "unsere" OpenSSL-Library in ein anderes Verzeichnis legen und alle Binaries mit LD_LIBRARY_PATH aufrufen, was ich persöhnlich nicht gut finde.
Ich hab mich noch nicht wirklich mit dem Thema befasst. Jedoch hatte mir schonmal jemand eine Tipp bezüglich LD_PRELOAD gegeben.

MfG Oliver
 
Hier ist mal ein kleiner Anfang, der mit einfacheren Mitteln zustande gekommen ist: Ich habe mittels des Werkzeugs strings in die beiden OpenSSL-Blbliotheken (libssl, libcrypto) sowohl von AVM (29.04.27) als auch von uns (ds26-15.2) hinein geschaut, d.h. die entsprechenden Strings extrahiert. Danach habe ich noch etwas übrig gebliebenen Müll mit dem Editor entfernt und ein diff -u0 (Uni-Diff ohne Kontext) darüber laufen lassen. Um das Ganze noch kompakter zu bekommen und unnötige Unterschiede aufgrund textueller Verschiebungen zu vermeiden, habe ich in einem zweiten Durchgang die Diffs dann noch einmal mit den sortierten (sort) und von doppelten Textzeilen (uniq) befreiten Textdateien gemacht. Sämtliche Ergebnisse befinden sich im Anhang. Aus den Dateinamen sollte man erkennen, worum es sich jeweils handelt.

Es fällt zunächst beim Überfliegen auf, daß die Unterschiede hauptsächlich, aber eben nicht ausschließlich aus Sachen bestehen, die wir zusätzlich zu AVM in den Libs haben. Das sollte nicht stören, kann aber Hinweise darauf geben, wie wir noch etwas mehr sparen können. Andererseits benötigen wir evtl. die zusätzlichen Funktionen für OpenVPN u.a. Pakete, das habe ich nicht geprüft. Es ist in diesem Zusammenhang auch nicht so wichtig.

Interessanter sind meiner Meinung nach die Sektionen, wo AVM Dinge drin hat, die uns fehlen. Da gibt es schon viel weniger. Auf die Schnelle sehe ich
  • MD2 (zusätzlich zu MD4/5)
  • SHA (zusätzlich zu SHA1/224/256/...)
  • ossl_HMAC statt bei uns HMAC (Versionsunterschied 0.9.8 zu unserem 0.9.8e? Keine Ahnung.)
  • EXP1024* (z.B. EXP1024-DES-CBC-SHA)
  • SSLv2/3 compatibility part
Außerdem findet sich in AVMs libcrypto folgende Compiler-Zeile:
Code:
mipsel-linux-uclibc-gcc \
	-fPIC \
	-DOPENSSL_PIC \
	-DOPENSSL_NO_ERR \
	-DL_ENDIAN \
	-DTERMIO \
	-march=4kc \
	-mtune=4kc \
	-Os \
	-fomit-frame-pointer \
	-Wall
Wir verwenden das hier (nicht viel anders):
Code:
mipsel-linux-uclibc-gcc \
	-fPIC \
	-DOPENSSL_PIC \
	-DZLIB_SHARED \
	-DZLIB \
	-DDSO_DLFCN \
	-DHAVE_DLFCN_H \
	-I/home/kriegaex/ds/trunk/toolchain/build/gcc-4.2.1-uClibc-0.9.28/mipsel-linux-uclibc/include \
	-DOPENSSL_SMALL_FOOTPRINT \
	-DOPENSSL_NO_ERR \
	-DTERMIO \
	-Os \
	-pipe \
	-march=4kc \
	-Wa,--trap \
	-D_LARGEFILE_SOURCE \
	-D_LARGEFILE64_SOURCE \
	-D_FILE_OFFSET_BITS=64 \
	-fomit-frame-pointer \
	-Wall
Ob das jemandem etwas nützt, weiß ich nicht. Aber es könnte ein Anfang sein.

Update: Ich habe mal noch schnell mit einem Kommandozeilen-Werkzeug für ELF-Dateien nur die Symboltabellen der Bibliotheken exportiert und verglichen. Diese Diffs sind etwas übersichtlicher, wenn man speziell an den Symboltabellen interessiert ist. Siehe Anhang #2.
 

Anhänge

  • openssl-diffs.tar.bz2
    78.1 KB · Aufrufe: 6
  • openssl-symbols-diffs.tar.bz2
    20.1 KB · Aufrufe: 3
Zuletzt bearbeitet:
Hallo Olistudent,

[edit]
Oh, vergiß es, ich habe wohl openSSL mit openVPN verwechselt.
[/edit]

entschuldigung wenn ich was verpasst habe, aber seit wann verwendet AVM openVPN? Ich dachte die hätten ein anderes VPN in ihrer Laborfirmware.
Ich interessiere mich dafür, wiel ich dabei bin ein VPN zwischen ner FB7050 (mit DS-mod aber externer openVPN-Binary) und ner FB7170 (bisher ohne mod mit der selben openVPN-Binary) aufzubauen und es vielleicht später interessant wäre Code zu nutzen der eh schon in der Box ist. Oder wird das AVM openVPN nie kompatiebel mit ner FB7050 sein?

.
 
Zuletzt bearbeitet:
Wo steht etwas davon, daß AVM openVPN verwenden würde?
AVM verwendet angeblich IPSEC.

Wie äußern sich denn Probleme zwischen der AVM-OpenSSL und der ds-mod-OpenSSL?
Fehlende Symbole, nicht funktionierende Programme?
Gibt es ds-mod Programme, die nicht mit der AVM-OpenSSL funktionieren, wo das nicht an fehlenden Funktionen liegt?
 
Der ctlmgr crasht mit einem Segfault, wenn wir unsere Library nutzen und tr069 aktiviert ist. Leider konnte ich das gestern nicht nachstellen. Keine Ahnung warum.
Und andersrum ist natürlich auch schwierig, da wir nicht gegen AVMs Libraries linken können.
Mir wäre es daher am Liebsten, wenn wir eine libcrypto und libssl bauen könnten, die "binär kompatibel" mit AVMs Versionen sind. Ist das überhaupt möglich (0.9.8 vs. 0.9.8e)?

MfG Oliver
 
Mir ist klar, daß die Frage auf binär kompatible Libraries abzielt, speziell weil von den AVM-Programmen nur die Binärdateien vorhanden sind.

Ich habe bei mir auch mal tr069 aktiviert, und er baut auch tatsächlich eine Verbindung auf, was ich nicht erwartet hatte, weil er nicht selbst eine DSL-Verbindung hat. Die tr069.cfg wurde auch geändert, hier die neue Datei mit den Änderungen gegenüber der Default-Datei:
Code:
[B]/*
 * /var/flash/tr069.cfg
 * Wed Sep 26 11:05:31 2007
 */

[/B]tr069cfg {
        enabled = yes;
        igd {
                DeviceInfo {
                        ProvisioningCode = "000.000.000.000";
                }
                managementserver {
                        url = "https://acs.t-online.de/acs/";
                        username = "";
                        password = "";
                        URLAlreadyContacted = no;
[B]                        PeriodicInformEnable = no;
                        PeriodicInformInterval = 0;
                        PeriodicInformTime = "1970-01-01 01:00:00";
                        UpgradesManaged = no;
                        ConnectionRequestUsername = "";
                        ConnectionRequestPassword = "";
                }
        }
        FirmwareDownload {
                valid = no;
                status = 0;
                StartTime = "1970-01-01 01:00:00";
                CompleteTime = "1970-01-01 01:00:00";
        }
        RebootRequest = no;
        RebootRequest_CommandKey = "";
[/B]        ACS_SSL {
                own_cert_file = "/etc/default/tcom/tr069_cert.pem";
                verify_server = yes;
                trusted_ca_file = "/etc/default/tcom/verisign_class3_root_ca.pem";
        }
        Download_SSL {
                own_cert_file = "/etc/default/tcom/tr069_cert.pem";
                verify_server = yes;
                trusted_ca_file = "/etc/default/tcom/verisign_class3_root_ca.pem";
        }
}
[B]
// EOF
[/B]

Die Meldungen vom ctlmgr sehen so aus:
Code:
cltmgr: ssl_verify: depth=2 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
cltmgr: verify return:1
cltmgr: ssl_verify: depth=1 /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
cltmgr: verify return:1
cltmgr: ssl_verify: depth=0 /C=DE/ST=Hessen/L=Darmstadt/O=T-Online International AG/OU=T-Online International AG/OU=Terms of use at www.verisign.com/rpa (c)00/CN=acs.t-online.de
cltmgr: verify return:1
cltmgr: ValueChanged() GetParameterValueOfRelativePath mod=0x2b3e8758 name= failed
cltmgr: ValueChanged() GetParameterValueOfRelativePath mod=0x2b3e8558 name= failed
cltmgr: ValueChanged() GetParameterValueOfRelativePath mod=0x2b3e8458 name= failed
cltmgr: ValueChanged() GetParameterValueOfRelativePath mod=0x2b3e83d8 name= failed
Ich weiß nicht, ob das failed normal ist, aber ich bin sowieso nicht scharf darauf, daß von extern Einstellungen auf meinem Gerät verändert werden, daher ist meine größere Sorge, ob nicht andere Änderungen erfolgreich waren.

Wenn es jemand schafft, daß der ctlmgr zuverlässig abstürzt, wäre folgendes interessant:
Code:
# beschreibbares Verzeichnis wählen, ggf. auf USB oder NFS mount
cd /var/tmp
# ctlmgr stoppen, falls nötig
ctlmgr -s
# strace ctlmgr aufrufen, forground, verbose
strace -o strace.txt -s4000 ctlmgr -fv
# ltrace ctlmgr aufrufen, forground, verbose
ltrace -o ltrace.txt -s4000 -n2 -S ctlmgr -fv
# core Dateien erzeugen lassen
ulimit -c unlimited
# ctlmgr aufrufen, forground, verbose
ctlmgr -fv
# Dateien strace.txt ltrace.txt core sichern.
 
Info: Ich habe in #2 noch Dateien angehängt, die sich auf die Symboltabellen konzentrieren.

Update: Kleinigkeit: Der zweite Dateianhang wurde soeben durch eine neue Version ersetzt, weil ich die Symboltabellen ohne Unterscheidung der Groß-/Kleinschreibung sortiert hatte im Gegensatz zu Anhang 1. Das habe ich gerade korrigiert. Die Diffs sehen dadurch etwas anders aus.
 
Zuletzt bearbeitet:
Als nicht-Programmierer habe ich eine wilde Idee, die Bibliotheken aufzusplitten:
Wäre es möglich so eine Kostruktion zu erzeugen:
ds-mod OpenSSL enthält ein include auf AVM-OpenSSL (letztere wird dann umbenannt).
Unter dem "include"-Teil packt man in ds-mod OpenSSL nur die Funktionen, die AVM nicht hat.

MfG
 
Dafür wären mehrere Voraussetzungen notwendig:
  • Man müßte genau wissen, welche Funktionen in der AVM Library enthalten sind.
  • Es müßte Möglich sein, die Library ohne die (vermutlich Kern-)Funktionen der AVM Library zu erstellen.
  • Und das wichtigste: Die Funktionen, die in der eigenen Library weggelassen wurden, müssen kompatibel zu den Funktionen sein, die sich in der AVM-Version der Library befinden. Die AVM-Funktionen müssen als mindestens das tun, was man selbst an Funktionen weggelassen hat, und die Schnittstelle, inkl. Definition von Strukturen, muß exakt die gleiche sein.
Der letzte Punkt bringt uns dann auf den Beitrag #1:
olistudent schrieb:
Aus gegebenem Anlass würde ich hier gerne rausfinden, wie wir die OpenSSL Konfiguration von AVM erraten können.
Wenn die Funktionen aber schon genau kompatibel wären, könnte man auf die Aufteilung verzichten und nur die eigenen nehmen.
 
Wäre es denkbar, dass AVM in ihren Bibliotheken irgendeine Art Hardwareunterstützung nutzt, die eine eigene Bibliothek aus offenen Quellen nicht nutzt? (--> Geschwindigkeit)
 
Wir (Ralf und ich) sind dem Problem auf der Spur...

MfG Oliver
 
LD_PRELOAD wäre eine Möglichkeit, aber man müsste immernoch die genaue Struktur der Headerfiles kennen, damit man den Hook auch schreiben kann.

Das schwierige ist hier wohl das "erraten" der Parameter/Rückgabewerte der Funktionen (es sei denn, jmd kennt ein Werkzeug, mitdem das auch möglich ist. Es kann auch sein, dass AVM ganz andere Strukturen verwendet, als in der Standard-OpenSSL (was unweigerlich zum Segfault führt).
 
Die Symboltabellen habe ich ja oben bereits gepostet, Werkzeuge wie ltrace und gdb(server) zeigen Parameter, da sollte für die Experten des Fachs etwas zu machen sein. Meiner Meinung nach sind die Unterschiede gering, ich bin nur nicht fit in der C-Debugging-Ecke, Oliver schon etwas mehr. Aber es gibt ja noch Ralf, wie gesagt...
 
Hoffentlich haben die dann die Debug-Informationen miteinkompiliert ;)
 
Das meine ich nicht, obwohl ltrace und ein bißchen Versuch und Irrtum auch helfen könnten. Wir können jedoch TR-069 auf unseren Libs laufen lassen und nachvollziehen, wo es ggf. kracht. Daraus kann man auch Schlüsse ziehen.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.