Open tommy4st opened 5 years ago
iampickle
commented
5 years ago Ich habe in der libre link apk, da diese den libre link 2 ja jetzt auch lesen kann, ein bisschen rumgeschnüffelt und ein Sektion gefunden die "encryption" oder so heißt, müsste ich nochmal nachgucken. Es wäre ja möglich das der Algorithmus zum entschlüssel da drin steckt und dass man das ganze da rausextrahieren kann.🙃
tommy4st
commented
5 years ago Also, ich denke es ist relativ aussichtslos. Den Algorithmus bekommt man möglicherweise noch raus, aber den Schlüssel eher nicht. Anscheinend wird die Software Secure Key Box von intertrust verwendet um den Schlüssel zu schützen. Im Promovideo auf der Startseite wird sogar von Blutzuckermessung geredet.
Alternativ müsste man den Schlüssel von Hand knacken. Folgende Verfahren werden von SKB unterstützt: DES, AES, RSA, ECC, ECDSA, DH, ECDH, und SHA. Hier sollte man sich fragen, was macht für ein kleines Device wie den Freestyle Sensor energetisch gesehen Sinn?
TheCrazyT
commented
3 years ago Weis nicht inwieweit das noch Sinn macht hier noch zu antworten, ich mach es aber trotzdem. Glaub die "SKB"-Verschlüsslung in der APK wird eldiglich für das Senden von Support-Infos verwendet. (aus Datenschutzgründen) Rein technisch macht das auch nicht soviel Sinn da irgendwas zu verschlüsseln, die App selbst ist ja kostenlos.
TheCrazyT
commented
3 years ago Aus speichertechnischer Sicht macht es vermutlich mehr sinn die Daten zu packen. Hätte ich nur begrenzt Speicher zur verfügung würde ich beispielsweise nur so viele Bits verwenden wir ich wirklich brauche. Dadurch kämen halt dann auch Daten zustande die man im Hexeditor nicht so gut sehen würde. Leider nützen die hier hinterlegten Dumps nicht viel ohne zu wissen was für Werte real rauskommen müssten.
Ergänzung: Also die Hauptverarbeitung des Streams übernimmt wohl libDataProcessing.so . (vermutlich in der Methode "Java_com_abbottdiabetescare_flashglucose_sensorabstractionservice_dataprocessing_DataProcessingNative_processStream") Allerdings ist die Datei ziemlich gut mit obfuscation geschützt. Selbst mit Disassembler wie IDA kommt man da nicht weit. Vermutlich wird das modul erst während des ladens/während der Ausführung "lesbar".
Frage mich allerdings wozu der ganze Aufwand überhaupt betrieben wird ... Kommt mir persönlich etwas spanisch vor.
Noch eine Ergänzung: Das mit dem lesbaren disassembly hab ich mit einem Dump jetzt hinbekommen. Leider wird man trotzdem nicht ganz schlau aus der Prozedur. Hatte gehofft das dort nur ein einzelnes xor-stattfindet ... Fakt ist dort finden mehrere xor-Operationen statt, hier ein kleiner Ausschnitt:
...
movl $0x9eb98ce7,0xc(%esp)
movl $0x7abd8c41,0x14(%esp)
movl $0xaa8e4421,0x10(%esp)
movl $0x0,0x1c(%esp)
...
movl $0xbcc908df,0xc(%esp)
...
xor $0x12d0823a,%ecx
...
xor $0xa4cb1043,%eax
...
xor $0x433fc422,%ebx
...Und so weiter ... zu den Konstanten(0x9eb98ce7,...) wird man im Internet auch nicht fündig. Ist wohl eine Verschlüsslung Marke Eigenbau :-(
Die Werte selbst scheinen auch willkürlich zu sein. Evl. hat jemand anderes eine Idee was das sein könnte.
Ich hab irgendwo gelesen, dass die Daten nun verschlüsselt sind. Es muss aber eine einfache Verschlüsselung sein, da sie offensichtlich jede Minute, also über 20.000 mal pro Sensor, durchgeführt wird und der Stromverbrauch sicher relevant ist. Außerdem gehe ich davon aus, dass der Schlüssel mit übertragen wird. Die Frage ist nun wo steht der Schlüssel und welche Verschlüsselung wird genutzt. Als Arbeitshypothese würde ich erstmal von einer einfachen XOR-Verschlüsselung ausgehen und das der Schlüssel am Anfang oder am Ende steht. Wahrscheinlich eher am Ende. Die Blöcke ab Zeile 26 sehen seltsam aus. Wenn es das nicht ist, wird es schwer.