引言

作為一名IT專業人士和網絡安全愛好者，我一直對系統和技術的運作方式充滿好奇——尤其是那些不輕易透露其秘密的系統和技術。懷著對天氣和風暴追蹤的熱情，我常常想知道，在嚴重風暴來襲時，緊急警報系統（EAS）和美國國家海洋和大氣管理局（NOAA）氣象廣播是如何如此迅速地傳輸和接收警報的。在本文中，我們將探討緊急警報系統（EAS）、其特定區域消息編碼（SAME）格式，以及如何利用一些巧妙的編程、樹莓派和NOAA氣象廣播來模擬真實的緊急警報，作為一次網絡安全和無線電信號的實踐。

注意：本文內容強調了一個關鍵的政府系統，該系統旨在在緊急情況下向公眾發出警報。篡改、廣播或偽造EAS中使用的受限無線電信號是違法的。本文中執行的所有操作均在受控環境中進行，以降低無線電信號泄漏的風險。

什么是EAS？

如果你住在美國中西部或周邊地區，你可能經歷過不少春季雷暴，甚至可能遭遇過惡劣天氣。如果是這樣，那么你很可能也經歷過由政府緊急警報系統（EAS）觸發的老式CRT電視或收音機上發出的刺耳且令人不悅的聲音。

龍卷風警報期間緊急警報系統的一個示例幻燈片和伴隨的聲音。

緊急警報系統正如其名：旨在在緊急情況下向公眾發出警報。然而，推動EAS的技術是一段引人入勝的歷史，我們將在本文中深入探討。

緊急警報系統簡史

緊急警報系統標志

緊急警報系統于1997年1月正式啟動，以取代其前身——1963年創建的緊急廣播系統（EBS）。EAS最初是為國家緊急情況（如核攻擊）而創建的，但現在用于傳遞來自國家氣象局的各種警報，如惡劣天氣警報。

在現代，EAS與無線緊急警報（WEA）、NOAA氣象廣播以及各種其他在線網絡饋送協同工作。這一切都被整合到FMEA系統中，稱為綜合公共警報與預警系統（IPAWS）。在大多數日常對話中，由于其豐富的歷史，大多數人通常將這些系統簡單地稱為EAS。在本文中，我們將主要關注EAS和NOAA氣象廣播，因為它們在接收警報方面使用了相似的技術。

警報是如何傳輸和接收的？

IPAWS和下游路徑系統的架構圖

在現代，大多數政府發布的警報都是通過IPAWS網絡饋送發送的，廣播電臺、電視臺和有線提供商需要訂閱該饋送以轉發任何和所有國家警報。軟件開發者可以利用IPAWS-OPEN以通用警報協議（CAP）格式（XML）接收警報。IPAWS-OPEN還可以傳輸和轉發國家氣象局的警報。

要查看CAP警報的示例，你可以訪問顯示國家內任何活躍CAP格式警報的公共weather.gov API。此外，在URL后附加?area={STATE}將按提供的兩字母州名過濾警報。所有CAP信息（以及更多內容）都在OASIS開放規范中記錄，NWS的實現鏈接在此處。

此外，在美國及其領土上戰略性地布置了（截至撰寫本文時）77個主要入口點（PEP）系統，這些系統會輪詢數字IPAWS-OPEN饋送，以及參與的廣播電臺、電視臺和有線提供商。這些參與者使用像Sage Digital ENDEC 3644這樣的解碼器系統或類似設備。

用于EAS系統的SAGE Digital ENDEC解碼器圖片

然而，如果在危機期間互聯網變得不可訪問，從而阻塞了對數字CAP饋送的訪問，那么EAS的真正威力就開始顯現。正如FEMA關于通用警報協議的細節中所指出的，電臺也會以“雛菊鏈”結構監控其他電臺的EAS警報。

特定區域消息編碼（SAME）

在FEMA關于IPAWS的網站上，你還會開始發現對其他EAS協議的引用，如特定區域消息編碼（SAME）和那些令人不悅的EAS音調（音量警告）。

當CAP解碼器接收到警報并對其進行解碼時，它不僅負責將警報傳輸到其直接管轄范圍內，還負責將其轉發給其他EAS電臺。這創建了一個從某個源頭傳播信息并迅速通過無線電波轉發到其他電臺的快速網絡。

主要入口點電臺還有額外的要求，例如必須配備備用通信設備和發電機。這些設備允許它們在《聯邦法規》§ 11.18 EAS指定中描述的“重大”災難期間繼續運行。傳輸的代碼就是SAME協議所在之處，也是NOAA氣象廣播和經典無線電驅動的EAS協議的驅動力。

在《聯邦法規》§ 11.31 EAS協議中，你可以找到關于SAME代碼的詳細技術信息，但最相關的信息列在下面。

EAS消息的結構

消息由激活EAS的4部分消息組成：

前導碼，后跟EAS（SAME）頭代碼

音頻注意信號（同時傳輸853和960 Hz）

消息本身（通常為文本轉語音）

前導碼，后跟EAS消息結束（EOM）代碼

消息的關鍵部分是EAS頭，這是EAS設備（以及NOAA氣象廣播，更多內容見后文）實際解碼以確定其本地管轄范圍是否受到警報影響的部分。這些頭是編碼的ASCII文本字符，以精確頻率編碼和傳輸：

音頻頻移鍵控速率：每秒520.83位

標記（二進制1）頻率：2083.3 Hz

間隔（二進制0）頻率：1562.5 Hz

標記和間隔時間必須精確為1.92毫秒

EAS頭必須以三個為一批進行傳輸，每次傳輸頭時，EAS解碼器都應能夠接收消息。這確保了無線電噪聲不會嚴重影響警報的轉發。

頭的模板文本列在下面：

[PREAMBLE]ZCZC-ORG-EEE-PSSCCC-+TTTT-JJJHHMM-LLLLLLLL

[PREAMBLE]是16個十六進制0xAB字節的流，本質上用于在準備警報本身之前清除EAS解碼器系統。

ZCZC是靜態文本，作為標識符。

ORG是激活EAS的發起方。這些列在此處。

EEE是事件代碼，最終告訴你EAS被激活的原因。這些列在此處。

PSSCCC是一個6位數字字符串，代表受警報影響的國家區域。SAME頭在一個警報中最多可以支持31個位置。

P代表一個形狀異常的縣的細分，或設計用于更具體的定位（通常為“西北”、“東南”或其他分區）。在實踐中，P并不常用。

SS代表被定位的2位FIPS州代碼。這些列在此處。州代碼為00代表所有州（整個國家）。

CCC代表一個3位縣/市FIPS代碼，可以在NWS網站上輕松找到。在瀏覽這些列表時，SAME位置代碼是州和縣（SSCCC）的組合，因此對于俄亥俄州的富蘭克林縣，它將是俄亥俄州的39和縣的049。

+TTTT代表消息的有效時間期，以15分鐘為增量開始，然后每小時以30分鐘為增量。有趣的事實：這就是為什么天氣警報總是落在均勻分布的時間段上。）

JJHHMM代表消息最初以UTC發送的儒略歷日、小時和分鐘。

LLLLLLLL代表EAS消息的發起辦公室，或誰在轉發它。這個字符串由EAS編碼器設備自動附加到消息上。

整合所有部分

點擊此處查看GitHub倉庫

https://github.com/JacobSecOps/Emergency-Alert-Generator

為了實現一種穩健且可重用的生成警報的方法，我開始構建一個自定義的Python程序，該程序接收所有必要的參數并導出有效的波形（.wav）文件，該文件可以通過無線電波或通過一些專用軟件進行解碼（更多內容稍后）。

在探索了波形采樣、與最低有效位編號對齊以及確保振幅匹配預期格式之后，我能夠構建一個足夠穩健的程序，以使用有效的SAME頭和EOM字符串創建模擬的EAS警報。

除了生成EAS警報本身之外，這個Python項目還實現了一些便利功能，使其相當易于使用：

0xAB前導碼自動應用于頭和EOM字符串。

州和縣FIPS代碼從人口普查API獲取，該API允許你指定州和縣的名稱，并讓API返回正確的代碼。

指定注意音調的長度。雖然大多數警報默認為8秒，但根據EAS規范，這些音調可以播放長達24秒。

編碼一個在警報中的適當位置附加的文本轉語音消息。

作為說明，我并不是第一個創建此類工具的人，然而，從我所做的所有研究來看，我是第一個直接與人口普查API集成并為其創建命令行工具的EAS生成器的作者。以下是我在研究過程中發現的其他幾個項目：

模擬測試

為了進行模擬測試，我計劃為俄亥俄州的富蘭克林縣生成一個龍卷風警報警報消息。這將由KILN辦公室發起，該辦公室是位于俄亥俄州威爾明頓的國家氣象局辦公室。

使用新開發的Python程序，我可以簡單地運行以下命令來生成一個新的.wav文件進行測試：

python eas_generator.py--state"Ohio" \--county"Franklin" \--message"This isatest of the EAS Generator" \--day98\--hour2\--minute25\--origin"WXR" \--event"TOR" \--duration"0015" \--identification"NWS/KILN" \--attention-tone8\--output"tornado_warning_franklin_co_eas_example.wav"

這將生成一個帶有編碼SAME頭的tornado_warning_franklin_co_eas_example.wav，頭為ZCZC-WXR-TOR-039049+0015-0980250-KILN/NWS-。然后，我們將波形導入Audacity以分析警報的結構。

Audacity頻譜圖視圖中輸出EAS警報的截圖。

現在的問題是，我們如何測試它？顯然，在驗證其工作之前，我們希望盡量避免在無線電波上廣播噪聲，因此找到軟件解決方案是必要的。

一些研究產生了兩個可能的工具，可用于驗證EAS SAME頭是否可以正確解調和解碼。它們是：

SeaTTY

https://www.dxsoft.com/en/products/seatty/

multimon-ng

https://github.com/EliasOenal/multimon-ng

使用SeaTTY進行測試

SeaTTY是一款有趣的軟件，我對其研究的時間并不長，但從我所收集的少量信息來看，它可以通過無線電波接收完整的天氣報告、航行警告和其他信息。就我們的目的而言，我們可以將模式更改為NWS-SAME，然后選擇從文件解碼。

ModeNWR-SAME解碼模式的SeaTTY軟件設置截圖

從文件解碼后，我們看到緩沖區窗口顯示了我們原始的警報，以及消息結束字符串NNNN：

成功將EAS警報解碼回其純ASCII文本的SeaTTY軟件截圖

這意味著，從理論上講，我們應該能夠傳輸這個警報并通過氣象廣播接收它。然而，讓我們也通過multimon-ng進行測試，以確認我們可以正確地將波形通過音頻處理工具。

使用sox和multimon-ng進行測試

為了盡可能接近我們的實地測試而不實際通過無線電波傳輸（目前），我們可以使用sox和multimon-ng的組合來解調波形，看看我們是否可以打印原始警報。Multimon-ng有一個內置的模式來解碼EAS SAME頭，因此這應該很簡單。

在Windows Subsystem for Linux環境中安裝了適當的軟件包后，我們就可以運行以下命令：

soxtornado_warning_franklin_co_eas_example -c1-r22050-t raw -e signed -b16- gain +6| multimon-ng -a EAS -t raw -

該命令的參數詳細說明如下：

-c 1 這強制使用單聲道（單通道）音頻。技術上EAS可以支持立體聲，但就我們的目的而言，我們將堅持使用單聲道。

-r 22050 這將采樣率設置為22,050 Hz，以便multimon-ng可以處理它。

-t raw 這輸出沒有WAV頭的原始音頻。

-e signed 我們的編碼類型。在這種情況下，我們使用有符號整數。

-b 16 每樣本的位數。16位PCM是標準，也是我們之前Python腳本輸出的內容。

這直接輸出到標準輸出，因此我們可以將其管道傳輸到multimon-ng，并使其像酷孩子一樣成為一行命令。

gain +6 雖然可能不是嚴格必要的，但這會提高音量，使其更容易解碼。

然后，我們將其傳遞到multimon-ng，我們必須為EAS聲明解碼器模式-a，指定輸入為原始音頻-t raw，并從標準輸入讀取-。

結果：我們的sox + multimon-ng命令成功解碼EAS警報的終端輸出截圖

在結果屏幕上，我們可以看到原始的EAS SAME頭以及EOM字符串都被顯示出來，這證實了我們得到了期望的結果。

使用NOAA氣象廣播進行實際實驗室測試

既然我們已經完成了所有的模擬測試，我們現在可以在配備適當設備的實驗室環境中嘗試真實測試。在進行測試之前，讓我們快速了解一下我們為這次測試準備了哪些設備：

Raspberry PI 3B+

Midland NOAA氣象廣播

Midland NOAA氣象廣播的圖片

RTL-SDR無線電接收器

RTL-SDR無線電接收器的圖片

雖然RTL-SDR嚴格來說并不是必需的，但它對于確保我們的信號在視覺上以正確的頻率傳輸非常有用。我們將使用SDR#來查看我們傳輸時的頻率瀑布圖。

我們如何安全傳輸？

我已經多次提到，傳輸非政府發布的EAS警報可能會導致監禁。因此，這是最后的警告：不要在家嘗試這個！

話雖如此，在配備非常低功率發射機的受控實驗室場景中，進行我們的實驗以確認我們可以觸發氣象廣播應該是安全的。

雖然樹莓派肯定不是射頻發射機，但信不信由你，它實際上可以傳輸非常低的射頻信號（大約在10毫瓦的范圍內），頻率高達約1 GHz。我們很幸運，因為NOAA氣象廣播在七個低FM頻率之一上接收傳輸：

162.400 MHz

162.425 MHz

162.450 MHz

162.475 MHz

162.500 MHz

162.525 MHz

要通過樹莓派傳輸，我們可以使用兩個很棒的GitHub項目rpitx和pifmrds來完成繁重的工作。這將通過GPIO 4或引腳7進行傳輸。為了保持傳輸范圍盡可能小，我們將放棄在引腳上附加任何天線或電線，并將氣象廣播和RTL-SDR物理上靠近樹莓派放置。

rpitx：https://github.com/F5OEO/rpitx

pifmrds：https://github.com/ChristopheJacquet/PiFmRds

樹莓派GPIO引腳圖片，特別是引出了GPIO 4或引腳7。

在我進行實際發送EAS警報的樣本測試中，我無法從房子的一側到另一側（沒有天線或電線）接收到信號，這給了我信心，可以嘗試真實操作。

在NOAA氣象廣播上觸發真實的龍卷風警報

在這個視頻演示中，我們可以看到用于測試的樹莓派和NOAA氣象廣播。我們還將RTL-SDR插入筆記本電腦，以在我們傳輸警報時監控所選頻率。在屏幕的左下角，我們通過SSH登錄到樹莓派以運行命令來傳輸我們的警報。在右下角是氣象廣播調諧頻率的SDR#瀑布圖，以查看警報何時被傳輸。

在這個例子中，我發現雖然樹莓派可以作為射頻發射機運行，但晶體振蕩器并不完美。因此，經過反復試驗，我發現162.500 MHz是傳輸的最佳頻率，并將氣象廣播調諧到該頻率。

我們在樹莓派上運行的最終觸發警報的命令如下：

sudopifmrds -freq162.500-audio tornado_warning_franklin_co_eas_example.wav

當它被發送時，廣播噪音立即停止，我們開始聽到熟悉的EAS音調通過廣播傳來，我們可以在SDR#的瀑布圖上看到它們脈沖。在所有三個EAS音調被發送后，氣象廣播關閉，認為有來自官方KILN國家氣象局辦公室發布的龍卷風警報。

發送EAS警報時SDR#瀑布圖的截圖。這是從下往上讀的，底部是更早的時間。這個截圖是在注意音調期間拍攝的

眼尖耳利的觀眾可能會在視頻中注意到，每次頭重復時，EAS音調都會“變響”。這很可能是由我們使用樹莓派引起的，它需要一些時間來校準振蕩器。SDR#瀑布圖也證明了這一點，因為信號傳輸時間越長，信號就越鮮艷。這是一個很好的例子，說明了為什么EAS頭在官方警報中會發送多次，因為直到第三次頭被傳輸后，氣象廣播才真正關閉。

在這個例子中，我還省略了文本轉語音語音，突出了它實際上并不是廣播關閉或EAS解碼器捕獲有效警報所必需的。真正的每周測試（RWT）警報通常會省略語音，因為這些警報類型僅用于每周測試設備。

惡劣天氣（龍卷風）警報器的相關性

這個項目最初是在2025年3月30日俄亥俄州和富蘭克林縣受到惡劣天氣影響時產生的靈感。當時我與住在哥倫布附近的一位朋友交談，他說盡管他的城鎮遠在警告多邊形之外，但龍卷風警報器還是響了。以下是愛荷華州立大學環境監測網關于這次天氣事件的截圖示例：2025年3月30日影響俄亥俄州費耶特、富蘭克林、麥迪遜和皮卡韋縣的雷達反射率復合圖和龍卷風警告多邊形圖片

在突出顯示的“綠色框”區域，當龍卷風警報器遠離多邊形時，它們卻響了。這個警告框最初是在2025-03-31T0138 CDT（如上圖所示）發布的。然后，在其生命周期內，它收到了兩次更新，警告多邊形在背面被“削減”（如下面的白色輪廓所示）。然后，它在晚上9:14 CDT過期。2025年3月30日雷達反射率復合圖和龍卷風警告多邊形更新的圖片。

我為什么要提這個？嗯，每當有足夠高嚴重性的警報（如龍卷風警告）更新時，國家氣象局實際上會再次提交EAS警報。從技術上講，這是相同的警報，但在某些情況下，NOAA氣象廣播以及最值得注意的是：龍卷風警報器會“再次觸發”。我的朋友從未處于這次風暴警告的龍卷風路徑中，但警報器卻一直響個不停，最終被禁用，然后過一段時間又會再次響起。

原因是什么？這是因為戶外警告警報器（俗稱“龍卷風警報器”）是基于與氣象廣播和EAS本身相同的EAS-SAME技術構建的。

正如我們在本文中所探討的，基于天氣的EAS警報針對整個縣（或在罕見情況下針對主要子區域）。因此，即使你的縣被警告框“剪切”，而你在縣的另一側，龍卷風警報器很可能仍會被觸發。在某些情況下，民事當局實際上會在風暴不真正威脅其管轄范圍時關閉警報器，但如上所述，提交給EAS的更新會再次觸發它們，這就是我朋友所描述的警告正常生命周期進展時的情況。然而，值得注意的是：他的手機從未收到過無線緊急警報（WEA）推送。這是這里所使用的技術的另一個有趣之處。

我們在這個場景中看到的是新舊技術的融合。2007年10月，國家氣象局停止了對整個縣的嚴重天氣警告，轉而選擇在地圖上繪制多邊形，他們稱之為“基于風暴的警告”。這很有用，因為它減少了未受直接影響的人們的警告數量。盡管如此，舊的EAS和氣象廣播技術尚未完全采用這項技術，這導致了在這些情況下警報器“時開時關”。然而，像WEA這樣的新系統利用手機的GPS來確定你是否在多邊形內，這解釋了為什么他從未收到過緊急警報推送。

作為額外的說明，所有NWS的天氣通知都通過NOAA氣象廣播傳輸，并使用SAME頭。其中只有一小部分實際上會觸發EAS，通常保留給極端嚴重性的情況，即生命或財產即將受到威脅。如果你閱讀龍卷風警告或“破壞性”標記的嚴重雷暴警告的警報文本，你可能會看到“EAS激活請求……”的文本。這就是觸發EAS并使戶外警告警報器響起的一個例子。

EAS與網絡安全

鑒于我從事IT和網絡安全工作，為什么我覺得有必要探索這個？除了EAS是一項控制很多幕后工作的酷技術之外，有人可能會認為，廣播系統的老派性質和它們的結構方式是不安全的，更傾向于使用新技術途徑進行警報傳播。事實上，EAS是近30年前最初部署時最智能設計的IT相鄰系統之一。在需要時，使用雛菊鏈功能在全國范圍內大約5分鐘內傳輸警報的能力在國家緊急情況下非常重要。此外，它及其父IPAWS系統、EAS和SAME代碼構成了我們在遭遇嚴重天氣時理所當然地認為的很多天氣警報的通信骨干。

此外，在最近幾年中，EAS解碼器已擴展使用更現代的安全功能來驗證警報的真實性，使用數字簽名。本文中部分提到，EAS軟件使用證書鏈，就像大多數現代IT安全一樣。這樣，即使某個流氓個人想要在有效無線電頻率上“廣播”假的EAS警報，如果沒有有效簽名，大多數EAS設備都應該忽略它，或者記錄一個錯誤，如：

EventLog: Digital Signature VERIFICATION ERROR: Signer UNTRUSTED!Check for correct CAP decoder CA file.

相比之下，NOAA氣象廣播突出了該系統過去的工作方式。過去曾發生過EAS系統被黑客攻擊的情況。在下面的視頻示例中，黑客通過KRTV發送了一個虛假的局部區域緊急（LAE）警報，聲稱僵尸正在從墳墓中爬出并攻擊平民。

EAS Fandom Wiki上強調的有趣情況是，SAME音調后來在威斯康星州拉克羅斯的另一家電視臺上播放，當時新聞記者正在報道發生在KRTV上的情況。這家其他新聞臺在報道這一情況并播放相同的SAME音調時，實際上再次觸發了EAS，突出了為什么FEMA和FCC對SAME音調的任何濫用都進行了嚴格監控。

學習與收獲

對緊急警報系統及其相關技術的深入探索是一個相當有趣的探索過程。但這樣做揭示了一個最穩健的通信系統之一，該系統用于在緊急情況下保障人們的安全。了解EAS消息如何編碼、傳輸和通過網絡傳播，以及生成有效警報的Python程序都是極具洞察力的。

當將其與網絡安全聯系起來時，我想到了以下幾點：

在這種情況下，更準確的說法應該是調制與解調，因為它是FM無線電驅動的。

EAS（和許多其他技術）使用最低有效位編號，這在編寫腳本時讓我困惑了一段時間。

樹莓派可以作為低功率FM發射機運行。這項技術有無數個項目和深入探索的潛力，這是我未來希望探索的內容。

盡管世界上有所有的網絡安全工具，但錯誤的按鈕一按就可能被擊敗。

原文地址：

https://medium.com/@oglesbeejacob/hacking-the-airwaves-de578e40f53b