hogyan készítsünk víruskereső motort

hogyan készítsünk víruskereső motort

Bevezetés

amikor a techies fórumokon barangolok, gyakran látom, hogy néhány (és sok nem túl tapasztalt) ember megkérdezi, hogy “hogyan készítsek antivírust”, néha nem túl adaptált nyelvekkel (bat, PHP,…), és rossz elképzelésük van arról, hogy mi az antivírus, és hogyan kell felépíteni.

sok gyerek által készített “vírusirtó szoftvert” is láttam, nagyon kevés még iskolás emberrel, napi 4 órás kódolással több héten keresztül. Nem mondom, hogy a gyerekek nem képzettek, de azt mondom, hogy egy víruskereső motor felépítéséhez sok képzett emberre van szükség, teljes munkaidőben, plusz sok idő, hogy kiadjon egy tisztességes szoftvert, vagy sok pénzt fizetni nekik (ha nem önkéntesek).

tehát itt ismertetem az alapvető víruskereső kódolás irányelveit, Windows és C/C++nyelven. Itt találhatók a mutatók egy víruskereső motor tervezéséhez, vagy egyszerűen megtanulják, hogyan épülnek fel a legtöbbjük.

Protection

a jó védelem érdekében a víruskeresőnek legalább egy illesztőprogrammal kell rendelkeznie, hogy képes legyen a kernelben futtatni a kódot, és összességében hozzáférjen a kernel API-jaihoz. A Vista – tól kezdve a Microsoft megértette, hogy a víruskereső iparnak kulcsokra van szüksége a kernelbe való belépéshez és a szűrők aktiválásához stratégiai helyeken, például fájlrendszerben, nyilvántartásban és hálózatban. Ne döbbenjen meg, ha egy víruskereső felépítése a Vista előtti rendszerekhez valódi fájdalom lehet, mert nem erre tervezték.

• a Vista előtti rendszereken azonban a víruskereső cégek rootkit-szerű funkciókat használtak az ajtók védelmére (még akkor is, ha a Microsoft egyáltalán nem javasolta), és képesek voltak megvédeni a rendszert. Azt használták, amit “horgoknak” hívunk (API kitérők szűrési célokra).
• Vista+ rendszeren a Microsoft API-kat biztosított az alacsony szintű illesztőprogram beillesztéséhez a userland hívások és a kernel API-k közé. Így könnyű regisztrálni egy víruskereső terméket a kernelbe. Több, ez a fajta regisztráció alapú rendszer lehetővé teszi számunkra, hogy rendszerbiztonságunkat rétegekbe küldjük, ahol több különböző célú termék együtt élhet. A horgok esetében nem ez volt a helyzet, mivel a megvalósítás teljes mértékben termékfüggő volt.

megjegyzés: Nem fogom fedezni a megoldásokat horgokkal a Vista előtti rendszerekhez, mert könnyű megtalálni az interneten, és mert egy egész fejezetre lenne szüksége, hogy elmagyarázza, hogyan kell horgolni, hol kell horgolni, és így… de tudnod kell, hogy ugyanaz az ötlet, mint a kernel API-k, azzal a különbséggel, hogy meg kell valósítanod magad, amit a Microsoft biztosított a Vista+ rendszereken.

a kódoló illesztőprogramok megismeréséhez ellenőrizze, hogy hasznos linkek:
http://msdn.microsoft.com/en-us/library/windows/hardware/gg490655.aspx
http://www.codeproject.com/Articles/9504/Driver-Development-Part-1-Introduction-to-Drivers

ahhoz, hogy megtudjuk, horgok, akkor ellenőrizze, hogy az alapvető példa:
http://www.unknowncheats.me/forum/c-and-c/59147-writing-drivers-perform-kernel-level-ssdt-hooking.html

Process

az első dolog, ami megvédi a felhasználót, a rosszindulatú folyamatok elindítása. Ez az alapvető dolog. Az antivírusnak regisztrálnia kell egy PsSetCreateProcessNotifyRoutineEx visszahívást. Ezzel minden folyamat létrehozásakor, és mielőtt a fő szál elindulna (és rosszindulatú dolgokat okozna), a víruskereső visszahívása értesítést kap, és megkapja az összes szükséges információt.

megkapja a folyamat nevét, a fájlobjektumot, a PID-t és így tovább. Mivel a folyamat függőben van, az illesztőprogram megmondhatja a szolgáltatásának, hogy elemezze a folyamat memóriáját bármi rosszindulatú miatt. Ez megalapít valamit, a vezető egyszerűen állítsa CreationStatus hamis és visszatér.

NTSTATUS PsSetCreateProcessNotifyRoutineEx( _In_ PCREATE_PROCESS_NOTIFY_ROUTINE_EX NotifyRoutine, _In_ BOOLEAN Remove);

VOID CreateProcessNotifyEx( _Inout_ PEPROCESS Process, _In_ HANDLE ProcessId, _In_opt_ PPS_CREATE_NOTIFY_INFO CreateInfo);

typedef struct _PS_CREATE_NOTIFY_INFO { SIZE_T Size; union { ULONG Flags; struct { ULONG FileOpenNameAvailable :1; ULONG Reserved :31; }; }; HANDLE ParentProcessId; CLIENT_ID CreatingThreadId; struct _FILE_OBJECT *FileObject; PCUNICODE_STRING ImageFileName; PCUNICODE_STRING CommandLine; NTSTATUS CreationStatus;} PS_CREATE_NOTIFY_INFO, *PPS_CREATE_NOTIFY_INFO;

szálak

ugyanabban az ötletben, mint a folyamatoknál, a szálak a rosszindulatú dolgok károsodásának módját jelenthetik. Például be lehet fecskendezni egy kódot egy legális folyamatba, és elindíthat egy távoli szálat ezen a kódon a folyamat kontextusában (könnyen követhető? 🙂 ). Így egy legális folyamat rosszindulatú dolgokat tehet.

új szálakat szűrhetünk a PsSetCreateThreadNotifyRoutine visszahívással. Minden alkalommal, amikor egy szál jön létre, a víruskereső értesítést kap a TID és a PID. Így képes megvizsgálni a szál kezdő címkódját, elemezni, vagy leállítani a szálat, vagy folytatni.

NTSTATUS PsSetCreateThreadNotifyRoutine( _In_ PCREATE_THREAD_NOTIFY_ROUTINE NotifyRoutine);

VOID(*PCREATE_THREAD_NOTIFY_ROUTINE) ( IN HANDLE ProcessId, IN HANDLE ThreadId, IN BOOLEAN Create );

Images

a harmadik dinamikus fenyegetés a memóriába tölthető képekről szól. A kép egy PE fájl, akár EXE, DLL vagy SYS fájl. A betöltött képekről való értesítéshez egyszerűen regisztrálja a PsSetLoadImageNotifyRoutine-t. Ez a visszahívás lehetővé teszi számunkra, hogy értesítést kapjunk, amikor a kép betöltődik a virtuális memóriába, még akkor is, ha soha nem hajtják végre. Ezután észlelhetjük, amikor egy folyamat megpróbál betölteni egy DLL-t, betölteni egy illesztőprogramot, vagy új folyamatot indítani.

a visszahívás információt kap a teljes képútvonalról (statikus elemzéshez hasznos), véleményem szerint a legfontosabb a kép alapcíme (a memóriában történő elemzéshez). Ha a kép rosszindulatú, az antivírus apró trükkökkel elkerülheti a végrehajtást, például elemezheti a memóriában lévő képet, menjen a belépési pontra, majd hívja meg az assembly opcode “ret”-et, hogy semmisítse meg.

NTSTATUS PsSetLoadImageNotifyRoutine( _In_ PLOAD_IMAGE_NOTIFY_ROUTINE NotifyRoutine);

VOID (*PLOAD_IMAGE_NOTIFY_ROUTINE)( __in_opt PUNICODE_STRING FullImageName, __in HANDLE ProcessId, __in PIMAGE_INFO ImageInfo );

typedef struct _IMAGE_INFO { union { ULONG Properties; struct { ULONG ImageAddressingMode : 8; //code addressing mode ULONG SystemModeImage : 1; //system mode image ULONG ImageMappedToAllPids : 1; //mapped in all processes ULONG Reserved : 22; }; }; PVOID ImageBase; ULONG ImageSelector; ULONG ImageSize; ULONG ImageSectionNumber;} IMAGE_INFO, *PIMAGE_INFO;

Filesystem

ha minden dinamikus dolog biztonságos, egy víruskereső képesnek kell lennie arra, hogy értesítse a felhasználót a rosszindulatú dolgokat on-the-fly, nem csak akkor, ha hamarosan indul. Az antivírusnak képesnek kell lennie a fájlok beolvasására, amikor a felhasználó megnyit egy mappát, archívumot, vagy amikor letölti a lemezre. Sőt, az antivírusnak képesnek kell lennie arra, hogy megvédje magát, megtiltva bármely programnak a fájlok törlését.

mindezt úgy tehetjük meg, hogy telepítünk egy illesztőprogramot a fájlrendszerbe, pontosabban egy régi szűrő miniszűrőjét (régi módon). Itt a minifilter-ről fogunk beszélni.

a minifilter egy speciális illesztőprogram, amely képes visszahívásokat regisztrálni a fájlrendszer minden olvasási/írási műveletére (IRP főbb funkciók). Az IRP (Interrupt Request Paquet) egy olyan objektum, amelyet a lemezen lévő olvasási/írási művelet leírására használnak, amelyet az illesztőprogram-veremmel együtt továbbítanak. A minifilter egyszerűen beillesztésre kerül ebbe a verembe, és megkapja az IRP-t, hogy eldöntse, mit kezdjen vele (allow/deny művelet).

a minifilter egy kis példájához kérjük, ellenőrizze azt a hasznos linket vagy azt. A microsoft irányelvei itt találhatók.

2 példát is talál a WDK dokumentációjából itt és itt.

egy alapvető minifilter visszahívás így néz ki. Vannak 2 féle visszahívás, Pre operation és Post operation, amelyek képesek szűrni előtt a lekérdezés után. Itt van egy preoperációs álkód:

FLT_PREOP_CALLBACK_STATUS PreOperationCallback (__inout PFLT_CALLBACK_DATA Data, __in PCFLT_RELATED_OBJECTS FltObjects, __deref_out_opt PVOID *CompletionContext){ ... if ( all_good ) { return FLT_PREOP_SUCCESS_NO_CALLBACK; } else { // Access denied Data->IoStatus.Information = 0; Data->IoStatus.Status = STATUS_ACCESS_DENIED; return FLT_PREOP_COMPLETE; } }

Registry

a registry az egyik legkritikusabb hely, hogy őr. Vannak sok sok ways részére egy malware-hoz eltartás állandó kezét a rendszer regisztrálásával egy (vagy néhány) kulcsok/értékek a rendszerleíró adatbázisban. A legismertebb helyek a Futókulcsok és a szolgáltatások. Ez az a hely is, ahol az antivírus legyőzhető (a fájlrendszerrel együtt), egyszerűen eltávolítva az illesztőprogram/szervizkulcsokat, így a rendszer indításakor már nem indul újra.

ez nem egy igazi szükség egy antivírus őr újraindítás helyeken, a legtöbbjük nem. de meg kell őrizniük a telepítés rendszerleíró kulcsokat, hogy elkerüljék, hogy legyőzte könnyen malwares. Ezt a CmRegisterCallback regisztrálásával lehet megtenni.

a visszahívás elegendő információt ad a kulcs teljes nevéhez, a hozzáférés fajtájához (Létrehozás, átnevezés, törlés, … ) és a hívó PID-jéhez. Így könnyű hozzáférést biztosítani a híváshoz, vagy sem, a művelet utáni visszahívás Állapotmezőjének beállításával.

NTSTATUS CmRegisterCallbackEx(_In_ PEX_CALLBACK_FUNCTION Function,_In_ PCUNICODE_STRING Altitude,_In_ PVOID Driver,_In_opt_ PVOID Context,_Out_ PLARGE_INTEGER Cookie,_Reserved_ PVOID Reserved);

EX_CALLBACK_FUNCTION RegistryCallback;NTSTATUS RegistryCallback( _In_ PVOID CallbackContext, _In_opt_ PVOID Argument1, _In_opt_ PVOID Argument2){ ... }Argument1 = typedef enum _REG_NOTIFY_CLASS { RegNtDeleteKey, RegNtPreDeleteKey = RegNtDeleteKey,...Argument2 = typedef struct _REG_POST_OPERATION_INFORMATION { PVOID Object; NTSTATUS Status; PVOID PreInformation; NTSTATUS ReturnStatus; PVOID CallContext; PVOID ObjectContext; PVOID Reserved;} REG_POST_OPERATION_INFORMATION, *PREG_POST_OPERATION_INFORMATION;

hálózat (tűzfal)

a teljes internetes forgalom kapujának védelme érdekében, amely bizonyos rendszereken (szerverek, hatalmas sávszélességű felhasználók) hatalmas lehet, anélkül, hogy a userlandben zajló kontextusváltás lelassítaná, egyáltalán nem ajánlott olyan tűzfalat telepíteni, amelynek nincs mögöttes illesztőprogramja, kivéve néhány webböngésző szűrőt, amely elegendő lehet A http forgalomhoz, de nem véd a rosszindulatú programok kommunikációjától.

a tűzfal helyes megvalósításához NDIS, TDI vagy más módszert kell kódolni az alacsony szintű IP-szűrő illesztőprogramhoz. Az NDIS / TDI egy kicsit trükkös, és sok tudást igényel (véleményem szerint több, mint más szűrők).

mindenesetre itt van néhány mutató az ilyen illesztőprogramok kódolásának megkezdéséhez, a microsoft irányelvei és a régi codeproject oktatóanyag (de még mindig jó olvasni), egy példa az NDIS tűzfalra, és egy példa a TDI tűzfalra. Itt van még egy jó írás az NDIS tűzfal megkerülő trükkjéről, és egy kis magyarázat a hálózati illesztőprogram-veremről,

Userland védelem

a userland védelem nem szükségszerű, de kiegészítő modul lehet A trójai bankárok, pontosabban a folyamat kémek ellen. Általában minden folyamatba befecskendezik őket, több okból is.

először is képesek (igény szerint) megölni a folyamatot, ha azt rosszindulatú programként azonosították (ez nem történhet meg, mert az AV-K állítólag leállítják, mielőtt elindulna). Mindig könnyebb megállítani egy folyamatot, amikor a kontextusába kerül.

másodszor képesek megvédeni a kritikus folyamatokat, mint például a webböngészők, az olyan rosszindulatú szoftverek ellen, amelyek képesek kitérni és szűrni az API-hívásokat, hogy jelszavakat, banki információkat gyűjtsenek, és átirányítsák az internetes áramlást a rosszindulatú szerverekre. Ők csak nézni az IAT módosítás, a splicing, és azt is meg horgok magukat, hogy elkerüljék LoadLibray egy malware DLL, és így tiltják bizonyos módszerek kód injekció.

a protector DLL minden folyamatba történő befecskendezésének egyszerű módja az AppInitDll rendszerleíró kulcs használata a protector DLL regisztrálásához. Betölti a DLL – t a rendszeren elindított minden folyamatba, amint összekapcsolják a Felhasználót32.dll kép (legtöbbjük nem).

Analysis Engine

az analysis engine az egyik legfontosabb része, ez felelős elemzése fájl/memória minták érkező vezetők. Az If-nek gyorsnak kell lennie (még egy hatalmas adatbázissal is), és képesnek kell lennie a legtöbb fájltípus kezelésére (Self-extrahed executables, Archives-RAR, ZIP, Packed files – UPX,…), ezért sok modullal kell rendelkeznie ehhez:

• Unpacker: ennek a modulnak képesnek kell lennie a legtöbb ismert csomagoló (UPX, Armadillo, ASPack,…) felismerésére és kicsomagolására
• Signature engine: az antivírus adatbázisa több millió aláírást tartalmaz, és a motornak képesnek kell lennie arra, hogy gyorsan megkeresse őket egy mintában. Így egy nagyon erős algoritmusnak része kell lennie. Néhány példa : Ahorasick, RabinKarp, karakterlánc-illesztési algoritmusok.
• Sandbox : ez a modul nem szükséges, de plusz lenne ahhoz, hogy a mintákat korlátozott memóriába futtassa, a rendszerre gyakorolt hatás nélkül. Ez segíthet az ismeretlen csomagolókkal csomagolt minták kicsomagolásában, és segíthet a heurisztikus motornak (lásd később) a gyanúsnak vagy rosszindulatúnak tekinthető API-hívások észlelésében. Néhány jó homokozó itt.
• heurisztikus motor : mint fentebb említettük, a heurisztikus motor nem aláírásokat keres, hanem gyanús viselkedést keres (pl. minta, amely megnyit egy kapcsolatot a weboldalon hxxp: / / malware_besite. com). ezt statikus elemzéssel vagy homokozóval lehet elvégezni.

Signature syntax

az signature syntax annak a nyelvnek a “szótára”, amelyet az signature engine megért. Ez egy módja annak, hogy formalizáljuk, hogy mi a minta, hogyan kell keresni, és hol kell keresni a mintában. A szintaxisnak elég egyszerűnek kell lennie ahhoz, hogy a kutatók megértsék, elég erősnek ahhoz, hogy minden felhasználási esetet kezeljen, és könnyen elemezhető a jobb motorteljesítmény érdekében.

a VirusTotal kifejlesztett egy jó szintaxist és motort (Yara projekt), amely nyílt forráskódú. Ennek jó mutatónak kell lennie a saját szintaxisának elkészítéséhez, vagy egyszerűen csak használni. Itt van egy jó blogbejegyzés arról is, hogyan hozzon létre aláírásokat az antivírusokhoz.

példa az aláírásra:

rule silent_banker : banker{ meta: description = "This is just an example" thread_level = 3 in_the_wild = true strings: $a = {6A 40 68 00 30 00 00 6A 14 8D 91} $b = {8D 4D B0 2B C1 83 C0 27 99 6A 4E 59 F7 F9} $c = "UVODFRYSIHLNWPEJXQZAKCBGMT" condition: $a or $b or $c}

önvédelem

az önvédelem nagyon fontos egy víruskereső számára, hogy elkerülje a rosszindulatú programok legyőzését, és továbbra is megvédje a felhasználót. Ez az oka annak, hogy egy víruskeresőnek képesnek kell lennie arra, hogy megvédje saját telepítését, és tartsa fenn a kitartást az újraindításkor.

számos védelmi hely van: fájlok, rendszerleíró kulcsok, folyamatok/szálak, memória.

• fájlvédelem valósul meg a minifilter, különös szabályok a fájlokat a víruskereső (nincs hozzáférés törlés, átnevezés, mozgó, írás).
• a rendszerleíró adatbázis védelme a rendszerleíró adatbázis szűrőjébe kerül, az Illesztőprogram és a szolgáltatás rendszerleíró kulcsaihoz való hozzáférés megtagadva.
• a drivers szálak védettek, mert ez elég lehetetlen, hogy kirak kernel modul nélkül összeomlik a rendszer
• , hogy képes legyen megvédeni a szolgáltatást, ami egy userland folyamat, 2 megoldások:

1. a legegyszerűbb az lenne, ha a hibákra vonatkozó szabályokat hozzáadnánk a szolgáltatáskezelőhöz, és minden hibaszabályt “szolgáltatás újraindítása” – ra állítanánk. Így, ha a szolgáltatáskezelő nem állítja le a szolgáltatást, újraindul. Természetesen a szolgáltatásnak nem szabad képesnek lennie a parancsok elfogadására, amíg a rendszer nem indul újra (vagy nem áll le).

1. a második módszer, amely általánosabb, az lenne, ha visszahívásokat állítana be a folyamatkezelőkre az ObRegisterCallbacks segítségével.

ha az ObjectType-t Pprocesstype-re, a műveletet pedig OB_OPERATION_HANDLE_CREATE-re állítja, akkor egy művelet előtti és utáni visszahívást kap, és vissza tudja adni az ACCESS_DENIED-et ReturnStatus-ba, ha a lekérdezett folyamatkezelő olyan grantedaccess-t kapott, amely folyamatmegszakítási jogokkal rendelkezik (vagy folyamatírási jogokkal, vagy bármi mással, ami összeomláshoz/megöléshez vezethet), és természetesen, ha a folyamat az antivírusnak védenie kell (például a szolgáltatását).

természetesen a Duplicate handle-t és a PsThreadType-t is meg kell őrizni, hogy elkerüljük az olyan lezárási módszereket, amelyek megkövetelik a folyamat vagy a szál fogantyújának megragadását. Íme egy kis példa a visszahívás használatára.

NTSTATUS ObRegisterCallbacks( _In_ POB_CALLBACK_REGISTRATION CallBackRegistration, _Out_ PVOID *RegistrationHandle);

typedef struct _OB_CALLBACK_REGISTRATION { USHORT Version; USHORT OperationRegistrationCount; UNICODE_STRING Altitude; PVOID RegistrationContext; OB_OPERATION_REGISTRATION *OperationRegistration;} OB_CALLBACK_REGISTRATION, *POB_CALLBACK_REGISTRATION;

typedef struct _OB_OPERATION_REGISTRATION { POBJECT_TYPE *ObjectType; OB_OPERATION Operations; POB_PRE_OPERATION_CALLBACK PreOperation; POB_POST_OPERATION_CALLBACK PostOperation;} OB_OPERATION_REGISTRATION, *POB_OPERATION_REGISTRATION;

VOID ObjectPostCallback( _In_ PVOID RegistrationContext, _In_ POB_POST_OPERATION_INFORMATION OperationInformation);

typedef struct _OB_POST_OPERATION_INFORMATION { OB_OPERATION Operation; union { ULONG Flags; struct { ULONG KernelHandle :1; ULONG Reserved :31; }; }; PVOID Object; POBJECT_TYPE ObjectType; PVOID CallContext; NTSTATUS ReturnStatus; POB_POST_OPERATION_PARAMETERS Parameters;} OB_POST_OPERATION_INFORMATION, *POB_POST_OPERATION_INFORMATION;

typedef union _OB_POST_OPERATION_PARAMETERS { OB_POST_CREATE_HANDLE_INFORMATION CreateHandleInformation; OB_POST_DUPLICATE_HANDLE_INFORMATION DuplicateHandleInformation;} OB_POST_OPERATION_PARAMETERS, *POB_POST_OPERATION_PARAMETERS;

typedef struct _OB_POST_CREATE_HANDLE_INFORMATION { ACCESS_MASK GrantedAccess;} OB_POST_CREATE_HANDLE_INFORMATION, *POB_POST_CREATE_HANDLE_INFORMATION;

GUI (grafikus felhasználói felület)

ez a jéghegy látható része. Véleményem szerint az egyik (talán a) legfontosabb rész, ha el akarja adni a terméket. A felhasználók szeretik azt, ami szép, könnyen használható, intuitív. Még akkor is, ha nem 100% – ban hatékony. A GUI-nak szexinek kell lennie.

a GUI csak egy üres héj, csak grafikus kezeléseket végez, és parancsokat küld/fogad a magnak (a szolgáltatásnak). Megjeleníti az előrehaladási sávokat, az elemzett elemeket, konfigurációt biztosít, és így … itt van az Avast felhasználói felület. Szexi, igaz? 🙂

építészet

a globális építészet lehet valami, ami így néz ki:

1. GUI: nincs rendszergazdai jogok, gyenge
2. Guard DLL(s) : webböngésző védelem, közepes
3. szolgáltatás : rendszergazdai jogok. Átjáróként szolgál a kernel kódjához, és döntéseket hoz néhány adatbázissal együtt, STRONG
4. illesztőprogram(ok): Kernel szűrők, STRONG

a GUI-nak nincs szüksége adminisztratív jogokra, csak felhasználói műveleteket hajt végre és továbbítja azokat a szolgáltatásnak. Azt is megjeleníti a termék állapotát. Semmi több, nem ez a célja. Ha a GUI-t megölik, ez nem jelent problémát, mivel a szolgáltatásnak képesnek kell lennie arra, hogy újraindítsa.

a guard DLL-ek (ha vannak ilyenek) tömegesen kerülnek be az összes folyamatba, és képesnek kell lenniük IAT-horgok és/vagy rosszindulatú szálak keresésére. Meg kell elég nehéz kirak vagy legyőzni. Ezek nem kritikusak, hanem fontosak.

a szolgáltatás a termék magja. Meg kell killable, vagy legalábbis képesnek kell lennie arra, hogy önálló újraindítás kill. A szolgáltatás felelős a termék összes modulja közötti kommunikációért, parancsokat küld az illesztőprogramoknak, parancsokat vesz a felhasználótól, lekérdezi az adatbázist mintaelemzés céljából. Ez az agy.

a kernel illesztőprogramjai szintén kritikusak. Ők azok a csápok, amelyek információkat gyűjtenek mindenről, ami a rendszeren történik, és továbbítják azokat a szolgálatnak döntés céljából. A szolgálat döntése alapján megtagadhatják az őrzött helyekhez való hozzáférést is.

következtetés

egy erős, megbízható és stabil vírusirtó motor létrehozása bonyolult feladat, amelyhez kísérletezett emberek szükségesek, akik nagyon erős ismeretekkel rendelkeznek a windows kernel programozásában, a windows Alkalmazások programozásában, a GUI tervezésében, a szoftverarchitektúrában, a malware elemzésben, …

a stabil illesztőprogramok felépítése szintén bonyolult feladat, mert egy kis homokszem összeomolhat az egész rendszerben. Tesztelésre, tesztelésre és sok tesztelésre van szükség. Amikor a motor kész, és működik, akkor csak meg kell bérelni a kutatók elemezni malwares és adjunk aláírást az adatbázisba .. mire vársz? Gyerünk! Enterprises

linkek

• http://www.symantec.com/connect/articles/building-anti-virus-engine