Bảo vệ phần sụn trên bộ điều khiển AVR và PIC


23

Ai đó có thể trích xuất tệp HEX mà tôi ghi trong vi điều khiển mà tôi cung cấp không?

Nếu điều đó là có thể, làm thế nào ai đó có thể đảm bảo rằng mã của họ được bảo mật trong các hệ thống nhúng? Trong trường hợp vi điều khiển PIC và AVR, làm thế nào người ta có thể bảo vệ phần sụn của họ khỏi bị sao chép?



1
Trong trường hợp # 1, bạn dường như đề nghị rằng bạn cung cấp tệp hex cho khách hàng của mình, trong trường hợp đó họ chỉ có thể ghi nó vào một số thiết bị sao chép, không cần phải dịch ngược mã mặc dù điều đó là có thể. Trong trường hợp thiết bị bị khóa (# 2), vấn đề là họ quyết tâm lấy mã như thế nào (nói cách khác là họ chuẩn bị chi bao nhiêu) nhưng thường thì có thể.
alexan_e

1
nó đã được hai năm, nhưng bảo vệ những ngày này có xu hướng bị đánh bại trong một hoặc hai ngày trung bình cho các thiết bị phổ biến. về cơ bản một khi ai đó đã quyết định nó là đáng làm. Nếu bạn thực sự muốn bảo mật, bạn cần tham gia kinh doanh chip, bạn sẽ không nhận được bất kỳ thứ gì ngoài các bộ phận thương mại.
old_timer

Câu trả lời:


33

Hầu hết các bộ điều khiển vi mô ngày nay có các phương pháp cụ thể của nhà sản xuất hoặc bộ phận để bảo vệ mã chương trình cơ sở nhúng. Điều này thường được thực hiện bằng cách khóa các mạch thường cho phép đọc bộ nhớ mã. (Bạn sẽ phải tìm kiếm một số chi tiết cụ thể trong bảng dữ liệu hoặc tại trang web của nhà sản xuất trong các ghi chú ứng dụng).

Sau khi khóa, không thể đọc bộ nhớ mã bằng các kỹ thuật thông thường. Điều này cung cấp một mức độ bảo vệ hợp lý để ngăn chặn hầu hết các tin tặc xem mã máy cho ứng dụng nhúng của bạn.

Nhiều thiết bị MCU ngày nay có bộ nhớ FLASH trên bo mạch để lấy mã chương trình. Một chương trình được lưu trữ và bảo vệ trước đó được lưu trữ trong FLASH thường có thể được thay thế bằng mã mới nhưng phải thực hiện thao tác xóa FLASH đầy đủ chip để mở khóa cơ chế bảo vệ. Sau khi xóa, phần sẽ hoạt động như trước khóa bảo vệ ban đầu. Nếu một chương trình mới được tải, thường có thể khóa lại phần đó để bảo vệ mã máy mới được tải.

Bất kỳ cuộc thảo luận nào về bảo vệ mã trong vi điều khiển sẽ không được hoàn thành nếu không đề cập rằng thường không có gì đảm bảo rằng bất kỳ sơ đồ bảo vệ nào được cung cấp bởi nhà sản xuất bộ phận là bằng chứng ngu ngốc. Các nhà sản xuất thậm chí sẽ tuyên bố rằng các hệ thống bảo vệ không phải là bằng chứng ngu ngốc 100%. Một trong những lý do cho điều này là có cả một ngành công nghiệp thị trường chợ đen đang diễn ra, với một khoản phí, các tin tặc siêng năng sẽ đọc mã từ một phần được bảo vệ cho bất kỳ ai muốn trả tiền. Họ đã nghĩ ra các phương án khác nhau cho phép đọc mã ra khỏi ROM hoặc FLASH trên các bộ điều khiển vi mô được bảo vệ. Một số trong những kế hoạch này rất thông minh nhưng hoạt động để thành công tốt hơn ở một số gia đình hơn là những người khác. Vì vậy, nhận thức được thực tế này sau đó bạn cố gắng bảo vệ chương trình của bạn khỏi con mắt tò mò.

Khi ai đó đã chạm tay vào hình ảnh nhị phân của mã máy đã được đọc từ vi điều khiển, cho dù đó có phải là vi điều khiển được bảo vệ hay không, họ có thể xử lý mã máy thông qua một công cụ gọi là trình dịch ngược. Điều này sẽ biến dữ liệu nhị phân trở lại thành mã ngôn ngữ lắp ráp có thể được nghiên cứu để cố gắng tìm hiểu cách các thuật toán của chương trình của bạn hoạt động. Thực hiện việc tháo gỡ chính xác mã máy là một công việc khó khăn có thể mất rất nhiều công việc. Cuối cùng, quá trình có thể dẫn đến mã trình biên dịch mã như tôi đã mô tả. Nếu chương trình của bạn được viết bằng một số ngôn ngữ cấp cao như C, C ++ hoặc Basic, mã lắp ráp sẽ chỉ đại diện cho kết quả được biên dịch và liên kết của chương trình của bạn. Nhìn chung, không thể đảo ngược kỹ sư bị đánh cắp mã trở lại trình độ ngôn ngữ cấp cao.

Điều này có nghĩa là thực sự có lợi ích khi viết phần sụn ứng dụng nhúng của bạn bằng ngôn ngữ cấp cao. Nó cung cấp một lớp khác khiến cho chương trình của bạn khó có thể được thiết kế ngược hoàn toàn. Lợi ích lớn hơn nữa là có được bằng cách sử dụng trạng thái cao nhất của nghệ thuật trong việc tối ưu hóa trình biên dịch để biên dịch ứng dụng nhúng vì trình tối ưu hóa hiệu suất cao nhất có thể biến chương trình thành một bát mì spaghetti khổng lồ chứa hàng tá lệnh gọi đến chương trình con ngắn rất khó để giải mã trong một trình dịch ngược.

Hầu hết các nhà phát triển nhúng có kinh nghiệm sẽ bảo bạn tiếp tục và sử dụng bất kỳ sơ đồ bảo vệ nào được cung cấp trên MCU trong ứng dụng của bạn .... nhưng không phụ thuộc vào nó đến cuối con đường cho sản phẩm của bạn. Họ sẽ nói với bạn rằng cách tốt nhất để vượt lên trước đối thủ là liên tục nâng cấp sản phẩm của bạn để các phiên bản cũ đã lỗi thời và không quan tâm đến thời điểm tin tặc có thể sao chép mã của bạn. Thay đổi mã xung quanh, thêm các tính năng mới, thỉnh thoảng quay bảng PC của bạn để trao đổi tất cả I / O của bạn và bất kỳ điều gì khác mà bạn có thể nghĩ đến. Bằng cách này bạn có thể giành chiến thắng cuộc đua mọi lúc.


Cảm ơn bạn rất nhiều @Michael Karas Đó là một câu trả lời hoàn chỉnh
Rookie91

12

Tôi nghĩ câu trả lời của Michael là đủ cho câu hỏi này nhưng tôi thêm cả hai liên kết sau: Hack PIC 18F1320mọi thứ họ làm, Chúng tôi có thể phá vỡ! Cả hai đều rất thú vị đối với tôi.


EE siêng năng nên nghiên cứu liên kết cuối cùng đó và nghiên cứu / so sánh / chọn thiết bị bị thiếu trong danh sách. Sự phức tạp luôn có tính răn đe nhiều hơn - chẳng hạn như thêm DS3641 hoặc ATSHA204 . Mặc dù không có bảo mật bổ sung nào sẽ không thể phá vỡ 100%, nhưng sự phức tạp được thêm vào có thể khiến nó không đáng giá.
ndtsc
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.