Vor ziemlich genau 20 Jahren habe ich in einem Unternehmen gearbeitet, in dem Teile einer eigens entwickelten Lösung eine Zeit lang auf einem DALLAS DS80C400 basierten.
Der DALLAS DS80C400 ist ein hochintegrierter, netzwerkfähiger Mikrocontroller, der auf der Architektur des klassischen 8051 basiert. Entwickelt wurde er von Dallas Semiconductor (später Maxim Integrated) und war besonders für eingebettete Systeme geeignet, die eine Ethernet-Konnektivität benötigten.
Ja, klingt nicht weiter spannend, ich weiß – aber wir schreiben ja auch das Jahr 2025 und nicht 2005. Viele werden sich erinnern, dass der Raspberry Pi (Model B) im Februar 2012 veröffentlicht wurde. Arduino gab es zwar bereits seit 2005, aber ein einfach nutzbares TCP/IP-Netzwerk? Das war damals noch nicht so selbstverständlich. Der DS80C400 war mit seinem integrierten Netzwerkstack also ein ziemlich guter Mikrocontroller seiner Zeit.
Ich hatte ihn damals fertig montiert auf den Entwicklerboards von MAXIM in den Fingern. Das DSTINIM400 Embedded-Modul hatte 1 MB Flash, 1 MB SRAM, konnte 10/100 Mbit/s Ethernet, hatte zwei serielle RS232-Schnittstellen und noch ein paar andere nette Features. Dieses Modul steckte dann auf einem DSTINIS400, das – na ja, nennen wir es Hostboard – also eine Platine, die das DSTINIM400 aufnimmt und die verschiedenen Schnittstellen bereitstellt (Maxim TINI s400 Evaluation Board Socket).
Genau so ein Teil habe ich nun beim Aufräumen meiner „da muss ich noch mal nachschauen“-Elektronikkiste gefunden. Wirklich etwas damit tun wollte ich nicht, aber aus nostalgischen Gründen wollte ich es zumindest einmal booten sehen. Meine Erinnerung daran, wie das alles genau funktionierte, ist allerdings ziemlich verblasst. Irgendwas war da mit einer der beiden RS232-Schnittstellen und einem Terminalprogramm … also los.
Die mit Loader – Serial 0 beschriftete RS232-Schnittstelle war es, meine ich. Also habe ich mein Breakout-Board angeschlossen und ein bisschen herumgemessen. Sah soweit richtig aus – zumindest zeigte mein Oszilloskop beim Booten Aktivität auf den Datenleitungen. Die Pin-Belegung ist 1:1.
DSTINIm400 (DB9, DCE)
PC (DB9, DTE)
Funktion
2 (TXD)
2 (RXD)
Senden → Empfangen
3 (RXD)
3 (TXD)
Empfangen ← Senden
5 (GND)
5 (GND)
Gemeinsame Masse
Die Konfiguration der RS232 ist 9600 Baud, also 9,6 kbps. Dann noch 8N1:
8 Datenbits (8 Bits pro Zeichen)
N Paritätsbit (keine Parität)
1 Stoppbit
Da wirklich nur diese drei Leitungen benötigt werden, habe ich den Rest direkt beim Aufruf meiner Terminalemulation deaktiviert:
screen /dev/ttyUSB1 9600,cs8,-dtr,-rts
Hm … es passiert etwas, aber leider kommt nur Zeichensalat. Das spricht eher dafür, dass ich eine falsche Baudrate eingestellt habe. Also habe ich unterschiedliche Geschwindigkeiten ausprobiert – leider mit mehr oder weniger dem gleichen Ergebnis.
Vielleicht ist das auch der Grund, warum das Teil überhaupt in dieser Kiste gelandet ist?!
Ich wollte schon aufgeben, da fiel mir auf der Rückseite etwas auf: Ein MAX560CAI, ein Low-Dropout-Voltage-Regulator. In seiner direkten Nachbarschaft fehlen zwei Kondensatoren – C33 und C34. Klingt so, als wenn dort ein Keramik- oder Tantal-Kondensator für 10V und irgendwas zwischen 1 µF bis 10 µF hingehört. Und das könnte durchaus problematisch sein, denn einige Leitungen führen direkt bis zur RS232-Schnittstelle.
Um die richtigen Werte für die Kondensatoren zu finden, musste ich dann doch ein bisschen im Internet suchen. Dabei bin ich zumindest schon mal auf ein paar PDFs gestoßen, die ich hier mit euch teilen möchte.
Im DSTINIS-005-DSTINIS400.pdf bin ich dann zum Glück fündig geworden:
C10, C31, C32, C34-C36 → 1 µF
C33 → 10 nF
Passende SMD-Bauteile hatte ich zwar nicht (nicht gefunden), aber THT sollte für einen Test reichen. Für C33 habe ich einfach ebenfalls einen 1 µF-Kondensator genommen – das war mir passend genug für einen Versuch.
Noch ein Test mit 115200 Baud und … ha, er bootet! 😃
TINI Slush OS v1.17 – man, man, man … lange nicht gesehen!
Vor Kurzem habe ich einen Vulnerability Report erhalten. Ich freue mich natürlich immer über solche Hinweise – sie helfen mir, zu wachsen und mein Setup zu verbessern, bevor jemand eine Schwachstelle tatsächlich ausnutzt.
Der Report lautet wie folgt:
Subject: Vulnerability Report: Vulnerable System Detected at openpgpkey.kernel-error.com
Hello Team,
I have identified a security issue in your system related to a vulnerability (CVE-2023-48795) in Terrapin.
Description: A security vulnerability (CVE-2023-48795) related to Terrapin has been detected in your system. This vulnerability could be exploited to compromise your system's security. Please see the details below for more information.
Impact: Impact: 1. Potential for Unauthorized Access: Attackers may exploit this vulnerability to gain unauthorized access. 2. System Compromise: Vulnerable systems could be compromised, leading to data loss or further attacks. 3. Increased Attack Surface: Exposing systems with this vulnerability increases the risk of exploitation.
Recommendation: Recommendation: 1. Apply patches for CVE-2023-48795: Ensure your systems are updated to address this vulnerability. 2. Conduct a Security Review: Regularly review and update your security policies and procedures. 3. Monitor for Suspicious Activity: Implement continuous monitoring to detect any potential exploitation attempts. 4. Restrict Access: Limit access to systems vulnerable to exploitation.
Best Regards, Security Team
Ich war mir eigentlich sicher, dass ich Terrapin schon vor langer Zeit überall gepatcht und in den SSH-Konfigurationen berücksichtigt hatte.
Dann kam der Hinweis auf openpgpkey.kernel-error.com. Die Domain existiert als CNAME und gehört zur Web Key Directory (WKD), was im Groben dazu dient, öffentliche GPG-Keys möglichst automatisiert abrufen zu können. Wenn mir also jemand eine Mail schreiben möchte, aber meinen öffentlichen Key nicht hat, kann er diesen einfach über WKD beziehen. Ich habe das Ganze als CNAME zu wkd.keys.openpgp.org angelegt, weil dieser Keyserver zumindest eine E-Mail-Validierung beim Hochladen öffentlicher Schlüssel durchführt. Ich muss ja nicht jede Infrastruktur selbst betreiben.
Allerdings gehört der betroffene SSH-Server und das gesamte Zielsystem somit gar nicht zu meiner Infrastruktur – ich kann also selbst nichts tun.
Vulnerability Type: JavaScript
Das verstehe ich nicht ganz. Vermutlich hat der Finder einfach sein Standard-Template benutzt und nicht angepasst?! Aber zumindest wollte ich prüfen, ob seine Einschätzung zum SSH-Server überhaupt zutrifft:
# general
(gen) banner: SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u3
(gen) software: OpenSSH 8.4p1
(gen) compatibility: OpenSSH 7.4+, Dropbear SSH 2018.76+
(gen) compression: enabled (zlib@openssh.com)
# security
(cve) CVE-2021-41617 -- (CVSSv2: 7.0) privilege escalation via supplemental groups
(cve) CVE-2016-20012 -- (CVSSv2: 5.3) enumerate usernames via challenge response
# key exchange algorithms
(kex) curve25519-sha256 -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76
`- [info] default key exchange since OpenSSH 6.4
(kex) curve25519-sha256@libssh.org -- [info] available since OpenSSH 6.4, Dropbear SSH 2013.62
`- [info] default key exchange since OpenSSH 6.4
(kex) ecdh-sha2-nistp256 -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
`- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp384 -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
`- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp521 -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
`- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) diffie-hellman-group-exchange-sha256 (3072-bit) -- [info] available since OpenSSH 4.4
`- [info] OpenSSH's GEX fallback mechanism was triggered during testing. Very old SSH clients will still be able to create connections using a 2048-bit modulus, though modern clients will use 3072. This can only be disabled by recompiling the code (see https://github.com/openssh/openssh-portable/blob/V_9_4/dh.c#L477).
(kex) diffie-hellman-group16-sha512 -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) diffie-hellman-group18-sha512 -- [info] available since OpenSSH 7.3
(kex) diffie-hellman-group14-sha256 -- [warn] 2048-bit modulus only provides 112-bits of symmetric strength
`- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) kex-strict-s-v00@openssh.com -- [info] pseudo-algorithm that denotes the peer supports a stricter key exchange method as a counter-measure to the Terrapin attack (CVE-2023-48795)
# host-key algorithms
(key) rsa-sha2-512 (2048-bit) -- [warn] 2048-bit modulus only provides 112-bits of symmetric strength
`- [info] available since OpenSSH 7.2
(key) rsa-sha2-256 (2048-bit) -- [warn] 2048-bit modulus only provides 112-bits of symmetric strength
`- [info] available since OpenSSH 7.2
(key) ssh-rsa (2048-bit) -- [fail] using broken SHA-1 hash algorithm
`- [warn] 2048-bit modulus only provides 112-bits of symmetric strength
`- [info] available since OpenSSH 2.5.0, Dropbear SSH 0.28
`- [info] deprecated in OpenSSH 8.8: https://www.openssh.com/txt/release-8.8
(key) ecdsa-sha2-nistp256 -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
`- [warn] using weak random number generator could reveal the key
`- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(key) ssh-ed25519 -- [info] available since OpenSSH 6.5
# encryption algorithms (ciphers)
(enc) chacha20-poly1305@openssh.com -- [info] available since OpenSSH 6.5
`- [info] default cipher since OpenSSH 6.9
(enc) aes128-ctr -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes192-ctr -- [info] available since OpenSSH 3.7
(enc) aes256-ctr -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes128-gcm@openssh.com -- [info] available since OpenSSH 6.2
(enc) aes256-gcm@openssh.com -- [info] available since OpenSSH 6.2
# message authentication code algorithms
(mac) umac-64-etm@openssh.com -- [warn] using small 64-bit tag size
`- [info] available since OpenSSH 6.2
(mac) umac-128-etm@openssh.com -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-256-etm@openssh.com -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-512-etm@openssh.com -- [info] available since OpenSSH 6.2
(mac) hmac-sha1-etm@openssh.com -- [fail] using broken SHA-1 hash algorithm
`- [info] available since OpenSSH 6.2
(mac) umac-64@openssh.com -- [warn] using encrypt-and-MAC mode
`- [warn] using small 64-bit tag size
`- [info] available since OpenSSH 4.7
(mac) umac-128@openssh.com -- [warn] using encrypt-and-MAC mode
`- [info] available since OpenSSH 6.2
(mac) hmac-sha2-256 -- [warn] using encrypt-and-MAC mode
`- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56
(mac) hmac-sha2-512 -- [warn] using encrypt-and-MAC mode
`- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56
(mac) hmac-sha1 -- [fail] using broken SHA-1 hash algorithm
`- [warn] using encrypt-and-MAC mode
`- [info] available since OpenSSH 2.1.0, Dropbear SSH 0.28
# fingerprints
(fin) ssh-ed25519: SHA256:vwCCSg+OuRwAflHQs/+Y22UJ7p2lM57vbukGFt5AAaY
(fin) ssh-rsa: SHA256:o+WUM9bAmH2G5xMAsJfZRsmh8hvMoU4dx9gdmahLM+M
# algorithm recommendations (for OpenSSH 8.4)
(rec) -ecdh-sha2-nistp256 -- kex algorithm to remove
(rec) -ecdh-sha2-nistp384 -- kex algorithm to remove
(rec) -ecdh-sha2-nistp521 -- kex algorithm to remove
(rec) -ecdsa-sha2-nistp256 -- key algorithm to remove
(rec) -hmac-sha1 -- mac algorithm to remove
(rec) -hmac-sha1-etm@openssh.com -- mac algorithm to remove
(rec) -ssh-rsa -- key algorithm to remove
(rec) !rsa-sha2-256 -- key algorithm to change (increase modulus size to 3072 bits or larger)
(rec) !rsa-sha2-512 -- key algorithm to change (increase modulus size to 3072 bits or larger)
(rec) -diffie-hellman-group14-sha256 -- kex algorithm to remove
(rec) -hmac-sha2-256 -- mac algorithm to remove
(rec) -hmac-sha2-512 -- mac algorithm to remove
(rec) -umac-128@openssh.com -- mac algorithm to remove
(rec) -umac-64-etm@openssh.com -- mac algorithm to remove
(rec) -umac-64@openssh.com -- mac algorithm to remove
# additional info
(nfo) For hardening guides on common OSes, please see: <https://www.ssh-audit.com/hardening_guides.html>
(nfo) Be aware that, while this target properly supports the strict key exchange method (via the kex-strict-?-v00@openssh.com marker) needed to protect against the Terrapin vulnerability (CVE-2023-48795), all peers must also support this feature as well, otherwise the vulnerability will still be present. The following algorithms would allow an unpatched peer to create vulnerable SSH channels with this target: chacha20-poly1305@openssh.com. If any CBC ciphers are in this list, you may remove them while leaving the *-etm@openssh.com MACs in place; these MACs are fine while paired with non-CBC cipher types.
Joar, das sieht tatsächlich nicht ganz so optimal aus. Ein Hinweis darauf ist also nicht unberechtigt. Ich habe dem Finder also freundlich und dankbar geantwortet, aber auch darauf hingewiesen, dass das System nicht zu meiner Infrastruktur gehört. Zusätzlich habe ich ihm die relevanten Whois-Informationen zur IPv4 des angegebenen Hosts mitgeschickt.
Seine Antwort hat nicht lange auf sich warten lassen:
Thank you for your answer.
Let me know if you need anything else from myside
I hope this type of hard efforts deserves something reward
Hm… „hard efforts“. Ich will das jetzt nicht schlechtreden. Wäre der Hinweis im beruflichen Umfeld angekommen, hätte ich mich vielleicht sogar für eine Kleinigkeit stark gemacht. Aber da es hier nur um meine private Infrastruktur geht – und dann noch mit dem JavaScript-Hinweis und der Meldung zu einem fremden System – wirkt das Ganze doch etwas oberflächlich. Also habe ich ihn freundlich darauf hingewiesen.
Mein Tipp für den Umgang mit solchen Meldungen
Wenn euch mal eine solche Nachricht erreicht: Schnell und freundlich reagieren! Den Report ernst nehmen, bewerten und eine angemessene Rückmeldung geben. Die Mühe des Finders sollte wertgeschätzt werden. Zwei Wochen später mit „Anzeige ist raus!“ zu antworten, wäre der falsche Weg. Denn ganz ehrlich: Es ist für jemanden deutlich aufwendiger, sich die Mühe zu machen, eine Meldung zu schreiben, als einfach das Ganze in ein passendes Darknet-Forum zu posten und dort ein paar XMR oder Bitcoin einzusammeln.
Macht es den Leuten also möglichst einfach, euch zu kontaktieren. Eine security.txt oder klare Kontaktinformationen für eine Security-Mailbox helfen ungemein. Hauptsache, jemand kann seinen Report unkompliziert abgeben – und er wird von jemandem gelesen, der das Ganze bewerten kann.
Meine SSH Konfiguration sieht von außen wie folgt aus:
# general
(gen) banner: SSH-2.0-OpenSSH_9.7 DemMeisterSeinRennAuto
(gen) software: OpenSSH 9.7
(gen) compatibility: OpenSSH 8.5+, Dropbear SSH 2018.76+
(gen) compression: enabled (zlib@openssh.com)
# key exchange algorithms
(kex) sntrup761x25519-sha512@openssh.com -- [info] available since OpenSSH 8.5
(kex) curve25519-sha256 -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76
`- [info] default key exchange since OpenSSH 6.4
(kex) curve25519-sha256@libssh.org -- [info] available since OpenSSH 6.4, Dropbear SSH 2013.62
`- [info] default key exchange since OpenSSH 6.4
(kex) diffie-hellman-group16-sha512 -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) diffie-hellman-group18-sha512 -- [info] available since OpenSSH 7.3
(kex) diffie-hellman-group-exchange-sha256 (3072-bit) -- [info] available since OpenSSH 4.4
`- [info] OpenSSH's GEX fallback mechanism was triggered during testing. Very old SSH clients will still be able to create connections using a 2048-bit modulus, though modern clients will use 3072. This can only be disabled by recompiling the code (see https://github.com/openssh/openssh-portable/blob/V_9_4/dh.c#L477).
(kex) ext-info-s -- [info] pseudo-algorithm that denotes the peer supports RFC8308 extensions
(kex) kex-strict-s-v00@openssh.com -- [info] pseudo-algorithm that denotes the peer supports a stricter key exchange method as a counter-measure to the Terrapin attack (CVE-2023-48795)
# host-key algorithms
(key) ssh-ed25519 -- [info] available since OpenSSH 6.5
# encryption algorithms (ciphers)
(enc) aes256-gcm@openssh.com -- [info] available since OpenSSH 6.2
(enc) aes128-gcm@openssh.com -- [info] available since OpenSSH 6.2
(enc) aes256-ctr -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes192-ctr -- [info] available since OpenSSH 3.7
(enc) aes128-ctr -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
# message authentication code algorithms
(mac) hmac-sha2-256-etm@openssh.com -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-512-etm@openssh.com -- [info] available since OpenSSH 6.2
(mac) umac-128-etm@openssh.com -- [info] available since OpenSSH 6.2
# fingerprints
(fin) ssh-ed25519: SHA256:kPRXNCMRLiHfvJunW2CbW5H3NZmn3Wkx2KnHJXl1aLc
# algorithm recommendations (for OpenSSH 9.7)
(rec) +rsa-sha2-256 -- key algorithm to append
(rec) +rsa-sha2-512 -- key algorithm to append
Seit inzwischen knapp 10 Jahren nutze ich das Magenta SmartHome-System. Eine der wirklich praktischen Funktionen ist „Lüften“.
Sobald ein Tür- oder Fensterkontakt signalisiert, dass er geöffnet ist, wird ein Signal an die Heizungsventile gesendet, damit diese schließen. Gerade mit Kindern im Haushalt ist das eine tolle Funktion, denn so heize ich nicht versehentlich durch ein offenes Fenster oder gleich die ganze Terrasse.
Diese Funktion findest du in der SmartHome-App unter: Mehr → Heizung → Overflow-Menü → Einstellungen → Sensoren konfigurieren. Dort kannst du für jeden Raum die Kontakte auswählen, die für die Funktion genutzt werden sollen.
Vor knapp zwei Jahren ist mir in der Winterzeit aufgefallen, dass ein ausgetauschter Sensor zwar einwandfrei funktionierte, aber von der „Lüften“-Funktion komplett ignoriert wurde. Also habe ich im Menü nachgeschaut: Der Sensor wurde als nicht ausgewählt angezeigt (grauer Haken oben rechts auf der Kachel). Ich wählte ihn aus, bestätigte mit dem Haken, wechselte erneut ins Menü „Sensoren konfigurieren“ – und der Sensor war wieder nicht ausgewählt. Ein endloser Kreislauf.
Zuerst dachte ich, das Problem liegt vielleicht an meinem Smartphone. Doch auch auf dem Gerät meiner Frau zeigte sich derselbe Fehler. Also: App deinstallieren, neu installieren. Leider ohne Erfolg.
Daraufhin kontaktierte ich den Magenta SmartHome-Support und schilderte mein Problem. Die Antwort kam nach ein paar Tagen: Ein alter Sensor blockiere wohl die Funktion. Als Lösung schlug man vor, die komplette SmartHome-App von der Zentrale zu löschen und alles neu einzurichten. Das hätte bedeutet, dass meine gesamte Konfiguration, alle Regeln und Szenen verloren gehen – und ich jedes Gerät neu anlernen müsste.
Da ich zahlreiche Geräte im Einsatz habe, war das für mich keine Option. Also entschied ich mich, abzuwarten. Schließlich war ich nicht der Einzige mit diesem Problem, und früher oder später würde es sicher eine Lösung geben.
Nun ist wieder Winter, und das Problem besteht weiterhin. Also wandte ich mich erneut an den Support, in der Hoffnung auf eine bessere Lösung. Diesmal bekam ich folgende Antwort:
Das Problem ist hier, dass noch ein alter bereits abgelernter Tür-Fensterkontakt in der Lüften Einstellung fest hängt.
Erkennen kann man dies in der Android App bei der Auswahl der Tür-Fensterkontakte. Hier wird oben in der Titelzeile die Anzahl der ausgewählten Geräte angezeigt.
Ist die Zahl hier höher, als die sichtbar ausgewählten Tür-Fensterkontakte, so ist der Kunde von diesem Problem betroffen.
Unter iOS wird die Anzahl der ausgewählten Tür-Fensterkontakte nicht angezeigt.
Update 08.01.2025: Es wird noch ein weiteres Magenta SmartHome App Release mit Fehlerbehebungen geben. Es ist geplant, dass der Fehler dort behoben wird.
Workaround 1: Da der Fehler nur in der Android App auftritt, kann man das Problem mit der iOS App lösen. Mit der iOS App reicht es einen Tür-Fensterkontakt abzuwählen und zu speichern.
Danach lassen sich die aktuell angelernten Tür-Fensterkontakte wieder wie gewohnt auswählen/abwählen und auch speichern. Auch in der Android App.
Sofern der Kunde also ein iOS Gerät hat, ist dieser Workaround dem Workaround 2 zu bevorzugen.
Workaround 2: Das Plugin vom 3rd Level löschen lassen. Hier muss der Kunde dann jedoch alle Einstellungen, die er in der App vorgenommen hat, wieder neu Einrichten.
Regeln, Szenen, Heizkurve, Übersichten ... alles. Insofern fragt bitte den Kunden bevor ihr ein 3rd Level Ticket erstellt, ob er mit dieser Löschung einverstanden ist.
Workaround 2 war für mich weiterhin keine Option. Aber Workaround 1 klang vielversprechend – ein iOS-Gerät hatte ich noch im Regal. Also installierte ich die App, ging ins Menü „Sensoren konfigurieren“, wählte die gewünschten Sensoren aus – und siehe da: Es funktionierte! Seitdem läuft die Funktion auch wieder einwandfrei unter Android.
Man stelle sich vor, ich hätte tatsächlich den aufwendigeren Workaround 2 gewählt, nur um später herauszufinden, dass ein einmaliger Abstecher in die iOS-App genügt hätte.
Vielleicht rettet diese Info ja jemanden vor unnötigem Aufwand 😉 Laut Support soll das Problem mit einem zukünftigen Update behoben werden.
Die meisten von euch werden das Spiel GeoGuessr kennen. Man bekommt ein Google-Street-View-Bild gezeigt, kann sich vielleicht noch ein paar Meter hin- und herbewegen und muss dann auf einer Weltkarte einen Marker setzen, wo man meint, dass dieses Bild aufgenommen wurde. Wer dem Punkt am nächsten kommt, gewinnt.
Eine etwas abgewandelte Version begegnet mir immer mal wieder, wenn ich mich an einem Bug-Bounty-Programm beteilige oder einfach mit offenen Augen durchs Internet spaziere. Damit ist natürlich kein aktives Port-Scanning auf Netzblöcke oder Ähnliches gemeint.
Worum geht es genau?
In den letzten Jahren verbreiten sich immer mehr billige „China-Kameras“ bei Heimanwendern, aber auch bei Unternehmen. Dagegen spricht erst einmal nichts.
Was leider oft übersehen wird, sind die kleinen automatischen Helferlein, die die Einrichtung und den Betrieb einer solchen Kamera möglichst einfach machen sollen. UPnP (Universal Plug and Play) haben manche vielleicht schon mal im Zusammenhang mit Windows 95 oder USB gehört (ja, ich bin alt …). So etwas gibt es aber auch für Router und Firewalls, also für Netzwerke. Bei einer Fritzbox nennt sich das beispielsweise „Automatische Portfreigabe“.
Der eine oder andere ahnt jetzt sicher schon etwas: Es gibt IP-Kameras, die sich so – vielleicht sogar ohne das Wissen des Betreibers – selbst über das Internet erreichbar machen. Das betrifft nicht selten die komplette Weboberfläche. Mal ist diese kennwortgeschützt, mal nicht.
Sehr oft findet sich auch nur der RTSP-Port (Real Time Streaming Protocol) offen im Internet. Per RTSP werfen solche Kameras oft einen einfachen Videostream aus, der die Anbindung an zentrale Videoüberwachungssysteme erlaubt. Auch RTSP-Streams lassen sich mit einer Anmeldung schützen, was aber scheinbar in der Regel werkseitig deaktiviert ist.
Wenn dieser Port offen ist, könnte man sich einfach per ffplay einen solchen Stream anschauen:
ffplay rtsp://1.2.3.4/11
Wenn man sich nicht sicher ist, wie die korrekte RTSP-URL für die jeweilige IP-Kamera lautet, kann nmap zusammen mit dem Script rtsp-url-brutehelfen:
nmap --script rtsp-url-brute -p 554 1.2.3.4
Die rechtliche Lage
Nun kann es natürlich rechtlich schwierig sein, bei einer fremden IP-Adresse nach dem offenen Port 554/TCP zu suchen, dort per nmap nach einer nutzbaren RTSP-URL zu scannen und sich den Stream dann live per ffplay, nmap oder vlc anzuschauen. Schließlich hat man nicht das Einverständnis des Betreibers.
Natürlich hält das wohl weniger Menschen ab, die ohnehin Schlechtes im Sinn haben. Ebenfalls gibt es verschiedene Dienste, die 24/7 nichts anderes tun. Ein Beispiel ist hier vielleicht shodan.io – dort lässt sich direkt nach solchen Vorschaubildern filtern, ohne dass man selbst eine Verbindung zu betroffenen IPs aufnehmen muss.
Warum ist das alles überhaupt problematisch?
Hat ein Angreifer Böses im Sinn, ist ein Zugriff auf die Überwachungskamera sehr hilfreich. Man kommt so möglicherweise an Insiderinformationen, findet heraus, wo wertvolle Dinge gelagert werden, wann und wie die Öffnungszeiten sind oder sogar mögliche Zugangscodes und Kennwörter. Natürlich auch, welche Kunden sich zu welcher Zeit dort aufhalten usw.
Denkt man an eine Arztpraxis, kann das schnell eine echte Datenschutzkatastrophe werden. Wenn die Kamera im Wohnzimmer oder Schlafzimmer einer Wohnung steht, führt das ebenfalls schnell zu ungewollten Einblicken.
Wenn man einmal außer Acht lässt, dass niemand gerne ohne sein Wissen per Livestream im Internet zu sehen ist, halte ich das Thema Datenschutz für eines der größten Risiken.
In der Vergangenheit sind mir bereits Beispiele begegnet, die das Problem verdeutlichen: Arztpraxen mit Kamerablick von hinten auf die Anmeldung – inklusive direktem Blick auf Patienten, Monitore mit Patientendaten oder Vertragsabschlüsse bei Mobilfunkanbietern. Auch Überwachungskameras in DHL-Filialen, die Bild und Ton in Zoom und 4K aufzeichnen, habe ich gesehen.
Für private Betreiber kann es ebenfalls schnell zu einem Datenschutzproblem werden. Nicht jeder achtet beim eingestellten Bildausschnitt der Kamera darauf, die Vorgaben des Datenschutzes einzuhalten. So werden oft mehr öffentliche Bereiche oder sogar Nachbargrundstücke gefilmt, als zulässig ist.
Wenn diese Daten dann auch noch ohne Schutz und Hürden in die Hände Dritter geraten, wird es heikel. Hier sollte besser jemand mit rechtlichem Hintergrund eine Einschätzung abgeben. Für mich klingt das alles jedenfalls ziemlich unschön.
Was kann man tun?
Eine Abuse-Mail an den jeweiligen ISP (Internet Service Provider) schicken, mit der Bitte, ihre Kunden zu informieren? Kann man machen. Bei kleineren ISPs klappt das oft sogar, und die Betreiber werden informiert. Spricht man aber über einen großen ISP wie die Telekom, verschwinden einzelne Abuse-Mails gefühlt einfach im Nichts.
Sonst jemanden zu finden, der ein Interesse daran hat, den meist unwissenden Betreiber zu informieren, ist nahezu unmöglich. Weder unsere Behörden noch das BSI interessieren sich dafür. Möchte man also den Betreiber darauf hinweisen, bleibt realistisch nur die Möglichkeit, ihn selbst zu kontaktieren.
GeoGuessr in der Praxis
Jetzt sind wir beim Thema GeoGuessr: Man hat also nur das Bild der Kamera, die IP-Adresse mit einer recht groben und nicht immer stimmigen Geolokalisierung und vielleicht noch ein paar weitere Rahmeninfos oder Dienste auf dieser IP-Adresse. Hin und wieder macht es mir daher sogar Spaß, den eigentlichen Betreiber ausfindig zu machen und ihm per E-Mail oder telefonisch kurz auf diesen möglichen Missstand hinzuweisen.
Wenn du das also gerade liest, weil ich dich darauf hingewiesen habe, weißt du jetzt, warum 😀
Natürlich trifft man oft auf Unverständnis – oder das klassisch deutsche „Anzeige ist raus!“ begegnet einem immer mal wieder. Es bietet also auch eine gute Möglichkeit, die eigenen Kommunikationsskills zu erweitern.
Heute möchte ich euch eine kleine Geschichte zu meinem Milchkühlschrank erzählen. Ob das spannend wird? Na, da bin ich mir noch nicht so sicher.
In meiner Küche steht so ein Kaffeevollautomat – einfach wegen lecker Kaffee und so. Dieser ist, bei angeschlossener Milch, auch in der Lage, die gängigen Milchkaffeegetränke (nennt man das so?) auf Knopfdruck zuzubereiten. Also alles top. Nun trinke ich, vor allem wenn ich im Homeoffice sitze, schon mal einen Kaffee mehr. Da räume ich natürlich nicht für jeden Kaffee die Milch raus und wieder rein. Damit die Milch mehr als einen halben Tag überlebt, braucht sie etwas Kühlung. Genau an dieser Stelle kommt ein Milchkühlschrank ins Spiel.
In der Regel basieren solche kleinen Kühlschränke oder Kühlboxen auf einem einfachen thermoelektrischen Kühler namens Peltierelement. Ein solches Peltier-Modul funktioniert recht simpel. Meistens ist es ein kleines, flaches Quadrat mit zwei Leitungen. Schließt man die passende Stromversorgung an, wird eine der beiden Seiten warm und die andere kalt. Das Modul sorgt also dafür, dass es eine Temperaturdifferenz zwischen beiden Seiten gibt.
Sagen wir einfach mal, das Modul erzeugt immer eine Temperaturdifferenz von 30°C. Bei einer Raumtemperatur von 20°C wäre die eine Seite also bei 20°C und die andere bei -10°C. Gut, das ist nur die halbe Wahrheit, denn die heiße Seite wird im Betrieb wärmer, weil dort zwei Wärmequellen zusammenkommen:
Wärmeübertragung von der kalten Seite (Peltier-Effekt): Der Peltier-Effekt transportiert Wärme von der kalten zur heißen Seite, wenn ein Strom durch das Modul fließt. Diese transportierte Wärme wird an der heißen Seite freigesetzt.
Joulesche Verlustwärme (Widerstandserwärmung): Beim Fließen des elektrischen Stroms durch die Halbleiterelemente des Peltier-Moduls entsteht aufgrund des elektrischen Widerstands zusätzliche Wärme (Joule-Effekt). Diese Wärme erhöht ebenfalls die Temperatur der heißen Seite.
Kurz gesagt: Man muss die heiße Seite kühlen, damit die kalte Seite auch wirklich kalt wird. Diese wird allerdings nicht unendlich kalt, da wir nur einen Temperaturunterschied erzeugen können. Die Kühlung der heißen Seite ist also sehr wichtig. Dieses Wissen wird später noch hilfreich sein, also bitte kurz merken.
Zurück zum Milchkühlschrank. Wie funktioniert dieser nun? Um das besser erklären zu können, habe ich euch eine kleine Zeichnung angefertigt:
Die dicke schwarze Linie an der Innenseite der Schaumstoffdämmung stellt eine Metallplatte dar, die die Innenseite des Kühlschranks bildet. Diese ist mit etwas Wärmeleitpaste (für bessere Temperaturübertragung) mit dem Aluminiumblock verbunden. Im Aluminiumblock befinden sich Temperaturfühler, die dafür sorgen, dass das Peltier-Modul bei der gewünschten Temperatur abgeschaltet wird. Die kalte Seite des Moduls ist ebenfalls mit Wärmeleitpaste am Aluminiumblock befestigt, während die heiße Seite mit einem großen Kühlkörper verbunden ist. Dieser Kühlkörper vergrößert die Oberfläche der heißen Seite, sodass die Wärme besser an die Umgebungsluft abgegeben werden kann. Meist ist zusätzlich ein kleiner Lüfter verbaut, der aktiv Luft zuführt.
Mit diesem Wissen können wir nun alle selbst einen Milchkühlschrank oder eine kleine Kühlbox bauen. Ein oft verwendetes Peltier-Modul ist das TEC1-12706, das man im Doppelpack für ca. 10 € bekommt. Ein einfacher PC-Lüfter kostet etwa 10 €. Für rund 50 € kann man sich so ein Ding zusammenbauen.
Warum ist das wichtig? Nun, weil die Dinger für ca. 150 € verkauft werden. Was auch der Grund ist, warum ich mir nicht einfach einen gekauft habe. Denn, mal ehrlich: Wenn ich das für 50 € bauen kann, dann kostet es in der Massenproduktion in China noch weniger. Ja, ich weiß, ich kaufe ja nicht nur das Gerät, sondern auch die Bequemlichkeit – meine Milch bleibt länger frisch, und ich muss mich nicht kümmern. Aber so einfach ist das für mich nicht zu rechtfertigen. Es widerstrebt mir einfach.
Einen gebrauchten zu kaufen, schien mir da eine Option. Was soll ich sagen? Die Technik, die in solchen Geräten verbaut ist, ist oft billig und nicht auf Langlebigkeit ausgelegt. Von den Geräten, die ich bisher in der Hand hatte, hat keines länger als drei Jahre gehalten. Selbst gebraucht werden sie noch für rund 100 € angeboten. Das ist für mich einfach nicht verhältnismäßig.
Jetzt stand bei meinem Arbeitgeber plötzlich ein defekter Milchkühlschrank beim Elektroschrott. Das kam für mich überraschend. Natürlich habe ich nachgefragt, was mit dem Gerät los ist und ob es okay wäre, wenn ich es „entsorge“. Es war kein Problem, und so hatte ich einen neuen alten, kaputten Milchkühlschrank.
Und was hatte das Ding? Nichts Besonderes. Der Lüfter war gestorben, und die passive Kühlung reichte nicht aus, um das Innere des Kühlschranks ausreichend zu kühlen. Verbaut war ein einfacher 80×80 mm 12V PC-Lüfter. Den hatte ich noch in meiner Ersatzteilkiste. Also: Lüfter getauscht, und zack – schon funktionierte der Kühlschrank wieder. Zumindest bis zum Sommer.
Als die Temperaturen stiegen, wurde es im Kühlschrank nicht mehr richtig kühl, obwohl Lüfter und Peltierelement alles gaben. Ich habe das Gerät wieder aufgeschraubt, weil ich vermutete, dass die Wärmeleitpaste inzwischen hart und trocken war und ausgetauscht werden musste. Der Milchkühlschrank war inzwischen vier, knapp fünf Jahre alt – da kann das schon mal passieren.
War es die Wärmeleitpaste? Ja und nein. Die Paste war zwar trocken, aber das allein war nicht das Problem. Wenn ihr euch meine Zeichnung anschaut, sind euch vielleicht die Befestigungsschrauben (3) aufgefallen. Diese Schrauben sind aus Metall und verbinden den kalten Aluminiumblock direkt mit dem Kühlkörper – also eine klassische thermische Brücke. Das heißt: Ein Teil der Kälte wird direkt wieder in Wärme umgewandelt, weil Metall die Wärme gut leitet.
Das ist … naja, sagen wir mal suboptimal. Es funktioniert irgendwie, aber effizient ist das nicht. Ich habe die Löcher im Kühlkörper daher aufgebohrt und mit meinem 3D-Drucker Kunststoffbuchsen für die Schrauben hergestellt. Diese habe ich zusätzlich mit kleinen Federn versehen, die thermische Brücke ist so unterbrochen und die Felder drücken alles noch zusammen, selbst wenn sich das Aluminium durch die unterschiedlichen Temperaturen ausdehnt bzw. zusammen zieht. Danach war der Kühlschrank deutlich effizienter und verbrauchte spürbar weniger Energie. Warum der Hersteller das nicht von Anfang an so gemacht hat? Tja, irgendwie habe ich nur das Wort „Gewinnmaximierung“ im Kopf.
Das verbaute Netzteil war ebenfalls nur gerade so passend für die benötigte Leistung. Das ist okay, aber wenn ein Netzteil immer bei 90 bis 100 % Belastung arbeitet, gibt es irgendwann auf. Es funktionierte zwar noch, aber die Messwerte waren nicht optimal, und man konnte ihm die jahrelange Arbeit ansehen. Ich hatte noch ein HOUHUI-1206im Regal – ein 12V 6A Gleichstromnetzteil, das ich irgendwann mal bei einem Gerät dabei hatte. Damals wollte ich es nicht einsetzen, weil es so billig aussah. Also lag es herum.
Hätte ich doch mal auf mein früheres Ich gehört! Denn sechs Monate später war der Kühlschrank wieder warm, und die LED am Netzteil war aus. Das Chinanetzteil hatte den Geist aufgegeben.
So langsam bröckelte der WAF (Woman Acceptance Factor). Ich sah mich schon einen neuen Milchkühler kaufen. Also habe ich das Netzteil aufgeschraubt und mal reingeschaut. Überraschung: Die Elektrolytkondensatoren (Elkos) waren aufgebläht – ein klassischer Fehler. Ich habe die Elkos getauscht, und schon funktionierte alles wieder.
Natürlich habe ich den Strombedarf des Kühlschranks gemessen, um sicherzugehen, dass das Netzteil nicht ständig an seiner Leistungsgrenze arbeitet. Ich bin nicht an die Grenze von 6A gekommen, aber trotzdem behalte ich das im Auge. Denn: 12V und 6A bedeuten 72 Watt. Wenn der kleine Milchkühlschrank 24/7 mit 70 Watt läuft, dann ist das auf Dauer auch zu teuer.
So viel also zu meiner Geschichte des Milchkühlschranks. Ob ich am Ende einen neuen kaufe? Vielleicht. Aber bis dahin läuft mein reparierter Milchkühlschrank wieder.
Die Feiertage sind da, und ich hatte tatsächlich etwas Zeit zum Zocken. Früher hatte ich dafür einen eigenen Rechner, heute reicht ein Dual Boot. Gearbeitet wird unter Linux, gezockt unter Windows. Dafür habe ich mein Windows auf einer gesonderten SSD installiert. Natürlich ist diese ebenfalls verschlüsselt, in diesem Fall mit BitLocker.
Warum erzähle ich das? Na, weil die SSD irgendwann aufgegeben hat und ich mein Windows neu installieren darf. Ein Backup spare ich mir, da es eh nur zum Zocken ist.
Windows 11 war „schnell“ wieder installiert. Dann noch alle Treiber usw. – Gott, ist das noch immer alles aufwendig… Wie auch immer: Windows 11 und die Games sind drauf. Los geht’s!
Nun fragt mich mein BitLocker bei jedem Start der Betriebssystemfestplatte nach dem BitLocker-Wiederherstellungsschlüssel, wenn ich vorher in meinem Linux war. Da zuckt so eine Erinnerung durch mein Hirn: Das gleiche hatte ich schon mal, am gleichen Rechner. Wie hatte ich das damals gelöst? Ich habe nichts darüber geschrieben, also ist es einfach weg. Diesen Fehler mache ich nicht noch mal. Also liest du gerade etwas darüber. 😄
Der Ausgangspunkt: Ein Windows 11 Pro, installiert auf einer SSD, inkl. BitLocker-Verschlüsselung und TPM mit PIN. Warum PIN? Ich fühle mich einfach besser, wenn es noch eine manuelle Hürde zur Entschlüsselung gibt; Ist auch egal, soll ja nun weg.
Terminal als Administrator ausführen und dann:
C:\Windows\System32> manage-bde -status
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.
Datenträgervolumes, die mit BitLocker-Laufwerkverschlüsselung
geschützt werden können:
Volume "C:" [System]
[Betriebssystemvolume]
Größe: 465,00 GB
BitLocker-Version: 2.0
Konvertierungsstatus: Nur verwendeter Speicherplatz ist verschlüsselt
Verschlüsselt (Prozent): 100,0 %
Verschlüsselungsmethode: XTS-AES 128
Schutzstatus: Der Schutz ist aktiviert.
Sperrungsstatus: Entsperrt
ID-Feld: Unbekannt
Schlüsselschutzvorrichtungen:
Numerisches Kennwort
TPM und PIN
TPM
C:\Windows\System32>
Schlüsselschutzvorrichtungen sind also numerisches Kennwort, TPM und PIN, sowie TPM. Was fehlt? Richtig, das Password. Da ich nur das Password möchte, kann im Grunde alles weg. Damit Windows 11 mir erlaubt, TPM von meinem Betriebssystemvolume zu entfernen, muss ich vorher noch eine Gruppenrichtlinie anpassen.
Dafür einfach die Tastenkombination Win + S drücken und nach Gruppenrichtlinie bearbeiten suchen.
Dann zu: Computerkonfiguration ⇒ Administrative Vorlagen ⇒ BitLocker-Laufwerkverschlüsselung ⇒ Betriebssystemlaufwerke ⇒ Zusätzliche Authentifizierung beim Start anfordern.
Hier die Einstellung so ändern, dass der Haken bei „BitLocker ohne kompatibles TPM zulassen“ gesetzt ist.
Im Anschluss sicherstellen, dass die neue Gruppenrichtlinie auch angewendet wird. Dazu im Administrator-Terminal einfach ein kurzes:
PS C:\WINDOWS\system32> gpupdate /force
Die Richtlinie wird aktualisiert...
Die Aktualisierung der Computerrichtlinie wurde erfolgreich abgeschlossen.
Die Aktualisierung der Benutzerrichtlinie wurde erfolgreich abgeschlossen.
PS C:\WINDOWS\system32>
So, jetzt wird’s spannend. Erstmal alle Schlüsselschutzvorrichtungen deaktivieren, dann löschen, die neue Schlüsselschutzvorrichtung Password hinzufügen und alles wieder aktivieren. Das Ganze natürlich im Administrator-Terminal. Ich starte damit, alle Schlüsselschutzvorrichtungen zu deaktivieren:
C:\Windows\System32>manage-bde -protectors -disable C:
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.
Die Schlüsselschutzvorrichtungen für Volume "C:" sind deaktiviert.
Als Nächstes schaue ich nach, welche Schlüsselschutzvorrichtungen auf meinem Betriebssystemvolume eingerichtet sind.
C:\Windows\System32>manage-bde -protectors -get C:
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.
Volume "C:" [System]
Alle Schlüsselschutzvorrichtungen
Numerisches Kennwort:
ID: {AF6C0AAD-B337-4519-8D66-C06386994D97}
Kennwort:
673101-147301-650001-335379-291368-420618-438350-305327
Sicherungstyp:
In Datei gespeichert
TPM und PIN:
ID: {D5F87162-5556-4C27-82F9-25B389DBAF1B}
PCR-Validierungsprofil:
0, 2, 4, 11
TPM:
ID: {CA1BF147-2C40-4934-9161-660FBB44BA2C}
PCR-Validierungsprofil:
0, 2, 4, 11
Jetzt lösche ich alle Schlüsselschutzvorrichtungen anhand ihrer IDs:
C:\Windows\System32>manage-bde -protectors -delete C: -id {D5F87162-5556-4C27-82F9-25B389DBAF1B}
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.
Volume "C:" [System]
Schlüsselschutzvorrichtung mit ID {D5F87162-5556-4C27-82F9-25B389DBAF1B}
TPM und PIN:
ID: {D5F87162-5556-4C27-82F9-25B389DBAF1B}
PCR-Validierungsprofil:
0, 2, 4, 11
Die Schlüsselschutzvorrichtung mit der ID "{D5F87162-5556-4C27-82F9-25B389DBAF1B}" wurde gelöscht.
C:\Windows\System32>manage-bde -protectors -delete C: -id {CA1BF147-2C40-4934-9161-660FBB44BA2C}
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.
Volume "C:" [System]
Schlüsselschutzvorrichtung mit ID {CA1BF147-2C40-4934-9161-660FBB44BA2C}
TPM:
ID: {CA1BF147-2C40-4934-9161-660FBB44BA2C}
PCR-Validierungsprofil:
0, 2, 4, 11
Die Schlüsselschutzvorrichtung mit der ID "{CA1BF147-2C40-4934-9161-660FBB44BA2C}" wurde gelöscht.
C:\Windows\System32>manage-bde -protectors -delete C: -id {AF6C0AAD-B337-4519-8D66-C06386994D97}
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.
Volume "C:" [System]
Schlüsselschutzvorrichtung mit ID {AF6C0AAD-B337-4519-8D66-C06386994D97}
Numerisches Kennwort:
ID: {AF6C0AAD-B337-4519-8D66-C06386994D97}
Kennwort:
673101-147301-650001-335379-291368-420618-438350-305327
Sicherungstyp:
In Datei gespeichert
Die Schlüsselschutzvorrichtung mit der ID "{AF6C0AAD-B337-4519-8D66-C06386994D97}" wurde gelöscht.
Wenn ich jetzt noch einmal kontrolliere, welche Schlüsselschutzvorrichtungen ich habe, sollten dort keine mehr stehen.
C:\Windows\System32>manage-bde -protectors -get C:
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.
Volume "C:" [System]
Alle Schlüsselschutzvorrichtungen
FEHLER: Es wurden keine Schlüsselschutzvorrichtungen gefunden.
Damit kann ich jetzt meine neue, gewünschte Schlüsselschutzvorrichtung Passwort hinzufügen.
C:\Windows\System32>manage-bde -protectors -add C: -password
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.
Geben Sie das Kennwort ein, das zum Schützen des Volumes verwendet werden soll:
Bestätigen Sie das Kennwort durch erneute Eingabe:
Hinzugefügte Schlüsselschutzvorrichtungen:
Kennwort:
ID: {4D141862-4C75-4321-AA6D-8BABB89C601C}
Bleibt nur noch, diese auch zu aktivieren.
C:\Windows\System32>manage-bde -protectors -enable C:
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.
Die Schlüsselschutzvorrichtungen für Volume "C:" sind aktiviert.
Wenn ich jetzt den BitLocker-Status prüfe, ist alles aktiv, und es gibt nur noch die Schlüsselschutzvorrichtung Kennwort / Password!
C:\Windows\System32>manage-bde -status
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.
Datenträgervolumes, die mit BitLocker-Laufwerkverschlüsselung
geschützt werden können:
Volume "C:" [System]
[Betriebssystemvolume]
Größe: 465,00 GB
BitLocker-Version: 2.0
Konvertierungsstatus: Nur verwendeter Speicherplatz ist verschlüsselt
Verschlüsselt (Prozent): 100,0 %
Verschlüsselungsmethode: XTS-AES 128
Schutzstatus: Der Schutz ist aktiviert.
Sperrungsstatus: Entsperrt
ID-Feld: Unbekannt
Schlüsselschutzvorrichtungen:
Kennwort
Starte ich meinen Computer und wähle im Grub Windows aus, werde ich danach nach meinem BitLocker-Kennwort gefragt, und das System fährt sauber hoch.
Heute mal etwas ganz Einfaches… Beim Löten entstehen Dämpfe, die man besser nicht durch den „Lungenfilter“ aus der Luft ziehen sollte.
Hier kommen Lötdampfabsaugung ins Spiel. Es gibt kleine, einfache Modelle für etwa 50 €, die wie ein kleiner Tischventilator in der Nähe stehen, die Dämpfe absaugen und meist durch einen Aktivkohlefilter leiten. Allerdings stehen mir diese Geräte immer im Weg, und die Lüfter sind oft so schwach, dass trotzdem noch ein großer Teil der Dämpfe zu mir gelangt.
Da bei Projekten öfter mal Reste übrig bleiben, liegen in meinem Keller eigentlich schon alle Einzelteile für eine selbstgebaute Lötdampfabsaugung bereit. Man müsste sie nur noch zusammenbauen.
Ich habe noch einen 100-mm-Lüftungsschlauch aus Aluminium, der einigermaßen flexibel ist, einen 120-mm-12V-Lüfter, der für ordentlich Luftstrom sorgt, und ein paar 130-mm-Aktivkohlefilterplatten. Wenn ich davon einfach zwei doppelt nehme, geht mehr als genug Luft durch, und sie filtern die Dämpfe recht gut.
Mit FreeCAD habe ich dann ein Gehäuse für die Teile entworfen, das ich einfach unter meine Werkbank schrauben kann. So liegt nur der Schlauch in einer Ecke und kann bei Bedarf zur richtigen Stelle bewegt werden, um die Löt-Dämpfe direkt an der Quelle abzusaugen.
Hier ein paar Bilder für euch – die Druckdateien findet ihr bei Maker World.
Ob die Teile auch zu euren „Resten“ passen, müsst ihr selbst kurz prüfen.
Einen guten Dokumentenscanner zu finden, der auch noch bezahlbar ist, kann schnell zu einer Herausforderung werden. Viele ältere Geräte verlieren nach kurzer Zeit den Support für das nächste Betriebssystem und funktionieren dann nicht mehr. Wenn der Scanner zusätzlich unter Linux reibungslos laufen soll, wird es noch spannender.
Vor vielen Jahren konnte ich mir günstig einen Fujitsu ScanSnap S1500 zulegen. Dieser Dokumentenscanner erfüllt genau meine Anforderungen: Er zieht mehrere Seiten über den automatischen Dokumenteneinzug (ADF) ein, scannt beidseitig, ist schnell und liefert eine gute Auflösung. Wenn ich ihn nicht brauche, lässt er sich genauso schnell zusammenklappen, wie er sich aufstellen lässt, und nimmt kaum Platz auf meinem ohnehin schon überladenen Schreibtisch ein. Ich nutze den Scanner, um meine Post, Rechnungen und andere wichtige Unterlagen zu digitalisieren. Anfangs lief dies noch über eine Windows-VM, da es lange keine wirklich einfache Software für Linux gab, die auf Knopfdruck Dokumente scannt, Texterkennung (OCR) anwendet und alles als durchsuchbares PDF abspeichert. Dieses PDF wandert dann automatisch in meine Nextcloud und hilft mir, Ordnung in meinen Unterlagen zu halten.
Vor etwa anderthalb Jahren stieß ich auf die Software VueScan. Zwar kostet sie etwas, aber für mich ist sie jeden Cent wert. Sie läuft nativ oder als Flatpak auf meinem Linux-System, bietet mehr Funktionen, als ich tatsächlich benötige, und unterstützt eine beeindruckend große Anzahl an Scannern. Sie scannt sogar mein Netzwerk nach anderen Geräten – so läuft auch mein Samsung-Multifunktionsdrucker problemlos damit. Was mich jedoch wirklich beeindruckt, sind die Menschen hinter der Software.
Soweit ich weiß, wird VueScan nur von zwei Leuten entwickelt. Sie reagieren extrem schnell auf E-Mail-Anfragen und bieten hervorragenden Support. Gestern ist die Anwendung zum ersten Mal abgestürzt. Ich konnte sie direkt wieder öffnen, und alles war in Ordnung. Da VueScan den Absturz jedoch selbst erkannte, öffnete sich sofort ein Dialog für einen Fehlerbericht. Das kennt man ja. Ich füllte den Bericht aus und schickte ihn ab – und heute hatte ich bereits eine E-Mail vom Entwickler im Postfach, der mir Unterstützung anbot und weitere Fragen zum Absturz stellte. Diese schnelle, persönliche Reaktion hat mich sehr positiv überrascht.
Klar, mir war bereits aufgefallen, dass VueScan sehr häufig und regelmäßig Updates erhält, aber dass der Entwickler so engagiert dahintersteht, beeindruckt mich wirklich. Das gibt mir ein gutes Gefühl. Die Software ist klasse, der Preis ist in Ordnung (ich habe die Professional-Version), und der Support sowie die Reaktionszeit sind erstklassig. Außerdem unterstützen sie gefühlt jeden Scanner auf diesem Planeten. Und ja, die Software gibt es natürlich auch für Windows und Mac. 😉
Ich muss also nur einmal lernen, wie eine Software funktioniert, und bin dann in der Lage, auf verschiedenen Betriebssystemen und mit verschiedenen Geräten zu arbeiten. Ich möchte ja nicht Experte für x verschiedene Softwarelösungen werden, sondern einfach nur schnell meine Dokumente digitalisieren.
Ich bekomme für diesen Beitrag keinerlei Vergütung oder Ähnliches – ich bin einfach wirklich überzeugt von VueScan. Probiert es doch einfach mal aus, und ich bin gespannt, ob ihr meine Meinung teilt.
Eigentlich sollte die Überschrift heißen: Ärgere ich mich gerade über mich selbst oder über AVM?
Zuhause arbeitete eine FRITZ!Box 7590 KA, die zu Beginn mit einem Frixtender erweitert wurde. Nach knapp zwei Jahren habe ich bemerkt, dass die FRITZ!Box angefangen hat zu fiepen. Eine Funktionseinschränkung konnte ich jedoch nicht feststellen. Da es aber knapp vor dem Ablauf der Garantie war, habe ich Kontakt mit dem AVM-Support aufgenommen.
Dem AVM-Support habe ich in einer kurzen E-Mail geschildert, dass meine Box plötzlich fiept und ob ihnen in diesem Zusammenhang vielleicht Probleme, beispielsweise mit Spulen oder Spannungsreglern, bekannt sind. Die Antwort vom AVM-Support ließ nicht lange auf sich warten und lautete zusammengefasst: „Nein, uns sind keine Probleme bekannt, aber du kannst deine Box gerne zur Überprüfung/Austausch einschicken.“
Jetzt kommen wir zum Punkt, warum ich mich ärgere und unschlüssig bin, ob ich mich über mich selbst oder über AVM ärgere. Für meine Arbeit benötige ich eine funktionsfähige Internetverbindung. Wenn ich die Box einschicke, muss ich für eine Alternative sorgen. Wenn AVM die Box vorsorglich gegen eine neue tauscht, wäre das zwar schön, aber es gibt schon zu viel Elektroschrott. Elektronik darf Geräusche machen. Spulen könnt ihr euch oft wie eine Art Schwungrad vorstellen. Es braucht etwas, um anzulaufen, läuft dann aber auch noch einige Zeit weiter, selbst wenn es niemand mehr antreibt. Das hängt mit den aufkommenden Magnetfeldern zusammen und ist so gewollt. Magneten kennt ihr, und dass dort Kräfte an den Bauteilen ziehen, könnt ihr euch jetzt ebenfalls vorstellen. Eine Spule kann also mit der Zeit anfangen, leichte Geräusche zu machen, und das ist auch okay. Für Spannungsregler gilt das ebenfalls. Stellt euch einfach euren Wasserhahn vor: Wenn ihr ihn voll aufdreht, kommen da vielleicht 5 Liter in der Minute heraus. Wenn ihr weniger Wasser wollt, macht ihr den Hahn ganz schnell an und wieder aus. Wie schnell ihr das Wasser ein- bzw. ausschalten müsst, um beispielsweise nur 1 Liter pro Minute fließen zu lassen, messt ihr mit euren Augen. Ganz grob funktionieren Schaltnetzteile so. Je nach Last kann man da also schon mal etwas hören, und das ist okay.
So ist ein weiteres Jahr ins Land gegangen, bis mir in einem meiner Newsticker die Meldung über sterbende FRITZ!Boxen vom Typ 7590 aufgefallen ist. Hier wird von anfänglichem Fiepen, schlechter werdendem 2,4-GHz-WLAN bis hin zum Totalausfall des WLANs und der Box berichtet. Bääähhhhh. Das klang verdächtig nach dem von mir beobachteten Fehlerbild. Nun ist meine Box aus jeglicher Garantie und Gewährleistung heraus. Den AVM-Support brauche ich also nicht mehr zu bemühen, sondern kann mich vielmehr mit dem Gedanken anfreunden, eine neue Box zu kaufen, um auf einen Ausfall vorbereitet zu sein. Zeitgleich haben bei uns im Ort die Arbeiten am Glasfaserausbau begonnen. Diese gehen so schnell und gut voran, dass ich damit rechnen kann, bis zum Ende dieses Jahres von DSL auf Glasfaser wechseln zu können. Mit diesem Wechsel kommt vom Anbieter auch eine neue FRITZ!Box. Tjo… Also Risiko eingehen oder eine Box kaufen, die in 5 oder 6 Monaten dann wohl irgendwo im Regal Staub fängt?
Bevor es eine Antwort auf diese Frage gibt, noch schnell zum Punkt mit dem Ärgern: Ich habe AVM bewusst gefragt, ob es bekannte Probleme mit der Box gibt und speziell auf die aus meiner Sicht verdächtigen Bauteile hingewiesen. Die Antwort war ein klares Nein. Das muss ich jetzt einfach so glauben, aber ich werde den Beigeschmack nicht los, dass es zum Zeitpunkt meiner Supportanfrage schon einige Reklamationen wegen dieses Problems gegeben haben müsste. Daher wohl mein möglicher Ärger über AVM – und dass ich auf die Möglichkeit eines Austauschs verzichtet habe – und der Ärger über mich selbst.
Habe ich jetzt eine neue Box gekauft oder nicht? Nein, habe ich natürlich nicht. Ich habe meine Box von der Wand genommen, aufgeschraubt und durchgemessen. Ja, Geräusche und etwas zu hohe Spannung für das 2,4-GHz-WLAN habe ich gemessen bzw. zuordnen können. Alles aber noch im Rahmen, sodass ich gehofft habe, dass es noch ein paar Monate gutgeht. War leider nicht so. Vor ein paar Wochen ist die Box an der Wand „geplatzt“ und ich musste in den sauren Apfel beißen und eine neue für den Übergang kaufen. Jetzt habe ich wohl ein Backup für die Zukunft. Woohoo 🙁 Manchmal lerne ich nicht so schnell dazu, oder? Naja, manchmal kommt halt eins zum anderen.
Ob meine alte Box wirklich mit genau dem beschriebenen Problem ausgefallen ist, wollte ich dennoch herausfinden. Die Sichtprüfung war noch immer gut, aber es war keine Spannung mehr zu messen. Daher habe ich mir von Aliexpress ein paar MP1477 (die genaue Bezeichnung ist MP1477GTF-Z) zuschicken lassen. Ich habe direkt alle drei verbauten Chips ausgetauscht und siehe da, die Box lebt wieder. Oft sollen dabei wohl noch die RF FRONT ENDs 055F als Folge der zu hohen Spannung sterben, aber diese haben es bei mir zum Glück überlebt.
Nun habe ich also auch noch ein Backup für das zukünftige Backup. Super…
Da ich bei Aliexpress insgesamt 10 Stück bestellt habe, liegen hier jetzt noch ein paar herum. Ich wäre bereit, sie gegen ein Snickers zu tauschen, falls jemand von euch vor einem ähnlichen Problem steht. Uhh, und bedenkt bitte, dass die Dinger ECHT klein sind. Ich habe euch mal einen auf ein 1-Cent-Stück gelegt. Ohne Heißluftstation und etwas SMD-Löterfahrung solltet ihr das vielleicht lieber nicht angehen.
Die Messpunkte und die erwarteten Spannungen findet ihr im folgenden Bildchen.
Bei meinen letzten Einkaufstouren auf Aliexpress ist mir immer mal wieder ein FNIRSI GC-01 Nuclear Radiation Detector, sprich Geigerzähler vorgeschlagen worden. Was soll ich sagen, japp hat funktioniert, irgendwann habe ich das Teil tatsächlich einfach für knapp 30€ mit im Einkaufswagen gehabt. Nach ein paar Spielerreien ging mir aber schnell die Batterielebensdauer auf die Nerven, denn das Teil war im grunde immer leer. Da mich, wie immer, brennend interessiert, was denn da überhaupt verbaut ist, habe ich es mir etwas näher angesehen und schnell festgestellt, dass man noch ein paar Veränderungen vornehmen kann. Darum soll es in diesem Beitrag gehen.
Das Gerät kam mit einem J613 Geiger-Müller-Zählrohr. Dieses ist in der Lage Beta- und Gamma-Strahlung zu erfassen. J613 braucht eine Betriebsspannung von 300 bis 400 Volt und ist ganz gut darin auch niedrige Stralungsniveaus zu messen. Die Platine des GC-01 ist recht simpel aufgebaut. Es hat ein kleines PSU, welches vom USB-C Anschluss oder vom 3.7V Akku eine Spannung von ca. 130V AC aufbaut (ich hab den Teil mal mit einer 1 markiert). Dieses fütter dann einen 3-Stage Multiplier (2) und schon kommen die knapp 400V zusammen. Eine kleine CR1220 Knopfzellenbatterie sorgt dafür, dass der Speicher für Uhrzeit und Messwerte gehalten wird. Dann ist da noch ein kleiner CH32F103 (3). Das kann aber auch mal ein ARM MCU sein, kommt auf die Version an. Der eigentliche 3.7V Akku kommt bei mir mit 1100mAh, also knapp 4Wh, was die geringe Laufzeit erklären sollte. Es gibt noch einen kleinen Piezo Tongeber, welcher für die für einen Geigerzähler bekannten Knackgeräusche sorgt, wenn ein Teilchen „gezählt“ wird. Nahe der MCU sind noch vier „Löcher“ in der Platine, welche als JP1 beschriftet sind. Wie sich heraus stellte, ist dieses ein ST-Link Connector und von link nach rechts sind es die Pins +3.3V, SWDIO, SWCLK, GND. Das wird etwas später noch spannend.
Was mir ebenfalls recht schnell aufgefallen ist, ist dass scheinbar nicht jedes Teilchen ein hörbares Knacken auslöst. Zwar findet sich über dem Display noch eine kleine rote LED, welche passen zu den Teilchen aufblinkt aber halt nicht das Knacken. Der Soundgeber scheint auschließlich per Firmware angesteuert zu werden und die Entwickler haben anders entschieden. 😉
Im Internet habe ich ein paar Modifikation per Widerstand, Transistor usw. gesehen um eine Verbindung zwischen LED und Piezo Soundgeber zu löten, damit diese auch immer Geräusche von sich gibt. Ich bin aber bei Firmware hängen geblieben. Zum einen gibt es eine doch leistungsstarke MCU, dann noch eine USB-C Schnittstelle, bei welcher die Datenleitungen bis zur MCU reichen und natürlich noch den ST-Link.
Schalte ich das Gerät aus, schließe es per USB-C an meinen Computer an und schalte es ein taucht ein Laufwerk mit einem leeren Textfile auf. Irgendwas muss da also gehen. Da war nun wieder der Punkt an welchem ich nicht los lassen konnte.
Die CR1220 kam schon etwas verbraucht an und wurde von mir gegen eine frische ersetzt. Für den kleinen 1100mAh Akku hat sich ebenfalls ein günstiger und vor allem ins Gehäuse passender Ersatz mit immerhin 2200mAh gefunden. Dieser sollte die Autonomiezeit fast verdoppeln. Das J613 ist im grunde sehr gut für seinen Zweck, ich hatte da aber noch ein SBM-20 von einem früheren Projekt in meiner Schublade liegen. Das SBM-20 braucht eine Betriebsspannung von 380 bis 450V und hat eine sehr ähnliche Bauform. Ebenfalls erfasst es Beta- und Gamma-Strahlung. Es ist zwar bei geringeren Strahlungen nicht gaaanz so genau wie das J613 und das Fenster für Beta-Strahlung ist etwas kleiner aber hey, dafür ist das Ding fast unkaputtbar und wenn ich der Firmware irgendwie mitteilen kann, was ich da eingebaut habe, dann sollte sich Vieles durch berechnungen in der Firmware doch ausgleichen lassen, oder?
Firmware…. Ein Datalogger wäre toll, damit ich einfach jeden Tag, jede Stunde oder so kurz den aktuellen Messwert wegschreiben kann. Dann könnte ich über einen laaangen Zeitraum eine Kurve zeichnen. Wenn ich dann noch irgendwie den Stromverbrauch beeinflussen könnte, denn das Display muss ja nicht 24/4 leuchten. Vielleicht noch etwas um die normale Hintergrundstrahlung heraus zu filtern?! So Kleinigkeiten welche mir in der Stock Firmware irgendwie fehlen. Aber vielleicht gibt es ja inzwischen ein Update vom Herstellen oder ich kann da was auslesen und selbst schreiben, mal schauen.
Die Recerche hat mich recht schnell zu einem GitHub repro gebracht. Rad Pro, da hat sich schon jemand mit einer alternativen Firmware für verschiedene Geräte beschäftigt. Selbst Dinge über welche ich noch nicht im Ansatz nachgedacht habe, werden dort erfüllt bzw. gelöst. Öhm also was soll ich sagen? Ich hab einfach gemacht, was dort in der sehr überschaubaren Anleitung steht und geht einfach! Naja, fast. der Weg über das USB Laufwerk hat nicht so wirklich funktioniert. Am Ende habe ich einfach kurz eine Stiftleiste für den ST-Link eingelötet und die neue Firmware über diesen Weg in die MCU gedrückt. Was sich für mich auch irgendwie zuverlässiger anfühlte, vielleicht bin ich da aber auch zu oldschool.
Ein paar Bilder vom Gerät mit der neuen Firmware findet ihr unten.
Viel Spaß beim Basteln und wenn ihr Fragen habt, wie immer einfach fragen.
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept All”, you consent to the use of ALL the cookies. However, you may visit "Cookie Settings" to provide a controlled consent.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Dauer
Beschreibung
cookielawinfo-checkbox-advertisement
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category .
cookielawinfo-checkbox-analytics
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Analytics" category .
cookielawinfo-checkbox-necessary
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Necessary" category .
cookielawinfo-checkbox-others
1 year
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Others".
cookielawinfo-checkbox-performance
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to store the user consent for cookies in the category "Performance".
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Dauer
Beschreibung
CONSENT
16 years 3 months 22 days 14 hours
These cookies are set via embedded youtube-videos. They register anonymous statistical data on for example how many times the video is displayed and what settings are used for playback.No sensitive data is collected unless you log in to your google account, in that case your choices are linked with your account, for example if you click “like” on a video.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Dauer
Beschreibung
yt-remote-connected-devices
never
These cookies are set via embedded youtube-videos.
yt-remote-device-id
never
These cookies are set via embedded youtube-videos.
