Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.sci.electronics > #258415 > unrolled thread
| Started by | Joerg <news@analogconsultants.com> |
|---|---|
| First post | 2019-06-13 13:54 -0700 |
| Last post | 2019-06-14 23:57 +0200 |
| Articles | 20 on this page of 268 — 30 participants |
Back to article view | Back to de.sci.electronics
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-13 13:54 -0700
Re: Hamburg, Co.. Gerhard Hoffmann <dk4xp@arcor.de> - 2019-06-14 00:59 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-14 02:22 +0200
Re: Hamburg, Co.. Gerhard Hoffmann <dk4xp@arcor.de> - 2019-06-14 04:18 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-14 07:55 -0700
Re: Hamburg, Co.. Klaus Butzmann <kb.usenet@butzomail.de> - 2019-06-14 21:19 +0200
Re: Hamburg, Co.. Holger <me@privacy.org> - 2019-06-14 23:45 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-14 14:53 -0700
Re: Hamburg, Co.. Holger <me@privacy.org> - 2019-06-14 23:58 +0200
Re: Hamburg, Co.. "Horst-D. Winzler" <horst.d.winzler@web.de> - 2019-06-15 05:29 +0200
Re: Hamburg, Co.. Holger <me@privacy.org> - 2019-06-15 10:27 +0200
Re: Hamburg, Co.. "horst-d.winzler" <horst.d.winzler@web.de> - 2019-06-15 11:31 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-15 16:03 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-15 07:45 -0700
Re: Hamburg, Co.. "Horst-D. Winzler" <horst.d.winzler@web.de> - 2019-06-15 17:07 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-15 08:27 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-15 19:02 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-15 11:11 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-16 12:00 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-16 07:44 -0700
Re: Hamburg, Co.. Gerhard Hoffmann <dk4xp@arcor.de> - 2019-06-16 17:42 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-16 09:58 -0700
Re: Hamburg, Co.. Peter Thoms <dl6lat@darc.de> - 2019-06-16 19:10 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-16 23:48 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-17 14:04 -0700
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-17 23:40 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-17 14:59 -0700
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-18 08:41 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-18 07:27 -0700
Re: Hamburg, Co.. Holger <me@privacy.org> - 2019-06-18 16:48 +0200
Re: Hamburg, Co.. Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-18 20:08 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-18 20:34 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-18 11:34 -0700
Re: Hamburg, Co.. Hartmut Kraus <hartmut.melina@web.de> - 2019-06-19 22:54 +0200
Re: Hamburg, Co.. Hartmut Kraus <hartmut.melina@web.de> - 2019-06-19 22:57 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-18 17:57 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-18 11:30 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-18 23:48 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-19 10:35 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-19 07:13 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-19 17:19 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-19 18:04 +0200
Re: Hamburg, Co.. Hartmut Kraus <hartmut.melina@web.de> - 2019-06-19 23:40 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-18 20:44 +0200
Re: Hamburg, Co.. Holger <me@privacy.org> - 2019-06-16 19:12 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-17 14:09 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-18 18:05 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-18 11:42 -0700
Re: Hamburg, Co.. Rolf Bombach <rolfnospambombach@invalid.invalid> - 2019-06-18 22:18 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-19 00:13 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-18 16:49 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-19 13:51 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-19 07:27 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-19 18:30 +0200
Re: Hamburg, Co.. Holger <me@privacy.org> - 2019-06-21 03:18 +0200
Re: Hamburg, Co.. Uhu <Euleuhu@nest.de> - 2019-06-15 19:51 +0200
Re: Hamburg, Co.. Reinhardt Behm <rbehm@hushmail.com> - 2019-06-16 11:20 +0800
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-16 07:47 -0700
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-16 23:03 +0200
Re: Hamburg, Co.. Rolf Bombach <rolfnospambombach@invalid.invalid> - 2019-06-18 22:21 +0200
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-16 12:30 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-16 13:55 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-16 14:04 +0200
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-16 23:12 +0200
Re: Hamburg, Co.. Gerhard Hoffmann <dk4xp@arcor.de> - 2019-06-16 23:22 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-17 14:27 -0700
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-16 07:58 -0700
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-16 19:51 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-17 14:12 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-18 18:13 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-18 11:52 -0700
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-18 21:05 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-18 13:29 -0700
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-19 09:22 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-19 12:34 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-19 07:30 -0700
Re: Hamburg, Co.. Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-19 16:34 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-19 09:16 -0700
Re: Hamburg, Co.. Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-19 22:02 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-19 13:13 -0700
Re: Hamburg, Co.. Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-19 22:51 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-19 15:08 -0700
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 07:21 +0200
Re: Hamburg, Co.. Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-20 08:50 +0200
Re: Hamburg, Co.. Rolf Bombach <rolfnospambombach@invalid.invalid> - 2019-06-20 19:55 +0200
Re: Hamburg, Co.. Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-20 21:39 +0200
Re: Hamburg, Co.. Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2019-06-21 23:36 +0200
Re: Hamburg, Co.. Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2019-06-19 20:59 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-19 16:05 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-19 07:49 -0700
Re: Hamburg, Co.. [OT] Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-19 16:57 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-19 09:29 -0700
Re: Hamburg, Co.. Martin Gerdes <martin.gerdes@gmx.de> - 2019-06-19 23:39 +0200
Re: Hamburg, Co.. Rolf Bombach <rolfnospambombach@invalid.invalid> - 2019-06-18 22:26 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-19 00:51 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-18 16:36 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-19 14:24 +0200
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-19 09:19 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-19 07:53 -0700
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-19 09:39 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-19 08:08 -0700
Re: Hamburg, Co.. [OT] Falk Dµebbert <falk@duebbert.com> - 2019-06-19 20:02 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-19 11:31 -0700
Re: Hamburg, Co.. [OT] Falk Dµebbert <falk@duebbert.com> - 2019-06-20 00:22 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-19 15:49 -0700
Re: Hamburg, Co.. [OT] Falk Dµebbert <falk@duebbert.com> - 2019-06-20 01:15 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-19 16:22 -0700
Re: Hamburg, Co.. [OT] Falk Dµebbert <falk@duebbert.com> - 2019-06-20 10:15 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 07:00 -0700
Re: Hamburg, Co.. [OT] Hanno Foest <hurga-news2@tigress.com> - 2019-06-20 16:19 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 07:35 -0700
Re: Hamburg, Co.. [OT] Hanno Foest <hurga-news2@tigress.com> - 2019-06-20 16:45 +0200
Re: Hamburg, Co.. [OT] Hanno Foest <hurga-news2@tigress.com> - 2019-06-20 16:46 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 08:04 -0700
Re: Hamburg, Co.. [OT] Hanno Foest <hurga-news2@tigress.com> - 2019-06-20 18:19 +0200
Re: Hamburg, Co.. [OT] Falk Dµebbert <falk@duebbert.com> - 2019-06-20 23:32 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 15:14 -0700
Re: Hamburg, Co.. [OT] Helmut Schellong <rip@schellong.biz> - 2019-06-20 19:04 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 10:13 -0700
Re: Hamburg, Co.. [OT] Helmut Schellong <rip@schellong.biz> - 2019-06-20 14:10 +0200
Re: Hamburg, Co.. [OT] Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-20 08:57 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 07:19 -0700
Re: Hamburg, Co.. [OT] Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 16:29 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 08:02 -0700
Re: Hamburg, Co.. [OT] Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 17:16 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 08:57 -0700
Re: Hamburg, Co.. [OT] Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-20 18:17 +0200
Re: Hamburg, Co.. [OT] Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-20 18:13 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 09:47 -0700
Re: Hamburg, Co.. [OT] Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-20 18:52 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 10:08 -0700
Re: Hamburg, Co.. [OT] Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-20 18:57 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 10:05 -0700
Re: Hamburg, Co.. [OT] Klaus Butzmann <kb.usenet@butzomail.de> - 2019-06-20 23:33 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 15:32 -0700
Re: Hamburg, Co.. [OT] Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-21 08:36 +0200
Re: Hamburg, Co.. [OT] Roland Franzius <roland.franzius@uos.de> - 2019-06-21 08:57 +0200
Re: Hamburg, Co.. [OT] Klaus Butzmann <kb.usenet@butzomail.de> - 2019-06-21 13:07 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-21 07:28 -0700
Re: Hamburg, Co.. [OT] Klaus Butzmann <kb.usenet@butzomail.de> - 2019-06-21 16:53 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-21 08:03 -0700
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-18 23:48 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-19 10:40 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-19 12:44 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-19 13:51 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-19 16:11 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-19 18:09 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-19 18:37 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-19 19:40 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-19 20:19 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-19 21:17 +0200
Re: Hamburg, Co.. Olaf Schultz <o.schultz@enhydralutris.de> - 2019-06-19 22:02 +0200
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-20 00:27 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-20 01:10 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-20 07:15 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 07:29 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-20 14:34 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 14:45 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-20 14:56 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 15:42 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-20 17:15 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 17:18 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-20 15:43 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-20 17:18 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-20 09:01 -0700
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-20 18:13 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-20 19:30 +0200
Re: Hamburg, Co.. Klaus Butzmann <kb.usenet@butzomail.de> - 2019-06-20 23:42 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-20 15:50 -0700
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-22 16:34 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-22 07:54 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-21 12:41 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-21 01:03 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-20 07:28 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-20 18:40 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-20 18:59 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-20 10:01 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-20 20:37 +0200
Re: Hamburg, Co.. Rupert Haselbeck <mein-rest-muell@gmx.de> - 2019-06-22 16:38 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-22 21:18 +0200
Re: Hamburg, Co.. Stefan Engler <stefan@epiket.de> - 2019-06-23 11:44 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-23 12:03 +0200
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-23 12:48 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-23 12:55 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-23 16:11 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-23 16:17 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-23 19:12 +0200
Re: Hamburg, Co.. Guido Grohmann <guido.grohmann@gmx.de> - 2019-06-23 19:35 +0200
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-24 01:11 +0200
Re: Hamburg, Co.. "Horst-D. Winzler" <horst.d.winzler@web.de> - 2019-06-24 10:09 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-24 07:22 -0700
Re: Hamburg, Co.. Volker Bartheld <news2018@bartheld.net> - 2019-06-24 16:42 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-25 07:13 -0700
Re: Hamburg, Co.. Marte Schwarz <marte.schwarz@gmx.de> - 2019-06-25 11:03 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-25 13:44 +0200
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-25 23:07 +0200
Re: Hamburg, Co.. Heinz Schmitz <kma@kma.org> - 2019-06-26 08:40 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-23 23:01 +0200
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-22 19:08 +0200
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-20 23:37 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 07:31 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-20 09:51 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-20 15:59 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-20 20:08 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-21 00:01 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-21 09:19 +0200
Re: Hamburg, Co.. Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-21 09:35 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-21 14:14 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-21 01:04 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 07:22 +0200
Re: Hamburg, Co.. Ewald Pfau <anderswo@gmx.net> - 2019-06-19 19:35 +0000
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-19 21:59 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-19 19:09 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-19 19:14 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-19 19:56 +0200
Re: Hamburg, Co.. Ewald Pfau <anderswo@gmx.net> - 2019-06-19 20:34 +0000
Re: Hamburg, Co.. Hartmut Kraus <hartmut.melina@web.de> - 2019-06-20 00:15 +0200
Re: Hamburg, Co.. Ewald Pfau <anderswo@gmx.net> - 2019-06-20 12:11 +0000
Re: Hamburg, Co.. Hartmut Kraus <hartmut.melina@web.de> - 2019-06-20 15:03 +0200
Re: Hamburg, Co.. Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2019-06-24 08:21 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-24 11:29 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-24 17:39 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-24 17:55 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-25 02:16 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-25 13:37 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-25 14:22 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-25 14:47 +0200
Re: Hamburg, Co.. Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2019-06-25 21:02 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-19 16:06 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-19 18:16 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-19 18:40 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-19 20:02 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-19 20:32 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-19 21:43 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-19 22:13 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-20 00:34 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-20 01:21 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-20 14:29 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 07:27 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-20 10:01 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 10:28 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-20 10:49 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 11:48 +0200
Re: Hamburg, Co.. Ewald Pfau <anderswo@gmx.net> - 2019-06-20 12:11 +0000
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 14:48 +0200
Re: Hamburg, Co.. Ewald Pfau <anderswo@gmx.net> - 2019-06-20 16:41 +0000
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-19 21:11 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-19 21:54 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-19 22:16 +0200
Re: Hamburg, Co.. Rolf Bombach <rolfnospambombach@invalid.invalid> - 2019-06-18 23:01 +0200
Re: Hamburg, Co.. Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-15 16:50 +0200
Re: Hamburg, Co.. Rolf Bombach <rolfnospambombach@invalid.invalid> - 2019-06-18 22:55 +0200
Re: Hamburg, Co.. Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-15 10:35 +0200
Re: Hamburg, Co.. "horst-d.winzler" <horst.d.winzler@web.de> - 2019-06-15 11:33 +0200
Re: Hamburg, Co.. Ole Jansen <remove.this.kaspernasebaer@gmx.de> - 2019-06-17 10:11 +0200
Re: Hamburg, Co.. "Horst-D. Winzler" <horst.d.winzler@web.de> - 2019-06-17 11:01 +0200
Re: Hamburg, Co.. Hartmut Kraus <hartmut.melina@web.de> - 2019-06-17 18:30 +0200
Re: Hamburg, Co.. "Horst-D. Winzler" <horst.d.winzler@web.de> - 2019-06-17 19:11 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-17 14:20 -0700
Re: Hamburg, Co.. Klaus Butzmann <kb.usenet@butzomail.de> - 2019-06-17 23:02 +0200
Re: Hamburg, Co.. "Horst-D. Winzler" <horst.d.winzler@web.de> - 2019-06-18 05:31 +0200
Re: Hamburg, Co.. Rolf Bombach <rolfnospambombach@invalid.invalid> - 2019-06-18 22:50 +0200
Re: Hamburg, Co.. "Horst-D. Winzler" <horst.d.winzler@web.de> - 2019-06-19 10:06 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-19 10:28 +0200
Re: Hamburg, Co.. Klaus Butzmann <kb.usenet@butzomail.de> - 2019-06-14 20:54 +0200
Re: Hamburg, Co.. "Horst-D. Winzler" <horst.d.winzler@web.de> - 2019-06-14 09:28 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-14 08:00 -0700
Re: Hamburg, Co.. Holger <me@privacy.org> - 2019-06-14 23:57 +0200
Page 12 of 14 — ← Prev page 1 … 10 11 [12] 13 14 Next page →
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2019-06-24 11:29 +0200 |
| Message-ID | <gnbjf2ForcsU2@mid.individual.net> |
| In reply to | #259069 |
On 24.06.19 08:21, Thomas Prufer wrote: > On Wed, 19 Jun 2019 18:09:35 +0200, Hans-Peter Diettrich <DrDiettrich1@aol.com> > wrote: > >> Ich war bei der Entwicklund der Airbags dabei, da waren autonome >> Sicherheitskreise eine unabdingbare Voraussetzung. > > Ich sag mal "ist nicht mehr so", s.u.:-) > > Remotely Hacking a Car While It's Driving > > https://www.schneier.com/blog/archives/2015/07/remotely_hackin.html > > "Miller and Valasek's full arsenal includes functions that at lower speeds fully > kill the engine, abruptly engage the brakes, or disable them altogether." Hatte ich bereits zitiert. Hans-Peter liest sowas nicht. Hanno
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-06-24 17:39 +0200 |
| Message-ID | <gnc94kFte6rU1@mid.individual.net> |
| In reply to | #259077 |
Am 24.06.2019 um 11:29 schrieb Hanno Foest: > On 24.06.19 08:21, Thomas Prufer wrote: >> "Miller and Valasek's full arsenal includes functions that at lower >> speeds fully >> kill the engine, abruptly engage the brakes, or disable them altogether." > > Hatte ich bereits zitiert. Hans-Peter liest sowas nicht. Es ist einfach noch nicht spruchreif. Wenn das so bleibt, lohne sich ein Kommentar nicht, und wenn sich was ändert, dann ist die Situation eine andere. DoDi
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2019-06-24 17:55 +0200 |
| Message-ID | <gnca3tFtlfrU1@mid.individual.net> |
| In reply to | #259105 |
On 24.06.19 17:39, Hans-Peter Diettrich wrote: >>> "Miller and Valasek's full arsenal includes functions that at lower >>> speeds fully >>> kill the engine, abruptly engage the brakes, or disable them >>> altogether." >> >> Hatte ich bereits zitiert. Hans-Peter liest sowas nicht. > > Es ist einfach noch nicht spruchreif. Wenn das so bleibt, lohne sich ein > Kommentar nicht, und wenn sich was ändert, dann ist die Situation eine > andere. "Der Brunnen ist sicher, bis ein Kind reingefallen ist. Wir müssen erst warten, bis das Kind reingefallen ist, bevor wir einen Deckel draufmachen." Daß vernetzte Computer auf Rädern die gleichen Sicherheitsprobleme haben wie alle anderen vernetzten Computer, dürfte der Sachlage nach unbestreitbar sein. Hanno
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-06-25 02:16 +0200 |
| Message-ID | <gne5qiFbbt7U1@mid.individual.net> |
| In reply to | #259106 |
Am 24.06.2019 um 17:55 schrieb Hanno Foest: > Daß vernetzte Computer auf Rädern die gleichen Sicherheitsprobleme haben > wie alle anderen vernetzten Computer, dürfte der Sachlage nach > unbestreitbar sein. Kein vernetzter Computer ist verpflichtet, irgendwas als Kommando überhaupt, sofort und ungeprüft auszuführen. So what? DoDi
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2019-06-25 13:37 +0200 |
| Message-ID | <gnefcbFdd6mU1@mid.individual.net> |
| In reply to | #259152 |
On 25.06.19 02:16, Hans-Peter Diettrich wrote: >> Daß vernetzte Computer auf Rädern die gleichen Sicherheitsprobleme haben >> wie alle anderen vernetzten Computer, dürfte der Sachlage nach >> unbestreitbar sein. > > Kein vernetzter Computer ist verpflichtet, irgendwas als Kommando > überhaupt, sofort und ungeprüft auszuführen. Ja, und? Hast du schon mal gehört, was der Begriff "hacken" bedeutet? Hanno
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-06-25 14:22 +0200 |
| Message-ID | <gnei0dFdt3iU1@mid.individual.net> |
| In reply to | #259160 |
Am 25.06.2019 um 13:37 schrieb Hanno Foest: > On 25.06.19 02:16, Hans-Peter Diettrich wrote: > >>> Daß vernetzte Computer auf Rädern die gleichen Sicherheitsprobleme haben >>> wie alle anderen vernetzten Computer, dürfte der Sachlage nach >>> unbestreitbar sein. >> >> Kein vernetzter Computer ist verpflichtet, irgendwas als Kommando >> überhaupt, sofort und ungeprüft auszuführen. > > Ja, und? Hast du schon mal gehört, was der Begriff "hacken" bedeutet? Ja, Hacker sind die Guten, die decken Sicherheitslücken auf. Du meintest wohl eher die andere Sorte... Noch so ein dämlicher Kommentar, und Du landest in meinem Filter :-] DoDi
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2019-06-25 14:47 +0200 |
| Message-ID | <gnejfgFe80lU1@mid.individual.net> |
| In reply to | #259164 |
On 25.06.19 14:22, Hans-Peter Diettrich wrote: >>> Kein vernetzter Computer ist verpflichtet, irgendwas als Kommando >>> überhaupt, sofort und ungeprüft auszuführen. >> >> Ja, und? Hast du schon mal gehört, was der Begriff "hacken" bedeutet? > > Ja, Hacker sind die Guten, die decken Sicherheitslücken auf. Du meintest > wohl eher die andere Sorte... Hacker sind Leute, die Computer zu Dingen bringen, für die sie nicht gedacht waren. Das ist erst mal wertfrei. > Noch so ein dämlicher Kommentar, und Du landest in meinem Filter :-] WER schreibt hier die dämlichen Kommentare? Hanno
[toc] | [prev] | [next] | [standalone]
| From | Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> |
|---|---|
| Date | 2019-06-25 21:02 +0200 |
| Message-ID | <20190625210239.5bf4903f@Achmuehle.WOR> |
| In reply to | #259152 |
Hallo Hans-Peter, Du schriebst am Tue, 25 Jun 2019 02:16:04 +0200: > > Daß vernetzte Computer auf Rädern die gleichen Sicherheitsprobleme haben > > wie alle anderen vernetzten Computer, dürfte der Sachlage nach > > unbestreitbar sein. > > Kein vernetzter Computer ist verpflichtet, irgendwas als Kommando > überhaupt, sofort und ungeprüft auszuführen. So what? Dann ist ein Netzwerkanschluß für diesen Computer aber völlig überflüssig. Der kann dann ja _überhaupt keine_ Daten empfangen (annehmen) können. In dem Fall hättest Du allerdings recht, aber dann ist das auch kein "vernetzter Computer". -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz -----------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2019-06-19 16:06 +0200 |
| Message-ID | <qedfi0$hp7$2@news.bawue.net> |
| In reply to | #258632 |
On 6/18/19 11:48 PM, Hans-Peter Diettrich wrote: > Am 18.06.2019 um 18:13 schrieb Helmut Schellong: >> On 06/17/2019 23:12, Joerg wrote: >> >>> Klar, aber in dem Massenbereich ist die Gewinnmarge hauchduenn und >>> staendig unter Druck. Viel Know-How und Gewinnpotenzial steckt in den >>> Baugruppen mit grossen Prozessoren, wo es in Richtung autonomes Fahren >>> geht. Egal, was man davon haelt (ich als regelmaessiger Fahrradnutzer >>> halte davon nicht so viel). >> >> Autonomes Fahren (SAE Level 5) wird meist gewaltig unterschätzt. >> Es wird wohl bis zu solchen Fahrzeugen noch 20-30 Jahre dauern. > > Es wäre deutlich einfacher, erst einmal die Autobahnen nur noch für > selbstfahrende (vernetzte!) Kfz offenzulassen. Aha... Motorradfahrer also nicht mehr? Und vernetzte Autos? Hacker's Dream! Dann gibt es keine > Notwendigkeit für ethische KI-Einzelentscheidungen oder Raum für falsche > Einschätzungen, es wird ja alles mehr oder weniger zentral geplant und > überwacht. Funklöcher gibts also auch keine mehr? Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-06-19 18:16 +0200 |
| Message-ID | <gmv64uF3lluU2@mid.individual.net> |
| In reply to | #258658 |
Am 19.06.2019 um 16:06 schrieb Gerrit Heitsch: > On 6/18/19 11:48 PM, Hans-Peter Diettrich wrote: >> Es wäre deutlich einfacher, erst einmal die Autobahnen nur noch für >> selbstfahrende (vernetzte!) Kfz offenzulassen. > > Aha... Motorradfahrer also nicht mehr? Nur noch auf Zweirad-Wegen :-] > Und vernetzte Autos? Hacker's Dream! Man sollte Vernetzung nicht gleich mit Cloud und Web und offenem Zugang assoziieren. Das wäre zwar einfacher, aber dann vor allem für Hacker :-( > Dann gibt es keine >> Notwendigkeit für ethische KI-Einzelentscheidungen oder Raum für >> falsche Einschätzungen, es wird ja alles mehr oder weniger zentral >> geplant und überwacht. > > Funklöcher gibts also auch keine mehr? Nö, die Notruftelefone werden entsprechend umgerüstet :-) DoDi
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2019-06-19 18:40 +0200 |
| Message-ID | <qedoh3$lbh$2@news.bawue.net> |
| In reply to | #258681 |
On 6/19/19 6:16 PM, Hans-Peter Diettrich wrote: > Am 19.06.2019 um 16:06 schrieb Gerrit Heitsch: >> On 6/18/19 11:48 PM, Hans-Peter Diettrich wrote: > >>> Es wäre deutlich einfacher, erst einmal die Autobahnen nur noch für >>> selbstfahrende (vernetzte!) Kfz offenzulassen. >> >> Aha... Motorradfahrer also nicht mehr? > > Nur noch auf Zweirad-Wegen :-] > >> Und vernetzte Autos? Hacker's Dream! > > Man sollte Vernetzung nicht gleich mit Cloud und Web und offenem Zugang > assoziieren. Das wäre zwar einfacher, aber dann vor allem für Hacker :-( Es reicht wenn ein Auto dem anderen was mitteilen kann. Damit muss das Auto von aussen erreichbar sein. Wie ist egal, ob nun WLAN, was eigenes oder Bluetooth. Sobald das geht reicht 1 Bug an der falschen Stelle und das Auto gehorcht dem Angreifer. Schlecht für den der drin sitzt. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-06-19 20:02 +0200 |
| Message-ID | <gmvbnpF4rglU3@mid.individual.net> |
| In reply to | #258688 |
Am 19.06.2019 um 18:40 schrieb Gerrit Heitsch: > On 6/19/19 6:16 PM, Hans-Peter Diettrich wrote: > Es reicht wenn ein Auto dem anderen was mitteilen kann. Damit muss das > Auto von aussen erreichbar sein. Wie ist egal, ob nun WLAN, was eigenes > oder Bluetooth. Sobald das geht reicht 1 Bug an der falschen Stelle und > das Auto gehorcht dem Angreifer. Bei ordentlichem Design gibt es nicht viele solche Stellen. Zeige mir einen Hacker, der durch die reine Übertragung von Daten (nicht Updates oder Skripte) irgendwo die Kontrolle übernehmen kann. DoDi
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2019-06-19 20:32 +0200 |
| Message-ID | <qedv4h$o85$1@news.bawue.net> |
| In reply to | #258695 |
On 6/19/19 8:02 PM, Hans-Peter Diettrich wrote: > Am 19.06.2019 um 18:40 schrieb Gerrit Heitsch: >> On 6/19/19 6:16 PM, Hans-Peter Diettrich wrote: > >> Es reicht wenn ein Auto dem anderen was mitteilen kann. Damit muss das >> Auto von aussen erreichbar sein. Wie ist egal, ob nun WLAN, was eigenes >> oder Bluetooth. Sobald das geht reicht 1 Bug an der falschen Stelle und >> das Auto gehorcht dem Angreifer. > > Bei ordentlichem Design gibt es nicht viele solche Stellen. Zeige mir > einen Hacker, der durch die reine Übertragung von Daten (nicht Updates > oder Skripte) irgendwo die Kontrolle übernehmen kann. Buffer Overflow als Beispiel sagt dir was? Da kommen eigentlich unschuldige Datenpakete an und einen Moment später hat der Angreifer eine root-Shell. 'sendmail' war früher berüchtigt dafür, auch 'ssh' hatte solche Probleme. Eigentlich sollte sowas nicht vorkommen, deshalb nennt sich sowas auch 'Bug'. Es reicht wenn ein Programmierer nicht daran denkt. Kurz, wenn ich Daten reinschicken kann, dann müssen die bearbeitet werden und wenn der Code der das erledigt Fehler hat ist der Hacker drin. Wie sowas aussehen kann wird hier beschrieben: http://illmatics.com/Remote%20Car%20Hacking.pdf Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-06-19 21:43 +0200 |
| Message-ID | <gmvhk1F64c2U2@mid.individual.net> |
| In reply to | #258699 |
Am 19.06.2019 um 20:32 schrieb Gerrit Heitsch: > On 6/19/19 8:02 PM, Hans-Peter Diettrich wrote: >> Bei ordentlichem Design gibt es nicht viele solche Stellen. Zeige mir >> einen Hacker, der durch die reine Übertragung von Daten (nicht Updates >> oder Skripte) irgendwo die Kontrolle übernehmen kann. > > Buffer Overflow als Beispiel sagt dir was? Da kommen eigentlich > unschuldige Datenpakete an und einen Moment später hat der Angreifer > eine root-Shell. 'sendmail' war früher berüchtigt dafür, auch 'ssh' > hatte solche Probleme. Das kann nur vorkommen, wenn Messages mangels Redundanz nicht verloren gehen dürfen. Wenn Abstandswerte zu oft hereinkommen, darf gerne jeder zweite weggeworfen werden. Das geht z.B. automatisch wenn den externen Meßwerten feste Speicherplätze zugewiesen werden, die dann stets den neuesten Wert enthalten. Zudem kann im Straßenverkehr das meiste Datenaufkommen lokal gehalten werden, womit ein einzelner Angreifer viele Ziele gleichzeitig bombardieren müßte. Übergeordnete Steuerung betrifft allenfalls die optimale Geschwindigkeit vor Kreuzungen oder Unfallstellen. Und daß beim Buffer Overflow auch noch Daten und Code vermischt werden können, ist ein schwerer Designfehler. Ich schätze mal, daß sich die Militärs dieses Problems spätestens dann annehmen werden, wenn der erste größere Angriff stattgefunden hat. Möglicherweise auch schon früher... Im Verkehrsnetz wäre es durchaus eine sichere Lösung, beim Auftreten von Überlastungen die Fahrzeuge anzuhalten. Das geht auch mit abgeschaltetem Netzwerk, nur mit den Sensoren am Fahrzeug. Oder etwas weicher mit dem Rückfall auf konservative Abstände, wenn die zuvor wegen der vorauseilenden Mitteilungen von Geschwindigkeitsänderungen (Bremsen!) verringert werden konnten. DoDi
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2019-06-19 22:13 +0200 |
| Message-ID | <qee519$qod$1@news.bawue.net> |
| In reply to | #258702 |
On 6/19/19 9:43 PM, Hans-Peter Diettrich wrote: > Am 19.06.2019 um 20:32 schrieb Gerrit Heitsch: >> On 6/19/19 8:02 PM, Hans-Peter Diettrich wrote: > >>> Bei ordentlichem Design gibt es nicht viele solche Stellen. Zeige mir >>> einen Hacker, der durch die reine Übertragung von Daten (nicht Updates >>> oder Skripte) irgendwo die Kontrolle übernehmen kann. >> >> Buffer Overflow als Beispiel sagt dir was? Da kommen eigentlich >> unschuldige Datenpakete an und einen Moment später hat der Angreifer >> eine root-Shell. 'sendmail' war früher berüchtigt dafür, auch 'ssh' >> hatte solche Probleme. > > Das kann nur vorkommen, wenn Messages mangels Redundanz nicht verloren > gehen dürfen. Nein, das kann jederzeit passieren. Bevor dein Code entscheidet, ob er die Daten behält oder wegwirft hat er (bzw. das OS) sie schon im Netzwerkstack bearbeitet. Dieser könnte fehlerhaft sein. Siehe auch der aktuelle Bug im Linuxkernel im Bezug auf SACK. Passend gebaute Pakete an einen Linux-Rechner geschickt ergeben eine Kernel-Panic. Ein Absturz des Steuerrechners eines autonomen Autos ist ein GAU. Es gilt bei Kommunikation mit der Aussenwelt: Alle eingehenden Daten sind bis zum Beweis (!) des Gegenteils als böse zu betrachten und das bei jedem eingehenden Datenpaket. Alternativ kann man die Logik so bauen, daß nichts passieren kann. Ist aber bemerkenswert schwer wie sich immer wieder zeigt. Wenn Abstandswerte zu oft hereinkommen, darf gerne jeder > zweite weggeworfen werden. Das geht z.B. automatisch wenn den externen > Meßwerten feste Speicherplätze zugewiesen werden, die dann stets den > neuesten Wert enthalten. Vorsicht... Buffer Overflows passieren wenn man meint, daß eingehende Daten nur Länge <X> Bytes haben können und der Angreifer ein spezielles Paket bastelt bei dem das Datenfeld <X+Y> Bytes groß ist. Ist dein Eingangspuffer genau <X> Bytes groß wird er beim Kopieren der Daten des bösen Paketes überlaufen. Zudem kann im Straßenverkehr das meiste > Datenaufkommen lokal gehalten werden, womit ein einzelner Angreifer > viele Ziele gleichzeitig bombardieren müßte. Macht nichts, dafür hat man heutzutage Computer, die können sowas gut. Sobald der proof-of-concept-Exploit da ist finden sich Leute die das optimieren und danach reicht womöglich ein Laptop mit WLAN- oder Bluetooth-Stick um Spass zu haben. > Und daß beim Buffer Overflow auch noch Daten und Code vermischt werden > können, ist ein schwerer Designfehler. Ja, kommt aber immer wieder vor und ist bei der üblichen von-Neumann-Architektur gar nicht so einfach zu vermeiden. Alternative Architekturen die Code und Daten trennen gibt es, aber so richtig durchsetzen wollen die sich nicht. Noch schöner ist der off-by-one-Exploit: https://csl.com.co/en/off-by-one-explained/ Es gibt Sprachen die das Problem nicht haben. Dafür haben sie andere, in einem Auto muss der Kram echtzeitfähig sein. Da kann nicht der Garbage-Collector kommen und das ganze für 100ms einfrieren während er Speichermüll einsammelt. > Im Verkehrsnetz wäre es durchaus eine sichere Lösung, beim Auftreten von > Überlastungen die Fahrzeuge anzuhalten. Autos die das häufiger tun kauft keiner. Schönes Ziel für einen Denial-of-Service-Angriff. Das Auto wird dabei nicht übernommen, aber fahren tut es auch nicht mehr. Das geht auch mit abgeschaltetem > Netzwerk, nur mit den Sensoren am Fahrzeug. Ist nur zu spät wenn der Angreifer das System bereits übernommen hat. Denn dann kannst du das Netzwerk nicht mehr abschalten wenn er das erwartet hat, du (bzw. dein Programm) ist dann nicht mehr Herr im Haus (Auto). Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-06-20 00:34 +0200 |
| Message-ID | <gmvrmjF88a1U1@mid.individual.net> |
| In reply to | #258711 |
Am 19.06.2019 um 22:13 schrieb Gerrit Heitsch: > On 6/19/19 9:43 PM, Hans-Peter Diettrich wrote: > Vorsicht... Buffer Overflows passieren wenn man meint, daß eingehende > Daten nur Länge <X> Bytes haben können und der Angreifer ein spezielles > Paket bastelt bei dem das Datenfeld <X+Y> Bytes groß ist. Ist dein > Eingangspuffer genau <X> Bytes groß wird er beim Kopieren der Daten des > bösen Paketes überlaufen. Das halte ich für ein spezielles Problem unsicherer Programmiersprachen, wie C. Speicher dürfte heutzutage keine Mangelware mehr sein. Kein System kann gezwungen werden, übergroße Datenpakete anzunehmen. > Zudem kann im Straßenverkehr das meiste >> Datenaufkommen lokal gehalten werden, womit ein einzelner Angreifer >> viele Ziele gleichzeitig bombardieren müßte. > > Macht nichts, dafür hat man heutzutage Computer, die können sowas gut. Ähm, wieviele Sender auf unterschiedlichen Kanälen soll so ein Computer haben? > Es gibt Sprachen die das Problem nicht haben. Dafür haben sie andere, in > einem Auto muss der Kram echtzeitfähig sein. Da kann nicht der > Garbage-Collector kommen und das ganze für 100ms einfrieren während er > Speichermüll einsammelt. Sag ich doch: ein Problem der Programmiersprache :-( >> Im Verkehrsnetz wäre es durchaus eine sichere Lösung, beim Auftreten >> von Überlastungen die Fahrzeuge anzuhalten. > > Autos die das häufiger tun kauft keiner. Schönes Ziel für einen > Denial-of-Service-Angriff. Das Auto wird dabei nicht übernommen, aber > fahren tut es auch nicht mehr. Es geht dabei doch nicht um einzelne Autos, und selbst die wären kaum auf einen bestimmten Typ beschränkt. > Das geht auch mit abgeschaltetem >> Netzwerk, nur mit den Sensoren am Fahrzeug. > > Ist nur zu spät wenn der Angreifer das System bereits übernommen hat. Woher kommt nur immer wieder die Annahme, daß ein Kfz bei geeigneter Programmierung gekapert werden könnte? Von den großen Autobauern, nehme ich mal an, die damit schlampige Programmierung entschuldigen wollen. Für mehr als Mogelsoftware scheint es dort nicht zu reichen, zumindest nicht ohne nachhaltigen äußeren Druck :-] DoDi
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2019-06-20 01:21 +0200 |
| Message-ID | <gmvuboF8pg3U1@mid.individual.net> |
| In reply to | #258732 |
Am 20.06.19 um 00:34 schrieb Hans-Peter Diettrich: > Woher kommt nur immer wieder die Annahme, daß ein Kfz bei geeigneter > Programmierung gekapert werden könnte? Aus der Realität? https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/ https://www.theguardian.com/technology/2016/sep/20/tesla-model-s-chinese-hack-remote-control-brakes Die Frage ist eher, woher die Annahme stammt, daß ein vernetzter Computer auf Rädern wundersamerweise besser gegen informationstechnische Angriffe geschützt sein sollte als irgendwelche vernetzte Computer anderswo. Hanno -- The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. - John Kenneth Galbraith
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2019-06-20 14:29 +0200 |
| Message-ID | <qefu78$qvc$1@solani.org> |
| In reply to | #258743 |
On 06/20/2019 01:21, Hanno Foest wrote: > Am 20.06.19 um 00:34 schrieb Hans-Peter Diettrich: > >> Woher kommt nur immer wieder die Annahme, daß ein Kfz bei geeigneter >> Programmierung gekapert werden könnte? > > Aus der Realität? > > https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/ > > https://www.theguardian.com/technology/2016/sep/20/tesla-model-s-chinese-hack-remote-control-brakes > > > Die Frage ist eher, woher die Annahme stammt, daß ein vernetzter Computer auf > Rädern wundersamerweise besser gegen informationstechnische Angriffe > geschützt sein sollte als irgendwelche vernetzte Computer anderswo. Ich verstehe solches seit langem nicht, auch nicht in Filmen. Meine Autos sind nicht vernetzt, und werden es nie sein. Falls doch, würde ich die Antenne unwirksam machen. Es gibt keinerlei Aktoren in meinen Autos, die eine Manipulation erlauben würden. Einen Zugang per Funk sowieso nicht. Meine Autos sind folglich absolut nicht remote zu hacken. Es gibt nur einen Weg: Falls jemand an mein Auto herankäme, es öffnen und ungestört daran arbeiten könnte, nur dann wäre eine Manipulation möglich. -- Mit freundlichen Grüßen Helmut Schellong var@schellong.biz www.schellong.de www.schellong.com www.schellong.biz http://www.schellong.de/c.htm
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2019-06-20 07:27 +0200 |
| Message-ID | <qef5fe$98t$1@news.bawue.net> |
| In reply to | #258732 |
On 6/20/19 12:34 AM, Hans-Peter Diettrich wrote: > Am 19.06.2019 um 22:13 schrieb Gerrit Heitsch: >> On 6/19/19 9:43 PM, Hans-Peter Diettrich wrote: > >> Vorsicht... Buffer Overflows passieren wenn man meint, daß eingehende >> Daten nur Länge <X> Bytes haben können und der Angreifer ein spezielles >> Paket bastelt bei dem das Datenfeld <X+Y> Bytes groß ist. Ist dein >> Eingangspuffer genau <X> Bytes groß wird er beim Kopieren der Daten des >> bösen Paketes überlaufen. > > Das halte ich für ein spezielles Problem unsicherer Programmiersprachen, > wie C. Speicher dürfte heutzutage keine Mangelware mehr sein. Kein > System kann gezwungen werden, übergroße Datenpakete anzunehmen. Doch, eben, aufgrund von Programmierfehlern. Wir reden hier von Fehlern im Code. >> Zudem kann im Straßenverkehr das meiste >>> Datenaufkommen lokal gehalten werden, womit ein einzelner Angreifer >>> viele Ziele gleichzeitig bombardieren müßte. >> >> Macht nichts, dafür hat man heutzutage Computer, die können sowas gut. > > Ähm, wieviele Sender auf unterschiedlichen Kanälen soll so ein Computer > haben? Weieviele USB-Ports hast du und wie schnell kann der Sender in so einem Stick den Kanal wechseln? Dazu noch USB-Hubs. >>> Im Verkehrsnetz wäre es durchaus eine sichere Lösung, beim Auftreten >>> von Überlastungen die Fahrzeuge anzuhalten. >> >> Autos die das häufiger tun kauft keiner. Schönes Ziel für einen >> Denial-of-Service-Angriff. Das Auto wird dabei nicht übernommen, aber >> fahren tut es auch nicht mehr. > > Es geht dabei doch nicht um einzelne Autos, und selbst die wären kaum > auf einen bestimmten Typ beschränkt. Doch, am Ende geht es um einzelne Autos. >> Das geht auch mit abgeschaltetem >>> Netzwerk, nur mit den Sensoren am Fahrzeug. >> >> Ist nur zu spät wenn der Angreifer das System bereits übernommen hat. > > Woher kommt nur immer wieder die Annahme, daß ein Kfz bei geeigneter > Programmierung gekapert werden könnte? Bei geeigneter Programmierung nicht. Aber woher kommt die Annahme, daß die Programmierer solchen Code programmieren? Wer schon länger mit IT zu tun hat, hat eher den Eindruck als wenn solche Bugs der Normalzustand sind. Ich bekomme hier mehrfach die Woche Sicherheitsupdates für alle möglicht Software. Von den großen Autobauern, nehme > ich mal an, die damit schlampige Programmierung entschuldigen wollen. > Für mehr als Mogelsoftware scheint es dort nicht zu reichen, zumindest > nicht ohne nachhaltigen äußeren Druck :-] Nach allem was ich gelesen habe war zumindest die Codequalität der Mogelsoftware sehr gut. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-06-20 10:01 +0200 |
| Message-ID | <gn0sv3Ff3jaU2@mid.individual.net> |
| In reply to | #258752 |
Am 20.06.2019 um 07:27 schrieb Gerrit Heitsch: > Ich bekomme hier mehrfach die Woche Sicherheitsupdates für alle > möglicht Software. Eben, alle mögliche Bananasoft, nicht Kfz :-] > Von den großen Autobauern, nehme >> ich mal an, die damit schlampige Programmierung entschuldigen wollen. >> Für mehr als Mogelsoftware scheint es dort nicht zu reichen, zumindest >> nicht ohne nachhaltigen äußeren Druck :-] > > Nach allem was ich gelesen habe war zumindest die Codequalität der > Mogelsoftware sehr gut. Na also, geht doch :-) Ähm, war die Mogelsoftware auch sicher gegen Hackerangriffe? DoDi
[toc] | [prev] | [next] | [standalone]
Page 12 of 14 — ← Prev page 1 … 10 11 [12] 13 14 Next page →
Back to top | Article view | de.sci.electronics
csiph-web