Port MD5 dla AmigaOS 4.1

22.10.2011 17:47

W PPA#1 opisano algorytm CRC32. Widząc dopiero zapowiedź tego artykułu jeszcze przed wydaniem numeru napotkałem na podobny problem. Otóż okazało się, że na mojej SAM440 świetnie "ściąga się" i wypala obrazy ISO (Update 1 dla AmigaOS 4.1, aktualizacje Uboot), ale nie bardzo jest jak sprawdzić ich integralność po zakończeniu operacji pobierania. Problem o tyle istotny, że OWB do dzisiaj nie dorobiło się paska postępu (na szczęście AmigaOS 4.1 sam aktualizuje wyświetlane foldery oraz objętość RAM dysku). Dodatkowo obrazy ISO z dystrybucjami Linuksa dla SAM zazwyczaj posiadają plik [nazwa_iso].md5, więc głupotą byłaby próba instalacji takiego systemu bez sprawdzenia czy obraz jest poprawny. W ten oto sposób nadarzyła się okazja do szybkiego przetestowania SDK dostarczanego przez firmę Hyperion. Dlaczego nie CRC32? Powodów jest kilka. Pierwszy to fakt, że dla obrazów ISO z dystrybucjami Linuksa sumy kontrolne są liczone w MD5. Stan taki ma swoją przyczynę. Podłożem problemu algorytmów z rodziny CRC jest fakt, iż nie dają one odpowiedniej pewności co do integralności kontrolowanego obiektu (wiadomości). Mówiąc już bardziej technicznie - nie są one kryptograficznie silne. MD5 z kolei należy do kryptograficznych, jednokierunkowych funkcji skrótu. Oznacza to w teorii, że: 1. zmiana jednego bitu w wiadomości powoduje inny wyniki funkcji 2. nie ma dwóch różnych wiadomości dających taki sam wynik funkcji 3. z wyniku funkcji nie można odczytać lub wydedukować wiadomości, która została użyta jako wejście 4. ta sama wiadomość zawsze da taki sam wynik. W praktyce charakterystyka z punktu drugiego nazywana jest brakiem kolizji. Jak się okazuje MD5 ma jednak kolizję. To jeden z powodów, dla którego od kilku lat zaleca się zastępowaniem jej silniejszymi funkcjami skrótu, np. z rodziny SHA. Na nasze potrzeby wady MD5 nie mają jednak aż tak dużego wpływu i dlatego przy niej pozostaniemy. Z perspektywy teorii bezpieczeństwa informacji CRC32 ma kilka wad, o których warto wspomnieć w kontekście MD5. Nawet jeśli użyjemy najdłuższego standardowego wielomianu 65-bitowego (CRC64), nadal pozostaje problem wykrywania określonych zmian. Sumy kontrolne zostały wymyślne do wykrywania typowych błędów w transmisji danych, a ich zadaniem była szybka kontrola komunikatu. Oznacza to, że wiadomość można tak zmodyfikować, aby jej suma kontrolna pozostała bez zmian. Dlatego do kontroli obrazów ISO czy pamięci, MD5 lub mocniejsze funkcje skrótu nadają się znacznie lepiej. Różne cele twórców algorytmów CRC i MD (MD5 jest jednym z rodziny funkcji, wcześniejsza jej wersja nazywała się MD4) mają odzwierciedlenie w ich konstrukcji. MD5 nie jest oparta o wielomian, pod który podstawia się kolejne bity wiadomości. Cała wiadomość jest dzielona na równe, 512-bitowe bloki + ostatni blok o długości 448 bitów. Bloki są uzupełniane za pomocą zer do wymaganego rozmiaru. Różnica w rozmiarze ostatniego bloku wynika z faktu tworzenia miejsca na 64-bitowy licznik oznaczający rozmiar wiadomości. W ten sposób wszystkie bloki wiadomości mają jednakową długość 512 bitów. Każdy blok przechodzi transformację, która składa się na wynik końcowy. Zainteresowanych kryptografią odsyłam do Wikipedii gdzie znajduje się dokładniejszy opis algorytmu MD5. "Portujemy" md5.c Gdy stanąłem przed problemem weryfikacji obrazu ISO, sięgnąłem do zasobów OS4Depot i stwierdziłem, że hasło "md5" zwraca zero wyników. Drugim adresem był Aminet i tutaj znalazłem 8 pakietów, z czego najnowszy był z 2000 roku (generator liczb pseudolosowych na bazie MD5 dla 68k i PPC). Ciekawą opcją wydała się wersja dla Arexxa, ale idąc tym tropem równie dobrze mógłbym skorzystać z wbudowanej w AmigaOS 4.1 wersji Pythona. Pakietów dla PPC i wersji nowszej niż 4.0 dla AmigaOS nie znalazłem. Postanowiłem zatem w pełni wykorzystać dostępne mechanizmy i aplikacje w wersji 4.1 systemu. Pierwszym krokiem była instalacja oficjalnego SDK. SDK można bezpłatnie pobrać ze strony firmy Hyperion - w momencie pisania tego artykułu najnowsza publicznie dostępna wersja była oznaczona numerem 53.20 z 1 marca 2010 roku. Ponieważ jest to wersja sprzed Update 2, to pewnie w momencie czytania tego tekstu będzie dostępna nowsza wersja. Instalacja SDK przebiega prosto. Po rozpakowaniu archiwum uruchamiany program instalacyjny i klikamy w "Next". Następnie wykonujemy jeszcze restart (choć można obyć się bez niego - szczegóły znajdziecie w dokumentacji SDK). Program instalacyjny domyślnie zakłada przypisania SDK:. Po restarcie możemy sprawdzić czy wszystko działa. W tym celu uruchamiany kompilator GCC z przełącznikiem "-version". Jeśli GCC się uruchomiło, to znaczy że kompilator działa. Nie spotkałem się z problemami podczas instalacji SDK na czystym systemie, więc niewiele mogę powiedzieć o potencjalnych pułapkach. Natomiast podczas aktualizacji lub usuwania SDK należy uważać i pamiętać o tym, aby usunąć wpisy dodane przez program instalacyjny do Startup-Sequence i User-Startup. Teraz możemy utworzyć plik hello.c: #include <stdio.h> void main() { printf(„Hello world”); } Lub jeśli wolimy c++ (wtedy plik zgodnie z przyjętymi konwencjami powinien nazywać się hello.cpp): #include <iostream.h> void main() { cout << “Hello world”; } Do utworzenia pliku w zupełności wystarczy systemowy Notepad. Po jego zapisaniu w katalogu, w którym znajduje się plik wydajemy polecenie: gcc -o hello hello.c lub gcc -o hello hello.cpp w zależności od wersji dialektu, który wybraliśmy. Przełącznik "-o" definiuje nazwę pliku wykonywalnego, który zostanie utworzony na podstawie kompilacji plików źródłowych. Domyślnie gcc tworzy plik wynikowy o nazwie a.out. W przypadku AmigaOS 4.x kompilator tworzy pliki w formacie ELF a nie HUNK, jak ma to miejsce w przypadku wcześniejszych wersji systemu. Warto o tym pamiętać, ponieważ pakiet bintools poprawnie obsługuje pliki wynikowe AmigaOS 4.x. Dzięki temu możemy na przykład korzystać z narzędzia objdump, które jest dołączone do oficjalnego SDK. Pobieramy plik źródłowy z adresu: http://people.csail.mit.edu/rivest/Md5.c i zapisujemy go na dysku. Teraz możemy skompilować nasz "port" md5.c wydając polecenie: gcc -o md5 Md5.c pod warunkiem, że znajdujemy się w tym samym katalogu, w którym zapisaliśmy kod źródłowy. Do pierwszych prób idealnie nadaje się mechanizm RAM dysku. Jeśli wszystko pójdzie dobrze, powinniśmy otrzymać plik wynikowy md5, który jest gotowy do użycia. Inne strategie portowania Do tej pory korzystaliśmy tylko z narzędzi z oficjalnego SDK. Do tak małego projektu, który składa się z jednego pliku źródłowego, wykorzystanie samego SDK ma dużo sensu. W przypadku bardziej złożonych projektów oczywiście można pisać pliki makefile i używać ich do kompilacji, jednak na dłuższą metę jest to rozwiązanie mało wygodne. Dlatego możemy wybrać dwie strategie: - wykorzystanie środowiska IDE na platformie AmigaOS, - wykorzystanie cross kompilatorów na innych platformach. Opcja druga daje szerokie możliwości i wygodę pracy (zwłaszcza jeśli ktoś tworzy przede wszystkim na inne platformy, a Amiga jest platformą mniej ważną). Można wykorzystać omawiany w poprzednim numerze PPA, AmiDevCPP na platformie Windows. Dla systemów Unix, Linux, BSD dostępne są cross kompilatory, z czego najlepsze doświadczenia miałem z tymi bazującymi na gcc. Pakiet z którym najlepiej mi się pracowało na OpenBSD został przygotowany przez Joachima "Zerohero" Birginga i jest dostępny pod adresem: http://www.zerohero.se/cross/os4.html Wybór AmigaOS jak platformy deweloperskiej stawia nas przed wyborem: Cubic IDE lub CodeBench. Oba pakiety potrzebują oficjalnego SDK. Teoretycznie można na AmigaOS 4.x uruchomić jeszcze StormC PPC, ale w moim przypadku pakiet ten na AmigaOS 4.1 nigdy nie działał stabilnie. Cubic IDE wymaga obecności SDK w wersji 51.22. Idealnie jest najpierw zainstalować Cubic IDE a potem SDK [3]. Rozmowy z twórcą pakietu pozwoliły potwierdzić, że działa on poprawnie z nowszymi wersjami SDK, ale nadal jest wymagana instalacja wersji 51.22 SDK. Niestety Hyperion Entertainment na swojej stronie, w momencie pisania artykułu, udostępniał ze starych wersji tylko 53.13. CodeBench nie był dostępny w pełnej, komercyjnej wersji w trakcie pisania tego tekstu. Chwilami przypomina on StormC PPC, co dla użytkowników tego produktu firmy Haage&Partners może być zaletą. Z drugiej strony inna filozofia działania niż w przypadku CubicIDE nie każdemu musi odpowiadać. Dlatego najlepszym rozwiązaniem jest pobranie wersji demo obu pakietów i ich samodzielne porównanie. Do dalszej pracy będziemy używać CodeBench, ponieważ obecna wersja pracuje poprawnie z aktualnym SDK 53.20. Aby wygodnie edytować kod, musimy najpierw utworzyć projekt. W tym celu wybieramy z CodeBench ToolBar przycisk "Create new project" (żółty sześcian po lewej stronie). W oknie "Project information" wpisujemy następujące elementy: W zakładce General: Project name (czyli nazwa projektu) - wpisujemy: MD5, Project base directory (czyli lokalizacja katalogu, który będzie zawierał nasze pliki) W zakładce Make zaznaczamy opcję "Create Makefile". W zakładce Linker, w polu "Executable name" ustawiamy nazwę pliku wynikowego, np. cbmd5. W oknie Project... dodajemy do pozycji "Source files" nasz plik Md5.c. Teraz zapisujemy projekt i możemy pracować dalej. Podczas pierwszej kompilacji moją uwagę zwróciło ostatnie ostrzeżenie dotyczące wyniku zwracanego przez funkcję main(). Poprawmy ten problem. W tym celu w kodzie źródłowym należy dokonać kilku zmian. Najpierw odszukaj funkcję main() - jest ona na końcu pliku. W jej definicji należy usunąć słowo kluczowe void i zastąpić je słowem kluczowym int. Teraz definicja funkcji wygląda tak: int main( argc, argv) int argc; char *argv[]; Następnie w ostatniej linijce kodu funkcji main() dodajemy kod: return(0); i zapisujemy kod źródłowy na dysk. W oknie "Build window" wybieramy opcję "Build whole Project", co spowoduje skompilowanie wszystkich plików projektu (w naszym przypadku jest to oczywiście tylko jeden plik). Teraz warto się przyjrzeć jeszcze wewnętrznej budowie programu. W oknie "Quick Links" mamy pokazane niektóre funkcje. Jak widać brakuje main() oraz kilku innych funkcji - jest to jeden z elementów do poprawy w kolejnych wersjach CodeBench. Oto kilka istotnych funkcji: MDString () - wylicza funkcję skrótu dla danej wiadomości przekazanej jako parametr MDTestSuit() - testuje poprawność algorytmu na znanych wiadomościach oraz zakodowanych poprawnych wartościach funkcji skrótu dla nich MD5Init() - inicjalizuje funkcję skrótu (bez wywołania tej funkcji algorytm nie będzie działał poprawnie) Transform() - razem z makrodefinicjami serce algorytmu MD5 (tutaj zaimplementowane są wszystkie 4 rundy przekształcenia, które decydują o sile MD5) Odnośniki Cubic IDE http://devplex.awardspace.biz/ CodeBench http://www.codebench.co.uk/ Installing the latest OS4 SDK in Cubic IDE http://www.amigans.net/modules/AMS/article.php?storyid=30 Artykuł oryginalnie pojawił się w trzecim numerze Polskiego Pisma Amigowego.

Simon Archer (February 2009)

22.02.2009 21:22

Could you introduce yourself and briefly describe what you do? Which Amigas do you use? Could you describe circumstances that made you interested in Amiga and AmigaOS 4.0? My name is Simon Archer, and I'm an Alcoholic....erm, wrong forum :) I have been involved with the Amiga for a lot of years now. My first Amiga experience was at a friends house. He had a wildly expanded A500 (around 1987 or so anyway) which he used for raytracing and animation etc. This intrigued me, as my current computer at the time was a C64. Needless to say it wasn't long after that I found a second hand A500 which came home with me. After that, spending money on Amiga stuff was like water down the river:- neverending. A natural progression from the A500, to an A2000, and then A4000 (with many others in there too) followed. I still have my A2000, A4000 and a highly modified A600. Over the years I have run just about every version of the operating system that has been released, and it has always been my OS of choice, even though these days a Windows XP box does get a lot of use too. AmigaOS4 was just the natural progression for me, and I run the very latest 4.1 version available, which is part of my duties as a beta-tester. Could you generally describe what CodeBench is? It is a Development Management Environment specifically aimed at AmigaOS 4.1, and designed from scratch to work with the AmigaOS 4 SDK, amongst others. It basically offers the functionality of compiling and editing code all in one interface. There are other features too, more on that later. What made you decide to work on this project? Because there is nothing else out there designed purely for AmigaOS 4.1. Cubic is a great piece of established software, and I certainly don't want to take any business away from Deitmar, but it's time for a native application that works in a similar fashion to the operating system, which was my main drive for basing it on Reaction. What is special about this program that will make it shine amongst other similar programs known from other platforms? As it has been written from scratch, it already has an advantage of not being laden down by bloat from ported systems. I have specifically made sure I don't look at any other development environments purely so that I don't pick up any bad ideas :) CodeBench is going to be the first such program for AmigaOS 4.1, and because all previous attempts to create something similar have failed so far, aren`t you afraid that "curse" will make this project fail as well? Interesting. Firstly, this project started from a need for software of its type. I needed something easy to code in, so to me, this project will never fail. Secondly, as there is a functionally limited version being given away for free licence, I find it hard to say it will fail. While I need this software, I will continue to update it for myself, and if there are sufficient users, I shall pass those updates on to them. There will be a commercial version, which will offer more features, and the ability to be able to use different types of projects (HTML/PHP, Perl, Arexx etc. are all planned), and whether that sells well remains to be seen. It's extremely unlikely that it will ever cover the costs of its development, but then how many actually create software in the Amiga market these days for financial gain? CodeBench will be a commercial program. What is the expected price of it? It is a tool for rather narrow group of users, what was the reason to make it commercial? What does "commercialization" mean in this case ? How the program will be distributed? As a program sold in internet shop through your web site or as shareware with its functions activated after registering activation key? Yes, as I explained above, the commercial version will offer a wider scope of the types of languages that can be used with it. Currently, the SDK version only allows C/C++ projects to be worked on. The functionality that is supplied can also equally be applied to other languages, and this is what the commercial version will offer. You will be able to select a PHP/HTML type project, and the editor will highlight the syntax for that language type, the project will change to allow the various filetypes to be loaded/saved/handled, and the Build button will allow the code to be pushed straight to a web browser, for example. An AmigaDOS type project will allow the running of scripts directly in a console, with a possible "step and trace" type debugger. All these things are currently under construction, but I felt it was time to give the users a chance to try out what we currently have. Once that is finalised, the commercial version will most likely be available from an online resource, at a cost yet to be established. There will be no activation system, it will be a binary upgrade system. Will developers, not related with beta-tests of AmigaOS 4.x, get new version of SDK? Obviously I am not in a postition to answer that, but see no reason why future updates to the SDK will not be available to the general Amiga user, just as they are now. Are You working on any other projects? Yes :) What do you think about whole situation related to AmigaOS 4.0 and Hyperion and Amiga Inc.? I think while AmigaOS still keeps working on my machines, I'm happy. What are those machines you are happy with that let you enjoy AmigaOS 4.x? I have a 1.2 Ghz 7447 A1-XE, MicroA1 and SAM.. Are there any chances for AmigaOS 3.X, MorphOS or AROS versions of Your programs? Currently no. The simple fact is that CodeBench relies on the very latest versions of the BOOPSI classes, some of which are not even yet publicly available. The chances of getting these ported to other Amiga-like systems is close to none, so that rules them out. In your opinion, does support for Pegasos 2 was a good move of Hyperion? Anything that widens the userbase is a good idea in my opinion. Thank you for answering all the questions and I wish you good luck with your projects.

Simon Archer (Luty 2009)

22.02.2009 18:47

Czy mógłbyś się przedstawić i krótko opowiedzieć czym się zajmujesz? Jakich Amig używasz? Czy mógłbyś opisać okoliczności, w jakich zainteresowałeś się Amigą i AmigaOS 4.0? Nazywam się Simon Archer i jestem alkoholikiem... Oj, to nie to zgromadzenie :) Amigą zajmuję się od wielu lat. Moje pierwsze doświadczenia z Amigą miały miejsce w domu mojego przyjaciela. Miał nieźle rozszerzoną A500 (było to gdzieś w 1987 roku), którą wykorzystywał do raytracingu i tworzenia animacji. Zainteresowało mnie to, zwłaszcza, że w tamtym okresie miałem C64. Nie muszę więc mówić, że niedługo później udało mi się nabyć używaną A500, a moje wydatki na Amigę zaczęły przypominać studnię bez dna. Naturalną koleją rzeczy były kolejne, nowsze modele. Po A500 przyszła m.in. A2000, a następnie A4000. Te dwie ostatnie wciąż posiadam, jak również nieźle rozbudowaną A600. Przez te wszystkie lata miałem styczność chyba z każdą wersją systemu operacyjnego i zawsze był to świadomy wybór, nawet jeśli obecnie w znaczniej części korzystam z Windows XP. AmigaOS 4.x był więc niejako dla mnie kolejnym krokiem. Obecnie działam na ostatniej dostępnej wersji, czyli AmigaOS 4.1. Jest to poniekąd część moich obowiązków jako betatestera. Czy mógłbyś w skrócie opowiedzieć czym jest CodeBench? Jest to środowiska deweloperskie (DME - Development Management Environment) tworzone z myślą o AmigaOS 4.1 i od początku projektowane tak, aby m.in. działało z AmigaOS 4 SDK. Zasadniczo oferuje funkcje kompilowania i edycji kodu z poziomu jednego interfejsu. Są oczywiście jeszcze inne elementy, o których więcej opowiem później. Dlaczego zdecydowałeś się zająć tym projektem? Dlatego, że nie ma niczego podobnego zaprojektowanego stricte pod AmigaOS 4.1. Cubic to całkiem niezły kawałek oprogramowania i z całą pewnością nie chcę zabierać klientów Dietmarowi, ale nadszedł chyba czas na natywne narzędzie działające zgodnie ze standardami systemu operacyjnego (stąd też oparte zostało całkowicie na ReAction). Co wyróżnia Twój program na tle innych, podobnych narzędzi znanych z innych platform i systemów? Jako że piszę go od samego początku, już posiada jedną zaletę - nie nosi brzemienia bycia portem. Specjalnie nie oglądałem się na inne podobne oprogramowanie, gdyż nie chciałem się na niczym wzorować, aby nie podchwytywać złych pomysłów :) CodeBench będzie pierwszym narzędziem tego typu dla AmigaOS 4.1. Z racji, że poprzednie próby stworzenia czegoś podobnego spaliły na panewce, czy nie obawiasz się, że "klątwa" spadnie również na Twój projekt? Ciekawe. Po pierwsze projekt powstał z racji zapotrzebowania na oprogramowanie tego typu. Potrzebowałem czegoś, w czym będzie się łatwo pracowało, a więc dla mnie, ten projekt nigdy nie upadnie. Po drugie, z racji tego, że istnieje ograniczona w użytkowaniu wersja dostępna na darmowej licencji, trudno jest mi sobie wyobrazić, że projekt może się nie powieść. Gdy będę programu potrzebował, nadal będę rozwijał go dla samego siebie, a jeśli będzie wystarczająca liczba użytkowników, przekażę im uaktualnienia. Program dostępny będzie również w postaci komercyjnej, która będzie oferować znacznie więcej, jak na przykład obsługę różnych języków (w planach jest obsługa dla HTML/PHP, Perl, Arexx i innych). Czas pokaże jak będzie wyglądać sprzedaż. Raczej mało prawdopodobne, że pokryje to koszty rozwoju programu, lecz kto w dzisiejszych czasach pisze oprogramowanie dla Amigi w celach zarobkowych? Jak wspomniałeś, CodeBench będzie programem komercyjnym. Jaka jest przewidywana cena? Jest to narzędzie dla raczej ograniczonej liczby odbiorców, więc dlaczego zdecydowałeś się na takie rozwiązanie? Co w tym przypadku oznacza "komercjalizacja"? No i wreszcie, jak zamierzasz program sprzedawać: przez internetowy sklepik na Twojej stronie internetowej, czy też w formie "shareware" z aktywacją niedostępnych funkcji po rejestracji pliku klucza? Wersja komercyjna będzie oferować więcej możliwości, w tym więcej języków, które będzie obsługiwała. Obecnie, wersja obsługująca SDK radzi sobie tylko z C/C++. Program jest w takim stadium, że dostępne już funkcjonalności mogą być bez problemów zaadaptowane na potrzeby innych języków, co właśnie się stanie w wersji komercyjnej. Będzie możliwość przełączenia się na przykład na PHP/HTML, a edytor rozpozna język i składnia będzie odpowiednio podświetlana. Ekran projektu zmieni się pod kątem wczytywania, zapisywania i obsługi różnych typów plików, a przycisk "Build" pozwoli przenieść kod bezpośrednio do przeglądarki. Z innej beczki, tworzone skrypty AmigaDOS będzie można od razu uruchamiać w oknie konsoli z dodatkową możliwością śledzenia krok po kroku jego działania (coś na wzór debuggera). Te funkcje na tę chwilę są jeszcze w budowie, lecz wydawało mi się, że to co już jest dostępne należało przekazać użytkownikom do testów. Gdy zakończę już prace, wersja komercyjna najprawdopodobniej będzie dostępna do kupienia ze strony internetowej. Nie zastanawiałem się jeszcze nad ceną. Nie będzie żadnego systemu aktywacji ani kluczy, a uaktualnienia dostępne będą w formie nowych binarek. Czy deweloperzy niezwiązani z betatestami systemu AmigaOS 4.x, otrzymają nową wersję SDK? Nie do mnie to pytanie należy kierować, lecz nie widzę powodów, aby przyszłe uaktualnienia SDK miały nie być dostępne dla szerszego grona (tak jak to jest obecnie). Pracujesz nad jakimiś innymi projektami? Tak :) Co sądzisz o całej sytuacji związanej z AmigaOS 4.x, Hyperion-Entertainment i Amiga Inc.? Jeżeli AmigaOS nadal działa na moich komputerach, to jestem szczęśliwy. A jakie komputery z działającym AmigaOS 4.x posiadasz? Posiadam A1-XE 7447 1.2 GHz, MicroA1 i SAM. Czy istnieją jakieś szanse na wersje Twoich programów dla AmigaOS 3.x, MorphOS-a lub AROS-a? Obecnie nie. Z prostego powodu - CodeBench opiera się na najnowszej wersji klas BOOPSI, z czego niektóre nie są jeszcze publicznie dostępne, a szanse na ich przeportowanie na inne systemy amigowe i amigopochodne są bliskie zeru. Twoim zdaniem, czy port AmigaOS 4.1 dla Pegasosa 2 był dobrym ruchem? Moim zdaniem, wszystko co powiększa grupę użytkowników systemu jest dobrym ruchem. Dziękuję bardzo za rozmowę i życzę powodzenia w pracach nad Twoimi projektami. Tłumaczenie na podstawie oryginału - Sebastian Rosa. Korekta - Aleksander "APC74" Chyliński.