heron 23.12.2010 08:36 Zgłoś naruszenie Udostępnij Napisano 23 Grudnia 2010 Jeśli brak dokumentacji protokołu ma być zabezpieczeniem Nie zabezpieczenie - jedynie utrudnienie. Wystawienie komunikacji z ETHM na świat (tj. bez jakiegokolwiek szyfrowanego tunelowania), choćby nawet sama ta komunikacja była szyfrowana, też uważam za sporą nierozważność, bardzo bliską skrajnej głupocie. IMHO to ni mniej ni więcej tylko wlasnie glupota by byla. No ale dostałem oficjalne info od Satela, że dokumentacji do protokołu "GuardX over IP" nie dadzą, więc jedyna opcja to podejrzenie go samodzielne (co swoją drogą nie powinno być szczególnie trudne, dla odpowiednio zmotywowanych ludzi). Nie koniecznie. Jesli szyfruja komunikacje, a raczej tak robią, to podejrzenie moze byc tak trudne jak zlamanie klucza (tu strzelam) 128-bitowego. O ile nie dysponujesz odpowiednio mocnym sprzetem, to zajmie to na tyle dlugo, ze nie ma sensu sie tego podejmowac. Swoja droga moze byc tak, ze nie publikuja protokolu bo jest zaszyfrowany i zeby z niego skorzystac musieliby ujawnic klucze. Cytuj Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania
civic9 23.12.2010 08:43 Zgłoś naruszenie Udostępnij Napisano 23 Grudnia 2010 kiedyś dało się wyrwać od satela opis protokołu z manipulatora CA64-LCD - tam też się podłączało przez GuardX więc możliwe, że to ten sam, którym się posługuje centrala, tyle że może trzeba ją przestawić w ten tryb jeszcze jakoś dodatkowo. a jak nie to może być to podstawa do rozgryzienia protokołu, pewnie używają nadal czegoś podobnego. generalnie dane rzucają się tam w oczy. Cytuj Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania
ravbc 23.12.2010 09:09 Zgłoś naruszenie Udostępnij Napisano 23 Grudnia 2010 (edytowane) Protokół oczywiście może używać (i mam nadzieję używa) szyfrowanej komunikacji sieciowej. Wydaje mi się wręcz pewne, że jest to po prostu ten sam protokół co na połączeniu przez RSa, tyle, że tunelowany w IP. Ale skoro jesteśmy w stanie w pełni kontrolować oba końce transmisji, a co najmniej jeden z nich wręcz zdekompilować, to dla na prawdę zdeterminowanego ktosia jego odtworzenie nie będzie aż tak czasochłonne. Oczywiście osobną kwestią pozostaje późniejsza realność wykorzystania tak zdobytych informacji. Gdyby chcieć w ten sposób podsłuchać transmisję obcego systemu, to już nie będzie dostępu do kluczy szyfrujących i faktycznie podsłuchanie będzie trudne. Ale gdyby to było tak trudne, to po co ukrywać specyfikację? Z drugiej strony nie ma też szczególnego powodu by ją ujawniać... Natomiast potrafię chyba wymyślić powód, dlaczego jednak ujawnienie specyfikacji protokołu było by groźne. Otóż skuteczne szyfrowanie transmisji (czyli z użyciem długich kluczy i mocnych algorytmów) jest kosztowne obliczeniowo. Nie sądzę by ETHM-1 był wystarczająco silny sprzętowo, więc pewnie użyte szyfrowanie jest jednak niższej klasy, a to już może rodzić realne zagrożenie jego złamania. Tak więc ukrywając protokół zabezpieczają się po prostu przed wytykaniem im tej słabości (bo raczej nikt kto zada sobie trud by ten protokół złamać, nie będzie się zdobytą wiedzą chwalił). Tak czy owak, dla normalnych ludzi jedynym wyjściem pozostaje INT-RS, a szkoda. Edytowane 23 Grudnia 2010 przez ravbc Cytuj Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania
civic9 23.12.2010 10:16 Zgłoś naruszenie Udostępnij Napisano 23 Grudnia 2010 przyczyna może być bardziej prozaiczna - kto wtedy kupowałby int-rs? (tak to może widzieć management, abstrahuje od tego, że otwartość systemu zazwyczaj wpływa pozytywnie na jego sprzedaż) Cytuj Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania
ravbc 23.12.2010 10:54 Zgłoś naruszenie Udostępnij Napisano 23 Grudnia 2010 INT-RS jest o połowę tańszy, a systemy automatyki jednak nadal częściej wykorzystują interfejsy szeregowe niż ETH. Więc klientów raczej by nie zabrało. A nawet jeśli, to co jest złego w sprzedaniu drozszego produktu zamiast tańszego? Wydaje mi się, że jednak Satel zwyczajnie boi się pokazać protokół GuardX - bo w sumie po co wymyślali by nowy "otwarty" protokół, skoro INT-RS także GuadrXa wystawia? Cytuj Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania
civic9 23.12.2010 11:07 Zgłoś naruszenie Udostępnij Napisano 23 Grudnia 2010 zakładam, być może błędnie, że ten sam protokół jest na porcie szeregowym centrali (bez opakowania w tcp/ip) - dlatego sprzedaż by jednak mogła zmaleć (z punktu widzenia/myślenia managementu - podkreślam). tak to widzę, że moduł ETHM to tylko bramka rs232-tcp/ip jeśli chodzi o guardx (zauważcie, że trzeba go podłączyć do portu rs232 centrali, żeby guardx działał, stąd też ograniczenie na jednego użytkownika). coś tam piszą o szyfrowaniu 192bitowym kluczem - ale możliwe, że to dotyczy tylko tej aplikacji appletowej w Javie (chyba, że guardx jednak też korzysta z tego szyfrowania nawet na rs232). Cytuj Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania
ravbc 23.12.2010 11:31 Zgłoś naruszenie Udostępnij Napisano 23 Grudnia 2010 No ale ETHM-1, to de facto _jest_ RS-over-IP. Jeśli znajdziesz jakikolwiek inny moduł wystawiający RSa po TCP, to można spokojnie spróbować go podpiąć wprost do centrali i to ma prawo normalnie działać. Dokumentacja protokołu nic tu do tego nie ma, bo przecież na RSie jest on normalnie dostępny. "Siłą" ETHM-1 jest to, że jest to oficjalny produkt producenta centrali z jego wsparciem technicznym, ale tego ujawnienie specyfikacji protokołu nie zmieni. Nieznane są jednak ścieżki po jakich plączą się myśli managementu wszelakiego... A co do 192-bitowego klucza: nie sądzę by na RSie tego używali. Nie ma za bardzo ku temu szczególnego powodu, a realizacja jest nietrywialna. No i jeszcze jedno: to jednak marketing, a widziałem już kiedyś określenie 3DESa z kluczem 64bitowym, mianem szyfrowania 192bitowego. Cytuj Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania
heron 23.12.2010 14:36 Zgłoś naruszenie Udostępnij Napisano 23 Grudnia 2010 Nie jest to RS-over-IP. Aby tak bylo musieliby rowniez sprzedawac modul konwertujacy z IP na RS po drugiej stronie kabla. To jest bramka jak napisal civic9. Ja mysle, ze hipoteza o slabym szyfrowaniu jest trafna. Ewentualnie maja zahardkodowany wszedzie ten sam klucz i musieliby go ujawnic. Cytuj Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania
civic9 23.12.2010 14:50 Zgłoś naruszenie Udostępnij Napisano 23 Grudnia 2010 Jeśli znajdziesz jakikolwiek inny moduł wystawiający RSa po TCP, to można spokojnie spróbować go podpiąć wprost do centrali i to ma prawo normalnie działać. Zgubiłem się już trochę w tej dyskusji, ale napiszę że dokładnie tak robię, bo mi się nie chce chodzić z kompem do centrali, a ETHM nie miałem w budżecie Dokumentacja protokołu nic tu do tego nie ma, bo przecież na RSie jest on normalnie dostępny. Ale jest niejawny więc bez INT-RS i ETHM-1 nikt się do tego nie podobnie. Ujawniając specyfikację ETHM-1 jednocześnie (jeśli mam rację) ujawniliby specyfikację centrali co by oznaczało możliwość podpinania się bez INT-RS i ETHM-1. I możliwość powstania produktów alternatywnych - zapewne lepszych i tańszych. Sam bym to zrobił Cytuj Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania
ravbc 23.12.2010 15:13 Zgłoś naruszenie Udostępnij Napisano 23 Grudnia 2010 Zgubiłem się już trochę w tej dyskusji, ale napiszę że dokładnie tak robię, bo mi się nie chce chodzić z kompem do centrali, a ETHM nie miałem w budżecie A swoją drogą przypomnij jak masz to zrealizowane. Prznajmniej wrócimy trochę w kierunku tematu wątku. Ujawniając specyfikację ETHM-1 jednocześnie (jeśli mam rację) ujawniliby specyfikację centrali co by oznaczało możliwość podpinania się bez INT-RS i ETHM-1. I możliwość powstania produktów alternatywnych - zapewne lepszych i tańszych. Sam bym to zrobił Ale rozmawialiśmy nie o specyfikacji ETHM-1, tylko protokołu GuardX. On działa na jakichkolwiek alternatywnych interfejsach, które umieją po stronie centrali udawać RSa, czyli by go używać nie trzeba kupowac od Satela niczego poza centralą. Niestety brak jego specfikacji powoduje, ze jedyna pewna metoda integracji, to zakupo INT-RS i uzycie wystawionego przez niego "otwartego" protokołu przeznaczonego do integracji z innymi rozwiązaniami. IMHO to jednak dość dziwna polityka. Chyba, że protokół GuadrX jest aż tak kiepski, albo centrala jest mocno podatna na ewentualne błędy w jego implementacji. Cytuj Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania
civic9 23.12.2010 15:41 Zgłoś naruszenie Udostępnij Napisano 23 Grudnia 2010 A swoją drogą przypomnij jak masz to zrealizowane. Prznajmniej wrócimy trochę w kierunku tematu wątku. Na windowsie HW Virtual Serial Port (darmowy). Role modułu RS2TCP pełni: kabelek rs232-usb + sheevaplug z linuxem, którą akurat mam przy centrali + oprogramowanie ser2net. To podpięte to LANu i WANu (spokojnie, z zabezpieczeniami). HW Group ma też moduły całkiem sprzętowe, będzie działało identycznie, ale tak mam to po koszcie kabelka (sheevaplug do różnych innych celów). Poprzednio działało mi to też na Linksys NSLU2. Działa to z dloadx, guardx. Ale rozmawialiśmy nie o specyfikacji ETHM-1, tylko protokołu GuardX. On działa na jakichkolwiek alternatywnych interfejsach, które umieją po stronie centrali udawać RSa, czyli by go używać nie trzeba kupowac od Satela niczego poza centralą. Miałem na myśli pisząc "ujawniając specyfikację ETHM-1" ujawnienie specyfikacji "GuardX". Nie trzeba do tego kupować nic poza centralą, ale możliwości użycia są dość ograniczone, tzn. tylko z oprogramowania satela, a użycie w sposób zdalny wymaga kombinowania i nie zapewnia przemysłowej jakości. Cytuj Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania
p 26.12.2010 20:46 Zgłoś naruszenie Udostępnij Napisano 26 Grudnia 2010 Mam satela. Mamy też piloty napadowe. Instalatorzy zaprogramowali Satela w ten sposób, że po naciśnięciu przycisku napadowego na pilocie na manipulatorze wyskakuje o tym komunikat ("Alarm z wej. X - Piloty). Chciałbym aby w takiej sytuacji nie wyskakiwał żaden komunikat albo (ewentualnie) na sekundę jakiś sygnał, że pilot zadziałał. Jak mogę to zmienić ? Co muszę zmienić w centralce aby tak działała ? Cytuj Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania
arpl 26.12.2010 21:53 Zgłoś naruszenie Udostępnij Napisano 26 Grudnia 2010 Mam satela. Mamy też piloty napadowe. Instalatorzy zaprogramowali Satela w ten sposób, że po naciśnięciu przycisku napadowego na pilocie na manipulatorze wyskakuje o tym komunikat ("Alarm z wej. X - Piloty). Chciałbym aby w takiej sytuacji nie wyskakiwał żaden komunikat albo (ewentualnie) na sekundę jakiś sygnał, że pilot zadziałał. Jak mogę to zmienić ? Co muszę zmienić w centralce aby tak działała ? Najpościej zmienic linię na typ 47 i jeśli chcesz żeby cos zadzwoniło to ustawić z tej lini gong w manipulatorach. Cytuj Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania
heron 28.12.2010 11:52 Zgłoś naruszenie Udostępnij Napisano 28 Grudnia 2010 civic9, a da sie ta droga sensownie odczytywac chwilowy stan wejsc? Inaczej, czy jesli ruch w pomieszczeniu wywolal powiedzmy jeden impuls na PIR, to czy odczytujac stan wejscia po INT-RS moge sie nie wstrzelic i przegapic ten impuls czy tez protokol jakos sensownie to podaje (np. timestamp kiedy ostatnio wejscie odebralo sygnal z czujki)? Cytuj Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania
ravbc 28.12.2010 12:22 Zgłoś naruszenie Udostępnij Napisano 28 Grudnia 2010 INT-RS może wystawiać zdarzenia, nie tylko bieżący stan systemu, więc jesli pojawi sie zdarzenie "naruszenie czujki", to da się je odczytać. Oczywiście jest tam też rejestrowany czas zaistnienia tego zdarzenia. Cytuj Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania
szczukot 29.12.2010 09:38 Zgłoś naruszenie Udostępnij Napisano 29 Grudnia 2010 Moze mi ktos wskazac jakas czujke z podlaczenem do centrali alarmowej (satel) 2in1 : dymu i tlenku wegla ? Fantom Cytuj Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania
arpl 29.12.2010 20:21 Zgłoś naruszenie Udostępnij Napisano 29 Grudnia 2010 Moze mi ktos wskazac jakas czujke z podlaczenem do centrali alarmowej (satel) 2in1 : dymu i tlenku wegla ? Fantom Nie wiem czy jest taka w miarę dobra? Spotkałem się z "dualną" Gazexa tlenek +gaz ale tlenek + dym to jeszcze nie instalowałem chyba. Cytuj Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania
szczukot 29.12.2010 20:34 Zgłoś naruszenie Udostępnij Napisano 29 Grudnia 2010 No wlasnie nie moge nic znalezc Gaz mnie racej nie inetersuje bo nie mam w sumie w domu (tylko garaz). A tlenek i dym by sie przydal (np kominek lub pozar). Fantom Cytuj Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania
arpl 29.12.2010 22:23 Zgłoś naruszenie Udostępnij Napisano 29 Grudnia 2010 No wlasnie nie moge nic znalezc Gaz mnie racej nie inetersuje bo nie mam w sumie w domu (tylko garaz). A tlenek i dym by sie przydal (np kominek lub pozar). Fantom Kup osobne, Czujnik tlenku Gazexa a dymu polon adr-20 , bedziesz miał osobne wyjścia . Cytuj Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania
szczukot 30.12.2010 06:30 Zgłoś naruszenie Udostępnij Napisano 30 Grudnia 2010 A sa czujki CO ktore nie wymagaja wymiany co kilka lat ? Gdzies mi sie chyba takie cos obilo o oczy a teraz znalezc nie moge - jakas inna zasada dzialania musiala byc. Fantom Cytuj Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania
Recommended Posts
Dołącz do dyskusji
Możesz dodać zawartość już teraz a zarejestrować się później. Jeśli posiadasz już konto, zaloguj się aby dodać zawartość za jego pomocą.