str(float("100.0")) + "%"

Because this repo is going viral from time to time to developers, I’m open for discussion if you want to promote a product/service in this README file. Just mail me at XXXX

Ew.

Ein Kollege hat sich sein “normales” Fahrrad selbst mit einem Chinesischem Nabenmotor elektrifiziert, dort ist aus Bastler Sicht alles sehr viel zugänglicher. Für ein zukünftiges E-Bike würde ich persönlich also auf jeden Fall in die Richtung tendieren.

Dazu sei auch gesagt, dass man gute Teile, um ein bestehendes Rad inklusive Akku auf Pedelec umzurüsten, bereits verhältnismäßig günstig für um die 500€ bekommt. Das sieht dann am Ende nicht so sexy wie ein fertiges E-Bike aus, da die Kabel normalerweise am statt im Rahmen verlegt werden, aber so ein Umbau ist naturgemäß modular und auch transferierbar. Der Umbau ist eigentlich für jeden machbar, Videos gibt es genug.

Man sollte sich aber mit den Vor- und Nachteilen der verschiedenen Antriebsarten auseinandersetzen, wesentlich hier Mittel- und Nabenmotor. Auch werden viele Kits so ausgeliefert, dass theoretisch eine in Deutschland für Pedelecs nicht zugelassene Konfiguration möglich ist, beispielsweise durch Gashebel und höherer Unterstützung als 25 km/h.

The problem isn’t necessarily “stuff not sent over vpn isn’t encrypted”. Everyone uses TLS.

Never said it was. It’s a noteworthy detail, since some (rare) HTTP unencrypted traffic as well as LAN traffic in general is a bit more concerning than your standard SSL traffic contentwise, apart from the IP.

For this to be practical you first need a botnet of compromised home routers

This is more of a Café/Hotel Wi-Fi thing IMO. While it may take some kind of effort to get control over some shitty IoT device in your typical home environment, pretty much every script kiddie can at least force spoof the DHCP server in an open network.

Interesting read.

So, in short:

• The attacker needs to have access to your LAN and become the DHCP server, e.g. by a starvation attack or timing attacks
• The attacked host system needs to support DHCP option 121 (atm basically every OS except Android)
• by abusing DHCP option 121, the attacker can push routes to the attacked host system that supersede other rules in most network stacks by having a more specific prefix, e.g. a 192.168.1.1/32 will supersede 0.0.0.0/0
• The attacker can now force the attacked host system to route the traffic intended for a VPN virtual network interface (to be encrypted and forwarded to the VPN server) to the (physical) interface used for DHCP
• This leads to traffic intended to be sent over the VPN to not get encrypted and being sent outside the tunnel.
• This attack can be used before or after a VPN connection is established
• Since the VPN tunnel is still established, any implemented kill switch doesn’t get triggered

DHCP option 121 is still used for a reason, especially in business networks. At least on Linux, using network namespaces will fix this. Firewall mitigations can also work, but create other (very theoretical) attack surfaces.