mboost-dp1
unknown
#4
Neither do I...
Og jeg har ikke engang prøvet at læse den...
Bare lige i tilfælde af at det er "Reverse-engeneering" du ikke ved hvad er. Det går ud på at man tager et færdigt stykke elektronik, og skiller det ad, og på den måde finder ud af hvordan enheden er bygget op. I dette tilfælde en CPU.
Neither do I...
Og jeg har ikke engang prøvet at læse den...
Bare lige i tilfælde af at det er "Reverse-engeneering" du ikke ved hvad er. Det går ud på at man tager et færdigt stykke elektronik, og skiller det ad, og på den måde finder ud af hvordan enheden er bygget op. I dette tilfælde en CPU.
hmmm kunne være man skulle købe sådan et par stykker også lige tage et ekstra år på uni hvor man bare sætter sig i et lab og leger lidt :)
#4 #5 #6
Simpelt forklaret så skiller man softwaren ad.
Bedst sammenligneligt med at tage en kemisk analyse af en citronmåne, for at afgøre præcist hvilket kemiske grundsybstanser den er opbygget af.
I software sammenhæng vil man dekompilere en binær fil, og få ren assemblerkode ud af det.
Noget kun meget få rå personer nogensinde bruger mere.
Assembler svare til at programmere, ikke med kommandoer men med cpuinstruktioner direkte.
Derfor er reverse engeneering ikke særlig nemt, men nødvendig til tider.
Noget som desværre vanskeliggøres af love som DMCA og andre afskyligheder.
Simpelt forklaret så skiller man softwaren ad.
Bedst sammenligneligt med at tage en kemisk analyse af en citronmåne, for at afgøre præcist hvilket kemiske grundsybstanser den er opbygget af.
I software sammenhæng vil man dekompilere en binær fil, og få ren assemblerkode ud af det.
Noget kun meget få rå personer nogensinde bruger mere.
Assembler svare til at programmere, ikke med kommandoer men med cpuinstruktioner direkte.
Derfor er reverse engeneering ikke særlig nemt, men nødvendig til tider.
Noget som desværre vanskeliggøres af love som DMCA og andre afskyligheder.
#8
>>Assembler svare til at programmere, ikke med kommandoer men >>med cpuinstruktioner direkte.
Det passer nu ikke helt. Med forbehold for fejl vil jeg forklare det som følgende:
Det assembler kode man får fra reverse engineering ligger på opperativ systemet niveau. DVS man programmere til et opperativ system. Opperativ systemet udfører nogle instruktion direkte på ISA (ikke at forveksle med busen) niveau, og oversætter andre til en eller flere ISA niveau opperationer. På ISA niveauet oversættes kommandoerne til kommandoer som cpu'en kan forstå. Denne oversættelse kan foregå enten i software (microprogram) eller eller i hardware (man startede med at gøre det i hardware, skiftede så til software og er nu tilbage i hardware på mange arkitekturer).
--edit--
Og reverse engineering behøves ikke at foregå helt til assembler niveau, det kan også være til noget der minder om assembler niveau, f.eks. JVM instruktioner (java bytecode), eller hvis man er på windows platformen til .Net CLR instruktioner.
--/edit--
>>Assembler svare til at programmere, ikke med kommandoer men >>med cpuinstruktioner direkte.
Det passer nu ikke helt. Med forbehold for fejl vil jeg forklare det som følgende:
Det assembler kode man får fra reverse engineering ligger på opperativ systemet niveau. DVS man programmere til et opperativ system. Opperativ systemet udfører nogle instruktion direkte på ISA (ikke at forveksle med busen) niveau, og oversætter andre til en eller flere ISA niveau opperationer. På ISA niveauet oversættes kommandoerne til kommandoer som cpu'en kan forstå. Denne oversættelse kan foregå enten i software (microprogram) eller eller i hardware (man startede med at gøre det i hardware, skiftede så til software og er nu tilbage i hardware på mange arkitekturer).
--edit--
Og reverse engineering behøves ikke at foregå helt til assembler niveau, det kan også være til noget der minder om assembler niveau, f.eks. JVM instruktioner (java bytecode), eller hvis man er på windows platformen til .Net CLR instruktioner.
--/edit--
quin:
Når man reverse engineerer til assembler niveau er det til cpuinstruktioner og kalde mnemonics eller op-codes.
At CPU'en inten så deler det op i microkode igen, og smækker det igennem diverse pipelines, og andet elektronik er en helt anden sag.
Jeg ved ikke lige hvor du har det fra at assembler, skulle være til at programmere til et operativ system. For hvis den udtalelse er sand hvad er operativ systemmet så lavet i ?
Når du kompiler f.eks. et C++ program, eller når JVM'en afvikler Java Bytecode, oversættes højniveau sprogene til Assembler/Mnemoninc som så afvikles direkte af CPU'en, ligeledes er operativ systemmets binære filer også assembler.
Assembler er på lang de fleste systemmer det laveste niveau man kan programmerere i, der findes mig bekendt nogle få specialiserede CPU'er hvor du kan ændre på mikrokoden, men dette er meget unormalt.
Microkoden er forresten en form for assembler som cpu'en bruger til at dekode assembler koden med.
p.s. Assembler er en sproglig repræsentation af op-codes/mnemonics, så man i sin kode f.eks. kan skrive 'nop' istedet for $4e75, det er forresten Motorola MC680x0 assembler.
Når man reverse engineerer til assembler niveau er det til cpuinstruktioner og kalde mnemonics eller op-codes.
At CPU'en inten så deler det op i microkode igen, og smækker det igennem diverse pipelines, og andet elektronik er en helt anden sag.
Jeg ved ikke lige hvor du har det fra at assembler, skulle være til at programmere til et operativ system. For hvis den udtalelse er sand hvad er operativ systemmet så lavet i ?
Når du kompiler f.eks. et C++ program, eller når JVM'en afvikler Java Bytecode, oversættes højniveau sprogene til Assembler/Mnemoninc som så afvikles direkte af CPU'en, ligeledes er operativ systemmets binære filer også assembler.
Assembler er på lang de fleste systemmer det laveste niveau man kan programmerere i, der findes mig bekendt nogle få specialiserede CPU'er hvor du kan ændre på mikrokoden, men dette er meget unormalt.
Microkoden er forresten en form for assembler som cpu'en bruger til at dekode assembler koden med.
p.s. Assembler er en sproglig repræsentation af op-codes/mnemonics, så man i sin kode f.eks. kan skrive 'nop' istedet for $4e75, det er forresten Motorola MC680x0 assembler.
Det kan godt være at det er mig der ikke har fuldt helt med, men hvad er der specielt ved Crusoe CPU'en, og hvorfor er det vigtigt om den kan reverse-engineeres eller ej?
#10
>>Jeg ved ikke lige hvor du har det fra at assembler, skulle være til at programmere til et operativ system. For hvis den udtalelse er sand hvad er operativ systemmet så lavet i ?
Tanenbaum : structured computer organization, fourth edition side 5.
Hvis du tager et program skrevet til windows (eller linux, solaris eller et andet styresystem) og reverse engineere det så får du den kode som bliver udført på opperativ system niveau. At opperativ systemmet så udfører en nogle af opperationerne direkte på ISA niveau er en anden sag, men en stor del af dem bliver oversat.
Lad os nu lige antage engang at du har ret, og at C++ kompileret kode bliver kørt direkte ved hjælp af CPU instruktion eller at JVM bytecode bliver afviklet direkte på cpu'en. Jeg har så lige et spørgsmål til dig. Hvordan kan det være at et program som bliver kompilet med en c++ kompiler under windows så ikke kan kører under linux? Du siger jo at det blot er CPU instruktioner!
En c++ kompiler til windows oversætter til operativ system afhængige komandoer, som man kalder asembler kode. Når asembler kode afvikles oversættes det af operativ systemmet til arkitektur afhængig op codes, som måske igen oversættes af et microprogram eller en hardware til talkoder som cpu'en kan bruge.
Når man programmere et operativ system starter man med at programmere en del af systemmet på ISA (instruction set arcitecture) niveau. Dette niveau oversættes af et microprogram eller hardware. Resten af operativ systemmet bygger man oven på denne kerne. Kernen oversætte nogle kommandoer, mens andre bliver udført direkte på ISA nivauet, hvilket også er grunden til at man kalder det partiel oversættelse mellem operativ system niveau og ISA niveau. De komandoer som operativ systemmet tilbyder kalder man asembler!
>>Jeg ved ikke lige hvor du har det fra at assembler, skulle være til at programmere til et operativ system. For hvis den udtalelse er sand hvad er operativ systemmet så lavet i ?
Tanenbaum : structured computer organization, fourth edition side 5.
Hvis du tager et program skrevet til windows (eller linux, solaris eller et andet styresystem) og reverse engineere det så får du den kode som bliver udført på opperativ system niveau. At opperativ systemmet så udfører en nogle af opperationerne direkte på ISA niveau er en anden sag, men en stor del af dem bliver oversat.
Lad os nu lige antage engang at du har ret, og at C++ kompileret kode bliver kørt direkte ved hjælp af CPU instruktion eller at JVM bytecode bliver afviklet direkte på cpu'en. Jeg har så lige et spørgsmål til dig. Hvordan kan det være at et program som bliver kompilet med en c++ kompiler under windows så ikke kan kører under linux? Du siger jo at det blot er CPU instruktioner!
En c++ kompiler til windows oversætter til operativ system afhængige komandoer, som man kalder asembler kode. Når asembler kode afvikles oversættes det af operativ systemmet til arkitektur afhængig op codes, som måske igen oversættes af et microprogram eller en hardware til talkoder som cpu'en kan bruge.
Når man programmere et operativ system starter man med at programmere en del af systemmet på ISA (instruction set arcitecture) niveau. Dette niveau oversættes af et microprogram eller hardware. Resten af operativ systemmet bygger man oven på denne kerne. Kernen oversætte nogle kommandoer, mens andre bliver udført direkte på ISA nivauet, hvilket også er grunden til at man kalder det partiel oversættelse mellem operativ system niveau og ISA niveau. De komandoer som operativ systemmet tilbyder kalder man asembler!
quin:
Du spørger: Hvordan kan det være at et program som bliver kompilet med en c++ kompiler under windows så ikke kan kører under linux? Du siger jo at det blot er CPU instruktioner!
Det er da meget logisk, fordi der bliver lavet kald til operativ systemet.
Hvis du laver f.eks. en dir kommando i windows om til assembler source kode, kan du assemblere det og afvikle det på windows, men selvfølgelig kan du ikke flytte den til et andet OS, hvis der bliver lavet kald til OS'en, eller pga. hardware specifikke ting.
Men hvis det er ren assembler som ikke kalder noget OS specifik kode kan du flytte det uden problemmer.
Du siger også:
En c++ kompiler til windows oversætter til operativ system afhængige komandoer, som man kalder asembler kode. Når asembler kode afvikles oversættes det af operativ systemmet til arkitektur afhængig op codes, som måske igen oversættes af et microprogram eller en hardware til talkoder som cpu'en kan bruge.
Det passer ikke, en compiler oversætter IKKE til noget OS specifikt, den oversætter til assembler/Op-codes, men pga kald til OS'et som forresten også er assembler, så kan du ikke bare flytte en lille del uden at flytte alt.
Assembler kode er ikke system afhængige, assembler er CPU arkitektur afhængigt !! En meget meget vigtig forskel.
du siger mere:
De komandoer som operativ systemmet tilbyder kalder man asembler
Det er helt forkert.
ALLE programmer der bliver afviklet ender ALTID med at være på assembler niveau i form af mnemonics også kaldet opkoder. Dette gælder operativ system, counter strike, grep, eller driveren til dine virtual reality briller, det er ALTID assembler som CPU'en afvikler. De et operativ system tilbyder kan man kalde f.eks. metoder, funktionalitet, klasser, interfaces osv. Og alt er i assembler for at de kan afvikles, eller det liver assembler igennem en JVM.
Og du kan skrive alle dine programmer direkte i assembler, ligegyldigt om det er operativsystemmet, eller dit hjemmelavede tekstbehandlingsystem.
Følgende program:
move.w #$0010,d0
loop:
sub.w #1,d0
bne loop
rts
Er ren MC680x0 (skrevet frit fra hukommelsen) og det kører lige fint på en Amiga 500, som på en gammel Mac, eller f.eks. D voice recognition systemmer der sidder i forsvarets Martello Radar (som står på Bornholm).
Forresten tæller programmer fra 16 ned til 0.
Når man laver et operativ system behøves man slet ikke at lave noget som helst i assembler, eller ISA som du gerne vil kalde det. DU kan sagtens lave dit operativ system i f.eks. C++, hele vejen igennem. Men ligemeget hvad oversætter compileren det alligevel til assembler kode som er det eneste CPU'en forstår.
Du spørger: Hvordan kan det være at et program som bliver kompilet med en c++ kompiler under windows så ikke kan kører under linux? Du siger jo at det blot er CPU instruktioner!
Det er da meget logisk, fordi der bliver lavet kald til operativ systemet.
Hvis du laver f.eks. en dir kommando i windows om til assembler source kode, kan du assemblere det og afvikle det på windows, men selvfølgelig kan du ikke flytte den til et andet OS, hvis der bliver lavet kald til OS'en, eller pga. hardware specifikke ting.
Men hvis det er ren assembler som ikke kalder noget OS specifik kode kan du flytte det uden problemmer.
Du siger også:
En c++ kompiler til windows oversætter til operativ system afhængige komandoer, som man kalder asembler kode. Når asembler kode afvikles oversættes det af operativ systemmet til arkitektur afhængig op codes, som måske igen oversættes af et microprogram eller en hardware til talkoder som cpu'en kan bruge.
Det passer ikke, en compiler oversætter IKKE til noget OS specifikt, den oversætter til assembler/Op-codes, men pga kald til OS'et som forresten også er assembler, så kan du ikke bare flytte en lille del uden at flytte alt.
Assembler kode er ikke system afhængige, assembler er CPU arkitektur afhængigt !! En meget meget vigtig forskel.
du siger mere:
De komandoer som operativ systemmet tilbyder kalder man asembler
Det er helt forkert.
ALLE programmer der bliver afviklet ender ALTID med at være på assembler niveau i form af mnemonics også kaldet opkoder. Dette gælder operativ system, counter strike, grep, eller driveren til dine virtual reality briller, det er ALTID assembler som CPU'en afvikler. De et operativ system tilbyder kan man kalde f.eks. metoder, funktionalitet, klasser, interfaces osv. Og alt er i assembler for at de kan afvikles, eller det liver assembler igennem en JVM.
Og du kan skrive alle dine programmer direkte i assembler, ligegyldigt om det er operativsystemmet, eller dit hjemmelavede tekstbehandlingsystem.
Følgende program:
move.w #$0010,d0
loop:
sub.w #1,d0
bne loop
rts
Er ren MC680x0 (skrevet frit fra hukommelsen) og det kører lige fint på en Amiga 500, som på en gammel Mac, eller f.eks. D voice recognition systemmer der sidder i forsvarets Martello Radar (som står på Bornholm).
Forresten tæller programmer fra 16 ned til 0.
Når man laver et operativ system behøves man slet ikke at lave noget som helst i assembler, eller ISA som du gerne vil kalde det. DU kan sagtens lave dit operativ system i f.eks. C++, hele vejen igennem. Men ligemeget hvad oversætter compileren det alligevel til assembler kode som er det eneste CPU'en forstår.
#12 Crusoe er en VLIW processor (Very Long Instruction Word - ligesom Itanic), der benytter morphing software - der omformer instruktionerne i dens gæste ISA (AFAIK er det i øjeblikket i686) til dens egne native instruktioner. Rent faktisk bliver instruktionerne også grupperet således at flere instruktioner kan udføres på een gang (Crusoe har en 256bit pipepline og Astro en 512bit)
Den morphing software er lige til at skifte ud og derfor er Crusoe (Og Astro for den sags skyld) principielt ikke bundet til noget bestemt instruktionssæt.
Den morphing software er lige til at skifte ud og derfor er Crusoe (Og Astro for den sags skyld) principielt ikke bundet til noget bestemt instruktionssæt.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund