|
[ Nibble @ 02.07.2006. 16:55 ] @
| Kako je moguce da sa 1 bytom alocirane memorije mogu da da pravim 2-matrice a da ne izbacuje nikakvu gresku(pogledajte kod i sve radi ali kako?).Mali Misha mi je pomogao sa alociranjem memorije za pokazivace ali meni je pala na um druga ideja koja radi za sad.Ipak me interesuje kako je moguce da program moze da radi(da ne puca) ako mu se alocirana memorija ne prosiruje.
evo pogledajte dio koda
Code:
//part je definisan kao char **part;
part = (char**)malloc(sizeof(char*)); //ovdje sam alocirao 1 bajt
while(1)
{
j = 0;
z = 0;
memset(buffer,0,512);
valid=frecv(sock,buffer,sizeof(buffer),0);
printf("%s [=-=]\n",buffer);
if (valid<=0) break;
for(i = 0;i < valid;i++)
if(buffer[i] == '\r'||(buffer[i] == ':' && i > 0))
fstrcpy(&buffer[i],&buffer[i+1]);
for(i = 0;i < valid;i++)
{
if(buffer[i] == ' ' ||
buffer[i] == '\n')
{
// part = (char**)realloc(part,(j+1) * sizeof(char*)); kad ovo nestavim u kod
// program opet radi
buffer[i] = '\0';
part[j] = &buffer[z+1]; //ovdje stavljam u part[j] pokazivac od buffer
printf("part[%d] - %s\n",j,part[j]);
z = i;
j++;
}
}
if(strlen(sbuff) > 5)
{
fsend(sock,sbuff,sizeof(sbuff),0);
memset(sbuff,'\0',512);
}
}
free(part);
Evo ga citav kod. |
[ tomato101 @ 02.07.2006. 20:06 ] @
Mrzi me da citam citav kod :), ali u prvoj liniji nisi alocirao jedan bajt vec cetiri -- sizeof(char*) (pointer na char).
[ Nibble @ 02.07.2006. 22:55 ] @
Ok ali opet je to malo.
[ n1tr0 @ 02.07.2006. 23:53 ] @
I mene mrzi da citam kod... 
Pretpostavljam da se radi o najobicnijem buffer overflow-u. Ako je to u pitanju onda to treba da sprecis jer samim tim ces da prepises neke druge podatke. Program ne puca jer verovatno na toj lokaciji (part + j) nije nista smesteno. Probaj to da uradis kod nekog veceg i zahtevnijeg program pa ce biti pucanje svako malo.
[ peka @ 03.07.2006. 00:28 ] @
Pokusaj ovako nesto:
Code:
int *a = (int *) malloc(sizeof(int));
int *b = (int *) malloc(sizeof(int));
*b = 1;
*(a+1) = 2;
*(a+2) = 2;
*(a+3) = 2;
*(a+4) = 2;
printf("%d\n\n", *b);
Nagradno pitanje: sta ce se ispisati? :)
Jednostavno, sve ce funkcionisati dok taj dio memorije u koji ti (nelegalno) upisujes ne bude dodjeljen nekom drugom podatku. Onda ce nastati problemi.
[ n1tr0 @ 03.07.2006. 22:18 ] @
Odgovor je, naravno: b=2
Kazem ja buffer overflow...
btw vazan je samo deo *(a+4)=2;
U ovom slucaju sto si naveo ce se desiti, medjutim kada radis sa dinamickim listama i bla,bla,bla e onda moze da se desi da deo memorije koji prepisujes bude 'prazan'(nevazan za korisnika) korisnik nece primetiti nista cudno, medjutim kod velikih programa, tipa 3D Studio MAX i slicnih, kada je opterecenje memorije max nastaju problemi i program pukne.
[ Nibble @ 04.07.2006. 00:03 ] @
Ok hvala momci ja sam stavio ono sa realloc.
[ DjoleReject @ 13.07.2006. 17:31 ] @
To ti je fora sa nizim jezicima (uslovno receno). Mozes da jases memoriju kako god ti zelis, ali time kao da potpisujes paragraf "ako sam budala - niko mi nije kriv". To sto program radi ne cini ga dobrim. Gledao sam ljude kako na kraj niza dodaju jos podataka i to radi, ali niko ne zna dokle ce da radi.
[ nikoladsp @ 27.07.2006. 15:16 ] @
slazem se sa @DjoleReject
radice dok se neko ne seti da nabilda release verziju,...a onda...mrak...video sam to par puta,sve kao satro radi kad ono medjutim....
eh ti kompjuteri nisu normalni ko ni japanci...
[ Sarevok @ 13.08.2006. 00:34 ] @
Nije u pitanju samo programski jezik, nego i OS na kome se program izvrsava.
U DOS-u recimo takav program (skoro) nikad ne bi pukao, jedino bi eventualno davao pogresne rezultate + sto bi mogao ugroziti rad drugih programa (prepisati njihove podatke). U nekim drugim OS bi moglo doci do segmentation fault-a i slicno.
Inace ovo o cemu se pricha u ovom topicu je tema koja je vrlo bliska ljudima "on the dark side of the force", i jedna je od prvih lekcija na putu zauzimanja roota nekog OS-a :)
Nekada je na ES postojao podforum (mozda jos uvek postoji) koji se bavio takvim stvarima. Ako te interesuje potrazi malo, ili ukucaj u google "buffer overflow exploit" ili "heap overflow" :)
[ DjoleReject @ 19.08.2006. 03:47 ] @
Da, da, secam se da sam citao poneku o tome, ali sam u vecini prica uglavnom sretao komentar da su te fore "starije od interneta", pa i srazmerno neefikasne... Za sve one sa Dzedajske strane sile, potrebno je zapamtiti da je buffer overflow arhineprijatelj C-olikih jezika (mada mladji kompajleri imaju pristojne nacine borbe protiv ovoga).
[ Sarevok @ 19.08.2006. 22:26 ] @
Citat: DjoleReject: Da, da, secam se da sam citao poneku o tome, ali sam u vecini prica uglavnom sretao komentar da su te fore "starije od interneta", pa i srazmerno neefikasne...
Moras prvo puzati, da bi znao hodati ;)
Inace, iako takvo programiranje treba izbegavati pri pravljenju standardnih aplikacija, poznavanje svega toga moze samo da koristi ... iz mnogo razloga.
[ z@re @ 23.08.2006. 03:06 ] @
U production okruzenjima se koriste dodatci za razvojna sucelja koji paze na ovakve stvari. Medjutim, programeri koji kodiraju u jezicima nizeg nivoa i ne naviknu se automatski na pisanje normalnog koda, kasnije imaju gadnih problema sa "normalizacijom". Jer navika je zeznuta stvar. Eto, zato su i Java i .NET uspjeli, managed programiranje ima svojih velikih prednosti.
Citat: Sarevok: Nije u pitanju samo programski jezik, nego i OS na kome se program izvrsava.
U DOS-u recimo takav program (skoro) nikad ne bi pukao, jedino bi eventualno davao pogresne rezultate + sto bi mogao ugroziti rad drugih programa (prepisati njihove podatke). U nekim drugim OS bi moglo doci do segmentation fault-a i slicno.
DOS je kretenski osmisljen, i jos gore implementiran. Onih 640kb konvencionalne memorije nije nikako zasticeno. Znaci, ti mozes apsolutno i rucno iz programa adresirat svih tih 640kb, i ne brinut za alokaciju/dealokaciju. Jednostavno pointer na neku adresnu lokaciju, i pici kume po memoriji kako hoces. Naravno, ako postoji neki TSR program koji "cuci" u tih 640kb poput drivera za mis, zvucnu karticu, ode u vjecna lovista ako se previse igras po memoriji. Jer DOS nema nikakve mehanizme za zastitu adresnog prostora. Pojavom DOS4GW u kombinaciji sa memorijskim ekstenderima dobila se bazicna protekcija, ali sve je to vise manje dirty hack lose implementacije OS-a. Sta je onda dvostruko gore.
Svaki od "naprednih" OS-ova, pocevsi od prvih verzija UNIXa je osmisljen kao multitasking OS, sta znaci da automatski treba garantirat mehanizme zastite memorije i razdvajanja adresnog prostora procesa. Cak i rani Windowsi, iako realno samo ljuska za DOS, su imali on-halt model multitaskinga (ukratko...nema privida paralelnosti, vec samo jedan proces se konstantno izvrsava, a od onoga koji se izvrsavao prije se sacuva kontekst i ide u halt dok ga korisnik ne aktivira), i s time zastitu memorijskog prostora.
Eto, valjda ce u buducnosti masina malo ublaziti ljudsku glupost, pa se nece desavat debilne programerske pogreske. Iako, da se nebi krivo razumjeli, ja sam debeli advokat C-a, i mislim da programer nije dozivio svoje vatreno krstenje sve dok mu se trista pointera ne razleti po memoriji :)
Copyright (C) 2001-2025 by www.elitesecurity.org. All rights reserved.
|