Adatvégrehajtást megengedő Linux kell

Kezdőlap Fórumok Programozás Adatvégrehajtást megengedő Linux kell

10 bejegyzés megtekintése - 1-10 / 10
  • Szerző
    Bejegyzés
  • #1889832
    x0
    Felhasználó

      Azt szeretném megtudni, hogy melyik nyílt forráskódú ingyenes operációs rendszer engedi meg az adatvégrehajtást? Azt tudom hogy a Windows megengedi de az nem megbízható (a megbízhatóság miatt kell hogy nyílt forráskódú legyen). Olyan programot fejlesztek ami működés közben gépi kódot állít elő és végrehajtja anélkül hogy lemezre kiírná (nem hoz létre végrehajtható file-t). Sajnos semmiképpen se tudom nélkülözni, ha nincs ilyen visszatérek a Windows-hoz. Az a feltétel hogy a kód és a dinamikus memória 1 szegmensben legyen. Mivel egy szegmens nem lehet egyszerre végrehajtható és írható is, így a CS-ben és a DS-ben levő szelektor ugyan más lesz, de a GDT-ben vagy LDT-ben a szegmens deszkriptor határozza meg a szegmens kezdőcímét ami ugyanaz kell legyen (mint ahogy Windows-on van). Debian GNU/Linux-on próbáltam de ott „Szegmens hiba”. A cc –help és az ld –help se segített. A weben fentvan a man ld(1), abban a „seg” sokszor előfordul de egyik se az, az execstack ugyan hasonló, de kipróbáltam, az se jó: „cc -z execstack dataexec.c”: futtatáskor ugyancsak „Szegmens hiba”.Lehet hogy a kernel támogatja az ilyen végrehajtható file-okat is, de az is kell hogy a linker ilyet hozzon létre. A webes man ld(1) alapján úgy tűnik ilyet nem tud létrehozni. Nekem olyan operációs rendszer kell ahol a kernel is hajlandó végrehajtani és van hozzá olyan linker ami ilyen végrehajtható file-t készít.Valami Linuxra vagy OpenSolarisra gondoltam.A félreértések elkerülése végett: ha a dinamikus memória és a kód külön szegmensben van az az NX bit nélkül is teljes mértékben megakadályozza a leendő programom működését. Tehát nem elég ha az operációs rendszer olyan régi hogy nem támogatja az NX bitet. Angol wikipédia (sajnos csak a Windows-t említi ami nekem rossz hír. Alul a linkeken az NX bitnél már említi a Linux-okat is):http://en.wikipedia.org/wiki/Data_Execution_PreventionMivel 64 bites üzemmódban PC-n nincs szegmentálás, egy 64 bites operációs rendszernél az lenne a feltétel hogy be lehessen úgy állítani hogy az én programomnál ne akadályozza meg az adatvégrehajtást az NX bittel (végrehajtástiltó bit), de mivel 32 bites CPU-m van, így 64 bites operációs rendszer nem jó.A félreértés elkerülése végett: mindenki másnak adatvégrehajtást tiltó rendszer kell, és a tiltására törekszenek. Egyedül nekem kell azt megengedő. De nekem is elég ha csak az én programomnak engedi meg. A többinél minél jobban tiltja annál jobb még számomra is, mert egyes vírusokat meggátol.Ebben a kódban a TAB mérete 4 szóköz (erre nincs szükség a kipróbálásához).Mivel nekem csak a 32 bites futási eredmények számítanak, ha 64 bites fordítóprogramunk van, állítsuk át 32 bitesre. A warning-okat hagyjuk figyelmen kívűl, csak az error számít. Fordítás:cc dataexec.cVégrehajtás:./a.outAkinek ingyenes nyílt forráskódú operációs rendszere van azt megkérem hogy próbálja ki és írják meg ide hogy ment-e neki és hogy milyen operációs rendszeren és milyen linker beállításokkal próbálta. Ha sikerült lefordítani de nem futott le és nem szegmenshiba miatt, akkor lehet hogy lefut ha úgy állítjuk be az operációs rendszert hogy az NX bittel ne akadályozza meg az adatvégrehajtást. Mivel az NX bit lapozással akadályozza meg a programvégrehajtást (Windows-on is ez van, CPU támogatás kell hozzá), ezért úgy csináltam meg hogy a kód és az adat véletlenül se lehessen 1 lapon. A lapok mérete 4 KB, 2 MB, 4 MB lehet.Magyarul: http://x0.tvn.hu/magyar.cAngolul: http://x0.tvn.hu/dataexec.cOlyan programoknál kell adatvégrehajtás mint például a .NET: ez egy képzeletbeli gép gépi kódján van. Amikor meghívunk egy rutint, akkor a .NET lefordítja a rutint és úgy hajtja végre (legalábbis Windows-on). Linuxon is van már .NET és C# is. Emulátor helyett is lehet olyan hogy lefordítja (amivel nem IBM PC kompatíbilis gép programját lehet végrehajtani, illetve Windows-, Macintosh-emulátor.Vizsla adminisztrátor azt írta a Gcc alapból így fordít. Az a problémám hogy nekem 32 bites Debian GNU/Linux-on 686-os kernellel a terminálablakos cc és a gcc se így fordít, ugyanis mindig "Szegmens hiba". Azt elfogadom hogy Windows-on így fordít.64 bites módban PC-n csak flat modell van ami nekem kell, de az én CPU-m 32 bites. Vizsla pedig 64 bitesen próbálta. Naná hogy flat modell van mikor a CPU nem is tud mást (a szegmens kezdőcímét és méretét se veszi figyelembe, az FS és GS regiszterekhez 1-1 MSR-ben megadható a szegmens kezdőcíme). Amit írt kódot abban egyébként 4 byte-os adatnak 1 byte-ot foglalt.

      #2201681
      pointux
      Felhasználó

        Szóval, akkor néhány tudnivaló:- nem futtatható adatszegmensben a windows sem futtat- ha a windows megenged valamiket, amiket a linugz nem, talán azért stabilabb és, ha áthágod őket, akkor lehet, hogy nem lesz az- az, hogy az adat valamint a kód szegmens báziscíme egyezik nem jelenti azt, hogy futtatható az adat(tehát rossz az elv, amit követsz)- az, hogy futtatható legyen egy puffered, nem kell, hogy egyezzenek a szegmensek (tehát megintcsak rossz az elv, amit követsz)- hogy egy nem futtatható szegmens futtatni akarsz, ahhoz nincs köze sem a kernelnek, sem a linkernek, így nyílván nem is találhatsz erre való leírást- a nincs szegmentálásos, és NX bites megjegyzéseidet nem is értem- a kódod alapvetően hibás- egyébként igen nagy veszélyt rejt magában, ha egy menetközben módosítható területet futtatsz (egyénként is, de leginkább, ha menetközben is módosítható)Na, akkor lássunk egy viszonylag biztonságos módszert:[bash]// definiáljunk egy gépikódotunsigned char Code [] = {

        #2201682
        x0
        Felhasználó

          Szóval nem tudom hogy honnan veszed hogy a kódom alapvetően hibás. Próbáltad már 64 bites Linuxon úgy hogy előtte kikapcsolod az adatvégrehajtás megakadályozását? Ezt gondolom a grafikus felületen lehet megtenni, kell hozzá a root jelszó. Esetleg próbáltad már futtatni akár 32 akár 64 bites Windows-on? Ott is ki kell kapcsolni előtte az adatvégrehajtás megakadályozását a Vezérlőpultban, kategórianézetben talán az energiagazdálkodásnál van, azon belül talán a rendszernél.A 32/64 bites fordítók NEAR mutatókkal dolgoznak. Semmi jelét se látom hogy FAR mutatók használatára utasítottad volna. Anélkül legfeljebb a lapozásnál állítja a jogokat.PC-n 64 bites üzemmódban nincs szegmentálás, nem tudja a CPU.Az NX bit a végrehajtás-tiltó bit, amely a laptáblázat-bejegyzésekben van. Normál esetben 4 KB-os lapok vannak és 1 lapot 4 byte ír le, abban egy bit. Egyes 32 bites CPU-k is tudják. Na ennek használatát kell előbb kikapcsolni.Ha megfigyeled, a programom tisztán NEAR mutatókkal dolgozik. Tehát az egész folyamat során a CS változatlan. Tehát még ha Windows alatt futtatom is, akkor se "nem végrehajtható" szegmenst hajt végre, hanem ugyanazt a kódszegmenst hajtja végre mint a C-ben írt rutinoknál. Én is tudom hogy még a Windows se hajt végre nem végrehajtható adatszegmenst.Tehát én 32 bites üzemmódban akarok "linear flat" modellt használni, nem 64 bitesben.Természetesen az is megoldás ha kernelhívással létrehozatok egy szegmensszelektort és FAR hívással hívom meg assembly rutinból. Ekkor nem kell hogy a kód és a dinamikus memória 1 szegmensben legyen, ez nem "linear flat" modell. A kódodat azért nem értem mert ha azok a mutatók NEAR mutatók akkor legfeljebb a laptáblázat-bejegyzéseket módosítják azok a rutinok.A programom azt ellenőrzi hogy "linear flat" modell van-e. Lehet olyan kernelt csinálni ami ilyen programot nem hajlandó végrehajtani. Hogy egy programnak milyen memóriamodellje van az a linkeléstől is függ. Hogy nálam szegmenshiba van Linuxon, abból egyértelműen következik hogy külön szegmensben van a kód és az adat. Tehát az a bizonyos a.out mindig is ezt a hibaüzenetet fogja generálni, ugyanis túlcímzi a kódszegmenst, hiszen az a pár sor nyilván nincs 4 MB. Ahhoz hogy működjön másképp kell linkelni. Mivel tisztán near mutatók vannak, fordítani nem kell másképp csak linkelni. Azt pedig én se állítottam hogy attól hogy a szegmensek báziscímei azonosak az adat futtatható lesz. Ahhoz az is kell hogy a kódszegmens mérete ami a GDT/LDT-ben van tárolva olyan nagy legyen hogy abban az adatterület is benne legyen. Ekkor ami az adatterületen van az egyben a kódterületen is van, tehát a CPU úgy érzékeli hogy a kódszegmensben levőt hajtom végre. A DS-ben levő szelektor írható szegmenset jelent, és az nem lehet végrehajtható. Tehát azért lehet a programommal egyes rendszerek esetén adatot végrehajtani, mert a CPU nem tud róla hogy az adat.Amit írtál megoldást az megy 32 bitesen is? Na mingyár ki is próbálom. Ha igen, érdekelne hogy azok a mutatók near vagy far mutatók, és ha far, akkor mivel lehet a fordítót arra utasítani hogy a * far mutatót jelentsen. Ha near, akkor meg a kódszegmens méretét megnöveli a kernel hogy átfedjen az adattal. Meg lehet hogy a laptáblázatban is engedélyezi a végrehajtást (ha eddig nem volt engedélyezve).Bár jó nagy méretet foglaltam neki, mégis nálam csak addig megy hogy RET NEAR (0xC3). Ha már beleteszem hogy i++ akkor már megint szegmenshiba. Pedig mivel DS-t semmi se módosítja ezért az i-re való hivatkozás nem okozhat szegmenshibát. Ez az i++ egyébként 32 és 64 bitesen is működik. A tesztelőprogramom angol nyelvű változatából másoltam át az i++ gépi kódját azért van angolul.

          Code:
          #include #include #include #include // These types must be 1 and 4 byte size// If the size is wrong, you must be modify (act upon to the compiler)typedef unsigned char nat08;typedef unsigned int nat20;// Execute program in an address, the function don't have any parameter and don't have result type#define dataexec(p) ((*((void (*)()) (p)))())nat20 i;int main() { nat08 *p = mmap ( NULL, 8000000, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0 ); p[0] = 0xFE; // INC p[1] = 0x04; // mod=0, 0, r/m=4: SIB byte to come (it disables RIP-relative addressing in 64 bit mode) p[2] = 0x26; // SS=0, INDEX=4 (=none), BASE=6: it's mean with mod=0: [constant] *((nat20 **) (p+3)) = &i; p[7] = 0xC3; // RET (NEAR) mprotect ( p, 8000000, PROT_EXEC | PROT_READ ); printf("It attempt execute dynamic memory.n"); for (; i < 8; ) { dataexec(p); // i++; printf("%u times executed the data what increase the counter.n", i); } return 0;}

          #2201683
          zoltan22
          Felhasználó

            A 32/64 bites fordítók NEAR mutatókkal dolgoznak. Semmi jelét se látom hogy FAR mutatók használatára utasítottad volna. Anélkül legfeljebb a lapozásnál állítja a jogokat.PC-n 64 bites üzemmódban nincs szegmentálás, nem tudja a CPU.

            Javitsatok ki, ha nem jol tudom, de mintha 32 bites modban is teljesen linearis a memoria-modell, a mutatok 32 bitesek es nincs ertelme a NEAR es FAR megkulonboztetesnek.A program elszallasaval kapcsolatban:Ahogy elnezem, amikor meghivod azt a fuggvenyt, valahogy a verem korrupta valik: gdb-ben, miutan a "dataexec(p)" ( call * %eax) lesz vegrehajtva, eltunik a "main" a verembol. Szerintem ennek a dolognak mukodnie kellene, csak par finomitas szukseges az assembler es a C kod kozott.Mas otlet: miert nem forditasz egy .so fajlt es toltod be azt dinamikusan? Talan konnyebb lenne ugy programot fejleszteni.

            #2201684
            zoltan22
            Felhasználó

              Csak most, csak nektek:az alabbi kod mukodik nalam:

              Code:
              #include #include #include #include #include int i;unsigned char instr[] = {

              #2201685
              pointux
              Felhasználó

                Nyalván, mert értelmes (létező) utasítások van az instr-ben.Megjegyzés: elvileg ez

                Code:
                ...mov 0, %eaxpop %ebpret

                megfelel ennek:

                Code:
                int ret_0 = func (); // ret_0 = 0;

                #2201686
                pointux
                Felhasználó

                  Szóval nem tudom hogy honnan veszed hogy a kódom alapvetően hibás.

                  Nemcsak a kódod, de az elveid is... leírtam pár dolgot. De ezt a p-ben lévő kódot sem igazán értem. (De nem is nézegettem, mert most nincs sok időm.)

                  Próbáltad már 64 bites Linuxon úgy hogy előtte kikapcsolod az adatvégrehajtás megakadályozását?

                  Pont ezt csinálja a kód (a buf területen).

                  Ezt gondolom a grafikus felületen lehet megtenni, kell hozzá a root jelszó. Esetleg próbáltad már futtatni akár 32 akár 64 bites Windows-on? Ott is ki kell kapcsolni előtte az adatvégrehajtás megakadályozását a Vezérlőpultban, kategórianézetben talán az energiagazdálkodásnál van, azon belül talán a rendszernél.

                  De már most megint miről beszélsz?

                  A 32/64 bites fordítók NEAR mutatókkal dolgoznak. Semmi jelét se látom hogy FAR mutatók használatára utasítottad volna. Anélkül legfeljebb a lapozásnál állítja a jogokat.

                  Ez most megint hogy jön ide? Semmi jellentősége nincs abból a szempontból, hogy tudsz-e futtatni, vagy nem.

                  PC-n 64 bites üzemmódban nincs szegmentálás, nem tudja a CPU.

                  Mi az, hogy nincs szegmentálás... vagy mi az, hogy van?

                  Az NX bit a végrehajtás-tiltó bit, amely a laptáblázat-bejegyzésekben van. Normál esetben 4 KB-os lapok vannak és 1 lapot 4 byte ír le, abban egy bit. Egyes 32 bites CPU-k is tudják. Na ennek használatát kell előbb kikapcsolni.

                  Ez most még zavarosabb.Ebben számomra keveredik a futtatás az egy MB alatti területre való lapozás/ Granularity bit?De nem értem mi köze van ennek az egészhez.

                  Ha megfigyeled, a programom tisztán NEAR mutatókkal dolgozik. Tehát az egész folyamat során a CS változatlan. Tehát még ha Windows alatt futtatom is, akkor se "nem végrehajtható" szegmenst hajt végre, hanem ugyanazt a kódszegmenst hajtja végre mint a C-ben írt rutinoknál. Én is tudom hogy még a Windows se hajt végre nem végrehajtható adatszegmenst.

                  Persze, lehet az egész adatszegmenst futtathatóvá tenni... végül is, úgyis úgyis olyan hibás kódod állítasz elő, amilyet akarsz és ez elég nagy kockázat. Ez annyiban módosul, hogy a kalózoknak pl.: elég a programod végére tenni egy kódot. (Azt hiszem a C amúgy ott tartja a globális változókat. De lehet, hogy az elején.)

                  Tehát én 32 bites üzemmódban akarok "linear flat" modellt használni, nem 64 bitesben.

                  Jó, alapvetően ezt is használsz (vagy kvázi flatot), amikor gcc-vel binárist fordítasz... ennek nincs köze sem a futtatáshoz, sem a 32/64-hez.

                  Természetesen az is megoldás ha kernelhívással létrehozatok egy szegmensszelektort és FAR hívással hívom meg assembly rutinból. Ekkor nem kell hogy a kód és a dinamikus memória 1 szegmensben legyen, ez nem "linear flat" modell. A kódodat azért nem értem mert ha azok a mutatók NEAR mutatók akkor legfeljebb a laptáblázat-bejegyzéseket módosítják azok a rutinok.

                  Még mindig nincs köze a memória modellnek ahhoz, hogy mi futtatható és mi nem.Ha elolvasod a manualt ez mindössze ennyit jelent:[man doc=man mprotect]mprotect - set protection on a region of memory[/man]És mivel (inkább nem írom le, hogy miért) csak teljes lapoknak a jogait lehet módosítani, logikus, hogy magunk is hozzuk létre a lapot, mert akkor tudjuk, hol az eleje és hol a vége.Erről szól a [man doc=man mmap][/man]

                  Amit írtál megoldást az megy 32 bitesen is? Na mingyár ki is próbálom. Ha igen, érdekelne hogy azok a mutatók near vagy far mutatók, és ha far, akkor mivel lehet a fordítót arra utasítani hogy a * far mutatót jelentsen.

                  Természetesen fut, ez mindenen fut. Azért "szabványos" függvényekkel van megoldva és nem ilyen OS, meg sajátspecifikus dolgokkal.És attól függ, hogy a program hogy fordítja. Ált. 32 bites óta a flat, vagy kvázi flat modellt használják.

                  Bár jó nagy méretet foglaltam neki, mégis nálam csak addig megy hogy RET NEAR (0xC3). Ha már beleteszem hogy i++ akkor már megint szegmenshiba.

                  Első körben az a "p" hibásnak tűnik, majd valamikor talán estefelé írok lehetőségeket.A C visszatérési értéket már írtam az előbbi postban. (Annak pl. elvileg működnie kell. Azt kipróbálhatod.)

                  #2201687
                  x0
                  Felhasználó

                    Hibás volt a gépi kód. „Inc i” helyett Inc [ESI] volt, és utána az i címe utasításként értelmezve. Meg az i-t 1 byte méretűnek vette de ez nem baj. Javítva simán lefut. Az én eredeti programom is meg az is amit vizsla kódja alapján csináltam. Egyébként az enyémben se volt rendszer-specifikus kód, csak tisztán a flat modellt teszteltem.Elnézést hogy feltartottalak titeket. Mivel az NX bittel is meg lehet akadályozni az adatvégrehajtást és az én CPU-m nem tudja az NX bitet, még annyit kérnék hogy akinek NX bitet tudó CPU-ja van nézze meg hogy be lehet-e állítani úgy hogy egy adott programnál ne akadályozza az adatvégrehajtást. Úgy is jó ha csak úgy lehet beállítani hogy egyiknél se akadályozza. Az NX a végrehajtástiltó bit. Ugyanis ha később esetleg lecserélem a gépet, mondjuk mert ez elromlik, akkor nem fogom tudni használni a programot ha még annál az 1 programnál se lehet kikapcsolni a gátlást. Nyilván root jelszó kell hozzá, valahol ilyen helyen lehet: rendszer, beállítások, adminisztráció, memóriakezelés.Az a %regiszter egyébként micsoda? Azt végképp nem értem hogy mov-nál a 0 a cél ami konstans, és a kódja is más mint amikor a 2 operandust felcserélve helyes sorrendben van.Azt majd megnézem hogy assembyl betétet tud-e valamelyik fordító, illetve többféle assembly nyelv van, majd megnézem hogy lehet Intel-stílusúra állítani (amit eddig is használtunk itt a fórumon).PC-n 64 bites üzemmódban egyszerűen nincsenek szegmensek. Csak "linear flat" modell van. A szegmensszelektorok vagyis a szegmenscímek csak a jogokat és a tulajdonságokat adják meg (mondjuk hogy hány bites üzemmód, illeszkedő-e a kód, ami a far call/jmp-nél a más jogosultságúra váltással kapcsolatos). Ez is a GDT/LDT-ben van tárolva. Tehát ezek csak jogokat és tulajdonságokat adnak meg. Egyáltalán nincs szegmensméret, és ES CS SS DS esetén a szegmenskezdet fixen 0. Ez gyakorlatilag azt jelenti hogy nincsenek szegmensek. A szegmensregiszterek és a GDT/LDT csak a jogok és a tulajdonságok beállítására szolgál. Van ugyan a GDT/LDT-ben szegmens kezdete és mérete mező, de azt 64 bites üzemmódban teljesen figyelmen kívűl hagyja a CPU. FS és GS esetén 1-1 MSR-ben kernel jogokkal (0. szint) megadható a szegmensek kezdete, de szegmensméret ott sincs. Még SWAPGS utasítás is van ami ezt cseréli. Tehát FS/GS esetén se a GDT/LDT-ből olvassa ki a szegmens kezdőcímét.Talán így érthetőbb: 32 biten van a 4 GB-os címterület. Ha a lapok 4 KB-osak, akkor ez a 4 GB 1048576 részre van osztva. Minden egyes laphoz van 4 byte a laptáblázatban, ami így tehát összesen 4 MB méretű, 1048576 darab byte-os laptáblázat-bejegyzésből áll. Minden egyes laptáblázat-bejegyzésben van egy végrehajtástiltó bit, az NX bit. Összesen tehát a 4 MB = 32 Mbit-es laptáblázatból 1 Mbit az NX bit. Ez pont arra van hogy még flat modellnél is meg lehessen akadályozni az adatvégrehajtást. Na ezért kell hogy az operációs rendszer beállítható legyen úgy hogy ne akadályozza meg. Nem tudom értelmesebben leírni. 1 bit bekapcsolása egy 4 KB-os területen akadályozza az adatvégrehajtást.

                    #2201688
                    pointux
                    Felhasználó

                      Elvileg és általában – az információim szerint – a 386-os C programok logikailag nem szegmentáltak (egyik sem), fizikailag meg mind az.Az, hogy pl. a gcc logikailag sem 32, sem 64 biten nem szegmentált azt látjuk a kódon. (Nem mintha érdemben számítana.)Tehát, amit leírtál, az bizony igaz, mind a 32, mind a 64 bites kódokra is... persze, hogy assemblerben ki mit kalózkodik.. az már 64 bites CPU-nál is az ő dolga.No, hát nem pont a laponkénti jogok beállítását mutattam? És azt is hozzátettem, hogy csak laponként lehet, és ezért kell lapot létrehozni. Az, hogy most ez hardware-es sw-es emuláció, az mellékes. (Igen, kvázi flat, mert a gyakorlatilag flatet éppúgy nem használják, mint a logikai szegmentálást.)Egyébként látod, ezért jók ezek a függvények, ha jól és mindenre meg vannak írva.

                      Code:
                      mmemory_protect () {

                      #2201689
                      zoltan22
                      Felhasználó

                        Mivel az NX bittel is meg lehet akadályozni az adatvégrehajtást és az én CPU-m nem tudja az NX bitet, még annyit kérnék hogy akinek NX bitet tudó CPU-ja van nézze meg hogy be lehet-e állítani úgy hogy egy adott programnál ne akadályozza az adatvégrehajtást. Úgy is jó ha csak úgy lehet beállítani hogy egyiknél se akadályozza. Az NX a végrehajtástiltó bit. Ugyanis ha később esetleg lecserélem a gépet, mondjuk mert ez elromlik, akkor nem fogom tudni használni a programot ha még annál az 1 programnál se lehet kikapcsolni a gátlást. Nyilván root jelszó kell hozzá, valahol ilyen helyen lehet: rendszer, beállítások, adminisztráció, memóriakezelés.

                        Gondolom vizsla gepen mukodik a kod, es latom az o processzora tamogatja az NX-t. A mprotect() fuggveny "kapcsolja ki" a vegrehajtast tilto bitet. Ha azt a fuggvenyhivast kihagyom a programbol, akkor nmeg a sajat gepemen is szegmentalasi hibaval elszall a programom.

                        Az a %regiszter egyébként micsoda? Azt végképp nem értem hogy mov-nál a 0 a cél ami konstans, és a kódja is más mint amikor a 2 operandust felcserélve helyes sorrendben van.Azt majd megnézem hogy assembyl betétet tud-e valamelyik fordító, illetve többféle assembly nyelv van, majd megnézem hogy lehet Intel-stílusúra állítani (amit eddig is használtunk itt a fórumon).

                        Erre ezt talaltam: http://ubuntuforums.org/showthread.php?t=774078Vagy az assembler kododat julon fajlba helyezetd, es leforditod peldaul nasm-vel, amelyik ismeri az intel szintaxist, majd az .o fajlokat hozzalinkeled a futtathato allomanyhoz.

                      10 bejegyzés megtekintése - 1-10 / 10
                      • Be kell jelentkezni a hozzászóláshoz.