Licenszellenőrző

C/C++
Valaki kérte, így összedobtam, és akkor már kitettem MIT licensszel, hátha másnak is kapóra jön. Arra szolgál, hogy adott egy kulcs-érték lista, amit úgy szeretnénk feldolgozni, hogy tudjuk, nem piszkáltak bele. Tipikusan extra funkciók engedélyezésére jó például. (A lényegi részét a MEG-4-ból vettem, és azt alakítottam önálló repóvá. Ott pl. arra használom ezt, hogy engedélyezze a WASM, EXE és ELF exportálást, ami bónusz funkcionalitás és csak külön licensszel érhető el.)

licchk

Ez a License Checker áll egy parancssoros programból és egy C fejlécből. A tetszőleges szöveges adatot a parancssoros proggival aláírod, amit aztán elküldhetsz az ügyfelednek és a C fejléc által nyújtott funkcióval ellenőrizhetsz. Nem kell neki semmi (na jó, libc-n kívül semmi), teljesen függőség mentes, ANSI C, nem használ semmilyen bővítményt, roppant kicsi (96K a forrás, kb. 2500 SLoC) ezért akár embedded cuccokban is könnyedén felhasználható. 
#include <licchk.h>
int licchk(char *license);
Ha nem piszkáltak bele a licensz sztringbe, akkor 1-el tér vissza, egyébként nullával. Ennyi. A licensz sztring formátuma bármilyen UTF-8 adat lehet (pl. INI, JSON, YAML, XML, PLIST, stb.), ez teljesen a programozóra van bízva.

UPDATE: csak hogy teljesen világos legyen, mire való ez: minden felhasználó ugyanazt a programot tölti le és használja, ami alapból "free trial" módban működik. Attól függően, hogy ki mennyit és miért fizetett, eltérő licenszfájlt kap, amit aztán a program betölt, és a tartalma függvényében engedélyez bizonyos funkciókat vagy sem. Ennek a függvénykönyvtárnak az a dolga, hogy garantálja, ebbe a licenszfájlba ne írhasson csak úgy bele akárki, mondjuk azt, hogy "unlimited", "all features" meg "never expires".
Ez tök bevett, általános gyakorlat, lásd pl (egy perces webkeresés eredménye): Autodesk, Adobe, Cisco, Microsoft, stb. (Egyébként az aktiváló kulcs is tök ugyanez, csak ott erősen limitált az opciók száma a kulcs hossza miatt és könnyű okosba' is kigeneráni, lásd keygen-ek. Ezzel szemben egy digitálisan aláírt licenszfájlt csak a privát kulcs birtokosa képes előállítani.)
  • 2350 megtekintés
A motorháztető alatt az ellenőrzés asszimetrikus kulcsokkal történik (konkrétan 4096 bites RSA-val). Az RSA kulcspárok pedig két prímből állnak elő.
(Ezt a részét az atomstabil, harcedzett Mbed-TLS-ből vettem, így azt a prímgenerálót is, ami a small_prime[] tömböt használja.)
miért jó a kis prímeket külön egy tömbben tárolni.
Hatékonyság miatt, lookup table.
Emlékeim szerint az RSA-hoz pont, hogy nagy prímek kellenek.
Nem egészen. Igazaból az RSA-hoz még csak nem is prímek kellenek, hanem csupán relatív prímek. Az Mbed-TLS sem nagy prímeket használ, hanem prímhalmazok szorzatát, úgy hogy n = ∏P(i), és ez is elég. (Sőt, valójában még nagyobb biztonságot is ad, mert a támadónak nehezebb a dolga, mintha csak mindig két n = pq szorzatáról lenne szó.)

TL;DR Igazából még csak relatív prímeknek sem kellene lenniük ezeknek, mert az RSA csak a szorzatuk maradékát használja fel. Mindössze arról van szó, hogy a publikus kulcs n,e párból áll össze, ahol az n legkissebb közös többszöröse (λ(n)) és az e kell, hogy relatív prímek legyenek (és igazából elég is, ha ezek azok, de persze ezt sokkal egyszerűbb elérni, ha az n eleve ismert prímek szorzata), a privát kulcs pedig ebből számolható, az n,d párosa, ahol d = e^-1 modulo λ(n) (legalábbis elméletben számolható, ugye a gyakorlatban túl sokáig tartana kiszámolni, pont ez a lényege). A szignó s = hash ^ d modulo n, az ellenőrzés meg hash == s ^ e modulo n?, és ennél a kettőnél mindegy, hogy az n két nagy pq prím szorzata, vagy számtalan több kissebbé, a lényeg, hogy az e (és a belőle számolt d) ne ossza.
Pontosan azért.

Most belenéztem egyébként az Mbed-TLS mbedtls_mpi_gen_prime() függvényébe, nem egészen világos, mit csinál, de mintha erathosztenészi szitaszerűséghez használná a small_prime[]-ot? A prímek produktumát a mbedtls_rsa_deduce_primes()-ban számolja, de úgy nézem azt csak a mbedtls_rsa_complete() hívja, a prímgeneráló maga nem. Nem kicsit van kézzel agyonoptimalizálva ez az Mbed-TLS, nem csoda, hogy olyan gyors (4096 bites RSA kulcspárt 26 mp alatt kiköpi, a GPG-nek ez több percébe kerül).

( Elbandi v | 2026. 03. 02., h – 17:48 )

a cracking tutorialok level 1 szinje hogy az if (akarmi()!= 0) tipusu ellenorzeseket hogy kell "feltorni". jol megbonyolitottad az egeszet, kozben meg szogegyszeru feltorni: https://pt.memedroid.com/memes/detail/1137543

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Nem érted a lényeget. Ez nem arra van, hogy bináris futtaható mahinálásától megvédjen, hanem arra, hogy az általa feldolgozott szöveges licenszfájlt ne mahinálhassák.
a cracking tutorialok level 1 szinje hogy az if (akarmi()!= 0) tipusu ellenorzeseket hogy kell "feltorni".
Ha feltételezzük, hogy a támadó képes átírni a gépikódot, akkor eleve minek bármiféle ellenőrzéssel vesződni, hisz bármikor átbillenthet bármilyen JNZ-t JZ-re, nem igaz?

Nem. Ha azt akarod, hogy a bináris gépikódot ne buzerálják, ahhoz a futtahatót magát kell aláírni, amit az OS-nek kell ellenőrizie betöltéskor, de az egy tök másik focipálya, semmi köze ehhez.
A PE elvileg tud ilyent (azt használja UEFI alatt a Secure Boot, bár nem túl hatásos, lásd CVE-k), tudtommal az ELF-nek nincs általános megoldása rá, csak nem hivatalos próbálkozások. Vagy esetleg obfuszkálhatod a text szegmenst, így lehetetlenítve el a diszasszemblálást.
De mégegyszer, ennek az égvilágon semmi köze a bemeneti adat ellenőrzéséhez.
de, tokeletesen ertem.
Dehogy érted, ez nyilvánvaló. Állításod szerint még az OpenSSL is egy felesleges, könnyen törhető vacak, hisz abban is if(RSA_verify() != 0) típusú ellenőrzés szerepel a kódban...
ha feltetelezzuk hogy user nemhaxol
Rohadtul nem ugyanaz a tudásszint egy szöveges fájlba beleírni, meg bináris gépikódot basztatni. Előbbit egy átlagos felhasználó is megkísérelheti (erre van ez), utóbbihoz vérprofi hacker kell (arra meg van a futtatható aláírásellenőrzés).
tokre folosleges egy ssl szarakodas.
Nincs semmiféle SSL itt. Egyébként is TLS-nek hívják már, de az sincs. Csak asszimmetrikus kulcsos aláírás és ellenőrzés.
eleg lenne egy sima ellenorzes is.
:FACEPALM: Tényleg fingod sincs, mire jó a digitális hitelesítés? Remélem nem IT-ban dolgozol.

De legyen neked, tessék, itt egy példa. A licensz tartalma "feature1=0" és "feature2=0" azoknak, akik nem perkáltak az extra funkciókért. Miféle ellenőrzéssel akarod meggátolni és észrevenni, hogy a felhasználó átírta-e Notepad-ban a licenszfájl tartalmát "feature1=1" és "feature2=1"-re, ezáltal fizetés nélkül aktíválva az extra funkciókat? Lássuk, miféle sima ellenőrzésről beszélsz!

Miféle ellenőrzéssel akarod meggátolni és észrevenni, hogy a felhasználó átírta-e

hat ilyen bonyolultat csak akkor ha a vege nem egy sima if. tehetnel meg bele egy kicsit tobb cput hasznalo cuccot (pl tobbfele titkositast!), biztos hasznos, amikor a vegen egy jz/jnz-vel ki lehet utni! :D

ha meg csak 1.0-as user ellen kell vedeni: sha256("titkoskod"+feature1+feature2) == fajlban_levo_hash. vagy barmi amit csak "security through obscurity" ved.

de badarsag lenne ilyet feltetelezni! ha meg az user tud haxxolni arra egyikse jo.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

hat ilyen bonyolultat csak akkor ha a vege nem egy sima if.
:FACEPALM: Bármilyen ellenőrzés vége mindig egy sima if. Igen, mindenhol, az OpenSSL-ben is, és nemcsak az RSA_verfiy() esetén, hanem a DSA_verify()-nél is.
tehetnel meg bele egy kicsit tobb cput hasznalo cuccot (pl tobbfele titkositast!)
:FACEPALM: Milyen "többféle"? Ebben semmiféle titkosítás sincs! Nyista! Nada! Ez hitelesítés! A base64 semmiképp sem tekinthető titkosításnak, csak kódolásnak.
ha meg csak 1.0-as user ellen kell vedeni: sha256("titkoskod"+feature1+feature2) == fajlban_levo_hash
:FACEPALM: Na akkor most fejtsd ki, hogy ennek a vége szerinted miért nem egy sima if! Szerinted ezt nem lehet egy jz/jnz-vel kiütni?
barmi amit csak "security through obscurity" ved.
:FACEPALM: Te tényleg azt képzeled, hogy az asszimmetrikus kulcsos aláírás az security by obscurity? Kezdjük ott, hogy sifrírozásra vonatkozhat csak, és nem is hitelesítésre, LOL! Csak ismételni tudom magam, remélem nem az IT-ban dolgozol.
ha meg az user tud haxxolni arra egyikse jo.
:FACEPALM: Látom még a magyar nyelvű olvasás sem megy... Konkrétan leírtam, mi való az adatmanipuláció ellen, és mi való a kódmanipuláció ellen.
:FACEPALM:
ne csodalkozz ha egy AI is kepes lenne feltorni ezt a "csoda" tithitelesitest!
Na azt megnézném, ha az AI képes lenne feltörni az RSA hitelesítést! És az RSA egyáltalán nem "csoda", hanem iparági sztandard.

Őszintén fel nem foghatom, mit picsogsz itt. Fikázod itt az RSA-t, holott nyilván azt sem tudod, mi fán terem, miért biztonságos, még alapvető fogalmakkal sem vagy tisztában (pl. mi a különbség authentication és encryption között). Olyan egetverő ostobaságokat hordasz itt össze, hogy egy hash ellenőrzés is elég lenne. :FACEPALM: Ezzel csak hülyét csinálsz magadból. Önmagában a hash egyáltalán nem elég, és pontosan erre kínál megoldást ez a függvénykönyvtár, ami digitálisan alá is írja azt a bizonyos hash-t.
pedig ahhoz nem is kell magas lec
Hát neked láthatóan ez is túl magas... Ennél már csak az lenne lejjebb, ha még PEDOFIDESZ szimpatizáns is lennél. Ha nem tetszik és nem érted, mire való a függvénykönyvtáram meg az iparági sztandard, akkor te csak használj tákolt megoldást a programjaidban! Na azt aztán tényleg bármelyik AI és még a Marci néni is röhögve feltöri és ráadásul a gépikód átírása nélkül is! Szerintem nem kéne világgá kürtölnöd, hogy akkora fogalmatlan idióta vagy, hogy fingod sincs a digitális hitelesítésről... Tudod értelmes ember ilyenkor inkább előveszi a tankönyvet / wikipédiát / stb., és nem kezd nyilvános ámokfutásba a saját maga lejáratására.

Mindenki más meg örül, hogy lett egy függőségmentes, könnyen illeszthető, könnyen használható, maximális védelmet nyújtó, RSA alapú megoldása.

Pedig abban valóban nincs igazad, hogy az if(x() != 0) az egyből sebezhető kód lenne, szerintem ilyent soha, senki, sehol nem állított.

Ha ez igaz lenne, akkor a legtöbb szoftvert kidobhatnánk a kukába, pláne azokat, amik C-ben vannak írva, hiszen a C-ben nem létezik a NULL intézménye, a NULL az by default egy #define NULL 0 eredményeképpen áll elő. És egy pointer ha nem mutat sehova, pontosan 0 értékű.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Pedig abban valóban nincs igazad, hogy az if(x() != 0) az egyből sebezhető kód lenne, szerintem ilyent soha, senki, sehol nem állított.
Pontosan, ráadásul ez nemcsak C-re vonatkozik, hanem általánosan az összes létező programozási nyelvre.

Például a Rust alatt az OpenSSL RSA ellenőrzésének is if(Verifier.verify() !=0) a vége, vagy épp Python alatt hasonlóan if public_key.verify() != 0: a vége. Az összes létező programozási nyelv alatt egy "if(x() != 0)" lesz a vége, nincs kivétel.
És egy pointer ha nem mutat sehova, pontosan 0 értékű.
Ezt benézted, itt még csak pointer sincs. Sima mezei int a visszatérési érték (az én licchk()-emnél, az Mbed-TLS mbedtls_rsa_pkcs1_verify()-jénél és az OpenSSL RSA_verify()-jénél is csak sima int).
Vagy csak úgy általánosságban értetted? Való igaz, hogy C alatt az egyik legtipikusabb, leggyakoribb kódrészlet az "if(valami != NULL)", tényleg irtó sok helyen jelentene gondot, ha ezzel baj lenne.

Értsd már meg, hogy itt nincs mit feltörni, itt nem a bináris támadásáról van szó. Bzt programja egy ellenőrzést végez, majd visszaadja, hogy igen vagy nem. Ha fel akarod törni, akkor symlinkelj a helyére egy scriptet amiben van egy return 0, és verd a melled, hogy mekkora hekker vagy. Na, a te feltörésed is pont ennyit ér, papíron nyilván működik, csak itt egyszerűen nincs relevanciája.

Form follows function.

ha jol ertem a cuccot akkor van egy license fajl, amiben benne van hogy az user jogosult X meg Y ficsort hasznalni, de Z-t nem. es ezt akarja valami magic koddal vedeni. lehet ezt csinalni nincs ezzel baj, csak epp egy picit ugyes user siman be tudja kapcsolni hogy a Z ficsor is menjen.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Látszik, hogy nem sikerült elolvasni.

Arról van szó, hogy lényegében a licencfájlban valóban ez az infó van benne, de elkódolva RSA kódolással. Tehát nem nyíltszövegesen, hanem lényegében kétkulcsú titkosítással, amit nem tud olyan egyszerűen módosítani, mert a licencfájl újrakódolásához kellene a kiadó oldaláról a kulcs. Ebben amúgy semmi új nincs, majdnem az összes licencfájl így működik.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

te most mirol beszelsz? bebasztal?

nincs semmi kodolva a licenc fajlban:

$ ./licchk  genkey test
Generating 4096-bit RSA key (be patient)... OK
Saving private key... OK
Saving public key... OK
$ echo -e "feature1=Y\nfeature2=N" >licfajl
$ ./licchk sign licfajl
Checking keys... OK
Generating license... munmap_chunk(): invalid pointer
Aborted (core dumped)

ezt most engedjuk el (ha lesz idom kidebugolom), a fajl ala lett irva:

$ cat licfajl
--------------------------test License--------------------------
feature1=Y
feature2=N
----------------------------------------------------------------
Qffm+hIJZj7nl+9eKB5kbmAb7ifjJkOTUULaKr3FG40MQvuu2QWN190b8V097va0
T8je/IMtGXbBzxCcbmOUk0TICF/R0lZWzXkYddob7FIhemt5tjdyg2D+wdlUPywx
j9fmk9fOPQ0KbIb0YWB+OMjwRBZFus4ylymZp4IAJfq0B7bsr6NjX33Udp8mFPwY
+37Z9kW2UdhfNYIbq5bstEg/0lQun6qKfTVqO71snyxdOPIBDH+DaIy4M9MQJiM/
61E48OPa+rgoaR96maZeK7kQbCjL/X5KojR52TwN6LKNQI0VV26O2DVOLJiN4+EM
/6adkj9pPO2S43OE7k7D8nf3WVCU3ddfEVDwu89uPrEfazb0AdVSLfCtquuHQ79G
4QOHwUSa02JN1SYyh5SxtxgMzdLwFCfy9ZkIAjfpYUVfq0CFtEx0futEmBGpDI6a
VfYLhxGUOQGF3R3zGbwzJqxd4LtpkS3/cFULSbEa/wQJ2yavqCAY1dhE/ZMlE42i
phX/an8Y2517nGrsMdBXe0IO9TVogLPnHayGo+aUcezAWUJ9bAsUwsM0QUyEt4tm
BoIHfrZcW2JSjUtETypAeV3Qby/nce/HSD17sVQO4AqUMuHmWjObxLgpM8IqDntD
1uiMHSBw64otxjPU/vvCi2cj4jpx4JvXZq1jRgOKE0c=

$ ./licchk verify licfajl
Checking keys... OK
Verifying license... OK

ott figyel benne az adat. "kapcsoljuk be" a feature2-ot, ugy mar nem lesz jo a verify :(

$ sed 's/feature2=N/feature2=Y/' -i licfajl
$ ./licchk verify licfajl
Checking keys... OK
Verifying license... FAILED

:(

A nagy magikus "tores":

$ sed 's/\x85\xC0\x74\x18/\x85\xC0\x75\x18/' -i licchk
$ ./licchk verify licfajl
Checking keys... OK
Verifying license... OK

Nahat! Koszi az ingyen feature2-ot! :D

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

van a programodhoz 

ha jol ertem ez lenne a licchk, nem?

egy kulcs=érték lista, amit te állítasz be a felhasználódnak

ez meg lenne a licfajl (vagy barmi), ahol a kulcs a feature1-2, az ertek meg hogy engedve van.

és nem akarod, hogy más belenyúlkáljon, miután kiadtad neki.

es itt bukik meg a story.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

ha jol ertem ez lenne a licchk, nem?
NEM. A "programod" az nem az aláíró tool, hanem az az a program, ami a te programod, amihez licenszeket akarsz eladni.
ez meg lenne a licfajl (vagy barmi)
Igen.
es itt bukik meg a story.
Faszt. Senki nem tud belenyúlkálni a licfájlba annélkül, hogy a te (szintén aláírt, ezért eredeti gépikódot tartalmazó) programod ezt ne venné észre.

Ugyanis ha valaki egyetlen bitet is módosít a licfájlon, akkor nem fog stimmelni a kiszámolt hash a digitális aláírásban szereplő hash-sel. Ahhoz meg, hogy a digitális aláírásban szereplő hash-t módosítsd, szükséges a privát kulcs, ami nincs meg a felhasználónál, sem a programodban, csakis a te gépeden.

Ha meg valaki a programodba akar belenyúlni (jnz/jz átbillentés), akkor a programod aláírása nem fog stimmelni. (Vagy lehet, hogy eleve el is titkosítod a kódszegmenst a programodban, ezért nem is látszik az az utasítás, ahol a jnz/jz flip kéne stb.)

az az a program, ami a te programod, amihez licenszeket akarsz eladni

jah az appom ami include-olta a licchk.h-t, ahogy a licchk.c. jo de akkor ott a test app, frissen buildelve (gcc -o test test.c), az mar jo?

$ ./test licfajl
License is valid, contents:
--------------------------test License--------------------------
feature1=Y
feature2=Y
----------------------------------------------------------------
bEGxgrj/1+1Cx7JeanbSwBjnB8YgeQVJjUJ/kWrauctQ1VVsTktyPHrax0TGwigL
....

itt a "csodacrack": sed 's/\x85\xC0\x74\x1A/\x85\xC0\x75\x1A/' -i test

modositsunk valamit a licfajl-on: sed 's/feature2=Y/ideaztirokbeamitakarok/' -i licfajl

# ./test licfajl
License is valid, contents:
--------------------------test License--------------------------
feature1=Y
ideaztirokbeamitakarok
----------------------------------------------------------------
bEGxgrj/1+1Cx7JeanbSwBjnB8YgeQVJjUJ/kWrauctQ1VVsTktyPHrax0TGwigL
...

es tovabbra is validnak mondja. :(

ez igy mindenre jo, csak erre nem:

nem akarod, hogy más belenyúlkáljon, miután kiadtad neki

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

tt a "csodacrack": sed 's/\x85\xC0\x74\x1A/\x85\xC0\x75\x1A/' -i test
És továbbra is bináris futtathatót módosítod, te fasz.
Már bocs, de aki ennyi után sem képes felfogni, mi a különbség a bemeneti adatfájl módosítása és a bináris futtatható program módosítása között, az egy idióta balfasz.

miert szerinted a binaris hol van? a gepemen. de jolvan, ha szerinted ez igy jo, hat lelke rajta. csak aki hasznalja a sajat appjahoz sok bevetelre ne szamitson, ilyen egyszeru tores mellett a kutya sem fogja megvenni.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Hát, tőled nem is vennék semmit.

Rajtad kívül mindenki más meg tisztában van vele, hogyha meg akarják akadályozni a kódjuk mahinálását, akkor azért bizony tenniük kell. És nem, nem a linpng-t vagy libjpeg-et próbálják majd erre használni, mert tudják, hogy azok nem erre valók, mint ahogy a License Checker sem erre való (az ég szerelmére, még véletlenül sem Nativemachinecode Checker a neve...).

És nem, még ha ehelyett az "nagypályás" OpenSSL-el / KiskukutyinRSA-val oldják is meg a licenszellenőrzést, még az sem elég, akkor is ugyanúgy plusz lépéseket kell tenniük, hogy ne lehessen azt az if-et átbillenteni. Mert ezt az OpenSSL-nek sem dolga kivédeni, ahogy a License Checkernek sem.

Hallod, meséld már el a saját szavaiddal, hogy mi a retek problémát látsz abban, hogy valaki nulla visszatérési értékre ellenőriz?! Mert ez úgy látom, eddig nem sikerült, csak hajtogatod a saját elméletedet, hogy az AI majd feltöri. Vagy oszd meg velünk végtelen bölcsességed, hogy tanulhassunk, vagy hagyd már abba a hülyeség szórását. Nem meggymag ez, a fórum meg nem a saját kerted.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Ezt benézted, itt még csak pointer sincs

Technikailag a visszatérési érték literálisan bármi lehet, AKÁR egy pointer is, tök mindegy, mert az if(x() != 0) az véd a null pointer ellen is. És pont azt akartam bemutatni - csak nem feltétlen neked - hogy ez egy teljesen átlagos és valid ellenőrzési módja annak, hogy akár egy int akár egy pointer típusú visszatérési értékre rácsekkoljunk (csak az értelme lesz más). Azt akarom elkerülni, hogy egy érvényes nyelvi konstrukciót démonizáljunk mindenféle indoklás nélkül.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Elvileg egyiken sem, pont ez (lenne) a lényege az UEFI Secure Boot-nak. Persze a gyakorlatban szinte képtelenség jól megvalósítani, virágzanak is a rootkitek meg az SB bypassok.
De ez azért akkor is nagyságrendekkel nehezebb feladat: most már nemcsak a program bináris kódját kell módosítani, hanem még a kernel-be is bele kell nyúlni pluszban. Azért ez már simán elérheti azt a komplexitást, hogy egyszerűen ne érje meg.

es aki warezolni akar meg programokat crackolni, az direkt bekapcsolja a secure bootot az uefi-ben hogy ezzel is szopassa magat. ertem! meg az uber secure macos-ben is ki lehet kapcsolni. ios-en mondjuk nem nagyon, de csinalhatsz ra sajat alairast es telepitheted a sajat ca-dat amivel alairtad.

Persze. De mégegyszer: azért ez már simán elérheti azt a komplexitást, hogy egyszerűen ne érje meg. Mostmár nemcsak a programba, nemcsak a kernelbe, hanem már az OS bootba is alaposan bele kell nyúlni (Win alapból nem hajlandó Secure Boot nélkül elindulni, szóval a BOOTMGR.EFI-t is basztatni kell ehhez).

Ha valaha foglalkoztál IT biztonságtechnikával, akkor tudod, hogy nem létezik feltörhetetlen rendszer, a trükk az, hogy akkor minősül biztonságosnak valami, ha a feltöréshez szükséges ráfordítás és költség jóval meghaladja a védeni kívánt adat értékét.
win11 talan, de ezt sem hiszem hogy nehez lenne megkerulni
De az még egy plusz szükséges lépés. Mégegyszer: azért ez már simán elérheti azt a komplexitást, hogy egyszerűen ne érje meg.
:)
Ha tényleg foglalkoztál IT biztonságtechnikával, akkor miért lep meg az, hogy mindent meg lehet kerülni, és a kérdés csupán csak az, megéri-e a ráfordítást?

Hogy jön ide a secure boot? Miért kellene bármelyik boot közben betöltődő binárist is módositani? Nincs olyan közkeletű oprendszer, ahol a csak aláirt alkalmazások futtatásának kikényszeritése ne egy policy lenne, azaz egy bit a beállitásokban, semmi köze a boot-kor betöltődő fileokhoz.

Hogy jön ide a secure boot?
Fentebb már írtam. Ha azt akarod, hogy ne módosítsák a kódot, ahhoz magát a futtathatót kell aláírni. Történetesen pont ennek egy iskolapéldája a Secure Boot, ti. az is aláírt futtathatókkal operál.
Miért kellene bármelyik boot közben betöltődő binárist is módositani? Nincs olyan közkeletű oprendszer, ahol a csak aláirt alkalmazások futtatásának kikényszeritése ne egy policy lenne, azaz egy bit a beállitásokban, semmi köze a boot-kor betöltődő fileokhoz.
Tévedsz. A policy ellenőrzés a kernel feladata, a kernel pedig boot-kor betöltött file (és egyébként Win esetében a policy maga is). Ha ki akarod ütni az aláírt programok futtatásának kikényszerítését, akkor így vagy úgy, de boot-kor betöltött fájlokon kell módosítanod. Ha futás közben bármelyik proggi kénye-kedve szerint módosíthatná a policy beállításokat, akkor az egész semmit sem érne (ez tipikusan egy Critical CVE kijátszása nélkül lehetetlen, abból meg nincs túl sok és azokat is gyorsan befoltozzák).

mégegyszer: a secure boot, nem vizsgál semmilyen user programot, hogy alá van-e irva, köze nincs ahhoz, hogy a te programod alá van irva vagy sem, meg ahhoz sem, hogy a rendszer vizsgálja-e a programod aláirását vagy sem.

Ezt egy policy befolyásolja és hidd el nekem, hogy még ha ellenőrizné is a secure boot a policy-t (de természetesen nem teszi) akkor is érvényes lenne az aláirás, ha kikényszeritve van az user programok aláirásának ellenőrzése, meg akkor is ha nem.

Tehát igen, a policy átbillentésével simán kikapcsolható az aláirás ellenőrzése a user programodnak. Hogy erre kinek van joga az más kérdés, de esélyes, hogy annak, aki amúgy is át tudja billenteni azt a nyamvadt if-et a programodban, annak lesz rá joga.

 

Jut eszembe, az egész vita arról szól, hogy az ellenőrző kódod a usereknél fut-e vagy sem. (szerintem nem irtad le hogy hogyan van használva)

Ha a user gépén fut, akkor teljesen jogos a felvetés, semmi perc alatt törhető az if megforditásával. Ennél sokkal-sokkal bonyolultabban szokás a védelmet felépiteni.

Ha meg a saját szervereden fut, ahova a user nem jut el, akkor meg tökmindegy.

a secure boot, nem vizsgál semmilyen user programot, hogy alá van-e irva
Dehogynem, sőt, még azt is megköveteli, hogy amit betölt, annak is vizsgálnia kell azokat, amiket az tölt be. Nem véletlenül szopóroller a GRUB Secure Boot alatt. Úgy kerülik meg, hogy a shim indul el (ez van a Microslop kulcsával aláírva), ami implementál egy teljesen független tanusítványkezelőt, és a GRUB, valamint az összes GRUB modul és a kernel és minden más, amit a GRUB betölthet, ezzel van aláírva. Ha nem így lenne, már a shim-et magát sem írná alá a Microslop.
még ha ellenőrizné is a secure boot a policy-t (de természetesen nem teszi)
De természetesen teszi, ellenőrzi a policy fájl aláírását is, és nem enged módosított policyfájlt betölteni. Keress arra, hogy "UEFI Golden key vulnerability", az pont arról szólt, hogy a bennfelejtett debug mód lehetővé tette tetszőleges policyfájl betöltését.
Tehát igen, a policy átbillentésével simán kikapcsolható az aláirás ellenőrzése a user programodnak.
Csak épp a Secure Boot által aláírt kernel nem hagyja, hogy csak átbillentsd ezt a bitet a policyben. Ha ezt képes egy felhasználói program megtenni, az Critical CVE minimum.
szerintem nem irtad le hogy hogyan van használva
Szerintem meg de. De akkor leírom mégegyszer. Csinálsz egy fájlt, amit a programodból akarsz feldolgozni. Ezt aláírod, majd elküldöd a usernek. A user elindítja a programod a saját gépén, ami betölti ezt a fájlt, és meggyőződik róla, hogy időközben senki sem piszkált bele.
semmi perc alatt törhető az if megforditásával.
Mert erre minden átlagfelhasználó képes? Még akkor is, ha maga a futtatható is alá van írva?
Ennél sokkal-sokkal bonyolultabban szokás a védelmet felépiteni.
Digitális aláírásnál jobb megoldás? Halljuk!

"Nem véletlenül szopóroller a GRUB Secure Boot alatt."

kezdek belefáradni... Mi a lfasz köze van a GRUB-nak a kispista.exe user program aláirásához? Betölti talán boot közben? NEM. Akkor köze nincs hozzá. Betölti azt, ami a boot folyamatban részt vesz, majd a user a login után futtat, amit csak akar, akár aláirt akár nem, akár secure boot-os CA-val van aláirva, akár nem. Hidd el, secure boot-om van és csilliárd aláiratlan szoftvert futtatok.

Ne hülyüljünk már meg teljesen...

"Csak épp a Secure Boot által aláírt kernel nem hagyja, hogy csak átbillentsd ezt a bitet a policyben."

Nem a szart nem. Köze nincs a secure boot-nak egy group policy beállitáshoz, ami jórészt registry értékek halmaza. Vagy azt gondolod van egy aláirókulcs a rendszerben, ami miután megváltoztattam a policy-t, újra aláirja egy olyan kulccsal amit a secure boot elfogad? Bebaszna. (ráadásul, ha lenne ilyen, akkor az egész rendszernek nem lenne értelme, hiszen bármit alá tudok vele irni, akár patkolt boot file-okat is, hiszen ezek szerint nálam van a privát kulcs)

"Ezt aláírod, majd elküldöd a usernek. A user elindítja a programod a saját gépén, ami betölti ezt a fájlt, és meggyőződik róla, hogy időközben senki sem piszkált bele."

Ha ez igy van, azaz a program is a user gépén van és a feldolgozandó file is a user gépén van, akkor nyugodj bele, teljesen jogos volt a felvetés, ez igy kutyagumit nem ér, fél pillanat alatt törhető az if megforditásával.

"Mert erre minden átlagfelhasználó képes?"

Dehogy, csak a userek 0,001%-a. Azok felrakják az egysoros scriptet ami átbillenti az if-et, a buta felhasználó meg patcheli vele a programot.

"Digitális aláírásnál jobb megoldás? Halljuk!"

Az a baj, hogy nem érted a problémát. Nem a titkositás törhető, hanem az ellenőrzése. Nem a titkot kell még nehezebbé tenni, hanem azt kell elérni, ne egyetlen if ellenőrizze, hanem sok, a feldolgozás sok pillanatában, ezek egymásra is hassanak stb-stb. Ezzel sem lesz atombiztos, csak nem 5 perc lesz hozzá egy egysoros patchelő megirása.

kezdek belefáradni...
Azt látom, pedig nem is olyan bonyi.
Mi a lfasz köze van a GRUB-nak a kispista.exe user program aláirásához? Betölti talán boot közben?
Az, hogy kispista.exe aláírását az a kernel ellenőrzi, ami a boot során töltődött be. Ha ki akarod herélni a kispista.exe aláírásellenőrzését a kernelből, ahhoz bizony azt a kernelt kellene módosítanod, ami a Secure Boot során töltött be és szintén alá van írva (ez a kernel a Secure Boot-tal, a kispista.exe valami mással).
group policy beállitáshoz, ami jórészt registry értékek halmaza
Faszt. Be is baszna, ha a teljes Windows védelmet bármelyik jöttment pistike ki tudná kapcsolni egy mezei regedit futtatással.
Vagy azt gondolod van egy aláirókulcs a rendszerben, ami miután megváltoztattam a policy-t, újra aláirja egy olyan kulccsal amit a secure boot elfogad?
Nem gondolom, TUDOM, és te is tudnád, ha vetted volna a fáradtságot, és kattintottál volna a linkre. És nem, te nem tudod megváltoztatni, csak a Microslop, pont ez a lényeg!
ezek szerint nálam van a privát kulcs
Nem, nincs nálad, és a policyfájlokat a Microslop írja alá, ne te. Te csak birka módon lecsengeted a pénzt aztán kapsz "Home"/"Pro"/"Enterprise"/mittommilyen verziót belőle, te nem tudod ezt átváltani.
Ha ez igy van, azaz a program is a user gépén van és a feldolgozandó file is a user gépén van, akkor nyugodj bele, teljesen jogos volt a felvetés, ez igy kutyagumit nem ér, fél pillanat alatt törhető az if megforditásával.
Csakhát nem tudod módosítani azt az if-et. Hogy miért nem tudod, azon gondolkodj el.
Dehogy, csak a userek 0,001%-a
Tehát mégha nincs is futtatható aláírásellenőrzés, sem kódszegmenstitkosítás, sem semmi, még akkor is szerinted az esetek 99,999%-ban tökéletes a megoldásom. Most nemazé', de az kicseszettül jó arány, nekem megfelel! (Mint tudjuk, 100%-os megoldás úgysem létezik soha)
azt kell elérni, ne egyetlen if ellenőrizze, hanem sok
Már leírtam sokszor, de leírom mégegyszer utoljára: az összes kibaszott programozási nyelven, az összes kibaszott függvénykönyvtár esetében, az összes kibaszott módszernél egyetlen if lesz a vége.

Az OpenSSL-nél is konkrétan egy if a vége, "if(RSA_verify() != 0)", akkor szerinted törhető az OpenSSL? Ha szerinted az, nyiss rá náluk egy ticketet, aztán meglátjuk, elküldenek-e melegebb éghajlatra!

/o\

"Ha ki akarod herélni a kispista.exe aláírásellenőrzését a kernelből, ahhoz bizony azt a kernelt kellene módosítanod"

Aztakurva. A kernelhez hozzá sem kell érjek magáról a file-ról veszem le az aláirást.

"Be is baszna, ha a teljes Windows védelmet bármelyik jöttment pistike ki tudná kapcsolni egy mezei regedit futtatással."

Jóreggelt kivánok, bármelyik admin jogú pistike át tudja irni a policy-t a registry-ben a pici kezével. De nyugodtan elindithatja a gpedit.msc-t, az is ugyanazt fogja csinálni, csak szép felületen.

"Nem gondolom, TUDOM"

Tehát minden egyes policy módosulás után újra aláiródik valami a boot process által vizsgált file-ok között. LOL, erre tényleg nem tudok mást mondani :)

"Nem, nincs nálad, és a policyfájlokat a Microslop írja alá, ne te."

Ez a rész külön érdekes. Tehát azt mondod amikor átbillentem a bitet a registry-ben, egy policy-hez, akkor jön valahogy a MS és alárija nekem. Érdekes elképzelés :)
De gondolom, akkor internet nélkül nem is tudok policy-t módositani. És ezt most kell megtudjam 2026-ben. Megérte ma is felkelni...

"Home"/"Pro"/"Enterprise"/mittommilyen verziót belőle, te nem tudod ezt átváltani."

;)

"még akkor is szerinted az esetek 99,999%-ban tökéletes a megoldásom."

Valamit nagyon csúnyán félreértesz.

"az összes kibaszott programozási nyelven, az összes kibaszott függvénykönyvtár esetében, az összes kibaszott módszernél egyetlen if lesz a vége."

NEM egyetlen if lesz a vége, nézz egy picit utána a programtöréseknek és védelmeknek.

"akkor szerinted törhető az OpenSSL?"

Ha az a feladat, hogy tudom-e módositani az openssl.exe-t, hogy egy megpiszkált hash-ű file-t jónak minősitsen, akkor természetesen IGEN, törhető az openssl.

Sajnos továbbra sem érted az alap problémát sem, én meg nem tudom ennél érthetőbben elmagyarázni.

Miafasz?
Aztakurva. A kernelhez hozzá sem kell érjek magáról a file-ról veszem le az aláirást.
Kernel: aláírás nélküli fájlok nem futtathatók. Csá.
NEM egyetlen if lesz a vége
DE. Mesélj, akkor a "if(RSA_verify() != 0)" vajon mi?
Ha az a feladat, hogy tudom-e módositani az openssl.exe-t, hogy egy megpiszkált hash-ű file-t jónak minősitsen, akkor természetesen IGEN, törhető az openssl.
Nyiss hát jegyet az OpenSSL-nél, hogy sebezhető a libjük, és lássuk, elküldenek-e a bús picsába avagy sem.
Sajnos továbbra sem érted az alap problémát sem, én meg nem tudom ennél érthetőbben elmagyarázni.
Sajnos továbbra sem érted az alap problémát sem, hogy amiről hadoválsz azt kurvára NEM ennek a függvénykönyvtárnak a feladata megoldani.

(A megoldási javaslatodat meg a DOS-os időkben használták csillámfaszlámák, de már akkor is gázosnak találták, mert veled ellentétben mindenki tudta, hogy az ilyen kód karbantarthatatlan, ezért inkább kódszegmenstitkosítás volt a nyerő már akkoriban is. Azóta meg eltelt 30 év, lett sokkal jobb megoldás is, futtatható aláírásellenőrzés, amiről persze fingod sincs.)

"Kernel: aláírás nélküli fájlok nem futtathatók. Csá."

Most eszembe jutott, hogy mi van a scriptekkel, amin nincs aláírás? Vagy ez úgy működik, hogy ha nincs a scripten/binárison aláírás akkor futtatható, de ha van, akkor csak akkor futtatja (a secure boot láncolat miatt megbízhatónak tekintett) kernel, ha az aláírást le tudja ellenőrizni, és az helyes?

Illetve mi van, ha nem módosítom az eredeti .exe -t, hanem berakok a helyére egy másikat, ugyanolyan névvel? Az ellen nem véd az a mechanizmus, ami a TPM/Secure boot -tal kezdődik (tamper védelem) és az aláírt kernellel folytatódik, majd a szintén aláírt user space -beli programokkal teljesedik ki, ugye?

(nem támadás, tényleg megérteni próbálom)

Form follows function.

Most eszembe jutott, hogy mi van a scriptekkel, amin nincs aláírás?
Abba mégis hogy akarod integrálni az ANSI C-ben írt, bináris gépikódra lefordított kódot?
Illetve mi van, ha nem módosítom az eredeti .exe -t, hanem berakok a helyére egy másikat, ugyanolyan névvel?
Azta kurva! Beraktam a Photoshop helyére egy Notepad-et, akkor én most feltörtem a Photoshop-ot?
Ne már, azért az idiotizmusnak is van határa.
tényleg megérteni próbálom
Szerintem ne erőlködj, meghaladja az értelmi képességeidet. A bináris futtatható (azaz PE/COFF vagy MACHO vagy ELF formátumú bitkolbász) védelme kurvára más lapra tartozik, mint amiről itt most szó van.

Nyugi, mondom, hogy nem támadlak, egyetértek veled. Az fel sem merült bennem, hogy a licchk -nak kellene védekezni bármilyen módon a licchk binárist ért bármilyen támadással szemben, lásd a korábbi szarkazmusos hozzászólásomat.

"Abba mégis hogy akarod integrálni az ANSI C-ben írt, bináris gépikódra lefordított kódot?"

Erre most nem gondoltam, de egyébként pythonban már csináltam ilyet, a win32.dll -t húztam be. Feltételezem, hogy van mód .exe -t is behúzni, és használni belőle a függvényeket. De ebben simán lehet, hogy tévedek, ehhez nem értek, szóval ez igazából egy kérdés, hogy milyen limitációkkal lehet (ha lehet) .exe -t használni függvénykönyvtárként.

Az végül is valid, amint mondtam, ugye? Erre gondolok: "Illetve mi van, ha nem módosítom az eredeti .exe -t, hanem berakok a helyére egy másikat, ugyanolyan névvel? Az ellen nem véd az a mechanizmus, ami a TPM/Secure boot -tal kezdődik (tamper védelem) és az aláírt kernellel folytatódik, majd a szintén aláírt user space -beli programokkal teljesedik ki, ugye?"

Ha ez valid, az nyilván nem a licchk gyengesége, hanem inkább ennek a kód aláírósdi koncepciónak (a kierőszakolt secure boot-tól kezdve) a gyengesége. Itt engem az érdekel, hogy akkor ez mi ellen véd? Mondom, nem a licchk, mert azt értem, hogy az mit ellenőriz, és a számára bemenő adatot (a licensz filet) a hardcodeolt pub kulccsal validálja, ez szerintem teljesen oké. De maga a secure boot-tól kezdve felépített, aláírt kernel és RÉSZBEN (és ez a fontos, hogy részben) aláírt user space programok által felépített vár mitől véd, ha nem követeli meg, hogy MINDEN alá legyen írva? Márpedig ilyet nem követelhet meg, hiszen script amit én írok, vagy a program amit én fordítok, az nyilván nem lesz aláírva, mint ahogyan a cmd -ben bepötyögött akármilyen parancsom sem.

Ezt a részét próbálom megérteni a dolognak, ennek már nincs köze a licchk -hoz, csak mellékszálként jutott eszembe ez a felvetés.
 

"Szerintem ne erőlködj, meghaladja az értelmi képességeidet."

Bevallom, ez rosszul esett. 

Form follows function.

Vagy ez úgy működik, hogy ha nincs a scripten/binárison aláírás akkor futtatható
Nem, aláírás nélkül egyáltalán nem futtatható semmi, ez az alap.

Például Secure Boot esetében ilyenkor "X has no signature. Incompatible with SecureBoot." vagy "Secure Boot Violation – Invalid Signature Detected" a hibaüzenet.
A Windows kernel meg "ERROR_INVALID_IMAGE_HASH (577 / 0x241 / 0x80070241)" hibaüzenetet ad.
Erre most nem gondoltam, de egyébként pythonban már csináltam ilyet, a win32.dll -t húztam be.
Rövid válasz: a .dll-nek kell aláírva lennie, mert az tartalmaz natív gépikódot, az PE/COFF formátumú.
egy kérdés, hogy milyen limitációkkal lehet (ha lehet) .exe -t használni függvénykönyvtárként.
Che? Soha, sehol nem kell semmiféle .exe-t függvénykönyvtárként behúzni. A License Check teljesen függőségmentes, az ellenőrző kódja statikusan linkelődik az azt használó programba.
Az végül is valid, amint mondtam, ugye? Erre gondolok: "Illetve mi van, ha nem módosítom az eredeti .exe -t, hanem berakok a helyére egy másikat, ugyanolyan névvel?"
Nem valid. Ha lecseréled az .exe-t, akkor másik programod lesz, Photoshop helyett Notepad. Igen, a Notepad nem fogja ellenőrizni a Photoshop licenszét, de nem is fogja tudni azt, amit a Photoshop. Ennek nincs értelme.
az nyilván nem a licchk gyengesége, hanem inkább ennek a kód aláírósdi koncepciónak
A kódaláírás sem tökéletes. Nem létezik tökéletes megoldás.
De maga a secure boot-tól kezdve felépített, aláírt kernel és RÉSZBEN (és ez a fontos, hogy részben) aláírt user space programok által felépített vár mitől véd, ha nem követeli meg, hogy MINDEN alá legyen írva?
De megköveteli, hogy minden alá legyen írva. Az aláírt kernel meg ellenőrzi a felhasználói programok aláírását (vagy nem, az már nem a Secure Boot hatásköre, az csak odáig tart, hogy a kernel binárisába nem piszkálhass bele, azaz ne kapcsolhasd ki a felhasználói programok ellenőrzését). Olyan nincs, hogy RÉSZBEN aláírt, ha az aláírásellenőrzés be van kapcsolva, akkor MINDEN csakis hibátlan aláírással indítható el, annélkül semmi. Ha a Secure Boot be van kapcsolva, de a felhasználói programok ellenőrzése nem, akkor az egyáltalán nem biztonságos és csak vendor lock in-re jó, semmi másra.
Bevallom, ez rosszul esett.
Nekem is, hogy olyanok próbálják egyfolytában ócsárolni a munkámat, akik még csak fel sem fogják, mire való, még azután sem, hogy többször udvariasan elmagyaráztam (nem feltétlenül rólad beszélek).

No várj, ezt nem értem. Ahogy utánaolvastam a Secure Boot az a boot folyamatot védi:

"Secure Boot is a UEFI firmware security feature that ensures only digitally signed, trusted software—such as operating system bootloaders and drivers—can load during a computer's startup process."

Ez egy szót se szól user space alkalmazásokról, azok simán futnak mindenféle aláírás nélkül, hacsak az operációs rendszer ezt nem kényszeríti ki. Ilyen például a Microsoft AppLocker, amely:

"AppLocker helps you control which apps and files users can run. These include executable files, scripts, Windows Installer files, dynamic-link libraries (DLLs), packaged apps, and packaged app installers."

Szóval én úgy értem hogy a két dolog (boot során azt biztosítani hogy digitálisan aláírt kernel, driverek, stb. töltődjenek be vs user space-ben futó alkalmazások indíthatósága) eltér egymástól.

Mit nem látok?  

 

perszehogy ugy van. secureboot az egyik laptopom, a kernel bootol, aztan olyan appot futtatok amit akarok, akar van cert, akar nincs. de most kiprobaltam, a putty.exe-n ottvan ket alairas is. modositottam a binarist, alt+enternel mutatja hogy a cert nemjo, de vigan elindul.

ha be lenne kapcsolva valami eros vedelem akkor lehet nemfutna. de hat nincs bekapcsolva, ahogy az userek 99.9999%-nal sem.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

No várj, ezt nem értem. Ahogy utánaolvastam a Secure Boot az a boot folyamatot védi:
Megismétlem magam: "a Secure Boot hatásköre, az csak odáig tart, hogy a kernel binárisába nem piszkálhass bele, azaz ne kapcsolhasd ki a felhasználói programok ellenőrzését".
Ez egy szót se szól user space alkalmazásokról, azok simán futnak mindenféle aláírás nélkül
Megismétlem magam: "Ha a Secure Boot be van kapcsolva, de a felhasználói programok ellenőrzése nem, akkor az egyáltalán nem biztonságos és csak vendor lock in-re jó, semmi másra".
Szóval én úgy értem hogy a két dolog (boot során azt biztosítani hogy digitálisan aláírt kernel, driverek, stb. töltődjenek be vs user space-ben futó alkalmazások indíthatósága) eltér egymástól.
Megismétlem magam: "Az aláírt kernel meg ellenőrzi a felhasználói programok aláírását (vagy nem, az már nem a Secure Boot hatásköre".
Továbbá: "Ha ki akarod herélni a kispista.exe aláírásellenőrzését a kernelből, ahhoz bizony azt a kernelt kellene módosítanod, ami a Secure Boot során töltött be és szintén alá van írva (ez a kernel a Secure Boot-tal, a kispista.exe valami mással)".
Mit nem látok?
Nem tudom, mondjuk a posztjaimat?

Tehát te akkor azt mondod hogy az alkalmazás módosíthatatlanságát rábízod a környezetre. Csakhogy ezzel az a gond hogy az esetek 99.99%-ban nincs bekapcsolva hogy csak digitálisan aláírt program induljon el, de még ha be is lenne akkor a támadónak csak annyi a dolga hogy egy valid developer accounttal aláírja a módosított alkalmazást.

Illetve te valamiért kernelről beszélsz (hogy is kerülne a kispista.exe a kernelbe?) pedig a licensz kezelés alapvetően user space alkalmazásokra való. Vagy nem ez a célod?

Tehát te akkor azt mondod hogy az alkalmazás módosíthatatlanságát rábízod a környezetre.
Nem. Nem a környezetre, hanem konkrétan az alkalmazást betöltő kernelre, és nem, nem bízom rá, csak azt mondom, ez is egy lehetséges módja annak, hogy megakadályozzuk az alkalmazás módosítását.
Hogy jó megoldásnak tartom-e? Nem. De ettől még tény, hogy pontosan erre találták ki, hogy ne lehessen belenyúlkálni az alkalmazások kódjába, amin itt egyesek úgy lovagolnak, mint lelencgyerek a Zsolti bácsi farkán.
Illetve te valamiért kernelről beszélsz (hogy is kerülne a kispista.exe a kernelbe?)
Hát úgy, hogy az tölti be. A kernel az, ami beolvassa a kispista.exe-t a lemezről, a kernel az, ami kiszámolja a hash-ét, a kernel az, ami értelmezi a Program Headert (ELF) / Section Tablet (PE/COFF) / stb. és megállapítja a szegmenseket, a kernel az, ami esszerint létrehozza és elrendezi az új címteret és a kernel az, ami ellenőrzi, hogy egyezik-e az aláírt hash-sel, mielőtt átadná rá a vezérlést. (Az, hogy itt most a kernel alatt magát a core-t értjük-e vagy pedig egy kernel modult / binfmt modult / AppLock drivert / stb. az lényegtelen, ami fontos, hogy ezek kernel szinten futó cuccok és nem felhasználói szintűek.)

A kernel nagyon is könyékig benne van a kispista.exe-ben ahhoz, hogy elindíthassa (és akkor az ELF interpreter (már ha van), run-time linker, dinamikus linker stb. még a kanyarban sincsenek, ezek ugyanis már mind felhasználói szinten futnak az új címtérben, és azután indulnak, hogy kernel átadta a vezérlést a kispista.exe címterére, és az csak a legeslegutolsó lépés, hogy a végrehajtás eljut a kispista.exe fejlécében szereplő, tényleges belépési pontjára. A részletek persze eltérnek Linux és Windows alatt, de a lényegi lépések pontosan ugyanazok, a bitformátum más ELF és PE/COFF esetén, de mégis ugyanaz az infó tárolódik bennük, stb.).
a licensz kezelés alapvetően user space alkalmazásokra való. Vagy nem ez a célod?
De, csak a sok idióta itt a HUPon azon lovagol, hogy az user space alkalmazásban nem lehet licenszt ellenőrizni, mert átbillentik az if-et. Nem képesek megérteni, hogy az, hogy ne lehessen átbillenteni az if-et, egy másik tészta, és a License Checker függvénykönyvtárnak semmi köze hozzá, nem az ő dolga ezt megakadályozni.

Hogy erre rávilágítsak, jött példának a futtatható aláírása (mint lehetséges megoldás az if átbillentés megakadályozására), aminek meg iskolapéldája a Secure Boot (PE/COFF beágyazott CI tanusítvánnyal), de persze hiába, mert így sem voltak képesek felfogni a különbséget, felesleges volt megpróbálni elmagyarázni nekik bármit is...

Ahogy fentebb is írtam, én egyáltalán nem ócsároltam a munkádat. Elbandi felvetése szerintem teljesen invalid.

Én nem a licchk bármilyen vélt gyengeségéről, törhetőségéről beszélek, mert ahogy írtam, itt már a kérdés is hülyeség.

Én arról beszélek, hogy (teljesen függetlenül a licchk -től) a kód aláírás által biztosított védelemnek mik a határai.

Az egyik határa nyilván az, hogy ha a futtató/ellenörző rendszer nem megbízható, akkor a hajunkra kenhetjük az egészet, ezért kell a secure boot -tól kezdve az aláírt kernelen keresztül az összes futó szoftverkomponensnek megbízhatónak, vagyis aláírtnak lennie.

A vége viszont az, hogy ha van egy script, amit én írok, és az OS azt mondaná, hogy bocs, de nem futtatom, mert nincs aláírva, akkor erősen pislognék.

Vagyis én most a szoftver aláírási lánc limitációit, illetve a hasznosságát boncolgatom.

Az tök jó, hogy nem tudok boot vírust becsempészni, mert nem tudok a hardveresen (TPM) tárolt kulcsoknak megfelelő bootolható binárist berakni, így van esélye, hogy az OS hamarabb töltse be a vírusírtót, mint az én programomat, de nagyjából ennyi a hozadéka szerintem ennek a történetnek. Vagy van más hozadéka, amire én nem gondoltam? Ez a kérdés érdekel.

Mondom, ez teljesen független a licchk -tól! 

Form follows function.

kell a secure boot -tól kezdve az aláírt kernelen keresztül az összes futó szoftverkomponensnek megbízhatónak, vagyis aláírtnak lennie.

mutass mar nekem ilyet! sok linuxot lattam, de kb sehol nincs alairva rendszer binarisok sem. ugyhogy az nagyon speci kornyezet ahol minden ala van irva. ott meg az igenyhez van penz is, van lo've' fejlesztore es nem gitlab-rol huzott cuccal dolgoznak.

ez a project meg tanulasra tok jo!

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

mutass mar nekem ilyet! sok linuxot lattam, de kb sehol nincs alairva rendszer binarisok sem.
Az összes olyan Linux disztróban, ami támogatja a Secure Boot-ot, alá van írva mind a GRUB, mind a kernel. Méghozzá a shim hitelesítésével.
"All GRUB modules not stored in the core.img, OS kernels, ACPI tables, Device Trees, etc. have to be signed"
Ahogy fentebb is írtam, én egyáltalán nem ócsároltam a munkádat. Elbandi felvetése szerintem teljesen invalid.
Igen, tudom, bocs, csak jó sok a barom itt a HUPon, nem figyeltem eléggé, kinek válaszolok.
Az egyik határa nyilván az, hogy ha a futtató/ellenörző rendszer nem megbízható, akkor a hajunkra kenhetjük az egészet
Nyilván, de tegyük fel, hogy jó.
ezért kell a secure boot -tól kezdve az aláírt kernelen keresztül az összes futó szoftverkomponensnek megbízhatónak, vagyis aláírtnak lennie
Pontosan.
A vége viszont az, hogy ha van egy script, amit én írok, és az OS azt mondaná, hogy bocs, de nem futtatom, mert nincs aláírva, akkor erősen pislognék.
Pedig pontosan ez történik. Hacsak alá nem írod.

(A script azért túlzás szerintem, mert abban nincs natív kód, és abban így nem is lehet exploit. Az interpretere az, ami natív kód, és amiben lehet bibi meg overflow meg mittoménmi, ezért az interpreter az, aminek aláírva kell lennie, és ha egy script mégis képes hibát előidézni, akkor az az interpreter sara, tehát azt kell kijavítani, hogy beintsen a hibás scriptnek. Szerintem. Ettől függetlenül a sz332 kolléga által említett Microsoft AppLocker scripteket is alá tud írni, bár gondolom nem .bat fájlokról van itt sem szó.)

"Kernel: aláírás nélküli fájlok nem futtathatók. Csá."

Mutass már ilyen felhasználóknak szánt rendszert, amin nem indul el nem aláirt bináris.

Ha sikerült (nem fog) akkor már csak azt áruld el, hogy engem, akinek ez a hiperszuperbiztonságos, aláriatlan szoftvert nem futtató (egyébként minennapi munkára teljesen használhatatlan) rendszerben mi fog megakadályozni, mint local admint, hogy 

  1. kikapcsoljam a büdös francba ezt a hülyeséget benne
  2. telepitsek egy saját CA-t a trusted root-ba és aláirjam vele az 1 perc alatt megpatchelt binárisodat és máris kurvabiztonságos, aláirt szoftver legyen belőle

Ja semmi. (jó persze a szekúrbút, az biztos meggátol)
Vissza és tértünk az eredeti problémára, az 1 ifes bohóckodás akkor működik, ha ez az ellenőrzés nem azoknak a gépén fut, akitől meg akarod óvni a program feltörését. Bár ezt már 3-an, nulladik pillanatban is leirtuk, akkor sem fogtad fel, valószinű ezután sem fogod.

A userek gépére telepitett programokat (mint pl. adobe, AAA játékok, autocad stb-stb) ennél százszor bonyolultabb védelmek védik.

Vagy azért, mert ezen kiadók nem annyira okosak mint te és nem látják át azt a géniusz dolgot, hogy egy nyamvadt iffel meg egy titkositás ellenőrzéssel meg lehet oldalni a problémát, vagy azért mert a problémát sem érted.

Mutass már ilyen felhasználóknak szánt rendszert, amin nem indul el nem aláirt bináris.
Az összes rendszer beállítható így, Windows, Linux, macOS, stb.. Részletes útmutató (ajánlom figyelmedbe a "Application signatures required for execution" oszlopot).

Egyéb példák: AppLocker, vagy Linuxra (nincs hivatalos, csak 3rd party, de van): signelf / elf_sign_verify / linux-elf-binary-signer. Nem próbáltam, de az SELinuxnak és az AppArmournak is biztos van ilyesmije.
Ha sikerült (nem fog)
Márpedig nagyon is sikerült, úgyhogy ez beszoptad, mint Orbán a Putyin faszát.

"beállítható"

Ja, hogy úgy érted beállithatNÁ a user úgy is a gépét, hogy a te license ellenörződet ne tudja megkerülni. Teljesen reális és persze komplett szakmai baklövés, lásd lentebb.

Láttál te már applockert egyáltalán? Nyilván nem. Tudod hogy állitják be? Audit mode-ba rakják néhány hétre, összeszedik vele, hogy milyen app-okat kell whitelist-elni, majd egyszer csak azt mondják, na ezeket az appokat, ezekkel az aláirásokkal mostantól megengedem, a többit tiltom. (hogy ráadásul ez a feature el sem érhető a home usereknek, azzal már nem is akarlak mégjobban összezavarni)

Kapisgálod már a problémát? Nyilván nem. A user (már ha teljesen hülye lenne és követné az útmutatódat butaságodat), akkor a félperces patchelés után felvenné a programot (akár saját CA-val aláirva) a whitelist-elt alkalmazások közé. (ja, tudom, majd a szekúrbút megvéd!!!)

"Márpedig nagyon is sikerült, úgyhogy ez beszoptad, mint Orbán a Putyin faszát."

Orvos kéne, azt sikerült bizonyitsad, de a többi cáfolatot is ügyesen átugrottad.

Erre már csak azt tudom mondani, te atya úr isten, tényleg léteznek ekkora idióták?
Komolyan mondom, neked valami nagyon nagyon súlyos probléma van a fejedben.
A user (már ha teljesen hülye lenne és követné az útmutatódat butaságodat)
Igen, én voltam, én írtam a biztonságtechnikai útmutatót a defense.gov oldalára! Rendszeresen közli a Fehér Ház az IT-s szakmai útmutatóimat, rajtam kívül nem is hallgatnak senki másra! (szarkazmus)

Jobban belegondolva, ennyi erővel azt is kérhetnéd a usertől, hogy NE irja át a 

feature1=no

sort 

feature1=yes

sorra, mert kb ugyanannyit ér az elgondolás.

De amúgy nincs is semmi gond, csak az ellenörző rutinod mellé kell csapni a defense.gov kivonatát, hogy hogyan kell fejreállni, ha használni akarja valaki. 

Az, hogy a userek 99%-ának rendszerén nem működik, a maradék 1%-nak pedig bár elméletben működhetne, admin jogával 3 kattintás megkerülnie egy gui felületen, az tényleg senkit ne zavarjon meg.

(de hová lett a szekúrbút által védett, folyamatosan MS kulcsokkal aláirt pOLIcY ????)

Az de genya. Én arra emlékszem (az egyik gyerekkori haverom építészmérnök, tőle van, szóval nem saját infó), hogy az AutoCAD régen nem licensszel dolgozott, hanem egy kódrészletet a diszk helyett egy soros vonalra csatlakoztatott fizikai tárolóból töltött be. Ha nem volt csatlakoztatva fizikailag ez a cucc, akkor nem is töltődött be teljesen a program, és hát nyilván ezt nem lehetett a program többi részével együtt a szokásos módon lemásolni.
Na az tényleg jó, meg a Maya is. Annyira túltolta az Autodesk a licenszelést, hogy kitalálták, csinálnak hozzá egy külön licensz daemont. Ez azért "jó", mert így elég csupán egy olyan mockolt deamon, ami minden API hívásra azt válaszolja, okés, és csók, nem is kell foglalkozni semmi mással. Mindössze pár perc egy ilyen kész, működő mockolt NLM-et találni a neten, mégcsak megírni sem kell :-)

akkor meg a return 1-et kell atirni hogy mindig 0-val terjen vissza. az mar szivatosabb ha nemcsak indulaskor hanem egy random timerrel is lefut egy masik check, es az kapcsolja vissza az app allapotat unlicensed modra.

btw, olyanra nincs egyszeru megoldas, hogy a program kodot titkositja valami (eleg csak az adott funkcio kodjat), es ha van license akkor a gepikod feloldasra kerul? az mar nem egy jz/jnz tipusu crack, tobb skill kell hozza.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

akkor meg a return 1-et kell atirni hogy mindig 0-val terjen vissza.
De ez már megint a bináris gépikód módosítását feltételezi. Mégegyszer, ennek megakadályozása NEM feladata a License Checker függvénykönyvtárnak.
ha van license akkor a gepikod feloldasra kerul?
Hogy mire használod, az teljesen rajtad múlik. Tárolhatsz például egy kititkosító kódot is a licenszben (sima feature flag helyett), amivel desifrírozod a feature kódszegmensét, igen. Ez csak rajtad múlik.
az mar nem egy jz/jnz tipusu crack, tobb skill kell hozza.
Pontosan. Az ellen nem véd, de nehezebbé teszi. Ha kellően sokat nehezítesz rajta, akkor egyszerűen nem fogja megérni a kódbuzgerálás. De mégegyszer, a kódvédelem nem ennek a függvénykönyvtárnak a feladata.

Igen ez így könnyen megkerülhető, ugyanúgy mint bármely offline license ellenőrzés, csak idő függvénye. Linkelheted statikusan, szétszórhatod, elrejtheted, használhatsz obfuscatort tök mindegy. Pár perc vagy pár óra, de úgyis megtörik. Viszont a mezei user mikor megtalálja a license fájlt és átírja akkor ez jelzi. Mást nem is ígért.

( the_manni | 2026. 03. 03., k – 16:46 )

Nekem becrashel a sign. Különben gpg[1]-vel is tudsz ilyet csinálni, de persze az nem ok arra, hogy ne írja meg az ember. Külön köszönet, hogy meg is sharelted.

Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
44          return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;
(gdb) bt
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007ffff7e113d3 in __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:89
#2  0x00007ffff7db8e48 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x00007ffff7da06c9 in __GI_abort () at abort.c:77
#4  0x00007ffff7da1739 in __libc_message_impl (vma_name=vma_name@entry=0x7ffff7f22f89 "glibc: fatal", fmt=fmt@entry=0x7ffff7f265b8 "%s\n") at ../sysdeps/posix/libc_fatal.c:138
#5  0x00007ffff7e1b53e in __libc_message_wrapper (vmaname=0x7ffff7f22f89 "glibc: fatal", fmt=0x7ffff7f265b8 "%s\n") at ../include/stdio.h:203
#6  malloc_printerr (str=str@entry=0x7ffff7f28fd0 "double free or corruption (out)") at malloc.c:5359
#7  0x00007ffff7e1cee0 in _int_free_merge_chunk (av=0x7ffff7f5fac0 <main_arena>, p=0x7fffffffd320, size=17100569470855199904) at malloc.c:4438
#8  0x00007ffff7e1cf55 in _int_free_chunk (av=<optimized out>, p=<optimized out>, size=<optimized out>, have_lock=<optimized out>) at malloc.c:4386
#9  0x00005555555629e9 in main (argc=3, argv=0x7fffffffd798) at licchk.c:1798
 

A gpg-s változat:

gpg --clearsign mylicense
gpg --verify mylicense.asc

Különben gpg[1]-vel is tudsz ilyet csinálni
Persze, de azt az ellenőrzést nem tudod egyszerűen berakni a programodba (a system("gpg --verify mylicense.asc") nem valami biztonságos megoldás). Ahogy az Mbed-TLS (elég macera jól bekonfigurálni) és különösen az OpenSSL (dinamikus függőségek) linkelése sem épp leányálom, pláne nem embedded környezetben.

Pontosan ezért csináltam az Mbed-TLS-ből ezt a leszűkített változatot, amit egyáltalán nem kell linkelni, minden további függőség ki lett gyalulva belőle, és mindössze egyetlen függvényhívásra lett lebutítva a publikus API-ja is. K.I.S.S.

azt az ellenőrzést nem tudod egyszerűen berakni a programodba

Tudom, hogy ünneprontó vagyok, de létezik a gpgme library intézménye, ami pont arra való, hogy "egyszerűen belerakd a programodba". 

https://www.gnupg.org/documentation/manuals/gpgme.pdf

https://www.gnupg.org/documentation/manuals/gpgme/Verify.html

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Tudom, hogy ünneprontó vagyok, de létezik a gpgme library intézménye, ami pont arra való, hogy "egyszerűen belerakd a programodba".
Pontosítás: arra szánták, de arra pont nem jó. Tudom, mert próbáltam, az volt a legelső nekifutásom.

Miután agyfaszt kaptam tőle, jött az OpenSSL és a libcrypto. Az sem volt simacsiga, de az már (gyakorlati szempontból) sokkal használhatóbb volt. Csak épp a frissítéseknél folyton eltört a fordítása, amiből elegem lett.

Végül az Mbed-TLS-nél kötöttem ki, annak csak a fordítási környezete agyrém, maga a kód viszont kiváló minőségű, könnyen portolható, teljeskörű (nincs külső dependency-je), nagyon-nagyon rugalmasan testre szabható. A legtöbb bloatot hála égnek eleve kirakták belőle a TF-PSA-Crypto repóba, úgyhogy ez csak az alacsonyszintű, sallangmentes rész. Mondjuk rámegy jópár napod, mire megtanulod rendesen bekonfigurálni, irtó könnyű elcseszni, rengeteg a define, tele (nemegyszer hibás) függőségekkel, és nagyon tudnod kell, mit akarsz és mi micsoda, mert sok kombináció lefordul ugyan, de egyáltalán nem biztonságos. De ha ez megvan, akkor már csak a cmake-t kell kihajítani és lecserélni make-re, onnantól aztán kezesbárány, élvezet vele dolgozni. Komolyan mondom, az egyik legjobb minőségű kód, amihez valaha is szerencsém volt.

( Luckye | 2026. 03. 03., k – 21:35 )

Mi biztosítja azt, hogy egy érvényes licenszfájlt másoljon valaki máshova? 

Semmi, ez nem copy protection. Ez arra van csak, hogy van a programodhoz egy kulcs=érték lista, amit te állítasz be a felhasználódnak, és nem akarod, hogy más belenyúlkáljon, miután kiadtad neki. Ennyi, se nem több, se nem kevesebb.
Hogy mire akarod használni ezt a kulcs=érték listát, meg hogy eleve milyen kulcsokat kezel a programod és milyen formátumban akarod tárolni, az teljesen rád van bízva. Beleírhatod mondjuk annak a nevét, aki fizetett a licenszért, és ha másnál is meglátod ugyanezt a licenszt, akkor egyből tudod, ki a saras, kit kell seggberúgni / beperelni / stb.

( bzt | 2026. 03. 03., k – 22:40 )

Na, látom sokan nem értik, hogy működik a digitális hitelesítés, ezért leírom, lépésről lépésre.

1. RSA kulcspár létrehozása
A licchk genkey létrehoz egy publikus és egy privát kulcsot. Ezeket lementi a licchk.key fájlba, valamint a publikus kulcsot a licchk.h-ba is (licchk_key[]).
A programot ezután ezzel a licchk.h-val fordítják (benne a publikus kulccsal).
2. aláírás
A védendő fájl tartamáról hash készül, és ez a hash kerül titkosításra a privát kulccsal, majd pedig base64 kódoltan a fájl végéhez fűződik. Maga a tartalom nincs titkosítva, csak a 32 bájtos hash-e. Ezt a licchk sign végzi, ami szigorúan csakis a fejlesztő gépén fut, a felhasználónál soha.
3. ellenőrzés
A felhasználónál futó program betölti a fájlt, fogja a fájl végéről a base64 kódolt hasht, kititkosítja a publikus kulccsal, majd összehasonlítja, hogy egyezik-e az általa kiszámolt hash-el (ezt az mbedtls_rsa_pkcs1_verify() végzi, amit a licchk() hív).

Az aláírás előállításához szükséges a privát kulcs, de az a programban nincs meg, csak a publikus kulcs. Ezért ellenőrizni tudja, de újra aláírni már nem, az csakis a fejlesztő gépén lévő licchk.key birtokában, a licchk toollal lehetséges.
felülvágom a pubkeyt a programban
:FACEPALM: Immár kurvára sokadjára: a futtatható módosításának megakadályozása kibaszottul NEM feladata a License Checker függvénykönyvtárnak. Arra más függvénykönyvtárak valók.
Mondhatnám, de nagy balfasz ez az snq-, mert amit magyarul ír, azt se egy angol, se egy német, de még egy orosz sem érti.

Ezért elegánsan rúgjuk ki snq-t, mint macskát szarni.
homegrown crypto
Sosem lesz olyan jó, mint az RSA, pontosan ezért készült ez a függvénykönytár. De ezt is elmondtam már, meg kéne tanulni olvasni.
nem arról van szó, hogy nem értenénk
Dehogynem.
további jó vergődést
Ti vergődtök alapfogalmak megértésével, ez még a Holdról is látszik. Csak azt nem értem, miért hangoztatjátok egyfolytában, hogy mekkora idióták vagytok. Egyszer is sok lenne, úgy is tudja mindenki.
jo, hat a szabadon fityego pubkey az meg a level 3 szint. illik azt elkodolni is
A __PUBLIKUS__ kulcsot elkódolni? Oszt mi a ráknak illene ilyent művelni? Mégis, mi a fene haszna lenne annak? (Költői kérdés, felesleges válaszolnod rá, mindenki tudja már, hogy hülye vagy ehhez.)

de valaszolok, hatha a tobbiek tanulnak belole, neked ugyis mind1. 

egy csomo appnak az a torese, hogy a binarisban kicserelik a pubkeyt egy sajatra (aminek nyilvan megvan a privkulcsa), igy mar lehet barmilyen license fajlt generalni, amit boldogan elfogad. pl mikrotik, navicat, xilinx ise, stb. ezert szoktak a pubkey bajtokat "elkodolni", akar egy sima xor-ral. (bar az se sokat er :D)

dehat mit tudhatok en ilyenrol, ezeket is a szomszed sractol hallottam! ;)

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( bzt | 2026. 03. 04., sze – 10:05 )

De most komolyan, mennyire kell hülyének lenni ahhoz, hogy valaki ne legyen képes megkülönbözteti egy szöveges adatfájlt az azt feldolgozó bináris futtathatótól?
Hála égnek az ilyen "programozókat" leváltja hamarost az AI, aztán ti meg mehettek vécét pucolni a MÁVhoz és nem rontjátok tovább a HUP és magyar IT színvonalát. Brave new world, yeah!

( Elbandi v | 2026. 03. 04., sze – 10:54 )

szerintem szabadalmaztatnia kene! es eladni az adobenek, meg a tobbieknek. nem is ertem hogy a nagy cegek miert csinalnak bonyolult license megoldasokat, mikor egy ilyen pofonegyszeru megoldana mindent! :DDD

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Szerintem meg nem kéne irogatnod ide, mert már így is komplett idiótát csináltál magadból.
szabadalmaztatnia kene!
Ezt Rivest, Shamir, Aldeman szerzőknek mondd, ők alkották meg az RSA-t 1977-ben. Esetleg Fermatnak, mert a Fermat tételen alapul. De tudtommal matematikai számítás a világ semelyik táján sem szabadalmaztatható, az EU-ban egész biztos nem.
nem is ertem hogy a nagy cegek miert csinalnak bonyolult license megoldasokat
:FACEPALM: Ez pontosan a nagy cégek bonyolult license megoldása. Ez az mbedtls_rsa_pkcs1_verify() köré írt, gyakorlati használatra szánt wrapper csupán, hogy ne kelljen mindig a pepecs részletekkel szopni. Persze ismervén az értelmi képességeidet, nem meglepő, hogy ezt nem vagy képes felfogni, csak azt nem értem, miért kell egyfolytában hangoztatod, hogy hülye vagy hozzá?

( Raynes v | 2026. 03. 05., cs – 07:08 )

Nem akarok szemétkedni, de nekem úgy tűnik, hogy a kereket (PGP aláírás) találtad fel újra. De mindegy is, mert nem csak ez a gond vele, már alapvetőbb formában súlyos gondok vannak:
1) nem AI-val kódoltad
2) nem Rustban
3) nem akkuról lehúzott, szénné matricázott Macbookon a Starbucksban, live streamben is közvetítve
4) nem vetted be a transzvesztiket a projektbe és CoC-ba, ezért a jogaik sárba vannak tiporva, és automatikusan szélsőjobbosnak minősül az egész projekt
5) kalifornai kiskorúakra vonatkozó előírást sem veszed figyelembe, hogy életkor-ellenőrző API-n keresztül tudjál gondoskodni az egészséges lelki fejlődésük zavartalanságáról

“Linux isn't an OS, it's a troubleshooting sim game.” (a YouTube commenter)

LOL :-)
Értem, hogy viccelsz, de azért egy dologra reagálnék, mert hát pont ez a lényege az egésznek (nem neked írom, hanem azoknak, akik nem értették a vicced):
nekem úgy tűnik, hogy a kereket (PGP aláírás) találtad fel újra
Szándékosan nincs benne semmi újrafeltalálás, mindössze szopóroller az mbedtls API-ja, ezért egy könnyen használható, egyetlen függvényhívásból álló API lett köré rittyentve. Illetve akkor már csináltam hozzá egy parancssoros toolt, ami elvégzi a folyamat többi lépését is, kulcsgenerálást, aláírást (meg a pubkey beágyazást is, hogy még azt se kelljen copy'n'pastelni).

Hogy ez befolyásolná-e a futtatható módosítással járó kockázatot? Aligha, hiszen végső soron az mbedtls_rsa_pkcs1_verify() is egy true / false értékkel tér vissza, akárcsak a licchk(). A futtatható módosításának kivédése ugyan szükséges, de sem a License Checkernek, sem az Mbed-TLS-nek nem dolga ezzel foglalkozni.

Az meg, hogy macerás API-k köré írok könnyen illeszthető, platformfüggetlen wrapper-t, nem újdonság, lásd sdlogv, nanoalsa, openmodal, easyjpeg, de még a POSIX-UEFI is lényegében ez (bár az fordítási környezet is egyben, nemcsak lib).