Nie zezwalam na komercyjne wykorzystanie niniejszej recenzji, jej fragmentów, ani danych jej autora.
Analiza/recenzja szkolenia "Bezpieczeństwo Aplikacji Windows" (dalej: BAW) powstała z uwagi na dyskusję na forum portalu UW-Team.org (vide http://www.uw-team.org/forum/viewtopic.php?f=33&t=9577). Tematem przewodnim dyskusji było zapytanie o 'ogólne zdanie nt. kursu "Szkoła Hakerów"', m.in. w kontekscie promocji nowego kursu ("Bezpieczeństwo Aplikacji Windows"). Dyskusja była dość jednostronna, a przynajmniej do czasu aż nie dołączyła do niej "The Watcher" (pani Ewa Kawecka, BOK CSH), oraz dwie inne osoby nie związane bezpośrednio z CSH, ale pełniące funkcję moderatorów/adminów na forum HACK.EDU.PL (jest to zamknięte forum do którego dostęp mają klienci CSH).
Ponieważ dyskusja nie dążyła w żadnym ciekawym kierunku, głównie z uwagi na brak danych lub opinie oparte na przejrzeniu oryginalnego kursu (wydanego w 2006 roku, czyli 5 lat temu), wyszedłem z propozycją stworzenia recenzji (a raczej analizy od strony merytorycznej) najnowszego szkolenia CSH:
Przyznaję, że ja poruszonego w topicu kursu nie widziałem na oczy (więc go nie komentuje), ale tematyka jest mi dość bliska - w związku z czym mam małą propozycję: Mogę uczciwie i bezstronniczo zrecenzować kurs/szkolenie o którym mowa ("Bezpieczeństwo Aplikacji Windows 7, Vista, XP"), a recenzję opublikować na niniejszym forum + na moim blogu. Sądzę, że moje kompetencje są do tego wystarczające - mam zarówno doświadczenie w security Windowsa, w tworzeniu materiałów szkoleniowych, jak i kilka lat doświadczenia w branży jako pentester/bughunter/reverse eng/sec. eng. Jeśli kurs jest dobry, to będzie to dla Państwa reklama (a ja będę miał co polecać początkującym).
Jeśli zgadza się Pani / Państwo na powyższą propozycję, to prosiłbym o mejla oraz paczkę ze szkoleniem do recenzji (taką jak dostaje osoba, która kupi wspomniane szkolenie od Państwa).
Kontakt do mnie, jak i więcej informacji o mojej osobie, znajduje się na moim blogu: click.
fragment postu by Gynvael Coldwind na forum UW-Team.org
Pani Ewa przekazała moją propozycję dalej i dość szybko otrzymałem e-mail od pana Bartosza, który (po wymianie dwóch mejli) na moją propozycję przystał.
Chciałbym w tym miejscu zauważyć, że cała korespondencja (wymieniliśmy około 30 mejli) z ekipą CSH przebiegała w miłej atmosferze.
[Niniejsza sekcja jest bardzo subiektywna.]
Podejmując się tej recenzji znalazłem się w dość interesującej sytuacji.
Z jednej strony mamy Wydawnictwo CSH, które kojarzy mi się z (dyplomatycznie rzecz ujmując) kontrowersyjną kampanią reklamową typu "nie ważne co mówią, byle by mówili", i której to kampani w żadnym wypadku nie popieram (szczerzę przyznaję, że wg mnie hasła typu "Jak Zostać Hakerem w 1 Lub 2 Noce, Nie Posiadając Doświadczenia?" mogą wytwarzyć w czytelniku bardzo mylny obraz sytuacji). (Dla pełnego obrazu należy jednak zaznaczyć, że Wydawnictwo CSH posiada również stronę z informacjami o tym samym produkcie, którą czyta się o niebo lepiej.)
Z drugiej jednak strony, rozumiem, że trzeba rozgraniczyć marketing od faktycznego produktu (tym bardziej jeśli wspomniany marketing nie dotyczy produktu którego recenzji się podjąłem), oraz, że produkt (szkolenie) powinien obronić się sam.
W związku z powyższym:
1. Proszę pamiętać, że recenzja ta nie została zamówiona przez Wydawnictwo CSH i nie dla CSH jest wykonywana - tworzę ją z myślą o community (patrz Background wyżej). Natomiast, Wydawnictwu CSH należy się uznanie za przyjęcie mojej propozycji (i wkroczenie na polę bitwy) wiedząc, że będzie to dokładna recenzja części merytorycznej, oraz więdząc, że nie będa mogli użyć jej w swoich materiałach promocyjnych (dotyczył tego jeden z wymienionych mejli).
2. Proszę pamiętać, że jest to tylko i wyłącznie recenzja BAW, a nie innych produktów Wydawnictwa CSH.
3. Do recenzji starałem się podejść z pełnym profesjonalizmem, obiektywnie oraz neutralnie.
4. Proszę pamiętać, że mimo moich najlepszych chęci, ta recenzja i tak jest w pewnym stopniu subiektywna. Oznaczyłem miejsce w których nawet wg mnie jest zbyt subiektywna.
Zagrajmy w otwarte karty, czyli "czy znam autorów"?
Piotr Planeta (podręcznik) - Autor nie jest mi znany. Również, nie udało mi się znaleźć o nim żadnych informacji via wyszukiwarka (co sugeruje pseudonim lub brak publikacji).
Michał Kowalczyk (prezentacja video) - Redford'a (wymieniam z nicka, ponieważ nick i tak występuje na każdej dołączonej płycie przynajmniej w 81 różnych plikach, jak i w samych video, łącznie z udostępnionym przez CSH na YT darmowym fragmentem) natomiast znam osobiście (ale niezbyt dobrze) - proszę więc wziąć pod uwagę, że mogę być trochę bardziej subiektywny w tym wypadku (natomiast będę się starał nie być).
Pozostałych osób z redakcji nie znam.
(W powyższej wyliczance celowo pominąłem Bogdan Drozdowskiego ponieważ jego kursu (który stanowi Dodatek 2 do podręcznika BAW) nie recenzowałem, gdyż każdy może obejrzeć go na necie.)
Jak widać poniżej, mimo, że do recenzji potrzebowałem tylko BAW, redakcja CSH położyła na szali (tj. przesłała mi) cały swój pack (wartość rynkowa: 685 PLN, wg. cen ze strony Wydawnictwa CSH).
Na drugiej szali położyłem około 30 godzin swojego czasu.
Czyli w kilku punktach postaram się wyjaśnić czym BAW jest, a czym nie jest - tak, jak ja to widzę. Ułatwi to ustawienie sobie skali oceniania / oczekiwań przed czytaniem dalszej części rezencji.
Tak więc chyba bardziej adekwatnym tytułem byłoby "Exploitacja BO na Windows". Warto się zastanowić w tym miejscu, czy to dobrze/źle, że szkolenie ogranicza się do BO (pod Windows XP/Vista/7).
Z jednej strony, niewątpliwie zawężenie tematu pozwala na jego dokładniejsze omówienie i drobne dygresje (np. dzięki temu poświęcono miejsce na omówienie DEP/ASLR/SafeSEH/SEHOP/etc oraz dokładnie (choć bez bardziej zaawansowanych tricków) zaprezentowano ret2libc aka ROP).
Z drugiej jednak strony brakuje mi choćby napomknięcia o problematyce vuln disclosure (np. full-disclosure vs coordinated disclosure, vulnerability reward programs, czy o tzw. vulnerability brokerach), szukania luk, czy też wymienienia innych klas błędów które występują w aplikacjach (typu race condition, popularne ostatnio use-after-free, wymierające format stringi, interger overflowy i ich konsekwencje, etc), czy o tym, że w kernelu też są błędy (tak, żeby czytelnik/widz miał szerszy pogląd na sprawę).
Jeszcze jedna uwaga odnośnie kodu prezentowanego/tworzonego podczas szkolenia: ponieważ BAW nie jest szkoleniem o programowaniu, to nie zwracałem przesadnej uwagi na poprawność, budowę, czy estetykę kodu (a prawdę mówiąc pod tym względem listingi są dość słabe). Od tej zasady jest jednak jeden wyjątek: ponieważ jestem przeciwnikiem dodawania różnych getchar() czy innych system("pause") na końcu wykonania programu ("żeby konsola się nie zamykała"), to takie wstawski będę uznawał za błąd. Jestem zdania, że aplikacje konsolowe są tworzone z myślą o konsoli, oraz że początkujące osoby powinny być uczone korzystania z konsoli, a nie wykształcających złe nawyki "hacków" we wcześniej wymienionym stylu.
Moim zdaniem interpretacja wysokości ceny (czy też stosunku ceny do jakości) jest kwestią indywidualną każdego czytelnika, więc nie planuje wypowiadać się na ten temat.
Ogólnie video tutoriale są poprawne i nie miałem do nich za wiele uwag. Tempo jest dostosowane do osób początkujących (przez co pozwoliłem sobie fragmenty kilku modułów pominąć, co jest odnotowane w tabeli). Płyty zadziałały bez problemu w moim napędzie i były odpowiednio zabezpieczone do transportu.
Jedna rzecz mnie trochę niepokoi - w module nr. 7 (Trening praktycznej exploitacji na przykładzie Wireshark) przedstawiony jest pewien schemat: 1. idź na exploit-db; 2. ściągnij exploit; 3. przerób na bind-shella - jeśli zestawić to z brakiem przedstawienia szerszego spojrzenia na sprawę szukania błędów / ich exploitacji, to wychodzi dość niepokojąca mieszanka (tj. zastanawiam się, jaki obraz "świata" będzie miała po tym osoba początkująca).
Pozytywną cechą są występujące w niektórych modułach odnośniki do zew. materiałów/artykułów/etc.
Błędy w video tutorialach postanowiłem traktować łagodniej (tj. mniej się czepiać) niż błędy w podręczniku, ponieważ dużo trudniej jest coś poprawić po nagraniu audio+video, niż w edytorze tekstu. Również, kontekstu jest trochę więcej (obraz, video vs tekst + ew ilustracje od czasu do czasu), więc i łatwiej czytelnikowi się zorientować, że coś jest nie tak.
Z poniższej tabeli wyłączone są: przejęzyczenia, drobne uproszczenia, drobne błędy które osobiście bym uznał za "czepianie się", etc.
Proszę również pamiętać, że dany moduł trwa dłużej niż te 5-30 sekund których dotyczy dana uwaga / komentarz.
| duży plus | bardzo dobrze, że ta rzecz została pokazana |
| plus | dobrze, że dana rzecz została pokazana |
| brak uwag | wszystko poprawnie, brak uwag |
| drobny komentarz | wszystko poprawnie, mała uwaga |
| hmm | drobny błąd, nieścisłość lub nadmierne uproszczenie |
| błąd | dana rzecz jest niepoprawna / wprowadza w błąd widza co do stanu faktycznego |
| duży błąd | duży błąd, to powinno zostać wyłapane przez korektę |
| błąd kardynalny | videotutorial z takim błędem nie powinien zostać opublikowany (błąd, przez który użytkownik może ponieść stratę, np stracić dane, etc) |
| [subiektywne] | ten komentarz jest bardzo subiektywny |
| [zły nawyk] | ten komentarz dotyczy złego (wg mojego doświadczenia) nawyku |
| Czas (ca.) | Uwaga | Komentarz |
|---|---|---|
| Moduł 1 - Przygotowanie środowiska (ca. 17 minut) | ||
| 00:00:05 | hmm | [subiektywny] irytująca notka o prawach autorskich (vide mój rant na blogu) |
| 00:00:50 | drobny komentarz | (na ekranie hexplorer) zabrakło mi tu słowa "hexedytor" użytego do opisu tego narzędzia |
| 00:02:50 | hmm | cygwin emuluje całą linuxową konsolę - nadmierne uproszczenie |
| 00:12:00 | duży plus | duży plus za modowanie/przystosowywanie do działania plugina w hexedytorze |
| Moduł 2 - Podstawy obsługi debuggera (ca. 28 minut) | ||
| 00:00:05 | hmm | [subiektywny] irytująca notka o prawach autorskich (vide mój rant na blogu) |
| 00:11:00 | hmm | (na ekranie olly i okno Memory map) [...] lista stron pamięci [...] - na tej mapie są widoczne regiony pamięci, a nie same strony |
| 00:21:00 | drobny komentarz | [funny] zobaczmy jak wyglada w większości kompilatorów wywołanie funkcji main + losowy scroll ekranu i zero omówienia (należy zaznaczyć, że jest to trochę dokładniej omawiane w kolejnych modułach) |
| --:--:-- | plus | plus za omówienie niektórych pluginów olliego |
| Moduł 3 - Podstawy assemblera (ca. 24 minuty) | ||
| 00:00:05 | hmm | [subiektywny] irytująca notka o prawach autorskich (vide mój rant na blogu) |
| 00:04:05 | hmm | (widoczne na ekranie: mov eax, [ebx]; eax = *ebx) do eax zostanie przeniesiona wartość komórki spod ebx - pewna nieścisłość - adresowalna komórka pamięci ma jeden bajt, natomiast tutaj zostaną przeniesione cztery bajty (a więc cztery komórki) |
| 00:08:00 | hmm | [subiektywny] (o cmp) [...] jeśli [argumenty] są równe, to ustawia ZF na 1 - imo to trochę za mało o cmp; powiedzenie, że działa jak sub bez zapisu wyniku nie trwało by jakoś super dłużej |
| 00:09:30 | drobny komentarz | w tym miejscu kończy się "kurs assemblera" - nie jest to za dużo i brakuje np. omówienia stosu o którym jest dość sporo dalej; natomiast, to nie jest szkolenie o assembly, więc można na to przymknąć oko |
| 00:10:50 | hmm | [o DOS header] jest to nagłówek, który był używany w systemach 16-bitowych - nadmierne uproszczenie; np. w Windowsie 2x i 3.1 (które były 16-bitowy) używany był "NE"-header (segmented EXE header aka New Executable), a DOS header był w zasadzie stubem z redirectem (tak samo jak jest w przypadku PE); poprawnie: DOS header był używany pod DOSem |
| 00:11:10 | błąd | [o TimeDataStamp w optional header] to jest na przykład data ostatniej modyfikacji - jest to nieprawdziwe; cytat ze specyfikacji formatu PE: "indicates when the file was created" (created, a nie modified) |
| 00:15:15 | błąd | [zły nawyk] "można dodać getchar() [...] dwa razy" (ofc chodzi o zamykanie się konsoli) - podpowiedź: programy konsolowe powinno się odpalać spod konsoli - wtedy nie trzeba dawać dwóch getchar() tylko dlatego, że wcześniej się używa scanf() |
| 00:15:30 | drobny komentarz | środowisko Visual C++ posiada pewną opcję, która daje mu przewagę nad g++ jeśli chodzi o wstawki assemblerowe [...] declspec naked - owszem (tzn nie środowisko, a kompilator, ale nvm), przy czym w gcc/g++ również można identyczną funkcjonalność uzyskać, również w przypadku x86-64 (czego o Visual C++ niestety powiedzieć nie można - Inline assembly is not supported on the Itanium and x64 processors.) |
| 00:17:25 | hmm | [widoczny fragment kodu w asm na ekranie] a esp zwiększyliśmy o 4, ponieważ standardowo, dla integer, rezerwowane są 4 bajty pamięci - niestety, nie jestem wstanie znaleźć powiązania między tym zdaniem, a tym co widać na ekranie |
| Moduł 4 - Wykorzystanie prostych przepełnień stosu (ca. 45 minut) | ||
| Uwaga: nie obejrzałem całego tego modułu, a jedynie kilka losowo wybranych fragmentów o łącznej długości około 20 minut | ||
| --:--:-- | hmm | ad tytuł modułu: Wykorzystanie prostych przepełnień stosu - mylenie dwóch różnych klas błędów (ponieważ jest to często wystepujący błąd w polskich tłumaczeniach / etc, oznaczę to jedynie jako "błąd"); co ciekawe, w ścieżce audio używany jest poprawny termin, więc to tylko kwestia tytułu modułu |
| 00:00:05 | hmm | [subiektywny] irytująca notka o prawach autorskich (vide mój rant na blogu) |
| 00:01:00 | hmm | (o argc) mniejsze od dwóch, ponieważ aplikacja dostaje zawsze jeden argument, którym jest ścieżka do niej samej - nadmierne uproszczenie; w argv[0] jest "komenda" za pomocą której aplikacja została wywołana ("By convention, argv[0] is the command with which the program is invoked"), nie można jednak zakładać, że jest to ścieżka do aplikacji (np. pełna ścieżka trafia do argv[0] jeśli aplikacja jest odpalona z Explorera, ale jeśli jest odpalona z konsoli, to do argv[0] trafi dokładnie to co zostało wpisane w konsoli, a co pozwoliło wskazać na daną aplikację) |
| 00:02:20 | hmm | (o BO via strcpy w przypadku gdy bufor jest char[16]) [...] więcej niż 16 znaków i wtedy nadpiszemy dalszą część stosu - jest to oczywiście prawdziwe, ale brakuje mi tam wspomnienia, że samo nadpisanie dalszej części stosu pojawia się już przy "więcej niż 15 znakach" (np. dla 16 kopiowanych znaków do bufora trafi 17 bajtów, czyli znaki i terminator ) |
| Moduł 5 - Wykorzystanie prostych przepełnień sterty (ca. 1h) | ||
| Uwaga: nie obejrzałem całego tego modułu, a jedynie kilka losowo wybranych fragmentów o łącznej długości około 15 minut | ||
| --:--:-- | hmm | ad tytuł modułu: Wykorzystanie prostych przepełnień sterty - identyczny błąd jak z "przepełnieniem stosu" (patrz moduł wyżej) - oczywiście chodzi o "przepełnienie buforu na stercie" - dla jasności, nie jestem pewien czy można sterte przepełnić, natomiast niewątpliwie można ją wyczerpać, a to (+ nie sprawdzenie co zwracają funkcje alokujące typu malloc/etc) prowadzi jednak do innych klas błędów; wygląda na to, że błąd również dotyczy tylko i wyłącznie tytułu modułu |
| 00:00:05 | hmm | [subiektywny] irytująca notka o prawach autorskich (vide mój rant na blogu) |
| Moduł 6.01 - Architektura 64-bitowa - różnice (ca. 18 minut) | ||
| 00:00:05 | hmm | [subiektywny] irytująca notka o prawach autorskich (vide mój rant na blogu) |
| 00:09:30 | hmm | (o przestrzeni adresowej procesu) [...] usermode miały dostępne adresy od 0 do 7fffffff; natomiast dla trybu jądra mieliśmy adresy 80000000 do ffffffff - uproszczenie (tj. nie zawsze jest to prawda) - pod Windowsami (dla aplikacji które są "large address aware") można to kontrolować (tj. na XP zmienić granicę z 80000000 na C0000000, a pod nowszymi ją kontrolować bardziej płynnie); również, nie jest to zasada na x86-32, że pamięć jest tak dzielona, np. na *nixach jest inaczej (ale na to można przymknąć oko - w końcu to książka o Windowsach) |
| --:--:-- | drobny komentarz | moduł OK, natomiast kilka różnic nie zostało poruszonych (natomiast chyba wszystkie istotne zostały) |
| Moduł 6.02 - Zabezpieczenia chroniące stos (ca. 19 minut) | ||
| 00:00:05 | hmm | [subiektywny] irytująca notka o prawach autorskich (vide mój rant na blogu) |
| --:--:-- | brak uwag | |
| Moduł 6.03 - Zabezpieczenia chroniące stertę (ca. 8 minut) | ||
| 00:00:05 | hmm | [subiektywny] irytująca notka o prawach autorskich (vide mój rant na blogu) |
| --:--:-- | plus | plus za odnośnik do czegoś nowszego o exploitacji heap BO |
| Moduł 6.04 - Mechanizmy DEP i ASLR - omówienie (ca. 10 minut) | ||
| 00:00:05 | hmm | [subiektywny] irytująca notka o prawach autorskich (vide mój rant na blogu) |
| --:--:-- | plus | plus za odnośnik do materiałów o JIT (trochę szkoda, że nie było to omówione) |
| Moduł 6.05 - Omijanie SafeSEH i ASLR w praktyce (ca. 24 minuty) | ||
| 00:00:05 | hmm | [subiektywny] irytująca notka o prawach autorskich (vide mój rant na blogu) |
| --:--:-- | drobny komentarz | dla informacji: ominięcie via znalezienie liba który tych opcji nie ma; shellcode wygenerowany metasploit |
| Moduł 6.06 - Omijanie DEP i ASLR przy użyciu ROP (ca. 22 minuty) | ||
| --:--:-- | hmm | tytuł, w szczególności Omijanie [...] ASLR przy użyciu ROP trochę wprowadza w błąd - ASLR nie omija się przy użyciu ROP; w zasadzie ASLR jest jednym z mechanizmów który utrudnia exploitacja korzystając z ROP (dodam, że ponownie chodzi o znalezienie liba który nie ma "włączonego ASLR") |
| 00:00:05 | hmm | [subiektywny] irytująca notka o prawach autorskich (vide mój rant na blogu) |
| Moduł 6.07 - Wykorzystanie ROP w praktyce (ca. 1h) | ||
| 00:00:05 | hmm | [subiektywny] irytująca notka o prawach autorskich (vide mój rant na blogu) |
| --:--:-- | duży plus | dobry moduł, bardzo dobrze, że się pojawiło coś ciekawszego w tym kursie; natomiast prezentowane podejście jest trochę masohistyczne (ręczne składanie exploita / chaina retów w hexedytorze, ręczne szukanie kawałków kodu) - ale przynajmniej widać co się skąd bierze |
| Moduł 7 - Trening praktycznej exploitacji na przykładzie Wiresharka (ca. 54 minuty) | ||
| 00:00:05 | hmm | [subiektywny] irytująca notka o prawach autorskich (vide mój rant na blogu) |
| 00:03:30 | błąd | (o LE vs BE) np procesory PowerPC - czyli komputery firmy Apple - cóż, Apple odeszło od PowerPC ponad 5 lat temu, warto więc aby w kursie wydanym pod koniec roku 2011 była trochę bardziej aktualna informacja |
| --:--:-- | drobny komentarz | [funny] w pewnym momencie w prezentacji jest kopiowane z konsoli do hexedytora dość sporo danych i potem chwile prezentujący bawi się w usuwanie znaków nowej linii, które się tam pojawiły; przyznaję, że od ręki przychodzi mi kilka szybszych sposobów na zrobienie dokładnie tego samego, np. użycie | clip lub bardziej cygwinowych sposobów |
| --:--:-- | drobny komentarz | na początku modułu jest mowa o "ciekawszym shellcode" (bind shellu) - liczyłem, że zostanie pokazane, jak taki shellcode stworzyć; niestety, "ciekawszy shellcode" ograniczył się do podania innego payloadu generatorowi z metasploit |
Ogólnie podręcznik jest poprawny (ad szczegóły - patrz niżej). Brak zastrzeżeń co do fizycznych cech książki (klejenia, papieru, druku).
Jeśli chodzi o formę, to ogólnie jest OK, natomiast mam pewne zastrzeżenia co do szczegółów (odnotowane częściowo poniżej), a w szczególności:
Poza tym, moim [subiektywnym] zdaniem w podręczniku nadużywane jest słowo "haker".
Bogata bibliografia jest niewątpliwym plusem.
| duży plus | bardzo dobrze, że dana rzecz znalazła się w książce |
| plus | dobrze, że dana rzecz znalazła się w książce |
| brak uwag | wszystko poprawnie, brak uwag |
| drobny komentarz | wszystko poprawnie, mała uwaga |
| hmm | drobny błąd, nieścisłość lub nadmierne uproszczenie |
| błąd | dana rzecz jest niepoprawna / wprowadza w błąd czytelnika co do stanu faktycznego |
| duży błąd | duży błąd, to powinno zostać wyłapane przez korektę |
| błąd kardynalny | książka z takim błędem nie powinna zostać wydrukowana (błąd, przez który użytkownik może ponieść stratę, np stracić dane, etc) |
| [subiektywne] | ten komentarz jest bardzo subiektywny |
Z poniższej tabeli wyłączone są: literówki, drobne uproszczenia, drobne błędy które osobiście bym uznał za "czepianie się", etc.
Proszę również pamiętać, że na każdej stronie jest ~30 linijek tekstu, i to, że ja uznałem daną linijkę na danej stronie za błędną, nie oznacza, że cała strona jest błędna.
| Strona | Uwaga | Komentarz |
|---|---|---|
| 7 | spis treści | |
| 8 | spis treści | |
| 9 | spis treści | |
| 10 | pusta strona | |
| Rozdział: Wskazówki prawne | ||
| 11 | duży plus | Duży plus za umieszczenie wskazówek prawnych. |
| 12 | duży plus | Duży plus za umieszczenie wskazówek prawnych. |
| 13 | duży plus | Duży plus za umieszczenie wskazówek prawnych. |
| 14 | duży plus | Duży plus za umieszczenie wskazówek prawnych. |
| Rozdział: Wstęp | ||
| 15 | brak uwag | |
| 16 | brak uwag | |
| 17 | hmm | [...] natomiast kod powłoki [...] przygotowano za pomocą programu Turbo Asembler w wersji 5.0 firmy Borland - dziwny wybór narzędzia, szczególnie, że od roku 2002 jest nierozwijane i może być trudno dostępne |
| 18 | pusta strona | |
| Rozdział: Informacje wstępne | ||
| 19 | plus | W celu pogłębienia wiedzy na tematy przedstawione w tej książce, poleca się czytelnikowi zaznajomić z pozycjami wymienionymi w bibliografii. |
| 20 | hmm | [subiektywne] kod powłoki - brakuje angielskiego "shellcode" + uparta polonizacja terminu |
| 21 | błąd | Procesory IA-32 posiadają kilka trybów pracy, które określają między innymi sposób zarządzania pamięcią i uprawnienia użytkownika. - tryb pracy procesora nie ma nic wspólnego z uprawnieniami użytkownika - uprawnieniami użytkownika zajmuje się system operacyjny; również, nawet "root"/"SYSTEM" nie działają w ring0; przy czym, być może zdanie źle zrozumiałem / jest źle napisane, i chodzi o fakt, że dowolny kod w real mode posiada większe uprawnienia niż kod w protected mode ring-3 (w kontekscie Windowsa) |
| 21 | hmm | Tryb chroniony [...] umożliwia dostęp do całej pamięci zainstalowanej w komputerze (do 4GB) - nadmierne uproszczenie, szczególnie, że PSE-36 i PAE (o którym jest wspomniane w dalszej części książki) umożliwiają dostęp do max 64GB pamięci |
| 22 | błąd | EIP - rejestr, który zawiera adres aktualnie wykonywanego rozkazu - błąd, EIP zawiera adres następnego rozkazu do wykonania, co jest explicit napisane m.in. w manualach Intela |
| 23 | brak uwag | |
| 24 | brak uwag | |
| 25 | brak uwag | |
| 26 | błąd | w jednej instrukcji może wystąpić do czterech prefiksów - prefixów może być spokojnie więcej (afair tylko Native Client sprawdza czy nie ma nadmiarowych); zapewne autorowi chodziło o to, że zazwyczaj nie ma po co dawać więcej prefixów niż 1 z danej danej grupy prefixów |
| 27 | błąd | ModR/M Jest to opcjonalny bajt [...] - ModR/M nie jest opcjonalny, tj nie można sobie wybrać czy ma być czy nie ma go być - jest co najwyżej "nie wystepujący w przypadku każdej instrukcji", tj. opcode'y się dzielą na te w których ModR/M jest obligatoryjny, albo w których go nie w ogóle nie ma |
| 27 | błąd | Pole stałych (ang. immediate data) Opcjonalne pole [...] - jak wyżej |
| 28 | brak uwag | |
| Rozdział: Podatności i ich wykorzystywanie | ||
| 29 | brak uwag | |
| 30 | błąd | przepełnienie stosu (przepełnienie bufora, którego pamięć została przydzielona na stosie) - mylenie dwóch różnych klas błędów (ponieważ jest to często wystepujący błąd w polskich tłumaczeniach / etc, oznaczę to jedynie jako "błąd"); dodam, że ten termin jest niepoprawnie używany w kilku innych miejscach, ale nie będę ich odnotowywał |
| 30 | duży błąd | Maksymalna wielkość stosu jest zazwyczaj stała w czasie wykonania programu i jest także ustalana w czasie kompilacji. Oczywiście cecha ta jest bardzo istotna z punktu widzenia atakującego, ponieważ biorąc pod uwagę typową sytuację, rozmiar stosu nie może się zwiększyć, przez co można doprowadzić do jego przepełnienia. W celu dokładniejszego zilustrowania działania stosu posłużymy się przykładem prostej aplikacji napisanej w języku C. [i dalej typowy przykład na przepełnienie bufora na stosie] - to powinno zostać wyłapane przez korektę - w zaznaczonych miejscach powinno być raczej słowo "bufor" niż "stos"; w obecnym statnie to zdanie + przykład nie mają sensu / są błędne, a jest to kluczowe miejsce w tekście |
| 31 | hmm | [forma] listing bez numeracji linii, a w tekscie np. to w linijce 17-tej czy linia 6; jeśli w tekście jest odwołanie do konkretnej linii, to linie powinny być albo ponumerowane, albo specjalnie oznaczone; brakuje również wcięć w kodzie; brak również konsekwencji w nazwenictwie (nazwy zmiennych po polsku, nazwy funkcji po angielsku) |
| 32 | hmm | [forma] dwa listingi wygenerowane w IDA Pro, ale brak informacji, że to IDA Pro |
| 33 | drobny komentarz | [forma] diagram mógł by być trochę bardziej czytalne (i mieć większe DPI) |
| 34 | hmm | [forma] listing/screen z OllyDbg, ale brak informacji, że to OllyDbg |
| 35 | brak uwag | |
| 36 | brak uwag | |
| 37 | błąd | [forma] listing/screen z WinDbg, ale brak informacji, że to WinDbg; dodatkowo odniesienia do tego nieokreślonego narzędzia w tekscie: Do wyszukiwania instrukcji użyto polecenia "s" [...]. Komenda "u" powoduje [...]. |
| 38 | drobny komentarz | w końcu pojawiło się (ang. shellcode) :) |
| 38 | hmm | [...] z uprawnieniami administratora (ang. root) - skąd tu "root"? "administrator" po angielsku to oczywiście "administrator"; również, pod Windowsem (o którym jest przecież ta książka) defaultowe konto z uprawnieniami administratora jest "Administrator" (przy czym to kwestia wersji językowej Windowsa), a nie "root". |
| 39 | brak uwag | |
| 40 | brak uwag | |
| 41 | brak uwag | |
| 42 | brak uwag | |
| 43 | brak uwag | |
| 44 | błąd | [zły nawyk] #include <conio.h> [...] getch(); return -1; - raczej zalecałbym po prostu użycie terminala / konsoli |
| 45 | błąd | Przepełnienia sterty - identyczny błąd jak z "przepełnieniem stosu" (patrz strona 30) - oczywiście autorowi chodziło o "przepełnienie buforu na stercie" - dla jasności, nie jestem pewien czy można sterte przepełnić, natomiast niewątpliwie można ją wyczerpać, a to (+ nie sprawdzenie co zwracają funkcje alokujące typu malloc/etc) prowadzi jednak do innych klas błędów; ten termin jest niepoprawnie używany w kilku innych miejscach, ale nie będę ich odnotowywał |
| 45 | hmm | W systemach Microsoft Windows rozmiar strony pamięci wynosi zawsze 4096 bajtów (4kB) [...] - jest to oczywiście nieprawdziwe (patrz Large-Page Support); natomiast wystarczyło by wymienić słowo "zawsze" na "zazwyczaj" i będzie OK |
| 46 | brak uwag | |
| 47 | duży plus | Duży plus za ilość odnośników do informacji o implementacji heapu |
| 47 | błąd | Sterta dynamiczna jak i sterta statyczna - nie ma czegoś takiego jak "sterta statyczna"; autorowi zapewne chodziło o "sterte domyślną" (vide Managing Heap Memory (w szczególności "The two types of heaps") |
| 48 | brak uwag | |
| 49 | brak uwag | |
| 50 | drobny komentarz | [subiektywne] ad kod z przykładowym heap-based BO - brakuje mi fflush(stdout) po printf'ach |
| 51 | hmm | opisywany jest przykład nadpisywania struktury wew. heapu via overflow na poziomie struktur w C, i nagle, bez żadnego wyjaśnienia, część kopiowanych danych wskakuje do rejestrów ECX i EAX; OK, ja wiem skąd to się tam wzieło, ale przydałby się np. kawałek kodu heap managera, który by to i początkującym wyjaśnił (jest tylko krótka notka na stronie 52, że wartości rejestrów EAX i ECX odpowiadają danym przekazanym przez łańcuch wejściowy) |
| 52 | brak uwag | |
| 53 | drobny komentarz | [subiektywne] w jednym miejscu brakuje mi angielskiego terminu, tj. nadpisanie wskaźnika pierwszej wektoryzowanej procedury obsługi wyjątków |
| 53 | duży plus | Ponownie duży plus za ilość odnośników do innych materiałów |
| 54 | brak uwag | |
| 55 | hmm | [forma] Ponownie nie podpisane używanego narzędzie (WinDbg) |
| 56 | brak uwag | |
| 57 | brak uwag | |
| 58 | pusta strona | |
| Rozdział: Zabezpieczenia systemu Windows | ||
| 59 | brak uwag | |
| 60 | brak uwag | |
| 61 | brak uwag | |
| 62 | brak uwag | |
| 63 | drobny komentarz | Ponownie listing wygenerowany IDA Pro, bez podpisu, że to IDA Pro. |
| 63 | hmm | [forma] Instrukcja xor eax, ebp dokonuje operacji sumy modulo 2, pomiędzy wartością ciasteczka i aktualną wartością wskaźnika ramki (rejestru EBP) - prawie dobrze, tylko nie "pomięcy wartością [...] i [...] wartością", a bitwise; [subiektywne] czemu upwarcie autor pisze "suma modulo 2" zamiast po prostu XOR? |
| 64 | brak uwag | |
| 65 | hmm | [...] które zostały skompilowane przez program Microsft Visual Studio (co oczywiście nie oznacza, że jest to jedyny kompilator [...] - Microsoft Visual Studio to nie kompilator, a IDE, które jest dostarczane razem z kilkoma różnymi kompilatorami, nie tylko Microsoft C/C++ Optimizing Compiler o który zapewne autorowi chodziło. |
| 66 | brak uwag | |
| 67 | hmm | [...] w kompilatorze Microsoft Visual Studio od wersji 2005. - patrz strona 65 |
| 67 | drobny komentarz | [subiektywne] Mechanizmy bezpiecznych bramek obsługi wyjątków - to jest nagłówek podsekcji; raz: s/bramek/ramek; dwa: chyba wolałbym w wpisie tresci widzieć po prostu SafeSEH i SEHOP niż ten przydługawy spolonizowany termin. |
| 67 | hmm | W języku C zdefiniowanie ramki SEH jest bardzo proste - po czym listing wykorzystujący compiler-specific extension do tego, który z całą pewnością nie wchodzi w skład języka C; więc nie, w "jęzku C" nie jest to proste, jest to proste jedynie jeśli ten "język C" kompiluje się kompilatorem z tej konkretnej rodziny kompilatorów |
| 68 | brak uwag | |
| 69 | brak uwag | |
| 70 | brak uwag | |
| 71 | hmm | [forma] Ponownie listing bez numerowania linii (i wcięć) oraz odwołania typu W wierszu numer 7 czy w Wierszu numer 8 |
| 72 | błąd | Bit nie-wykonywalności (NX) jest obecnie technologią wykorzystywaną w procesorach w celu oddzielenia przestrzeni pamięci zawierającej kod (instrukcje procesora) od pamięci zawierającej dane. - bit NX nie służy do "oddzielenia przestrzeni pamięci" (do tego służyły raczej segmenty), tylko do oznaczenia stron pamięci jako niewykonywalne (ale one nadal pozostają w tej samej przestrzeni) |
| 73 | hmm | [o segmencie we flat mode] Może on mieć rozmiar maksymalnie do 4 GB (włącznie z wszystkimi fizycznymi i wirtualnymi zasobami RAM). - przyznaję, że zaznaczonej części po prostu nie rozumiem |
| 73 | duży plus | Duży plus za wspomnienie o tym, że "NX" można było "symulować" innymi mechanizmami + podanie odnośnika |
| 73 | drobny komentarz | Procesory z obsługą sprzętowej funkcji DEP najczęściej zgłaszają wyjątek przy próbie wykonania kodu ze strony, która nie posiadała praw wykonywalności. - s/DEP/NX (procesory nie mają "sprzętowej funkcji DEP" - DEP to termin Microsoftu używany pod Windowsem); również zastanawia mnie tam słowo "najczęściej" - tj czy są przypadki w których, przy "włączonej" obsłudzę NX, w takiej sytuacji nie nastąpi #PF? |
| 74 | hmm | Konfiguracja DEP sla systemu Windows - i opis jak to zrobić w boot.ini, który jest na, wydanym w 2001, Windowsie XP, ale nia ma ani na Windows Vista (2006), ani na Window 7 (2009) - ta część jest przestarzała już w tym momencie (mamy końcówkę roku 2011 w momencie pisania) |
| 75 | hmm | [...] ret2lib zwaną też jako programowanie skierowane wyjściowo (ang. return oriented programming) - "skierowane wyjściowo"? raczej "skierowane na powroty" - w końcu chodzi o zrobienie chainingu retów, a nie "exitów". |
| 76 | duży plus | Ponownie plus za ilość odnośników do szczegółów. |
| 77 | drobny komentarz | [brak konsekwencji] ASLR, mimo że nie jest nowym pomysłem, został wprowadzony dopiero w systemach Windows Vista i Windows Server 2008 - wcześniej w tabelce było zaznaczone, że Windows XP miał ASLR dla PEB i TEB |
| 78 | hmm | Ponownie screen z OllyDbg i brak informacji, że to jest OllyDbg |
| 79 | hmm | Jak wyżej, ponownie screen z OllyDbg i brak informacji, że to jest OllyDbg |
| 80 | plus | Plus za przegląd o innych (tj. nie związanych z Windowsem) mechanizmach zwiększających bezpieczeństwo. |
| 81 | plus | Jak wyżej. |
| 82 | plus | Plus za wspomnienie jak podejść do ASLR + zestaw odnośników (chociaż szkoda, że nie jest to rozwinięte). |
| 83 | brak uwag | |
| 84 | pusta strona | |
| Rozdział: Polityka bezpieczeństwa | ||
| 85 | duży plus | Dobrze, że taki dział został załączony. |
| 85 | błąd | (zasady dla programistów) starać się nie używać zmiennych środowiskowych - pod *nixami ma to sens (SUIDowalne programy, etc), ale pod Windowsem? |
| 86 | drobny komentarz | używać narzędzi [...] takich jak Valgrind - w książce o Windowsie spodziewałbym się raczej wymienienia jakiegoś natywnego narzędzia pod Windowsa (a nie Valgrinda, który natywnie pod Windowsem nie działa) |
| 87 | brak uwag | |
| 88 | hmm | a także nieużywanie pirackiego oprogramowania - ta uwaga (w kontekscie książki o exploitowaniu vulnów w aplikacjach) jest pozbawiona sensu; aplikacja piracka różni się od aplikacji "nie-pirackiej" kawałkiem wykupionego papierka zwanego "licencją", i tyle, koniec różnic; vulnów w tej aplikacji będzie dokładnie tyle samo ile w tej samej aplikacji "nie-pirackiej"; czym innym ofc jest lub oprogramowania nieznanego pochodzenia, co ma dużo więcej sensu |
| 89 | brak uwag | |
| 90 | brak uwag | |
| 91 | brak uwag | |
| 92 | pusta strona | |
| Rozdział: Podsumowanie | ||
| 93 | brak uwag | |
| 94 | brak uwag | |
| Rozdział: Dodatek 1: Format pliku PE i analiza kodu | ||
| 95 | duży plus | Dobrze, że taki dział został załącozny. |
| 96 | hmm | Rysunek D.1 jest przetłumaczonym rysunkiem z "Microsoft Portable Executable and Object File Format Spec.", ale brak oryginalnego źródła. |
| 97 | brak uwag | |
| 98 | hmm | Sekcja importów (tabela importów). Występowanie sekcji importów (ang. imports section) jest opcjonalne, aczkolwiek rzadko zdarza się, aby poprawny plik PE nie posiadał tabeli importów. - mam wrażenie, że autor tożsamo traktuje "sekcje importów" i "tabelę importów", a są to dwie różne rzeczy; brak sekcji importów nie jest równoważny z brakiem tablicy importów (importy mogą być w innej sekcji) |
| 99 | brak uwag | |
| 100 | brak uwag | |
| 101 | brak uwag | |
| 102 | brak uwag | |
| 103 | brak uwag | |
| 104 | brak uwag | |
| 105 | brak uwag | |
| 106 | brak uwag | |
| 107 | brak uwag | |
| 108 | brak uwag | |
| 109 | brak uwag | |
| 110 | pusta strona | |
| Rozdział: Dodatek 2: Podstawowy kurs języka assembler | ||
| Przedruk kursu Bogdana Drozdowskiego. Ponieważ jest on dostępny również online, został on wyłączony z recenzji/analizy (raz, że każdy może rzucić na niego okiem sam; a dwa, że nie trzeba kupować recenzowanego szkolenia, aby mieć do niego dostęp). | ||
Poniższe podsumowanie dotyczy tylko i wyłącznie BAW (tak więc sugeruje nie rozszerzać tego podsumowania na inne produkty Wydawnictwa CSH).
Szkolenie BAW jest ogólnie poprawne pod względem technicznym i merytorycznym. Znalazłem trochę niedociągnięć, ale są to rzeczy, które można poprawić np. wydając erratę lub w kolejnym wydaniu, i które nie wpływają w znaczący sposób na wartość dydatktyczną szkolenia. Znalazłem również tylko jeden większy błąd merytoryczny, który jednak wydaje się być spowodowany prostą pomyłką (a nie brakiem wiedzy autorów).
O erracie: Dostałem informację od pana Bartosza z CSH, że zostanie sporządzona errata do szkolenia wg niniejszego tekstu (tj ofc tego, co warto wrzucać w erratę). Reakcja zdecydowanie na plus. Aktualizacja: errata została sporządzona, a w niniejszej recenzji zostało zaznaczone wszystko, co zostało przez erratę obięte (patrz również aktualizacja w sekcji Dane Techniczne oraz Podrecznik).
Subiektywnie (Biorąc pod uwagę wszystko co napisałem w "Czym BAW jest, czym BAW nie jest"): Przyznaję, że w ostatecznym rozrachunku mam pozytywne odczucia co do BAW jeśli chodzi o zawartość merytoryczną i sądzę, że może to być wartościowy dodatek do innych materiałów. W szczególności video tutoriale wydają mi się warte uwagi dla osób początkujących/etc. Natomiast jak pisałem, nie jest to szkolenie skierowane do osób zaawansowanych. Nie jest to również dzieło wybitne (za dużo niedociągnięć, zbyt mały zakres, no i osobiści mi brakowało dygresji autorów wynikających z doświadczenia). Natomiast... nikt od tego nie zgłupieje :)
Komentarze do recenzji + dyskusja: http://www.uw-team.org/forum/viewtopic.php?f=33&t=9649 (zachęcam do podyskutowania).Otrzymałem od CSH link do większej ilości materiałów marketingowych, ale odniosę się tylko do tego, co jest napisane z tyłu okadki, a wzasadzie do "bold claims" które zaznaczyłem boldem poniżej (ponieważ do reszty zacytowanego tekstu uwag nie mam).
Oddajemy w Twoje ręce kolejne, niszowe szkolenie z dziedziny IT security oraz hackingu, które tym razem traktuje o bezpieczeństwie aplikacji działających pod kontrolą systemów z rodziny Microsoft Windows. W szkoleniu znajdziesz wiele interesujących informacji na temat technik ataku na aplikacje w najnowszych odsłonach systemu firmy z Redmond i dowiesz się, jak skutecznie się przed nimi bronić. Autorzy szkolenia obnażają słabości takich mechanizmów jak SafeSEH, SEHOP, DEP, czy ASLR. Jeżeli kiedykolwiek zastanawiałeś się, co leży u podstaw masowych ataków na oprogramowanie, o których co jakiś czas głośno w mediach, tutaj znajdziesz odpowiedź i wiele cennych informacji ku przestrodze.| Autorzy szkolenia obnażają słabość... | Komentarz |
|---|---|
| SafeSEH | Cytat: Oczywiście metoda zapewnia ochronę tylko w przypadku, kiedy w pamięci adresowanej danego procesu nie znajduje się moduł (biblioteka), który nie został skonsolidowany z opcją /SAFESEH - przyznaję, że trudno mi tą uwagę uznać za "obnażenie słabości mechanizmu" (tj. ta uwaga wskazuje na potencjalną słabość w użyciu mechanizmu, ale nie w samym mechaniźmie). |
| SEHOP | Cytat: Rozwiązanie to wspólnie z mechanizmem ASLR [...] jest bardzo trudne do ominięcia. - prawie jak obnażenie słabości :) |
| DEP | ROP (które ślicznie wykazuje słabość DEP) jest ładnie omówione i zaprezentowane w video tutorialu. Jest również wspomniane coś o JIT'ach (a w zasadzie o JIT sprayingu) |
| ASLR | W podręczniku jest mniej więcej (w sumie) 3/4 strony (z pięcioma odnośnikami) o tym jak podejść do ASLR. Natomiast w video tutorialach ASLR jest po prostu omijane (tj. w pamięci jest zawsze moduł który nie ma "włączonego ASLR"). Ponownie, jest to raczej wskazanie na słabość w użyciu mechanizmu, a nie samego mechanizmu. Należy jednak odnotować, że jest również 3/4 strony poświęcone problemowi entropii w ASLR. |
Na forum serwisu UW-Team.org założyłem temat, w którym osoby zainteresowane mogły wrzucać dodatkowe pytania do kursu. Poniżej postaram się odpowiedzieć (raczej subiektywnie) na wybrane.
Q: W jakich kategoriach można rzeczywiście rozpatrywać tę książkę/zestaw: jako ściśle techniczna/specjalistyczna, lekka poradnikowa, popularnonaukowa, inne (a może bliżej jej do beletrystyki?)
A: Techniczna, dla początkujących.
Q: Czym wyróżnia się w stosunku to innych publikacji tego typu (pozytywnie lub negatywnie).
A: Trudno jest mi to z czymkolwiek porównać (tj. nie widziałem na polskim rynku innych video tutoriali na ten temat - sądzę, że można to zaliczyć na plus).
Q: Czego brakuje, czego autorzy nie napisali a powinno być lub znaleźć się w takiej publikacji?
A: O tym pisałem w części "Czym BAW jest, czym BAW nie jest".
Q: Występowanie paraboli myślowych, skakanie z tematu na temat, przedstawienie podstaw dla danego tematu?
A: Skakania / etc nie zauważyłem. Podstawy są wyjaśnione (być może możnaby to zrobić lepiej, natomiast i tak jest to zrobione poprawnie).
Q: Czy tę wiedzę można przełożyć na jakiś faktyczny efekt, czy to bardziej uświadamianie o zagrożeniu, a do czynów jeszcze daleka droga?
A: Jest to wiedza praktyczna. Natomiast jak pisałem wcześniej - BAW jest tylko o exploitacji BO, nie ma tam nic o szukaniu błędów czy o innych klasach błędów, ani też o tworzeniu uzbrojonych exploitów (jest zademonstrowane tworzenie exploitów typu PoC, tj. odpalających calc.exe).
Q: Czy podręcznik wymaga by go przewałkować od deski do deski, żeby zrozumieć o co chodzi w ostatnim rozdziale?
A: Trudno powiedzieć, ale skłoniłbym się do odpowiedzi: tak, trzeba przerobić to od deski do deski jeśli się wcześniej nie miało z tym styczności.
Q: Jak prezentowany materiał ma się do aktualnego stanu rzeczy, tzn. na ile prezentowane błędy, dziury, etc. można wykorzystać w dzisiejszych realiach?
A: O ile materiał nie dotarł do current state of art, to mimo to imho jest on aktualny (tj. jest sporo o mechanizmach z Windows 7, a jest to obecnie najnowszy Windows [celowo pomijam Windows 8, który jeszcze jest tworzony]). Natomiast jak pisałem, prezentowano tylko i wyłącznie BO (stack-based i heap-based) - ofc nie wszystkie znajdowane dziury to BO.
Q: Czy prezentowana problematyka jest ogólnie znana i wszystko można znaleźć w sieci, czy też może autorzy odkrywają przed czytelnikiem coś co nie jest szerzej znane i jest wynikiem dociekań/badań autorów?
A: Jak pisałem w "Czym BAW jest, czym BAW nie jest", zawarta wiedza jest w granicy state of art i common knowledge - więc: tak, można wszystko to znaleźć w sieci (nawet są odnośniki w BAW), ale w większości jedynie w języku angielskim (i w formie tekstu, a nie video tutoriali - inna krzywa uczenia).
Q: Jak bardzo można być początkującym, tzn. czy za ten materiał mogą wziąć się osoby zupełnie zielone czy też jednak trzeba mieć już jakieś podstawy?
A: Trzeba znać (imo) podstawy C i WinAPI. Zalecałbym również silne podstawy assembly i architektury x86.
Q: Czy książka się nie rozsypuje? Czy płyta jest dobrze zabezpieczona? Co jest w zestawie?
A: Nie mam uwag co do książki i zabezpieczenia płyt (o czym pisałem wyżej). W zestawie jest książka i dwie płyty (oraz, jak rozumiem, dostęp do supportu oraz forum klientów CSH zwane szumnie "forum polskich hakerów").
Powyżej przedstawione opinie są opiniami prywatnymi ich autora, a nie jego pracodawcy/etc.