Newsgroup: it.politica
Titolo: Mi era sfuggita questa perla del nostro cicap

>più efficiente, ma molto più complicato da programmare.
Ecco, ora qui qualcuno dovrebbe spiegare all'incompetente,
che implementare un algoritmo ricorsivo tramite ciclo for
non è sempre possibile. Perchè la ricorsività è una
caratteristica intrinseca dell'algoritmo e non è sempre
detto che sia convertibile in iteratività (ciclo for).
In secondo luogo, qualcuno dovrebbe spiegare al troll,
che quando si cerca di trasformare un algoritmo ricorsivo
serio in un algoritmo iterativo, ammesso che sia possibile,
ci si scontra con la necessità di implementare
la pila tramite malloc/free durante il ciclo
for (per contenere i dati per gli step parziali che devono
essere recuperati se i tentativi in un certo ramo
falliscono..), e questo fa sì che il programma si
carichi l'overhead della chiamata a malloc()/free()
(si noti che allocare dati in stack come variabili
locali non richiede overhead, mentre eseguire una
malloc() assolutamente sì, a causa della necessità
di eseguire l'sbrk() ).
Risultato: un algoritmo ricorsivo che viene riscritto
come iterativo (ciclo for), salvo casi particolarissimi
e banali (calcolo fattoriale) non solo diventa molto
più difficile da scrivere.. ma diventa anche più lento,
perchè ti devi caricare l'overhead di malloc e free.
Devo dire la verità: la pochezza tecnica che sta
venendo fuori da queste pagine di cicap è
semplicemente incredibile.
Questo lo devono mandare all'ITIS, altro che
venire a giudicare professionalmente me.

Pegasus crunched.
Che ti dicevo, Cicap?
Non poteva resistere ancora a lungo!
ROTFL! 


Silenzio, pezzaccio di merda senza valore.
S.I.L.E.N.Z.I.O. ho detto.
Tu non hai "resistito" nel costruire addirittura un intero NG
pur di scassare il cazzo a Pegasus, un tizio che in fin dei
conti non t' aveva fatto nulla.
Ne di fare tante altre "belle" cosette allo scopo di non dargli
tregua.
E di piu' : non contento, vieni a scrivere che e' lui a starti
appiccicato, quando tu non fai altro. E questo post ne e' una
ulteriore conferma.
Sei una MERDA, un individuo psicotico che dovrebbe essere
investito da un autobus e poi far retromarcia e ripassargli sopra
ancora.
Vanaco' : NON VALI UN CAZZO, e stai tranquillo che se ne sono
accorti tutto qui.

 Si
--------------------------------------------------------
EBBENE SI ! HO MENTITO ! VABBE' ? Ahhhh !
Ho voluto assaggiare il BRIVIDO della
menzogna, come fai TU tutti i santi
giorni (o quasi)
(me vie' da ride ...)
Ho MENTITO !!!!! Una volta. La prima.
1)
Ma vivaddio, io almeno non pubblico i dati
personali della gente a scopo diffamatorio.
D' accordo con altri, poi.
2)
E poi la soddisfazione di vederti fare le
statistiche per "beccarmi" la voi mette ?
"e che ora e' 0,11 ?" Ma  !!!
3)
Me so' divertito un mondo, giuro.
E' BELLO mentire e  farvi ravanare a 1000 km
orari per beccarmi !
Questa l' ho buttata la senza pensarci, ma
ho scoperto il gusto della menzogna.
Le prossime me le studiero' SCIENTIFICAMENTE
e QUINDI saro' PERICOLOSISSIMO.
Eheheheheh ...
------------------------------------------------------------
Bravo Pugne', faje vede' a 'sti quattro coministi der cazzo
di quale pasta semo fatti noantri.
Altro che Rapisarda, tu sei er mejo de 'sta fogna di ennegi'.
Spaccamoie er culo Pugne', sono con te!
1-7-2010

 EBBENE SI ! HO MENTITO ! VABBE' ? Ahhhh !
Prenderti per il culo non e' nemmeno lontanamente paragonabile al
comportamento ossessivo-persecutorio che per ANNI E ANNI
(a ancora continui, imperterrito) hai tenuto con quel ragazzo,
(e pure con l' aiuto di altri) che ripeto :
NON T' HA FATTO NIENTE.
E piu' ci stava male, e te lo faceva capire, e piu' tu tignavi.
Ecchecazzo.  Cattiveria, astio allo stato puro.
CATTIVERIA, senza ragione, a gratis.
Questa tua reazione scomposta CONFERMA ancora una volta
la MERDA che sei. Uno stronzo che se avesse un comportamento
simile (mutatis mutandis) fuori , nella vita reale, sarebbe evitato
come la peste, se non gonfiato di botte. E perfino qui sei stato
plonkato da parecchi di "casa tua", unico caso nell' NG.

Pegasus :
[cut]
Tira fuori le ciliegine e vai a scrivere su un ng appropriato 
cio' che hai scritto qui riferendoti al kernel di linux:
<pegghy>
Ripeto il concetto: un kernel che mi assegna una quantità
randomica di stack ad ogni lancio di processo
finisce fuori dalla finestra in qualsiasi università.
</pegghy>

 Pren
HOP! HOP! HOP! HOP!
http://i26.tinypic.com/2zztfdt.jpg

 ha scritto nel messaggio news:i2m505$7fq$1...@news.albasani.net...

Vedi Andrea, tu non hai capito una cosa.
Tutti ormai qui hanno capito che tu sei
solo un malato di mente.
Ma non per modo di dire.
Uno squilibrato vero.
E quindi, qualsiasi cosa tu possa scrivere
o meno su di me, ottieni poco perchč
la gente non prende in considerazione
le dichiarazioni di uno squilibrato.
Ora, scrivi pure tutto quello che vuoi....
come ti ripeto: non mi fai nč caldo, nč
freddo.

 freddo.
HOP! HOP! HOP! HOP!
http://groups.google.com/group/pegasus-fan-club/browse_thread/thread/a8d678737bc3806e
" In questo momento io sono qui con altre persone
 e stiamo monitorando il ng, ricavando gli IP,
 controllando le email e tutto il necessario..."
HOP! 


BUAHAHHAHAHAHHHAHHAAAHAHAAHAAHAAHAH!!! 

 venire a giudicare professionalmente me.
Si vede che rodi come un castoro. Sei anche tutto paonazzo in volto?
P.S.
allora questo video su Windows 7 arriva o ti sei già rimangiato tutto?


Delinquente!
Napoletano di merda e spacciatore ....
Mafioso e camorrista...
La pagherai cara... o se la pagherai cara!


Via Borsa a calci?
ROTFL!!!!
(e CRUUUUUUUUUUUUUUUUUNCH! Brucia culetto, eh? CI GODO!) 

 continuare sullo stesso? Ti piace insozzare il NG?
Delinquente testè segnalato all'abuse per SPAM!
Provvedete tutti. 

>allora questo video su Windows 7 arriva o ti sei già rimangiato tutto?
Non ho mai parlato di video.
Ho parlato di un .exe che la gente può scaricare
e provare.
Così ti dò l'ennesimo calcio in faccia, stavolta
violentissimo.


Date: Tue, 27 Jul 2010 10:30:34 GMT
NNTP-Posting-Host: 151.53.139.69
X-Complaints-To: 
ab...@libero.it
X-Trace: 
twister2.libero.it
 1280226634 151.53.139.69 (Tue, 27 Jul 2010 
12:30:34 MET DST)
NNTP-Posting-Date: Tue, 27 Jul 2010 12:30:34 MET DST
Organization: [Infostrada]
Xref: 
news.albasani.net
 it.politica:1607291

 violentissimo.
ROTFL
http://groups.google.it/group/it.politica/msg/569fdfd75eb93056?hl=it
"Altrimenti la provo io, faccio un bel video e te
lo sbatto in faccia. "
Che fai, ritratti di già?
HOP HOP HOP HOP HOP
Che figura de MMMMMMMMMMMMERDA!
P.S.
l'eseguibile te lo puoi ficcare su per il culo perchè non prova un bel
nulla. Il fatto che tu ora parli di eseguibile significa una cosa
sola: hai fatto la prova e ti sei accorto di essere in torto marcio :)

 continuare sullo stesso? Ti piace insozzare il NG?
Scusa se mi intrometto ma no, guarda che ha ragione.
(e infatti t' ha risposto per filo e per segno)
Esistono alcuni problemi (senza arrivare agli NP
completi, per carita') che possono essere risolti solo
con la ricorsione.
Certo, hai ragione : si pone un problema di limitazione
della risorsa - stack.
Ma devi considerare che in ambito scientifico questo
problema e' superabile : a certi livelli di programmazione
la gestione dello stack non viene certo data al sistema
operativo ! Viene gestita direttamente dall' applicazione.
Il fatto e' che "vivete" in due mondi diversi, te e lui.
Io al posto vostro ne approfitterei per imparare a
vicenda, invece di scannarvi come due matti.
(si lo so, stavolta ha cominciato lui, te ne do atto)
Oh, sia chiaro : il consiglio vale anche per Pegasus.

 con la ricorsione.
Tipo?
-- 
Strike: il disonesto di IP
"Un autonomo che non paga parte di tasse non ruba soldi a nessuno" (Strike)
Strike: "Mi spiace, ma ti sei rovinato con le tue mani, quel "di loro 
volontà" non mi appartiene, l'hai aggiunto tu per sottolineare che non 
li ha mandati via Soru, ma sei un gran bugiardo."
La realta': 
http://groups.google.it/group/it.politica/msg/e5db751d1af1a427?hl=it

 con la ricorsione.
Ah si?
Pensa che io sapevo che esisteva un teorema che recita più o meno
così: "Dato un programma ricorsivo, esiste un programma iterativo che
calcola la stessa funzione."
E pensa che qui qualcuno s'è pure preso la briga di dimostrarlo:
http://www.di.unito.it/~ronchi/didattica/FONDAMENTI/recursion.pdf
Che strano, eh?
Ma quanto fesso sei, ragadeanale?!? Già spari cazzate a 1000 quendo
scrivi di cose che o bene o male riesci vagamente a capire, ma quando
scrivi di cose di cui non sai nulla, raggiungi davvero dei vertici di
idiozia inarrivabili...
Pure i problemi NP completi vai a citare - a vanvera...
Tu sì che sei NP: Notevolmente Pirla!
P.


Non c'entra niente.
Ha solo paura.
Ha portato avanti una quantità impressionante
di imbrogliamenti continui di carte in tavola.
Ieri io la prova l'ho fatta. E lui lo sa.
Guarda infatti come si è immediatamente
parato il sedere:
[cite cicap]
P.S.
l'eseguibile te lo puoi ficcare su per il culo perchè non prova un bel
nulla. Il fatto che tu ora parli di eseguibile significa una cosa
sola: hai fatto la prova e ti sei accorto di essere in torto marcio :)
[/cite cicap]
E' solo un povero pagliaccio di una
disonestà inaudita.
Ora posto sorgenti ed eseguibile e
potrete provare voi stessi su
Windows 7.
Così la verità verrà a galla (anche se di
sicuro si inventerà qualche altra cosa).

così: "Dato un programma ricorsivo, esiste un programma iterativo >che calcola la stessa funzione."
Con *risolti solo* intendevo in relazione alla complessita'.
(La quale e' calcolabile con esattezza).
Non intendevo certo in senso ASSOLUTO.
Esempio iper-semplificato : se per tradurre un programma
ricorsivo con 100 istruzioni debbo usarne 250.000, supposto
che una mente umana sia in grado di farlo in un tempo
ragionevole, anche non considerando gli errori, il resto
viene da se : o ricorsione o niente. Chiaro ?
Un esempio analogo, anche se apparentemente diverso :
e' famoso a questo riguardo il teorema della colorazione
delle mappe. La dimostrazione che per colorare qualunque
mappa sono sufficienti solo 4 colori era solo un problema
di calcolo. Ma fintanto che non fu' possibile usare potenti
elaboratori, nessuno era in grado di eseguirli. NESSUNO.
Il teorema e' stato dimostrato infatti solo con l' utilizzo
di queste macchine.
Cioe' voglio dire : anche la mente umana e' una risorsa
limitata, non solo lo "stack" o la quantita' di memoria.
Capisci ?
Riguardo agli NP completi, in effetti li ho citati solo
per evidenziare il fatto che non c'e' bisogno di arrivare
a complessita' irrisolvibili per dire che e' necessaria
la ricorsione. Tutto qui.
Tu sai cosa sono i problemi NP completi ?
Riguardo al resto (insulti e ciarpame vario) a me
indicano solo che sei un tipetto astioso, evidentemente
per i troppi calcioni in faccia che hai ricevuto, che
ricevi ora e che riceverai in futuro dal sottoscritto.
Non ti conviene farmi la guerra, dammi retta. Con me
ci sbatti il grugno, sempre e comunque.
Per il semplice fatto che sono molto piu' astuto e
soprattutto molto piu' intelligente di te :
ti pare che mi sarei esposto in questo modo, se non
avessi ben chiare le idee in proposito ?
Vai in pace, figliolo.

> modo efficiente solo tramite ricorsione.
Cos'e, devo mettermi a ridere subito?
La ricorsione e' molto elegante ma per nulla efficiente.
*Tutti* gli algoritmi ricorsivi si possono codificare
in modo piu' efficiente con loop.
E oltretutto, la ricorsione e' comunista.
a.

 sicuro si inventerà qualche altra cosa).
Vabbe' ma mo' basta, dai ...
Se sa che questi so' cosi', che ce voi fa' ?
Pure te ! Dalle stelle alle stalle !
Bono, stai bono, damme retta.
Tra l' altro un culo cosi' per dimostrare
che cicap e' quello che e' ? Basta "parlarci"
5 minuti per capirlo, non c'e' bisogno di
agitarsi tanto ... Da retta a ragadeanale tuo.
Cia'.

 (La quale e' calcolabile con esattezza).
Hai scritto una montagna di fregnacce. Ma per ora mi interessa questo:
come calcoli con esattezza la complessità di un programma?

 Se sa che questi so' cosi', che ce voi fa' ?
Quindi secondo te l'eseguibile  che Pegasus vorrebbe postare (ma manco
quello ha postato comunque) potrebbe essere una prova sensata?
Potresti spiegarci di grazia, per quale motivo? E potresti spiegarci
per quale motivo prima parla di video e poi vuole postare solo
l'eseguibile?
Ti do io una spiegazione (l'unica plausibile): dopo aver verificato
che su W7 l'ASLR gli da totalmente torto, ha deciso di barare postando
un eseguibile taroccato. Il video infatti è più difficile da
taroccare. Semplice e lineare.

 (e infatti t' ha risposto per filo e per segno)
Ha torto marcio.
E questo lo puo' capire chiunque, non occorre essere informatici.
E' da giorni che va in giro a raccontare che 'linux randomizza lo 
stack'.
Chiunque e dico chiunque, puo' comprendere che se anche fosse vero (e 
non lo e') che si ha randomizzazione dovuta a overflow, cio' non 
significa che 'normalmente lo stack venga randomizzato ad ogni sessione 
per ogni programma'.
A casa mia, prima di trovare una soluzione, mi pongo seriamente la 
domanda se il problema (bug) esiste perche' trovare magnifiche 
soluzioni a problemi inesistenti equivale a fare le seghe alle zanzare.
E questo, ripeto, e' una questione di problem solving, e perdersi in 
supercazzole non cambia i termini della discussione.
Se il SO assegnasse NORMALMENTE a cazzo lo stack, non girerebbe 
assolutamente niente, manco le librerie del SO.
Questo bischero a pile, con quel cazzo di programmino, e' come se 
avesse scoperto che l'auto senza olio grippa.
E questo sarebbe poco, vuol convincere chiunque che e' un bug del 
motore.

>taroccare. Semplice e lineare.
Verrà postato
- progetto Dev C++
- sorgente
- eseguibile
e chiunque in 3 minuti 3 può ricompilare il progetto
Dev C++ e vedere che non c'è nulla di taroccato.
Puoi andare, grazie.
(Sto finendo di lavorare su una cosa qui a casa e
poi provvedo subito...)


Tu sei un coglione.
Quello si legge dai dati postati dal tuo amicone cicap,
e da una cretinissima operazione chiamata sottrazione.
Senza contare il fatto che eseguendo un programma
ricorsivo, il tuo amicone cicap asserisce che il programma
prima esce dopo k ricorsioni, e poi esce dopo j
ricorsioni con k DIVERSO da j.
Lo dice cicap, non io.
Come, di fronte a questa evidenza banale banale,
tu possa continuare a sbattere su "se anche fosse
vero (e non lo č)", te lo sai soltanto tu.
O siete cretini, o siete fuori di testa, o siete in
malafede.
Io propendo per la 3.

 ha scritto nel messaggionews:bd9325b3-bc12-4b94...@w30g2000vbs.googlegroups.com...

NEEEEEEEEEEEE.
Guarda i tuoi trucchetti con me non funzionano: ero stato
assolutamente preciso, devi usare Visual Studio 2010 Trial.
Da quanto ho letto, su Windows l'ASLR viene abilitato in fase di
linking, e dubito che Dev C++ abbia questa opzione. Visual Studio 2005
e 2010 ce l'hanno:
http://msdn.microsoft.com/en-us/library/bb384887.aspx

 malafede.
Potresti spiegarci perchè randomizzare FP dovrebbe avere un effetto
differente rispetto alla randomizzazione di SP? Attendiamo...

Quindi secondo te l'eseguibile  che Pegasus vorrebbe postare (ma >manco quello ha postato comunque) potrebbe essere una prova sensata?
Ricordo la tua generosita' quando t' ho chiesto un
consiglio, sai ? E' per questo che ci vado sempre
piano con te. Tu no con me (non sempre) ma non ha
importanza. Sei un bravo ragazzo, lo so.
Una volta hai *perfino* ammesso d' esserti sbagliato !
Una cosa INCREDIBILE, almeno qui. Da apprezzare. E
lo apprezzo.
Dunque :
Io facevo un discorso molto piu' generale, mi pare.
Nessuno mette in discussione qui il fatto che tu
sia un bravo programmatore. Io sono un programmatore,
non bravo come te, ma abbastanza da riconoscere che
sei preparato.
Semplicemente, secondo me, ragionate su piani
diversi, come ho scritto nell' altro post.
Vedi pure la mia risposta ad Ampelio.
Ciao. Mo' scappo che c' ho una magagna che non
finisce mai : una applicazione che gira con
access 2003 non gira con il 2007 e non si capisce
il perche'.

 Ciao. Mo' scappo [...]
Mah

 Non intendevo certo in senso ASSOLUTO.
Ah, quindi dovremmo pure cambiare il senso all'italiano per venire
incontro alle tue arrampicate sugli specchi?
Guarda che la frase "Esistono alcuni problemi (senza arrivare agli NP
completi, per carita') che possono essere risolti solo con la
ricorsione" ha un significato preciso nella nostra lingua: se volevi
dire che possono esere risolti n modo efficace (cosa comunque dubbia)
solo con la ricorsione, avresti dovuto scrivere: ""Esistono alcuni
problemi (senza arrivare agli NP completi, per carita') che possono
essere risolti efficacemente solo con la ricorsione", ma non è ciò che
hai scritto...
Ora vai in pace, ragade.
P.

>Guarda i tuoi trucchetti con me non funzionano: ero stato
Non c'è nessun trucchetto.
Qui la questione è che tu sostenevi che sotto
Windows 7, poichè è attivo l'ASLR, i
processi si vedono assegnati stack diversi
di volta in volta.
E sostenevi anche di avere fatto la prova.
La prova l'ho fatta anch'io.
Non solo: nella tua allegra impostazione,
questo comportamento lo giudicavi pure
normale (da cui seguivano altre allegre
rigirate di frittata, come lo stack che deve
essere poco utilizzato dal programmatore
e bla bla bla bla bla...)
Ed ecco qui il risultato:
http://rapidshare.com/files/409394346/CheckStack.zip
Provatelo su Windows 7.
Vedrete che il processo viene terminato **sempre**
dopo un numero identico di ricorsioni,
ovvero che lo stack assegnato è sempre
lo stesso.
Il che ci dice, in modo devastante, che stavolta
avevo ragione io.
Ma aggiungo anche che una prova fatta con il
Dev-C++ è anche più significativa di una fatta
con il Visual Studio. Infatti, ci dice come il
sistema operativo si comporta ***di default***,
per esempio con tutti i programmi che vengono
compilati e linkati con strumenti normali come
il gcc ed ld.
Potrebbe essere anche che il Visual Studio
abbia una opzione speciale per abilitare l'ASLR
e che questa comporti la randomicità dello stack
(non ci credo, devo controllare e per questo
appena ho tempo scarico Visual Studio
Express).
Ma il punto importante è che questa randomicità
della size dello stack (se c'è, dubito molto), è
una caratteristica non voluta, ***ed infatti***,
per il normale codice binario di Win32/Dos,
Windows 7 continua ad assegnare uno stack
di dimensioni predefinite all'avvio.
Aggiungo anche, per maggiore chiarezza, che:
a) dai tempi del Dos, la quantità di stack assegnata
ad un processo viene stabilita da un apposito
campo nell'eseguibile (non così sotto Unix).
Nei sistemi Dos/Win32 non si è **mai**
parlato di randomizzazione della size dello
stack.
b) che debba essere randomizzata la size
dello stack ***non*** risulta riportato in
alcun documento sull'ASLR: tutti parlano
di randomizzazione della posizione dello
stack e non della size.
Pegasus prende la mira
GOAALLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL

 Pegasus prende la mira
E piglia un doppio calcione nel culo dall'arbitro!
Ora sparisci, essere insulso.

>parliamo della stessa cosa.
No, minus, tutta questa discussione è iniziata
perchè tu hai cianciato di "comportamento
aleatorio" per un pezzo di codice C
che fa un buffer overflow.
Siccome ti è stato fatto notare che nell'
ambito informatico di aleatorio non c'è
un tubo (un programma che crasha si
spera che lo faccia sempre in modo
riproducibile, perchè sennò non potremmo
fare il debug) ti sei precipitato a cercare
un qualcosa, un qualsiasi cosa, che
potesse infilarti dentro a forza la
tua alea.
Ed hai trovato l'ASLR.
Ovviamente, hai usato una condizione
particolare di un sistema operativo,
per giustificare il fatto che "undefined
behaviour" in qualche libro di C di
15 anni fa tu lo possa tradurre con
"aleatorio" a causa di una tecnologia
sviluppata 2 anni fa (e certo... con l'ASLR
abbiamo trovato il modo di infilarci
dentro l'alea e salvare capra e cavoli).
Per ora, quello che vediamo è che per
il codice standard che gira sotto Windows
(per standard intendo compilato con i
normali strumenti che si trovano in rete),
il tuo comportamento aleatorio
semplicemente non esiste: lo stack
resta sempre lo stesso.
A questo punto, possiamo pensare che
anche con i software Windows compilati
con compilatori più vecchi di Visual
Studio 2010, il comportamento randomico
non c'è.
Riassumendo, il tuo "comportamento aleatorio",
se realmente esiste, sta diventando una
condizione sempre più particolare e sempre
più ridotta solo ad alcuni casi di sistema
operativo.
Adesso vedrò se con Visual Studio,
abilitando questa opzione, compare uno
stack randomico, ma dubito proprio
moltissimo.
Ancora ti ricordo che:
a) non c'è mezza pubblicazione come mezza
che parli di randomizzazione della size dello
stack
b) l'unica prova sarebbe una verifica che
hai fatto tu (ma non posti il video perchè
non hai la videocamera, ROFTL)
c) uno stack randomico renderebbe
"aleatorio" il comportamento anche di
software corretti, non solo di software
errati
d) nelle pubblicazioni che abbiamo visto,
riguardo a Windows, si parla sempre di
randomizzazione di BP e non di SP.
Per adesso ho finito, grazie.

 resta sempre lo stesso.
ROTFL, sei patetico.
Tanto per dimostrare che parlavamo di comportamento con ASLR attivo
ecco solo alcuni dei tanti stralci tratti dai post di Pegasus, il
bugiardo:
-------------
http://www.sysdream.org/articles/Analysis-of-Microsoft-Windows-Vista'.
..
Spiacente, T-Stupid, in Vista funziona diversamente
da Linux.
Prego infatti notare che lì è EBP che viene randomizzato
e non SP (come dicevo io).
-------------
-------------
E, a riprova di quello che ho scritto, sotto Windows Vista
le cose vanno proprio in questo modo:
http://www.sysdream.org/articles/Analysis-of-Microsoft-Windows-Vista'.
..
[...]
Come diceva Pegasus.
-------------
-------------
Il chè conferma in pieno che, per qualche oscuro ed
incomprensibile motivo, sul kernel Linux, a differenza
di quanto avviene su Windows, è la posizione di SP
ad essere randomizzata (e non EBP come su Windows).
-------------
-------------
[cite cicap]
E bravo Peggy!
Va in stack overflow con valori **differenti** di x. Dopo aver
disabilitato l'ASLR invece va in overflow sempre nello stesso punto.
[/cite cicap]
Questo ****NON**** deve succedere con una
implementazione corretta dell'ASLR (ossia, quando
metti l'offset ma la size dello stack rimane la stessa).
Chiaro ora ?
-------------
Come potete vedere, Piggy sosteneva che un'implementazione corretta di
ASLR (come a suo dire quella di Windows) dovesse far funzionare il
programma diversamente. E invece non è così perchè su Windows 7 si
comporta esattamente come su Linux. Per lo stesso moitivo aveva
tacciato il kernel Linux di essere BUGGATO.
Invece è stato semplicemente sconfessato su tutta la linea, e ora non
può poroprio ammetterrlo.
ROOOOOOOOOOOOOOOOOOOOOOOOOOOOOTFL
...sei uno spettacolo di indecenza.

 Io propendo per la 3.
Io penso invece che tu ne faccia una battaglia personale e che questo 
ti impedisca di avere la lucidita' necessaria.

 perchè ti devi caricare l'overhead di malloc e free
Senti, io non è che ci capisca tanto ma per quel poco che ne so questi 
problemi di programmazione non erano stati risolti già da parecchio? 
Cioè...io quando avevo Win95/98 in media il crash avveniva dopo 8-12 minuti 
dall'avvio, con XP ne avviene uno ogni 3-4 settimane. Quindi io, da profano, 
non capisco dove tu voglia arrivare a parare 

 operativo ! Viene gestita direttamente dall' applicazione
Quindi confermi che è cretino?

 ng, da parte di entrambi i tuoi antagonisti.
Ove non si fosse capito, questa è la babbiona roditrice sicula che morfa. 


Senti, X05, parliamoci chiaro.
Dammi torto direttamente per partito preso,
anche quando scrivo che 2+2 fa 4,
e non parliamone più.
Stai diventando semplicemente patetico nel
fare finta di non capire la questione semplice
e chiara.
Qui il prg che va in buffer overflow non c'entra
più nulla.
Con Cicap c'eravamo messi a ragionare, dopo,
ed è la sesta volta che lo dico, su un normale
software ricorsivo che fa un printf ad ogni
ricorsione.
Il numero di ricorsioni possibili prima dello stack
overflow è proporzionale alla quantità di stack
che il kernel assegna al processo.
In base ai dati del tuo amico cicap (oltre che in
base alle differenze |EBP-ESP|), il programmino
in questione sul suo kernel Linux alle volte esce
dopo k ricorsioni ed alle volte dopo j ricorsioni
con k!=j.
Segue che quel kernel sta assegnando al processo
di volta in volta una quantità di stack differente.
Randomica.
Cicap sostiene che questo sia un comportamento
accettabile per un kernel (ma sì... tanto lo sviluppatore
deve allocare poco stack come buona regola
di programmazione... geniale...), io sostengo che
un sistema operativo deve assegnare al processo
una quantità di stack che sia sempre la stessa,
perchè altrimenti il comportamento di un software,
anche di quelli corretti, diventa non più garantibile
a priori.
Ed infatti, ci sono 6-7 segnalazioni di software su
Linux che non funzionano, e si mettono a funzionare
guardacaso quando disattivi l'ASLR.
Questo è quanto.
Poi se vuoi continuare a difendere cicap, fai pure,
ma i fatti sono come te li ho riassunti.

>bugiardo:
cicap, ma perchè provi di nuovo con ste sceneggiate ?
Io che ti ho detto: che prima parlavo di comportamento
senza l'ASLR attivato ?
Mai detto e mai scritto.
Quindi come al solito stai ricorrendo alla tua solita tecnica
di mettere in bocca al tuo avversario quello che fa comodo
a te, oltre che autoassegnarti vittorie inesistenti, allo
scopo di imbrogliare le carte.
IO TI HO DETTO, che questa discussione era partita
dal fatto che, secondo la tua geniale interpretazione,
sarebbe corretto parlare di undefined behaviour come
comportamento aleatorio.
Siccome ti abbiamo contestato, sia io che Giorgi, che
un crash non ha nulla di aleatorio (per potere parlare
di comportamento aleatorio ci vuole un alea, ossia
una qualche funzione randomica, valeadire che hai
scritto una sonora minchiata), tu ti sei messo a
cercare qualcosa, qualsiasi cosa, che ti permettesse
di infilare dentro il sistema un qualche elemento
randomico.
E lo hai trovato nell'ASLR, che hai infilato dentro
pretestuosamente e dopo 5-6 ore di ricerca sul web.
Ma siccome non bastava (**TUTTA** la documentazione
che abbiamo parla di randomizzazione della posizione
dello stack, e non della size), te ne sei uscito con
quei dati, che ancora non ho verificato, sul fatto
che **anche la size** dello stack sotto Linux sarebbe
randomizzata dall'ASLR.
Ribadisco: tutta la documentazione che abbiamo finora,
sia su Windows che su Linux, ci dice che la randomizzazione
dello stack riguarda il registro EBP (posizione stack)
e non la size dello stack.
Per verificare cosa succede sotto Windows 7 ho provato
un normale .exe, ovviamente con l'IDE che mi sono
trovato sottomano. Per ora sappiamo che sotto
Windows 7, con un normale programma, non c'è
traccia di randomizzazione.
Quindi, riassumendo:
- cicap sostiene che "undefined behaviour" si possa
tradurre con "comportamento aleatorio", e che questa
cosa sarebbe scritta su tutti i manuali C (come no) e
lo giustifica con queste parole:
[cite cicap]
Tutto dipende da che valore assume la variabile "a", quindi
dall'indirizzo che viene assegnato all'array, ovvero il valore di "z"
nelle tue stupide equazioni.
Se z finisce "a ridosso" della parte indirizzabile (tutto detto molto
a spanne per farmi capire dai CRETINI), allora z + 1000 può sforare.
MA se alla prossima esecuzione del programma, il sistema assegna un
valore (per esempio) basso a z magari perchè qualche registro è
cambiato, allora z + 1000 non sfora più un bel niente e non ottieni
segmentation fault.
[/cite cicap]
- Per ora, invece, quello che sappiamo è che
a) quanto affermato da cicap è falso in
- Dos, Windows 3.x
- Windows 95, 98, ME, XP
- Windows Vista e 7 per qualsiasi programma ottenuto per mezzo
di gcc ed ld, o compilatori non Microsoft.
- Kernel Linux in cui l'ASLR sia stato disattivato
mi pare che siano un pò tantine le situazioni in cui quello
che dice cicap non è vero
b) per quanto riguarda ciò che accade con binari ottenuti
da Visual Studio **avevo già detto** che appena ho un momento
libero mi riservo di provare.
Ma, ***dalla documentazione*** dubito davvero molto
che la size dello stack di un programma Win32 possa
essere randomizzata, perchè sarebbe una violazione
delle specifiche di caricamento degli eseguibili di
Windows (da ciò che leggiamo, ribadisco per
l'ennesima volta, è EBP ad essere randomizzato e
non la size dello stack, ed esiste un motivo per
questo comportamento).

 ma i fatti sono come te li ho riassunti.
Non ho da difendere nessuno.
Hai la chiarezza espositiva di un gerbillo sotto l'effetto della 
mescalina.

 morfa.
Ecco perche' non la vedo.


Forse se scrivo in arabo ci capiamo meglio.
Ripeto (stiamo calmi e ragioniamo).
a) C'è stato un primo momento in cui si
discuteva di quello che accade facendo
un buffer overflow su una variabile
locale. Tu hai
int a[size];
e fai un a[k] con k>size in un punto del tuo
programma.
CICAP, in questa prima fase, sosteneva che
un buffer overflow determinasse **di per sè**
un comportamento aleatorio, e la prova era
un programma in cui lui faceva
printf ("%d \n", a[k]);
ed alle volte dava un valore ed alle volte dava
una eccezione di segmentation fault
b) Io a questo punto ho **dimostrato**, disequazioni
alla mano, che
- se l'execution trace è lo stesso (e questo non ci interessa
perchè è pacifico)
- e se lo STACK HA SEMPRE LA STESSA DIMENSIONE
il programma ha solo due possibilità (e farà sempre la
stessa cosa, senza alcuna randomicità)
1. o a[k] con k>size supera i limiti del buffer ma si mantiene
comunque ancora all'interno del segmento stack (e quindi
ancora nello spazio di indirizzamento del processo), ed
allora il programma stamperà sempre un risultato a video e
proseguirà
2. o a[k] con k>size supera non solo i limiti del buffer,
***ma anche i limiti dello stack*** ed in quel caso
il programma terminerà sempre con un segmentation
fault.
NOTA BENE CHE, SE LA SIZE DELLO STACK E'
SEMPRE LA STESSA, IL COMPORTAMENTO
SARA' SEMPRE 1, OPPURE SEMPRE 2.
DIPENDE SOLO DA K O DA SIZE DELLO STACK
c) Siccome cicap insisteva che da lui il programma una
volta faceva una cosa, ed una volta ne faceva un'altra,
mi ha postato il valore del registro EBP e del registro
ESP all'inizio del programma.
La cosa **sospetta** dei dati di CICAP è che la
differenza |EBP-ESP|, che è la SIZE DELLO STACK,
non è COSTANTE come dovrebbe essere ad ogni
lancio, ma nel caso di CICAP VARIAVA.
Ovvero: i dati di cicap ci dicono che il kernel del sistema
operativo sta allocando al medesimo processo prima
x kb, e poi y kb per lo stack, con x ed y DIVERSI.
Hai uno stack allocato RANDOMICAMENTE: oggi
di dò 1 Mb ed al prossimo lancio ti dò 995 kb di STACK,
così, TANTO PER FARE...
Abbiamo anche verificato che con l'ASLR disattivato
questo non succede, pertanto è l'ASLR
d) Siccome stentavo a credere ai miei occhi, per essere
sicuro che lo stack assegnato dal kernel di cicap variasse
effettivamente in modo randomico, gli ho assegnato un
SECONDO PROGRAMMA DOVE NON C'ERA
PIU' ALCUN BUFFER OVERFLOW, MA SOLO UNA
SEMPLICE RICORSIONE INFINITA.
Siccome il numero di ricorsioni che puoi fare è proporzionale
allo stack assegnato, se avrai sempre lo stesso numero di
ricorsioni, allora lo stack assegnato è sempre lo stesso,
se avrai un numero di ricorsioni diverso da lancio a lancio
del medesimo programma, allora avrai la prova provata
che lo stack varia randomicamente.
E CICAP CI HA CONFERMATO CHE IL NUMERO
DI RICORSIONI CAMBIA DI VOLTA IN VOLTA,
IL CHE' VUOL DIRE CHE AD OGNI LANCIO DEL
MEDESIMO PROCESSO IL KERNEL ASSEGNA
UNA QUANTITA' DI STACK DIVERSA E
VARIABILE RANDOMICAMENTE.
Il chè, in opinione del sottoscritto, è una cosa assolutamente
inaccettabile, come anche sottolineato qui:
http://gnats.netbsd.org/41877
Mentre per cicap è una cosa accettabilissima perchè...
... tanto una buona tecnica di programmazione richiede
di usare poco stack... di tenersi larghi....
Abbastanza chiaro ora ?

 stessa cosa, senza alcuna randomicità)
Tu non hai capito un cazzo. Su architettura x86 un array è salvato in
modo da andare verso l'alto, cioè verso 0xffff. Quindi centra un cazzo
la dimensione dello stack:
int a[10];
| FP [         ]a   SP  ..... |
[     ]a è l'array
Se scrivi a[1000], che equivale ad
*(a + 1000)
stai andando verso sinistra, non verso destra. E poi è ovvio, penserai
mica che esaurisco lo stack con 4 kb?

 che lo stack varia randomicamente.
E se esaurisci lo stack cosa accade?

>la dimensione dello stack:
Ennesima figura di merda.
Complimenti vivissimi.
                                    x
++++++STACK++++++++
x rappresenta lo stack pointer
all'inizio del programma,
quello che nel tuo programma
viene randomizzato
Adesso eseguiamo una funzione
che ha un array locale a[1000]
                             <<<<x
+++++++STACK++++++++
(perchè lo stack cresce verso
il basso).
Se poi esegui un a[H] ed un a[K]
ti può succedere questo:
                             <<<<x   H   K
+++++++STACK++++++++
Per H non uscirai dallo spazio di
indirizzamento, per K invece sì e
ti arriva l'eccezione.
Indovina indovinello....
... che succede quando x si sposta
randomicamente a causa dell'ASLR ?


Va bene, ho capito.
Mi stai prendendo per i fondelli.
Non c'è bisogno di altri ragionamenti.

 Mai detto e mai scritto.
Ottima rosicata. In realtà le cose stanno più o meno così:
1. cicap sostiene che **si possa** avere un comportamento aleatorio in
caso di buffer overflow. E lo dimostrano le prove che fa sul suo PC.
2. Pegasus nega, secondo lui lo stesso programma o va sempre in errore
oppure mai
3. cicap possiede un Linux e scopre che quel comportamento è dovuto ad
una feature del kernel chiamata ASLR.
4. Pegasus deride negando decisamente.
5. cicap dimostra, postando dati inconfutabili più le istruzioni per
riprodurre le prove, che la responsabile è proprio l'ASLR
6. Pegasus invece che dare ragione, si inventa che non vale perchè
l'implementazione di Linux è bacata.
7. cicap dimostra che l'ASLR su Linux non è bacato perchè si comporta
nella stessa identica maniera di Windows7
8. Pegasus salta incredibilmente i punti 2,3,4,5,6,7 e cerca di
tornare al punto 1 senza neppure scusarsi o ammettere gli
strafalcioni.
Per quanto mi riguarda è questo. Hai qualche problema di autostima per
caso?

 ha scritto nel messaggionews:22ac75e0-44a6-4647...@d8g2000yqf.googlegroups.com...


ROTFL
Guarda che hai riscritto quanto ho detto io pari pari.
La dimensione dello stack centra nulla, come si evince anche dal tuo
esempio. Ma ci sei o ci fai?
Cioè nei nostri esempi, lo stack potrebbe essere anche grande
sedicimila terabyte, andrebbe ugualmente in segmentation fault, pechè
l'array sborda verso destra nel tuo esempio (e a sinistra nel mio).

 Mi stai prendendo per i fondelli.
....qualora ci fosse bisogno di altre conferme che questo essere NON CI STA 
CON LA CAPOCCIA.

caso?
Quando qualcuno capirà che occorre un ricovero urgente, sarà sempre troppo 
tardi.

>esempio. Ma ci sei o ci fai?
ASLR di cicap:
-------------------------x     H K
+++++++STACK++++++++
-----------------x H K
+++++++STACK++++++++
La linea tratteggiata ti dice qual è
la size del tuo stack (è la distanza
|EBP-ESP|).
Nel secondo caso hai meno stack
disponibile: l'accesso a[K] però
non produrrà una eccezione
(lo hai detto tu che è normale che
SP sia randomizzato no ? come
no, e questo è quello che succede).
E ti spiega anche perchè nel primo
caso farai un numero maggiore di
ricorsioni e nel secondo caso
ne farai di meno.

 ne farai di meno.
E ti ripeto: hai detto la stessa identica cosa del sottoscritto.
Quello che io ti contestavo due post fa è che hai tirato in ballo la
size dello stack sull'esempio
a[1000]
sul quale invece non ha alcun impatto. Sulla ricorsione siamo
d'accordo che ce l'abbia.

>a[1000]

Cazzata, si consiglia un buon ripasso di
matematica anche....
La size dello stack è |EBP-ESP|
(o anche ESP-EBP).
Quindi:
sstack = ESP-EBP
Facciamo finta che il segmento stack allocato
dal sistema operativo sia dalla locazione di
memoria w alla locazione di memoria z.
ESP è minore di z e, grazie alla tua implementazione,
è anche randomico.
w < ESP < z
La quantità di stack che hai è evidentemente
sstack = ESP - w
o anche ESP - EBP, da cui segue che EBP=w
(lo sapevamo, niente di nuovo)
Supponiamo ora di allocare un certo array in
stack, oltre all'indirizzo di ritorno della routine
ed i registri. La nuova posizione dello stack
pointer diventa:
ESP' = ESP - sbuffer
Dove sbuffer è la size dell'array locale + registri
+ indirizzo di ritorno della routine.
Se ora cerco di accedere all'int a[1000], il
sistema cercherà di accedere all'indirizzo:
ESP' + 4*1000 = ESP - sbuffer + 4*1000
Problema: quando si verificherà l'eccezione ?
Quando questo indirizzo uscirà dallo segmento
stack, la cui dimensione, ti ricordo, va da w a z.
Quindi, eccezione quando:
ESP - sbuffer + 4*1000 > z
Ma siccome la stack size abbiamo detto che è:
ssize = ESP - EBP
da cui
ESP = ssize + EBP
sostituendo:
ssize + EBP + 4*1000 > z
oppure
ssize + w + 4*1000 > z
ssize + 4*1000 > z - w
Il chè dimostra che la condizione che determina
l'eccezione o meno è dipendente da
ssize = ESP - EBP.
Pegasus prende la mira
GOAAAAAAAAAAAAAAAALLLLLLLLLLLLLLL
(E cicap prende il secondo goal...)


(avevo dimenticato sbuffer. capita)
:)

 (E cicap prende il secondo goal...)
ROTFL
ma il primo goal quale era scusa?

>Per fottere la tua pappardella illeggibile bastano tre righe:
Certo, pappardella illeggibile perchè
ti sei trovato davanti questa disequazione:
ssize - sbuffer + 4*1000 > z - w
ed a quel punto hai capito che avevi
preso un altro calcio in faccia
(lo vedi ssize, quello che tu dici
non influisce ?)
Detto in termini semplici, più nel grafico
x si sposta a sinistra (il tuo SP iniziale
randomizzato, ricordi ?), più la distanza
ESP-EBP diminuisce (in pratica l'applicazione
ha meno stack) e più aumenta la probabilità
che un a[1000] non esca dai limiti del
segmento stack, ma ci rimanga dentro,
**non** provocando l'eccezione.
Ed è proprio questo ragionamento
elegantissimo che ho fatto che spiega
perchè nel tuo primo programma
printf ("%d \n", a[1000]);
con a array locale di dimensione 10,
alle volte stampava ed alle volte
andava in segmentation fault.
Quindi, spiacente, ssize c'entra eccome.
Palla al centro.

 ma il primo goal quale era scusa?
Quello che ha visto nelle allucinazioni ipnagogiche dovute allo sforzo 
notturno, matto e disperatissimo, di mistificare, per non ammettere di 
essere un emerito CAZZARO presuntuoso. 

 Palla al centro.
Secondo me tu fai fatica a cogliere il punto, come al solito.
La dimensione dello stack non ha alcun impatto su quel segmentation
fault. Ti ripropongo il codice di prima:
int a[10];
printf("%d", a[1000]);
se eseguo il programma assegnando stack size diversi cambia qualcosa?
No. Ergo...

>se eseguo il programma assegnando stack size diversi cambia qualcosa?
No, minus, in questo programma tu hai detto
che alle volte stampava ed alle volte arrivava
il segmentation fault.
E questo è il motivo:
ssize - **sbuffer** + 4*1000 > z - w
Con quella implementazione di ASLR,
ssize ti cambia di volta in volta.
Ti ricordo che:
ssize = ESP (che da te è random) - EBP

 ssize = ESP (che da te è random) - EBP
Il motivo l'ho già scritto sopra e anche schematizzato con disegnini,
ed è questo:


 Mi stai prendendo per i fondelli.
Puo' darsi ma tu hai un mucchio di tempo da perdere.

>nella stessa identica maniera di Windows7
Questo lo devi ancora dimostrare. Il famoso video che
ti è stato chiesto non si è ancora visto.
Quello che per ora sappiamo dalla documentazione è
che viene randomizzato EBP, mentre ancora non
c'è una riga come una che parli di randomizzazione
della quantità di stack disponibile **come feature**.

>La risposta è "no", oppure non vuoi darla?
Ti faccio rispondere da te stesso:
[cite cicap 10/7/2010, 21:05]
Mio Dio. Hai qualche ENORME carenza di programmazione C a quanto pare.
E si che non programmo in C da...4-5 anni eppure prendi mazzate anche su
quello che dovrebbe essere il tuo linguaggio:
Programmino di esempio:
int main(int argc, char *argv[])
{
    int a[10];
    printf("elemento %d \n", a[1000]);
    return 0;
}
compila ed esegui 1,2,3, 10 volte.
Risultato:
elemento 0
elemento 1668312366
elemento 0
elemento 976565051
elemento 0
elemento 0
elemento 0
elemento 0
elemento 1026718306
Segmentation fault
Come vedi al decimo tentativo ho ottenuto un segmentation fault, in
tutti gli altri tentativi, NONOSTANTE STESSI ACCENDENDO AD UNA ZONA DI
MEMORIA NON ALLOCATA, non si è evidenziato alcun problema.
[/cite]
Ho finito, grazie.
Certo però che le piroette che ho visto fare
in questo NG negli ultimi giorni me le ricorderò
a lungo. Potreste fare le olimpiadi di
disonestà intellettuale.

 disonestà intellettuale.
Vinceresti tutte le medaglie, CRETINO da Guinness.

 Certo però che le piroette
Come quella di fingere di non capire le domande?

 ha scritto nel messaggio 
news:06e426bb-a6ac-4753...@d8g2000yqf.googlegroups.com...
----------------
Ti ripropongo il codice di prima:
int a[10];
printf("%d", a[1000]);
se eseguo il programma assegnando stack size diversi cambia qualcosa?
----------------
cicap, come assegni stack size diversi a
quel programma ? Li assegni manualmente tu ?
Negli esempi fatti fino ad ora,
č il tuo OS che gli assegna stack size
differenti ad ogni lancio, grazie all'ASLR.
E certo che cambia qualcosa: nel primo
caso ti spara il numero, e nel decimo
ti spara il segmentation fault.
(ahņ, certo perņ che č surreale sta commedia)

 ti è stato chiesto non si è ancora visto.
Il famoso video io non ho mai detto che te l'avrei fatto. Piuttosto tu
continui a svincolare su due punti, che dicono tutto:
1. perchè non tiri fuori le palle e scrivi le fregnacce che continui a
proporre qua, su un NG appropriato? Magari che si occupa di kernel
linux.
2. la prova su Win7 la puoi fare benissimo anche tu, ma ovviamente ti
fa paura farla.

 (ahò, certo però che è surreale sta commedia)
Di surreale c'è la tua incapacità di comprensione.

>è così.
No, cicap.
Ti ho fatto i calcoli.
Ti ho fatto i disegni
Se a te piace prendere per i fondelli la gente,
lo vai a fare con altri, non con me.
Il punto è la randomizzazione del tuo SP,
che fa sì che la quantità
ESP-EBP = ssize
non sia una costante tra un lancio e l'altro.
Questo cambiamento della posizione di
SP rispetto a BP, legato all'ASLR,
determina l'insorgenza di quel comportamento
randomico nel buffer overflow.
Stop.
Poi se fai finta di non capirlo... fai lo scemo
da solo.

 Stop.
Ecco, non hai capito un cazzo. CVD.
Se vuoi un consiglio ricomincia da qua:
http://groups.google.it/group/it.politica/msg/aa6d4aa22592168e?hl=it
Nell'esempio a[1000] è fuorviante parlare di stack size, perchè non è
quello il motivo per cui si ottiene l'errore. Altrimenti uno potrebbe
pensare che a[1000] esce perchè sfora la dimensione dello stack (vero
invece nel caso dell'esempio ricorsione).
Come si diceva prima, tu non sai cogliere il punto e rendi difficile
la comprensione agli altri (infatti X05 non ti capisce, ed è
tutt'altro che scemo).
Stop.

>invece nel caso dell'esempio ricorsione).
No, ti ho fatto i calcoli, persino i
disegni stamattina.
stack size non è fuorviante, perchè
più x si sposta a sinistra (te lo avevo
detto stamattina), più diminuisce
|EBP-ESP|=ssize a sinistra, e più
aumenta lo spazio a destra nel
segmento stack.
Siccome la spazio a destra aumenta,
c'è una sempre maggiore probabilità
che a[1000] ci cada dentro e non
fuori e quindi l'eccezione di segmentation
fault non si verifichi.
Conclusione: tutto dipende dal punto
iniziale dove si cade ESP (che è random),
ossia la x che avevo disegnato stamattina.
Vai a quel paese, grazie.

 stack size non è fuorviante
C'è poco da fare, quando uno non ci arriva non ci arriva.

 C'è poco da fare, quando uno non ci arriva non ci arriva.
Parole sante.