Witam.
Przed kilkudziestoma minutami wysłałem kumplowi swój program do przetestowania. Po chwili pisze on do mnie żebym nie robił sobie jaj i nie posyłał mu wirusów. Byłem zdziwiony ponieważ mój program jest w 100% mojego autorstwa i niemożliwe żeby jakikolwiek antywir go wykrył. Tym bardziej iż sam program nie ma złych intencji. Anty wirus, który pluje się o moją aplikację to NOD 32. Mój program jest napisany 100% w assemblerze i skompilowany w MASM32. Razem z kumplem trochę poeksperymentowaliśmy i okazało się, że NOD 32 wykrywa każdy program skompilowan w MASM32 jako potencjalny nieznany wirus. Zresztą pokusiłem się nawet o dalsze eksperymenty i zmieniłem troszkę kod puttego ( parę mov itd i na końcu dałem pętlę nieskończoną ). Okazało się, że i tym razem NOD 32 pluł się o to samo. Wynika z tego, że ten AV nie toleruje programów napisanych w czystym asm albo wymaga pewnego modelu programowego dla aplikacji pod Windows. Moje pytanie jest następujące: Jak oszukać NOD 32 lub możę inaczej, jak pisać prawidłową aplikację w assemblerze tak aby NOD 32 nie uznał jej za wirus?
Oczywiście informowanie użytkownika o tym, że niektóre antywirusy mogą wykryć aplikację jako wirus odpada. Nikt jej nie odpali jak AV nagle zacznie mu pokazywać swoje komunikaty. Projekt musi być pisany w asm i raczej nie zamierzam go już przepisywać ponieważ jest już prawie skończony.
Bardzo proszę Was o pomoc.
Pozdrawiam
Ha, rozwiązałem swój problem :d Okazało się, że heurystyka NODa nie potrafi poradzić sobie z funkcją CreateThread. Starczy w sekcji kody dodać pare bajtów kodu i od razu utworzyć wątek, który znajduje się w innej sekcji razem z resztą mojego kodu a następnie skoczyć do kodu właściwego aplikacji. Rozwiązuje to mój problem bo piszę aplikację, która ma być bindowana z aplikacją wybraną przez użytkownika i po uruchomieniu zastępować niektóre jej funkcje swoimi jednak dla samodzielnych programów czysto napisanych w asm nie znalazłem dobrego rozwiązania :( NOD dalej wykrywa je jako wirusy dlatego drugą część projektu będę musiał napisać w c++ :(
Napisz do firmy ESET i opisz w paru zdaniach. Powinni sie zaintersowac.
NOD jak wykryje "nowe" wirusy przez heurystykę to pyta się czy może wysłać ten plik do analizy swoim szefom - wyślij im kilkanaście takich progsów to sie może wkurzą i napiszą aktualizację nie wykrywającą takich rzeczy ;P
Chyba spróbuję obu rozwiązań. Aczkolwiek cała ta heurystyka, o ile zdążyłem się z nią zaznajomić, to swojego rodzaju sztuczna inteligencja, a że sztuczne znaczy prawie, a prawie robi wielką różnicę to nie zawsze działa jak powinna. Z mojego punktu widzenia jest to lekka panika jednak z drugiej strony NOD tylko informuje o możliwym zagrożeniu. Programy napisane w asm są prostsze i inaczej złożone niż te pisane w językach wyższego poziomu zarówno jak wirusy, które mają być małe a zarazem funkcjonalne. Zresztą polityka wielkiej nieufności to w dzisiejszych czasach chleb powszedni więc dopóki technologia nie pójdzie jeszcze troche w górę to będziemy musieli liczyć się z podobnymi niedogodnościami. Swoją drogą wątpię jednak by twórcy NODa zrobili jakieś ulepszenie, które sprawiłoby, że nie będzie on wywoływał tylu fałszywych alarmów. Myślę, że raczej wprowadziliby sygnaturę mojego programu do bazy i byłby on jednym z wyjątków, a to także mi nie pasuje bo nie mam zamiaru wysyłać im co chwila nowej wersji ;) W każdym razie liczyłem na jakiś złoty środek, bo przecież jakaś zasada w tej całej heurystyce musi być ale takiego prostego rozwiązania jak to, którego użyłem do rozwiązania mojego problemu, się nie spodziewałem.
Wiesz, heurystyka o ile wiem dziala na takiej zasadzie, ze najpierw szuka podejrzanych ciagow instrukcji typu: odczyt danych, zapis danych, bezposredni dostep do dysku, wykorzystywanie pewnych przerwan itp. Cos co wirusy bardzo czesto robia i wykorzystuja. Poznej wchodzi statystyka i prawdopodobienstwo - obliczanie jaka jest szansa, ze przy takim zestawie podejrzanych zestawow instrukcji Twoj program to wirus. Najwyrazniej twoj niestety wpadl w zla szufladke, bo MASM32 kompilujac kod uzywa takich zestawow w naglowkach czy gdzies tam (niewiele pamietam z asemblera :P)
A inny kompilator?
pozdrawiam
johny
Z tego co pamiętam to jeszcze avast /czy jak to się tam pisze/ nie lubił exec'ow z masma i tasma... Z fasmem jest czasem jeszcze weselej - daje lepszą kontrolę nad budową pliku /co przydaje się np. przy okacji przeróżnych compo, w których liczy się rozmiar/. Niektórym antywirom wystarcza, że EP nie jest w pierwszej sekcji - może dlatego nod32 się pluje /najpierw .code a potem .data - linker powinien poskładać to według kolejności z obj/. Moja rada - ściądnąć fasma i pobawić się kolejnością sekcji. Ja tam mając arcavira nie mam żadnych problemów z nawet bardzo dziwnymi konstrukcjami.
dlaczego :
- wiekszosc wirusow powstaje w assemblerze,
- znikomy procent populacji programuje w tym jezyku (totez brak zrodel i programow w zasobach komputera),
- rzadko tworzy sie w nim programy pod windowsa (j.w.),
Dlatego program o takiej struktorze, ktory znajduje sie na komputerze przecietnego uzytkownika jest wirusem.
Nie znaczy to jednak, ze to dobra tendencja i trzeba zwalczac cos co nie jest szkodliwe dla dobra wiekszosci(ulatwiajac sobie sprawe).
jest taka opcja że wprowadzą coś takiego - w NODzie było coś takiego że wykrywało wszystkie programy spakowane UPXem jako wirusy - następna aktualizacja to unieszkodliwiła, w AVASTcie zdaje się było że wykrywało jako wirusy wszystkie projekty delphi z wykorzystaniem Indy - też aktualizacja to poprawiła więc myślę że jest szansa, tymbardziej że jest to program płatny i powinien mieć rację - co za problem napisać antywirusa który przez niby heurystyke będzie informował że każdy plik może być wirusem
Adamo napisał(a)
AVASTcie zdaje się było że wykrywało jako wirusy wszystkie projekty delphi z wykorzystaniem Indy - też aktualizacja to poprawiła
Mam BitDefender 8.0 Pro, całkiem niedawno napisałem aplikację z użyciem IdSMTP i IdMessage i jakiez było moje zdziwienie :| , kiedy AntyVir brutalnie przerwał działanie aplikacji. Wystarczyło dodać jedną linijkę kodu, która nic nie robiła i po kłopocie.
Dzięku wszystkim za odpowiedzi. Z tego co zauważyłem to nagłówek tu nie a za dużo do gadania. Raczej zawartość sekcji. Jak już wspominałem mój twór będzie działał w przestrzeni adresowej innego procesu i będzie nadawał jej dodatkowych funkcjonalności. Dlatego też chciałem dodać opcję aby dodatkowy kod mógł być przez użytkownika na stałę dodany do aplikacji. Do tego wykorzystuję dodatkową sekcję, w której odpalany jest najpierw mój kod a potem kod właściwej aplikacji - i tu owszem, AV może się przyczepić ale nigdzie później nie ma żadnych złośliwych instrukcji ani broń Boże instrukcji odpowiedzialnych za "zarażenie" jakiejkolwiek innej aplikacji.
W każdym razie po skopiowaniu sekcji .text z mojego exeka do sekcji dodatkowej w wybranym przez użytkownika exeku, program szuka w tablicy importu funkcji LoadLibrary i GerPorcAddress, ustawia je w dodanej aplikacji i ustawia RVA punktu startowego, który oczywiście jest w nowej sekcji. W tym wypadku NOD się rzuca nawet gdy zmienię w nagłówku bazę kodu na RVA nowo dodanej sekcji. Jedynym dobrym rozwiązaniem to w pierwotnej sekcji kodu dodać CreateThread i tym sposobem uruchomić mój dodatkowy kod a następnie skoczyć do właściwej aplikacji. Kiedy dodawałem CreateThread w nowo dodanej sekcji i skakalem do sekcji kodu to NOD także się rzucał. W sumie w tym wypadku mój program działa w innym i AV ma prawo się to nie podobać jednak jakież było moje zdziwienie jak skompilowałem jakikolwiek przykład z MASMa a NOD wykrywał go jako potencjalne zagrożenie.
Z mojego doświadczenia z tym AV dochodzę do wniosku, że problemem nie są nagłówki plików, podejrzane instrukcje dostępu do dysku itd. Przeglądając inne programy napisane w językach wysokiego poziomu zauważyłem, że często używają ciekawych API na wstępie. Niektóre z nich nie są nawet udokumentowane. Zapewne służy to w jakiś sposób aplikacjom wysokiego poziomu a w assemblerze jest to zupełnie zbędne, bo po to używa się tego języka aby aplikacja była jak najprostsza. Podobnie jest z wirusami. Wirus ma się uruchomić niezauważony, być jak najmniejszy i używać jak najprostszych mechanizmów. Dlatego też zapewne NOD profilaktycznie woli powiadomić użytkownika zanim odpali taki program.