破解“我的” Tesla Model 3 -＞ 01安全概述

• 翻译加上个人小小尝试，膜拜大佬！！！！

目录

0x00 概述

• 我最近买了一辆特斯拉 Model 3，因为我是个超级书呆子，所以我一直在花很多时间研究系统，并试图对我的汽车进行逆向工程 弄清楚 how to root my car(这句不翻译 精髓了吧)。
• 我从事机器学习基础架构的工作，因此我希望能够深入了解自动驾驶仪/FSD 的工作原理，以及除了 UI 显示的有限信息之外，它实际上还能做什么。我知道有些人已经设法得到了这个副本。 使用内部 API 在屏幕上显示消息。版本 2020.12.11.1

0x01 现有研究

• 很多关于内部系统[the internal systems]的现有知识都是针对老式 Model S 汽车的，因为它们的安全性几乎不存在。Model 3（可能是较新的 Model S/X/Y）具有多层安全措施。高级架构非常相似，但已经加强了很多。

1-Model 3

• lewurm’s blog posts about his Model 3

2-Model S/X

• green’s analysis from his older Model S
• Lunar’s Model S MCU1 info dumps/wiki
• Reverse Engineering the Tesla Firmware Update Process
• freedomEV for Model S MCU1

(1) 腾讯科恩安全实验室 [Tencent Keen Security Lab]

• Free-Fall: Hacking Tesla From Wireless To CAN BUS
• Over-The-Air: How We Remotely Compromised The Gateway, BCM, and Autopilot ECUs Of Tesla Cars

0x02 特斯拉安全研究员计划

• 在我拿我的车之前，我就注册了特斯拉漏洞奖励计划，我的车是一辆用于研究的注册[research-registered vehicle]车。如果你有兴趣“捅（捣腾）”你的车，我强烈建议你注册，如果你把车“玩”坏了，特斯拉会尽力修复它。

如果通过你的善意安全研究，你（预先被批准的善意安全研究人员）导致软件问题需要更新或“刷新”你的研究注册车辆，作为善意行为，特斯拉应尽合理努力通过无线更新或者在服务中心提供帮助以使用我们的标准服务工具或我们认为适当的其他措施来恢复车辆软件的研究注册车辆上的 Tesla 软件。
https://www.tesla.com/about/security

0x03 车内布局

• 所有更高级别的组件都通过内部以太网交换机连接。这些包括：- cid/ice - 这是控制显示器和所有媒体系统（如声音）的计算机。 - 192.168.90.100- **自动驾驶主计算机和辅助计算机**。 - 192.168.90.103 - ap/ape- 192.168.90.105 - ap-b/ape-b- 网关 - 这主要是 UDP 服务器，它控制以太网端（cid/自动驾驶仪）和网关之间的交换机、车辆配置和代理请求 - 和192.168.90.102 CAN BUS 到电机控制器[motor controllers]和传感器。- 调制解调器[Modem] - 这是 LTE 调制解调器 - 192.168.90.60- 调谐器[Tuner] - 这是为AM/FM收音机准备的。不存在于包括我的车在内的较新的 Model 3 汽车上。没有 AM/FM 收音机似乎是一个安全问题，所以我看到它被移除了表示很惊讶。 - 192.168.90.60

0x04 seceth - 安全以太网 TCAM

• 内部汽车网络似乎使用 Marvel 88EA6321 作为交换机。这是一个自动千兆交换机。
• 大多数连接都使用 100BASE-T1，它是用于以太网的 2 线 PHY(100BASE-T1 Ethernet: the evolution of automotive networking)。自动驾驶计算机、调制解调器、调谐器、网关、CID 都使用 100Base-T1。车上有两个标准以太网端口。一个位于 CID 主板上，具有标准以太网插孔。另一个位于驾驶员侧脚部空间并具有定制连接器。
• 第一个，位于辅助驾驶位置那一侧：- - 板子的细节 -
• 第二个位于主驾驶位放脚部上侧：- - 细节： -

1-DSA

• 该交换机似乎正在使用一种称为分布式交换机架构 和 TCAM 的东西。
• DSA 允许交换机由单独的处理器控制。在 Model 3 中，我相信网关控制了它。我没有在 CID 中看到任何对 Linux dsa 子系统的引用[references]。

2-TCAM

• TCAM 是一种特殊类型的内存[memory]，可以在一个完整的循环中进行非常快速的查找/过滤[lookups/filters]。这允许网关为要应用的交换机指定数据包过滤器。默认情况下，驾驶员侧的以太网端口被这些规则所禁用[亲测，确实被禁用了 多来点大佬 找到入侵方法 我等着白嫖]。CID 主板上的诊断插孔只能访问 CID 上的端口 8080（Odin）和 22（SSH）。
• 有一种方法可以禁用安全以太网，但这似乎只能由特斯拉工程和可能的服务通过 Odin 访问。
• 很显然有一个每日更改的代码[a daily changed code]可以解锁诊断端口/服务模式。该服务可能必须通过特斯拉通用工具箱[Tesla via Toolbox]那里获取。

0x05 Hermes - 与"母舰(???)"对话 [Talking to the Mothership]

• 老款Model S 车使用持久的OpenVPN连接与特斯拉所称的“母舰”进行通信。与特斯拉的所有通信都通过此VPN连接，因此无法嗅探任何更新。
• Model 3 没有使用 OpenVPN，而是运行了一个名为 Hermes 的代理服务。Hermes 是一个相对简单的服务，可以将 CID 上未经身份验证的请求代理到母舰。据推测，在 500,000 多辆汽车上维持持久的 OpenVPN 连接是不可扩展的，因此他们转向了开销较低的解决方案。
• Hermes 还允许特斯拉向汽车本身发出请求，并从中获取日志。据推测，这就是特斯拉如何在没有完整软件更新的情况下启用诸如全自动驾驶等功能以及提供远程服务的方式。

1-证书

• 每辆车都为 Hermes/OpenVPN 颁发了唯一的客户端证书，并且它们会定期轮换。这使得抓取固件图像或检查特斯拉的后端等事情变得非常困难，因为您首先必须获得对汽车的 root 访问权限。
• 这些证书位于/var/lib/car_creds/car.{crt,key}. [这个我没找到，当然我不是在实车上测试的，我只是在Tesla Model 3 固件中提取的(squashfs文件系统)文件系统中寻找的，如果哪位大佬 找到了 @一下我 怎么整]

# Phone Home connects to devices over Hermes based on the# Hermes certificate CN....
#     subject=#     CN=BANGELOM300000001#     OU=Tesla Motors#     O=Tesla#     L=Palo Alto#     ST=California#     C=US

• 每辆车都有一个特定的通用名称，只能在内部访问，以使攻击者更难尝试伪造证书。这与 SSH 相关，我们稍后会看到。

2-二进制文件

• 有一堆不同的hermes二进制文件。它们似乎都是用 Go编写的。很高兴看到我最喜欢的编程语言在我的车上运行。[亲测，这个确实能验证，大佬说的没错，再次膜拜！！！]

$ ls opt/hermes/
hermes_client*     hermes_fileupload*  hermes_historylogs*  hermes_teleforce*
hermes_eventlogs*  hermes_grablogs*    hermes_proxy*

$ file /opt/hermes/hermes_client
opt/hermes/hermes_client: sticky ELF 64-bit LSB executable, x86-64, version 1(SYSV), statically linked, Go BuildID=JRZRLflVY89A6p67rwkt/nb9KmeWMLadrBGvRVujH/aJPtciQz8Xldpa7VcVy_/XzIY9KY7sZI0KdwLYOK5, stripped

• 
• 很容易看到他们在二进制文件中使用了哪些 OSS 库 strings hermes_client | rg vendor /. 也许我会在后续文章中分析Hermes本身。

0x06 Odin - 服务接口

• Odin 是一个运行在每辆车上的 python 3 服务。它用于对汽车进行各种维护操作，例如校准雷达和摄像头。如果您连接到内部汽车网络，您可以通过 http://192.168.90.100:8080 访问它。
• [我最先通过nmap端口扫描的时候就看到了开放了8080端口，但是经过我测试发现8080提供的服务不可用，下面贴个图，有哪位大佬有 比较好的 侵入方案 请告知我一下 谢谢！！！]
• 

1-Odin认证

• 点击这个的时候会弹下面那个错误：
• 

{error: "Token 2.0 not found."}

• 我深入研究了源代码。
• 特斯拉对所有事情都使用签名证书[signed certificates]。
• 从安全的角度来看，这是惊人的。从“I want to get root on my car”的角度来看，这太糟糕了。
• 每个令牌都包含一个安全级别。这些级别授予对不同 Odin 命令的访问权限。这允许不同层次的服务获得他们完成工作所需的最低权限。
• 这些分为principals和remote_execution_permissions。大概principals需要通过诊断以太网端口进行物理访问。
• Odin任务中列出的principals级别为：- tbx-internal- tbx-external- tbx-technical-specialist- tbx-engineering- tbx-service
• 这些似乎主要是在制造过程中可能使用的内部汽车测试。非内部/外部principals出现的时间是PROC_ICE_X_LOGS-UPLOADER和ICE_DEASSOCIATE_PRODUCT_ID。第二个仅仅用于工程，似乎可以擦除车辆 VIN 和汽车配置。
• ODIN任务中列出的remote_execution_permission级别是：- tbx-service- tbx-service-infotainment- tbx-technical-specialist- tbx-service-engineering- tbx-engineering- tbx-mothership
• 像TEST-BASH_ICE_X_SEARCH-UI-ALERTS这样的东西可以由tbx-service、tbx-service-engineering和tbx-mothership访问。
• 像PROC_ICE_X_SET-VEHICLE-CONFIG这样的东西只能由tbx-mothership访问。
• 令牌[token]由中间证书签名。此中间证书公钥作为令牌的一部分包含在令牌中，并由特斯拉的root CA签名。据我所知，这遵循了web CA的标准安全实践，以防止root证书被泄露。

2-Odin网络

• Odin 以一种非常有趣的方式实现。有一个tasks和 networks的列表。这些任务是可以由具有特定权限的人执行的高级操作。
• 这些lib文件是“networks”[这句不是很理解]，似乎是一个专门用于创建服务任务的[a domain specific language]领域特定语言/UI程序。
• networks非常接近 JSON，但存储在.py文件中。
• 这是其中的摘录：

network ={..."get_success":{"default":{"datatype":"Bool","value":False},"position":{"y":265.22259521484375,"x":108.96072387695312},"variable":{"value":"success"},"value":{"datatype":"Bool"},"type":"networks.Get",},"IfThen":{"position":{"y":340.1793670654297,"x":297.02069091796875},"expr":{"datatype":"Bool","connection":"get_success.value"},"if_true":{"connection":"exit.exit"},"type":"control.IfThen","if_false":{"connection":"capturemetric.capture"},},...}

• 每个network都由一系列节点构成，这些节点的类型描述了它们的功能。这些节点可以通过“连接”从其他节点获取输入[consume inputs 我翻译的是 获取输入]。每种节点类型的实际逻辑是用标准 python 实现的。
• position字段似乎表明这些networks是通过 UI 工具创建的。

3-工具箱

• Tesla 的服务工具叫做 Toolbox。好像有两个版本。1. 一个可以下载并在windows下运行的程序：https://toolbox.teslamotors.com/2. 还有一个较新的基于网络的工具：https://toolbox.tesla.com/
• 查看基于 Web 的工具的源代码，我们看到对身份验证令牌[auth tokens]和任务名称的引用。这个工具箱界面是在每辆车上运行的Odin服务器的前端。
• 据说有一些俄罗斯人会以 5000 美元的价格卖给你一个破解版的 Toolbox。看看 Odin 是如何实现的，我想这个破解版只适用于旧的Model S/X汽车，因为Model 3需要特斯拉的签名证书[the Model 3 requires signed certs from Tesla]。

0x07 Fused vs Unfused [融合与未融合 额 这个翻译好尬]

• 好像翻译成 装有保险丝的和未装保险丝的 更合理 有许多基于英特尔 SOC’s eFuse [电子熔丝] 的安全措施。这是一个内置在处理器中的位[bit]，只能被写入一次。在制造过程中，在供应汽车后，汽车的efuse 被设置为“熔断”["fuse"]，用于防止对系统进行任何未经授权的修改。
• 开发汽车时处于"unfused"状态，以便于调试。当汽车"unfused"时，所有防火墙规则都被禁用，使用一组不同的 SSH 密钥并禁用 Odin 身份验证[authentication]。
• 我在 eBay 上看到过至少一台"unfused"的车载电脑。我很想知道他们是如何获得它的。你可以买一个看看是否可以将标准汽车固件上传到它并以"unfused"/hackable可破解模式运行它会很有趣。
• 我从一位曾经在英特尔工作过的朋友那里听说，[the fuses]保险丝应该只被写入一次，但有时可能会多次写入它们并使它们进入"broken"状态，从而返回错误的值。[fuser]熔凝器似乎是将同一个值写入10次，所以特斯拉可能已经缓解了这一问题。

0x08 SSH

1-验证

• Model S 过去在 CID/APE 上有一个 SSH 密钥，可以通过 SSH 相互连接。他们还启用了密码身份验证，因此你只需使用默认密码即可获得 root 访问权限。现在已经不是这样了。
• 正如我之前提到的，特斯拉对所有东西都使用签名证书[signed certifcates]，这包括 SSH。要通过 SSH 连接到汽车，你需要一个由特斯拉 CA 签名的该车的 SSH 证书或他们的一个恢复密钥[recovery keys]。为了确保一个泄露的证书不会在其他地方重复使用，密钥包括该特定汽车的“原则[principle]”。

PubkeyAuthentication yes
AuthorizedKeysFile /etc/ssh/authorized_keys_prod

# Support SSH certificate-based authentication.  Certificates must be signed# by the TrustedUserCAKeys and must contain the authorized principal string# that is returned by AuthorizedPrincipalsCommand.
TrustedUserCAKeys /etc/ssh/ssh_ca_developers_prod.pub
AuthorizedPrincipalsCommand /sbin/authorized_principal
AuthorizedPrincipalsCommandUser root

• 有一些备份密钥可用于 SSH，但密钥长度似乎很长，并且可能在某个地方的冷存储[cold storage]中作为最后的手段，如果他们所有的 CA 基础设施全部奔溃的话。[还是太菜了，不知道怎么利用 呜呜呜呜]
• 

(1)

/sbin/authorized_principle

[纠正

/sbin/authorized_principal

]

• 
• 不过我尝试查看的时候发生了很奇怪的问题 [所以提醒大家 做研究的时候一定要一心一意，看岔几个字母，寄半天，手动狗头！！！！] - - 抱歉我看错了，我没找到作者提到的那个 文件 ，只找到了上一个图中那个authorized_principal文件，经分析这个文件与作者提到的吻合（巧合还是大佬也会犯错 有意思）

/sbin # cat authorized_principal#!/bin/shCERT_PATH=/var/lib/car_creds/car.crt
VIN_PATH=/var/etc/vin

# Phone Home connects to devices over Hermes based on the# Hermes certificate CN.  We therefore want the SSH authorized# principal to match the Hermes certificate CN to avoid getting# locked out due to mismatches.if[-s"$CERT_PATH"];then# The openssl command retrieves the subject field from the Hermes certificate.##     subject= /CN=BANGELOM300000001/OU=Tesla Motors/O=Tesla/L=Palo Alto/ST=California/C=US## The tr command replaces all forward slashes with new lines.##     subject=#     CN=BANGELOM300000001#     OU=Tesla Motors#     O=Tesla#     L=Palo Alto#     ST=California#     C=US## Finally, the sed command isolates the Common Name (CN) field.##     BANGELOM300000001## The sed options are as follows.##     -n        don't print lines by default#     s/        select#     ^CN=/     lines that start with "CN="#     /         replace with nothing (remove the "CN=")#     p         print the line that matched#CN=$(openssl x509 -noout-subject-in"$CERT_PATH"2> /dev/null |tr / '\n'|sed-n's/^CN=//p')if[-n"$CN"];thenecho tesla:motors:vehicle:"$CN"exit0fifi# Fallback to the VIN, which is externally visible on the vehicle.if[-s"$VIN_PATH"];thenVIN=$(cat"$VIN_PATH")if["$VIN"!="unknown"];thenecho tesla:motors:vehicle:"$VIN"exit0fifi# Fallback to the unprovisioned otherwise.echo tesla:motors:vehicle:unprovisioned

• 此脚本解析 Hermes 证书以获取汽车的通用名称。它确保使用的 SSH 证书具有原则tesla:motors:vehicle:$CN ，因此证书不能从一辆车重复使用到另一辆车。
• 如果没有 Hermes 证书，它会退回到tesla:motors:vehicle:$VIN.
• 如果没有 VIN码，则需要tesla:motors:vehicle:unprovisioned. 大概后两者是在开发过程中使用的，或在制造过程中作为最后的手段。

2-协议和密码 [Protocols & Ciphers]

• 从2020.12.11.1版本开始，该车使用的是2020年4月21日的OpenSSH和OpenSSL版本。那里似乎没有任何已知的漏洞。
• 特斯拉在使用最新的软件方面已经有了很大的进步。以前在Model S上发生的一些漏洞都是由于古老的软件版本造成的。

alarm@tesla ~>ssh-v192.168.90.100
OpenSSH_8.2p1, OpenSSL 1.1.1g  21 Apr 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 192.168.90.100 [192.168.90.100] port 22.
debug1: Connection established.
debug1: identity file /home/alarm/.ssh/id_rsa type0
debug1: identity file /home/alarm/.ssh/id_rsa-cert type-1
debug1: identity file /home/alarm/.ssh/id_dsa type-1
debug1: identity file /home/alarm/.ssh/id_dsa-cert type-1
debug1: identity file /home/alarm/.ssh/id_ecdsa type-1
debug1: identity file /home/alarm/.ssh/id_ecdsa-cert type-1
debug1: identity file /home/alarm/.ssh/id_ecdsa_sk type-1
debug1: identity file /home/alarm/.ssh/id_ecdsa_sk-cert type-1
debug1: identity file /home/alarm/.ssh/id_ed25519 type-1
debug1: identity file /home/alarm/.ssh/id_ed25519-cert type-1
debug1: identity file /home/alarm/.ssh/id_ed25519_sk type-1
debug1: identity file /home/alarm/.ssh/id_ed25519_sk-cert type-1
debug1: identity file /home/alarm/.ssh/id_xmss type-1
debug1: identity file /home/alarm/.ssh/id_xmss-cert type-1
debug1: Local version string SSH-2.0-OpenSSH_8.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9
debug1: match: OpenSSH_7.9 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.90.100:22 as 'alarm'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC:
<implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC:
<implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256
SHA256:g2LMKjlsobIXVimHcaP58JLahYrhyzoqJevYMq0LTuQ
debug1: Host '192.168.90.100' is known and matches the ECDSA host key.
debug1: Found key in /home/alarm/.ssh/known_hosts:4
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/alarm/.ssh/id_rsa RSA
SHA256:C6m79wZNJKGfQxEHWp2MunUjssfKgYq4FNZQ6ncrPZ8
debug1: Will attempt key: /home/alarm/.ssh/id_dsa
debug1: Will attempt key: /home/alarm/.ssh/id_ecdsa
debug1: Will attempt key: /home/alarm/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/alarm/.ssh/id_ed25519
debug1: Will attempt key: /home/alarm/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/alarm/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info:
server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/alarm/.ssh/id_rsa RSA
SHA256:C6m79wZNJKGfQxEHWp2MunUjssfKgYq4FNZQ6ncrPZ8
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/alarm/.ssh/id_dsa
debug1: Trying private key: /home/alarm/.ssh/id_ecdsa
debug1: Trying private key: /home/alarm/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/alarm/.ssh/id_ed25519
debug1: Trying private key: /home/alarm/.ssh/id_ed25519_sk
debug1: Trying private key: /home/alarm/.ssh/id_xmss
debug1: No more authentication methods to try.
[email protected]: Permission denied (publickey).

• 我也浅试了一下，但然这是没有用的，因为我没有特斯拉，我怎么连！！扎心了
• 
• 当然我拿我BOSS的Model 3 试过，狗头 - - 吐槽一下，垃圾的Windows 系统，最后还是靠的你，是我对你偏见太大了（因为我的kali 没有正确识别我的物理网卡，真tm 办正事的时候就寄！！！）

0x09 磁盘/固件

1- dm-verity

• CID 的根文件系统以只读方式挂载，以防止对正在运行的代码进行任何更改。用户数据有几个分区，例如 Spotify logins、various configs、map data等，但这些分区都是不可执行的。
• 根文件系统也是由dm-verity内核模块验证的，该模块在启动时对文件系统进行加密[ hashes]。这意味着几乎不可能通过修改文件系统来获得根权限。

2-内核/安全启动[

Secure Boot

]

• 我对正在使用的英特尔 SOC 了解不多，但它确实支持某种形式的安全启动。我无法检查它是否已启用，但如果启用我不会感到惊讶。如果未启用，则应该可以修改内核以禁用 dm-verity 并启动未签名的镜像文件[image]。
• 其实这里就是难点，我也在这一块卡住了 Linux内核没怎么学过，看来得找时间恶补一下了，tmd，网安要学的东西好多，要是家里有个几千头牛就好了，害

3- Updater

• 部署到汽车周围各种控制器的所有固件 blob 均由 Tesla 签名。更新程序在更新之前检查签名以确保没有任何奇怪的事情发生。这意味着我们不能 MITM 更新程序来安装修改后的固件。
• 如果您可以绕过 seceth 规则，你可以直接与更新程序建立回话，并手动为其提供要安装的镜像，但必须由 Tesla 签名。在 Keen Security Lab 的一篇论文中，他们提到特斯拉已经添加了一项安全措施，以防止更新程序安装旧版本的软件。这几乎消除了降级到更易受攻击的固件版本的任何希望。- 马老板 你看着办吧

0x0A CAN总线

• 车内有许多可以访问的 CAN 总线连接。CAN 总线是未加密的，因此我们可以从中提取大量内部数据。有许多项目可以对消息含义进行逆向工程。
• 你可以使用一些现成的线束[harnesses]/诊断工具来阅​​读它们。比如：但是这个链接失效
• 
• 反正我也买不起 卖光了 刚好断了我的念想
• 我联系了 EVTV Motor Verks 的人，他们告诉我如果汽车检测到任何注入/恶意 CAN 总线消息，整个汽车就会关闭。我还没有尝试在这上面注入消息，所以我不确定这些保护措施的范围有多大。

0x0B Services & AppArmor

• 车内几乎所有的各种服务都启用了 AppArmor，并以非特权用户身份运行。
• Spotify 在 spotify 用户下作为服务运行。似乎没有任何方法可以将新的沙盒应用程序部署到系统上。我以为会有类似于安卓APK的东西，用于Spotify这样的东西，但它只是一个Qt应用程序。

0x0C iptables / Firewall Rules

• 有大量 iptables 规则限制所有的网络通信。防火墙规则是在每个用户的基础上指定的，这是我以前从未见过的。这意味着调制解调器之类的东西受到限制，因此他们只能由调制解调器控制器和更新程序访问。
• 有转发规则[forwarding rules]，因此 [Autopilot]自动驾驶计算机可以直接与 Internet 通信，但只允许出站连接。驾驶汽车的电脑[the computer driving the car]直接连接 Internet ，这有点可怕。

# Setup Internet sharing for ape
iptables -A FORWARD -i eth0 -o eth0.2 -s$APE_LIST-d192.168.20.0/24 -j DROP # disallow forwarding to modem deviceforiin eth0.2 wlan0 ;do
    iptables -A FORWARD -i eth0 -o$i-s$APE_LIST-j ACCEPT
    iptables -A FORWARD -i$i-o eth0 -d$APE_LIST-m state --state RELATED,ESTABLISHED -j ACCEPT
    iptables -t nat -A POSTROUTING -o$i-j MASQUERADE -s$APE_LISTdoneecho1> /proc/sys/net/ipv4/ip_forward

• 说实话 上面这个脚本 我没分析明白，如果那个 大佬看懂了 请@我一下，感恩的心！

0x0D Escalator

• 有一个服务在车上运行，叫做escalator. 这是一项允许来自特定进程/用户的特定请求以 root 身份运行的服务。在 Model S 上，只有一个进程可以调用的硬编码 root 密码，但现在所有提升的权限都通过一个点运行。
• 如果您设法在汽车上拿到一个 shell，这将是寻找漏洞以获取 root 权限的好地方。

0x0E 汽车内部 APIs

• 有许多内部汽车API可通过未经身份验证的HTTP访问。防火墙规则主要阻止这些被外部访问以及不应该被进程访问。
• 我能够访问其中的一些内容，我将发布一篇关于我发现的一些内容的后续文章。
• 到此，第一部分结束，后续的章节我也会在今后的日子里慢慢尝试及复现。最后 respect 每一个为网络安全做出贡献的各位，尤其是各位大佬，感谢你们的无私奉献，让我这个小弱鸡，也能接触到比较复杂的领域。
• **当然，如果有在研究车联网安全的小伙伴也可以私信我，我近期想建立一个技术交流、论文研讨的群，希望能逮到大佬**。
•