- This topic has 272 hozzászólás, 28 résztvevő, and was last updated 16 years, 11 months telt el by
.
-
Bejegyzés
-
Így is. 🙂
Kicsit ásd bele magad a Linux jogosultság kezelésébe, felépítésébe stb… Ha végeztél, jöhet a SELinux.
Így is. 🙂
Kicsit ásd bele magad a Linux jogosultság kezelésébe, felépítésébe stb… Ha végeztél, jöhet a SELinux.
Milyen üzleti érdekkel?
Ki csinálja a vírusokat? A Novell, vagy az Apple, hogy keresztbe tegyen a MS-nek… vagy az MS írja a vírusokat, mert kevés eladása van… vagy most mi van?ui.: az első mondat után, tulajdonképpen elvesztettem a fonalat. :))))
Milyen üzleti érdekkel?
Ki csinálja a vírusokat? A Novell, vagy az Apple, hogy keresztbe tegyen a MS-nek… vagy az MS írja a vírusokat, mert kevés eladása van… vagy most mi van?ui.: az első mondat után, tulajdonképpen elvesztettem a fonalat. :))))
Egyébként a windózos szervereket ugyanúgy nem érdemes támadni, mivel még azok is relatív nehezen törhetőek meg. A windózos kliensekre meg – tulajdonképpen – senki nem vigyáz, viszont sokan vannak… és pont ezért, mivel sokan vannak ugyanazt a célt el lehet velük érni, mert, ha egyesült erővel megtámadnak egy szervert az ugyanúgy meg fog bénulni, mintha közvetlenül azt támadnák… viszont kevesebb munka befektetésével.
Linukszra meg azért nem érdemes vírust írni, mert nem elég az, hogy kevesen vannak (bár ahhoz elegen, hogy megbénítsanak valamit) még megtörni is nehéz őket… alapból is, de még az is elmondható, hogy egy linukszos júzer (illetve a linukszos júzerek többsége) jobban odafigyel a gépére, ami megint csak megnehezíti a feladatot.
Ott vannak még a bsd, egyéb unix félék, melyekkel megint nem érdemes foglalkozni, tehát kizárásos alapon maradnak a windózos kliensek… (ill. a komolyabb „szakembereknek” bármilyen „amatőr” kézben lévő szerver)Egyébként a windózos szervereket ugyanúgy nem érdemes támadni, mivel még azok is relatív nehezen törhetőek meg. A windózos kliensekre meg – tulajdonképpen – senki nem vigyáz, viszont sokan vannak… és pont ezért, mivel sokan vannak ugyanazt a célt el lehet velük érni, mert, ha egyesült erővel megtámadnak egy szervert az ugyanúgy meg fog bénulni, mintha közvetlenül azt támadnák… viszont kevesebb munka befektetésével.
Linukszra meg azért nem érdemes vírust írni, mert nem elég az, hogy kevesen vannak (bár ahhoz elegen, hogy megbénítsanak valamit) még megtörni is nehéz őket… alapból is, de még az is elmondható, hogy egy linukszos júzer (illetve a linukszos júzerek többsége) jobban odafigyel a gépére, ami megint csak megnehezíti a feladatot.
Ott vannak még a bsd, egyéb unix félék, melyekkel megint nem érdemes foglalkozni, tehát kizárásos alapon maradnak a windózos kliensek… (ill. a komolyabb „szakembereknek” bármilyen „amatőr” kézben lévő szerver)bacsi2 wrote:A leg „elcseszettebb” (csúnyább szót akartam írni :P) problémára is találsz részletes leírást. Win alatt, ha valami értelmes dolgot akarsz csinálni (aka nem jegyzettömbbel akarsz szöveget szerkeszteni, vagy nem a solitairet szeretnéd nyomni), akkor maga a káosz fogad.Alátámaszthatom, hogy magán a windowson belül is ez a helyzet. Sok évvel ezelött, de hosszabb ideig drivereket írtam, ott „belelát” az ember a rendszerbe. Különösen egy meglehetösen központi eszköz, a billentyüzet esetében. Speciális, sokbillentyüs tasztra (is) írtam drivert. (Kezdet: win 3.1, vége: NT 4.0 … XP, bár ide csak már mint „régi berendezés install”). Ami megszerezhetö volt, azt a megbízók megszerezték, DDK, egyes forrásjogok/anyagok direktben a M$-tól.
A 3.1 alatt (akkor ez volt a legfrissebb!!!) nem létezett a „keleteurópai” taszt driver forráskód. Amint ez késöbb „mendemonda” szinten kiderült, azért nem, mert külsökkel iratták, binárisat tároltak, forrást nem… Azért kellett volna, mert az volt „átkapcsolható” a különbözö kiosztások között. Maradt a disassemblálás, annyira zavaró nem volt, hiszen a forrás is assembler volt. (Ez még OK, akkoriban) De az, hogy timerrel történt a váltás, az már nem, különösen, hogy a 3.1-ben, a WfW-ben a rendszertimer volt az egyik szük keresztmetszet, és abból egyet felzabáltak. Valójában a kód megfejtése után egyértelmüvé vált, hogy ezzel a hekkelt valamivel senki sem büszkélkedhet. Ahogyan az „extended” billentyükódokkal, illetve annak kezelésével sem. Az eredeti forráskódban benne is volt egy kommentár, angol és olasz nyelven, ami magyarul így hangzik: „Ki itt belépsz, hagyj fel minden reménnyel!” – Dante.
Az ember késöbb látta, hogy ez igaz. Volt egy klasszikus hiba pl, amikor a make / brake kódokat win event kódokká alakítják, a jobb vagy baloldali ctrl gomb elengedésekor (nem emlékszem már melyiknél) hibás a kód. Ha ezt nem így csinálod a saját driveredben, egy halom alkalmazással nehézséged lesz! (M$ alkalmazásoknál is, meg 3rd partynál is) Nohát múlt az idö, a assemblerben programozott 3.1 -es driverek helyett jöttek a C-ben megírt NT driverek. Természetesen a régi hibákkal bennük, mert a kompatibilitás kellett. És ugyanaz a gusztustalan programozási stílus, extended billentyüknél…, amire viszont semmi szükség nem volt.
Amikor az ember – másik driver – nem tudta, mit cseszett el, és kiderült, hogy semmit, csak a dinamikus tárallokáció rosszul müködött kernel módú drivereknél, amikor jött a kékhalál, és kiderült, hogy a picipuha C compilere kikapcsolt optimalizálással is optimalizált, ráadásul rosszul, …. (automatic változót felülírt, mert jobban tudta, hogy mit akarok, regiszterváltozóként kezelte) akkor végleg megtelt velük a hócipöm. … Persze debuggolni lehetett volna két géppel, körülményesen, ahogyan a M$ megadta, vagy az ember egy más cégtöl vásárolt egy (SW)eszközt, amihez csak egy gép kellett, és azon is ment. Rád´sul a kék halál helyett ilyenkor a szimbolikus debuggerben landolt, szimbolikusan visszanézhette a stack-et, imigyen a hiba kb 10 perc alatt beazonosíthatóvá vált.
Folytathatnám… és amiket leírtam – a teljesség igénye nélkül 😉 – nem „urban legend”-ek, mert saját magam tapasztalatai.
bacsi2 wrote:A leg „elcseszettebb” (csúnyább szót akartam írni :P) problémára is találsz részletes leírást. Win alatt, ha valami értelmes dolgot akarsz csinálni (aka nem jegyzettömbbel akarsz szöveget szerkeszteni, vagy nem a solitairet szeretnéd nyomni), akkor maga a káosz fogad.Alátámaszthatom, hogy magán a windowson belül is ez a helyzet. Sok évvel ezelött, de hosszabb ideig drivereket írtam, ott „belelát” az ember a rendszerbe. Különösen egy meglehetösen központi eszköz, a billentyüzet esetében. Speciális, sokbillentyüs tasztra (is) írtam drivert. (Kezdet: win 3.1, vége: NT 4.0 … XP, bár ide csak már mint „régi berendezés install”). Ami megszerezhetö volt, azt a megbízók megszerezték, DDK, egyes forrásjogok/anyagok direktben a M$-tól.
A 3.1 alatt (akkor ez volt a legfrissebb!!!) nem létezett a „keleteurópai” taszt driver forráskód. Amint ez késöbb „mendemonda” szinten kiderült, azért nem, mert külsökkel iratták, binárisat tároltak, forrást nem… Azért kellett volna, mert az volt „átkapcsolható” a különbözö kiosztások között. Maradt a disassemblálás, annyira zavaró nem volt, hiszen a forrás is assembler volt. (Ez még OK, akkoriban) De az, hogy timerrel történt a váltás, az már nem, különösen, hogy a 3.1-ben, a WfW-ben a rendszertimer volt az egyik szük keresztmetszet, és abból egyet felzabáltak. Valójában a kód megfejtése után egyértelmüvé vált, hogy ezzel a hekkelt valamivel senki sem büszkélkedhet. Ahogyan az „extended” billentyükódokkal, illetve annak kezelésével sem. Az eredeti forráskódban benne is volt egy kommentár, angol és olasz nyelven, ami magyarul így hangzik: „Ki itt belépsz, hagyj fel minden reménnyel!” – Dante.
Az ember késöbb látta, hogy ez igaz. Volt egy klasszikus hiba pl, amikor a make / brake kódokat win event kódokká alakítják, a jobb vagy baloldali ctrl gomb elengedésekor (nem emlékszem már melyiknél) hibás a kód. Ha ezt nem így csinálod a saját driveredben, egy halom alkalmazással nehézséged lesz! (M$ alkalmazásoknál is, meg 3rd partynál is) Nohát múlt az idö, a assemblerben programozott 3.1 -es driverek helyett jöttek a C-ben megírt NT driverek. Természetesen a régi hibákkal bennük, mert a kompatibilitás kellett. És ugyanaz a gusztustalan programozási stílus, extended billentyüknél…, amire viszont semmi szükség nem volt.
Amikor az ember – másik driver – nem tudta, mit cseszett el, és kiderült, hogy semmit, csak a dinamikus tárallokáció rosszul müködött kernel módú drivereknél, amikor jött a kékhalál, és kiderült, hogy a picipuha C compilere kikapcsolt optimalizálással is optimalizált, ráadásul rosszul, …. (automatic változót felülírt, mert jobban tudta, hogy mit akarok, regiszterváltozóként kezelte) akkor végleg megtelt velük a hócipöm. … Persze debuggolni lehetett volna két géppel, körülményesen, ahogyan a M$ megadta, vagy az ember egy más cégtöl vásárolt egy (SW)eszközt, amihez csak egy gép kellett, és azon is ment. Rád´sul a kék halál helyett ilyenkor a szimbolikus debuggerben landolt, szimbolikusan visszanézhette a stack-et, imigyen a hiba kb 10 perc alatt beazonosíthatóvá vált.
Folytathatnám… és amiket leírtam – a teljesség igénye nélkül 😉 – nem „urban legend”-ek, mert saját magam tapasztalatai.
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz