From mitrogiannis at gmail.com Fri Mar 2 16:00:43 2007 From: mitrogiannis at gmail.com (christos mitrogiannis) Date: Fri, 2 Mar 2007 16:00:43 +0200 Subject: tiff-3.8.2.tar.gz installation problem Message-ID: <8adbafe50703020600h276a3a97u603a4759af311f7f@mail.gmail.com> Hello to everybody, I really need your help to install the libTIFF library. I am new user in linux so i will try to be accurate as possible. I have visited the site http://www.linuxfromscratch.org/blfs/view/svn/general/libtiff.html and afterwards i downloaded the tiff-3.8.2.tar.gz from : ftp://ftp.remotesensing.org/libtiff/tiff-3.8.2.tar.gz and then through the shell i wrote the following commnds: tar zxf tiff-3.8.2.tar.gz cd tiff-3.8.2 ./configure --prefix=/usr && make Unfortunately i received the following errors: Libtiff is now configured for i686-pc-linux-gnu Installation directory: /usr Documentation directory: ${prefix}/share/doc/tiff-3.8.2 C compiler: gcc -g -O2 -Wall -W C++ compiler: g++ Enable runtime linker paths: no Support Microsoft Document Imaging: yes Support for internal codecs: CCITT Group 3 & 4 algorithms: yes Macintosh PackBits algorithm: yes LZW algorithm: yes ThunderScan 4-bit RLE algorithm: yes NeXT 2-bit RLE algorithm: yes LogLuv high dynamic range encoding: yes Support for external codecs: ZLIB support: no Pixar log-format algorithm: no JPEG support: no Old JPEG support: no C++ support: yes OpenGL support: no Making all in port make[1]: Entering directory `/home/indian/Desktop/tiff-3.8.2/port' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/indian/Desktop/tiff-3.8.2/port' Making all in libtiff make[1]: Entering directory `/home/indian/Desktop/tiff-3.8.2/libtiff' make all-am make[2]: Entering directory `/home/indian/Desktop/tiff-3.8.2/libtiff' source='tif_stream.cxx' object='tif_stream.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../config/depcomp \ /bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I. -I. -c -o tif_stream.lo tif_stream.cxx libtool: compile: g++ -DHAVE_CONFIG_H -I. -I. -I. -I. -c tif_stream.cxx -o .libs/tif_stream.o ../libtool: line 837: g++: command not found make[2]: *** [tif_stream.lo] Error 1 make[2]: Leaving directory `/home/indian/Desktop/tiff-3.8.2/libtiff' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/indian/Desktop/tiff-3.8.2/libtiff' make: *** [all-recursive] Error 1 Unfortunately i am not able to understand what the problem is so if anyone knows how to solve this i would realy apriciate it. Thanks in advance. From sbolis at hellug.gr Fri Mar 2 23:30:42 2007 From: sbolis at hellug.gr (Spiros Bolis) Date: Fri, 2 Mar 2007 23:30:42 +0200 (EET) Subject: tiff-3.8.2.tar.gz installation problem In-Reply-To: <8adbafe50703020600h276a3a97u603a4759af311f7f@mail.gmail.com> References: <8adbafe50703020600h276a3a97u603a4759af311f7f@mail.gmail.com> Message-ID: On Fri, 2 Mar 2007, christos mitrogiannis wrote: > ../libtool: line 837: g++: command not found > make[2]: *** [tif_stream.lo] Error 1 Leei pentakathara pws soy leipei o compiler C++ ti dianomh xrhsimopoieis? analoga boreis na egkatasthseis to paketo me thn eykairia, giati de rwtas sth lista linux-greek-users mias kai to thema soy einai eidiko gia linux kai oxi gia opoia alla unices? ;-) From laura.battelle at gmail.com Mon Mar 5 05:34:23 2007 From: laura.battelle at gmail.com (Laura Battelle) Date: Sun, 4 Mar 2007 22:34:23 -0500 Subject: Harvard University - Peter Zmijewski Message-ID: <6d835f8f0703041934g57c9f548g485bdc2eb001c2a4@mail.gmail.com> Harvard University Sports Club - Peter Zmijewski http://www.harvard.edu Harvard"s undergraduate club teams are student-initiated activities that require students to be responsible for organization, leadership and decision making. Club activities range from informal play to regular practice or instruction and intercollegiate and tournament competition. some clubs hire coaches or instructors and all clubs require dues from their membership in order to support their activities. Peter Zmijewski and the Department of Athletics provides guidance, facility assistance, minimal financial support and an administrative framework for the operation of officially recognized clubs. Peter Zmijewski Harvard University Sports Club, 1986 A list of existing clubs and representitives as well as information con- cerning club sports can be obtained in the Club Sports Office. CLUB SPORTS Peter Zmijewski Aikido H-Fu Archery Hapkido Auto Society & Racing Team Jujutsu Badminton Kendo Ballooning Society Racquet Ballroom Dance Rugby (Men) Bowling Rugby (Women) Boxing Shotokan Karate Capoeira Regional Skiing Cheerleading Snowboarding Crimson Dance Team Surf Cycling Table Tennis Equestrian Taekwondo Figure Skating Tai Chi/Tiger Crane Fly Fishing Tennis (Men) Frisbee (Men) Tennis (Women) Frisbee (Women) Wushu From sbolis at hellug.gr Mon Mar 12 12:31:47 2007 From: sbolis at hellug.gr (Spiros Bolis) Date: Mon, 12 Mar 2007 12:31:47 +0200 (EET) Subject: Filtering Image Spam Message-ID: Mia syllogh apo fwtografies gia to FuzzyOCR sas ;-) http://blog.isja.org/index.php?/archives/41-Filtering-Image-Spam.html From advent.cloud.strife at gmail.com Wed Mar 28 19:52:57 2007 From: advent.cloud.strife at gmail.com (-) Date: Wed, 28 Mar 2007 19:52:57 +0300 Subject: Coding a SYN Scanner guide ( source included ) Message-ID: <460A9D69.1010506@gmail.com> Το παρων μακροσκελες guide πραγματευεται την δημιουργια ενος SYN port scanner ( source included ) καθως και την αναλυση των επιμερους σταδιων που χρειαζονται για τον προγραμματισμο του. http://rapidshare.com/files/23172011/Coding-a-Syn-Scanner.rar.html Μερικα απο αυτα ειναι: --Raw Sockets --Libpcap / Sniffing --Tcp/ip header analysis --Το ίδιο το SYN Scanning Aυτα. Enjoy teh 1368 lines of it. Περιμενω feedback. ( στο mail που αναφερω στον οδηγο ) ithilgore From v13 at it.teithe.gr Thu Mar 29 00:55:57 2007 From: v13 at it.teithe.gr (V13) Date: Thu, 29 Mar 2007 00:55:57 +0300 Subject: Coding a SYN Scanner guide ( source included ) In-Reply-To: <460A9D69.1010506@gmail.com> References: <460A9D69.1010506@gmail.com> Message-ID: <200703290055.57245.v13@it.teithe.gr> On Wednesday 28 March 2007 19:52, - wrote: > Το παρων μακροσκελες guide πραγματευεται την δημιουργια > ενος SYN port scanner ( source included ) καθως και την αναλυση των > επιμερους σταδιων που χρειαζονται για τον προγραμματισμο του. > > http://rapidshare.com/files/23172011/Coding-a-Syn-Scanner.rar.html > > Μερικα απο αυτα ειναι: > > --Raw Sockets > --Libpcap / Sniffing > --Tcp/ip header analysis > --Το ίδιο το SYN Scanning > > Aυτα. Enjoy teh 1368 lines of it. Περιμενω feedback. ( στο mail που > αναφερω στον οδηγο ) Poly kalo! Eisagogi se diktya kai sto pcap me ena poly kalo paradeigma... Eyge! Giati den to stelneis gia na mpei san arthro sto magaz? Oson afora ton link layer header, paliotera poy'xa piasei kati tetoia ekana to eksis: pcap_device.datalink_type=pcap_datalink(pcap_device.handle); switch(pcap_device.datalink_type) { case DLT_NULL: pcap_device.header_offset=4; break; case DLT_LOOP: pcap_device.header_offset=4; break; case DLT_EN10MB: pcap_device.header_offset=14; break; case DLT_RAW: pcap_device.header_offset=0; break; case DLT_LINUX_SLL: pcap_device.header_offset=16; break; default: ...... } An anoikseis me tin pcap to 'any' interface, tote ayto exei san link type to DLT_LINUX_SLL. Epeisis, to na xrisimopoieis etsi ta structs mallon problimata tha soy dimioyrgisei logo alignment kai reordering. Des to __attribute__((packed)) toy gcc. P.x. gia to IP: ---- struct pseudo_hdr { u_int32_t src; /* 32bit source ip address*/ u_int32_t dst; /* 32bit destination ip address */ u_char mbz; /* 8 reserved bits (all 0) */ u_char proto; /* protocol field of ip header */ u_int16_t len; /* tcp length (both header and data */ } __attribute__((packed)); ---- Des tin eksodo apo to parakato programma: ---- #include struct A { int a; char b; int c;}; struct B { int a; char b; int c; } __attribute__((packed)); int main() { printf("%d\n%d\n", sizeof(struct A), sizeof(struct B)); } ---- v13 at hell:/tmp$ ./a 12 9 Opos blepeis, logo alignment, to proto struct epiase 12 bytes giati to c egine align sta 32bit (4 byte), opote kai to c ksekinoyse apo to +2*4. Ayto mporeis na to deis kanontas compile me to -Wpadded: v13 at hell:/tmp$ gcc -Wpadded a.c -o a a.c:3: warning: padding struct to align ‘c’ Eimai sxedon sigoyros oti to gcc mporei kai na allaksei th seira ton metabliton poy briskontai mesa se ana struct alla den ksero pos to 'diorthoneis' ayto... Isos kapois allos na mporei na boithisei. > ithilgore <> From advent.cloud.strife at gmail.com Thu Mar 29 05:13:07 2007 From: advent.cloud.strife at gmail.com (-) Date: Thu, 29 Mar 2007 05:13:07 +0300 Subject: Coding a SYN Scanner guide ( source included ) In-Reply-To: <200703290055.57245.v13@it.teithe.gr> References: <460A9D69.1010506@gmail.com> <200703290055.57245.v13@it.teithe.gr> Message-ID: <460B20B3.9010804@gmail.com> V13 wrote: > On Wednesday 28 March 2007 19:52, - wrote: > >> Το παρων μακροσκελες guide πραγματευεται την δημιουργια >> ενος SYN port scanner ( source included ) καθως και την αναλυση των >> επιμερους σταδιων που χρειαζονται για τον προγραμματισμο του. >> >> http://rapidshare.com/files/23172011/Coding-a-Syn-Scanner.rar.html >> >> Μερικα απο αυτα ειναι: >> >> --Raw Sockets >> --Libpcap / Sniffing >> --Tcp/ip header analysis >> --Το ίδιο το SYN Scanning >> >> Aυτα. Enjoy teh 1368 lines of it. Περιμενω feedback. ( στο mail που >> αναφερω στον οδηγο ) >> > > Poly kalo! Eisagogi se diktya kai sto pcap me ena poly kalo paradeigma... > Eyge! Giati den to stelneis gia na mpei san arthro sto magaz? > > Oson afora ton link layer header, paliotera poy'xa piasei kati tetoia ekana > to eksis: > > pcap_device.datalink_type=pcap_datalink(pcap_device.handle); > > switch(pcap_device.datalink_type) > { > case DLT_NULL: > pcap_device.header_offset=4; > break; > case DLT_LOOP: > pcap_device.header_offset=4; > break; > case DLT_EN10MB: > pcap_device.header_offset=14; > break; > case DLT_RAW: > pcap_device.header_offset=0; > break; > case DLT_LINUX_SLL: > pcap_device.header_offset=16; > break; > default: > ...... > } > > An anoikseis me tin pcap to 'any' interface, tote ayto exei san link type to > DLT_LINUX_SLL. > > Epeisis, to na xrisimopoieis etsi ta structs mallon problimata tha soy > dimioyrgisei logo alignment kai reordering. Des to __attribute__((packed)) > toy gcc. P.x. gia to IP: > > ---- > struct pseudo_hdr { > u_int32_t src; /* 32bit source ip address*/ > u_int32_t dst; /* 32bit destination ip address */ > u_char mbz; /* 8 reserved bits (all 0) */ > u_char proto; /* protocol field of ip header */ > u_int16_t len; /* tcp length (both header and data */ > } __attribute__((packed)); > ---- > > Des tin eksodo apo to parakato programma: > ---- > #include > > struct A { int a; char b; int c;}; > > struct B { int a; char b; int c; } __attribute__((packed)); > > int main() > { > printf("%d\n%d\n", sizeof(struct A), sizeof(struct B)); > } > ---- > > v13 at hell:/tmp$ ./a > 12 > 9 > > Opos blepeis, logo alignment, to proto struct epiase 12 bytes giati to c > egine align sta 32bit (4 byte), opote kai to c ksekinoyse apo to +2*4. Ayto > mporeis na to deis kanontas compile me to -Wpadded: > > v13 at hell:/tmp$ gcc -Wpadded a.c -o a > a.c:3: warning: padding struct to align ‘c’ > > Eimai sxedon sigoyros oti to gcc mporei kai na allaksei th seira ton > metabliton poy briskontai mesa se ana struct alla den ksero pos > to 'diorthoneis' ayto... Isos kapois allos na mporei na boithisei. > > >> ithilgore >> > <> > thanx ! tetoiou eidous feedback perimenw. implicit reordering mias struct den nomizw na ginetai kai sumfwna me to C standard upo kanonikes sun8hkes den 8a prepei na ginetai Twra gia to packing ston sugekrimeno kwdika mono gia ka8ara optimization skopus ( < size ) tha eixe isws nohma. To pseudo header allwste xrhsimopoieitai mono sto checksuming kai me ena sizeof upologizetai pada swsta to mege8os. Ta upoloipa headers einai adistoixa twn klassikwn . Padws nice for pointing out . (to ar8ro to steila sto magaz btw molis prin ) ithilgore > > From v13 at it.teithe.gr Thu Mar 29 16:43:52 2007 From: v13 at it.teithe.gr (V13) Date: Thu, 29 Mar 2007 16:43:52 +0300 Subject: Coding a SYN Scanner guide ( source included ) In-Reply-To: <460B20B3.9010804@gmail.com> References: <460A9D69.1010506@gmail.com> <200703290055.57245.v13@it.teithe.gr> <460B20B3.9010804@gmail.com> Message-ID: <200703291643.52838.v13@it.teithe.gr> On Thursday 29 March 2007 05:13, - wrote: > Twra gia to packing ston sugekrimeno kwdika mono gia ka8ara optimization > skopus ( < size ) tha eixe isws nohma. To gcc by default (xoris -O) kanei align ta members ton struct kai otidipote allo xreiastei (p.x. metablites sth stoiba, parametroi (diladi metablites sth stoiba^2) klp). Se 32bit architectures ayto ginetai kata kanona sta 32 bit. To __attribute__((packed)) to dineis gia na *MIN* to kanei ayto. p.x. to: struct A { int a; char b; int c} xoris alignment tha eixe ta members toy stis sxetikes theseis mnimis: 0-3: a 4: b 5-8: c eno me alignment: 0-3: a 4: b 5-7: tipota (pading) 8-11: c > ithilgore <> p.s. Proteino eite na baleis kapoio onoma sto email soy, eite na afaireseis entelos thn payla oste na fainetai sketh h email dieythynsh... From advent.cloud.strife at gmail.com Fri Mar 30 00:58:11 2007 From: advent.cloud.strife at gmail.com (ithilgore) Date: Fri, 30 Mar 2007 00:58:11 +0300 Subject: Coding a SYN Scanner guide ( source included ) In-Reply-To: <20070329120942.GA1943@kobe.laptop> References: <460A9D69.1010506@gmail.com> <200703290055.57245.v13@it.teithe.gr> <460B20B3.9010804@gmail.com> <20070329120942.GA1943@kobe.laptop> Message-ID: <460C3673.60808@gmail.com> Giorgos Keramidas wrote: > On 2007-03-29 05:13, - wrote: > >> V13 wrote: >> >>> Epeisis, to na xrisimopoieis etsi ta structs mallon problimata tha >>> soy dimioyrgisei logo alignment kai reordering. Des to >>> __attribute__((packed)) toy gcc. P.x. gia to IP: >>> >>> ---- >>> struct pseudo_hdr { >>> u_int32_t src; /* 32bit source ip address*/ >>> u_int32_t dst; /* 32bit destination ip address */ >>> u_char mbz; /* 8 reserved bits (all 0) */ >>> u_char proto; /* protocol field of ip header */ >>> u_int16_t len; /* tcp length (both header and data */ >>> } __attribute__((packed)); >>> ---- >>> >>> Des tin eksodo apo to parakato programma: >>> ---- >>> #include >>> >>> struct A { int a; char b; int c;}; >>> >>> struct B { int a; char b; int c; } __attribute__((packed)); >>> >>> int main() >>> { >>> printf("%d\n%d\n", sizeof(struct A), sizeof(struct B)); >>> } >>> ---- >>> >>> v13 at hell:/tmp$ ./a >>> 12 >>> 9 >>> >>> Opos blepeis, logo alignment, to proto struct epiase 12 bytes giati >>> to c egine align sta 32bit (4 byte), opote kai to c ksekinoyse apo to >>> +2*4. Ayto mporeis na to deis kanontas compile me to -Wpadded: >>> >> thanx ! tetoiou eidous feedback perimenw. >> implicit reordering mias struct den nomizw na ginetai kai sumfwna me >> to C standard upo kanonikes sun8hkes den 8a prepei na ginetai >> > > Σωστός. > > >> Twra gia to packing ston sugekrimeno kwdika mono gia ka8ara >> optimization skopus ( < size ) tha eixe isws nohma. >> > > Αυτό όμως είναι λίγο λάθος. Έχει δίκιο ο Στέφανος (V13). Αν κάνεις > malloc() 12 bytes για ένα object τύπου "struct A", μπορεί ο memory > allocator να σου επιστρέψει τα παρακάτω bytes: > > A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 > ___________ __ ___________ > a b c > > Αν εσύ διαβάσεις από 'raw data' ένα πακέτο που έχει τιμές: > > a = 0x12345678 (4 bytes) > b = 0xCC (1 byte) > c = 0x23456789 (4 bytes) > > χρησιμοποιώντας απλά read() για όλο το struct κι όχι read() για κάθε > member ξεχωριστά, μπορεί να προσπαθήσεις να διαβάσεις περισσότερα bytes > από ότι είναι διαθέσιμα στο packet stream. > > Αν από την άλλη, για κάποιο λόγο όντως προσπαθήσεις να διαβάσεις 9 > bytes, τα δεδομένα θα γραφτούν σε ένα struct A με τη μορφή: > > 12 34 56 78 CC 23 45 67 89 A5 A5 A5 > ___________ __ ___________ > a b c > > και δεν θα είναι πολύ σωστές οι τιμές των struct members. > > >> To pseudo header allwste xrhsimopoieitai mono sto checksuming kai me ena >> sizeof upologizetai pada swsta to mege8os. >> > > Δηλαδή, ακριβώς λόγω των "padding bytes" μπορεί να κάνεις checksum σε > λάθος δεδομένα (επειδή π.χ. δεν έκανες memset() σε μηδέν όλα τα bytes > πριν από *κάθε* read() call). > > Δεν είναι πιο εύκολο να χρησιμοποιήσεις "packed structures"; :- > > Καλη παρατηρηση γενικα και απο τους 2. Καταλαβα τι εννοειτε αλλα στον συγκεκριμενο κωδικα συμβαινουν τα εξης: α) Το pseudo header χρησιμοποιειται **μονο** για το datagram που στελνουμε και **μονο** για τον υπολογισμο του checksum : με αλλα λογια δεν χρησιμοποιειται πουθενα σε συνδυασμο με την read( ) Να θυμισω λιγο τον κωδικα : /* pseudo header for tcp checksum */ struct pseudo_hdr *phdr = (struct pseudo_hdr *) ( datagram + sizeof(struct sniff_ip) + sizeof(struct sniff_tcp) ) ; phdr->src = iph->ip_src.s_addr; phdr->dst = iph->ip_dst.s_addr; phdr->mbz = 0; phdr->proto = IPPROTO_TCP; phdr->len = ntohs (0x14); /* in bytes the tcp segment length */ /*- WhyTF is it network byte saved by default ????*/ tcph->th_sum = htons ( checksum_comp ( (unsigned short *) tcph , sizeof(struct pseudo_hdr)+sizeof(struct sniff_tcp))); ..... if (sendto (sockfd ,datagram, iph->ip_len , 0, (struct sockaddr *) &sin, sizeof (sin)) < 0) { fprintf ( stdout , "Error sending datagram for port %d\n",i); break; } Επισης το ωραιο με αυτη τη struct ειναι οτι ειναι 12 (4+4+4(2+1+1))σε μεγεθος. Παραθετω output του gdb : 80 /* pseudo header for tcp checksum */ 81 struct pseudo_hdr *phdr = (struct pseudo_hdr *) ( datagram + 82 sizeof(struct sniff_ip) + sizeof(struct sniff_tcp) ) ; 83 phdr->src = iph->ip_src.s_addr; 84 phdr->dst = iph->ip_dst.s_addr; 85 phdr->mbz = 0; 86 phdr->proto = IPPROTO_TCP; 87 phdr->len = ntohs (0x14); /* in bytes the tcp segment length */ (gdb) list 88 /*- WhyTF is it network byte saved by default ????*/ 89 90 91 tcph->th_sum = htons ( checksum_comp ( (unsigned short *) tcph , 92 sizeof(struct pseudo_hdr)+sizeof(struct sniff_tcp))); 93 94 95 //printf ( "sizeof: %d \n" , sizeof(struct pseudo_hdr) ) ; 96 //printf ( "sizeof: %d \n" , sizeof( *(phdr) ) ) ; 97 (gdb) b 89 Breakpoint 1 at 0x8049d1c: file syn_scanning.c, line 89. (gdb) run -h 10.0.0.2 -S Starting program: /home/ithilgore/linux_programming/port_scan/creeper -h 10.0.0.2 -S filter exp: src host 10.0.0.2 Local IP: 10.0.0.4 Initiating Syn Scanning against 10.0.0.2 [1024 ports] Breakpoint 1, Syn_Scanning () at syn_scanning.c:91 91 tcph->th_sum = htons ( checksum_comp ( (unsigned short *) tcph , (gdb) print phdr $1 = (struct pseudo_hdr *) 0xbfffe378 (gdb) x /20x 0xbfffe378 0xbfffe378: 0x0400000a 0x0200000a 0x14000600 0x00000000 0xbfffe388: 0x00000000 0x00000000 0x00000000 0x00000000 0xbfffe398: 0x00000000 0x00000000 0x00000000 0x00000000 0xbfffe3a8: 0x00000000 0x00000000 0x00000000 0x00000000 0xbfffe3b8: 0x00000000 0x00000000 0x00000000 0x00000000 (gdb) Μας αφορουν οι 0xbfffe378: 0x0400000a 0x0200000a 0x14000600 πχ εδω source ip = 10.0.0.4 dest ip = 10.0.0.2 , reserved bits = 00 , ipproto =06 , header length = 1400 αλλα οτι και να ηταν απο τη στιγμη που ΔΕΝ κανουμε read δεν μας απασχολει. β ) Επισης το επομενο σημειο ειναι τα headers που διαβαζουμε. Εκει δεν υπαρχει περιπτωση να διαβασουμε κατι παραπανω καθως το ιδιο το *reading* το κανει η pcap με την dispatch οπου διαβαζει *πακετα* οχι απλα ενα καθορισμενο αριθμο bytes Οποτε σε αυτη την περιπτωση ειναι λιγο δυσκολο να βγουμε εκτος οριων. c) Τελος στο διαβασμα απο μας του πακετου ( στην got_packet ) , κανουμε access στο ιδιο το member της tcp struct ( tcp->th_flags ) . Θα πει κανεις ομως αν δεν ειναι packed τοτε πως ξερεις οτι εχει σωστη τιμη αυτο ? Αυτο με παρακινησατε (και καλα κανατε) να το δω παλι στον gdb ) οπου ειχα την εξης εξοδο: Breakpoint 2, got_packet (args=0x5
, header=0xbfffe240, packet=0x806a7d2 "") at packet_analysis.c:37 37 if ( ( (tcp->th_flags & 0x02) == TH_SYN) && ( tcp->th_flags & 0x10 ) == TH_ACK ) { (gdb) print ip $2 = (const struct sniff_ip *) 0x806a7e0 (gdb) print tcp $3 = (const struct sniff_tcp *) 0x806a7f4 (gdb) x /20x 0x806a7f4 0x806a7f4: 0xd2040100 0x00000000 0x6c8b4567 0x00001450 0x806a804: 0x000046a4 0x00000000 0x65640000 0x67726f03 0x806a814: 0x00010000 0x000cc001 0x00010001 0x00e7c400 0x806a824: 0x1b463e04 0x0010c076 0x00010002 0x00e7c400 0x806a834: 0x736e0306 0xc010c032 0x00020010 0xc4000001 κοιταξτε την πρωτη γραμμη: 0x806a7f4: 0xd2040100 0x00000000 0x6c8b4567 0x00001450 Αν συνεβαινε αυτο που λετε , τοτε το ACK sequence θα πρεπε να ηταν σε μια μη packed struct 0x00 και ομως ειναι 0x00000000 πραγμα απολυτως φυσιολογικο και καθωσπρεπει , αφου το ACK sequence ειναι 32 bit . Συνεπως ακομα και χωρις packed structs ο gcc και η libpcap που διαβασε στο data link layer μαλλον προνοησαν σωστα. Αλλα θα μπορουσε να σκεφτει κανεις και το αλλο: Κοιταξτε τα και γενικα τα επισημα headers. Δεν τα εχει πουθενα ως packed. Αυτο που λεω ειναι οτι θα μπορουσε να ειναι default συμπεριφορα ως attribute αλλα απο'τι φαινεται δεν χρειαζεται στις περιπτωσεις αυτες. Αυτα απο μενα. Καλη συζητηση παντως. ithilgore From advent.cloud.strife at gmail.com Fri Mar 30 01:21:41 2007 From: advent.cloud.strife at gmail.com (ithilgore) Date: Fri, 30 Mar 2007 01:21:41 +0300 Subject: Coding a SYN Scanner guide ( source included ) In-Reply-To: <20070329220146.GA22224@kobe.laptop> References: <460A9D69.1010506@gmail.com> <200703290055.57245.v13@it.teithe.gr> <460B20B3.9010804@gmail.com> <20070329120942.GA1943@kobe.laptop> <460C3673.60808@gmail.com> <20070329220146.GA22224@kobe.laptop> Message-ID: <460C3BF5.2050009@gmail.com> Giorgos Keramidas wrote: > On 2007-03-30 00:58, ithilgore wrote: > >> Καλη παρατηρηση γενικα και απο τους 2. Καταλαβα τι εννοειτε αλλα στον >> συγκεκριμενο κωδικα συμβαινουν τα εξης: >> α) Το pseudo header χρησιμοποιειται **μονο** για το datagram που >> στελνουμε και **μονο** για τον υπολογισμο του checksum : με αλλα λογια >> δεν χρησιμοποιειται πουθενα σε συνδυασμο με την read( ) >> >> Να θυμισω λιγο τον κωδικα : >> > > Δεν έχω δει τον κώδικα. Η σελίδα του αρχικού link κάνει timeout > όταν πάω να την ανοίξω. Οπότε μπορεί να σου λέω και κάτι άσχετο. > > >> Αλλα θα μπορουσε να σκεφτει κανεις και το αλλο: Κοιταξτε τα >> και γενικα τα επισημα headers. >> > > Εδώ πάλι διαφωνώ κάπως... > > Στο δικό μου λειτουργικό, που χρησιμοποιεί κι αυτό gcc για να κάνει > build τα πάντα, το netinet/ip.h header περιέχει: > > % /* > % * Structure of an internet header, naked of options. > % */ > % struct ip { > % #if BYTE_ORDER == LITTLE_ENDIAN > % u_int ip_hl:4, /* header length */ > % ip_v:4; /* version */ > % #endif > % #if BYTE_ORDER == BIG_ENDIAN > % u_int ip_v:4, /* version */ > % ip_hl:4; /* header length */ > % #endif > % u_char ip_tos; /* type of service */ > % u_short ip_len; /* total length */ > % u_short ip_id; /* identification */ > % u_short ip_off; /* fragment offset field */ > % #define IP_RF 0x8000 /* reserved fragment flag */ > % #define IP_DF 0x4000 /* dont fragment flag */ > % #define IP_MF 0x2000 /* more fragments flag */ > % #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ > % u_char ip_ttl; /* time to live */ > % u_char ip_p; /* protocol */ > % u_short ip_sum; /* checksum */ > % struct in_addr ip_src,ip_dst; /* source and dest address */ > % } __packed __aligned(4); > > Το linux έχει αρκετά πιο "περίεργες" ιδέες για το networking. > > >> Δεν τα εχει πουθενα ως packed. Αυτο που λεω ειναι οτι θα μπορουσε να >> ειναι default συμπεριφορα ως attribute αλλα απο'τι φαινεται δεν >> χρειαζεται στις περιπτωσεις αυτες. >> > > Μπα, νομίζω χρειάζεται (ειδικά στα netinet/* headers). > > Remember SPARC & SIGBUS :-) > > > Το link δεν δουλευει ? Περιεργο , οσοι το χουν κατεβασει ως τωρα δεν ειχαν προβλημα . Οσο για τα headers ουσιαστικα το ιδιο λεμε. Εγω λεω δεν χρειαζεται να ειναι packed ως απλα defined packed αφου αποσο ειδα και απο τον gdb ειναι packed by default ( δες το παραδειγμα με το ACK που ειπα ). Αυτο που λεω δηλαδη ειναι οτι μαλλον στο συστημα μου ,που το χω δοκιμασει επιτυχως ( Slackware 11 kernel 2.2.4.33 ) ,θα ειναι by default packed σε συμπεριφορα ακομα και αν δεν ειναι ορισμενο το attribute. ithilgore From v13 at it.teithe.gr Fri Mar 30 02:05:42 2007 From: v13 at it.teithe.gr (V13) Date: Fri, 30 Mar 2007 02:05:42 +0300 Subject: Coding a SYN Scanner guide ( source included ) In-Reply-To: <20070329220146.GA22224@kobe.laptop> References: <460A9D69.1010506@gmail.com> <460C3673.60808@gmail.com> <20070329220146.GA22224@kobe.laptop> Message-ID: <200703300205.42845.v13@it.teithe.gr> On Friday 30 March 2007 01:01, Giorgos Keramidas wrote: > Το linux έχει αρκετά πιο "περίεργες" ιδέες για το networking. Gia na to doyme ligo mazi: typedef u_int tcp_seq; struct sniff_tcp { u_short th_sport; /* source port */ u_short th_dport; /* destination port */ tcp_seq th_seq; /* sequence number */ tcp_seq th_ack; /* acknowledgement number */ u_char th_offx2; /* data offset, rsvd */ u_char th_flags; u_short th_win; /* window */ u_short th_sum; /* checksum */ u_short th_urp; /* urgent pointer */ }; u_short: 16bit tcp_seq: 32bit u_char: 8bit Ara exoyme: th_sport: offset 0 th_dport: 2 th_seq: 4 th_ack: 8 th_offx2: 12 th_flags: 13 th_win: 14 th_sum: 16 th_urp: 18 Sta prota 4 byte exei 2 16bitoys, opote einai 'packed' by default. Sth synexeia exei 2 32bitoys, opote epeisis no prob.. sth synexeia exei 2 8bitoys kai enan 16bito kai telos exei 2 16bitoys... Ola mia xara! Ola einai se sostes theseis mias kai den tygxanei na yparxei kapoio melos poy na ofeleitai apo peretero alignment... Epeisis, ayto paizei kai me 64bit mias kai exei metablites poy ksekinane sta offset 0, 8, 16... An pas sto /usr/src/linux/include/linux ths geitonias soy tha deis oti se kapoia merh, h packed xrhsimopoieitai (esto kai xoris logo)... Kai telos panton, 29.000.000 xristes toy linux[1] den mporei na min exoyn antimetopisei ayto to problima :-P <> [1] http://counter.li.org/ From advent.cloud.strife at gmail.com Fri Mar 30 02:20:54 2007 From: advent.cloud.strife at gmail.com (ithilgore) Date: Fri, 30 Mar 2007 02:20:54 +0300 Subject: Coding a SYN Scanner guide ( source included ) In-Reply-To: <20070329224855.GA22679@kobe.laptop> References: <460A9D69.1010506@gmail.com> <200703290055.57245.v13@it.teithe.gr> <460B20B3.9010804@gmail.com> <20070329120942.GA1943@kobe.laptop> <460C3673.60808@gmail.com> <20070329220146.GA22224@kobe.laptop> <460C3BF5.2050009@gmail.com> <20070329224855.GA22679@kobe.laptop> Message-ID: <460C49D6.4060808@gmail.com> Giorgos Keramidas wrote: > On 2007-03-30 01:21, ithilgore wrote: > >> Giorgos Keramidas wrote: >> >>> Εδώ πάλι διαφωνώ κάπως... >>> >>> Στο δικό μου λειτουργικό, που χρησιμοποιεί κι αυτό gcc για να κάνει >>> build τα πάντα, το netinet/ip.h header περιέχει: >>> >>> % /* >>> % * Structure of an internet header, naked of options. >>> % */ >>> % struct ip { >>> % #if BYTE_ORDER == LITTLE_ENDIAN >>> % u_int ip_hl:4, /* header length */ >>> % ip_v:4; /* version */ >>> % #endif >>> % #if BYTE_ORDER == BIG_ENDIAN >>> % u_int ip_v:4, /* version */ >>> % ip_hl:4; /* header length */ >>> % #endif >>> % u_char ip_tos; /* type of service */ >>> % u_short ip_len; /* total length */ >>> % u_short ip_id; /* identification */ >>> % u_short ip_off; /* fragment offset field */ >>> % #define IP_RF 0x8000 /* reserved fragment flag */ >>> % #define IP_DF 0x4000 /* dont fragment flag */ >>> % #define IP_MF 0x2000 /* more fragments flag */ >>> % #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ >>> % u_char ip_ttl; /* time to live */ >>> % u_char ip_p; /* protocol */ >>> % u_short ip_sum; /* checksum */ >>> % struct in_addr ip_src,ip_dst; /* source and dest address */ >>> % } __packed __aligned(4); >>> >>> Το linux έχει αρκετά πιο "περίεργες" ιδέες για το networking. >>> >> Το link δεν δουλευει ? Περιεργο , οσοι το χουν κατεβασει ως τωρα δεν >> ειχαν προβλημα . >> >> Οσο για τα headers ουσιαστικα το ιδιο λεμε. >> > > Ναι :) > > >> Εγω λεω δεν χρειαζεται να ειναι packed ως απλα defined packed αφου >> αποσο ειδα και απο τον gdb ειναι packed by default ( δες το παραδειγμα >> με το ACK που ειπα ). Αυτο που λεω δηλαδη ειναι οτι μαλλον στο >> συστημα μου ,που το χω δοκιμασει επιτυχως ( Slackware 11 kernel >> 2.2.4.33 ) ,θα ειναι by default packed σε συμπεριφορα ακομα και αν δεν >> ειναι ορισμενο το attribute. >> > > Το 'default' του ενός compiler μπορεί να μην είναι default στον άλλο, > όμως. Ακόμα και στον ίδιο compiler τα default options δε μπορεί να > θεωρούνται δεδομένα στο header file ή στο definition ενός struct. > > Στο magaz, αν γράψεις κάτι για το syn scanner, ίσως είναι καλή ιδέα να > χρησιμοποιήσεις το -fpack-struct option σε παραδείγματα που δείχνουν > πώς να γίνει compile κάτι. Π.χ. δες το παρακάτω πρόγραμμα: > > 1 #include > 2 > 3 struct A { > 4 char a_cf1; > 5 char a_cf2; > 6 unsigned long a_lf1; > 7 unsigned long a_lf2; > 8 }; > 9 > 10 struct B { > 11 char b_cf1; > 12 unsigned long b_lf1; > 13 char b_cf2; > 14 unsigned long b_lf2; > 15 }; > 16 > 17 int > 18 main(void) > 19 { > 20 struct A va; > 21 struct B vb; > 22 > 23 printf("sizeof A = %zu [%zu, %zu, %zu, %zu]\n", > 24 sizeof(va), > 25 (size_t)((unsigned char *)&(va.a_cf1) - (unsigned char *)&va), > 26 (size_t)((unsigned char *)&(va.a_cf2) - (unsigned char *)&va), > 27 (size_t)((unsigned char *)&(va.a_lf1) - (unsigned char *)&va), > 28 (size_t)((unsigned char *)&(va.a_lf2) - (unsigned char *)&va)); > 29 > 30 printf("sizeof B = %zu [%zu, %zu, %zu, %zu]\n", > 31 sizeof(vb), > 32 (size_t)((unsigned char *)&(vb.b_lf1) - (unsigned char *)&vb), > 33 (size_t)((unsigned char *)&(vb.b_cf1) - (unsigned char *)&vb), > 34 (size_t)((unsigned char *)&(vb.b_cf2) - (unsigned char *)&vb), > 35 (size_t)((unsigned char *)&(vb.b_lf2) - (unsigned char *)&vb)); > 36 > 37 return 0; > 38 } > > Ανάλογα με το αν χρησιμοποιηθεί το -fpack-struct option στο GCC, τα > αποτελέσματα είναι διαφορετικά: > > keramida at kobe:/home/keramida$ cc -O2 foo.c > keramida at kobe:/home/keramida$ ./a.out > sizeof A = 12 [0, 1, 4, 8] > sizeof B = 16 [4, 0, 8, 12] > keramida at kobe:/home/keramida$ cc -O2 -fpack-struct foo.c > keramida at kobe:/home/keramida$ ./a.out > sizeof A = 10 [0, 1, 2, 6] > sizeof B = 10 [1, 0, 5, 6] > keramida at kobe:/home/keramida$ > > Done . thanks for pointing out From keramida at ceid.upatras.gr Thu Mar 29 15:12:00 2007 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Thu, 29 Mar 2007 12:12:00 -0000 Subject: Coding a SYN Scanner guide ( source included ) In-Reply-To: <460B20B3.9010804@gmail.com> References: <460A9D69.1010506@gmail.com> <200703290055.57245.v13@it.teithe.gr> <460B20B3.9010804@gmail.com> Message-ID: <20070329120942.GA1943@kobe.laptop> On 2007-03-29 05:13, - wrote: >V13 wrote: >> Epeisis, to na xrisimopoieis etsi ta structs mallon problimata tha >> soy dimioyrgisei logo alignment kai reordering. Des to >> __attribute__((packed)) toy gcc. P.x. gia to IP: >> >> ---- >> struct pseudo_hdr { >> u_int32_t src; /* 32bit source ip address*/ >> u_int32_t dst; /* 32bit destination ip address */ >> u_char mbz; /* 8 reserved bits (all 0) */ >> u_char proto; /* protocol field of ip header */ >> u_int16_t len; /* tcp length (both header and data */ >> } __attribute__((packed)); >> ---- >> >> Des tin eksodo apo to parakato programma: >> ---- >> #include >> >> struct A { int a; char b; int c;}; >> >> struct B { int a; char b; int c; } __attribute__((packed)); >> >> int main() >> { >> printf("%d\n%d\n", sizeof(struct A), sizeof(struct B)); >> } >> ---- >> >> v13 at hell:/tmp$ ./a >> 12 >> 9 >> >> Opos blepeis, logo alignment, to proto struct epiase 12 bytes giati >> to c egine align sta 32bit (4 byte), opote kai to c ksekinoyse apo to >> +2*4. Ayto mporeis na to deis kanontas compile me to -Wpadded: > > thanx ! tetoiou eidous feedback perimenw. > implicit reordering mias struct den nomizw na ginetai kai sumfwna me > to C standard upo kanonikes sun8hkes den 8a prepei na ginetai Σωστός. > Twra gia to packing ston sugekrimeno kwdika mono gia ka8ara > optimization skopus ( < size ) tha eixe isws nohma. Αυτό όμως είναι λίγο λάθος. Έχει δίκιο ο Στέφανος (V13). Αν κάνεις malloc() 12 bytes για ένα object τύπου "struct A", μπορεί ο memory allocator να σου επιστρέψει τα παρακάτω bytes: A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 ___________ __ ___________ a b c Αν εσύ διαβάσεις από 'raw data' ένα πακέτο που έχει τιμές: a = 0x12345678 (4 bytes) b = 0xCC (1 byte) c = 0x23456789 (4 bytes) χρησιμοποιώντας απλά read() για όλο το struct κι όχι read() για κάθε member ξεχωριστά, μπορεί να προσπαθήσεις να διαβάσεις περισσότερα bytes από ότι είναι διαθέσιμα στο packet stream. Αν από την άλλη, για κάποιο λόγο όντως προσπαθήσεις να διαβάσεις 9 bytes, τα δεδομένα θα γραφτούν σε ένα struct A με τη μορφή: 12 34 56 78 CC 23 45 67 89 A5 A5 A5 ___________ __ ___________ a b c και δεν θα είναι πολύ σωστές οι τιμές των struct members. > To pseudo header allwste xrhsimopoieitai mono sto checksuming kai me ena > sizeof upologizetai pada swsta to mege8os. Δηλαδή, ακριβώς λόγω των "padding bytes" μπορεί να κάνεις checksum σε λάθος δεδομένα (επειδή π.χ. δεν έκανες memset() σε μηδέν όλα τα bytes πριν από *κάθε* read() call). Δεν είναι πιο εύκολο να χρησιμοποιήσεις "packed structures"; :-) From keramida at ceid.upatras.gr Fri Mar 30 01:04:12 2007 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Thu, 29 Mar 2007 22:04:12 -0000 Subject: Coding a SYN Scanner guide ( source included ) In-Reply-To: <460C3673.60808@gmail.com> References: <460A9D69.1010506@gmail.com> <200703290055.57245.v13@it.teithe.gr> <460B20B3.9010804@gmail.com> <20070329120942.GA1943@kobe.laptop> <460C3673.60808@gmail.com> Message-ID: <20070329220146.GA22224@kobe.laptop> On 2007-03-30 00:58, ithilgore wrote: > Καλη παρατηρηση γενικα και απο τους 2. Καταλαβα τι εννοειτε αλλα στον > συγκεκριμενο κωδικα συμβαινουν τα εξης: > α) Το pseudo header χρησιμοποιειται **μονο** για το datagram που > στελνουμε και **μονο** για τον υπολογισμο του checksum : με αλλα λογια > δεν χρησιμοποιειται πουθενα σε συνδυασμο με την read( ) > > Να θυμισω λιγο τον κωδικα : Δεν έχω δει τον κώδικα. Η σελίδα του αρχικού link κάνει timeout όταν πάω να την ανοίξω. Οπότε μπορεί να σου λέω και κάτι άσχετο. > Αλλα θα μπορουσε να σκεφτει κανεις και το αλλο: Κοιταξτε τα > και γενικα τα επισημα headers. Εδώ πάλι διαφωνώ κάπως... Στο δικό μου λειτουργικό, που χρησιμοποιεί κι αυτό gcc για να κάνει build τα πάντα, το netinet/ip.h header περιέχει: % /* % * Structure of an internet header, naked of options. % */ % struct ip { % #if BYTE_ORDER == LITTLE_ENDIAN % u_int ip_hl:4, /* header length */ % ip_v:4; /* version */ % #endif % #if BYTE_ORDER == BIG_ENDIAN % u_int ip_v:4, /* version */ % ip_hl:4; /* header length */ % #endif % u_char ip_tos; /* type of service */ % u_short ip_len; /* total length */ % u_short ip_id; /* identification */ % u_short ip_off; /* fragment offset field */ % #define IP_RF 0x8000 /* reserved fragment flag */ % #define IP_DF 0x4000 /* dont fragment flag */ % #define IP_MF 0x2000 /* more fragments flag */ % #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ % u_char ip_ttl; /* time to live */ % u_char ip_p; /* protocol */ % u_short ip_sum; /* checksum */ % struct in_addr ip_src,ip_dst; /* source and dest address */ % } __packed __aligned(4); Το linux έχει αρκετά πιο "περίεργες" ιδέες για το networking. > Δεν τα εχει πουθενα ως packed. Αυτο που λεω ειναι οτι θα μπορουσε να > ειναι default συμπεριφορα ως attribute αλλα απο'τι φαινεται δεν > χρειαζεται στις περιπτωσεις αυτες. Μπα, νομίζω χρειάζεται (ειδικά στα netinet/* headers). Remember SPARC & SIGBUS :-) From keramida at ceid.upatras.gr Fri Mar 30 01:53:35 2007 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Thu, 29 Mar 2007 22:53:35 -0000 Subject: Coding a SYN Scanner guide ( source included ) In-Reply-To: <460C3BF5.2050009@gmail.com> References: <460A9D69.1010506@gmail.com> <200703290055.57245.v13@it.teithe.gr> <460B20B3.9010804@gmail.com> <20070329120942.GA1943@kobe.laptop> <460C3673.60808@gmail.com> <20070329220146.GA22224@kobe.laptop> <460C3BF5.2050009@gmail.com> Message-ID: <20070329224855.GA22679@kobe.laptop> On 2007-03-30 01:21, ithilgore wrote: > Giorgos Keramidas wrote: > >Εδώ πάλι διαφωνώ κάπως... > > > >Στο δικό μου λειτουργικό, που χρησιμοποιεί κι αυτό gcc για να κάνει > >build τα πάντα, το netinet/ip.h header περιέχει: > > > >% /* > >% * Structure of an internet header, naked of options. > >% */ > >% struct ip { > >% #if BYTE_ORDER == LITTLE_ENDIAN > >% u_int ip_hl:4, /* header length */ > >% ip_v:4; /* version */ > >% #endif > >% #if BYTE_ORDER == BIG_ENDIAN > >% u_int ip_v:4, /* version */ > >% ip_hl:4; /* header length */ > >% #endif > >% u_char ip_tos; /* type of service */ > >% u_short ip_len; /* total length */ > >% u_short ip_id; /* identification */ > >% u_short ip_off; /* fragment offset field */ > >% #define IP_RF 0x8000 /* reserved fragment flag */ > >% #define IP_DF 0x4000 /* dont fragment flag */ > >% #define IP_MF 0x2000 /* more fragments flag */ > >% #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ > >% u_char ip_ttl; /* time to live */ > >% u_char ip_p; /* protocol */ > >% u_short ip_sum; /* checksum */ > >% struct in_addr ip_src,ip_dst; /* source and dest address */ > >% } __packed __aligned(4); > > > >Το linux έχει αρκετά πιο "περίεργες" ιδέες για το networking. > > Το link δεν δουλευει ? Περιεργο , οσοι το χουν κατεβασει ως τωρα δεν > ειχαν προβλημα . > > Οσο για τα headers ουσιαστικα το ιδιο λεμε. Ναι :) > Εγω λεω δεν χρειαζεται να ειναι packed ως απλα defined packed αφου > αποσο ειδα και απο τον gdb ειναι packed by default ( δες το παραδειγμα > με το ACK που ειπα ). Αυτο που λεω δηλαδη ειναι οτι μαλλον στο > συστημα μου ,που το χω δοκιμασει επιτυχως ( Slackware 11 kernel > 2.2.4.33 ) ,θα ειναι by default packed σε συμπεριφορα ακομα και αν δεν > ειναι ορισμενο το attribute. Το 'default' του ενός compiler μπορεί να μην είναι default στον άλλο, όμως. Ακόμα και στον ίδιο compiler τα default options δε μπορεί να θεωρούνται δεδομένα στο header file ή στο definition ενός struct. Στο magaz, αν γράψεις κάτι για το syn scanner, ίσως είναι καλή ιδέα να χρησιμοποιήσεις το -fpack-struct option σε παραδείγματα που δείχνουν πώς να γίνει compile κάτι. Π.χ. δες το παρακάτω πρόγραμμα: 1 #include 2 3 struct A { 4 char a_cf1; 5 char a_cf2; 6 unsigned long a_lf1; 7 unsigned long a_lf2; 8 }; 9 10 struct B { 11 char b_cf1; 12 unsigned long b_lf1; 13 char b_cf2; 14 unsigned long b_lf2; 15 }; 16 17 int 18 main(void) 19 { 20 struct A va; 21 struct B vb; 22 23 printf("sizeof A = %zu [%zu, %zu, %zu, %zu]\n", 24 sizeof(va), 25 (size_t)((unsigned char *)&(va.a_cf1) - (unsigned char *)&va), 26 (size_t)((unsigned char *)&(va.a_cf2) - (unsigned char *)&va), 27 (size_t)((unsigned char *)&(va.a_lf1) - (unsigned char *)&va), 28 (size_t)((unsigned char *)&(va.a_lf2) - (unsigned char *)&va)); 29 30 printf("sizeof B = %zu [%zu, %zu, %zu, %zu]\n", 31 sizeof(vb), 32 (size_t)((unsigned char *)&(vb.b_lf1) - (unsigned char *)&vb), 33 (size_t)((unsigned char *)&(vb.b_cf1) - (unsigned char *)&vb), 34 (size_t)((unsigned char *)&(vb.b_cf2) - (unsigned char *)&vb), 35 (size_t)((unsigned char *)&(vb.b_lf2) - (unsigned char *)&vb)); 36 37 return 0; 38 } Ανάλογα με το αν χρησιμοποιηθεί το -fpack-struct option στο GCC, τα αποτελέσματα είναι διαφορετικά: keramida at kobe:/home/keramida$ cc -O2 foo.c keramida at kobe:/home/keramida$ ./a.out sizeof A = 12 [0, 1, 4, 8] sizeof B = 16 [4, 0, 8, 12] keramida at kobe:/home/keramida$ cc -O2 -fpack-struct foo.c keramida at kobe:/home/keramida$ ./a.out sizeof A = 10 [0, 1, 2, 6] sizeof B = 10 [1, 0, 5, 6] keramida at kobe:/home/keramida$