Pisząc jakieś shellkody lub inne tego typu paskudztwa napotyka się na problem interakcji z systemem lub jego API. Aby cokolwiek zrobić sensownego wymagany jest dostęp do kilku kluczowych funkcji znajdujących się w kernel32.dll, będących niejako kluczem do świata systemu. Takimi funkcjami są oczywiście LoadLibrary/GetModuleHandle, GetProcAddress, itp… Mając dostęp do tych funkcji możemy zrobić praktycznie wszystko i wykorzystać dowolny kod z innych modułów.
Nawet jeśli chce się wstrzyknąć tylko dll-kę importującą niezbędne i używane przez siebie rzeczy, to wymagany jest jakiś sensowny kod loadera, który także musi zostać wstrzyknięty do procesu.
Nigdy nie zajmowałem się szczególnie tematyką security, nie interesowało mnie pisanie czy zabawa z shellcode-ami czy exploit-ami. Za to często zdarzają mi się różne eksperymenty, które w wielu przypadkach są dobrym sposobem na poznanie nowych rzeczy. A także pomagają ugruntować swoją wiedzę i przekonania. Bo pomimo, że wiem co i jak w teorii oraz praktyce, to często nie miałem jeszcze okazji tego dotknąć i poczuć. Dotyczy to nie tylko programowania, inżynierii wstecznej czy elektroniki, ale szeroko pojętej techniki (i w zasadzie nie tylko)…
Zawsze, gdy nie udaje mi się szybko (w kilka minut) osiągnąć spodziewanego efektu przy wizualizacji za pomocą wykresów w Excelu, przeskakuję na gnuplot-a i od razu świat wydaje się być lepszym miejscem. Nie trzeba się denerwować ograniczeniami w dostosowywaniu wyglądu jaki i możliwości. Wystarczy kilka linijek kodu (skryptu) i można wyrenderować dokładnie taki wykres jaki chcemy…
Gnuplot-a używałem z powodzeniem wiele razy w przeszłości, przy różnego rodzaju publikacjach, dokumentach czy pracach i zawsze byłem zadowolony z osiągniętych wyników.
Tematyka odzysku i wykorzystania różnych (głównie Li-Ion) ogniw ze starych baterii różnorakiego pochodzenia, choć często właśnie z laptopów i tym podobnego sprzętu przenośnego, nie jest niczym nowym. Od dawna jest dosyć popularna. Swego czasu sam się do tego długo zabierałem. Posiadając kilka niepotrzebnych baterii pozostałych po starszych sprzętach, starałem się znaleźć czas, aby je przejrzeć, zbadać i odzyskać choć kilka ogniw. Które będę mógł wykorzystać jako napęd do typowego power banka, czy innego źródła zasilania.
Potrzebowałem na szybko oszacować złożoność czasową kilku algorytmów na mikrokontrolerze AVR, aby poznać ilość cykli jakie skonsumuje procesor do wykonania tych interesujących mnie fragmentów kodu. Ponoć symulator posiada taką funkcjonalność, ja niestety nie mam takich zabawek. Można byłoby na piechotę policzyć ilość taktów na podstawie dokumentacji i wygenerowanego kodu, ale to raczej byłoby karkołomnym zadaniem.
Lepiej wykorzystać do tego sam mikrokontroler i liczyć na żywo ilość przeoranych taktów procesora. Do tego celu najlepiej użyć licznika napędzanego systemowym zegarem.
Naszła mnie mała ochota na podzielnie się kilkoma uwagami (typowe marudzenie) w kontekście sterowania multipleksowego wyświetlaczy LED. Jest kilka rzeczy jakie mi się nie podobają, przeszkadzają lub są często powtarzane na forach, czy też powielane w różnych projektach.
Na początek warto wspomnieć o fakcie, że mimo upływu lat, prócz popularnych ciekłokrystalicznych wyświetlaczy alfanumerycznych LCD (obecnie często zastępowane przez graficzne/kolorowe LCD/LED/OLED), 7-segmentowe LED-y są często wykorzystywane w różnych układach mikroprocesorowych i nie tylko.
Przeglądając (w przeszłości) różne projekty krótkofalowców i radioamatorów, często w roli urządzenia wyjściowego audio, zamiast słuchawek, wykorzystywany był zewnętrzny wzmacniacz z głośniczkiem znanej (niegdyś kultowej, a obecnie bankrutującej) firmy RadioShack: Mini Audio Amplifier. Mały i poręczny, a do tego prosty, idealnie sprawdzał się w tej roli.
[gallery columns=“2” size=“medium”] Tak bardzo mi się spodobał, że sam zapragnąłem go zdobyć. Niestety wzmacniacz od dawna nie był już produkowany ani sprzedawany oficjalnymi kanałami dystrybucji~~, ale chyba wciąż jest dostępny w lokalnych sklepach w Stanach.
Przełamałem noworoczny marazm motywacyjno-produktywny, który ciągnął się od czasu ostatniego wpisu. O ile w pracy nie ma problemów, to po powrocie do domu, do swoich obowiązków, projektów i planów, niestety ciągle brak motywacji oraz siły i ochoty do robienia czegokolwiek ciekawego. Ale ostatecznie, po kilku zmarnowanych wieczorach udało mi się wrócić na właściwe tory, do działania.
A do działania popchnęło mnie kilka losowych notatek Gynvaela o próbach przywracenia swojego Atari do życia.
Mija trzeci~~ piąty dzień nowego roku, trzeba znów się przyzwyczaić do nowej daty, aby przypadkiem nie wpisać gdzieś 16-tki zamiast 17-tki. Ale to i tak chyba najmniejszy problem, bo za dużo to nie ma się okazji do posługiwania się tekstem pisanym. To już nie lata szkolne ;)
Tym razem nie będzie żadnych podsumowań i planów oraz tego typu shitów. Nie chce mi się przygotowywać jakieś listy rzeczy zrobionych i tych nie do końca wykonanych.
Kilka miesięcy temu trafiłem na intrygujący problem z obsługą ścieżek w systemie Windows. Jak się okazało odkrycie to jest dobrze znane w środowisku deweloperów blisko związanych z bebechami tego systemu, ludziom zajmującym się inżynierią wsteczną, bezpieczeństwem i różnym badaczom… Można powiedzieć, że tak naprawdę to nic nadzwyczajnego, dlatego aż dziwne, że wcześniej nie trafiłem na coś podobnego, można wręcz powiedzieć zadziwiającego.
Te dziwne zachowanie (o jakim piszę) to nigdzie nie udokumentowane ignorowanie (usuwanie) znaku spacji i kropki na końcach poszczególnych elementów ścieżki.