Assembly: Lære assembly sier du ? Hvorfor ?

[GeirGrusom]

Jeg er 19, blir 20 om en måned, har holdt på med VB siden jeg var rundt 10.

 

Begynte med C++ for to år siden, begynte med assembly omtrent samtidig.

 

Visual Basic er et ganske enkelt språk å holde på med, og enkelt å lære.

mange andre velger Pascal (Delphi stort sett), ditt valg.

Lykke til!

[Vaughn]

- Hacker status / høy nerdefaktor...

 

Hehe.. Dette er faktisk en av de argumentene som det er mest hold i... Gutta og jentene i "scenen" ( hei Tone ) setter assembly kunnskaper høyt, men er du sikker på at det ikke finnes bedre veier til status ?? Tilgang til kjappe datalinjer bruker å være den raskeste veien inn i scenen :wink:. Husk også at heltestatus er noe du får basert på dine handlinger, og ikke din kunnskap.

komplekst er systemene man programmerer.

Nå må jeg nesten spørre - hvilken "scene"?

 

Jeg tror de dagene hvor assembly-kunnskaper var nyttige for demoer o.l. er over, men jeg er villig til å bli motsagt.

 

Men, uansett - *hvilken* scene?

[Tr1llobite]

Nå er jo dagens kompilatorer stort sett skrevet i det språket dem skal kompilere for. (c++ kompilator er skrevet i c++, c kompilator i c.. etc)

 

Hva er dette for noe tøys? Det har INGEN betydning hvilket språk du skriver en kompilator i, og den første kompilatoren som ble skrevet var nok en Assembløy kompilator, som ble skrevet i ren maskinkode, Deretter kom C kompilatoren som mest sannsynlig ble skrevet i Assembly.

Det er ikke noe problem å skrive en C++ kompilator i Visual Basic eller Turbo Pascal, for det er kun snakk om oversettelser, du skal oversette

int x = 4;

til

DB X

XOR X, X

ADD 4, X

Eller ikke akkurat slik, men til maskinkode, og det trenger du ikke å skrive i C, Assembly eller maskinkode, du kan skrive det rett i QB.

Ehem...

 

._x:                        ; For variabelen, lagres internt som en peker
dd 0x00000000        ; Lag et double-word (32 bits integer) i filen
mov eax, [._x]         ; Fløtt det inn i eax for å adde
add eax, 4               ; Add
mov [._x], eax        ; Fløtt det tilbake igjen

 

Compilere optimizer ikke sånne ting, siden compileren ikke kan se automatisk hva variabelen brukes til (og da mener jeg selvfølgelig det med define byte).

 

Dette er vel ikke så nøye egentlig, det jo ikke et kurs heller, men det har en vesentlig forskjell i praksis. Måtte liksom bare si det :!:

[GeirGrusom]

Compilere optimizer ikke sånne ting, siden compileren ikke kan se automatisk hva variabelen brukes til (og da mener jeg selvfølgelig det med define byte).

 

Dette er vel ikke så nøye egentlig, det jo ikke et kurs heller, men det har en vesentlig forskjell i praksis. Måtte liksom bare si det

 

Riktig, det vr stort sett bare et ekstremt svakt eksempel fra min side

[Tr1llobite]

Compilere optimizer ikke sånne ting, siden compileren ikke kan se automatisk hva variabelen brukes til (og da mener jeg selvfølgelig det med define byte).

 

Dette er vel ikke så nøye egentlig, det jo ikke et kurs heller, men det har en vesentlig forskjell i praksis. Måtte liksom bare si det

 

Riktig, det vr stort sett bare et ekstremt svakt eksempel fra min side

...

 

Nå må ikke du være så selvkritisk :!:

Endret 5. september 2004 av kr1570ffz0r

[Goophy]

Hehe, morsom "artikkel", mye sant, men også noe litt tullete, som allerede har blitt diskutert.

Har selv lært meg noe Assembly for å forstå hva maskinen driver på med når den tuller rundt omkring.

 

Et par år gammel post, men hvem bryr seg.

[Codename_Paragon]

Nå var vel Unix det første OS som ble skrevet hovedsaklig i C (eller portet rettere sagt), mange andre OS ble skrevet i assembly eller macroassembly. F.eks. var VMS skrevet mye i Bliss.

 

Assemblyprogrammering brukes fortsatt mye, spesielt i embeddede systemer, maskiner som har lite RAM ( f.eks 4KB RAM på en 8-bits prosessor), som brukes der folk sjelden tenker på det: lommedisko, mobiltelefon, stereoen, motorkontroll, kassapparat osv. Her er det så lite RAM og så lite prosessorkraft at assmeblyprogrammering er rett og slett eneste utvei.

 

Legacy-systemer er et annet felt: maskinvaren er gammel, men kan ikke bygges ut (f.eks. pga. krav til sertifisering), og ny funksjonelitet skal inn.

 

Jeg har selv vært betalt for håndoptimalisere C-kode til trimmet assembly i indre løkker, og har derved spart bedriften for oppgradering av hardwaren.

 

Andre argumenter for assembly er at

- maskinvaren er så ny at en god kompilator ikke er laget ennå

- arkitekturen er så sær at høynivåspråk ikke duger (f.eks. super-harwardarkitekturer)

- en har eksisterende program i assembly og skal bare gjøre mindre endringer

- krav til sanntidsegenskaper

[danandre]

- Hacker status / høy nerdefaktor...

 

Hehe.. Dette er faktisk en av de argumentene som det er mest hold i... Gutta og jentene i "scenen" ( hei Tone ) setter assembly kunnskaper høyt, men er du sikker på at det ikke finnes bedre veier til status ?? Tilgang til kjappe datalinjer bruker å være den raskeste veien inn i scenen  :wink:. Husk også at heltestatus er noe du får basert på dine handlinger, og ikke din kunnskap.

komplekst er systemene man programmerer.

Nå må jeg nesten spørre - hvilken "scene"?

 

Jeg tror de dagene hvor assembly-kunnskaper var nyttige for demoer o.l. er over, men jeg er villig til å bli motsagt.

 

Men, uansett - *hvilken* scene?

cracker/warez-scenen selvfølgelig.

 

Er du god på ASM kan du lett gjøre om såkalte "shareware" programmer osv til registrerte fullversjoner med verktøy som Ollydbg/softice og litt patching.

 

"kjappe datalinjer" vil jo bare si at du fort blir populær hvis du klarer å hoste såkaldt 0-day warez for større grupper innenfor warez "scenen".

[drall]

Linux er mer eller mindre en kopi(klipp og lim) av den orginale Unix koden som ble utgitt(gratis) på 70-tallet, så hvorfor Linus Thorvalds får så mye av æren bak linux, forundrer meg

Hvor i all verden tar du dette tullet fra? SCO? Ken Brown? Kanskje du vil finne det interessant å se hva Prof. Andrew Tannenbaum (mannen bak minix) har å si om saken.

[Klette]

cracker/warez-scenen selvfølgelig.

 

Er du god på ASM kan du lett gjøre om såkalte "shareware" programmer osv til registrerte fullversjoner med verktøy som Ollydbg/softice og litt patching.

 

"kjappe datalinjer" vil jo bare si at du fort blir populær hvis du klarer å hoste såkaldt 0-day warez for større grupper innenfor warez "scenen".

evt demoscenen

 

Kjappe linjer er vel populært overalt

[GeirGrusom]

Hvor i all verden tar du dette tullet fra? SCO? Ken Brown? Kanskje du vil finne det interessant å se hva Prof. Andrew Tannenbaum (mannen bak minix) har å si om saken.

 

Jeg gikk utifra at læreboka og læreren min hadde rett ang. saken... er det noen skam i det? nei.

[highlander]

- Cracke spill og programmer

 

FYYY!!!! Slem gutt / jente...

 

- Skrive shellcode til exploits

 

FYYY!!!! Slem gutt / jente...

hahahahah

[Smirnoff]

Jeg dillet med 6502 og 68k assembly tilbake i de gode gamle dagene.

 

Problemet tilbake i den tid var at ofte kunne et program funke greit på en maskin , mens det bugget / ikke funket på en annen. (Snakker da om C64/Amiga). Dette var ofte p.g.a sloppy programmering selvfølgelig, og rare moddinger og extrautstyr som var koblet til maskinene. Husker jeg måtte ha Kickstart switcher på Amigaen for å få visse ting til å fungere. Noen ganger måtte jeg røske ut minnekortet også. Hehe. Det var tider det.

[GeirGrusom]

Amiga var flott, samme med Commodore egentlig...

 

Her fortsatt den ubrukelige Crystal Video fra 1984 med DOS og QBasic på...

[Tr1llobite]

Amiga var flott, samme med Commodore egentlig...

 

Her fortsatt den ubrukelige Crystal Video fra 1984 med DOS og QBasic på...

[Jaffe]

Vel, man trenger Assembler for å lage NES spill

Faktisk delvis for å lage SNES og GameBoy spill også.

[Axel``]

Om ikke så alt for lenge skifter vi til en annen prosessorteknologi, og da er det meste du kan om assembly, totalt verdiløst.

Sludder og pølsevev. Vi har hatt x86-32 i en årrekke og kommer enda til å ha den lenge. Ja, det er sant at det legges til mer funksjonalitet etter hvert (3DNow!, HT), Dette er kun et lite tillegg i kunnskapsbasen din, du må ikke starte helt på nytt.

Og når det så kommer en fletta ny arkitektur er den gamle kunnskapen langt ifra verdiløs, gammel og "utdatert" kunnskap gir ofte et godt grunnlag for å lære ny teknologi, grunnfunksjonaliteten er den samme.

 

Ser ikke mange som utlyser stillinger for antivirus spesialister, men hvem vet

Kanskje man ønsker å gjøre det for morro skyld? Noen liker å danse ballett andre å pugge opkoder, så hvorfor ikke?

 

- Skrive shellcode til exploits

 

FYYY!!!! Slem gutt / jente...

Å skrive skallkode som utnytter svakheter i programvare, for så å poste det til en åpen mailing-liste (full-disclosure) er en fin ting. Det hjelper infosec miljøet, øker kunnskapen og kravet om at svakheter og feil fikses kjappt. Det gjør faktisk verden tryggere.

 

Du glemmer å nevne at assembly er nyttig til reversert ingeniørkunst, som er livsviktig for at fri- programvare miljøet skal kunne konkurrere med det lukkede programvaremiljøet (klone biblioteker, og legge til støtte for lukkede filformater i fri programvare). Dessuten er assembler også kjekt å bruke i embedded systems, hvor prosessorkraft/minne ofte er kraftig begrenset.

 

--Axel.

Endret 12. juni 2005 av Axel``

[blackbrrd]

Det ble nevnt noe om debugging av java programmer her...

 

For det første, hvis det oppstår feil i java programmer så får man gjerne ut hvilken linje feilen oppstod på...

 

For det andre, hvis man kun har class filene så er det ikke noe problem å bruke en decompiler for å gjøre det om til fullt lesbare java filer igjen.

 

Det krever vesentlig mer erfaring for å debugge C / C++ / assembly programmer enn java...

[LonelyMan]

- Raskere programmer

 

Joda.. Det er sant.. programmene er som regel raskere... Dette fordi de kan ta seg friheten å hoppe over en del "overhead" kode som eksempelvis C kompilere legger inn... Men er denne koden uinteressant ? Som regel er dette kode som sikrer stabilitet og sikkerhet... Er du sikker på at du vil fjerne denne også ?

 

Det er tull at denne overheaden er nyttig, den overheaden du snakker om er "wrapper-overhead", ikke "system-overhead". Microsoft har allerede laget en overhead som er helt perfekt å bruke. wrapper-overhead er relatert til c libraries og er unyttig for en assembler programmerer som koder for windows systemet.

 

Dessuten er det ikke sikkert at du er så god til å optimalisere koden som en kompiler er... Faktisk så er de fleste C kompilere MEGET effektive, og det kreves utrolig mye av en programmerer for å kunne optimalisere koden like bra.

 

Det fins mange c kompilatorer, intel sine kompilatorer er de beste i skrivende øyeblikk. Og nei, det kreves ikke utrolig mye for å "optimalisere koden like bra", det kreves nøyaktig 15 sekunder å optimalisere en assembler funksjon til å være bedre enn en c++ funksjon. En av de første tingene du kan optimalisere er å eliminere overhead til funksjonene ved å definere prolog og epilog, det neste du kan gjøre er å kalle funksjoner ved hjelp av registre istedet for minnereferanser. Veldig enkel optimalisering som du kan gjøre på alle funksjoner i hele programmet. Fullstendig umulig i c++.

 

- Små filer

 

Forøvrig er det også nevneverdig at programmer på 200b fortsatt opptar ca 4-64kb når det er lagret på disk, så de eneste som virkelig har nytte av denne optimaliseringen, er de som fortsatt bruker 2400 bauds modem ( eller ja... de som har behov for å dytte inn kode i andre programmer, eksempelvis shellkode programmerere, crackere og virus programmerere ).

 

Som regel tar de 4 KB og asm programmet kan være så lavt som 1 KB hvis du merger data og koden ved hjelp av noen triks.

 

- Full kontroll over maskinen

 

Full kontroll... hva innebærer det ? Jo... Det innebærer at du faktisk må gjøre ALT... Ta for eksempel et program på 1mb... Dersom dette programmet ikke inneholder data ( bilder, musikk, ikoner, tekst etc. ) betyr det faktisk at programmet inneholder ca 262144 linjer med assembly kode ( dette er tallet baseres på at programmet har et gjennomsnitt på 4 byte pr. instruksjon, som ikke vil være langt fra sannheten ).

 

Dersom du skrev med en hastighet på en linje kode i minuttet, ville du sitte og skrive dette programmet i mer enn 182 døgn i strekk.

 

For noe vrøvl (182 døgn).

 

1: Du skriver ikke like mange instruksjoner som du finner i et c program, det du printer ut i debuggeren fra et c program er overflødig kode.

 

2: Du har biblioteker i assembly også, du skriver ikke i 182 døgn.

 

3: du har makroer i assembly, du skriver ikke i 182 døgn.

 

4. Du kan skrive like fort i assembly, til og med fortere enn i c++. I c++ har du masse biblioteker som du må lære deg, slå opp i, du må alltid lære deg wrappere, i assembly vet du at du alltid dealer med registre og et sett med standard biblioteker. Jeg vil påstå at du kan skrive fortere i assembly under noen omstendigheter, ja faktisk.

 

- Guru på debugging

 

Joda... sant nok det, men hvor lang tid tar det å debugge programmer i assembly? Spesielt hvis programmene er skrevet i Java osv... I realiteten er det få som vil betale for den tidsbruken.

 

Nå snakker du mot bedre vitende. Den erfaringen du får i debuggeren, de triksene du kan implementere (som veldig veldig få høynivå-kodere vet om) er bare fenomenalt. De triksene du kan utføre (I min kunnskap) så kan du faktisk gjøre enkelte ting som er helt umulig i c++, og disse tingene fører deg ganske nært uknekkelig kode. Jeg vil ikke avsløre hvilke triks det er snakk om, men dette kan bare gjøres i assembly.

 

- Hacker status / høy nerdefaktor...

 

Hehe.. Dette er faktisk en av de argumentene som det er mest hold i... Gutta og jentene i "scenen" ( hei Tone ) setter assembly kunnskaper høyt, men er du sikker på at det ikke finnes bedre veier til status ?? Tilgang til kjappe datalinjer bruker å være den raskeste veien inn i scenen :wink:. Husk også at heltestatus er noe du får basert på dine handlinger, og ikke din kunnskap.

Hvis du kommer til ett punkt hvor vi (vi profesjonelle asm kodere) så vil du verdsette hva du kan gjøre fremfor nerdefaktoren, men nerdefaktor følger jo naturlig med, om man skal fokusere på det eller ikke får være opp til hver enkelt, men hvis du virkelig kan asm så bryr du deg ikke døyt om det du snakker om her. Helt håpløst.

 

 

- Vil vite alt som foregår i maskinen

 

Dette er etter min mening det desidert beste argumentet for å lære seg assembly... Men ikke glem at det tar lang tid... Ny teknologi kommer dessuten hele tiden... Om ikke så alt for lenge skifter vi til en annen prosessorteknologi, og da er det meste du kan om assembly, totalt verdiløst.

 

Total vranglære. Alt du kan om assembly blir helt verdiFULLT, det du kan om asm vil være overførbart, ikke fordi instruksjonene er annerledes, men fordi du forstår arkitekturen, dessuten arbeider arkitektene for å skape noe som er overførbart og likt det gamle på en eller flere måter. Men dette er ingen hindring, det vil være en hindring hvis du ikke kan asm til å begynne med.

 

- Vil ha evnen til å analysere virus...

 

Ser ikke mange som utlyser stillinger for antivirus spesialister, men hvem vet... kansje Norman en dag har tenkt å utvide... Det å jobbe for et utenlandsk firma... Det er ikke umulig, men tradisjonellt er norsk ekspertise dyrt, og kan for eksempel kjøpes langt billigere fra land som India og Russland etc.

Microsoft har i gamle tider så vel som i moderne OS og fortfarende skriver de kritiske deler av operativsystemet i assembler. Og store deler av tredjepartsverdenen skriver fortsatt dll'er i assembly for hastighet og størrelse.

 

- Cracke spill og programmer

- Skrive shellcode til exploits

- Skrive "proffe" virus...

- Ego boost

 

Det å vite at man kan "alt" om noe er meget tilfredsstillende... men vær klar over at crackmes og lignende fort mister effekten... Overgangen til kopibeskyttelser, hacking av .gov servere og virus programmering frister veldig fort...

 

Personlig tror jeg i bunn og grunn at 90% av alle hackere, crackere og virus programmerere gjør det ene og alene for å bevise for seg selv og andre at ingen ting kan stoppe dem... Dette gir en solid ego boost. Den varer dog ikke lenge, og nye utfordringer må overvinnes for at de skal holde seg ovenpå. Jo mindre man lykkes i andre situasjoner, jo mer avhengig er man av å bevise "sitt overlegne intellekt"...

 

Dersom du fortsatt er hellig overbevist om at assembly er tingen for deg, vil jeg ønske deg lykke til!

 

- Nuxofa

 

 

Ps. Tro det eller ei, men assembly språket er faktisk av de enkleste å lære da det kun er et fåtall instruksjoner. Det som er komplekst er systemene man programmerer.

 

Det er ikke ett fåtall med instruksjoner, det er hundrevis av dem, og nylig kom ett sett med AES krypterings instruksjoner til rådighet og det flyter inn mange nye hele tiden. Du har x86 instruksjoner, mmx/sse instruksjoner, aes instruksjoner, fpu instruksjoner, og listen er veldig lang. Dette er på ingen måte lett å lære. Å kode windows api er veldig rett frem og tidkrevende, men ikke komplekst eller utfordrende. DirectX er litt utfordrende, GDI+ er også litt utfordrende, men ikke så veldig.

 

[weebl]

assembly kan være greit å kunne, driver selv å leker en del med mikrokontrollere og det kan være veldig praktisk å skrive løkker som skal utføres mye i Assembly da det kreves færre klokkesykluser å utføre en løkke i ASM enn i f.eks C