Mam nadzieję, że ze swoim problemem trafiłem na dobrą grupę, wydała mi
się najwłaściwsza.
Jest sobie pewien program (Win32), którego elementem jest komponent
chatu osadzony w jednym z okien. Mam potrzebę logować w czasie
rzeczywistym teksty, które się tam (chat) pojawiają. Problemem jest to,
że jest to całkowicie autorski komponent twórców tego oprogramowania i
nie wiadomo jak on działa. Podglądałem go przy pomocy Spy++, jedyny
komunikat pojawiający się przy pojawianiu się nowej linijki tekstu to
WM_PAINT. Z kolei API Monitor twierdzi, że żadne WinAPI nie jest
wywoływane z parametrem w postaci pojawiającego się tam tekstu (z
tekstami pojawiającymi się poza komponentem chatu to i owszem). Ma ktoś
może pomysł gdzie i jak szukać tropu? O samą technikę przechwytywania
tego typu rzeczy (jak już wiadomo co i skąd) nie pytam, to już jako tako
wujek google mi wyjaśnił.

Pozdrawiam

do góry

Użytkownik "Przemysłąw Dębski" <p...@g...pl> napisał w wiadomości
news:kpdekb$8sn$1@node1.news.atman.pl...
>
> Mam nadzieję, że ze swoim problemem trafiłem na dobrą grupę, wydała mi
> się najwłaściwsza.
> Jest sobie pewien program (Win32), którego elementem jest komponent
> chatu osadzony w jednym z okien. Mam potrzebę logować w czasie
> rzeczywistym teksty, które się tam (chat) pojawiają. Problemem jest to,
> że jest to całkowicie autorski komponent twórców tego oprogramowania i
> nie wiadomo jak on działa. Podglądałem go przy pomocy Spy++, jedyny
> komunikat pojawiający się przy pojawianiu się nowej linijki tekstu to
> WM_PAINT. Z kolei API Monitor twierdzi, że żadne WinAPI nie jest
> wywoływane z parametrem w postaci pojawiającego się tam tekstu (z
> tekstami pojawiającymi się poza komponentem chatu to i owszem). Ma ktoś
> może pomysł gdzie i jak szukać tropu? O samą technikę przechwytywania
> tego typu rzeczy (jak już wiadomo co i skąd) nie pytam, to już jako tako
> wujek google mi wyjaśnił.

Czy napewno monitoruje całe API ?

Ale jak by nie kombinował - włanczasz debugger
szukasz okna tego czatu - a własciwie jego
procedury obsługi komunikatów - ustawiasz się
z przerwaniem i patrzysz jak on ten komunikat
WM_PAINT obsługuje ?
Wtedy zobaczysz co (tekst) i skąd (bufor)
bierze.A nawet jak/jakim_api to pisze :))))))

Wtedy podmieniasz na swoją procedurę
i przed paint robisz kopie do logu ?
:))))))))))

do góry

kali pisze:
> Użytkownik "Przemysłąw Dębski" <p...@g...pl> napisał w wiadomości
news:kpdekb$8sn$1@node1.news.atman.pl...
>> Mam nadzieję, że ze swoim problemem trafiłem na dobrą grupę, wydała mi
>> się najwłaściwsza.
>> Jest sobie pewien program (Win32), którego elementem jest komponent
>> chatu osadzony w jednym z okien. Mam potrzebę logować w czasie
>> rzeczywistym teksty, które się tam (chat) pojawiają. Problemem jest to,
>> że jest to całkowicie autorski komponent twórców tego oprogramowania i
>> nie wiadomo jak on działa. Podglądałem go przy pomocy Spy++, jedyny
>> komunikat pojawiający się przy pojawianiu się nowej linijki tekstu to
>> WM_PAINT. Z kolei API Monitor twierdzi, że żadne WinAPI nie jest
>> wywoływane z parametrem w postaci pojawiającego się tam tekstu (z
>> tekstami pojawiającymi się poza komponentem chatu to i owszem). Ma ktoś
>> może pomysł gdzie i jak szukać tropu? O samą technikę przechwytywania
>> tego typu rzeczy (jak już wiadomo co i skąd) nie pytam, to już jako tako
>> wujek google mi wyjaśnił.
>
> Czy napewno monitoruje całe API ?

Za to ręki nie dam sobie uciąć ale raczej tak, wyłączyłem wszystkie
filtry wywołań. Później ustawiłem filtr na api związane z GDI. W jednym
i drugim przypadku odnajdywał teksty z wszystkiego co pojawiało się na
okienkach programu z wyjątkiem problematycznego komponentu.

> Ale jak by nie kombinował - włanczasz debugger
> szukasz okna tego czatu - a własciwie jego
> procedury obsługi komunikatów - ustawiasz się
> z przerwaniem i patrzysz jak on ten komunikat
> WM_PAINT obsługuje ?

Ale to chyba jakiś dissasembler masz na myśli ? Mamy przecież do
dyspozycji goły exe i nic ponad to. Dodatkowo nie mamy pewności, czy
nasza funkcja nie siedzi w jakimś dll - choć ok. w tym konkretnym
przypadku to mało prawdopodobne. Załóżmy że przełamię "barierę językową"
;) Jak w takim kodzie znaleźć assemblerowy odpowiednik ~"case WM_PAINT"
skoro na tym poziomie komunikat będzie reprezentowany przez liczbę a nie
przez nazwę. Dodatkowo takich ~"case WM_PAINT" będzie tyle ile
komponentów w aplikacji (dobrze myślę?) i skąd wiadomo który z nich to
jest właśnie ten. Jeśli by chcieć szukać interesującego nas fragmentu
kodu poprzez jakiś charakterystyczny string, to też mamy problem. To
jest komponent chatu i wyświetla to co ludzie napiszą. Exe wrzucony do
dissasemblera nie jest (?) działającym programem.
Może źle zrozumiałem "włączasz debuger" ?

> Wtedy zobaczysz co (tekst) i skąd (bufor)
> bierze.A nawet jak/jakim_api to pisze :))))))

Do tego dążę :)

> Wtedy podmieniasz na swoją procedurę
> i przed paint robisz kopie do logu ?
> :))))))))))

Taki jest właśnie plan. Co prawda nigdy tego nie robiłem, ale w sieci
pełno materiałów i przykładów jak to się robi, więc tu problemu nie
powinno być :)

Pozdrawiam

do góry

W dniu piątek, 14 czerwca 2013 07:35:26 UTC+2 użytkownik Przemysłąw Dębski napisał:
> kali pisze:
> > Użytkownik "Przemysłąw Dębski" <p...@g...pl> napisał w wiadomości
news:kpdekb$8sn$1@node1.news.atman.pl...
> >> Mam nadzieję, że ze swoim problemem trafiłem na dobrą grupę, wydała mi
> >> się najwłaściwsza.
> >> Jest sobie pewien program (Win32), którego elementem jest komponent
> >> chatu osadzony w jednym z okien. Mam potrzebę logować w czasie
> >> rzeczywistym teksty, które się tam (chat) pojawiają. Problemem jest to,
> >> że jest to całkowicie autorski komponent twórców tego oprogramowania i
> >> nie wiadomo jak on działa. Podglądałem go przy pomocy Spy++, jedyny
> >> komunikat pojawiający się przy pojawianiu się nowej linijki tekstu to
> >> WM_PAINT. Z kolei API Monitor twierdzi, że żadne WinAPI nie jest
> >> wywoływane z parametrem w postaci pojawiającego się tam tekstu (z
> >> tekstami pojawiającymi się poza komponentem chatu to i owszem). Ma ktoś
> >> może pomysł gdzie i jak szukać tropu? O samą technikę przechwytywania
> >> tego typu rzeczy (jak już wiadomo co i skąd) nie pytam, to już jako tako
> >> wujek google mi wyjaśnił.
> >
> > Czy napewno monitoruje całe API ?
>
>
>
> Za to ręki nie dam sobie uciąć ale raczej tak, wyłączyłem wszystkie
> filtry wywołań. Później ustawiłem filtr na api związane z GDI. W jednym
> i drugim przypadku odnajdywał teksty z wszystkiego co pojawiało się na
> okienkach programu z wyjątkiem problematycznego komponentu.
>
>
>
> > Ale jak by nie kombinował - włanczasz debugger
> > szukasz okna tego czatu - a własciwie jego
> > procedury obsługi komunikatów - ustawiasz się
> > z przerwaniem i patrzysz jak on ten komunikat
> > WM_PAINT obsługuje ?
>
>
>
> Ale to chyba jakiś dissasembler masz na myśli ? Mamy przecież do
> dyspozycji goły exe i nic ponad to. Dodatkowo nie mamy pewności, czy
> nasza funkcja nie siedzi w jakimś dll - choć ok. w tym konkretnym
> przypadku to mało prawdopodobne. Załóżmy że przełamię "barierę językową"
> ;) Jak w takim kodzie znaleźć assemblerowy odpowiednik ~"case WM_PAINT"
> skoro na tym poziomie komunikat będzie reprezentowany przez liczbę a nie
> przez nazwę. Dodatkowo takich ~"case WM_PAINT" będzie tyle ile
> komponentów w aplikacji (dobrze myślę?) i skąd wiadomo który z nich to
> jest właśnie ten. Jeśli by chcieć szukać interesującego nas fragmentu
> kodu poprzez jakiś charakterystyczny string, to też mamy problem. To
> jest komponent chatu i wyświetla to co ludzie napiszą. Exe wrzucony do
> dissasemblera nie jest (?) działającym programem.
> Może źle zrozumiałem "włączasz debuger" ?
>
>
>
> > Wtedy zobaczysz co (tekst) i skąd (bufor)
> > bierze.A nawet jak/jakim_api to pisze :))))))
>
>
>
> Do tego dążę :)
>
>
>
> > Wtedy podmieniasz na swoją procedurę
> > i przed paint robisz kopie do logu ?
> > :))))))))))
>
>
>
> Taki jest właśnie plan. Co prawda nigdy tego nie robiłem, ale w sieci
> pełno materiałów i przykładów jak to się robi, więc tu problemu nie
> powinno być :)
>

no wydaje mi sie ze raczj te teksty nie ida przez
zadne komunikaty tylko w komponancie jest wywolywany
kod winsocka i to idze przez recv czy cos takiego

faktycznie chyba trzebaby to 'crackowac' tj wlaczyc
np pod ollyebug (byc moze zobaczy on nazwe recv w
kodzie bo rozpoznaje niektore wywolania winapi
- po czym napisac pare linijek w asmie tak by
wywolywal procedure ze wskaznikiem na tekst - ale
nigdy nie robilem takich rzeczy poza bardzo prostymi
tak ze nie wiem,)

do góry

Użytkownik "Przemysłąw Dębski" <p...@g...pl> napisał w wiadomości
news:kpea2d$2mf$1@node1.news.atman.pl...
> kali pisze:
...
> Ale to chyba jakiś dissasembler masz na myśli ? Mamy przecież do
> dyspozycji goły exe i nic ponad to. Dodatkowo nie mamy pewności, czy
> nasza funkcja nie siedzi w jakimś dll - choć ok. w tym konkretnym
> przypadku to mało prawdopodobne. Załóżmy że przełamię "barierę językową"
> ;) Jak w takim kodzie znaleźć assemblerowy odpowiednik ~"case WM_PAINT"
> skoro na tym poziomie komunikat będzie reprezentowany przez liczbę a nie
> przez nazwę. Dodatkowo takich ~"case WM_PAINT" będzie tyle ile
> komponentów w aplikacji (dobrze myślę?) i skąd wiadomo który z nich to
> jest właśnie ten. Jeśli by chcieć szukać interesującego nas fragmentu
> kodu poprzez jakiś charakterystyczny string, to też mamy problem. To
> jest komponent chatu i wyświetla to co ludzie napiszą. Exe wrzucony do
> dissasemblera nie jest (?) działającym programem.
> Może źle zrozumiałem "włączasz debuger" ?

dobrze zrozumiałeś - debugger :)))
Choć IDA razem z debuggerem też może być.

Wszystko zalezy od windowsa: XP, 7,8,* 64/32 ?
najbezpieczniejszy bedzie windbg - bo od MS-
i działa na wszystkich windowsach - ale ciężki w obsłudze.
Oly bedzie przydatny tylko na 32 bitowych
ale masz więcej tutoriali - opisów bardziej przyjazny.
Kiedys softice był dobry na wszystko :)))))

Debuggerowi wszystko jedno
czy to jest w exe czy dll czy w czym innym
on działa na tym co juz w pamięci - skąd się tam
wzięło to mało ważne.
Jednak jeśli to komponent w C# np. to
nie tędy droga . A jeszcze może np.
( to juz perwrsja) rysowac poprzez directx
:))))

trzeba najpierw rozpoznać co to jest i czy nie ma
zabezpieczeń antydebugg
bo wtedy sprawa sie komplikuje.

Może puść to pod procesmonitor - sysinternals ?
http://technet.microsoft.com/en-us/sysinternals/bb89
6645

będzisz miał nadmiar informacji :))))

pozdr.

do góry

On 14 Cze, 10:47, "kali" <g...@t...pl> wrote:
> Użytkownik "Przemysłąw Dębski" <p...@g...pl> napisał w
wiadomościnews:kpea2d$2mf$1@node1.news.atman.pl...
>
> > kali pisze:
> ...
> > Ale to chyba jakiś dissasembler masz na myśli ? Mamy przecież do
> > dyspozycji goły exe i nic ponad to. Dodatkowo nie mamy pewności, czy
> > nasza funkcja nie siedzi w jakimś dll - choć ok. w tym konkretnym
> > przypadku to mało prawdopodobne. Załóżmy że przełamię "barierę językową"
> > ;) Jak w takim kodzie znaleźć assemblerowy odpowiednik ~"case WM_PAINT"
> > skoro na tym poziomie komunikat będzie reprezentowany przez liczbę a nie
> > przez nazwę. Dodatkowo takich ~"case WM_PAINT" będzie tyle ile
> > komponentów w aplikacji (dobrze myślę?) i skąd wiadomo który z nich to
> > jest właśnie ten. Jeśli by chcieć szukać interesującego nas fragmentu
> > kodu poprzez jakiś charakterystyczny string, to też mamy problem. To
> > jest komponent chatu i wyświetla to co ludzie napiszą. Exe wrzucony do
> > dissasemblera nie jest (?) działającym programem.
> > Może źle zrozumiałem "włączasz debuger" ?
>
> dobrze zrozumiałeś - debugger :)))
> Choć IDA razem z debuggerem też może być.
>
> Wszystko zalezy od windowsa:  XP, 7,8,* 64/32 ?
> najbezpieczniejszy bedzie windbg  - bo od MS-
> i działa na wszystkich windowsach - ale ciężki w obsłudze.
> Oly bedzie przydatny tylko na 32 bitowych
> ale masz więcej tutoriali - opisów bardziej przyjazny.
> Kiedys softice był dobry na wszystko :)))))

Mamy do czynienia z XP wziętym zasadniczo z Węgorzewskiej ;)

> Debuggerowi wszystko jedno
> czy to jest w exe czy dll czy w czym innym
> on działa na tym co juz w pamięci - skąd się tam
> wzięło to mało ważne.
> Jednak jeśli to komponent w C# np. to
> nie tędy droga . A jeszcze może np.
> ( to juz perwrsja) rysowac poprzez directx
> :))))

Możliwe że są jeszcze bardziej perwersyjni, gdyż ten API Monitor
którym wczoraj się bawiłem DX-a też monitorował :)

> trzeba najpierw rozpoznać co to jest i czy nie ma
> zabezpieczeń antydebugg
> bo wtedy sprawa sie komplikuje.

Jakie tam zabezpieczenia są to nie wiem, ale pewne jest że autorzy
celowo dołożyli starań, by z tego okienka nie dało się nic wyciągnąć,
tudzież by to maksymalnie utrudnić.

> Może puść to pod procesmonitor - sysinternals
?http://technet.microsoft.com/en-us/sysinternals/bb8
96645
>
> będzisz miał nadmiar informacji :))))

Poćwiczę temat gdy wrócę z fabryki.
Natomiast w drodze do fabryki zdałem sobie sprawę z jednego pozornie
błahego faktu. Otóż w tym chacie działa zaznaczenie pojedynczej
linijki i Ctrl+C. Może od tej strony da się jakoś obadać ?

Aha - rozwinę nieco pierwotny plan z pomysłem. Otóż wiedząc że
bezpośrednio w komponencie ciężko będzie znaleźć miejsce w którym
teksty są przetwarzane, pomyślałem, że jak ten komponent by się nie
zabezpieczał i tak ostatecznie musi się odwołać do jakiejś funkcji
systemowej która to fizycznie wyświetli. Plan polegał na
zidentyfikowaniu tej funkcji która jest używana (bezpośrednio lub
pośrednio) do tego wyświetlania i podpięcie się zamiast niej.
Oczywiście trzeba by pokombinować jak zidentyfikować proces ją
wywołujący i zrobić bypass na nie interesujące nas wywołania innych
procesów. Miało by to dodatkowo jedną zaletę. Program który
podsłuchujemy miał by nikłe szanse na zorientowanie się że jest
podsłuchiwany.

Pozdrawiam

do góry

Użytkownik "Przemysław Dębski" <p...@g...pl> napisał w wiadomości
news:f5c5c9c8-de32-4ba3-a718-9135b94da9fa@fv8g2000vb
b.googlegroups.com...
On 14 Cze, 10:47, "kali" <g...@t...pl> wrote:
> Użytkownik "Przemysłąw Dębski" <p...@g...pl> napisał w
wiadomościnews:kpea2d$2mf$1@node1.news.atman.pl...
.

>Jakie tam zabezpieczenia są to nie wiem, ale pewne jest że autorzy
>celowo dołożyli starań, by z tego okienka nie dało się nic wyciągnąć,
>tudzież by to maksymalnie utrudnić.

no to wszystko zależy jak sie przyłożyli
może być łatwo/trudno/bardzo trudno ?

zatem powodzenia :))))))

pozdrawiam

do góry

Użytkownik "Przemysłąw Dębski" <p...@g...pl> napisał w wiadomości
news:kpdekb$8sn$1@node1.news.atman.pl...
>
> Mam nadzieję, że ze swoim problemem trafiłem na dobrą grupę, wydała mi się
> najwłaściwsza.
> Jest sobie pewien program (Win32), którego elementem jest komponent chatu
> osadzony w jednym z okien. Mam potrzebę logować w czasie rzeczywistym
> teksty, które się tam (chat) pojawiają. Problemem jest to, że jest to
> całkowicie autorski komponent twórców tego oprogramowania i nie wiadomo
> jak on działa. Podglądałem go przy pomocy Spy++, jedyny komunikat
> pojawiający się przy pojawianiu się nowej linijki tekstu to WM_PAINT. Z
> kolei API Monitor twierdzi, że żadne WinAPI nie jest wywoływane z
> parametrem w postaci pojawiającego się tam tekstu (z tekstami
> pojawiającymi się poza komponentem chatu to i owszem). Ma ktoś może pomysł
> gdzie i jak szukać tropu? O samą technikę przechwytywania tego typu rzeczy
> (jak już wiadomo co i skąd) nie pytam, to już jako tako wujek google mi
> wyjaśnił.

Grancik z PRISM?

do góry

Dnia 13-06-2013 o 23:47:11 Przemysłąw Dębski <p...@g...pl> napisał(a):

> Jest sobie pewien program (Win32), którego elementem jest komponent
> chatu osadzony w jednym z okien. Mam potrzebę logować w czasie
> rzeczywistym teksty, które się tam (chat) pojawiają. Problemem jest to,
> że jest to całkowicie autorski komponent twórców tego oprogramowania i
> nie wiadomo jak on działa.

Jeżeli jest to czat, to pewnie komunikuje się drogą sieciową z innymi
instancjami aplikacji. Może spróbować ugryźć problem z tej strony?

--
Boguś
/Każdy skutek ma swoją przyczynę/

do góry