Reverse engineering a car key fob signal (Part 1)

Context 上下文

I’ve had the curiosity to explore radio communication protocols for a few years now, ever since I’ve started fiddling around with an RTL-SDR dongle. I always had the goal of figuring out how data is transmitted in remote controls (car key fobs particularly), trying replay attacks, and other possible attack vectors.
自从我开始摆弄 RTL-SDR 加密狗以来，我就一直对探索无线电通信协议产生了好奇。我一直的目标是弄清楚数据是如何在遥控器（尤其是汽车钥匙扣）中传输的，尝试重放攻击和其他可能的攻击媒介。

Despite capturing some car key fob signals over the years, I haven’t had the chance of doing meaningful analysis on them, and that’s mainly due to the limited access I had to cars I could test on.
尽管多年来捕捉到了一些汽车遥控钥匙信号，但我没有机会对它们进行有意义的分析，这主要是由于我对可以测试的汽车的访问有限。

This blog post aims to bring the uninitiated through my journey of having successfully reverse engineered and replayed a car’s key fob signal last year, starting from the very basic concepts of radio frequency and going all the way through my entire thought process while I was working on this project.
这篇博文旨在让外行了解我去年成功逆向工程和重放汽车遥控钥匙信号的旅程，从射频的基本概念开始，一直到我在做这个项目时的整个思考过程。

Another goal I guess is to also prove that most cars are definitely not that easy to steal using replay attacks (unless it’s a Honda, lol), despite Canada’s recent ban of the Flipper Zero, and them claiming the risk warrants the ban of a device made of very cheap and accessible wireless modules.
我猜的另一个目标是证明大多数汽车绝对不是那么容易使用重放攻击来窃取的（除非是本田，哈哈），尽管加拿大最近禁止了 Flipper Zero，并且他们声称风险保证禁止由非常便宜和可访问的无线模块制成的设备。

Hardware used 使用的硬件

RTL-SDR RTL-SDR格式

I’ve had my first dive into the world of radio frequency back in 2016 when I learned that a very cheap (~$10) terrestrial TV/radio USB dongle can easily be turned into a multi-purpose RF receiver to inspect and decode pretty much anything happening in the range of 24 to 1750 MHz – this device is widely known as ‘RTL-SDR’:
早在 2016 年，我就第一次涉足射频世界，当时我了解到一个非常便宜（~10 美元）的地面电视/无线电 USB 加密狗可以很容易地变成一个多用途射频接收器，以检查和解码 24 到 1750 MHz 范围内发生的几乎所有事情——这个设备被广泛称为“RTL-SDR”：

The secret why this cheap device is very powerful, is the simple fact that it uses a chip which allows the use of SDR (software defined radio). It turns out that this chip (RTL2832U) allowed skipping the signal processing that usually happens on the hardware-level which converts the raw signal into ‘meaningful’ data to be used by the host device (a TV/radio feed in the case of this device).
这种廉价设备非常强大的秘诀在于它使用允许使用 SDR（软件定义无线电）的芯片。事实证明，该芯片（RTL2832U）允许跳过通常发生在硬件级别的信号处理，该处理将原始信号转换为“有意义的”数据以供主机设备使用（在此设备的情况下为电视/广播馈送）。

By having direct access to the raw I/Q data, we can receive, visualize and save pretty much any signal in raw format, without needing to know the specifics of the RF configuration used to transmit (modulation, bandwidth, data rate, etc.), since we can analyze/process the raw data ourselves. This effectively gives us a window to scan for virtually any activity on the radio spectrum under the 1.7 GHz frequency.
通过直接访问原始 I/Q 数据，我们可以接收、可视化和保存几乎任何原始格式的信号，而无需了解用于传输的射频配置（调制、带宽、数据速率等）的细节，因为我们可以自己分析/处理原始数据。这有效地为我们提供了一个窗口，可以在 1.7 GHz 频率下扫描无线电频谱上的几乎任何活动。

Flipper Zero 鳍状肢零

The Flipper Zero is an electronic gadget which attracted a lot of attention lately for being a hacker/troll’s ultimate Swiss knife, since it hosts a bunch of wireless hardware modules that allow ‘interacting with’ everyday electronics and consumer appliances.
Flipper Zero是一款电子产品，最近因成为黑客/巨魔的终极瑞士刀而备受关注，因为它拥有一堆无线硬件模块，可以与日常电子产品和消费电器进行“交互”。

The module that’s interesting to us in the Flipper is the Sub-GHz one, which is essentially a CC1101 chip that supports frequencies that are typically used in wireless consumer devices, and that are under 1 GHz, hence the name of the module.
我们在 Flipper 中感兴趣的模块是 Sub-GHz 模块，它本质上是一个 CC1101 芯片，支持无线消费类设备中通常使用的频率，并且低于 1 GHz，因此该模块的名称。

It’s important to note, however, that one could just buy the CC1101 module separately ($5+) and make it work with an Arduino/Raspberry Pi or simply a USB-to-TTL adapter, but the Flipper is definitely cooler and more practical. ¯\_(ツ)_/¯
然而，需要注意的是，人们可以单独购买 CC1101 模块（5 美元+），并使其与 Arduino/Raspberry Pi 或简单的 USB 转 TTL 适配器配合使用，但 Flipper 绝对更酷、更实用。¯\_(ツ)_/¯

CC1101 vs RTL2832U CC1101 与 RTL2832U

The CC1101 chip in the Flipper Zero, unlike the RTL2832U chip that’s on the RTL-SDR, is actually a transceiver module (supports sending and receiving), which means the Flipper Zero is the device we’ll be using to send signals.
与RTL-SDR上的RTL2832U芯片不同，Flipper Zero中的CC1101芯片实际上是一个收发器模块（支持发送和接收），这意味着Flipper Zero是我们将用来发送信号的设备。

However, the CC1101 chip doesn’t support SDR, which means that it would only send back data that it had completely processed. In other terms, the CC1101 will only be useful to us if we set the right RF configuration of the transmitted signal.
但是，CC1101 芯片不支持 SDR，这意味着它只会发回已完全处理的数据。换句话说，CC1101 只有在我们设置了传输信号的正确射频配置时才对我们有用。

Note: Transceiver SDR devices do exist of course, but they tend to be very pricey.
注意：收发器SDR设备当然存在，但它们往往非常昂贵。

Radio frequency signal basics (oversimplified)
射频信号基础知识（过于简化）

Now that we know a bit about the hardware we’ll be using, let’s go through some minimum basic concepts that are needed to tackle this subject.
现在我们已经对我们将要使用的硬件有了一定的了解，让我们来看看解决这个主题所需的一些最低基本概念。

Intro 介绍

Radio frequency transmissions use radio waves, which are a type of electromagnetic radiation, in order to send signals.
射频传输使用无线电波（一种电磁辐射）来发送信号。

These waves are of a typically higher frequency than the original signal we’re transmitting and this is to ensure reliability in sending data, since signals can have varying characteristics that make sending them as radio waves impractical and susceptible to interference and weak travel distance.
这些波的频率通常比我们传输的原始信号高，这是为了确保发送数据的可靠性，因为信号可能具有不同的特性，这使得将它们作为无线电波发送是不切实际的，并且容易受到干扰和弱传播距离。

These waves are called carrier waves, since they are essentially modified to carry the original signal reliably through the air (more on this below).
这些波被称为载波，因为它们基本上被修改为在空气中可靠地携带原始信号（更多内容见下文）。

Let’s take a look at some of the basic information needed to send/receive a radio signal:
让我们看一下发送/接收无线电信号所需的一些基本信息：

Frequency 频率

This one is self-explanatory, it’s the number of times a second a carrier wave occurs. Frequency affects the wavelength (the higher the frequency the shorter the waves). This parameter is also typically used to define the communication channel.
这是不言自明的，它是载波每秒发生的次数。频率影响波长（频率越高，波越短）。此参数通常也用于定义通信通道。

Modulation 调制

This refers to the way a signal is represented in the radio waves. The two most common modulation types, which I’m sure most people already know of, are:
这是指信号在无线电波中的表示方式。我相信大多数人已经知道的两种最常见的调制类型是：

AM (amplitude modulation) and FM (frequency modulation).
AM（调幅）和 FM（调频）。

The difference between these is simply the fact that for AM, the signal is modulated (encoded) in amplitude (or strength), which roughly means that the change in signal strength on the carrier waves is how the data is represented.
两者之间的区别在于，对于AM，信号在幅度（或强度）上被调制（编码），这大致意味着载波上信号强度的变化是数据的表示方式。

For FM, as one can guess, the data is rather modulated in frequency. So, changes in the frequency of the waves are used here to determine the data.
对于FM，正如人们可以猜到的那样，数据的频率相当调制。因此，这里使用波频率的变化来确定数据。

This is well visualized in this animation I found on Wikipedia (the ‘signal’ graph represents the data we’re trying to transmit):
这在我在维基百科上找到的这个动画中得到了很好的可视化（“信号”图代表我们试图传输的数据）：

Modulations can also have different subtypes and characteristics which we’ll talk about later on.
调制也可以有不同的亚型和特征，我们将在后面讨论。

Bandwidth 带宽

This refers to the range of frequencies occupied by a modulated RF signal, or in other words, the difference between the highest and the lowest frequency a modulated signal can have. This essentially dictates the amount of data a signal can carry.
这是指调制射频信号所占的频率范围，或者换句话说，调制信号可以具有的最高频率和最低频率之间的差值。这基本上决定了信号可以携带的数据量。

Since the rest of the radio characteristics are not terribly important for us to know at this stage, let’s move on to the fun stuff!
由于现阶段我们了解其余的无线电特性并不是很重要，因此让我们继续讨论有趣的东西！

Visual analysis 视觉分析

SDR#

SDR# is a free, intuitive, computer-based DSP (Digital Signal Processing) application for SDR written in C# with a focus on performance. It allows visualizing the radio spectrum in real time, and supports the demodulation of some common modulations. It also supports third-party plugins for custom modulations and integrations.
SDR# 是一款免费、直观、基于计算机的 SDP 应用程序，用 C# 编写，专注于性能。它允许实时可视化无线电频谱，并支持一些常见调制的解调。它还支持用于自定义调制和集成的第三方插件。

We’ll be using this software for our signal discovery and initial analysis phase.
我们将使用此软件进行信号发现和初始分析阶段。

Signal discovery 信号发现

By tuning into the 433.92 MHz frequency with our RTL-SDR dongle plugged in (using the WinUSB driver instead of the stock DVB-T one), we can watch the activity of most remote controls in close proximity (433.92 MHz being the standard unregulated frequency in the EU and other neighboring countries, including Morocco, where I live).
通过插入我们的 RTL-SDR 加密狗（使用 WinUSB 驱动程序而不是库存的 DVB-T 驱动程序）调谐到 433.92 MHz 频率，我们可以近距离观察大多数遥控器的活动（433.92 MHz 是欧盟和其他邻国的标准非管制频率，包括我居住的摩洛哥）。

On each car key fob button press we instantly notice that there’s 3 successive short bursts generated, as can be seen on the waterfall view under the spectrum visualizer:
在每次按下汽车钥匙扣按钮时，我们都会立即注意到会产生 3 个连续的短脉冲，如光谱可视化工具下方的瀑布视图所示：

SDR# visualizing the key fob signal (X axis = frequency, Y axis = signal intensity)
SDR# 可视化密钥卡信号（X 轴 = 频率，Y 轴 = 信号强度）

We can also notice that the signal has two major ‘peaks’ on both sides of the 433.92 MHz frequency (the red line in the middle is the exact tuning frequency).
我们还可以注意到，信号在 433.92 MHz 频率的两侧有两个主要的“峰值”（中间的红线是确切的调谐频率）。

Doing some research on common modulation schemes, we come across 2-FSK that sounds interesting:
对常见的调制方案进行一些研究，我们遇到了听起来很有趣的 2-FSK：

2-FSK 2-FSK系列

FSK stands for Frequency-Shift Keying, which is a frequency modulation scheme in which data is encoded on a carrier signal by periodically shifting the frequency of the carrier between several discrete frequencies.
FSK 代表 Frequency-Shift Keying，它是一种频率调制方案，其中通过在几个离散频率之间周期性地移动载波的频率，在载波信号上对数据进行编码。

Pretty straightforward so far, sounds like we’re dealing with FM here.
到目前为止，非常简单，听起来我们在这里处理 FM。

The interesting part is the ‘2’ however, which here stands for the number of channels used in the encoding. So, we’re actually encoding binary data in two separate frequencies here, one for the 0 and the other for the 1, which would explain the two peaks we’re noticing.
然而，有趣的部分是“2”，它在这里代表编码中使用的通道数。因此，我们实际上是在用两个不同的频率对二进制数据进行编码，一个用于 0，另一个用于 1，这可以解释我们注意到的两个峰值。

Note: One might wonder what the other smaller ‘peaks’ are in that screen capture – those are basically unwanted frequencies that are generated accidentally by the emitter chip, due to the cheap nature of the hardware, and due to the very close proximity of the remote and the antenna. So, it’s just a bunch of ‘noise’ that we can safely ignore.
注意：有人可能想知道屏幕截图中其他较小的“峰值”是什么 – 这些基本上是发射器芯片意外产生的不需要的频率，由于硬件的廉价性质，并且由于遥控器和天线非常接近。所以，这只是一堆我们可以放心忽略的“噪音”。

Practical analysis 实用分析

Now that we checked what the signal looks like visually, let’s explore how we can work on analyzing it in order to read the bits from the RF waves in hopes to spot some sort of structure/consistency.
现在我们已经检查了信号的视觉外观，让我们探讨如何对其进行分析，以便从射频波中读取位，以期发现某种结构/一致性。

Universal Radio Hacker 通用无线电黑客

As the README of its repository states, the Universal Radio Hacker (URH) is a complete open-source suite for wireless protocol investigation with native support for many common SDRs. URH allows easy demodulation of signals combined with an automatic detection of modulation parameters making it a breeze to identify the bits and bytes that fly over the air.
正如其存储库的自述文件所述，Universal Radio Hacker （URH） 是一个完整的开源无线协议调查套件，具有对许多常见 SDR 的原生支持。 URH 允许轻松解调信号，并自动检测调制参数，从而轻松识别在空中飞行的比特和字节。

This is precisely the software we need to decode radio waves into bits.
这正是我们需要将无线电波解码为比特的软件。

As we open URH, we’re invited to either open a file or record directly from a device.
当我们打开 URH 时，我们会被邀请直接从设备打开文件或录制。

Before recording, we have to select the source device, and set some basic radio parameters (I actually only made sure to put the right frequency and left everything else as default):
在录制之前，我们必须选择源设备，并设置一些基本的无线电参数（实际上我只确保放置正确的频率，而其他所有内容都保留为默认值）：

After recording a signal, URH will try to autodetect the right configuration to use when decoding the radio waves.
记录信号后，URH 将尝试自动检测在解码无线电波时使用的正确配置。

On my initial recordings, I wasn’t able to get URH to find the right parameters for me, which gave me wrong results. I have however later figured out that recording multiple repetitive signals in one go increases the chance that URH will figure out the right configuration, which turned out to be in my case: 50 samples/symbol, FSK.
在我最初的录音中，我无法让 URH 为我找到正确的参数，这给了我错误的结果。然而，我后来发现，一次性记录多个重复信号会增加 URH 找出正确配置的机会，事实证明，在我的情况下：50 个样本/符号，FSK。

Zooming in on one of the signals, we notice the 3 bursts we identified on SDR# (the second of which is made of 3 separate ones – so we have 5 sections to analyze now):
放大其中一个信号，我们注意到我们在 SDR# 上识别的 3 个突发（其中第二个由 3 个独立的突发组成 – 因此我们现在有 5 个部分需要分析）：

For each of these sections, a bit sequence is automatically extracted, which we can also convert to hex for a better visualization:
对于这些部分中的每一个，都会自动提取一个位序列，我们也可以将其转换为十六进制以获得更好的可视化效果：

We can already notice a lot of consistency and repeating patterns in the bytes, which is a sign that we’re on the right path.
我们已经可以注意到字节中有很多一致性和重复模式，这表明我们走在正确的道路上。

However, to my eyes, we’re still missing something here, because we notice the same 5 hex digits being repeated, with a lot of 0x55 bytes (01010101) also, which is pretty intriguing.
然而，在我看来，我们在这里仍然遗漏了一些东西，因为我们注意到相同的 5 个十六进制数字被重复，还有很多0x55字节 （01010101），这非常有趣。

Going over to the next tab labeled ‘Analysis’, we can see the bytes we’ve just extracted from each burst, each represented in a line, and there’s a decoding option that shows up with a bunch of curious algorithms:
转到下一个标有“分析”的选项卡，我们可以看到我们刚刚从每个突发中提取的字节，每个字节都表示在一行中，并且有一个解码选项，上面显示了一堆奇怪的算法：

By brute forcing my way and trying them consecutively, I noticed that one of them (Manchester II) converted all the 0x55 bytes to null ones, and without producing any decoding errors:
通过蛮力强行尝试并连续尝试它们，我注意到其中一个（Manchester II）将所有 0x55 字节转换为空字节，并且没有产生任何解码错误：

These bytes look more legit now.
这些字节现在看起来更合法。

Manchester encoding 曼彻斯特编码

Manchester is a very simple digital modulation scheme that ensures that the signal never remains at logic low or logic high for an extended period of time, and also converts the data signal into a data-plus-synchronization signal (for clock recovery).
曼彻斯特是一种非常简单的数字调制方案，可确保信号永远不会长时间保持在逻辑低电平或逻辑高电平，并将数据信号转换为数据加同步信号（用于时钟恢复）。

These characteristics are very useful when sending digital data over analog mediums that tend to be susceptible to noise and interference.
当通过容易受到噪声和干扰的模拟介质发送数字数据时，这些特性非常有用。

In Manchester, binary data is encoded in two opposite bits, therefore:
在曼彻斯特，二进制数据以两个相反的位编码，因此：

0 becomes 01 and 1 becomes 10 (or the other way around, depending on the convention):
0 变为 01,1 变为 10（或相反，取决于约定）：

Let’s go back and continue our investigation.
让我们回去继续我们的调查。

By doing some manual examination and comparison of the different captures, we’re able to note that each button press generates a signal with the following characteristics:
通过对不同的捕获进行一些手动检查和比较，我们可以注意到每次按下按钮都会生成具有以下特征的信号：

1. A long burst with no data (decodes to 100 null bytes).
   没有数据的长突发（解码为 100 个空字节）。
2. 3 bursts which look very similar with only 2 bytes partially changing.
   3 个突发，看起来非常相似，只有 2 个字节部分变化。
3. A final burst which is shorter but still looks fairly similar to the previous 3 bursts.
   最后一次爆发较短，但看起来仍然与前 3 次爆发非常相似。

I decided to look more closely at the 3 bursts (let’s call them packets) in the middle since they seem to be the important part of the signal, and I was quickly able to spot what seems to be an incremental ID which increases by 1 on each new signal:
我决定更仔细地观察中间的 3 个突发（我们称它们为数据包），因为它们似乎是信号的重要组成部分，并且我很快就能够发现似乎是一个增量 ID，它在每个新信号上增加 1：

To be able to move forward with our analysis, we must learn about a very important remote control security mechanism:

Rolling codes

A rolling code is used in keyless entry systems to prevent a simple form of replay attack, where an eavesdropper records the transmission and replays it at a later time to cause the receiver to ‘unlock’. Such systems are typical in garage door openers and keyless car entry systems. More on Wikipedia.

The gist of this system is that the key and the car both ‘agree’ on a cryptographically secure algorithm in order to generate rolling codes that are used to authenticate the remote.

These keys are generated and tracked using a counter which has to stay in sync between the remote and the car. This ensures that the car doesn’t reuse an old key, and that the remote always generates fresh keys.

An example of a rolling code implementation is pictured below (credits: RuhrSec 2017):

• uid: ID of the car/remote link
  uid：汽车/远程链接的 ID
• enc_k: Implementation of the rolling code algorithm
  enc _k ： 滚动代码算法的实现
• ctr: The car’s counter ctr：汽车的计数器
• ctr’: The remote’s counter
  ctr’：遥控器的计数器

The validity window permits the remote to not go out of sync if the car doesn’t happen to receive the signal (typically with a max of 255 out-of-range button presses on most implementations, after which the remote has to be manually resynchronized).
如果汽车碰巧没有接收到信号，有效窗口允许遥控器不会不同步（通常在大多数实现中最多按下 255 次超出范围的按钮，之后必须手动重新同步遥控器）。

Alright, let’s go back to the drawing board.
好了，让我们回到绘图板。

Since we now know that rolling codes are cryptographically secure, it becomes easy for us to spot the part of the signal responsible for this implementation (which would be the one with the highest entropy):
由于我们现在知道滚动代码在加密上是安全的，因此我们很容易发现负责此实现的信号部分（这将是熵最高的部分）：

We can also make the assumption that the incremental ID we’ve identified earlier is the counter for the rolling code system. As it also conveniently sits right next to the code.
我们还可以假设我们之前确定的增量 ID 是滚动代码系统的计数器。因为它也方便地位于代码旁边。

By comparing lock and unlock signals, I was also able to quickly spot the byte responsible for the command (8 = unlock, 4 = lock):
通过比较锁定和解锁信号，我还能够快速发现负责命令的字节（8 = 解锁，4 = 锁定）：

Now all that’s left for us to guess from the signal’s ‘variable parts’ are the two red changes we marked earlier:
现在，我们只能从信号的“可变部分”中猜测我们之前标记的两个红色变化：

1) For the first one, we notice that the same values repeat themselves across the other captured signals.
1）对于第一个信号，我们注意到相同的值在其他捕获的信号中重复出现。

Converting the 3 values to binary, we notice the following:
将 3 个值转换为二进制值，我们注意到以下几点：

• 0x6: 0110 0x6： 0110
• 0xA: 1010 0xA：1010
• 0xE: 1110 0xE： 1110

Interesting, looks as if it’s packing some sort of sequence number for the packets.
有趣的是，看起来好像它正在为数据包打包某种序列号。

And what if we check the final (4th) packet as well?
如果我们也检查最终（第 4 个）数据包呢？

• 0x13: 10011 0x13： 10011

Yup, our theory seems to check out (ignore the lowest bit that changed here).
是的，我们的理论似乎检查出来了（忽略这里改变的最低点）。

2) Let’s guess the last byte now.
2）现在让我们猜最后一个字节。

We can notice that this one not only changes for each packet, but it does so completely across all signals as well.
我们可以注意到，这个数据包不仅会随着每个数据包而变化，而且在所有信号中也完全会发生变化。

Seeing that this is the last byte on the packet and that it changes pretty randomly, leads me to suspect this being a checksum.
看到这是数据包上的最后一个字节，并且它的变化非常随机，这让我怀疑这是一个校验和。

One thing we can try doing is a XOR of this byte with the other byte we just analyzed, to see if we can end up with a static value (since pretty much everything besides these two bytes actually stays static when it comes to the 3 rolling code packets).
我们可以尝试做的一件事是将这个字节与我们刚刚分析的另一个字节进行异或，看看我们是否可以最终得到一个静态值（因为除了这两个字节之外，几乎所有东西实际上都保持静态当涉及到 3 个滚动代码包时）。

Let’s try with these two examples:
让我们试试这两个例子：

Example 1: 示例 1：

• 0x06 ^ 0xB9 = 0xBF
• 0x0A ^ 0xB5 = 0xBF
• 0x0E ^ 0xB1 = 0xBF

Example 2: 示例 2：

• 0x06 ^ 0xCC = 0xCA
• 0x0A ^ 0xC0 = 0xCA
• 0x0E ^ 0xC4 = 0xCA

Bingo. This is definitely a XOR checksum.
宾果游戏。这绝对是一个异或校验和。

By applying XOR on all the bytes of the packets, we notice that the value always ends up being off by 1:
通过对数据包的所有字节应用 XOR，我们注意到该值最终总是偏离 1：

This leads us to conclude that the first 2 bytes of the packet are likely excluded from the checksum (which is where the 1 is coming from):
这导致我们得出结论，数据包的前 2 个字节可能被排除在校验和之外（这是 1 的来源）：

And this actually makes sense, since these bytes would act here as a syncword to synchronize the receiver and indicate the beginning of the data.
这实际上是有道理的，因为这些字节在这里将充当同步字来同步接收器并指示数据的开头。

Note: If you’re wondering about the utility of the initial long burst highlighted in yellow in the captures – that one serves to basically wake up the radio receiver and prepare it to start receiving data (since it goes in an idle low power state on inactivity). And if you’re also wondering why the remote sends 3 packets with roughly the same data, it’s simply to insure some sort of reliability. In case one of the packets gets corrupted on the way (which we saw happen on an earlier screenshot).
注意：如果您想知道捕获中以黄色突出显示的初始长突发的效用 – 它基本上用于唤醒无线电接收器并准备开始接收数据（因为它在不活动时处于空闲低功耗状态）。如果您还想知道为什么遥控器会发送 3 个数据包，其中包含大致相同的数据，那只是为了确保某种可靠性。如果其中一个数据包在途中损坏（我们在之前的屏幕截图中看到这种情况发生）。

Final result 最终结果

After labeling the rest of the bytes to my best guess, this is the result I ended up with:
在将其余字节标记为我的最佳猜测后，这是我最终得到的结果：

Neat. We’ve just reverse engineered a car key fob signal.
整洁。我们刚刚对汽车钥匙遥控钥匙信号进行了逆向工程。

Tune in next time when I (hopefully) write about how I integrated support for this signal format on the Flipper Zero in order to be able to read, re-serialize, and replay it.
下次我（希望）写下我如何在 Flipper Zero 上集成对这种信号格式的支持以便能够读取、重新序列化和重播时，请收看。

Thanks for reading! 感谢您的阅读！

Note: If you’ve noticed inaccurate information, or room for improvement regarding this article, and would like to improve it, feel free to submit a pull request on GitHub.
注意：如果您发现有关本文的信息不准确或有改进的余地，并希望对其进行改进，请随时在 GitHub 上提交拉取请求。

原文始发于0x44：Reverse engineering a car key fob signal (Part 1)