réteges ködösítés: a réteges biztonság szoftveres ködösítési technikáinak taxonómiája

ez a szakasz az egyes kódelemek ködösítési technikáit vizsgálja. Ez a réteg lefedi a legtöbb kiadványt szoftver obfuscation terület. Amint az ábrán látható. 4, aszerint, hogy egy obfuscation technika milyen elemeket céloz meg, ezt a kategóriát öt alkategóriára osztjuk: obfuscating layouts, obfuscating controls, obfuscating dataobfuscating functions és obfuscating classes.

Obfuscating layout

Layout obfuscation összekeveri a kódok vagy utasítások elrendezését, miközben az eredeti szintaxis sértetlen marad. Ez a rész négy layout obfuscation stratégiát tárgyal: értelmetlen osztályozók, redundáns szimbólumok eltávolítása, kapcsolódó kódok elválasztása és kéretlen kódok.

értelmetlen azonosítók

ezt a megközelítést lexikális ködösítésnek is nevezik, amely az értelmes azonosítókat értelmetlenné alakítja. A legtöbb programozási nyelv esetében az értelmes és egységes elnevezési szabályok (pl. Magyar jelölés (Simonyi 1999)) elfogadása szükséges, mint jó programozási gyakorlat. Bár az ilyen neveket a forráskódok adják meg, egyesek alapértelmezés szerint a kiadott szoftverben maradnak. Például a globális változók és függvények nevei a C / C++ – ban binárisokban vannak tárolva, és a Java Összes neve bájtkódokban van fenntartva. Mivel az ilyen értelmes nevek megkönnyíthetik a kontradiktórius program elemzését, meg kell zavarnunk őket. Annak érdekében, hogy az elhomályosított azonosítók zavarosabbak legyenek, Chan and Yang (2004) azt javasolta, hogy szándékosan ugyanazokat a neveket használják különböző típusú vagy különböző tartományokon belüli objektumokra. Az ilyen megközelítéseket a ProGuard (2016) fogadta el a Java programok alapértelmezett ködösítési sémájaként.

redundáns szimbólumok eltávolítása

ez a stratégia redundáns szimbolikus információkat távolít el a kiadott szoftverektől, például a legtöbb propgram hibakeresési információitól (alacsony 1998). Ezenkívül vannak más redundáns szimbólumok is a programok bizonyos formátumaihoz. Például az ELF fájlok szimbólumtáblákat tartalmaznak, amelyek rögzítik az azonosítók és címek párjait. Amikor a C/C++ programok fordítására alapértelmezett fordítási opciókat fogadunk el, például az LLVM (Lattner and Adve 2004) használatával, a generált bináris fájlok ilyen szimbólumtáblákat tartalmaznak. Az ilyen redundáns információk eltávolításához a fejlesztők alkalmazhatják a Linux strip eszközét. Egy másik példa a redundáns információkkal az Android smali kódok. Alapértelmezés szerint a generált smali kódok a következővel kezdődő információkat tartalmazzák .vonal és .forrás, amely el lehet távolítani a ködösítés céljából (Dalla Preda and Maggi 2017).

kapcsolódó kódok elválasztása

EGY program könnyebben olvasható, ha logikailag kapcsolódó kódjai fizikailag is közel vannak (Collberg et al. 1997). Ezért a kapcsolódó kódok vagy utasítások elválasztása növelheti az olvasás nehézségeit. Mind a forráskódokra (pl. változók átrendezése (Low 1998)), mind az összeszerelési kódokra (pl. utasítások átrendezése (Wroblewski 2002)) alkalmazható. A gyakorlatban feltétel nélküli ugrások alkalmazása a program átírásához népszerű megközelítés ennek eléréséhez. Például a fejlesztők megkeverhetik az összeszerelési kódokat, majd alkalmazhatják a goto-t az eredeti vezérlési folyamat rekonstruálásához (You and Yim 2010). Ez a megközelítés népszerű az összeszerelési kódok és a Java bájtkódok esetében a goto utasítások elérhetőségével (Dalla Preda and Maggi 2017).

kéretlen kódok

ez a stratégia olyan kéretlen utasításokat ad hozzá, amelyek nem működnek. A bináris fájlokhoz hozzáadhatunk no-operation utasításokat (NOP vagy 0x00) (Dalla Preda and Maggi 2017; Marcelli et al. 2018). Különben is, mi is hozzá junk módszerek, mint például hozzátéve megszűnt módszerek Android smali kódok (Dalla Preda and Maggi 2017). A kéretlen kódok általában megváltoztathatják a kódok aláírását, ezért elkerülhetik a statikus mintafelismerést.

mivel az elrendezés zavarása nem befolyásolja az eredeti kód szintaxisát, kevésbé hajlamos a kompatibilitási problémákra vagy hibákra. Ezért az ilyen technikák a legkedveltebbek a gyakorlatban. Ráadásul az értelmetlen azonosítók és a redundáns szimbólumok eltávolításának technikái csökkenthetik a programok méretét, ami tovább vonzóvá teszi őket (ProGuard 2016). Az elrendezés zavarosságának hatékonysága azonban korlátozott. Ígéretes ellenálló képességgel rendelkezik a deobfuscációs támadásokkal szemben, mivel egyes átalakulások egyirányúak, amelyeket nem lehet megfordítani. Néhány elrendezési információt azonban alig lehet megváltoztatni, például a Java SDK módszerazonosítóit. Az ilyen maradék információ elengedhetetlen az ellenfelek számára, hogy visszaszerezzék az elhomályosított információkat. Például Bichsel et al. (2016) megpróbálta deobfuscated ProGuard-obfuscated apps, és sikeresen vissza mintegy 80% nevek.

Obfuscating controls

ez a fajta obfuscation technikák átalakítja a vezérlők kódok növelése a Program összetettségét. Ezt hamis vezérlési folyamatokkal, valószínűségi vezérlési folyamatokkal, diszpécser-alapú vezérlésekkel és implicit vezérlésekkel lehet elérni.

hamis vezérlési folyamatok

a hamis vezérlési folyamatok azokra a vezérlési folyamatokra vonatkoznak, amelyeket szándékosan adnak hozzá egy programhoz, de soha nem fognak végrehajtani. Ez növelheti a Program összetettségét, pl., McCabe komplexitás (McCabe 1976) vagy Harrison metrics (Harrison and Magel 1981). Például a McCabe komplexitást (McCabe 1976) úgy számítják ki, hogy a vezérlőáramú gráf éleinek száma mínusz a csomópontok száma, majd plusz a csatlakoztatott komponensek kétszerese. A McCabe komplexitásának növelése érdekében vagy új éleket vezetünk be, vagy mind az új éleket, mind a csomópontokat hozzáadhatjuk egy csatlakoztatott komponenshez.

a hamis kontrollfolyamatok elérhetetlenségének garantálása érdekében Collberg et al. (1997) átlátszatlan predikátumok alkalmazását javasolta. Az átlátszatlan előrejelzést olyan predikátumként határozták meg, amelynek eredménye a ködösítési idő alatt ismert, de statikus programelemzéssel nehéz levezetni. Általában egy átlátszatlan predikátum lehet állandóan igaz (PT), állandóan hamis (PF) vagy kontextusfüggő (P?). Három módszer létezik az átlátszatlan predikátumok létrehozására: numerikus sémák, programozási sémák és kontextuális sémák.

numerikus sémák

a numerikus sémák átlátszatlan predikátumokat alkotnak matematikai kifejezésekkel. Például a 7×2-1 db Y2-es szám állandóan igaz minden X és y egész számra. Közvetlenül alkalmazhatunk ilyen átlátszatlan predikátumokat hamis kontrollfolyamatok bevezetésére. Az 5a ábra egy példát mutat be, amelyben az átlátszatlan predikátum garantálja, hogy a hamis vezérlőáram (azaz az else ág) nem kerül végrehajtásra. A támadóknak azonban nagyobb esélyük lenne észlelni őket, ha ugyanazokat az átlátszatlan predikátumokat gyakran alkalmazzuk egy ködös programban. Arboit (2002) ezért javasolta az ilyen átlátszatlan predikátumok családjának automatikus létrehozását, hogy az obfuscator minden alkalommal egyedi átlátszatlan predikátumot válasszon.

egy másik, nagyobb biztonságú matematikai megközelítés a kriptográfiai funkciók alkalmazása, mint pl hash függvény \(\mathcal {H}\) (Sharif et al. 2008) és homomorf titkosítás (Zhu and Thomborson 2005). Például helyettesíthetünk egy állítmányt x= = c val vel \(\mathcal {H} (x)==c_{hash}\) hogy elrejtsük az X megoldását ehhez az egyenlethez. Vegye figyelembe, hogy egy ilyen megközelítést általában a rosszindulatú programok alkalmaznak a dinamikus programelemzés elkerülésére. Kriptográfiai funkciókat is alkalmazhatunk olyan egyenletek titkosítására, amelyek nem teljesíthetők. Az ilyen átlátszatlan predikátumok azonban sok fölött vannak.

a statikus elemzésnek ellenálló átlátszatlan állandók összeállításához Moser et al. (2007) 3-SAT problémák alkalmazását javasolta, amelyek NP-kemények. Ez azért lehetséges, mert hatékony algoritmusokkal lehet ilyen nehéz problémákat összeállítani (Selman et al. 1996). Például Tiella and Ceccato (2017) bemutatta, hogyan lehet ilyen átlátszatlan predikátumokat összeállítani k-klikk problémákkal.

a dinamikus elemzésnek ellenálló átlátszatlan állandók összeállításához Wang et al. (2011) javasolta az átlátszatlan predikátumok összeállítását olyan megoldatlan sejtésekkel, amelyek sokszor hurkolnak. Mivel a hurkok kihívást jelentenek a dinamikus elemzéshez, a természet megközelítésének ellenállónak kell lennie a dinamikus elemzéssel szemben. Ilyen sejtések például a Collatz-sejtés, 5x + 1 sejtés, Matthews-sejtés. Az 5B. ábra bemutatja, hogyan kell alkalmazni a Collatz-sejtést a hamis ellenőrzési folyamatok bevezetésére. Nem számít, hogyan inicializáljuk az x-et, a program x=1-gyel végződik, és az originalCodes() mindig végrehajtható.

programozási sémák

mivel a kontradiktórius programelemzés komoly veszélyt jelent az átlátszatlan predikátumokra, kihívást jelentő programelemzési problémákat alkalmazhatunk az átlátszatlan predikátumok összeállításához. Collberg et al. javasolt két klasszikus probléma, pointer analysis és egyidejű programok.

a mutatóelemzés általában annak meghatározására utal, hogy két mutató ugyanarra a címre mutathat-e vagy sem. Néhány mutatóelemzési probléma lehet NP-nehéz statikus elemzéshez, vagy akár eldönthetetlen is (Landi and Ryder 1991). További előny, hogy a mutató műveletek nagyon hatékonyak a végrehajtás során. Ezért a fejlesztők rugalmas és hatékony átlátszatlan előrejelzéseket állíthatnak össze jól megtervezett mutatóelemzési problémákkal, például dinamikus adatstruktúrájú objektumok mutatóinak fenntartásával (Collberg et al. 1998a).

párhuzamos programok vagy párhuzamos programok egy másik kihívást jelentő kérdés. Általában az n állítások párhuzamos régiója n! a végrehajtás különböző módjai. A végrehajtást nemcsak a program határozza meg, hanem a gazdagép futási állapota is. Collberg et al. (1998a) egyidejű programok alkalmazását javasolta a mutató alapú megközelítés javítása érdekében a mutatók egyidejű frissítésével. Majumdar and Thomborson (2006) javasolta az elosztott párhuzamos programok alkalmazását az átlátszatlan predikátumok összeállításához.

ezenkívül egyes megközelítések átlátszatlan predikátumokat alkotnak programozási trükkökkel, például kivételkezelő mechanizmusok kihasználásával. Például Dolz and Parra (2008) javasolta a try-catch mechanizmus használatát átlátszatlan predikátumok összeállításához.Net és Java. A kivételesemények közé tartozik a nullával való osztás, a nullmutató, a tartományon kívüli index vagy akár bizonyos hardveres kivételek (Chen et al. 2009). Az eredeti program szemantikája testreszabott kivételkezelési sémákkal érhető el. Az ilyen átlátszatlan predikátumoknak azonban nincs biztonsági alapja, és sebezhetőek a fejlett kézzel készített támadásokkal szemben.

kontextuális sémák

kontextuális sémák alkalmazhatók variáns átlátszatlan predikátumok (azaz {P?}). A predikátumoknak rendelkezniük kell bizonyos determinisztikus tulajdonságokkal, amelyek felhasználhatók a programok elhomályosítására. Például Drape és et al. (2009) olyan átlátszatlan predikátumok összeállítását javasolta, amelyek invariánsak egy kontextuális kényszer alatt, például az átlátszatlan predikátum x mod3==1 folyamatosan igaz, ha x mod3:1?x++: x=x + 3. Palsberg et al. (2000) javasolt dinamikus átlátszatlan predikátumok, amelyek Korrelált predikátumok sorozatát tartalmazzák. Az egyes predikátumok értékelési eredménye futásonként változhat. Mindaddig, amíg a predikátumok korrelálnak, a program viselkedése determinisztikus. Az 5C ábra a dinamikus átlátszatlan predikátumok példáját mutatja be. Nem számít, hogyan inicializáljuk *p és * q,A program egyenértékű y=x+3, x=y+3.

a hamis kontrollfolyamatok ellenállása leginkább az átlátszatlan predikátumok biztonságától függ. Az átlátszatlan predikátumok ideális biztonsági tulajdonsága, hogy a legrosszabb esetben exponenciális időre van szükségük a töréshez, de a felépítéshez csak polinom időre van szükség. Vegye figyelembe, hogy egyes átlátszatlan predikátumokat ilyen biztonsági aggályokkal terveztek, de hibákkal is megvalósíthatók. Például az Ogiso et al. által javasolt 3-SAT problémák. (2003) triviális problémabeállításokon alapulnak, amelyek könnyen egyszerűsíthetők. Ha az ilyen átlátszatlan predikátumokat megfelelően hajtják végre, akkor ígéretesek lesznek rugalmasak.

valószínűségi vezérlési folyamatok

a hamis vezérlési áramlások problémákat okozhatnak a statikus programelemzésben. Ezek azonban érzékenyek a dinamikus programelemzésre, mivel a hamis vezérlési folyamatok inaktívak. A valószínűségi ellenőrzési áramlások gondolata más stratégiát alkalmaz a fenyegetés kezelésére (Pawlowski et al. 2016). Bevezeti a kontrollfolyamatok ismétlését ugyanazzal a szemantikával, de eltérő szintaxissal. Ha ugyanazt a bemenetet többször fogadja, a program eltérő módon viselkedhet a különböző végrehajtási időpontokban. A technika az oldalsó csatornás támadások leküzdésére is hasznos (Crane et al. 2015).

vegye figyelembe, hogy a valószínűségi kontrollfolyamatok stratégiája hasonló a hamis kontrollfolyamatokhoz kontextuális átlátszatlan predikátumokkal. De természetükben különböznek egymástól, mivel a kontextuális átlátszatlan predikátumok halott utakat vezetnek be, bár nem vezetnek be kéretlen kódokat.

diszpécser-alapú vezérlők

a diszpécser-alapú vezérlés határozza meg a futási idő alatt végrehajtandó következő kódblokkokat. Az ilyen vezérlők elengedhetetlenek a vezérlés-áramlás ködösítéséhez, mert elrejthetik az eredeti vezérlőáramokat a statikus programelemzés ellen.

az egyik fő diszpécser-alapú obfuscation megközelítés a kontroll-flow simítás, amely a mélységi kódokat sekélyebbé, összetettebbé alakítja. Wang et al. (2000) először javasolta a megközelítést. A 6. ábra egy példát mutat be a papírjukból, amely egy while hurkot egy másik formává alakít át kapcsolótokkal. Az ilyen átalakulás megvalósításához, az első lépés az, hogy a kódot ekvivalens ábrázolássá alakítsuk az If-then-goto utasításokkal, az ábrán látható módon. 6; Ezután módosítják a goto nyilatkozatokat kapcsolóház állításokkal, amint az ábrán látható. 6. Ily módon az eredeti programszemantika implicit módon valósul meg a switch változó adatáramlásának szabályozásával. Mivel a kódblokkok végrehajtási sorrendjét a változó dinamikusan határozza meg, a program végrehajtása nélkül nem lehet tudni a vezérlési folyamatokat. Cappaert and Preneel (2010) formalized control-flow lapítás, mint foglalkoztató diszpécser csomópont (például switch), amely szabályozza a következő kódblokkot kell végrehajtani; végrehajtása után egy blokk, ellenőrzés átkerül vissza a diszpécser csomópont. Különben is, számos fejlesztések kód-flow egyengető. Például, hogy fokozza az ellenállást a statikus program elemzése a kapcsoló változó, Wang et al. (2001) javasolta a mutató elemzési problémáinak bevezetését. A program további bonyolítása érdekében Chow et al. (2001) hamis kódblokkok hozzáadását javasolta.

l 6szl és Kiss (2009) Egy kontroll-flow simító mechanizmust javasolt a C++ szintaxis kezelésére, mint például a try-catch, while-do, continue. A mechanizmus absztrakt szintaxisfán alapul, és rögzített elrendezési mintát alkalmaz. Ahhoz, hogy minden kódblokk elfedje, egy while utasítást készít a külső hurokban, és egy switch-case vegyületet a hurokban. A switch-case vegyület megvalósítja az eredeti program szemantikáját, és a switch változót is alkalmazzák a külső hurok lezárására. Cappaert and Preneel (2010) megállapította, hogy a mechanizmusok sérülékenyek lehetnek a helyi elemzésre, azaz a switch változót azonnal hozzárendelik úgy, hogy az ellenfelek a következő blokkot csak egy aktuális blokkra nézve következtethetik. Javasoltak egy megerősített megközelítést több trükkövel, például referencia-hozzárendelés alkalmazásával (pl. swVar=swVar+1) a közvetlen hozzárendelés helyett (pl. swVar=3), az If-else-en keresztüli hozzárendelés helyettesítése egységes hozzárendelési kifejezéssel, valamint egyirányú függvények alkalmazása az alapblokk utódjának kiszámításakor.

a kontroll-flow ellapítás mellett számos más diszpécser-alapú obfuscation vizsgálat is létezik (pl. (Linn and Debray 2003; Ge et al. 2005; Zhang et al. 2010; Schrittwieser és Katzenbeisser 2011)). Linn and Debray (2003) javasolta a bináris fájlok elfedését olyan ágfüggvényekkel, amelyek a vereminformációk alapján irányítják a végrehajtást. Hasonlóképpen, Zhang et al. (2010) azt javasolta, hogy ágfüggvényeket alkalmazzanak az objektumorientált programok elhomályosítására, amelyek egy egységes metódus meghívási stílust határoznak meg egy objektumkészlettel. Az ilyen mechanizmusok biztonságának növelése érdekében a Ge et al. (2005) azt javasolta, hogy az ellenőrzési információkat egy másik önálló folyamatban rejtsék el, és alkalmazzák a folyamatok közötti kommunikációt. Schrittwieser és Katzenbeisser (2011) változatos kódblokkok alkalmazását javasolta, amelyek ugyanazt a szemantikát valósítják meg.

a diszpécser-alapú ködösítés ellenáll a statikus elemzésnek, mivel elrejti egy szoftver vezérlő-áramlási grafikonját. Ugyanakkor érzékeny a dinamikus programelemzésre vagy a hibrid megközelítésekre. Például Udupa et al. (2005) hibrid megközelítést javasolt a rejtett kontrollfolyamatok feltárására mind statikus, mind dinamikus elemzéssel.

Implicit vezérlők

ez a stratégia az explicit vezérlési utasításokat implicit utasításokká alakítja. Ez akadályozhatja a fordított mérnököket abban, hogy foglalkozzanak a helyes vezérlési folyamatokkal. Például helyettesíthetjük az összeszerelési kódok vezérlő utasításait (például jmp és jne) a mov és más utasítások kombinációjával, amelyek ugyanazt a vezérlő szemantikát valósítják meg (Balachandran and Emmanuel 2011).

vegye figyelembe, hogy az összes létező kontroll-áramlás ködösítési megközelítés a szintaktikai szintű transzformációra összpontosít, míg a szemantikai szintű védelmet ritkán tárgyalták. Bár bizonyíthatnak némi ellenálló képességet a támadásokkal szemben, a szemantikai védelemmel kapcsolatos elhomályosító hatékonyságuk továbbra sem tisztázott.

Obfuscating data

jelenlegi adatok az obfuscation technikák az Általános adattípusokra összpontosítanak, például egész számokra, karakterláncokra és tömbökre. Az adatokat felosztással, egyesítéssel, eljárással, kódolással stb.

Adatfelosztás/összevonás

az Adatfelosztás egy változó információit több új változóra osztja szét. Például egy logikai változó két logikai változóra osztható, és logikai műveletek végrehajtásával megkaphatja az eredeti értéket.

az adatok összevonása viszont több változót összesít egy változóba. Collberg et al. (1998b) bemutatott egy példát, amely két 32 bites egész számot egyesít egy 64 bites egész számba. Ertaul and Venkatesh (2005) egy másik módszert javasolt, amely több változót egy térbe csomagol diszkrét logaritmusokkal.

Data procedurization

Data procedurization a statikus adatokat helyettesíti az eljáráshívásokkal. Collberg et al. (1998b) javasolta a karakterláncok helyettesítését egy olyan funkcióval, amely az összes karakterláncot képes előállítani a patikuláris paraméterértékek megadásával. Drape és et al. (2004) javasolta a numerikus adatok kódolását két F és g inverz függvénnyel. Ahhoz, hogy V értéket rendeljünk egy változóhoz i, hozzárendeljük egy injektált változóhoz j mint j=f (v). Az i használatához inkább g(j) – t hívunk meg.

adatkódolás

adatkódolás matematikai függvényekkel vagy rejtjelekkel kódolja az adatokat. Ertaul and Venkatesh (2005) javasolta a karakterláncok Affin rejtjelekkel történő kódolását (pl. Caser rejtjel), és diszkrét logaritmusokat alkalmaztak a szavak csomagolására. Fukushima et al. (2008) javasolta a tiszta számok kódolását exkluzív vagy műveletekkel, majd a számítási eredmény visszafejtését a kimenet előtt. Kovacheva (2013) javasolta a karakterláncok titkosítását az RC4 titkosítással, majd visszafejtését futás közben.

tömb transzformáció

tömb az egyik leggyakrabban alkalmazott adatszerkezet. A tömbök elhomályosításához Collberg et al. (1998b) számos átalakítást tárgyalt, például egy tömb felosztását több részsugárra, több tömb egyesítését egy tömbbe, egy tömb összecsukását a dimenzió növelése érdekében, vagy egy tömb ellapítását a dimenzió csökkentése érdekében. Ertaul and Venkatesh (2005) javasolta a tömbindexek kompozit függvényekkel történő átalakítását. Zhu és munkatársai. (2006); Zhu (2007) azt javasolta, hogy homomorf titkosítást alkalmazzanak a tömb átalakításához, beleértve az indexváltozást, a hajtogatást és a hízelgést. Például egy tömb elemeit összekeverhetjük I. m mod n-vel, ahol i az eredeti index, n az eredeti tömb mérete, m és n pedig viszonylag prímszám.

zavaró módszerek

módszer inline/outline

a módszer egy független eljárás, amelyet a program más utasításai hívhatnak meg. Módszer inline az eredeti eljárási hívást maga a függvénytest váltja fel. A módszer vázlata ellentétes módon működik, amely kivonja az utasítások sorozatát, és kivonja a módszert. Jó társaságok, amelyek elhomályosíthatják az eljárások eredeti absztrakcióját (Collberg et al. 1997).

Metódusklón

ha egy metódust erősen meghívunk, létrehozhatjuk a metódus replikációit, és véletlenszerűen meghívhatjuk az egyiket. A kontradiktórius értelmezés megzavarása érdekében a replikáció minden változatának valahogy egyedinek kell lennie, például különböző obfuscation transzformációk elfogadásával (Collberg et al. 1997) vagy különböző aláírások (Ertaul and Venkatesh 2004).

módszer összesítés/szórás

az ötlet hasonló az adatok elhomályosításához. Az irreleváns módszereket egy módszerbe összesíthetjük, vagy egy módszert több módszerre szórhatunk (Collberg et al. 1997; alacsony 1998).

Method proxy

ez a megközelítés proxy módszereket hoz létre a visszafejtés megzavarására. Például létrehozhatjuk a proxykat nyilvános statikus módszerként randomizált azonosítókkal. Ugyanazon módszerhez több különböző proxy is lehet (Dalla Preda and Maggi 2017). A megközelítés rendkívül hasznos, ha a módszer aláírások nem lehet megváltoztatni (Protsenko and Muller 2013).

Obfuscating classes

az Obfuscating classes néhány hasonló ötletet oszt meg az obfuscating módszerekkel, mint például a felosztás és a klón (Collberg et al. 1998b). Mivel azonban az osztály csak objektumorientált programozási nyelvekben létezik, mint például a JAVA és a. net, ezeket egyedi kategóriaként tárgyaljuk. Az alábbiakban bemutatjuk az osztályok elhomályosításának főbb stratégiáit.

csökkentő módosítók

az objektumorientált programok módosítókat tartalmaznak (pl., nyilvános, magán), hogy korlátozza az osztályokhoz és az osztályok tagjaihoz való hozzáférést. Csepegtető módosítók eltávolítja az ilyen korlátozásokat, és hogy minden tagja nyilvános (Protsenko and Muller 2013). Ez a megközelítés megkönnyítheti más osztályú obfuscációs módszerek megvalósítását.

hasító/Coalescing class

az ötlet a coalescing/felosztása, hogy elhomályosítja a szándék a fejlesztők, amikor a design az osztályok (Sosonkin et al. 2003). Az osztályok egyesítésekor helyi változókat vagy helyi utasításcsoportokat vihetünk át egy másik osztályba (Fukushima et al. 2003).

osztályhierarchia egyengető

interfész egy hatékony eszköz az objektum-orientált programok. A method proxyhoz hasonlóan proxykat is létrehozhatunk interfészekkel rendelkező osztályok számára (Sosonkin et al. 2003). Hatékonyabb módszer azonban az interfészekkel rendelkező osztályok közötti eredeti öröklési kapcsolat megszakítása. Ha hagyjuk, hogy az osztályhierarchiában egy részfa minden csomópontja ugyanazt az interfészt valósítsa meg, akkor a hierarchiát simíthatjuk (Foket et al. 2012).