64
  • who am I 7
    #64
    ezexerint....munkanélküli?
  • Sir Quno Jedi
    #63
    Tomkrúz elavult, már cserélték önjavítókódra.
  • who am I 7
    #62
    és akkor majd rámrúgja tom krúz az ajtót, és megnyomja a resetet
  • duke
    #59
    A microsoftnal gondolom ez ugy fog kinezni,mostantol az ellenorzo onjavito program fogja lefagyasztani a rendszert.Ezert majd szukseg lesz onjavitoprogram javito programra,majd kesobb az onjavitoprogram javito program javitasat egy ujabb program fogja elintezni.Es igy tovabb a vegtelensegig amig egy 20 GHz-es 100 procis gep eroforrasanak 99.999 %-t az egymas ellen hadakozo javito programok fogjak lefoglalni.Es egy bongeszo ablak tovabbra is 2 perc alatt nyilik majd meg,persze csak ha le nem fagy kozben,az explorer.
  • NEXUS6
    #58
    Másrészt előbb utóbb szerintem csak elfog indulni ebbe az irányba a számtech. Csak éppen nem feltétlenül az aktuálisan, egyetlen példányban futó programot kéne mókolni.

    Néhány (száz) kisebb-nagyobb módon eltérő példányban, párhuzamosan futó programot kéne hasonlítgatni, meg vizsgálni, hogy mikor melyik verzió mit csinál. Persze nem akkor, amikor használják a rencert és nem lenne jó, ha lefagyogatna, hanem pl éjszaka.
    Így szépen este "megálmodnák" a gépek, hogy hogyan működjenek jobban.

    (A M$-meg bezárhatna!:)
  • pasi29uk
    #57
    Azért kell mert a gyártónak tudnia kell a hiba létéről attól függetlenül, hogy kikerülhető az összeomlás ezzel programmal vagy sem.
  • Sir Quno Jedi
    #56
    Mér ne lenne?!?!? Ha az embert azé fizetik, hgy egy igen szűk aspektusát vizsgálja a szakmának, persze hogy ha jól beleássa magát csodákra képes.
  • n3whous3
    #55
    Ősszel volt a tanszékünkön, nagyon nagy ember ezen a szakterületen.
  • Sir Quno Jedi
    #54
    Itt egy fotó az új rendszerről:
  • Sir Quno Jedi
    #53
    VAGY lesznek precog error report-ok, miszerint előre megjósolja a szoftver PONTOSAN, hogy milyen hibák fordulnának majd elő és mikor, már HA jó előre ki nem javította volna őket... :DDDD
  • archelf
    #52
    Error Reporting??? Azt minek? Nem lesznek hibák, hiszen már a bekövetkezésük előtt kijavítja őket a program.

    AE
  • pasi29uk
    #51
    Error reporting tool ;)
  • Sir Quno Jedi
    #50
    Nyugika, mi értjük a problémádat. Mármint aki tervez, fejleszt, üzemeltet, karbantart, hibajavít, az biztos.

    Pl. egy pénzügyi/banki rendszerben, ahol a tranzakciók feldolgozásában tenne efféle igényes javításokat egy automata szoftver, ott még aznap hullanának a fejek (is)... :DDD
  • archelf
    #49
    És honnan tudja rendszer, hogy mondjuk egy IndexOutOfBoundsException *valójában* hol keletkezett... Attól, hogy a hiba *felmerülésének* a helyét megváltoztatja, attól még az okot nem szüntette meg. Legfeljebb elnyomja a hibát, csinál valami más hülyeséget helyette, amit úgy gondol, hogy helyes lenne.
    Ha talál 2-3 naponta egy-két ilyen hibát és "kijavítja", akkor egy-két hónap múlva az alkalmazás működésében olyan anomáliák lesznek, hogy a programozó öreganyja sem fogja kibogozni a szálakat...

    AE
  • Sir Quno Jedi
    #48
    Köhhh, nem tudom mi a bajod velem, szerencsére nem is érdekel. :D
  • roliika
    #47
    Egy olyasmiről lehet szóó, hogy van egy nagyobb rendszer...ebben van több futó valami.

    Egy program meg logol logol logol logol, és ha látja, hogy egy ismert hiba álltal állt le a a rendszer egy programja, akkor megnézi, hogy ugyanmár miért, és újra generálja a gépi kódot az ismert hibaokozó nélkül...magyarul azt kivágja belőle, és valamit betesz a helyére mert amúgy csúnya világ lenne ha nem.

    Éés az így "felfrissített" komponenst újra betolja a rendszerbe.

    Szerintem.
  • roliika
    #46
    De hisz ez egy Zeller!

    Ésss Jedinek igaza van....wuuuu wwwwwuuu... Luke..één vagyok az apááád....szóval azééé mikooo én tanultam a programolást, tanárbácsinak mondtam, hogy dejó vóóna önmódosító kódot írni..ez olyan 2005-2006 tájékán volt.

    Rám mosolygott, azt mondta felejtsem el. Háh mert ha .NET alatt mókolunk, a .NET környezet annyira nem tolerálja az önmódosító kódot.

    C/C++ ban lehet próbálkozni, ott van is rá esély ilyesmit készíteni, ha a memóba kezdünk direkt címzéssel matatni...ez még így működik is...ámde ezt meg a vírusírtók nem tolerálják.

    Merthát milyen program már az ami módosítgatja önmagát...netán trojan? Jujuj..puff lecsapunk rá.

    Én csak annyit csináltam, hogy egy dat file-ból létrejött egy exe egy algoritmus alapján, pár vírusírtó már ettől kiakadt, hogy mi az hogy egy exe darabjai vannak összekeverve valahol...van amelyik törölte van amelyik csak karanténba tette...hogy nono...aztán ez még futásidő alatt nem is kutyult saját magában.
  • n3whous3
    #45
    Mondjuk itt nem tudom milyen mélységben van ez, de tuti nem szimpla vak kódhalmaz elemzés és automatikus mestintes tanulás az adatokra, plusz kiszűrés, nem is tudná akkor normálisan akkor a javítást elvégezni szvsz
  • n3whous3
    #44
    És itt ki beszél AI-ról, a reverse-engineering és a kódelemzés egyáltalán nem esik ebbe a témába, ne akard már profinak érezni magad ebben a is. Max annyi közöd van szakmailag ehhez, hogy gépi tanulási módszerek. Esetleg olvass utána a bad smelleknek és egyéb olyan dolgoknak, ami ehhez köthető. Egy nagy rendszer esetében nagyon sok kis hiba lehet, ami tényleg egyszerűen felismerhető és esetleg módosítható automatikusan a kód, hogy jó állapotban legyen a futtatás. Estébé.
  • Sir Quno Jedi
    #43
    Futtató környezet?!?!? No látod itt kezdődnek a problémák...
  • Narxis
    #42
  • lordofchaos
    #41
    Természetesen meg lehet különböztetni a várakozástól azt ha leáll egy program futása.
    A Pachika először csak adatokat gyűjt a futásokból. Azt hogy egy program kiakadt e vagy sem a futtató környezet (ASPECTJ, RHINO, MINA, JDO) logjából szedi, ami természetesen tárolja ha egy program működése leállt. Ezeket elemzi, hogy megállapítsa mely állapotok okoztak leállást. Ezután készít csak patchet a több ezer elemzett helyes állapotból.
  • mrzed001
    #40
    Még ha ki is akadt sem lenne képes felismerni ember !
    Az a program lehet, hogy éppen adatbázis kapcsolatra vár, vagy más timeoutra, vagy emberi beavatkozásra, másik program inputjára, soros portra, vagy az egyik szál lefutására ... szóval még egy szimpla primitív win-es programnál sem lehet megállapítani, hogy az a program megfagyott, vagy másra vár.
    Service-ekről meg ugyebár ne is beszéljünk.
    Szóval nem hogy előre, hanem utólag sem lehet tudni, hogy kiakadt-e vagy sem.
  • lordofchaos
    #39
    Akkor nem értem mi a probléma. Linkeltem egy doksit is róla korábban:
    http://www.st.cs.uni-saarland.de/models/pachika/downloads/report.pdf
  • lordofchaos
    #38
    "És mit gondolsz, az a javított működő programok ki írta meg?
    Hát bizony egy programozó, nem a levegőből veszi ám ki a módosításokat (meg a Zoxigénbő)"
    Ez így igaz. Nem is állítottam az ellenkezőjét.

    Hogy időben felismeri e a "fennakadásokat" az jó kérdés. Ennyire nem ástam még bele magam, hogy hogy állapítja meg egy futásról hogy az kiakad e még mielőtt kiakad.
  • Sir Quno Jedi
    #37
    Én má' hozok popcornt is lassan.
  • mrzed001
    #36
    Most nekem magyarázod, hogy mi az a patch? [fekveröhög]
  • mrzed001
    #35
    És mit gondolsz, az a javított működő programok ki írta meg?
    Hát bizony egy programozó, nem a levegőből veszi ám ki a módosításokat (meg a Zoxigénbő).

    Ami ezt a pacsikát illeti
    "képes ezeket a későbbi súlyos fennakadásokat okozó hibákat időben felismerni és azokat automatikusan kijavítani"
    Na itt kezdődik a vasistdas. Ez az ami a lehetetlen kategória.
    Persze egy 2+2 összeadást végző függvény esetében működhet egy programon belül (persze az is nyelv függő, amit tud javítani javában azt nem egy c vagy delphi programban), így minden más esetben nem.
  • lordofchaos
    #34
    "A patch készítése során a szoftverfejlesztők bájtszintű összehasonlítást végeznek az adott fájl két verziója (az eredeti és a javított) között, és az eltérések információit tartalmazza a patch futtatható állománya. Ez a módszer lehetőséget ad nagy méretű fájlok sokkal kisebb méretű programmal történő javítására."

    http://hu.wikipedia.org/wiki/Patch

    Kezdhetsz röhögni.
  • lordofchaos
    #33
    Örülök neki hogy sikerült idáig eljutnod, akkor mehetünk tovább. A Pachika ugyanezen az alapon készít patchet a programhoz. Kivéve hogy itt Javáról lévén szó nem bitről bitre hasonlítja össze, hanem loggolja a metódushívásokat és paramétereket és ez alapján tárol jól futó és hibásan futó állapotokat.
  • lordofchaos
    #32
    Pedig maguk a patcherek így működnek, igen. A Pachikánál természetesen nem erről van szó, mert itt a példában Java kódot módosít.
  • Sir Quno Jedi
    #31
    Eljutottunk tehát egy két kódot bitről-bitre összehasonlító, majd abból különbségi kódot készítő, ill. szükség esetén visszaállító programocskához, amit egy elsőéves gimnazista "infós" is megír különösebb nehézségek nélkül. Köszönöm! :D
  • mrzed001
    #30
    Ugye nem arról beszélsz, hogy hexában összehasonlítod a két file-t és cseréled a módosításokat, mert itt helyben röhögőgörcsöt kapok.

  • lordofchaos
    #29
    Ok, ezzel 100%-osan egyetértek. Hasonlatként említettem, de igazad van, nem a legjobb, mert ez nem ismeri feltétlenül a kódot. A jó hasonlat a patcher volt és mióta utánanéztem kiderült hogy valóban így működik a Pachika, a javító része egy patcher, ami a elvégzi a módosításokat, de ő sem tudja mik azok, egyszerűen két kód különbségéből patchet készít és azzal módosítja a kódot.
  • Sir Quno Jedi
    #28
    Önmódosító programokat nem túl bonyolult írni, már a régi Amigás időkben (sőt azelőtt is) is igen nagy divat volt. De ennek az égegyadta világon SEMMI köze sincs a más programokat módosító programokhoz.

    Mindemellett az, hogy egy vírus átír egy ugrást a kód elején, nem jelenti azt, hogy "módosította" a KÓD konkrét működését. Az ugyanis továbbra sem fog mást csinálni, csak a vírus indul helyette, avagy előtte. A vírusnak segédfogalma sem lehet arról, hogy a KÓD valójában mit csinál, nem is ez a dolga. Maximum ha konkrét kód (pl. egy adott windows dll) megfertőzésére, vagy cseréjére írták, akkor tehet valamit, no de ez esetben erre írták az egészet, nem tud a vírus továbbra sem semmit, csak egy hót primitív célprogram.
  • lordofchaos
    #27
    De egyébként nem erről írtam lejjebb, hanem az önmódosító programokról, amilyenek pl. a polimorf vírusok.
    Itt olvashatsz a polimorf kódról: http://en.wikipedia.org/wiki/Polymorphic_code
    Itt sem tudja az encryptor pl. hogy mit csinál a kód, mégis módosítja és visszaállítja.
  • lordofchaos
    #26
    Abba igazad van, hogy az eredeti kódot nem változtatják meg a patcherekkel ellentétben, de mivel valószínűleg a programok legnagyobb részét nem arra szánták hogy egy részüket hozzámásolják másik programokhoz és az ugrási címeket megváltoztatva azt futtassák, ezért igen, a vírusok ha úgy vesszük átírják a programot. Megváltoztatják a futtatható állományt.
  • Sir Quno Jedi
    #25
    "A másik hogy assemblyben olyan ön vagy más programokat módosító kódot írsz, amit nem szégyellsz. Pl: vírusok. "

    Te ezt komolyan gondolod?! Hogy egy vírus az ÁTÍRJA egy tetszőleges futtatható program MŰKÖDÉSÉT, hogy homlokegyenest mást csináljon, mint amire szánták eredetileg!? Mert akkor nagyon el vagy tévedve... (én papot hívnék)
  • lordofchaos
    #24
    Akit érdekel egyébként itt leírják a működését, pontosan az a működésének a lényege amit sejtettem és leírtam: http://www.st.cs.uni-saarland.de/models/pachika/downloads/report.pdf
  • lordofchaos
    #23
    Na hát ez úgy hülyeség ahogy van.
    Ezen programok egyike sem tudja mit csinál az amiről épp a patchet készítik, mégis működnek:
    Patcher

    Én magam is írtam már patchert egy nagy rendszer részeként. Nem tudja hogy mit csinál a patchelni készült program mégis képes módosító kódot készíteni hozzá és mindez rohadtul egyszerű, ugyanis azt, hogy mire fogja módosítani is egy futtatható programból veszi. Ahogy a cikk is leírta.
    A másik hogy assemblyben olyan ön vagy más programokat módosító kódot írsz, amit nem szégyellsz. Pl: vírusok. Bár mostanában szinte csak a vírusok használják, nem egy ilyen kódot láttam anno demopartykon 1K, 4K, 64K demokban.