Có thể phá hủy vật lý một vi điều khiển bằng phần mềm?


29

Giả định:

  • Không có mạch ngoài được kết nối (trừ mạch lập trình, mà chúng tôi giả sử là chính xác).
  • uC không bị lỗi.
  • Bằng cách phá hủy tôi có nghĩa là giải phóng khói xanh chết chóc, không gạch nó trong phần mềm.
  • Đó là một uC "bình thường". Không phải là một số thiết bị cụ thể rất có mục đích 1 trong một triệu.

Có ai từng thấy điều gì đó như thế xảy ra không? Làm thế nào là nó có thể?

Lý lịch:

Một diễn giả của một cuộc họp mà tôi đã hỗ trợ để nói rằng có thể (và thậm chí không khó lắm) để làm điều này, và một số người khác đã đồng ý với anh ta. Tôi chưa bao giờ thấy điều này xảy ra, và khi tôi hỏi họ làm thế nào có thể, tôi đã không nhận được câu trả lời thực sự. Bây giờ tôi thực sự tò mò và tôi rất muốn nhận được một số phản hồi.


3
Cách duy nhất khả thi để điều này xảy ra, IMO, là nếu một pin được kết nối vật lý với VCC / COM, và pin được cấu hình để được điều khiển ngược lại với những gì nó được kết nối, gây ra tình trạng quá dòng. Nhưng đó là một kết hợp CTNH / SW thất bại.
Shamtam

6
Nhiều bộ điều khiển có đèn flash có thể được viết dưới sự kiểm soát của phần mềm và có thể bị hao mòn. Phần mềm nào sẽ làm hao mòn bộ nhớ trong một khoảng thời gian ngắn được tính là "phá hủy" chip?
supercat

1
Ngoài quan sát của biệt phái @ supercat về EEPROM hoặc hao mòn đèn flash (có thể làm hao mòn EEPROM trong vài phút), tôi sẽ nói thêm rằng có rất ít sự khác biệt trong nhiều trường hợp từ người dùng POV giữa thiết bị bị phá hủy vật lý và 'cục gạch 'sản phẩm. Nếu nó phải quay trở lại nhà máy, nó trông khá giống nhau.
Spehro Pefhany

1
Cẩn thận với vòng nhị phân vô hạn phức tạp thứ n . Nó đã có từ rất lâu rồi ...
jippie

3
@Roh Tôi đã đốt một con chip, bởi vì anh chàng phần cứng đã tráo đổi các chân Vcc và GND trên PCB. (Tôi nghĩ rằng anh ta mặc dù con chip là một sự thay thế ... Nó không phải.) Có khói và nhựa bị cháy. Nó không kéo dài lâu, nhưng dây có thể tồn tại điều này rõ ràng.
Mishyoshi

Câu trả lời:


20

Tất nhiên bạn có thể, với hướng dẫn HCF !

Điều đó nói rằng, tôi nói rằng điều đó là không thể nếu không có bất kỳ mạch bên ngoài nào, ngoài sức mạnh và như vậy.

Ngay cả bao gồm một số kết nối không cố ý có thể sẽ không cắt được: nếu bạn buộc tất cả các gpios vào đường ray điện, đặt chúng làm đầu ra (cho đường ray điện đối diện) có thể tiêu hao khá nhiều năng lượng. Một pin gpio có thể được bảo vệ chống ngắn mạch và do đó, không có gì có hại sẽ xảy ra.

Thiết kế một mạch bên ngoài phá hủy chip theo ý muốn không phải là quá nhỏ theo quan điểm của tôi. Điều đầu tiên xuất hiện trong đầu cần một nguồn cung cấp điện cao thế, một nmos và điện trở:

sơ đồ

mô phỏng mạch này - Sơ đồ được tạo bằng CircuitLab Trong đó:

  • là nguồn cung cấp thông thường cho micro, khoảng 3v3 đến 5V hoặc bất cứ thứ gì cần thiếtVCC
  • HV là nguồn cung cấp điện áp cao hơn mức tối đa tuyệt đối của vi mô
  • D1 có mặt để bảo vệ nguồn điện áp 3V3 quý giá của bạn
  • R1 kéo cổng mosfet lên cao khi micro không giữ nó xuống đất
  • M1 là kẻ giết người được chỉ định

Thao tác rất đơn giản: nếu micro phát hành GPIOx M1 bật, Vcc tăng và chip của bạn bắt lửa. Lưu ý rằng đây là một thiết lập tào lao , ví dụ HV phải được bật sau khi bạn chắc chắn thêm rằng GPIOx được giữ chắc chắn. Một số bóng bán dẫn có thể không thích một số Vs -5V, v.v ... Nhưng bạn có được hình ảnh.


3
thích tham khảo HCF.
giữ chỗ

Hey, cảm ơn vì đã cho tôi một bộ phim truyền hình mới để xem!
OJFord

@OllieFord Tôi không chắc bạn đang nói về điều gì ...
Vladimir Cravero


15

Disclaimer: supercat nói rằng đầu tiên trong một bình luận.

Trên thực tế, không thể phá hủy vật lý hầu hết các MCU, nhưng có thể mặc nó đủ để bắt đầu trục trặc đến một điểm không thể sử dụng được. Tôi có kinh nghiệm với MSP430 của TI, vì vậy đây là:

Những MCU đó cho phép lập trình lại toàn bộ đèn flash bất cứ lúc nào. Không chỉ có thể đeo đèn flash bằng cách viết lại hàng triệu lần cho đến khi nó bị lỗi, mà trình tạo lập trình flash trên chip có thể gây ra lỗi cho bộ xử lý cấp thấp hơn nếu trình tạo lập trình được cấu hình không chính xác. Đây là một phạm vi tần số được phép cho phép lập trình. Khi ra khỏi phạm vi đó (chậm hơn), thời gian lập trình có thể trở nên quá dài và gây ra lỗi cho các ô flash. Chỉ sau vài trăm chu kỳ, có thể "đốt cháy" các tế bào flash gây ra lỗi vĩnh viễn.

Ngoài ra, một số kiểu máy cho phép ép xung lõi để nó đạt tốc độ cao hơn bằng cách tăng điện áp bên trong. MCU chạy từ nguồn cung cấp điện áp 1.8-3.6V, nhưng bản thân lõi được thiết kế để chạy ở mức 1.8V. Nếu bạn ép xung quá nhiều lõi trên đường ray điện 3.6V trong khi bật tất cả I / O, kích hoạt tất cả các thiết bị ngoại vi và chạy ở tốc độ 40 MHz (bình thường là tối đa 25 MHz trên các model lớn hơn), bạn có thể sẽ bị rán cốt lõi vì quá nóng. Trên thực tế, một số kẻ nói rằng họ đã đạt được những tần số đó (thường là DCO thất bại trước đó và chip được lưu, nhưng ... có lẽ).

Hãy thử nó?


nit-pick - Tôi tin rằng hầu hết đèn flash được đảm bảo hoạt động không quá 10.000 lần ghi chứ không phải "hàng triệu". Có lẽ không đáng để sửa chữa như bạn đang làm cho một điểm.
xe cứu thương

2
À ... Flash mặc. Tôi nhớ lần đầu tiên tôi gặp một lỗi gây ra việc ghi liên tục vào EEPROM trên một bức ảnh. Tất cả chỉ mất 10 giây hoặc lâu hơn thời gian chạy. Tôi mất khoảng một phút để nhận ra điều gì đã xảy ra :-)
slebetman

6

Theo stackexchange - "Có thực sự là một ý tưởng tồi khi để một chân đầu vào MCU nổi?"

Nó mô tả một số trường hợp trong đó một con chip thể bị hỏng bởi một chân mạch mở. Chỉnh sửa: một ví dụ Spansion Sản phẩm Vi điều khiển và Vi điều khiển cho biết:

4.1 Cổng vào / chân I / O kỹ thuật số không sử dụng
nên để các chân I / O kỹ thuật số không được kết nối, trong khi chúng được chuyển sang đầu vào. Trong trường hợp này, các chân đó có thể vào trạng thái nổi gọi là trạng thái nổi. Điều này có thể gây ra dòng điện ICC cao, bất lợi cho các chế độ năng lượng thấp. Ngoài ra thiệt hại của MCU có thể xảy ra.

Điều kiện trong câu hỏi này là chính xác các chân mạch mở.

Vì vậy, nhiệm vụ của chúng tôi là để lái xe rằng từ tháng tới sẽ làm hỏng pin. Tôi nghĩ thế là đủ để vượt qua 'gạch đá'.

Một cơ chế được xác định trong câu trả lời đó là điều khiển chân đầu vào tới điện áp giữa, trong đó hai bóng bán dẫn bổ sung đều 'bật'. Hoạt động ở chế độ đó, giao diện pin có thể bị nóng hoặc thất bại.

Một pin đầu vào có trở kháng rất cao, và cũng là một tụ điện. Có lẽ, chúng đủ khớp nối giữa các chân liền kề để bật các chân lân cận đủ nhanh có thể đẩy điện tích vào chân đầu vào và đẩy nó vào trạng thái 'nóng' đó. Có thể một nửa các chân I / O được điều khiển trong trạng thái đó làm ấm chip đủ để gây ra thiệt hại?

(Có chế độ nào không, có thể sử dụng điện dung của pin cirrcuit mở như bộ nhân đôi điện áp không? Hmm.)

Tôi cũng nghĩ flash gây hại là đủ. Tôi nghĩ rằng điều đó là đủ xấu để làm cho chip vô dụng.

Nó không cần phải là tất cả flash, mà chỉ là trang chứa các vectơ Power-on, RESET, v.v. Giới hạn trên một trang có thể mất vài chục giây.

Tôi đã có một dấu hiệu, nhưng không có bằng chứng chắc chắn) rằng đối với một số MCU, nó có thể tồi tệ hơn. Tôi đã tham dự một buổi thuyết trình vài năm trước. Một số người hỏi tại sao các đối thủ cạnh tranh cung cấp các bộ phận với đèn flash cao hơn nhiều. Người dẫn chương trình (nhà sản xuất MCU lớn chưa được đặt tên) cho biết họ đã thực hiện một cách tiếp cận bảo thủ hơn rất nhiều trong thông số kỹ thuật bộ nhớ flash của họ. Ông nói rằng sự đảm bảo của họ được xác định ở nhiệt độ cao hơn đáng kể so với tiêu chuẩn của ngành. Có người hỏi "vậy thì sao". Diễn giả cho biết một số sản phẩm của nhà sản xuất sẽ có thời gian viết lại thấp hơn đáng kể so với các bộ phận của chúng ở cùng một temps như chúng đã sử dụng. Hồi ức của tôi là 5x sẽ trở thành <1x. Ông nói nó rất phi tuyến tính. Tôi nghĩ điều đó có nghĩa là lập trình ở 80C thay vì 25C sẽ là một "điều tồi tệ".

Vì vậy, flash viết lại kết hợp với một con chip rất nóng, cũng có thể khiến nó trở nên vô dụng trong chưa đầy 10 giây.

Chỉnh sửa:
Tôi nghĩ rằng "giải phóng khói xanh chết chóc" là một hạn chế khó khăn hơn so với yêu cầu. Nếu bất kỳ một trong số: mạch pin RESET, đầu dò màu nâu, mạch cấp nguồn, RC hoặc bộ tạo dao động tinh thể (và có thể một vài mạch khác) có thể bị hỏng, chip sẽ bị vô dụng.

Như những người khác đã lưu ý, việc phá vỡ đèn flash cũng sẽ giết chết nó.

"Khói" nghe có vẻ ấn tượng, nhưng các cuộc tấn công gây tử vong ít rõ ràng hơn vẫn gây tử vong và khó phát hiện hơn nhiều.


5

Một nguồn tiềm năng của sự hủy diệt như vậy là SCR latchup, trong đó các bóng bán dẫn (bên trong) ngoài ý muốn trong một con chip kết hợp với nhau để tạo thành một loại TRIAC có thể chìm rất nhiều dòng điện. Điều này có thể dễ dàng thổi dây liên kết, và tôi thậm chí đã nhìn thấy các thiết bị bọc nhựa bị cong vênh rõ rệt vì nhiệt sinh ra.

Nguyên nhân điển hình là lái xe (thậm chí trong giây lát) một đầu vào bên trên hoặc bên dưới đường ray cung cấp hoặc mặt đất tương ứng, nhưng tôi đoán bạn có thể thấy điều đó xảy ra nếu đầu vào bị thả nổi. Và không khó để tưởng tượng một mạch trong đó phần nổi của đầu vào được điều khiển bằng phần mềm (mặc dù đó sẽ là một điều rất ngớ ngẩn khi cho phép).


4

Đó là KHẢ NĂNG rằng phần mềm được viết có chủ đích cho mục đích, nhắm vào một bộ xử lý rất cụ thể, có thể buộc ép xung đến điểm mà bộ xử lý sẽ quá nóng. Tất nhiên, miễn là bộ xử lý chứa các thanh ghi điều khiển đồng hồ có thể cấu hình bằng phần mềm.

Tất nhiên, KHÔNG THỂ TẤT CẢ các bộ xử lý có thể bị hỏng theo cách này. Nếu đó là sự thật, đã có hàng tỷ Z80 và 6800 và 6502 được đặt bên lề bằng cách viết các phần mềm viết ngược lại khi chúng ta vẫn gõ mã máy một cách thủ công, mắc rất nhiều lỗi ngẫu nhiên.


2
Bạn không cần truy cập để cấu hình đồng hồ. Bạn chỉ cần chạy phần mềm theo cách mà nhà thiết kế CPU không hình dung. Đây là một số mã cố gắng đạt được 4 FLOPS lý thuyết trên mỗi chu kỳ trên bộ xử lý Intel Core series: stackoverflow.com/questions/8389648/ trộm . Mã này đã được biết là quá nóng CPU.
slebetman

1
Điều này có liên quan đến các chương trình "virus điện" không?
davidcary

1
@davidcary, đó là một thuật ngữ hoàn toàn mới đối với tôi. Mặc dù vậy, tôi đã đề cập đến không phải là một loạt các hướng dẫn ngốn đồng hồ mà là thay đổi tốc độ xung nhịp thực tế (một số bộ xử lý hỗ trợ phần mềm kiểm soát tốc độ xung nhịp thông qua thao tác của các thanh ghi điều khiển) với tần số cao hơn CPU hoặc tản nhiệt của nó có thể đối phó với.
TDHofstetter

3

Đây là mục nhập của tôi để phá hỏng một vi điều khiển với càng ít bộ phận càng tốt ...

Chỉ cần chuyển các chân đầu ra ở một vài kHz!

Bạn vẫn có thể không thấy khói, tùy thuộc vào chế độ thất bại bên trong.

schematic

mô phỏng mạch này - Sơ đồ được tạo bằng CircuitLab

- Chỉnh sửa, thêm ngày 22 tháng 8--

Bây giờ, tôi không nghĩ bạn có thể phá hỏng một vi điều khiển với các tiêu chí được đưa ra. Nhưng bạn có thể DỄ DÀNG làm hỏng mạch bên ngoài với mã sai. Một ví dụ xuất hiện trong đầu là một bộ chuyển đổi tăng cường đơn giản mà tôi đã thiết kế gần đây ... chỉ cần tạm dừng mã trong khi gỡ lỗi có thể rút ngắn một cuộn cảm xuống đất thông qua MOSFET. POOF


2
Tôi không muốn trở thành "Chàng trai đó", nhưng Giả định số 1: "Không có mạch điện bên ngoài nào được kết nối"
Radian

1
Bạn đang là "Chàng trai đó". Nội dung của phản hồi này là "Không, bạn không thể làm hỏng một con chip như thế."
Daniel

2

Về mặt mã chế độ người dùng thông thường, tôi không nghĩ bạn có thể viết bất cứ điều gì sẽ phá vỡ chip.

Tuy nhiên, tôi nhớ những ngày vi xử lý có thể bị phá hủy trong vòng chưa đầy một phút hoặc thậm chí vài giây nếu tản nhiệt rơi ra. Sau đó, họ đã thêm các mạch phát hiện nhiệt sẽ làm giảm đồng hồ nếu bộ phận quá nóng. Bây giờ chúng ta có thể đặt nhiều bóng bán dẫn hơn nhiều so với có thể sử dụng cùng một lúc, chip có khả năng tạo ra nhiều nhiệt hơn tản nhiệt có thể tiêu tan và quản lý năng lượng và mạch nhiệt giữ an toàn. Ví dụ: xem Intel Turbo Boost 2.0. Do đó, dường như hoàn toàn có thể làm tan chip nếu bạn có thể bỏ qua hoặc tăng giới hạn về quản lý năng lượng và mạch nhiệt. Vì vậy, nếu những điều này nằm dưới sự kiểm soát của phần mềm (không có ý tưởng; có thể nó yêu cầu cập nhật BIOS?) Thì bạn có thể chạy một loạt các vòng lặp không làm gì song song, cùng với công việc GPU tích hợp, cùng với giải mã và mã hóa phần cứng H.264, và bất cứ điều gì khác mà chip có thể làm, tất cả cùng một lúc cho đến khi chip quá nóng và phát ra khói màu xanh kỳ diệu.


2

Tôi quen thuộc nhất với bộ xử lý STM32, vì vậy những bộ xử lý này áp dụng nhiều nhất cho gia đình đó. Nhưng cách tiếp cận tương tự cũng có thể với các bộ xử lý khác:

  1. Có một chế độ chống ghi vĩnh viễn. Vì vậy, nếu bạn lập trình bit đó và một số chương trình vô dụng với FLASH, MCU không bao giờ có thể được sử dụng lại. Tôi không biết nếu điều này được tính là 'cục gạch', nhưng nó liên quan đến một cơ chế phần cứng vĩnh viễn.

  2. Các chân lập trình được cấu hình lại như GPIO. Bởi vì chân đồng hồ được điều khiển bởi thiết bị lập trình, điều này có thể được sử dụng để gây đoản mạch. Rất có thể nó sẽ phá vỡ pin đơn, mà là một pin lập trình sẽ khá tệ.

  3. Giống như được đề cập bởi dirkt, PLL có thể được sử dụng để ép xung bộ xử lý. Điều này có thể có thể làm cho nó quá nóng hoặc bị hư hỏng.


1

Ai đã từng nói rằng điều đó không hiểu làm thế nào liên quan đến quá trình thiết kế của những con chip như vậy. Điều đó không có nghĩa là trượt lên không xảy ra và phạm vi bảo hiểm mã của các hồi quy và các trường hợp góc đôi khi bỏ lỡ mọi thứ, nhưng để đưa ra tuyên bố rằng TẤT CẢ hoặc thậm chí hầu hết các bộ xử lý đều có lỗi này là không hợp lý.

Chỉ cần tự hỏi, điều gì xảy ra khi một đồng hồ quá giờ vượt quá yêu cầu về thời gian (giả sử nó không quá nóng). chip bị lỗi và có thể làm hỏng bộ nhớ và thậm chí truy cập ổ cứng nhưng về cơ bản, bộ xử lý sẽ hoạt động trở lại và thậm chí chạy lại hệ điều hành nếu lỗi được khắc phục. Vì vậy, loại vi mã được thiết kế đúng có thể có thể gây ra sự gián đoạn THÊM hơn kịch bản này? - trả lời rất có thể không có.

TLDR; Tất cả các bộ xử lý đều có lỗi này - KHÔNG


I believe some/most microcontroller CPUs (by volume, not value) are not microcoded. So does that invalidate your assumption?
gbulmer

No, whether you're designing a sequencer or a fixed purpose cell the regressions and constraints/tests on the design will be tight.
placeholder

For a blue puff of smoke to occur the CPU would have overheated one way or another. Either by experiencing very high voltage, experiencing very high current, experiencing reverse polarity or experiencing too may transistors switching at too high a frequency. Only the last method is doable in software. CPUs that run lower than around 500MHz are unlikely to die because of software caused overheat but I've seen CPUs die due to software caused overheat. The assumption you made is exactly what you shouldn't.
slebetman

@slebetman you are conflating far far too many things here. How does one get "reverse polarity" through software instructions? how does one get "too many switching at too high of a frequency" is there perhaps a magical flaw in all chips that turn them into massively parallel execution pipelines?
placeholder

@placeholder: I said you can't get reverse polarity through software instructions. Did you read my comment?
slebetman

1

I believe that it is certainly possible to physically destroy a micro-controller (MC) with software. All that is required, is the combination of the MC to be executing a "tight" loop of instructions that cause 100% utilization, and a "defective" heat-sink which allows the heat inside the chip to buildup. Whether the failure takes seconds, minutes or hours, will depend on how fast the heat builds up.

I have a laptop computer that I can only use it a 50% continuous utilization. If I exceed this, the computer shuts itself down. This means that at 50% usage the MC temperature is below the set trigger point. As the usage increases, the temperature of the MC increases until the trigger point is reached. If the thermal shut down circuit did not work (or did not have one), the temperature of the MC would keep on increasing until it got destroyed.


0

schematic

simulate this circuit – Schematic created using CircuitLab

#include <avr/io.h>

int main(void)
{
    DDRB |= _BV(2) | _BV(4);
    PORTB |= _BV(2);
    PORTB &= ~_BV(4);
    for (;;);
}

The code above causes the MCU to push PB2 high while pull PB4 low, and this creates a short circuit from VDD to PB2 to PB4 to GND and quickly the port drivers of PB2 and/or PB4 will fry. The short circuit may be an innocent error like accidental soldering bridge.


I'm skeptical that this would work. IO pins usually can't source or sink large amounts of current. The IO driver transistors would limit the current.
Adam Haun

@AdamHaun The problem is that there is no current limiting exist. What is happening here is that this circuit can burn those transistors.
Maxthon Chan

The current limiting is from the size and gate voltage of the output drive transistors. Maybe a 5V AVR could burn out the drivers, but looking at ATMega typical driver strength charts, with 3V Vcc shorting two pins together might not even exceed the absolute max pin current. And the current goes down at high temp! Lower-power MCUs would probably be fine.
Adam Haun
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.