Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Europejski lider sprzedaży techniki i elektroniki.
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Satel: monitoring po TCP/IP

mackoj 13 Mar 2012 15:51 15592 53
  • #31 13 Mar 2012 15:51
    Barry83
    Poziom 12  

    toruviel napisał:
    Rozważam by w najbliższym czasie rozłożyć na czynnik pierwsze na użytek własny protokół tcp/ip korzystając z wyników prac xckrzysin (bardzo cenne!!). Mam do dyspozycji centrale, moduł, pełną infrastrukturę odbiorczą, oraz możliwość weryfikacji (i samodzielnego ustalania) treści wszystkich komunikatów nadawanych co powinno znacząco usprawnić proces, gdyż będę z góry wiedział co jest w pakiecie.

    Czy na to będzie w ogóle zapotrzebowanie?

    Aha i jedno pytanie robocze do xckrzysin: skąd wniosek że pakiety po zdekodowaniu (aes192) są poprawne, skoro nie interpretowałeś ich zawartości?

    p.s. jestem tu nowy, więc z góry przepraszam za słabszą jeszcze znajomość reguł itp.



    Stacji monitorującej z tego nie zrobisz kolego, jedynie możesz jakąś pamięć zdarzeń odczytać. Nie wiem czy to coś wniesie wielkiego ,bo od tego masz program GuardX którym możesz też zarządzać centralą, jak chcesz realizować monitoring wielu central do jednego komputera? na jakiej zasadzie będą one się meldować (która jest która). Myślę że szkoda czasu Twojego kolego. Napisz jakiś soft do urządzeń z otwartym protokołem.

  • #32 13 Mar 2012 16:09
    toruviel
    Poziom 8  

    Barry83 napisał:

    Stacji monitorującej z tego nie zrobisz kolego, jedynie możesz jakąś pamięć zdarzeń odczytać. Nie wiem czy to coś wniesie wielkiego ,bo od tego masz program GuardX którym możesz też zarządzać centralą, jak chcesz realizować monitoring wielu central do jednego komputera? na jakiej zasadzie będą one się meldować (która jest która). Myślę że szkoda czasu Twojego kolego. Napisz jakiś soft do urządzeń z otwartym protokołem.


    Wydaje mi się że zrobię. Albo inaczej, niekoniecznie ja dam rade, ale zrobić się da. Idąc po kolei: w ramach protokołu contactid, którego komunikaty są przesyłane, jest w środku identyfikator centrali, więc tak, da sie realizować monitoring wielu central. Natomiast zanalizowałem jeszcze dokumentacje ethm-2 od satela i wynika że to (ethm-2) jest urządzenie które jest dedykowane do komunikacji ze stacją odbiorczą (czyli tym czego w przypadku reverse engineeringu protokołu, nie będziemy musieli mieć).

    Pytanie na teraz więc brzmi troche inaczej:
    1. czy ETHM-1 nie posiada też funkcji przekazywania sygnałów z centrali integra do STAM-1 - zwracam uwage na zapis z dokumentacji do ETHM-1, cytuje: "Moduł z oprogramowaniem w wersji 1.02 lub wyższej umożliwia centralom alarmowym z serii INTEGRA (wersja programowa 1.04 i wyżej) realizację monitoringu za pośrednictwem sieci Ethernet."
    2. co z tematem ETHM-2 - niezależnie od ETHM-1, jego też można wziąć na warsztat.

    Pracowałem przy urządzeniach wielu różnych producentów (oprócz satela) więc wiem czego się spodziewać.

  • #33 13 Mar 2012 16:18
    xckrzysin
    Poziom 11  

    Jak napisałem wcześniej:

    Cytat:

    To co już napisałem wystarczy średno inteligentnemu człowiekowi poznać protokół i napisać własną stacje monitoringu.


    Z czego można wywnioskować (lub nie jak widać), że poznałem protokół i mam własną stacje monitoringu już napisaną.

    PS.
    Nie, na razie jej nie udostępnię. Protokół opiszę podobnie jak kolega opisał w bliźniaczym wątku z GuardX. Jednak obecnie nie mam na to czasu.

    PS2. Wszystkie pakiety po zdekodowaniu rozpoczynają się od:
    ethm lub eth1

    PS3. Jeśli chodzi o cbc to sporo czasu zeszło mi nim wpadłem jak jest traktowy ostatni pakiet mniejszy od 16 bajtów, jest tam robiony zwykły xor jak dobrze pamiętam ostatniego IV z tym małym blokiem.

  • #34 13 Mar 2012 16:34
    toruviel
    Poziom 8  

    xckrzysin napisał:

    PS3. Jeśli chodzi o cbc to sporo czasu zeszło mi nim wpadłem jak jest traktowy ostatni pakiet mniejszy od 16 bajtów, jest tam robiony zwykły xor jak dobrze pamiętam ostatniego IV z tym małym blokiem.


    Czy to oznacza że jest to robione inaczej niż w standardzie AES/CBC?

  • #35 13 Mar 2012 16:35
    Barry83
    Poziom 12  

    xckrzysin napisał:
    Jak napisałem wcześniej:
    Cytat:

    To co już napisałem wystarczy średno inteligentnemu człowiekowi poznać protokół i napisać własną stacje monitoringu.


    Z czego można wywnioskować (lub nie jak widać), że poznałem protokół i mam własną stacje monitoringu już napisaną.

    PS.
    Nie, na razie jej nie udostępnię. Protokół opiszę podobnie jak kolega opisał w bliźniaczym wątku z GuardX. Jednak obecnie nie mam na to czasu.

    PS2. Wszystkie pakiety po zdekodowaniu rozpoczynają się od:
    ethm lub eth1

    PS3. Jeśli chodzi o cbc to sporo czasu zeszło mi nim wpadłem jak jest traktowy ostatni pakiet mniejszy od 16 bajtów, jest tam robiony zwykły xor jak dobrze pamiętam ostatniego IV z tym małym blokiem.



    Aby wspomagać Twoje testy chętnie zamonitoruję się do Twojej stacji. Proszę o dane jak mam skonfigurować ETHM

  • #36 13 Mar 2012 16:41
    xckrzysin
    Poziom 11  

    toruviel napisał:
    xckrzysin napisał:

    PS3. Jeśli chodzi o cbc to sporo czasu zeszło mi nim wpadłem jak jest traktowy ostatni pakiet mniejszy od 16 bajtów, jest tam robiony zwykły xor jak dobrze pamiętam ostatniego IV z tym małym blokiem.


    Czy to oznacza że jest to robione inaczej niż w standardzie AES/CBC?


    Aes szyfruje 16 bajtowe bloki.
    CBC rozbiera większe ciągi danych na takie bloki i je szyfruje. Może to robić na różne sposoby.

    http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation

  • #37 13 Mar 2012 17:00
    toruviel
    Poziom 8  

    xckrzysin napisał:

    Aes szyfruje 16 bajtowe bloki.
    CBC rozbiera większe ciągi danych na takie bloki i je szyfruje. Może to robić na różne sposoby.

    http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation


    Dlatego właśnie pisałem żeby oszczędzić sobie pracy ze zgadywaniem dot. paddingu, tudzież czy próbowac sposoby opisane w http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Padding czy też Satel ma coś konkretnie swojego.

    Dziękuje za informacje!

  • #38 13 Mar 2012 17:07
    xckrzysin
    Poziom 11  

    toruviel napisał:
    xckrzysin napisał:

    Dlatego właśnie pisałem żeby oszczędzić sobie pracy ze zgadywaniem dot. paddingu, tudzież czy próbowac sposoby opisane w http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Padding czy też Satel ma coś konkretnie swojego.

    Dziękuje za informacje!



    Cieszę się, że mogłem pomóc. Jak będziesz miał pytania związane z protokołem pisz. W miarę możliwości będę pomagać.

    Pozdrawiam

  • #39 13 Mar 2012 17:44
    mackoj
    Poziom 7  

    O tak tak! Dla mnie będzie bardzo pomocne!
    Jak rozumiem mówisz o rozkładzie na czynniki pierwsze komunikacji ze stacją monitorującą?

  • #40 13 Mar 2012 17:51
    Barry83
    Poziom 12  

    mackoj napisał:
    O tak tak! Dla mnie będzie bardzo pomocne!
    Jak rozumiem mówisz o rozkładzie na czynniki pierwsze komunikacji ze stacją monitorującą?


    Tu jeszcze chłopaki Stama by potrzebowali

  • #41 13 Mar 2012 21:28
    toruviel
    Poziom 8  

    Barry83 napisał:

    Tu jeszcze chłopaki Stama by potrzebowali


    Nie. Nie potrzebowali by. To co zrobimy właśnie WYELIMINUJE konieczność używania kupowania stama, gdyż np. samo wystawi odpowiedni socket nasłuchujący, odbierze komunikat, potwierdzi, zrealizuje co trzeba.

    Po przeczytaniu Twoich wypowiedzi mam jedno pytanie wprost: pracujesz dla Satela? Albo dystrybutora jego produktów?

    Nie musisz odpowiadać :)

  • #42 13 Mar 2012 21:41
    Barry83
    Poziom 12  

    toruviel napisał:
    Barry83 napisał:

    Tu jeszcze chłopaki Stama by potrzebowali


    Nie. Nie potrzebowali by. To co zrobimy właśnie WYELIMINUJE konieczność używania kupowania stama, gdyż np. samo wystawi odpowiedni socket nasłuchujący, odbierze komunikat, potwierdzi, zrealizuje co trzeba.

    Po przeczytaniu Twoich wypowiedzi mam jedno pytanie wprost: pracujesz dla Satela? Albo dystrybutora jego produktów?

    Nie musisz odpowiadać :)



    wyciągasz bardzo daleko idące wnioski , a mi chodziło o to że jak chcesz wiedzieć jak odpowiada stam to musiałbyś go chyba mieć? hmm?

    P.S. Jestem sceptycznie nastawiony bo dużo piszesz a dowodów brak.

  • #43 13 Mar 2012 21:59
    toruviel
    Poziom 8  

    Barry83 napisał:

    wyciągasz bardzo daleko idące wnioski , a mi chodziło o to że jak chcesz wiedzieć jak odpowiada stam to musiałbyś go chyba mieć? hmm?

    P.S. Jestem sceptycznie nastawiony bo dużo piszesz a dowodów brak.



    Masz racje co do ramek z potwierdzeniami. Zobaczymy. Na razie było to tylko pisanie tutaj.

  • #44 13 Mar 2012 22:01
    Barry83
    Poziom 12  

    toruviel napisał:
    Barry83 napisał:

    wyciągasz bardzo daleko idące wnioski , a mi chodziło o to że jak chcesz wiedzieć jak odpowiada stam to musiałbyś go chyba mieć? hmm?

    P.S. Jestem sceptycznie nastawiony bo dużo piszesz a dowodów brak.



    Masz racje co do ramek z potwierdzeniami. Zobaczymy. Na razie było to tylko pisanie tutaj.


    Widocznie każdy kto nie wierzy w opowieści dziwnej treści pracuje dla satela :> a może kolega sam pracuje a tu się popisuje :P a nie może się podzielić wynikami prac bo to służbowe :P

  • #45 13 Mar 2012 22:25
    toruviel
    Poziom 8  

    Barry83 napisał:

    Widocznie każdy kto nie wierzy w opowieści dziwnej treści pracuje dla satela :> a może kolega sam pracuje a tu się popisuje :P a nie może się podzielić wynikami prac bo to służbowe :P


    Nie. Po prostu ktoś kto pisze bdzury o niemożności identyfikacji różnych centralek oraz piszę o 'nadsłuchiwaniu stałego połączenia' oraz nie rozumiejący jak to działa, rzeczywiście ma coś na sumieniu? Nie ważne. Czas przyniesie rozwiązanie. Bez odbioru z mojej strony.

  • #46 13 Mar 2012 22:35
    Barry83
    Poziom 12  

    toruviel napisał:
    Barry83 napisał:

    Widocznie każdy kto nie wierzy w opowieści dziwnej treści pracuje dla satela :> a może kolega sam pracuje a tu się popisuje :P a nie może się podzielić wynikami prac bo to służbowe :P


    Nie. Po prostu ktoś kto pisze bdzury o niemożności identyfikacji różnych centralek oraz piszę o 'nadsłuchiwaniu stałego połączenia' oraz nie rozumiejący jak to działa, rzeczywiście ma coś na sumieniu? Nie ważne. Czas przyniesie rozwiązanie. Bez odbioru z mojej strony.


    Co do nasluchiwania to odnosilo się to do opisow z pdf z innego watku. Jak kolega pisze ze jego stacja juz dziala i potwierdza i zrobil to bez stama to mi nie pasuje, do tego tekst typu " wiem ale nie powiem" .

    P.S. Co do jednego masz rację, nie jestem specjalistą w tej dziedzinie, więc wycofam się z dyskusji i poczekam na wynik

  • #47 14 Mar 2012 22:07
    depmar
    Poziom 2  

    Witam, Podlacze sie do tematu.
    Pisze aplikacje komunikujaca sie z centrala Integra za pomoca modulu ETHM1 i protokolu INT RS po tcp/ip. Mam problem z poprawna konfiguracja portu integracji w module ETHM1. Nie mam fizycznego dostepu do modulu i musze polegac na tym co zostanie ustawione w odleglym miejscu. Probuje sie laczyc z rzekomo ustawionym portem integracji za pomoca telnetu, jednak dostaje komunikat Unable to connect to remote host: Connection refused.
    Czy przy poprawnie skonfigurowanym porcie integracji, urzadzenie powinno zwrocic jakis ciag bajtow? W opcjach konfiguracji portu integracji jest mozliwosc kodowania integracji, ale jak mnie zapewniono jest ona w tym momencie wylaczona.

    Przy polaczeniu z innym portem dostaje w odpowiedzi jakis ciag bajtow jednak ten ciag nie jest zgodny z tym, ktory zaklada specyfikacja protokolu INT RS. Przypuszczalnie port ten jest portem wykorzystywanym przy polaczeniu z programu DloadX albo GuardX bowiem trzykrotna proba wyslania czegos na ten port konczy sie zablokowaniem komunikacji z urzadzeniem. Jesto to zgodne z tym co podaje intrukcja do modulu ETHM1. Niestety dostepna na stronie Satela instrukcja jest nieaktualna i nie zawiera opisu konfiguracji portu integracji, ktory zostal dodany w ostatniej aktualizacji firmware'u do modulu.

  • #48 16 Mar 2012 13:09
    bobi1326
    Poziom 19  

    Aktualnie mam podpiętą w sieci za pośrednictwem ETHM 1 Integrę. Jest ona dla próbowania ustawień także mogę udostępnić ją do pracy w tworzeniu oprogramowania ;)

  • #49 17 Mar 2012 17:25
    Artur S.
    Poziom 11  

    mam kilka central integra z ethmem, ethm 1 ze 2 szt. i odbiornik smet256 więc jakby ktoś potrzebował żeby coś wysłać albo odebrać to służę pomocą..

  • #50 18 Mar 2012 19:15
    depmar
    Poziom 2  

    Dzięki. Póki co podpialem integre przez port szeregowy i uruchomilem na komputerze aplikacje -serwer tcp/ip ktory pozwala sie podlaczyc po ethernecie i przesyla dane przez port szeregowy do integry. W ten sposob wyeliminowalem chwilowo potrzebe posiadania modulu ETHM1.

  • #52 19 Mar 2012 13:15
    acc007
    Poziom 9  

    Ale się rozkręciła dyskusja :) Koledzy, a czy ktoś próbował już w praktyce zastosować wskazówki które padły w tym wątku, czy tylko czekacie na gotowe rozwiązanie bądź negujecie możliwość utworzenia software'owej stacji STAM ?

    Kolega xckrzysin pisał o niestandardowym CBC... a ja sobie tak myślę, że zapewne ponownie można wykorzystać kody udostępnione przez Satel w MobileKPD (opisałem to w swoim wątku o GuardX) i w ten sposób próbować dekodować pakiety. Bez główkowania czym jest IV, co zrobić z ostatnim blokiem... no i w Javie, więc jakaś alternatywa do Perla tu przedstawianego

    I głęboko wierzę w to, że da się napisać STAM'a software'owego i w logu zdarzeń mieć same PLUSy ;)

  • #53 20 Mar 2012 13:13
    xckrzysin
    Poziom 11  

    acc007 napisał:

    Kolega xckrzysin pisał o niestandardowym CBC... a ja sobie tak myślę, że zapewne ponownie można wykorzystać kody udostępnione przez Satel w MobileKPD (opisałem to w swoim wątku o GuardX) i w ten sposób próbować dekodować pakiety. Bez główkowania czym jest IV, co zrobić z ostatnim blokiem... no i w Javie, więc jakaś alternatywa do Perla tu przedstawianego


    Cbc jest jak najbardziej standardowe, jednak zastosowany padding nie jest wspierany przez znane mi biblioteki perla. Dlatego zrobiłem małego patha dla Crypt::CBC na wersje 2.30
    Code:

    --- /usr/share/perl5/Crypt/CBC.pm       2008-09-30 17:11:49.000000000 +0200
    +++ ./CBC.pm    2012-01-28 23:16:36.000000000 +0100
    @@ -238,7 +238,8 @@
         $self->{'buffer'} = '';

         if ($d) {  # when decrypting, always leave a free block at the end
    -      $self->{'buffer'} = length($blocks[-1]) < $bs ? join '',splice(@blocks,-2) : pop(@blocks);
    +#      $self->{'buffer'} = length($blocks[-1]) < $bs ? join '',splice(@blocks,-2) : pop(@blocks);
    +      $self->{'buffer'} =  pop(@blocks) if length($blocks[-1]) < $bs;
         } else {
           $self->{'buffer'} = pop @blocks if length($blocks[-1]) < $bs;  # what's left over
         }
    @@ -265,7 +266,8 @@
         $self->{civ} ||= '';

         my $result;
    -    if ($self->{'decrypt'}) { #decrypting
    +  #  if ($self->{'decrypt'}) { #decrypting
    +    if (0) { #decrypting
            $block = length $block ? pack("a$bs",$block) : ''; # pad and truncate to block size

            if (length($block)) {
    @@ -276,8 +278,10 @@
            }

         } else { # encrypting
    -      $block  = $self->{'padding'}->($block,$bs,'e') || '';
    -      $result = length $block ? $self->{'crypt'}->encrypt($self->{'civ'} ^ $block) : '';
    +  #    $block  = $self->{'padding'}->($block,$bs,'e') || '';
    + #     $result = length $block ? $self->{'crypt'}->encrypt($self->{'civ'} ^ $block) : '';




    +      my $len = length $block;
    +      $result = $len ? $block ^ pack("a$len", $self->{'crypt'}->encrypt($self->{'civ'})) : '';
         }
         delete $self->{'civ'};
         delete $self->{'buffer'};



    No i przykładowe użycie:
    Code:

    #!/usr/bin/perl

    use strict;
    use warnings;


    use Crypt::Rijndael;
    use Crypt::CBC;
    my $key = 'satel       ';

    my $cipher0 = Crypt::Rijndael->new($key.$key, Crypt::Rijndael::MODE_CBC());
    my $empty = pack("W16", 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00);
    my $iv = $cipher0->encrypt($empty);

    my  $cipher = Crypt::CBC->new( -key    => $key.$key,
                                   -cipher => 'Rijndael',
                                   -header => 'none',
                                   -iv => $iv,
                                   -keysize => 24,
                                   -literal_key => 1,
                                );

    my $data = '2e:df:f4:ac:3c:92:b8:79:6d:84:fa:65:fe:7f:f9:d1:c1:85:a7:5a:ba:f3:e5:2e:ee:cb:c3:a0:d0:05:3d:44:e7:0e:ef:46:7e:9c';
    my $array = [ map {$_ = hex($_)} split(':', $data) ];
    my $crypted = pack("W*", @$array);

    print "Cry: " . unpack("H* ", $crypted) ."\n";

    my  $plaintext  = $cipher->decrypt($crypted);

    print "Dec: " . unpack("H* ", $plaintext) ."\n";

    my $ciphertext = $cipher->encrypt($plaintext);

    print "Dec: " . unpack("H* ", $ciphertext) ."\n";


    Smacznego :)

    PS.
    Do javy nic nie mam, po prostu w niej nie piszę.

  • #54 27 Mar 2012 11:01
    Barry83
    Poziom 12  

    acc007 napisał:
    Ale się rozkręciła dyskusja :) Koledzy, a czy ktoś próbował już w praktyce zastosować wskazówki które padły w tym wątku, czy tylko czekacie na gotowe rozwiązanie bądź negujecie możliwość utworzenia software'owej stacji STAM ?

    Kolega xckrzysin pisał o niestandardowym CBC... a ja sobie tak myślę, że zapewne ponownie można wykorzystać kody udostępnione przez Satel w MobileKPD (opisałem to w swoim wątku o GuardX) i w ten sposób próbować dekodować pakiety. Bez główkowania czym jest IV, co zrobić z ostatnim blokiem... no i w Javie, więc jakaś alternatywa do Perla tu przedstawianego

    I głęboko wierzę w to, że da się napisać STAM'a software'owego i w logu zdarzeń mieć same PLUSy ;)



    Nikt nie neguje możliwości utworzenia softwarowego rozwiązania ponieważ, od działu technicznego Satel wiem ,że jest opracowywany softwarowy SMET, który ma za zadanie tłumaczyć monitoring TCP IP na inne formaty starszych stacji i podawać to po RS. DT Satela twierdzi, że już to gdzieś za granicą działa. Warto czasem zadzwonić :P Ten Smet program odbiera monitoring TCP-ip czy tam gprs i potwierdza dla centali, ciekawe tylko czy mozna cos z tym zrobic dalej bo to nadal nie jest stacja

TME logo Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME
TME Logo