Ponowne przechwytywanie wciśniętych klawiszy.

0

Witam potrzebuje bardzo pomocy ponieważ nie wiem jak sobie z tym poradzić. Chodzi o to że piszę do szkoły program przechwytujący wciśnięte klawisze ale tylko i wyłącznie z jednego programu jakim jest notatnik. Jednak problem tkwi w tym że nie wiem jak napisać pętelkę która pozwoli na zapis klawiszy przy każdym uruchomieniu notepada. Bo aktualnie po uruchomieniu notepada wraz z programem to wszystko ładnie działa lecz gdy program zostanie zamknięty a programik włączony to tak jak by przestał działać. Czy jest ktoś w stanie mi pomóc aby to działało zgodnie z moimi oczekiwaniami ? Aha i tak w ogóle to Wujka google przeszukałem pod wszystkimi zapytaniami jakie mi tylko przyszły do głowy :)

0

Rozumiem, że chodzi o Delphi. Zawssze taguj kod językiem lub środowiskiem, a nie słowami z tematu czy treści. A co do pytania to pokaż kod jak przechwytujesz, bo ja bym spróbował założyć globalnego hooka na SendMessage albo/i PostMessage sprawdzając czy komunikat to WM_CHAR, natomiast z przekazywanego uchwytu sprawdził czy należy on do okienka edycyjnego w notatniku. Przykłady kodu znajdziesz w google. A jeśli ktoś tutaj ma lepszy pomysł to podpowiedzcie lepsze albo inne rozwiązanie.

0

przechwytuję przez komponent jakim jest KeySpyXP. Chyba za bardzo rozbudowanym kodem to nie ma co się chwalić :) A czy mógł byś dać jakieś wskazówki w jaki sposób to napisać ??

1

Przeanalizuj sobie kod dołączony do tego posta. Sorry, ale nie pomyśłałem wcześniej odpisując, bo się śpieszyłem by wyjśc i zdążyć do pracy, a później po powrocie nie miałem długo w ogóle Internetu, bo UPC miało jakąs awarie pewnie przez przebudowujących drogę robotyników. Anyway, Hook na funckje API to tutaj nietrafiony pomysł, bo kontorlka wiadomo nie wyśle sama do siebie komunikatu tylko je obsłuży, dlatego też wstrzyknięcie dllki do procesu notepad.exe jest już bardziej trafione. I taką metodę zastosowałem. Wcześniej nie bawiłem się we wstrzykiwanie własnej dllki do innego procesu, ale wygooglowując informacje na temat pisania trainerów w dll doszukałem się informacji o module afxcodehook.pas, który tutaj zdał egzamin. A zagadnieniem bawiłem się od poniedziałku pisząc trainera z użyciem tej metody do starej dosowej gry. Wracając do kodu - to calość napisana jest w WinAPI i u mnie pod Windows 7 Ultimate 64 bit PL działa jak należy. Zasada działania po wstrzyknięciu jest prosta. Ponieważ możemy ustawić własną procedurę dla obsługi komunikatów okna lub kontrolki w tym oknie, ale wiadomo, że funkcja SetWindowLong z parametrem GWL_WNDPROC pozwala ustawić nową funkcję obsługi komunikatów tylko dla bieżącego procesu, a nie obcego. Dlatego mając wstrzykniętą dllkę omijamy ten problem, bo staje się ona jakby "dodatkowym kodem" w procesie, do którego została wstrzyknięta, a operacje na oknie możemy łątwo przeprowadzić mając Pid wstrzykniętego procesu, który dllka otrzymuje w prosty spsoób dzięki funkcji GetCurrentProcessId. Natomiast uzyskanie okna głownego na podstawie identyfikatora procesu przypomina moją metodę z tego gotowca na: Uchwyt na podstawie nazwy pliku exe programu - tylko, że tutaj zamiast nazwy procesu exeka podajemy jego Pid. Mam nadzieję, że jakoś Tobie pomogłem. A i uwaga co do zawartości archiwum, zawiera poza pełnym kodem również skompilowane pliki aby móć to łatwo przetestować. Dlatego piszący tutaj w komentarzu do mojej poprzedniej odpowiedzi t.r. nie może tego pobrać, bo mu mama chyba nie pozwala. Poza tym coś w komentarzy ściemnia, bo pamiętam, że pytał o nadawce wiadomości komunikatu, a nie to jak ustalić okno docelowe. Ale mogę się mylic jednak to nie jest temat na ten wątek. Pytającemu powodzenia życze w dalszym i już samodzielnym kombinowaniu. Bo jak widać metoda jaką zastosowałem z użyciem gotowego modułu do wygooglowania w necie jest banalna. A wcześniej też nie bawiłem się we wstrzykiwanie dllek. A dodam tylko, że dllka do wstrzykiwana jest ładowana z zasobów, a całośc pakowana jest UPX'em. Projekt kompiluje się wygodniej plikiem build.bat, a testuje uruchamiając run.bat. Na koniec dodam, że do skompilowania użyłem modułów z http://kolmck.net/sys/SysDcu7.zip poleconych mi kiedyś przez Miśkad. Pozwalają one pod Delphi 7 na osiągnięcie jeszcze mniejszych plików wykonywalnych i to przez spakowaniem jakimś wydajnym packerem plików wykonyalnych, ale tylko jeżeli piszemy w czystym WinAPI, nie używając modułów od VCL.

EDIT: Poprawiłem kod i dołaczyłem do posta powyżej - głownie drobne poprawki kosmetyczne. Polecam pobrać archiwum raz jeszcze. Na bazie tego rozwiązania można napisać coś w tym stylu, a nawet lepszego. Zapis do pliku czy wysyłanie do innej aplikacji przez DDE, Sockety albo na przykład WM_COPYDATA. Możliwości jest mnóstwo. Jednak ważne by nie zahaczyć o tworzenie malware, bo to zło.

EDIT #2: Ponownie poprawiłem kod. Kto zainteresowany niech pobierze raz jeszcze, bo wcześniej Bufor na odczytane z Memo znaki miał tylko ponad 5 KB. Teraz kod został zerżnięty z kodu modułu VCL do obsługi TControl, więc powinno być raczej idealnie, bo tak pisal Borland swoje kontrolki. A moje ostatnie posty w tym wątku dla porządku scaliłem w jeden.

0

Odświeżam temat. Zmiany opisane w powyższym postcie.

0

Może po prostu zrobić instrukcje warunkową, że jeśli aktywnym programem jest notatnik to przechwytuje klawisze, a jeśli nie to nie przechwytuje?

0

@qeeepek: Można i tak kombinować. Jednak lepiej spróbowac wstrzyknąc dllkę, tak jak to pokazałem w swoim kodzie. Ponieważ wtedy rejestrujemy tylko znaki na prawdę wpisane w kontrolkę edycyjną notatnika i mamy nad tym kontrolę. Nie zanotujemy na przykład Alt+Tab albo czegoś czego nie chcemy. Poza tym sprawdzanie co chwila jakie jest aktywne okno jest według mnie rozwiązaniem mało optymalnym. Jednak pytający zrobi jak uważa za stosowne byle by działalo, jeżeli zależy mu tylko na jakimkolwiek pozytywnym efekcie końcowym. Niemniej jednak pokazałem powyżej metodę - według mnie - znacznie bardziej elastyczną i uniwersalną dla innych programów. A i u mnie na przykład KAV 2010 mimo włączonej proaktywnej ochrony nie czepia się tego sposobu injectowania dllki, a wiem, że czasami w przypadku Hooka na klawiarutę może wyświetlić jakieś ostrzeżenia. Nie wiem jak inne antywirusy, ale porządne oprogramowanie antywirusowe nie powinno sprawiać problemów i fałszywie czy zbyt nadgorliwie ostrzegać Użytkownika przed czymś, co zagrożeniem wprawdzie może być, ale tutaj w tym kontekstcie nie jest.

0

W moim przypadku antywir(nod32) nie ma żadnych zastrzeżeń co do hooka na klawiature. A co do tego sposobu to jest on zapewne prostszy niż dllki, ale nie twierdze, że lepszy itp.

0

No rozumiem, ale Hook sprawdzający co klawisz czy aktywnym oknem jest na przykład Notatnik, jest wedle mnie mało optymalne. Metoda z injeckją dllki zarówno dla takiego zastosowania jak i na przykład dla Trainera do gry, sposobała mi się. Dzięki injekcji dllki robimy też takiego jakby Hooka, ale takiego, który może przechwycić i obslużyć komunikaty dla konkretnego okna albo kontrolki w danym procesie.

0

Ok. Jeszcze sie nie uczyłem o wstrzykiwaniu dll, więc napisałem to co dotychczas sie nauczyłem. :P

1 użytkowników online, w tym zalogowanych: 0, gości: 1