On Wed, Mar 14, 2007 at 06:23:00PM +0100, Wojtek Kaniewski wrote: > Jakub 'darkjames' Zawadzki napisał(a): > > (...) > Mógłbyś się podzielić zrzutami, jeśli nie przesyłałeś żadnych tajnych > danych? Miałem problem, żeby pobawić się nowym GG na jednej maszynie z > windowsami, a co dopiero z dwoma ;) W gadu-gadu teraz wystarczy zaznaczyc opcje 'Zezwalaj na wielokrotne i uruchomienie' A co do pakietow.. No ja jestem na etapie wprowadzania zmian w libgadu. Zrzutow nie mam, bo to jest sniffowane z ekg2 ;)
[Ktory moze nie jest super net-toolem, nie umie incjectowac pakietow, nie umie arp-poisoningu, zmieniac pakietow, ani zapisywac ich na dysk, itd... Ba, nawet nie umie laczyc pakietow, ani nie obsluguje flag tcp, ale do gadu-gadu sie swietnie nadaje ;)] Ktory ewentualnie zrzuca ze jedna wartosc w pakiecie sie nie zgadza z tym co byc powinno [Jesli jest to w jakims tam stopniu constant] [Lub jesli jest zawsze unknown to zawsze zrzuca]... Na szczescie z tego co testowalem to w tych polach unknown nawet jak beda 0x00, to i tak klient windowsowy zaakceptuje takie polaczenie... Wiem, wypadaloby jak najmniej psuc protokol, i trzeba jeszcze poglowkowach nad tymi polami. Ale to jest do zrobienia w czasie... Tutaj aktualna wersja kodu: http://webcvs.ekg2.org/_checkout_/ekg2/plugins/sniff/sniff.c?rev=1.28 [czytac od komentarza: /* nie w libgadu */] [Krotki komentarz nt. znanych wartosci: sa one zapisane w porzadku sieciowym.. czyli BE, czyli prosze sie nie dziwic gdy jest: np: CHECK_PRINT(pkt->dunno6, htonl(0x10000000)); to jest 0x10 w LE, wiem, mniej czytelne.. Ale kiedys bylo tak latwiej widac roznice w pakietach.] [PS678: jesli ktos chce wykorzystac plugin ekg2 do sniffowania polaczen gg, to trzeba dodac sobie do configure.ac + ./autogen.sh zeby wygenerowal Makefile dla plugina albo wywolac autotoolsy by hand. I potem /plugin +sniff /session -a sniff:urzadzenie_na_ktorym_pcap_ma_nasluchiwac /session auto_connect 1 /session alias snifus /connect I ewentualnie przed /connect zmodyfikowac /session filter jesli chcemy zeby pcap korzystal z innego filtru niz: "tcp and net 217.17.41.80/28 or net 217.17.45.128/27 and tcp" pewnie niepotrzebne dwa razy tcp. ale just in case. Wymagane uprawnienia roota pod linuksem, ekg2 ani plugin raczej nie sa explotiable. Ale jak ktos sie boi, to nie tykac. Na licencji GPL-2 jest, Without warranty.] A protokol mniej wiecej wyglada tak: Gdy wyslalamy plik: - gdy chcemy dostac jakies unikatowe id dcc z serwera (ten 8 bajtowy kod), wysylamy: GG_DCC_NEW_REQUEST_ID [0x20]. Serwer nam pakietem o tym samym id [0x20]. [Funkcje: sniff_gg_dcc_new_request_id_out(), sniff_gg_dcc_new_request_id_in()] W sumie jak nie wyslemy/dostaniemy tego pakietu, to nic zlego sie nie dzieje. Ewentualnie (chyba) nie bedziemy mogli wysylac danych przez jakis ichnij serwer [Bo te nowe dcc maja dzialac nawet gdy obie strony sa za ogniomurkiem]. - Wysylamy pakiet GG_DCC_NEW 0x20 [w libgadu GG_DCC7_NEW] (strukturka gg_dcc_new, funkcja: sniff_gg_dcc_new()) XXX, calkiem mozliwe ze na plik moze byc wiecej niz 226 znakow, moj windows ma vfata, i tylko tak dlugi plik mi pozwolil stworzyc. moze on jest blizszy temu (GG_MAX_PATH-14) z gg_file_info.filename... Jesli tak to by bylo fajniej ;) Mniej pol w strukturze do zgadywania. A deweloperzy gadu-gadu tez jakos dziwnie zrobili, bo tam nawet jak jest mniejsza dlugosc pliku nie ma \0\0.. sa rozne wartosci. Czyzby nie czyscili strukturki przed wyslaniem? dunno32 jest zwykle rowne dunno8, i tam jest 0x3f.. Ale tez nie zawsze, czasami w jednym jest 0x40, czasami inne wartosci. zupelnie nieznane sa: dunno31, oraz dunno7 [wiem duzo dunno, duzo empty, dlatego nie chcialem sie chwalic ;)] Tutaj peer powinien dostac info o tym ze chcemy mu wyslac plik, i albo nam wysyla pakiet: GG_DCC_1XXX [0x21] w libgadu: GG_DCC7_ACCEPT, z miejscem od ktorego chce zebysmy mu wysylali dane... albo: GG_DCC_REJECT_XXX [0x22] w libgadu: GG_DCC7_REJECT, z powodem dlaczego nie. Ponizej juz z libgadu.h #define GG_DCC7_REJECT_TRY_LATER 0x01 /* 7.6.0 nie umie wysyla kilku dcc na raz, wysyla ten pakiet kiedy kod/protokol nie potrafi obsluzyc. 'Komunikat: xyz wlasnie przesyla inny plik' */ #define GG_DCC7_REJECT_REJECTED 0x02 /* 7.6.0 wysyla wtedy gdy klikniemy rejected... czym sie to rozni od pozostalych, nie stwierdzono 'Komunikat: xyz odrzucil twoj plik' */ #define GG_DCC7_REJECT_INVALID_VERSION 0x06 /* 7.6.0 wysyla wtedy gdy dla niego nasz protokol jest mniej trendy do przesylania plikow 'Komunikat: xyz odrzucil twoj plik' */ Potem wymiana informacji o polaczeniu dcc przez GG_DCC_2XXX [0x1f] w libgadu: GG_DCC7_INFO.. w ktorym mamy informacje o stanie polaczenia.. O ip+porcie z jakiego sie laczymy, lub na jaki mamy sie laczyc I pewnie jeszcze inny wesole rzeczy. W ogole fajny ten protokol. [ W gg_dcc_new.uin1 np mozemy podac nie swoj uin, i tez zadziala ;)] Przy polaczeniach p2p jak juz sie laczymy na ten np. :1550, to zamiast uidow na poczatku, dostajemy/wysylamy 8 bajtow kodu.... Co sie potem dzieje, na razie nie wiem/i brak czasu. Niestety ten nowy protokol wymaga troche wiekszych zmian w api libgadu, niz myslalem... Aktualnie sa funkcje ktore wysylaja chec wyslania pliku.. Przemianowalem gg_dcc_fill_file_info2() na gg_dcc_fill_file_info3() ktory sie rozszerzyl o jeden parametr.. Miejsce gdzie ma wpisac hash pliku. Dodalem tez obsluge odrzucenia dcc, oraz akceptacji... Ale nadal brakuje obslugi samych polaczen p2p na :1550... Potem jeszcze trzeba dodac obsluge laczenia sie przez jakis peer, jesli nie mamy p2p... I duzo innych fajnych rzeczy. Na razie probuje sie zmiescic w strukturze gg_dcc. Ale nie wiem czy nie trzeba bedzie zrobic gg_dcc7 chociazby na trzymanie tego 8 bajtowego kodu. [Co wymaga jesli nawet nie zmian w api, to sporych zmian w ABI] Postam sie podrzucic patcha, ale wolalbym zebys wczesniej wrzucil ta obsluge nowego logowania.. Przy okazji bym wykorzystal API do robienia hasha z pliku (bo to tez sha1 ;)] > W tej chwili mamy warunkową obsługę zmiennych long long (też w DCC) do > obliczania czasu pliku. Jeśli to będzie naprawdę konieczne, możemy > zacząć wymagać uint64_t, chociaż wolałbym zrobić typedef zależny od > platformy: uint64_t albo uint8_t[8]. Przy czym nadal zamiast: jednocos = drugiecos, bedzie trzeba robic memcpy(jednocos, drugiecos, sizeof(jednocos)) ;) Spiacy, mail taki sobie. Hope, ze jakos sensownie napisany.. Ewentualnie przepraszac. Dobrej. _______________________________________________ libgadu-devel mailing list [email protected] http://lists.ziew.org/mailman/listinfo/libgadu-devel
