Twój adres IP to: 54.161.235.83
Przeglądarka: CCBot/2.0 (http://commoncrawl.org/faq/)


OE PowerTool
Wersja stabilna: 4.5.1

Ludwig von Mises Institute

Zmiana częstotliwości synchronizacji czasu w Windows 7

15 czerwca 2014

Windows domyślnie synchronizuje czas przez Internet raz w tygodniu. Bywa, że jest to niewystarczające, bo systemowy czas rozjeżdża się szybciej. Często spotykaną poradą na zmianę częstotliwości synchronizacji jest modyfikacja wartości SpecialPollInterval w rejestrze. Jest ona tak rozpowszechniona, że jej nie weryfikowałem i nawet można było ją znaleźć na mojej stronie. Zauważyłem jednak, że modyfikacja tej wartości nie pomaga. Owszem, Windows podawał krótszy czas do następnej synchronizacji, jednak czas nadal się rozjeżdżał o kilkadziesiąt sekund. Nie udało mi się znaleźć informacji jak dokładnie ta wartość wpływa na synchronizację, ani jakie jeszcze ustawienia wchodzą w grę. Jest co prawda w Harmonogramie zadań zadanie synchronizujące czas, ale także jego modyfikowanie nie pomaga. Konieczne jest stworzenie własnego, oddzielnego zadania, opartego np. o systemowy program w32tm.exe.

W tym celu w Harmonogramie zadań przechodzimy do gałęzi Biblioteka Harmonogramu zadań -> Microsoft -> Windows -> Time Synchronization. Nie musi być to koniecznie ta gałąź, ale utworzenie zadania w tym miejscu pozwoli zachować porządek. Klikamy Utwórz zadanie... Wpisujemy jakąś nazwę zadania, np. Synchronizuj czas. Użytkownika, na którego prawach będzie uruchamiane zadanie, trzeba zmienić na ZARZĄDZANIE NT\USŁUGA LOKALNA. Trzeba też zaznaczyć opcję Uruchom z najwyższymi uprawnieniami. Następnie w zakładce Wyzwalacze tworzymy nowy wyzwalacz, w którym możemy określić jak często zadanie ma być uruchamiane, np. codziennie, z nieograniczonym powtarzaniem co godzinę. Następnie trzeba utworzyć dwie akcje. Pierwsza ma zapewnić, że jest włączona usługa Czas systemu Windows (w32time). Tworzymy więc akcję typu Uruchom program i jako ścieżkę podajemy:

%windir%\system32\sc.exe

oraz argumenty:

start w32time task_started

Druga akcja to właściwa synchronizacja czasu. Tworzymy ją podobnie, wpisując ścieżkę:

%windir%\system32\w32tm.exe

oraz argument:

/resync

Ważne jest, żeby akcje były na liście w tej właśnie kolejności. W zakładce Warunki warto wyłączyć opcję uruchamiającą zadanie tylko wtedy, gdy komputer jest na zasilaniu sieciowym. Z kolei w zakłace Ustawienia dobrze jest zaznaczyć opcję Uruchom szybko zadanie, jeśli pominięto zaplanowane uruchomienie. I to wszystko, zadanie powinno działać poprawnie. Można je przetestować uruchamiając je ręcznie. Jeśli czas systemowy był niepoprawny, powinien ustawić się na prawidłowy. Trzeba pamiętać, że jest to zadanie niezależne, niezwiązane z systemową synchronizacją. Dlatego jeśli np. ustawimy wyzwalanie co godzinę, Windows może nadal twierdzić, że następna synchronizacja będzie np. za tydzień. I jeszcze jeden szczegół. Konsola Harmonogramu zadań nie odświeża swojego widoku zbyt często. Dlatego warto wcisnąć F5 żeby zobaczyć aktualny status zadania (stan, czas ostatniego uruchomienia, wynik)


Import grafiki wektorowej do MS Word

24 maja 2014

Tworząc dokument w Wordzie, trzeba czasem zaimportować jakąś grafikę wektorową, np. schemat elektroniczny. Można wkleić zrzut ekranu, jednak znacznie traci się wtedy na jakości, co jest szczególnie problematyczne, gdy dokument jest przeznaczony do druku. Konwersja na postać rastrową jest więc niedopuszczalna. Word obsługuje kilka formatów wektorowych, jednym z nich jest EPS (enkapsulowany PostScript). Posiadany materiał trzeba więc zapisać w formacie EPS. W moim przypadku źródłem grafiki wektorowej były pliki PDF. Do konwersji użyłem programu Inkscape, który pozwala na import pliku PDF, wykonanie ewentualnej obróbki, oraz eksport do EPS. Tę metodę można zastosować również w przypadku, gdy źródłem grafiki wektorowej jest jakaś aplikacja, trzymająca dane w swoim formacie, ale mająca możliwość wydruku. Wtedy można za pomocą wirtualnej drukarki PDF wykonać wydruk do pliku, zaimportować go do Inkscape, przekonwertować na EPS, a następnie zaimportować do dokumentu MS Word.


Reverse engineering na przykładzie prostego crackme

3 października 2013

Oprócz umiejętności programowania nieraz przydać się może także znajomość metod tzw. inżynierii odwrotnej, czyli analizy działania skompilowanych programów. Posługują się nią m.in. osoby tworzące cracki czy generatory seriali pozwalające obejść zabezpieczenia licencyjne w oprogramowaniu. To też podstawowa umiejętność pracowników firm antywirusowych, którzy analizują działanie wirusów. Przydać się też może w przypadku starego, niewspieranego oprogramowania, które nie może być zastąpione innym. Dotyczy to np. sterowników starszych urządzeń. Jeśli nie są dostępne źródła aplikacji, trzeba spróbować zdekompilować jej plik wykonywalny i ustalić w jaki sposób dany program działa. Podczas gdy w przypadku języków takich Java czy C# jest do dosyć proste, o tyle dekompilacja programu napisanego w C czy C++ jest trudna i czasochłonna. Dzieje się tak ponieważ kompilator może dany kod źródłowy skompilować na wiele sposobów, zależnie np. od ustawionego stopnia optymalizacji. Dekompilator musi więc bardzo często zgadywać i w wyniku dostaje się kod mało czytelny i trudny do analizy. Sytuacja na szczęście nie jest beznadziejna i dysponując odpowiednią wiedzą i zaawansowanymi narzędziami (np. IDA) można dosyć dokładnie rozgryźć dany program.

Dla początkujących w dziedzinie reverse engineeringu oraz chcących sprawdzić swoje umiejętności, tworzone są tzw. crackme. Są to programy, w których trzeba złamać hasło, napisać generator seriali lub w inny sposób wykazać, że rozgryzło się dane crackme. Często są rozprowadzane z podpowiedziami albo nawet gotowymi rozwiązaniami. Jeśli więc nie uda się nam złamać danego crackme, możemy przeczytać jakich metod należało użyć i w ten sposób nauczyć się kolejnych metod. W tym artykule chciałbym przedstawić łamanie crackme stworzonego przez osobę o nicku Devoney. Jest to proste crackme, do którego analizy można wykorzystać nawet najprostszy debugger/dekompilator. Ja użyłem Immunity Debugger. Naszym zadaniem jest podanie hasła.

crackme

Załadujmy więc crackme do debuggera. Wciskamy F9 aby przeskoczyć na początek kodu programu (adres 0x00401000).

debugger

Wciskamy F9 jeszcze raz, aby uruchomić program.

crackme

Lecz co się okazuje? Crackme posiada zabezpieczenie przed reversowaniem za pomocą debuggera. Na szczęście jest to proste crackme i możemy sobie z tym zabezpieczeniem poradzić dosyć łatwo. Realizowane jest ono za pomocą wywołania funkcji IsDebuggerPresent. Normalnie funkcja ta zwraca zero, jednak gdy proces wywołujący działa pod kontrolą debuggera, funkcja zwraca wartość niezerową. Wartość zwracana jest standardowo, przez rejestr EAX. Musimy więc sprawić, że w EAX będzie zero, nawet pod debuggerem. Przeglądając kod crackme (jest bardzo krótki, więc można ręcznie) widzimy, że funkcja IsDebuggerPresent jest wołana dwa razy: raz z adresu 0x0040131A, a raz z 0x004013AF. W tych dwóch miejscach musimy więc zasymulować brak obecności debuggera. Aby program działał tak, jakby debuggera nie było, trzeba wyzerować rejestr EAX. Można to zrobić np. instrukcją XOR EAX, EAX Ustawiamy więc kursor pod adresem 0x0040131A i wciskamy spację

debugger

Wpisujemy instrukcję, klikamy Assemble a następnie Cancel. OK, program mamy już spatchowany w jednym miejscu. Wykonujemy więc jeszcze taką samą operację dla adresu 0x004013AF.

debugger

Teraz można już przystąpić do analizy generowania hasła. Dla ułatwienia podzieliłem ją na punkty.

1. Program zaczyna się standardowo od adresu 0x00401000. Na początku skacze pod adres 0x00401017, gdzie znajduje się kod wczytujący stringi i tworzący okienko.

2. Okienko tworzone jest funkcją DialogBoxIndirectParam. Ma ona parametr lpDialogFunc, który określa funkcję przetwarzającą komunikaty okna. Tutaj jest ona pod adresem 00401308.

3. Procedura okna przetwarza przychodzące komunikaty. M.in. inicjalizuje wygląd okna w zależności od tego, czy został wykryty debugger. Reaguje także na kliknięcie przycisku. Sygnalizowane jest to komunikatem WM_COMMAND. Odpowiada mu liczba 0x111. Parametry są przekazywane do procedury przez stos. Dlatego możemy się do nich odwoływać względem rejestru EBP:
EBP+8 - hWnd
EBP+C - uMsg
EBP+10 - wParam
EBP+14 - lParam
Aby więc sprawdzić czy został kliknięty przycisk, program porównuje zawartość adresu wskazywanego przez EBP+C z liczbą 0x111 (WM_COMMAND) a EBP+10 z 1 (identyfikator przycisku).

4. Jeśli nastąpiło kliknęcie przycisku, pobierany jest tekst z pola tekstowego i rozpoczyna się weryfikacja hasła. Jest ona wykonywana poprzez wygenerowanie ciągu rozpoczynającego się pod adresem 0x0040304B. Ciąg ten będzie potem porównany z wpisanym hasłem.

debugger

5. Liczba znaków hasła jest przez funkcję GetDlgItemTextA zwracana przez rejestr EAX. Program kopiuje tę wartość do rejstru EBX, a następnie dodaje do niej 0x3C (60 dziesiętnie). W ten sposób dla hasła 5-znakowego otrzymamy liczbę 65, które odpowiada litera A. Dla 6-znakowego będzie to liczba 66 czyli litera B, itd. Wynikowa litera zapisywana jest na pierwszej pozycji generowanego ciągu.

6. Wpisane przez użytkownika hasło trafiło pod adres 0x00403144. Widzimy, że program ładuje do EBX wartość spod adresu 0x00403146, a więc trzeci znak hasła. Dodaje do niego 0x31, czyli 49 dziesiętnie. Patrząc na tablicę ASCII widzimy, że taka operacja może np. zamieniać kolejne cyfry na litery, czyli cyfrę 0 (w sensie znaku ASCII reprezentującego zero, mającego wartość 0x30, dziesiętnie 48) na literę a (znak o kodzie 0x61, dziesiętnie 97).

7. Następnie ładowana do EBX jest wartość spod adresu 0x00403148, czyli piąty znak hasła. Od tej wartości odejmowane jest 0x0A, czyli 10. Czyli trzeci znak hasła musi być o 10 mniejszy od piątego.

8. W kolejnym kroku do pierwszego znaku dodawane jest 0x20. Jeśli znakiem jest litera, to z tabeli ASCII widzimy, że dodanie 0x20 powoduje zamianę wielkiej litery na małą.

9. Potem analogicznie od szóstego znaku odejmowane jest 0x22 aby otrzymać znak piąty.

10. Szósty znak otrzymywany jest przez odjęcie 5 od drugiego znaku hasła. Następuje więc tu pewna zmiana, podczas gdy znaki 2-5 ciągu były generowane względem wpisanego hasła, znaki 6-8 generowane są na podstawie znaków ciągu.

11. Siódmy znak otrzymywany jest przez odjęcie 0x28 od znaku szóstego.

12. Przy ósmym znaku widzimy, że od znaku siódmego odejmowane jest pięć, jednak wynik tej operacji nie jest używany. Do pamięci wpisywana jest po prostu liczba zero, która powoduje zakończenie ciągu.

13. Możemy więc generowanie hasła przedstawić w postaci następującej tabelki, gdzie X - wpisane hasło, Y - ciąg generowany przez crackme i porównywany z hasłem. Jako że liczymy znaki, pozwoliłem sobie indeksować od 1.

Y[1] = len(X) + 0x3C, np. litera C dla siedmioznakowego hasła
Y[2] = X[3] + 0x31, np. a dla 0
Y[3] = X[5] - 0x0A
Y[4] = X[1] + 0x20, wielka litera na małą
Y[5] = X[6] - 0x22
Y[6] = Y[2] - 0x05
Y[7] = Y[6] - 0x28
Y[8] = 0

14. To w sumie tyle jeśli chodzi o sam kod crackme. Znając algorytm weryfikacji hasła spróbujmy wygenerować poprawne hasło. Jak widać, hasło walidowane jest względem samego siebie, w tym jego długości. Crackme generuje ciąg o długości siedmiu znaków, wpisywane hasło musi mieć więc tyle samo. Znając długość hasła znamy zatem jego pierwszą literę. Będzie to C. Możemy to zapisać tak:
C______
Wiemy też, że czwarta litera hasła jest taka jak pierwsza, ale mała, mamy zatem:
C__c___
Następnie widzimy, że zależności zapętlają się, bowiem znak 2 zależy od 3, 3 od 5, 5 od 6, a 6 znów od 2. Możemy więc sobie wybrać jakiś znak początkowy i według niego obliczyć pozostałe. Jest on ogólnie dowolny, jednak trzeba wziąć pod uwagę dwie rzeczy: znak musi dać się wpisać z klawiatury, odpadają więc znaki niedrukowalne. Żaden ze znaków nie może też być znakiem zerowym (bajtem o wartości 0x00), bo będzie on oznaczał zakończenie ciągu. Przyjmijmy więc, że znakiem na pozycji 2 będzie a, i zobaczmy jakie otrzymamy pozostałe znaki.
Ca_c___
Mając znak 2 otrzymujemy znak 6. Znakiem 2 jest a, czyli bajt 0x61. Odejmując 5 otrzymujemy bajt 0x5C czyli znak \.
Ca_c_\_
Ze znaku 6 obliczamy znak 5, odejmując 0x22 od 0x5C dostajemy 0x3A, czyli :.
Ca_c:\_
Ze znaku 5 obliczamy znak 3 przez odjęcie 0x0A, otrzymując 0x30, czyli 0.
Ca0c:\_
Ze znaku 3 możemy obliczyć znak 2, ale jego wartość już sobie przyjęliśmy na początku. Możemy więc dokonać sprawdzenia, czy faktycznie różnią się one o 0x31. Faktycznie, taka jest właśnie różnica pomiędzy 0x61 a 0x30. Zostaje nam ostatni, siódmy znak. Jest to znak (bajt) szósty, pomniejszony o 0x28. Znak 6 to \ czyli 0x5C, a więc znak 7 to 0x34 czyli 4. Ca0c:\4

crackme

W ten oto sposób złamaliśmy hasło analizowanego crackme :)


Prezentacja o Raspberry Pi

8 września 2013

W serwisie VirtualStudy dostępna jest moja prezentacja będąca wprowadzeniem do komputerka Raspberry Pi.


Moja pierwsza książka

17 czerwca 2013

Moja książka Serial port and microcontrollers. Principles, circuits, and source codes. jest już dostępna.

Serial port and microcontrollers

Książka jest poświęcona wykorzystaniu portu szeregowego w układach opartych o mikrokontrolery AVR i STM32. Zawiera szczegółowy opis standardów RS-232 i RS-485, a także wprowadzenie do projektowania układów opartych o mikrokontrolery oraz pogramowania ich w języku C. Przedstawione są przydatne narzędzia programistyczne oraz sprzętowe. Oprócz obsługi portu szeregowego w mikrokontrolerach, omówione zostało programowanie tego portu na komputerach PC, zarówno pod Windows jak i Linuksem. Książka zawiera również dużo informacji pobocznych, jak konwersja między RS-232 a USB, czy też wykorzystanie portu szeregowego w aplikacjach webowych. Całość uzupełnia kilkanaście praktycznych przykładów.

Wraz z książką dostępne są kody źródłowe i dokumentacja wykorzystanych elementów.


Zarządzanie procesami pod Windows

31 stycznia 2013

Dziś trochę o podstawach pracy z procesami pod Windows.

Programy, które uruchamiamy, są widziane przez system operacyjny jako tzw. procesy. Każdy proces posiada swój plik wykonywalny, czyli plik z którego został uruchomiony. Pliki te mają rozszerzenie .exe. Przykładowo Notatnik uruchamiany jest z pliku notepad.exe. Gdy włączamy program, system operacyjny ładuje do pamięci dany plik .exe i analizuje jego zawartość. Wczytuje z niego właściwy kod programu, informacje o używanych bibliotekach (pliki .dll), które też ładuje, oraz inne dane związane z wykonywaniem danego programu. Po uruchomieniu proces otrzymuje swój identyfikator - PID. Po tych identyfikatorach można rozróżniać uruchomione procesy, szczególnie jeśli jakiś program został uruchomiony kilkukrotnie i działa kilka jego kopii. Każdy proces ma też przydzieloną pamięć, w której trzymane są dane wykorzystywane przez program. Każdemu procesowi przydzielany jest również czas procesora. Ponieważ w danej chwili uruchomionych jest wiele procesów, procesor musi się szybko między nimi przełączać, poświęcając ułamek czasu na wykonywanie kodu każdego z nich. Jak duży jest ten ułamek, decyduje system operacyjny na podstawie czynności wykonywanej w danej chwili przez proces (oczekiwanie na dane użytkownika, przeprowadzanie obliczeń itd). Użytkownik może wpływać na przydział czasu ustawiając priorytety dla procesów.

Procesy pod Windows mogą wyświetlać okna, z większością programów pracujemy właśnie w ten sposób. Programy działające jako usługi nie wyświetlają z reguły żadnych okien. Są też programy konsolowe, przeznaczone do uruchamiania z wiersza polecenia (cmd.exe). Działają one w trybie tekstowym i korzystają z konsoli (wiersza polecenia) do komunikacji z użytkownikiem. Należy uruchamiać je właśnie z konsoli, a nie przez dwukrotne kliknięcie na pliku .exe albo przez okienko Uruchamianie, które wywołuje się przez Start -> Uruchom. Przykładem takiego programu jest ipconfig, który służy m.in. do wyświetlania konfiguracji interfejsów sieciowych. Gdy zostanie uruchomiony bez żadnych parametrów, wyświetla konfigurację i kończy pracę. Dlatego nie ma sensu uruchamiać go inaczej jak z wiersza polecenia, np. przez Start -> Uruchom, bo wtedy program tylko mignie na chwilę.

Z uruchamianiem procesów mamy do czynienia bardzo często, dzieje się to za każdym razem gdy uruchamiamy jakiś program, np. ze skrótu albo klikając plik exe. Do uruchomienia procesu (programu) możemy też wykorzystać wiersz polecenia (konsolę) i okienko Uruchamianie. Przy uruchamianiu procesu można określić jego priorytet oraz parametr, który zostanie do niego przekazany. Ustawianie priorytetu dostępne jest tylko z konsoli. Można wykorzystać tutaj polecenie start:

start /LOW calc.exe

Spowoduje ono uruchomienie programu Kalkulator z priorytetem niskim. Parametr także można przekazywać z konsoli:

notepad.exe C:\plik.txt

Polecenie to spowoduje, że Notatnik zostanie uruchomiony z parametrem C:\plik.txt. Notatnik traktuje otrzymany parametr jako ścieżkę do pliku, który ma otworzyć. Jeśli więc ten plik istnieje, to zostanie otworzony przez Notatnik. Działają tak praktycznie wszystkie programy, które otwierają jakieś pliki. Gdy klikamy na jakiś plik, z którym skojarzony jest jakiś program, to ścieżka do tego pliku zostanie przekazana do uruchamianego procesu. Parametr można przekazywać też przez skrót. Jeśli zrobimy skrót do pliku exe, to możemy potem otworzyć jego właściwości i w polu Element docelowy dopisać dowolny parametr. Pewną formą przekazania parametru jest też przeciągnięcie ikonki dowolnego pliku na ikonkę pliku exe. Wtedy ten plik .exe zostanie uruchomiony a jako parametr otrzyma ścieżkę do przeciąganego pliku. Parametry można też wpisywać w okienku Uruchamianie.

Uwaga, krótkie przypomnienie zasad pracy z konsolą:
1. Ścieżki zawierające spacje muszą być w cudzysłowie, np.

"C:\Program Files\Internet Explorer\iexplore.exe" http://www.google.pl/

2. Jeśli chcemy uruchomić program, który nie leży w katalogu bieżącym, ani w żadnym z wymienionych w zmiennej PATH, musimy podać pełną ścieżkę do niego.
3. Przy pracy z programem start trzeba pamiętać, że tekst ujęty w cudzysłowy może zostać potraktowany jako parametr oznaczający tytuł okna. Dlatego trzeba użyć dodatkowego cudzysłowu, np.

start "" "C:\Program Files\Internet Explorer\iexplore.exe"

Oczywiście proces może być uruchomiony także przez inny proces. I de facto praktycznie zawsze tak jest, bo jeśli nawet uruchamiamy coś ręcznie, to i tak dany proces jest uruchamiany przez narzędzie, którego użyliśmy, zwykle będzie to powłoka systemowa (explorer.exe) w przypadku klikania albo konsola (cmd.exe).

Po omówieniu uruchamiania procesów, trzeba też wspomnieć o ich zakańczaniu. W przypadku programów okienkowych możemy zamknąć główne okno programu albo skorzystać z menu. Proces zostaje wtedy o tym powiadomiony i wykonuje procedurę kończącą jego działanie. W przypadku programów konsolowych można zazwyczaj wcisnąć Ctrl+C, a jeśli program posiada np. linię komend, wpisać odpowiednie polecenie. Co jednak zrobić, jeśli program nie daje się normalnie zamknąć? Wtedy pozostaje zabicie procesu. Zwykle wykonujemy je z Menedżera zadań, wybierając proces i klikając przycisk Zakończ proces. Sam menedżer zadań można włączyć na kilka sposobów. Można wcisnąć Ctrl+Alt+Del i wybrać uruchomienie menedżera zadań. Jest to sposób popularny, ale można go przyspieszyć, wciskając Ctrl+Shift+Esc, wtedy Menedżer zadań zostanie uruchomiony od razu. Można także kliknąć prawym przyciskiem myszy na pasku zadań i wybrać Uruchom Menedżera zadań. A jak zabić proces z konsoli? Służy do tego polecenie taskkill. Może ono zabijać procesy po identyfikatorze albo po nazwie pliku .exe. W tym pierwszy przypadku używamy przełącznika /PID, w drugim /IM, np.

taskkill /pid 1234
taskkill /im notepad.exe

Polecenie taskkill ma też możliwość filtrowania po parametrach takich jak np. nazwa okna, zużycie pamięci czy numer sesji.

Najpopularniejszą alternatywą dla systemowego Menedżera zadań jest program Process Explorer. Dostarcza on wielu szczegółowych informacji na temat działających procesów. Można np. sprawdzić, przez jaki proces został uruchomiony dany proces, i z jakim parametrem. Można wyświetlić też listę załadowanych bibliotek lub uchwytów do plików, kluczy rejestru czy zdarzeń. Uchwyty te można zamykać, co czasem może być pomocne, np. gdy jakiś program trzyma otwarty plik, który chcemy skasować. Jeśli znamy nazwę pliku, ale nie znamy procesu, który go trzyma, możemy wyszukać go klikając na ikonkę lornetki. Przełączanie między widokiem bibliotek a uchwytów wykonuje się przez menu View -> Lower Pane View. Ciekawą funkcją Process Explorera jest możliwość wstrzymywania wątków, dzięki której można zatrzymać działanie programu. We właściwościach danego procesu trzeba przejść do zakładki Threads. Po wybraniu wątku można go zatrzymać klikając na Suspend. Można też go zabić klikając na Kill. Jeśli program jest jednowątkowy, wstrzymanie wątku spowoduje zamrożenie całej aplikacji. W przypadku programu wielowątkowego, wyłączone zostaną funkcje realizowane przez ten wątek.

W przypadku konsoli listę procesów można wyświetlić poleceniem tasklist. Jeśli potrzebne byłoby bardziej zaawansowane narzędzie, np. pokazujące pełne ścieżki do plików exe, można wykorzystać WMI. Służy do tego polecenie wmic, za pomocą którego możemy wyświetlić właściwości obiektów klasy Win32_Process. Przykładowo:

wmic path win32_process get Processid,ParentProcessId,CommandLine

Polecenie to wyświetli listę identyfikatorów procesów, ich procesów-rodziców, oraz ścieżkę z parametrami. Jeśli dla niektórych procesów nie będą widoczne dane takie jak ścieżka, wówczas wiersz polecenia trzeba najpierw uruchomić z uprawnieniami administracyjnymi i dopiero potem wydać w nim komendę wmic. Jeśli wynik komendy będzie nieczytelny przez zawijające się długie linijki, wyjście komendy można przekierować do pliku:

wmic path win32_process get Processid,ParentProcessId,CommandLine > procesy.txt
start procesy.txt

Szczegółowe informacje na temat poleceń start, tasklist i taskkill można znaleźć w pomocy do Windows oraz uruchamiając je z parametrem /? (np. start /?).