Newsgroup: it.comp.os.win.windows10
Titolo: Il "finto" ASLR di Windows

 
C'è un "problemino" nell'implementazione di ASLR che affligge windows a
partire dalla versione 8, in breve, non si tratta di un reale "Address
Space Layout Randomization"
 
https://betanews.com/2017/11/18/windows-aslr-security/
 
 
esiste un fix che consiste nell'impostare una voce nel registry, ma,
attenzione, alcune applicazioni potrebbero non digerire bene un vero
ASLR ed il risultato sarebbero dei crash inspiegabili
 
 


Si, va be
l'ASLR e' nata per tappare un buco logico di buffer overflow
Ora la cosa bella e' che MS non ha implementato una vera casualita nella 
scelta degli indirizzi.
Roba da matti,nel 2017 ci si deve ancora preoccupare dei buffer overflow

 Roba da matti,nel 2017 ci si deve ancora preoccupare dei buffer overflow
 
Perché, nel 2017 era prevista l'estinzione dei programmatori cani?
 
Enrico

 overflow
 
Non si tratta solo dell'OS :P
 

 
 
Ovvio,ha a che fare con la programmazione in generale,normalmente in C o 
assembler (lasciamo stare linguaggi vetusti come COBOL,PLI,ecc.. in 
quanto non usati in win)
 


io direi C e basta. Forse C++ che pero' non conosco.
 Un linguaggio veramente del cazzo senza strutture
serie sia nella definizione dati che nel controllo degli stessi.



Uff... "assembler" NON E' un linguaggio, "ASSEMBLY" lo è, per quanto
poi riguarda il "C" (standard), mi piacerebbe capire a cosa tu ti stia
riferendo quando scrivi che non ha strutture per la definizione dei dati
 
Ad ogni modo, per la programmazione ad "alto livello" (tipicamente
quegli applicativi desktop con i quali interagisce l'utente) ad oggi i
linguaggi citati vengono raramente utilizzati (quantomeno in ambiente
Windows), l'eccezione sono alcune applicazioni "legacy" scritte in "C"
ed altre applicazioni mantenute soltanto per motivi di compatibilità,
mentre per quanto riguarda assembly questo è di norma utilizzato solo
per quanto riguarda la scrittura di drivers o di porzioni di codice che
richiedano ottimizzazioni spinte
 
 


adesso si chiama assembly, ai miei tempi si chiamava assembler.
E forse era giusto cosi'.
Informati.

 Informati.
 
a me risulta che assembler è il programma (che traduce i mnemonici delle 
istruzioni in numeri digeribili dalla CPU) e assembly il linguaggio, e 
direi che ha pure una logica, dato che "assembler" significa appunto 
"assemblatore". Se poi hai delle fonti che dicono il contrario, postale.
 
-- 
Fri(END), Boyfri(END), Girlfri(END), Bestfri(END). Everything has an END 
except...Fam(ILY)! It Has 3 Letters that say I LOVE YOU


C e' un assembler portabile e gli OS si fanno (o si facevano?) al 99.99% 
di C ed il resto assembler
Non e' colpa del C se non  si sa usarlo
Ovviamente occorre stare attenti ed avere accortezze,ma ripeto,non  e' 
colpa del linguaggio
E' il prezzo da pagare per avere un assembler portabile
Con C++ le cose migliorano,ma anche qui,occorre sapere quello che si fa.
Certo,non ha senso paragonare C con C#,java o lo stesso C++
 
 

 
 
Si,hai ragione
Comunque nel contesto citando assembler si capisce,o si dovrebbe 
capire,se e' riferito al linguaggio od al programma pur non essendo 
propriamente corretto.
 

 Informati.
 
Non ne ho bisogno, ho scritto in codice nativo ed in assembly per
parecchio tempo e so di cosa sto parlando, credo che chi si debba
informare sia tu
 
https://en.wikipedia.org/wiki/Assembly_language#Assembler
 
 
tornando al "C", ti ripeto la domanda, cosa intendevi quando hai
affermato che non ha strutture per la definizione dei dati ?
 
 



che si possa capire è un conto, che sia corretto è un altro, confondere
assembly (il linguaggio) con assembler (il compilatore) è indice di
scarsa conoscenza dell'argomento, non che sia un peccato mortale, ci
mancherebbe, solo che siccome stiamo discutendo di informatica, credo
sia opportuno essere precisi
 
 


Quello che ho sostenuto e' che la differenziazione e' avvenuta
10-15 anni fa, nel linguaggio comune ante terzo millennio, ovvero
da parte di chi l'informatica l'ha creata esisteva il solo
termine assembler riferito sia al compilatore che al linguaggio.
il sofismo e' venuto dopo.


ma secondo te, quando dici C intendi il linguaggio o il compilatore?
E adesso ci spaparanziamo dalle risate.

 formato nativo (il cosiddetto "linguaggio macchina")
 
Sempre ?
da quanti anni ti occupi di informatica?
Io dal '74.


Si, però anche confondere un assembler con un compilatore, è indice di 
scarsa conoscenza dell'argomento... ;-)


 
"un compilatore è un programma che traduce una serie di istruzioni 
scritte in un determinato linguaggo di programmazione (codice sorgente) 
in istruzioni di un altro linguaggio (codice oggeto)"
 
quindi pare corretto definire l'assembler un compilatore.


 
 
Wikipedia può dire quel che vuole.
IO (ho cominciato nel '79 a paciugare con i computer, un Univac a schede 
perforate...) ho sempre fatto una prima passata con il compiler e poi, 
il file risultato obj, veniva fornito all'assembler per ottenere un 
eseguibile. Su Minc (si, era un computer, della Digital... :-) ), PDP11, 
VAX, sistemi HP vari assortiti, IBM6150, PC... un po' con tutti i vari 
sistemi operativi, il sistema era quello.
Confesso di non usare un compilatore da... coff, coff... anni, ma citare 
wikipedia come se fossero le tavole della legge consegnate a Mosé, 
francamente, lascia il tempo che trova.

 Io dal '74.
 
Non male, però vedi, questo tuo saltar fuori con il classico "lei non
sa chi sono io", non è granchè costruttivo, specie su usenet; anzi, a
dirla tutta è piuttosto controproducente, sembrerebbe quasi che tu stia
in qualche modo tentando di intimidirmi (non che sia così, in questo
momento sto sorridendo) e, sinceramente, la cosa non gioca granchè a
tuo favore
 
Ma torniamo in argomento; da un lato hai ragione, mi spiego, l'assembly
si è *sempre* chiamato in questo modo, solo che, da un certo periodo,
in ITALIA, vuoi per ignoranza, vuoi per scarsa conoscenza dell'inglese,
c'è stato chi ha iniziato a chiamarlo erroneamente "assembler", ossia
facendo riferimento con lo stesso termine sia al compilatore usato per
trasformare i codici mnemonici in codice binario, sia al linguaggio
stesso; non credo sia un peccato capitale, basterebbe ammettere di aver
sbagliato e via; non è che per una cosa del genere si viene condannati
alla fucilazione o chissà cosa
 
Spero con questo di aver risposto a quanto hai scritto, ora, ti
pregherei, cortesemente, di rispondere alla domanda che ti ho fatto ed
alla quale non hai ancora dato risposta, ossia



che i dati non sono "strutturati" come ad esempio in Pascal.
e che e' possibile scrivendo del codice schifoso uscire
da un array ad esempio e quindi provocare l'overrun di memoria.
Non molto diverso da quanto potresti combinare con cattivo
codice scritto in "assembly" (contento?).
Cosa che con compilatori di alto livello diventa molto ma
molto piu' improbabile.



L'assembler *E'* il compilatore del linguaggio assembly, in pratica
traduce i codici mnemonici in codice binario (e non solo, visto che le
versioni successive di vari assembler hanno anche implementato tutta
una serie di caratteristiche aggiuntive tipo l'inclusione di files, la
definizione di costanti e macro ed altro ancora)
 
Per dire, facciamo un esempio usando il vecchio "debug" 
 
0D6B:0100 31C0          XOR     AX,AX
0D6B:0102 89C3          MOV     BX,AX
0D6B:0104 89C2          MOV     DX,AX
0D6B:0106 89C6          MOV     SI,AX
0D6B:0108 89C7          MOV     DI,AX
0D6B:010A 8EC0          MOV     ES,AX
0D6B:010C FA            CLI
0D6B:010D F2            REPNZ
0D6B:010E AA            STOSB
0D6B:010F EA0000FFFF    JMP     FFFF:0000
0D6B:0114 90            NOP
0D6B:0115 EBF8          JMP     010F
 
le prime due colonne (06DB:0100...) indicano l'indirizzo di memoria sul
quale si sta lavorando, la terza colonna (31C0...) rappresenta
l'istruzione in formato nativo (machine code), le successive colonne
sono invece le istruzioni in formato mnemonico; in breve, nel caso di
un sorgente in assembly quello che avresti sarebbe qualcosa del tipo
 
  XOR     AX,AX
  MOV     BX,AX
  MOV     DX,AX
  MOV     SI,AX
  MOV     DI,AX
  MOV     ES,AX
  CLI
  REPNZ
  STOSB
reboot:  
  JMP     FFFF:0000
  NOP
  JMP     reboot
 
il codice di cui sopra, dato in pasto ad un assembler, verrebbe poi
convertito in una sequenza di bytes che, in esadecimale, sarebbe
qualcosa del genere
 
D6B:0100  31 C0 89 C3 89 C2 89 C6-89 C7 8E C0 FA F2 AA EA
D6B:0110  00 00 FF FF 90 EB F8 6F-5D 0D 0A 43 34 00 5A 0D
D6B:0120  5D 0D
 
in pratica la rappresentazione in codici binari del "listato" assembly,
ossia in codici mnemonici, visto sopra, ad esempio la sequenza di
codici mnemonici "XOR AX, AX" in assembly Intel viene tradotta nella
sequenza di bytes 31 C0; ovviamente nessuno ti obbliga ad usare
assembly, puoi anche usare un qualsiasi programma che ti permetta di
scrivere codici binari e scrivere direttamente 31 C0, ma ovviamente,
usare i codici mnemonici ti permette di avere un sorgente più facile da
leggere
 
chiaro ora ?
 
 

 francamente, lascia il tempo che trova.
 
lungi da me il prendere per oro colato quello che scrive wikipedia, ma 
per quanto se ne possa dubitare, la definizione del caso calza 
perfettamente.
 
In ogni caso se non ti fidi di wikipedia, c'è la Treccani:
 
"In informatica (per traduz. dell’ingl. compiler), programma che, nei 
calcolatori elettronici digitali, provvede alla traduzione automatica 
delle istruzioni dai linguaggi simbolici in linguaggio di macchina"


 a Mosé, francamente, lascia il tempo che trova.
 
non l'ho mica fatto, ho citato wikipedia come semplice riferimento, ma
non è l'unico, se non sei convinto, ti basterà cercare informazioni;
del resto è questo il bello di internet (che una volta non c'era e ti
dovevi sbattere... poi ok, dopo, molto dopo, sono arrivate le BBS, e
poi ARPANET... ma quella è un'altra storia ;-D)
 
 
 
 
 

 codice scritto in "assembly" 
 
o con cattivo codice in generale, il fatto che alcuni "runtime" mettano
delle pezze al cattivo codice, non è un buon motivo per considerare un
dato linguaggio migliore di un altro, d'altronde non è mai stata una
questione di quale "strumento" usare, ma solo di usarlo bene; un pezzo
di codice scritto male, continuerà ad essere un pezzo di codice scritto
male indipendentemente dal linguaggio
 
 

 delle istruzioni dai linguaggi simbolici in linguaggio di macchina"
 
che poi, se vogliamo, ad oggi non è del tutto vero, ad esempio nel caso
dei linguaggi in ambiente .NET (ma non solo, lo cito solo perchè siamo
in un gruppo dedicato a windows), il file risultante da una
compilazione non è un vero eseguibile ma un metafile in un formato che
viene successivamente caricato ed eseguito dal runtime, quindi in
questo caso non si può parlare di traduzione in "linguaggio macchina",
d'altro canto, nel caso di .NET (e di altri ambienti) non sarebbe
neanche corretto parlare di compilatore ma si dovrebbe utilizzare il
termine "metacompilatore" :)
 
Il che mi fa venire in mente il vecchio "Small-C compiler" (che c'entra
solo tangenzialmente, ma tant'è :D)
 
https://en.wikipedia.org/wiki/Small-C
 
 
https://github.com/ncb85/SmallC-85
 
 
che permetteva di scrivere codice in "C" e che poi trasformava tale
codice in assembly, a quel punto, per ottenere un eseguibile era
necessario dare in pasto il risultato ad un assembler (e, nel caso del
DOS ad un linker) per ottenere finalmente il file binario eseguibile
 
 

 ma molto piu' improbabile.
 
Non dovrebbe dipendere solo dal linguaggio? In C alcuni
controlli a tempo di compilazione non si possono fare
nemmeno in linea di principio e quindi anche il
compilatore ideale non può fare nessun controllo sui 
limiti degli indici.
 
ciao!
 
Apx.
 
 
-- 
"Pompieri? Presto, venite, la mia casa sta bruciando"
"OK, quando ha avuto origine il fuoco?"
"Nel paleolitico, però sbrigatevi"
 

> Non dovrebbe dipendere solo dal linguaggio?
 
ehm, chiaramente dovrebbe essere compilato; so che 
esistono interpreti del C e una implementazione 
interpretata può sempre fare i controlli.



Anche prima. Ahimé, ho anche programmato in codici binari. :-(
 
Diciamo che io non faccio rientrare l'assembler ed il linker nel novero 
dei compilatori, mentre voi definite meta-compilatore ciò che io chiamo 
compilatore?


usando lo stesso termine non significa necessariamente non  sapere la 
differenza tra assemblatore e linguaggio
 


Il linguaggio