[AVR] Jak zapisać aplikację WIN32 na HDD z mikrokontrolera w C/ASM?

Question

Witam, nie bardzo wiem jak podejść do tematu... Potrzebował bym z poziomu mikrokontrolera[AVR w C/ASM] zapisać aplikację zgodną z WIN32 na HDD lub kartę MMC/SD. Interesował by mnie opis ... jakie wartości bajtów zapisywać, aby aplikacja realizowała np. komendę MOV z ASM dla WIN32. Chodzi mi o...

MirekCz · Answer

Na stronie intela wszystko odnośnie kodu maszynowego znajdziesz. Co do zapisywania plików w FAT16 na MMC/SD to tematów na forum jest sporo.

elektryk · Answer

Nie rozumiem idei, czy program na PC będzie statyczny czy dynamiczny? Z poziomu AVR nie ma problemu zapisać cokolwiek na nośniku, poprostu realizujesz obsługę systemu plików (np FAT lub FAT32) i zapisujesz dowolne dane z pamięci AVR.

marenc · Answer

Z zapisem nie ma problemu... chodzi mi tylko głównie o sposób w jaki należy zapisywać bajty, aby utworzyć aplikację konsolową. Znam ASM dla Win32, więc opis jak wygląda instrukcja i argumenty w niej zawarte potrafił bym układać odpowiedni program ... Program będzie bazował na statycznie przydzielonej pamięci, ale zawartość programu(jego funkcje działania) będą różne

elektryk · Answer

A co ma przykładowo robić ten program? Chodzi mi o stopień kompilacji. Najprostszy program, który by tylko wyświetlał napis i się kończył zajmie może 20 instrukcji. Jeśli miałby coś np obliczać to ilości będzie wzrastać do powiedzmy 100 instrukcji. Nie wyobrażam sobie jak to miałoby działać z poziomu procesora AVR, może dałoby się to jakoś zrobić metodą kopiuj-wklej przez przechowywanie gotowych kawałków programu. Ja bym to zrobił tak że bym napisał bazowy program w asm i skompilował, a następnie modyfikował w nim instrukcje bajt po bajcie. Tyle że ten program musi mieć zapas miejsca w postaci dużej ilości instrukcji NOP, oraz w wersji bazowej wykorzystywać całą listę potrzebnych instrukcji WinAPI (tak żeby przy generowaniu nowych programów nie trzeba było się babrać w modyfikacje nagłówka PE). Zamiast wszystkich niezbędnych instrukcji można wykorzystać tylko dwie LoadLibraryA i GetProcAddress, ale wtedy dużo kodu zajmie samo wywoływanie i przechowywanie nazw funkcji i bibliotek. Nie wiem co dokładnie robisz, ale może da się to zrobić od drugiej strony, napisać pełną najbardziej rozbudowaną wersje programu, konfigurowalną przy pomocy powiedzmy stałych i w AVR trzymać listę stałych i ich adresy. Albo trochę inaczej, pełna wersja programu i wyłączać pewne bloki przez nadpisanie ich instrukcjami NOP.

marenc · Answer

No raczej nie ... z napisaniem programu nie będzie problemu. Program nie może być realizowany w sposób jaki wymieniłeś, bo zapisanie do AVR'ka dosyć szczegółowej obsługi(podmiany wartości bajtów) zajmie masę miejsca.

Na początek trzymał bym się tej wersji z odpaleniem napisu na ekranie i oczekiwanie na przycisk ...

A może wytłumaczę to w drugą stronę!? Jak AVR powinien interpretować instrukcje binarne aplikacji z WIN32? Znając to będę wiedział jak napisać aplikację z poziomu AVR'a.

elektryk · Answer

To zależy co tak naprawdę ma robić program. Opisz co to ma być, jakiś rodzaj sprzętowego asemblera?

marenc · Answer

Nie - assembler ma mi pomóc w zrozumieniu pisania aplikacji. Na HDD lub MMC/SD będą zapisywane dane zaszyfrowane odpowiednim dynamicznym kluczem(generowanym przez AVR). Aplikacje będzie musiała kasować wpisy w tablicy alokacji partycji o konkretnych plikach zawierających klucze po ich jednorazowym odczytaniu.

Coś w rodzaju sprzętowego szyfratora danych pobieranych z czujników. Aplikacja dba o bezpieczeństwo kluczy i ich utratę poprzez nadpisanie zerami. Musi być ona napisana przez mikrokontroler, aby zawierała adresy pod którymi są kawałki kluczy oraz potrafiła je zdekodować... W przyszłości może jakieś zabezpieczenia samej aplikacji przed disassembler'acją.

Projekt obszerny, ale poufność tych danych jest ogromna... Urządzenie będzie pracowało bez nadzoru przez dłuższy czas, a jego dostanie się w niepowołane ręce może sporo namieszać...

elektryk · Answer

Czy dobrze rozumiem że: 1. AVR zapisuje dane na nośniku (zaszyfrowane) 2. Program na PC odczytuje dane i usuwa je z nośnika. A co do tego ma pisanie aplikacji przez AVR?

MarasK · Answer

Problem wydaje się ciekawy, aczkolwiek nadal nie wiem po co Ci win32 w AVR. Użyj może innych słów, bo chętnie pomógłbym, ale nadal nie wiem gdzie leży problem

marenc · Answer

Adresy pod którymi znajdują się kawałki kluczy nie mogą być zapisane w pliku. Adresy pod którymi kawałki kluczy będą się znajdowały dla bezpieczeństwa będą dynamiczne oraz wrzucane do odpowiednich komórek plików(ukryte w plikach, ale nie naruszające danych z pliku i nie powiązane z plikiem).

AVR ma tylko poskładać odpowiednie bajty w aplikację zgodną z WIN32 - na tym polega problem. Co zapisać, aby uzyskać odpowiedniki komend z ASM?

Szybkość nie jest wymagana, a jedynie bezpieczeństwo danych...

Pisząc gotową aplikację w PC musiał bym z góry mieć ustalone gdzie są kawałki kluczy. Takie rozwiązanie jest niebezpieczne bo: zaszyfrowane dane + klucz = odszyfrowane dane. Napisanie aplikacji przez AVR pozwala na umieszczenie kluczy zupełnie przypadkowo...

Przykład: instrukcja ADD dla mikrokontrolera AVR zapisana w pamięci ma postać 0b000011rdddddrrrr, gdzie r - rejestr dodawany; d - rejestr do którego dodaje.

Chodzi mi o podobny opis, ale dla instrukcji assemblera WIN32, aby zapisywać dane na nośniku danych w formie aplikacji zgodnej z WIN32.

MarasK · Answer

I od razu problem się wyklarował Chodzi CI o postać kodu maszynowego dla x86. Googluj pod x86 machine code. Mam nadzieję pomoglem

marenc · Answer

To jest opis ASM dla WIN32 ... zajrzyj do pliku 253667.pdf(drugi link z Twoich) do działu "4.1 NOP - No operation". Na dole strony masz tabelkę 4.1 i o takie coś by mi chodziło ... nie sam opis, ale "Byte Sequence" dla danej instrukcji

W tych dokumentach niestety nie znalazłem do innych popularnych instrukcji niż NOP

Rozumiesz?

elektryk · Answer

Z kryptograficznego punktu widzenia to są jedynie złudne marzenia że to jest bezpieczne. Abstrahując od typowo kryptograficznego problemu losowości, to nadal pozostaje taki banalny problem, że skoro dajesz klientowi program który jest w stanie dane odtworzyć, to tak jakbyś dał mu te dane do ręki. Nie wiem jaka idea przyświeca Twojemu projektowi ale odnoszę wrażenie że chcesz zbudować coś w rodzaju kodu polimorficznego. Jest on stosowany typowo do ukrywania wirusów, jednak programy antywirusowe sobie jakoś świetnie dają radę z wykrywanie wirusów który za każdym razem są inne. Nie wiem co budujesz, ale wydaje mi się że idziesz w złym kierunku. Opisz co dalej się dzieje z tymi danymi (z nośnika) po zapisaniu ich przez procesor. Weź manual do procesorów Intel x86 tam będziesz miał dokładnie taki sam opis.

marenc · Answer

Co do manuala Intel x86 to chyba właśnie kolega wcześniej dał linki... Czy nie o to chodzi?

Widzę, że kolega trochę za bardzo się wgłębia z zasadę działania całości

Aplikacja będzie i owszem dostępna do użytkownika, ale będzie ona ponownie rozbita(jak klucze) w losowe miejsca oraz sama będzie zaszyfrowana. Pod WIN32 sam napiszę aplikację, która odpowiednio długim algorytmem będzie sobie składała tą aplikację. Jak już ją złoży to użytkownik będzie miał jedynie możliwość jednokrotnego "użycia" plików...

To jest własnie podchwytliwe ... dostając zaszyfrowane dane raczej się nie spodziewasz, że odpowiedź co do klucza generacyjnego(lub program dekodujący) jest zawarty w danych. A aplikacja jak wcześniej napisałem będzie zaszyfrowana i rozbita na nośniku. W efekcie użytkownik dostaje jeden plik(pozory jednego zaszyfrowanego dokumentu), który w rzeczywistości będzie całą zawartością nośnika(nie chce wzbudzać podejrzeń, że plik jest mniejszy niż zapisy na nośniku. Aplikacja nadpisuje dane podczas jej zamykania - bo gdyby się już komuś miało udać ją znaleść to dane w niej zawarte ulegną trwałemu zniszczeniu po jednorazowym ich otworzeniu. Dla zwiększenia czujności mogę mieć X plików z danymi, podczas gdy tylko 1 będzie prawdziwy ... otwarcie fałszywego nadpisuje ten poprawny.

MarasK · Answer

wybrany z tej strony: Trochę tylko przeglądnąłem i dla mnie to gra nie warta świeczki - za dużo tego. To już nie jest jak w AVR OPCODE + ŹRÓDŁO + CEL. Ale... nie zniechęcam Cię

marenc · Answer

Albo jestem ślepy, albo tam tego nie ma ... sam też szukam i nic ...

elektryk · Answer

Będzie mógł to robić nieskończenie wiele razy, tyle razy ile sobie skopiuje kartę SD i czy CF. Można zrobić idealną kopię karty tyle razy ile chcesz. Można się zabawić w przywiązanie aplikacji do numeru seryjnego karty, ale to niewiele zmieni, bo i tak będzie można nadpisać kartę wcześniej zrobionym obrazem. W tym pliku (wspomnianym wcześniej) masz cała listę instrukcji, opcodów i argumentów.

marenc · Answer

Tego nie przewidziałem ... ... macie jakieś pomysły na zabezpieczenie danych? Sorry za niedopatrzenie w tym dokumencie ...

Dr_DEAD · Answer

Zabezpieczenie przed czym???? Masz trzy urządzienia: AVR'a, Nośnik Danych i Komputer. Jeżeli złodziej będzie miał dostęp do conajmniej dwóch z tych trzech rzeczy to jakim cudem ty chcesz to zabezpieczyć?

elektryk · Answer

Najchętniej ja bym usłyszał opis funkcjonalności projektu, to może bym sam się domyślił o co biega. Ale jeśli uważasz że to jest aż tak tajne to rozważ poniższe zagadnienia. Oszacuj najpierw ilość danych i jak bardzo są cenne. Potem odpowiedz na pytanie czy chcesz budować układ finalny czy tylko potestować różne rozwiązania (np do pracy dyplomowej). Następnie określ jakie mają być etapy przetwarzania danych i które etapy mają być bezpieczne. A na końcu wyjaśnij mi po co użytkownik przed którym te dane są zabezpieczane ma mieć opcję podglądu.

MarasK · Answer

Mm popieram elektryka, ale wpadłem na inny pomysł. Może zrobić coś na zasadzie karty kodowej - robisz laminat o takim kształcie i rozkładzie pinów na slocie (bocznej krawędzi płytki), aby mógł symulować kartę SD/CF/MMC (do wyboru). A na samym laminacie umieszczasz procka z jakąś zewnętrzną pamięcią.

W procku (AVR) umieszczasz takie szyfrowanie, jakie chcesz. Oczywiście dane w zewnętrznej pamięci również są zaszyfrowane.

[AVR] Jak zapisać aplikację WIN32 na HDD z mikrokontrolera w C/ASM?

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Post #15

Post #16

Post #17

Post #18

Post #19

Post #20

Post #21

Post #22

Podsumowanie tematu