inżynieria wsteczna oprogramowania do spirometru - prośba o pomoc

[oskarasgda]

Witam serdecznie,
piszę tu na forum, ponieważ chciałbym prosić kogoś z Was o pomoc w wydobyciu pewnych informacji z oprogramowania detykowanego do spirometru.
Nie robię tego z nudów tylko potrzebuję pewne dane do mojej pracy inżynierskiej. Mianowicie tworzę system śledzący zmiany parametrów układu oddechowego. Jednym z jego elementów jest spirometr piko -6. Pomierzone dane mają trafić do urządzenia, które zaprojektowałem i wykonałem, a które to ma odbierać dane a następnie przesyłać je poprzez moduł gsm/gprs do bazy danych.
Problem zaczął się gdy próbowałem odczytać dane ze spirometru. Nadawane są one w standardzie RS232, jednak nie są to czyste dane lecz wysyłane poprzez jakiś protokół. Próbowałem go rozszyfrować ale niestety poległem.
Chyba jedynym sposobem rozszyfrowania protokołu jest inżynieria wsteczna programu znajdującego się na kompie i wydobycie z niego algorytmu zmieniającego długi ciąg pochodzący ze spirometru w dane możliwe do prezentacji.
Próbowałem wykorzystać Ollydbg oraz Spices ale nie wiele mi to dało. Czy ktoś z Was jest w stanie mi pomóc?

https://rapidshare.com/files/2436621891/PiKoTrend-pro.zip program wraz z bibliotekami i bazą danych
https://rapidshare.com/files/2157463226/wyniki.xls wyniki pobrane z terminala


Pozdrawiam
Oskar

 

[s0me1_like_?]

Nie wiem czy są tutaj ludzie którzy znają się na spiromierzach, więc opłacało by się trochę więcej informacji w jaki sposób uzyskałeś ten plik wyniki.xls. Po prawej przecież tam masz wszystko "odszyfrowane".

Gdyby opisałeś w jaki sposób badałeś ten "protokół", to było by łatwiej pomóc.

Jeśli chodzi o revers-engineering to nie wiem czy ktoś będzie chciał z tym bawić się, tym bardziej nie mając urządzenia. Ja bym na twoim miejscu bardziej bym skupił się na analizie "protokołu", wątpie że stosują jakieś szyfrowanie.

No i spróbuj napisać ładnego mail'a do producenta, że jesteś studentem, piszesz pracę dyplomową i próbujesz pobierać dane z ich urządzenia, może udostępnią jakiegoś datasheet'a.

 

[oskarasgda]

s0me1_like_?, dzięki za odzew.

Postaram się powolutku wszystko opisać.
"Odszyfrowane" dane w pliku .xls pochodzą już z programu czyli są już faktycznie odszyfrowane. Pytanie tylko w jaki sposób można dojść do tych danych mając
tylko te inne liczby.
Otrzymany ciąg danych pochodzi z terminala, który odczytywał dane z RS232 podpięte do spirometru.
Nie wiem już w jaki sposób analizować protokół. Albo wprowadzona jest jakaś redundancja albo już sam nie wiem co ;/

 

[s0me1_like_?]

s0me1_like_?, dzięki za odzew.
Postaram się powolutku wszystko opisać.

Znowu za mało danych, chłopie. Dawaj krok po kroku, ekstrasensów niema.

"Odszyfrowane" dane w pliku .xls pochodzą już z programu czyli są już faktycznie odszyfrowane. Pytanie tylko w jaki sposób można dojść do tych danych mając
tylko te inne liczby.

W jakiej postaci dostajesz te liczby? Najprawdopodobniej to są bajty, ale dostajesz ich jako binary-data czy odrazu tak w systemie decymalnym? 120 - to jeden bajt czy trzy?

Uruchom ten terminal znowu, włącz logowanie do pliku i pobierz jakiś jeden record (Total record: 1). Umieść ten plik w tym formacie co dostaniesz i napisz jakie wartości wyświetli program.

Najlepiej pobierz ten sam record trzy razy - dwa razy bez kasowania i jeden z kasowaniem, zobaczymy czy pierwsze dwa razy będą takie same i czym będzie różnić się trzeci.

Otrzymany ciąg danych pochodzi z terminala, który odczytywał dane z RS232 podpięte do spirometru.

Wytłumacz krok po kroku jak ty podpinasz to urządzenie i jak dostajesz te dane. Wpinasz się pomiędzy kompem a urządzeniem podczas pobierania danych przez program? Jakąś (jak?) softwerowo? Z kasowaniem/bez kasowania - to znaczy "odcytać i skasować dane z urządzenia"/"odczytać i pozostawić w urządzeniu"?

Nie wiem już w jaki sposób analizować protokół.

A w ogóle próbowałeś to analizować? Czy zobaczyłeś ciąg bajtów i odrazu przestraszyłeś się?

PS. napisałeś już maila do producenta?

WBR,

 

[oskarasgda]

Krok po kroku:
W skład piko -6 wchodzą: element pomiarowy zwany spirometrem, podstawka połączona poprzez usb do komputera.
Spirometr z podstawką łączy się poprzez podczerwień w standardzie RS232. Moim zadaniem jest uniezależnienie się od połączenia przez usb, dlatego
dane próbuje sczytać jeszcze przed 'przejściówką' RS232-> USB. 'przejściówkę stanowi PL-2303.
Nóżkę RX tego scalaka podłączam do przejściówki RS232 - usb dzięki czemu mam jakby wirtualny port rs232 w kompie. Uruchamiam terminal, ustawiam odpowiedni port i prędkość transmisji. Następnie zaznaczam opcje pozwalające wybrać sposób prezentacji danych. Oczywiście są one w formie binarnej ale nie wiedzieć czemu do pliku .xls wpisałem w postaci dziesiętnej.
120 samo w sobie to jeden bajt ale teraz pytanie czy faktycznie terminal nie porozdzielał sobie tego.
Niestety nie mam oscyloskopu cyfrowego (tylko analogowy). W pliku .xls są właśnie powtórzone pomiary 3 krotnie. Dziś wieczorem powtórzę pomiary bo zostawiłem przejściówke rs232 -usb u kolegi ;/
Oczywiście próbowałem analizować ten protokół. Starałem się porównać z danymi w bazie danych .mdb, tam jest przydział bajtów na poszczególne wielkości no ale na nic mi się to zdało. Zapewne robie jakiś głupi błąd i nie mogę wybrnąć z tego
bagna ;/

edit: do producenta napisałem już jakiś czas temu ale niestety nie odpisał

pozdrawiam
oskar

 

[s0me1_like_?]

Krok po kroku:
W skład piko -6 wchodzą: element pomiarowy zwany spirometrem, podstawka połączona poprzez
[...skipped...]
Następnie zaznaczam opcje pozwalające wybrać sposób prezentacji danych.

ok,rozumiem.

W pliku .xls są właśnie powtórzone pomiary 3 krotnie.

Rozumiem, ale szczerze mówiąc mi się nie chce bawić się z kopiowaniem liczb z .xls'a i konwersją ich z powrotem do bajtów.

Dziś wieczorem powtórzę pomiary bo zostawiłem przejściówke rs232 -usb u kolegi ;/

Ok, ale pamiętaj że potrzebujemy taką "raw-data", bez żadnych konwersji, etc, tylko taki zwykły plik, a lepiej kilka, coś w rodzaju

od_kompa_do_urzadzenia1 - co program powiedział do urzadzenia
od_urz_do_komp1 - co odpowiedziało urządzenie

dla 2 i 3 pobierania tak samo. I nie dopisuj nic swojego do tych plików - tylko te bajty w tym samym formacie co pobierasz.

tam jest przydział bajtów na poszczególne wielkości no ale na nic mi się to zdało.

To opisz ten przydział, to może pomóc.

WBR,

 

[oskarasgda]

SPIROMETR->KOMP:

http://wklej.org/id/703165/
http://wklej.org/id/703167/
http://wklej.org/id/703169/
http://wklej.org/id/703171/
http://wklej.org/id/703173/


KOMP->SPIROMETR:

z kasowaniem:
http://wklej.org/id/703175/

bez kasowania:
http://wklej.org/id/703176/
http://wklej.org/id/703178/

WYNIKI W PROGRAMIE:
Ref: FEV1 Zone Ref: 0
Total record: 2
PEF(2): 398 FEV(2): 3,98 TS: 124 Time(2): 2012-02-29 21:50:08
PEF(1): 463 FEV(1): 4,51 TS: 124 Time(1): 2012-02-29 21:50:08

DEFINICJA PÓL W BAZIE DANYCH .MDB:
name type size
id Long Integ 4
timestamp Integer 2
rec_datetime DateTime 8
pef Integer 2
fev Double 8
test_no Integer 2
uid Integer 2
exported Boolean 0
qflag Boolean 0
comment Memo/Hyp 0

 

[s0me1_like_?]

SPIROMETR->KOMP:

http://wklej.org/id/703165/
http://wklej.org/id/703167/
http://wklej.org/id/703169/
http://wklej.org/id/703171/
http://wklej.org/id/703173/


KOMP->SPIROMETR:

z kasowaniem:
http://wklej.org/id/703175/

bez kasowania:
http://wklej.org/id/703176/
http://wklej.org/id/703178/

Hmm, a jak tak? Na 3 zapytania dostajesz 5 odpowiedzi?

WYNIKI W PROGRAMIE:

Ok, jutro postaram się to rozwiązać.

 

[oskarasgda]

nie nie, zapytania się nie różnią (oprócz tego z ustawionym kasowaniem) dlatego wstawiłem tylko 3 logi. odpowiedzi spirometru się różnią więc wstawiłem ich więcej.
siedzę nad tym i dumam ;/
Będę wdzięczy jeśli uda Ci się coś z tego wydobyć.

Edit:
powtórzyłem dziś pomiary przy mniejszym baud rate w terminalu:
spirometr->komp, pobrany jeden wynik: http://wklej.org/id/704009/
spirometr->komp, pobrano dwa wyniki: http://wklej.org/id/704011/
komp->spirometr, bez kasowania: http://wklej.org/id/704012/
komp->spirometr, z kasowaniem: http://wklej.org/id/704013/

Ref: FEV1 Zone Ref: 0
Total record: 1
PEF(1): 430 FEV(1): 4,29 TS: 771 Time(1): 2012-03-07 15:31:04

 

[s0me1_like_?]

Nie jest to łatwo, chłopie. Bardzo chcę pomóc, ale trzeba by było trochę nad tym posiedzieć. Niestety, dużo czasu nie mam.

Te nowe dane wygłądają trochę bardziej sensownie z tymi FFami, ale nie wiem po co są 5F,7F,7F. Ja tak strzelam, że długość zapisu jest 128 bajt, popatrz, na końcu pliku pomiędzy 7F a 7F są 128 bajtów, dalej znowu od 7F do 5f (patrzymy z końca) - 128, dalej - od 5f do BB - 128, to jest chyba drugi rekord, pomiędzy BB, a początkiem pliku - 128. Bajty nie mające wartości = FF. Ten BB, 5F,7F,7F to mogą być jakieś bajty sterujące.

Ale to wszystko strzelanie, w starych plikach to się nie zgadza (http://wklej.org/id/703165/) w żaden sposób.

No i jeszcze jedno. Jak sam widzisz te dwa nowe pliki są prawie identyczne. Nie robiłem diff'a, ale tak mi się wydaje że zminia się jeden bajt na początku (linijka 5) i jeden "sterujący". Dlaczego tak - trzeba by było pomyśleć, może "sterujący" pokazuje że drugi rekord nie trzeba wyświetlać, może pierwsza zmiana dotyczy czasu pobrania. Chociaż z tym czasem pobrania nie jest bardzo logicznie.
To trzeba było by wszystko sprawdzić.

Jeszcze sprawdź swój sprzęt, może jest tam jakaś pomyłka. Jeśli możesz - spróbuj podpiąć ten programik, który odszyfruje do tego końca z którego odczytujesz terminałem - zobaczysz czy będą dobre wyniki w programie, czyli czy w ogóle na dobre dane patrzymy.

Po-drugiej, usiądź sobie i posprawdzaj te dane, jak się zminiają itd, jak będziesz miał jakieś myśli - możesz pisać tutaj, pomyślimy razem.

Po-trzeciej, chyba masz tam jakiegoś promotora, jak to jest twoja praca dyplomowa. Jak będziesz pewien że dostajesz dobre dane - bierz parę "próbek" i idź do niego, pogadaj. Może on coś doradzi albo skieruje do jakiegoś profesora na twojej uczelni który pomoże Ci z tym.

Jak producent nie odpowiada na mail'a, to weź zadzwoń do nich, pogadaj. Długo gadaj, niech połączą z jakimś inżynierem, bo first-line to zawsze first-line. Nie wstydź się, ty kupiłeś ich urządzenie więc muszą Ci pomóc. Mogą powiedzieć że nie udostępniają takich danych, ale w każdym razie warto spróbować.

Ja może popatrze na to tak za parę dni, bo na razie mam za dużo swojego gówna Jak będę miał jakiś pomysł to dam znać.

Ty nie rzucaj ten temat tutaj na forumie - jak rozwiążesz ten problem to napisz co tam było i jak do tego doszedłeś, bo to jest ciekawe i może przyda się komuś.

Co jeszcze... a, no możesz spróbować troche zdebagować jednak ten program, weź OllyDbg na przykład, dodaj breakpoint'y i patrz jak przebiega odczyt/odszyfrowanie danych, co jest w pamięci itd.

don't give up

WBR,

 

[oskarasgda]

Dziś powtórzyłem pomiary. Następnie wszystkie wydrukowałem na osobnych kartkach i porównywałem bajt po bajcie.
Zauważyłem pewną prawidłowość. Pierwsza linijka jest zawsze taka sama lecz druga już się zmienia. Zwróciłem uwagę na 5 bajt
drugiej linijki. Jej wartość zależy od ilości danych znajdujących się w pamięci spirometru i które to są przesyłane do komputera.
Poniżej zamieszczam 2 pierwsze linijki dla różnych pomiarów w zależności od ilości danych:

0 danych

15 6F 02 05 0B 1B 2F 49 6C 9C B1 D4 29 35 24 00
B1 0B 92 17 00 71 F8 70 04 81 38 FA FF FF FF 4E

2 dane

15 6F 02 05 0B 1B 2F 49 6C 9C B1 D4 29 35 24 00
B1 0B 92 17 00 71 F8 70 04 81 38 FA FF FF FF 4E

3 dane

15 6F 02 05 0B 1B 2F 49 6C 9C B1 D4 29 35 24 00
B0 0B 92 17 03 71 F8 70 04 81 38 B5 FF FF FF 4E

Pomiary powtórzone po kilku godzinach wydają się jakby 'czystsze' ale 5 bajt zachowuje się tak jak wcześniej:

0 danych

15 6F 02 05 0B 1B 2F 49 6C 9C B1 D4 29 35 24 00
00 00 00 00 00 00 00 00 00 00 00 F5 FF FF FF 55

1 dana

15 6F 02 05 0B 1B 2F 49 6C 9C B1 D4 29 35 24 00
01 00 00 01 01 00 00 00 00 00 00 F5 FF FF FF 52

2 dane

15 6F 02 05 0B 1B 2F 49 6C 9C B1 D4 29 35 24 00
01 00 00 02 02 00 00 00 00 00 00 F5 FF FF FF 55

http://wklej.org/id/705592/

oskaras






Coś już wiem. Siedziałem siedziałem, aż przyrosłem do fotela no ale pare rzeczy rozkminiłem chociaż nie do końca

http://wklej.org/id/709316/

53 00 0F 00
FF
D2 4E 05 C6
E6 73 15 2B
E4 61 15 2B => 484 353 277 299
FD 57 15 2C => 509 343 277 300
DD 28 15 2C => 477 296 277 300
AF 34 15 2D => 431 308 277 301
D1 9B 15 2D => 465 411 277 301

Po pierwszej paczce FF'ów można odnaleźć dane chociaż nie tak bezpośrednio, ponieważ do każdej wartości należy dodać heksalnie wartość 100. Po takim zabiegu wychodzą wyniki takie same jak w programie. Chociaż w wypadku FEV należy to co nam wyszło podzielić przez 100 dziesiętnie. Jest jeszcze problem. W jednym z pomiarów wynik PEF wynosił 535 przez co nie należy dodać 100 hex tylko 200 hex. Czy ktoś widzi może w tych danych miejsce, w którym jest zapisana wartość, którą należy dodać?

 

[oskarasgda]

Heh pisze tu sam ze sobą ale ok ;p

http://wklej.org/id/711945/ najbardziej po lewej stronie do są dane ze spirometru a to po prawej to są rozkodowane przeze mnie dane

 

[trojanxem]

Heh pisze tu sam ze sobą ale ok ;p

http://wklej.org/id/711945/ najbardziej po lewej stronie do są dane ze spirometru a to po prawej to są rozkodowane przeze mnie dane

Ja to czytam ciągle, ale niestety za wiele nie pomogę, aczkolwiek powodzenia

 

[oskarasgda]

W sumie już doszedłem do takiego etapu, że da się już napisać program na mikrokontroler. Będę sprawdzał czy pobrana dana ma ma wartość np 0B, wtedy do tego będzie dodawane 200h w pozostalych przypadkach dodam 100h i tyle