Zrobiłem coś co odczytuje wciśnięte klawisze i zapisuje to do zmiennej, którą później daję pod messageboxa i tak się tym bawię :). Moje pytanie jest takie, czy mogę odróżniać duże litery od małych?, bo nie zależnie czy piszę z capslockiem czy bez to i tak są duże litery. Dołączam plik, który jest niezbędny bo to on odczytuje te wciśnięte klawisze. Jeżeli ktoś wie o co mi chodzi to bardzo proszę o pomoc. Pozdrawiam !
0
0
Sprawdź stan capslocka, oraz shifta.
0
W programie czy na klawiaturze?, jeśli na klawiaturze to wszystko jest ok
0
Tworzysz sobie boola (bul'a jak by Prezydent napisał)
Na początku sprawdzasz przez Control.IsKeyLocked(Keys.CapsLock);
Potem, przy naciśnięciu sobie zmieniasz jego stan ;)
0
musisz w programie odczytać stan klawiszy. poszukaj sobie jakiś tutoriali do keyloggerów w delphi tam powinny być gotowce, wystarczy że znajdziesz jakieś odpowiedniki funkcji w .NET albo skorzystasz z funkcji winapi
0
Ja dodam że pisanie keyloggerów, hooków w C# to niedorzeczność. No ale zawsze można się nauczyć jak działa import funkcji z WinAPI, bo keyboardproc i mouseproc jest obsługiwany.
0
Zastanawia mnie, skąd ten trend na forum do pisania hooków, wstrzykiwaczy kodu, komunikacji międzyprocesowej, eksportowania funkcji do kodu natywnego — akurat w C#, języku który wybitnie do takich zastosowań przeznaczony nie jest.
0
Siedzę w tym c# i próbuję coś w nim robić. Jeśli chodzi o ten capslock to sprawdzę niebawem ale mam jeszcze jedno pytanko, gdy wysyłam to dla kolegi to po przytrzymaniu jakichś klawiszy wyskakuje brak odpowiedzi i program wyłącza się. Czym to może być spowodowane?
0
Jeśli chodzi o capslock to jest wyłączony a i tak duże litery są
0
no i co z tego ze są duże? to sobie je interpretuj jako małe, skoro jest wyłączony.
0
A bez kitu, dobry pomysł. Może dałbyś mi jakąś radę co robić w c#, jakie programiki pisać, bo muszę się uczyć a ten keylogger z nudów robię bo nie wiem co innego pisać, podrzuć mi pomysł
0
Serializacja, komunikacja TCP, co ja tam jeszcze robiłem jak się uczyłem.. Jak się bawiłem językiem to chyba wysyłanie maili, sprawdzanie zewnętrznego ip. Ogólnie lubie sprawy internetowe. Nie wiem czy cię to kręci, ale jak dla mnie to jest super.
0
Wszystko mnie kręci co związane z programowaniem
0
Ciężko powiedzieć na jakim jesteś poziomie.
Może przesyłanie plików między kompami po TCP, jakiś budzik/przypominacz, czat i jego różne wariacje.
0
Ogarnąłem też trochę wysyłanie emaila, nad budzikiem pomyślę a jak wysyłać między kompami pliki nie wiem co dopiero jakiś czat
0
no to może jeszcze jakiś program do notatek, bardziej złożony kalkulator(np. z obsługą ONP i obliczający złożone wyrażenia).
0
Azarien napisał(a):
Zastanawia mnie, skąd ten trend na forum do pisania hooków, wstrzykiwaczy kodu, komunikacji międzyprocesowej, eksportowania funkcji do kodu natywnego — akurat w C#, języku który wybitnie do takich zastosowań przeznaczony nie jest.
Bo jest łatwy i w designerze fajnie się przeciąga komponenty z toolboxa na formatkę.
0
Coś postaram się zrobić. Teraz dumam przeniesienie informacji między formami i jestem w dziwnej sytuacji, z formy2 mogę odczytać co jest napisane w labelu1, lecz nie mogę zmienić zawartości labela1 mimo tego iż label1 mam ustawiony na public. Naprowadzi mnie ktoś co źle zrobiłem?
0
NoobQuestion:
Czemu C# się nie nadaje np do Keyloggerów? Konkretne argumenty możecie podać?
1
to tak samo jak młot pneumatyczny nie nadaje się do naprawy zegarków
0
Do każdego procesu, do którego chciałbyś wstrzyknąć (jak w przypadku hooków) coś, co działa na CLR on również musi zostać wczytany. Jeżeli proces ma już swojego CLRa w innej wersji, mogą powstawać kolejne problemy (nad tym pracowano akurat w .NET 4). Wszelka komunikacja z natywnymi bebechami odbywa się najczęściej przez P/Invoke. Jest ono zwyczajnie wolne. Jeżeli chodzi o wywołanie trzech funkcji - ok, jeżeli chcemy regularnie zbierać jakieś callbacki, pojawia się problem. I tak dalej i tak dalej. Do wszelkich "rozszerzeń" (hooki, shell extensions) Windows, którym .NET nie jest dedykowany (a jest np. pakietowi Office czy SQL Server), lepiej użyć czegoś natywnego, np. C/C++.
2
krwq napisał(a):
to tak samo jak młot pneumatyczny nie nadaje się do naprawy zegarków
Znaczy że C#em możemy zniszczyć keyloggera bo ma on za dużą moc?
0
Bo im język wyższego poziomu, tym trudniejszy dostęp do rzeczy niskiego poziomu.
Wyobraź sobie to tak. Poziom niski, średni i wysoki (ASM, C(++), C#) to piętra domu. Znacznie trudniej myje się mopem podłogę na parterze z piętra pierwszego. A żeby myć z drugiego, musisz mieć naprawdę długi kij. Tym kijem są tu różnego rodzaju importy, korzystanie z bibliotek napisanych w C++...,
W niektórych przypadkach można powiedzieć "w C# tego nie da się zrobić", w większości "tego się nie opłaca robić". Przy znacznie większym nakładzie pracy zrobisz coś, co w C++ zajęło by kilkanaście linijek.
0
Rev napisał(a):
Do każdego procesu, do którego chciałbyś wstrzyknąć (jak w przypadku hooków) coś, co działa na CLR on również musi zostać wczytany. Jeżeli proces ma już swojego CLRa w innej wersji, mogą powstawać kolejne problemy (nad tym pracowano akurat w .NET 4). Wszelka komunikacja z natywnymi bebechami odbywa się najczęściej przez P/Invoke. Jest ono zwyczajnie wolne. Jeżeli chodzi o wywołanie trzech funkcji - ok, jeżeli chcemy regularnie zbierać jakieś callbacki, pojawia się problem. I tak dalej i tak dalej. Do wszelkich "rozszerzeń" (hooki, shell extensions) Windows, którym .NET nie jest dedykowany (a jest np. pakietowi Office czy SQL Server), lepiej użyć czegoś natywnego, np. C/C++.
Ok, ale keylogger (popraw mnie jesli sie myle) ma tylko sczytywac stan klawiatury i go gdzies sobie zapisywac. Wiec nie potrzebne tu chyba jest wstrzykniecie zadne itp
0
ubuntuser napisał(a):
Bo im język wyższego poziomu, tym trudniejszy dostęp do rzeczy niskiego poziomu.
Wyobraź sobie to tak. Poziom niski, średni i wysoki (ASM, C(++), C#) to piętra domu. Znacznie trudniej myje się mopem podłogę na parterze z piętra pierwszego. A żeby myć z drugiego, musisz mieć naprawdę długi kij. Tym kijem są tu różnego rodzaju importy, korzystanie z bibliotek napisanych w C++...,
W niektórych przypadkach można powiedzieć "w C# tego nie da się zrobić", w większości "tego się nie opłaca robić". Przy znacznie większym nakładzie pracy zrobisz coś, co w C++ zajęło by kilkanaście linijek.
Ok, dziękuję. ogólną iddeę zrozumiałem :) Nie znam jeszcze konkretnym przykładów dlaczego np konkretnie keylogger nie moze byc napisany w C# a to mnie ciekawi.
0
Ale męczysz. Może być napisany. Akurat keylogger może, bo funkcja KeyboardHookProc ma się całkiem dobrze, znacznie lepiej niż hook globalny. Ale i tak szybciej będzie w c++