題:
是否可以用軟件物理破壞微控制器?
Juan Carlos
2014-08-15 21:44:57 UTC
view on stackexchange narkive permalink

假設:

  • 未連接任何外部電路(除了編程電路,我們認為是正確的)。
  • uC正常。
  • 通過破壞,我的意思是釋放死亡的藍色煙霧,而不是在軟件中使用它。
  • 這是一個“正常的” uC。不是某些非常奇怪的百萬分之一的專用設備。

有人見過類似的事情嗎?怎麼可能?

背景:

我參加過一次聚會的發言人,我說可以(但不是很難)做到這一點,其他一些人也同意他。我從未見過這種情況發生,當我問他們如何可能時,我沒有得到真正的答案。我現在真的很好奇,很想獲得一些反饋。

發生這種情況的唯一可行方法是IMO,如果某個引腳物理連接至VCC / COM,並且該引腳配置為與所連接的引腳相反驅動,從而導致過流情況。但這是硬件/軟件組合的失敗。
許多控制器具有可在軟件控制下寫入的閃存,該閃存容易磨損。在短時間內耗盡內存的軟件是否算作“銷毀”芯片?
除了將@supercat's關於EEPROM或閃存磨損(可能在幾分鐘內使EEPROM磨損)的意見第二次外,我還要補充說,在許多情況下,物理損壞的設備與“磚狀”設備之間的用戶視點差異很小產品。如果必須返回工廠,則外觀幾乎相同。
提防[nth-complexity無限二進制循環](http://1997.webhistory.org/www.lists/www-talk.1995q1/0749.html)。它已經存在了很長時間...
我認為,即使是外部電路,也無法銷毀釋放藍煙的煙霧!因為要銷毀它(實際上是芯片),您需要足夠的電壓和電流,並且芯片和引腳之間還連接有非常細的電線,因此它們無法傳遞足夠的電流和電壓來完成此工作。
-1
@Roh,不,這很容易。我在電路的本科生實驗室工作,抽出藍色煙霧很普遍。Vcc至GND,您一切順利。
那些說“交換Vcc和GND”的人沒有讀過標題。僅軟件!(而@jippie-第n個複雜性無限的二進制循環只會“嚴重損壞”處理器-BITD(Back in the Day(tm)))引起了意想不到的可怕問題,例如,只要執行FDIV指令,奔騰芯片就會產生正確的結果。-)分享並享受。
通常,如果可以用軟件銷毀一個uC,則該uC被認為是有缺陷的-因此,至少對於大多數類型的uC,*根據定義*,用軟件銷毀一個無故障的uC是不可能的。
@Mishyoshi您的MCU是什麼?PIC,AVR ...?
http://en.wikipedia.org/wiki/Killer_poke
如果uC具有用於芯片中時鐘的板載PLL,並且您可以將PLL編程為實質上超過安全時鐘速率,則有可能因過熱而殺死芯片。不過,我不確定這是否屬於您的“僅普通uC”標準。我以這種方式破壞了一塊芯片(忘記禁用時鐘,並且PLL值無效),儘管它不是微控制器,並且產生時鐘的PLL在另一塊芯片上。
我肯定會懷疑某些單元可能會過熱到損壞的程度。當處理器陷入死循環時,實際上我的手機融化了(固定屏幕的膠水融化了)。
@Roh(抱歉,延遲)MSP430
十一 答案:
Vladimir Cravero
2014-08-15 21:59:33 UTC
view on stackexchange narkive permalink

當然,您可以使用 HCF指令!

也就是說,我說如果沒有任何外部電路(除了電源等),這是不可能的。

即使包括一些非故意的錯誤連接也可能不會切斷它:如果將所有gpios綁在電源軌上,則將它們設置為輸出(連接到相反的電源軌)會消耗很多功率。 gpio引腳可能具有短路保護,因此不會發生任何有害的事情。

設計一個隨意破壞芯片的外部電路在我看來也不是一件容易的事。首先想到的是需要一個較高電壓的電源,一個nmos和一個電阻器:

schematic

模擬該電路 –使用 CircuitLab sup>創建的原理圖,其中:

  • \ $ V_ {CC} \ $是微型電源的常用電源,有些是3v3至5V或
  • 需要的是HV,它的電壓遠高於微型絕對最大額定值。
  • D1在那裡可以保護您寶貴的3V3電壓源
  • 當微控制器未將其接地時,R1將mosfet柵極拉高
  • M1是指定的殺手

操作很簡單:如果微控制器釋放GPIOx M1,繼續,Vcc上升,您的芯片著火。請注意,這是一個糟糕的設置,例如,必須在 之後將HV打開,您要特別確保GPIOx牢固接地。某些晶體管可能不喜歡某些-5V Vgs,依此類推...但是您得到了圖像。

喜歡HCF參考。
嘿,謝謝你給我新的電視連續劇!
@OllieFord我不確定您在說什麼...
@VladimirCravero https: // en.wikipedia.org / wiki / Halt_and_Catch_Fire_(TV_series)
Mishyoshi
2014-08-15 22:26:16 UTC
view on stackexchange narkive permalink

免責聲明:supercat首先在評論中表示。

實際上,不可能物理破壞大多數MCU,但是可以將其磨損到足以使它開始故障直至無法使用的地步。 。我對TI的MSP430很有經驗,因此就可以了:

那些MCU允許隨時重新編程整個閃存。不僅有可能通過重寫閃存達數百萬次來使閃存磨損直至故障,而且如果編程生成器配置不正確,片上閃存編程生成器也可能導致低端處理器出現故障。這些是編程允許的頻率允許範圍。當超出該範圍(較慢)時,編程時間可能會變得過長,並導致閃存失效。僅幾百個週期後,就有可能“燒毀”閃存單元而導致永久性故障。

此外,某些型號允許超頻內核,以便通過增加內部電壓來提高內核速度。 MCU使用1.8-3.6V電源供電,但內核本身設計​​為以1.8V運行。如果您在切換所有I / O,激活所有外設並在封閉的小型機箱中以驚人的40MHz(大型機型通常為25MHz)運行時對3.6V電源軌上的內核進行了超頻,那麼您可能最終會油炸核心因為過熱。實際上,有些人說他們達到了這些頻率(通常DCO之前就失敗了,並且保存了芯片,但是...也許吧)。

只需嘗試一下?

nit-pick-我相信大多數閃存可以保證不超過10,000次寫入,而不是“百萬”寫入。當您提出要點時,可能不值得修復。
啊...閃光磨損。我記得我第一次遇到一個錯誤,該錯誤導致在圖片上不斷向EEPROM寫入數據。只花了10秒鐘左右的運行時間。我花了大約一分鐘才意識到發生了什麼事:-)
gbulmer
2014-08-16 03:23:09 UTC
view on stackexchange narkive permalink

根據 stackexchange-“讓MCU輸入引腳懸空真的是一個壞主意嗎?”

它描述了在幾種情況下芯片可能會被開路引腳損壞。編輯:示例跨度模擬和微控制器產品說:

4.1端口輸入/未使用的數字I / O引腳
強烈建議在將數字I / O引腳切換為輸入時,不要斷開它們的連接。在這種情況下,這些引腳可以進入所謂的浮動狀態。這會導致高ICC電流,這對低功耗模式不利。

此問題的條件是引腳完全開路。

因此,我們的任務是從 損壞引腳。我認為這已經足以超越“磚化”。

該答案中確定的一種機制是將輸入引腳驅動到中值電壓,兩個互補晶體管都處於“導通”狀態。在該模式下運行,引腳接口可能會變熱或發生故障。

輸入引腳具有很高的阻抗,並且也是電容器。據推測,它們在相鄰引腳之間的耦合足以使相鄰引腳足夠快地切換,可能會將電荷驅動到輸入引腳上並將其推入“熱”狀態。可能有一半的I / O引腳被驅動到這種狀態會使芯片預熱到足以造成損壞的程度?嗯。)

我也認為破壞性的閃光燈就足夠了。我認為這已經很糟糕了,以致無法使用該芯片。

它並不需要全部閃存,而只需包含上電,RESET等向量的頁面。一頁上的限制可能需要幾十秒鐘。

我有一個跡象,但沒有確鑿的證據)對於某些MCU來說可能更糟。幾年前,我參加了一個演講。有人問為什麼競爭對手提供的零件具有更高的閃存寫入周期。這位(大型未具名的MCU製造商)發言人表示,他們在閃存規格方面採取了非常保守的方法。他說,他們的保證書所規定的溫度要比行業標準高得多。有人問“那又怎樣”。發言人說,在相同的溫度下,幾種製造商的產品的重寫壽命將大大低於其零件。我的回憶是5x會變成<1x。他說這是非常非線性的。我認為這意味著在80C而不是25C下進行編程將是一件“壞事”。

因此,閃存重寫與非常熱的芯片相結合,可能會在不到10秒的時間內使它失效。 p>

編輯:
我認為“釋放死亡的藍煙”是比要求更難的約束。如果RESET引腳電路,掉電檢測器,上電電路,RC或晶體振盪器(可能還有其他一些電路)中的任何一個損壞,則該芯片將變得無用。

正如其他人所指出的那樣,破壞閃光也會無可挽回地殺死它。

“煙霧”聽起來令人印象深刻,但不太明顯的致命攻擊仍然是致命的,而且很難檢測到。

tkp
2014-08-18 01:52:35 UTC
view on stackexchange narkive permalink

這種破壞的潛在來源是SCR閂鎖,其中芯片中非預期的(本徵)晶體管聚集在一起形成一種TRIAC,這種TRIAC可以吸收大量電流。這很容易吹銲線,而且我什至看到塑料外殼的設備由於產生的熱量而明顯變形。

典型的原因是驅動(甚至是瞬時地)將輸入驅動到電源或地面的上方或下方。分別,但是我想如果輸入懸空,您可能會看到它發生的情況。因此,不難想像一個電路,其中輸入的浮動度是由軟件控制的(儘管允許這樣做很愚蠢)。

TDHofstetter
2014-08-15 22:12:08 UTC
view on stackexchange narkive permalink

為特定目的的處理器有意為此目的編寫的軟件可能會迫使超頻到處理器過熱的程度。當然,只要處理器包含軟件可配置的時鐘控制寄存器即可。

當然不可能所有處理器都以這種方式損壞。如果這是真的,那麼當我們仍然手動輸入機器代碼時,就會有數十億的Z80、6800和6502被隨意編寫軟件的輪胎所遺棄,從而造成許多隨機錯誤。

您無需訪問即可配置時鐘。您只需要以CPU設計人員未曾想到的方式運行軟件。以下是一些代碼,這些代碼試圖在Intel Core系列處理器上每個週期達到理論上的4 FLOPS:http://stackoverflow.com/questions/8389648/how-do-i-achieve-the-theoretical-maximum-of-4-每週期flops / 8391601#8391601。已知此代碼會使CPU過熱。
這是否與[“強力病毒”](http://en.wikipedia.org/wiki/power_virus)程序有關?
@davidcary,對我來說是一個全新的術語。不過,我並不是指一系列耗時的指令,而是指時鐘頻率的實際更改(某些處理器通過操縱控制寄存器來支持軟件對時鐘頻率的控制),使其頻率高於CPU或其散熱器的頻率。可以應付。
Daniel
2014-08-16 05:01:03 UTC
view on stackexchange narkive permalink

這是我破壞盡可能少的零件的微控制器的條目...

只需以幾kHz的頻率切換輸出引腳即可!

您仍然可能看不到冒煙的現象,但取決於內部故障模式。

schematic

模擬此電路 –使用 CircuitLab a創建的原理圖> sup>

-編輯,8月22日添加-

現在,我認為您不能根據給定的標準破壞微控制器。但是,您可以使用錯誤的代碼輕鬆破壞外部電路。我最近設計的一個簡單的升壓轉換器就是一個例子……在調試時暫停代碼可能會使電感器通過MOSFET接地短路。 POOF

我不想成為“那個傢伙”,但假設1:“未連接任何外部電路”
你是“那個傢伙”。此響應的潛台詞是“不,您不能破壞這樣的芯片”。
Dithermaster
2014-08-16 19:31:07 UTC
view on stackexchange narkive permalink

就常規用戶模式代碼而言,我認為您不能編寫任何會破壞芯片的內容。

但是,我確實記得,如果散熱器掉下來,在不到一分鐘甚至幾秒鐘的時間內,微處理器就會被毀壞的日子。然後,他們增加了熱檢測電路,如果零件溫度過高,該電路將降低時鐘。現在,我們能夠投入的晶體管數量遠遠超過了一次使用的數量,芯片產生的熱量超過了散熱器的散熱能力,其功率管理和熱電路也確保了它的安全。例如,請參閱 Intel Turbo Boost 2.0。因此,如果您能夠繞過或提高電源管理和熱電路的限制,則很有可能使芯片熔化。因此,如果這些操作受軟件控制(不知道;也許需要BIOS更新?),那麼您可以運行一堆並行的空循環,集成的GPU工作以及硬件H.264解碼和編碼,以及芯片可以做的所有其他事情,一次,直到芯片過熱並散發出魔幻的藍色煙霧。

jpa
2014-08-18 11:00:06 UTC
view on stackexchange narkive permalink

我最熟悉STM32處理器,因此它們最適用於該系列。但是,其他處理器也可能採用類似的方法:

  1. 有永久的寫保護模式。因此,如果您對該位進行編程,並對FLASH進行一些無用的編程,則將無法再使用MCU。我不知道這是否算作“磚塊化”,但它確實涉及一種永久性的硬件機制。

  2. 編程引腳可重新配置為GPIO。由於時鐘引腳是由編程設備驅動的,因此可以用來引起短路。很有可能會破壞單個引腳,而這是一個編程引腳會很糟糕。這可能會導致其過熱或損壞。

  3. ol>
placeholder
2014-08-15 22:10:17 UTC
view on stackexchange narkive permalink

誰曾說過,不了解這種芯片的設計過程是如何涉及的。這並不意味著不會發生滑動,並且回歸和極端情況的代碼覆蓋有時會遺漏一些東西,但是要聲明所有甚至大多數處理器都存在此缺陷在邏輯上是可疑的。

TLDR;所有處理器都有此故障-

我相信某些/大多數微控制器CPU(按體積而非價值)未進行微編碼。那是否會使您的假設無效?
不,無論您是要設計音序器還是固定用途的單元格,設計上的回歸和約束/測試都會很嚴格。
如果出現藍色煙霧,CPU可能會以一種或另一種方式過熱。通過經歷非常高的電壓,經歷非常高的電流,經歷反極性或也經歷晶體管可能以太高的頻率開關。在軟件中只有最後一種方法可行。低於500MHz的CPU不太可能因為軟件引起的過熱而死亡,但我已經看到CPU因軟件引起的過熱而死亡。您所做的假設正是您不應該做的。
您在這裡將@slebetman混淆太多了。如何通過軟件說明獲得“反極性”?如何獲得“在太高的頻率下進行太多切換”的所有芯片中是否存在一個神奇的缺陷,使它們變成了大規模並行執行管線?
@placeholder:我說過,您無法通過軟件說明獲得反極性。你讀了我的評論嗎?
-1
-1
@slebetman:並非所有處理器都支持HCF指令,只有一部分支持。您所有的軼事都是無效的。
@MickLH: OP並沒有詢問所有處理器。只是這樣的事情可能發生在常規處理器上。我會說未經修改的Core i7可以作為普通處理器使用。
@slebetman如果您真的想發揮語義:OP表示“微控制器”,而不是“中央處理器”或“處理器”。抱歉。(通常,“常規”微控制器的設計即使在軟件開發過程中也不會出現物理故障。例如,以Arduino使用的Atmel之一為例:它最大消耗0.2 mA的電流,並以5V電壓運行。此理論上的最大值鑑於散熱,每瓦1瓦的電能只能在室溫以上達到59攝氏度-資料來源:http://www.atmel.com/images/doc8161.pdf http://cds.linear.com/docs/en/packaging/Linear_Technology_Thermal_Resistance_Table.pdf
Guill
2014-08-23 01:30:51 UTC
view on stackexchange narkive permalink

我相信,用軟件物理上破壞微控制器(MC)當然是可能的。所需要的只是MC的組合正在執行“緊”的指令循環(導致100%的利用率),以及“有缺陷的”散熱片,使芯片內部的熱量散失。建立。故障發生的時間是幾秒鐘,幾分鐘還是幾小時,將取決於熱量積聚的速度。

我有一台筆記本電腦,只能連續使用50%。如果超過此限制,計算機將自行關閉。這意味著在使用率達到50%時,MC溫度低於設置的觸發點。隨著使用量的增加,MC的溫度會升高,直到達到觸發點。如果熱關斷電路不起作用(或沒有熱關斷電路),則MC的溫度將繼續升高,直到被破壞為止。

Maxthon Chan
2016-03-24 10:22:43 UTC
view on stackexchange narkive permalink

schematic

模擬此電路 –使用 CircuitLab sup>

  #include <avr / io.h>int main(void){DDRB | = _BV(2)|_BV(4);PORTB | = _BV(2);PORTB & =〜_BV(4);for(;;);}  

上面的代碼使MCU將PB2推高,同時將PB4拉低,這會造成VDD到PB2到PB4到GND的短路,並且PB2和/或PB4的端口驅動程序將被炸。短路可能是無意的錯誤,例如意外的電橋。

我對此是否有效表示懷疑。IO引腳通常無法提供或吸收大量電流。IO驅動器晶體管會限制電流。
@AdamHaun問題是不存在電流限制。這裡發生的是該電路可以燒毀那些晶體管。
電流限制來自輸出驅動晶體管的尺寸和柵極電壓。也許5V的AVR可能會燒毀驅動器,但查看ATMega典型的驅動器強度圖表,將3V Vcc短路兩個引腳在一起甚至可能不會超過絕對最大引腳電流。而且電流會在高溫下下降!低功耗的MCU可能很好。


該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...