2017 achievements

This is a usual time of the year for summaries so let’s keep the tradition alive and write one. Here’s my 2017 achievements split between months. January Blogging for 18 days straight – nothing near gutek’s achievement (whole year!) but still a nice streak Microsoft MVP title (thx Konrad Kokosa for pointing this one ;)) February […]

Paweł Łukasik / December 29, 2017 / 3 Comments
Advent of Code 2017 – solutions

“Advent of Code is a series of small programming puzzles for a variety of skill levels.” Each day was a fun an interesting coding challenge. I’ve decided to practice and code this in python to learn the skill. Some of them might not be the best python scripting as I was short on time in […]

Paweł Łukasik / December 28, 2017 / No Comments
.net developer days 2017 review & interview

Some time ago I’ve attended a .net developer days 2017 conference. I was quite busy since (traveling, teaching .net, working) that only now I got some time to share some thoughts about it. As a bonus I’m including a short interview I did during the event. I need to state here, just to be clear, […]

Paweł Łukasik / November 2, 2017 / 1 Comment
RTFD – Read The F* Documentation

We developers don’t like documentation. We don’t like to read it, and we even more we don’t like to write it. But sometimes it is worth to read it. Like when you find out that by using datetime in SQL DB you got a milliseconds precision but only if it ends on 0,3,7 (link). That […]

Paweł Łukasik / October 9, 2017 / 6 Comments
Fighting technical debt with NDepend – part2

In the previous post we’ve removed some of the technical debt that could be found in our NetDeveloperPoland Website application. In this one we will remove it even more. We can even maybe reach a B? Let’s see where we’ll end up at the end of this part.

Paweł Łukasik / July 25, 2017 / 1 Comment

Paweł Łukasik / September 27, 2008 / No Comments

Sposób na wykrycie debugger’a – C#-way

W jednym z ostatnich postów (Jeśli nie chcesz zarobić na swoim programie…) jako jeden z punktów umieściłem niewykrywanie debuggera. Noe dobrze, łatwo napisać, ale jak tak na prawdę można wykryć, że ktoś podgląda nasz kod w C#?? Jest kilka metod:

Debugger.IsAttached

Pierwszą metodę udostępnia nam sam framework. W namespace’ie System.Diagnostic jest klasa Debugger. Wystarczy, że napiszemy:

Debugger.IsAttached

Niestety wraz z prostotą tego rozwiązania przychodzi także jej ograniczenie. Wykryjemy nią (chyba) tylko uruchomienia programu pod Debuggerem VS.

API – IsDebuggerPresent()

W bibliotece Kernel32.dll możemy odnaleźć coś więcej. Wystarczy więc przy użyciu P/Invoke’a dodać definicję tej metody do naszego kodu. Zrobić to możemy tak:

[DllImport(“Kernel32.dll”)]

public static extern bool IsDebuggerPresent();

Metoda wykrywa WinDbg ale nie wykrywa debugger’a VS (??).

NtQueryInformationProcess

Istnieje jesszcze 3 metoda, wykorzystująca metodę NtQueryInformationProcess. Za jej pomocą możemy uzyskać informacje o procesie, który jest właśnie wykonywany. Jedną z informacji, która się tam znajduje jest wskaźnik na strukturę PEB, w której jest zawarta flaga czy program jest uruchomiony pod kontrolą debuggera. Kod troszkę bardziej używający P/Invoke’a.
Deklaracja niezbędnych struktur:

public enum PROCESSINFOCLASS : int

{

ProcessBasicInformation = 0,

ProcessQuotaLimits,

ProcessIoCounters,

ProcessVmCounters,

ProcessTimes,

ProcessBasePriority,

ProcessRaisePriority,

ProcessDebugPort,

ProcessExceptionPort,

ProcessAccessToken,

ProcessLdtInformation,

ProcessLdtSize,

ProcessDefaultHardErrorMode,

ProcessIoPortHandlers, // Note: this is kernel mode only

ProcessPooledUsageAndLimits,

ProcessWorkingSetWatch,

ProcessUserModeIOPL,

ProcessEnableAlignmentFaultFixup,

ProcessPriorityClass,

ProcessWx86Information,

ProcessHandleCount,

ProcessAffinityMask,

ProcessPriorityBoost,

MaxProcessInfoClass,

ProcessWow64Information = 26

};

[StructLayout(LayoutKind.Sequential)]

public struct PROCESS_BASIC_INFORMATION

{

public long ExitStatus;

public long PebBaseAddress;

public long AffinityMask;

public long BasePriority;

public long UniqueProcessId;

public long InheritedFromUniqueProcessId;

public static int Size

{

get { return (6 * sizeof(long)); }

}

[StructLayout(LayoutKind.Sequential)]

public class _PEB

{

[MarshalAs(UnmanagedType.ByValArray, SizeConst = 2)]

public byte[] Reserved1;

public byte BeingDebugged;

[MarshalAs(UnmanagedType.ByValArray, SizeConst = 1)]

public byte[] Reserved2;

[MarshalAs(UnmanagedType.ByValArray, SizeConst = 2)]

public IntPtr[] Reserved3;

public IntPtr Ldr;

public IntPtr ProcessParameters;

[MarshalAs(UnmanagedType.ByValArray, SizeConst = 104)]

public byte[] Reserved4;

[MarshalAs(UnmanagedType.ByValArray, SizeConst = 52)]

public IntPtr[] Reserved5;

public IntPtr PostProcessInitRoutine;

[MarshalAs(UnmanagedType.ByValArray, SizeConst = 128)]

public byte[] Reserved6;

public IntPtr Reserved7;

public ulong SessionId;

}

public struct _PEB64

{

[MarshalAs(UnmanagedType.ByValArray, SizeConst = 2)]

public byte[] Reserved1;

public byte BeingDebugged;

[MarshalAs(UnmanagedType.ByValArray, SizeConst = 21)]

public byte[] Reserved2;

public IntPtr LoaderData;

public IntPtr ProcessParameters;

[MarshalAs(UnmanagedType.ByValArray, SizeConst = 520)]

public byte[] Reserved3;

public IntPtr PostProcessInitRoutine;

[MarshalAs(UnmanagedType.ByValArray, SizeConst = 136)]

public byte[] Reserved4;

public ulong SessionId;

}

oraz import odpowiedniej metody z Ntdll.dll

[DllImport(“NTDLL.DLL”, SetLastError = true)]

static extern int NtQueryInformationProcess(IntPtr hProcess, PROCESSINFOCLASS pic,

ref PROCESS_BASIC_INFORMATION pbi, int cb, out int pSize);

Pozostaje tylko wywołać to co zaimportowaliśmy:

var pbi = new PROCESS_BASIC_INFORMATION();

int size;

var handle = Process.GetCurrentProcess().Handle;

NtQueryInformationProcess(handle, PROCESSINFOCLASS.ProcessBasicInformation,

ref pbi, PROCESS_BASIC_INFORMATION.Size, out size);

var p64 = (_PEB64) Marshal.PtrToStructure(new IntPtr(pbi.PebBaseAddress),

typeof (_PEB64));

Sprawdzenie to już drobnostka:

p64.BeingDebugged != 0

Oczywiście w przypadku 32-bitów należy użyć struktury _PEB zamiast _PEB32. Jak wykryć system można znaleźć w poście – 32 czy 64-bity? Oto jest pytanie?

.NET, debugger

Paweł Łukasik / September 25, 2008 / No Comments

32 czy 64-bity? Oto jest pytanie?

Przy okazji przygotowywania sobie materiałów do kolejnego postu natrafiłem na program, który wymagał ode mnie uzyskania
informacji ilo-bitowy mamy procesor oraz czy uruchamiany kod jest na systemie 32 czy 64-bitowym.
Rozpocząłem poszukiwania i ten post jest ich wynikiem?

Procesor

Zmienne systemowa

Po uruchomieniu polecenia SET w konsoli naszym oczom ukazuje lista zmiennych systemowych a wsród nich widnieje PROCESSOR_ARCHITECTURE.

Tak więc pierwszą i najgorszą metodą jest wywołanie poniższego kodu:

public static bool Is64Bit

{

get

{

return Environment.GetEnvironmentVariable(“Processor_Architecture”)

== “AMD64”;

}

Tak jak napisałem jest to najgorsza metoda z racji, iż zmienna taka może zostać zmieniona na cokolwiek (także z uwagi na to, że wartość ta jest pewnie różna w zależności od procesora – a może nie??)

WMI

Kiedyś pisałem o możliwościach WMI i o tym jak wiele się tam informacji znajduje (WMI Wokół masz informacje). Nie inaczej jest z informacją o procesorze. Wystarczy, że uruchomimy poniższy kod.

public static bool Is64Bits

{

get

{

var query = new WqlObjectQuery(“select * from Win32_Processor”);

var searcher = new ManagementObjectSearcher(query);

foreach (var elem in searcher.Get())

{

var addressWidth =

Convert.ToInt32(elem.GetPropertyValue(“AddressWidth”));

return 64 == addressWidth;

}

return false;

}

The best & simplest way

Jednakże jest trzecie (w sumie możliwe że istnieje więcej) podejście. Wiadomo (a może nie), że w 64bitach przestrzeń adresowa jest rozszerzona do 8 bajtów (z 4 w 32bitach). Zatem jeżeli udałoby się sprawdzić rozmiar wskaźnika na pamięc i jeśli wynosiłby on 8 bajtów oznaczałoby to, że mamy 64bity. I jak się okazuje takie sprawdzenie jest dziecinnie proste.

public static bool Is64Bits

{

get

{

return IntPtr.Size == 8;

}

I to wszystko. Prosty warunek i gotowe.

System operacyjny

Niestety tu tylko jak na razie znam tylko metodę za pomocą WMI:

public static bool Is64OS

{

get

{

var query = new WqlObjectQuery(“select * from Win32_OperatingSystem”);

var searcher = new ManagementObjectSearcher(query);

foreach (var elem in searcher.Get())

{

var osArchitecture =

elem.GetPropertyValue(“OSArchitecture”);

return “64-bit”.CompareTo(osArchitecture) == 0;

}

return false;

}

Jeśli ktoś zna jeszcze inne metody, zachęcam do pozostawienia komentarza.

.NET, 32-bit, 64-bit, WMI

Paweł Łukasik / September 23, 2008 / No Comments

Jeśli nie chcesz zarobić na swoim programie…

…wystarczy, że zastosujesz się do rad przedstawionych poniżej. Każda z nich w sposób istotny zmniejszy odporność twojego programu na złamanie.

Tak więc wracając do tematu tego posta, jeśli nie chcesz zarabiać na swoim programie wystarczy, że:

będziesz używał wyskakujących okienek informujących o poprawnym zarejestrowaniu programu

będziesz stosował proste porównanie wprowadzonego przez użytkownika hasła z czymś zaszytym wewnątrz aplikacji – przecież jakieś przekształcenia hasła są dla mięczaków

użyjesz standardowej metody przekształcenia hasła. Przecież użyty po raz 99 XOR czy zamiana ASCII na liczby jest silniejszy niż w pozostałych 99 przypadkach

twoje hasła będą liczyć maksymalnie 5 znaków

jedno i to samo hasło będzie odblokowywać aplikację na wielu różnych komputerach

użyjesz kontrolki MaskedTextbox do wprowadzenia hasła dzięki temu pokazując jak powinno wyglądać poprawne hasło oraz jakie znaki powinno zawierać

poinformujesz wszem i wobec jak wygląda techniczna strona informacji – najlepiej w helpie programu, aby atakujący nie musiał daleko szukać

utworzysz wersje demo zawierające pełną funkcjonalność a tylko przycisk ją uruchamiający twórz nieaktywny

pozostawisz nieobfuskowany kod (dotyczy programów w kodzie zarządzalnym)

dostarczysz dll’ki bez StrongName (w .NET)

kod sprawdzający poprawność wprowadzonego hasła umieścisz tylko w jednym miejscu w kodzie i wywołasz go tylko jeden jedyny raz – Gdy użytkownik naciśnie ‘Zarejestruj’

w okienku zarejestruj przepuścisz tylko ten ‘jeden’ właściwy klucz, po cóż dawać złudne wrażenie poprawnej rejestracji

pozwolisz uruchamiać swoją aplikację pod kontrolą debuggerów – przecież to jest to co zwykli użytkownicy robią codziennie

napiszesz metodę sprawdzającą tak, aby wszystko zależało od jednej instrukcji “if”

napisanie zabezpieczenia zostawisz na koniec. Przecież napisanie dobrego zabezpieczenia to nie więcej jak dzień pracy

zastosujesz standardowe okienko wprowadzania użytkownika i hasła, to przecież takie wygodne dla atakującego

użyjesz jednej z poniższych nazw lub ich kombinacji do nazwania pliku lub rejestru, gdzie przechowasz informację o zarejestrowaniu aplikacji: key, reg, register, password, registered itd.

będziesz udawał, że problem Cię nie dotyczy. Przecież jeśli nie wiemy, że ktoś złamał nam program to nie jest nam żal

będziesz przechwalał się jakie to twoje zabezpieczenie nie jest idealne. Przykład firmy Oracle pokazuje, że taka jest najlepsza praktyka

A czy ty drogi Czytelniku znasz jeszcze jakiś sposób aby skutecznie zrujnować sobie sprzedaż własnego dzieła? Zachęcam do pozostawienia komentarza.

bezpieczeństwo, IT, security

Paweł Łukasik / September 13, 2008 / No Comments

SonyEricsson Xperia X1 i SDK

W dzisiejszych czasach telefon to już coś więcej niż tylko ‘zamknięte’ urządzenie do dzwonienia i sms-owania. Dziś telefon to komputer, który podobnie jak ich duże odpowiedniki możemy oprogramować, tak aby maksymalnie wykorzystać jego możliwości. Jako, że zbierałem się na wymianę telefonu, a od jakiegoś już czasu jestem wiernym użytkownikiem marki Sony Ericsson, z radością przeczytałem, iż ma pojawić się Xperia X1.

Najnowsze dziecko będzie oparte o Windows Mobile w wersji 6.1. Z racji tego do oprogramowania jej będzie można użyć Visual Studio i C++ i większości znanych nam z ‘dużego’ świata rzeczy – środowisko Mophun znane z poprzednich wersji telefonów Sony Ericsson (chyba) pójdzie w odstawkę. Telefon ma pojawić się już niedługo (zapowiadana premiera w UK, Niemczech i Szwecji to 30.09 – za pdaclub.pl – Xperia X1 na rynku z końcem miesiąca) a już dziś można pobrać wersję Beta SDK dla Xperii X1. SDK zawiera w sobie niewiele (w sumie chyba 2) przykładów i dokumentację co będzie można z tego urządzenia wycisnąć. Dokumenty także nie liczą zbyt wiele stron – góra kilkanaście, ale mam nadzieję, że w wersji finalnej to się poprawi.

Elementy, które będzie można programować to tzw. Panele. Xperia X1 wprowadzi dwa rodzaje Paneli – Native oraz HTML (oba typy są zaprezentowane jako przykłady). Ten pierwszy zapewni lepszą kontrolę nad wynikiem jaki chcemy uzyskać. Drugi pozwoli na zabawę z telefonem także tym, który posiadają tylko wiedzę z zakresu HTML’a (lub nawet jej brak – ciekawe jak telefon będzie sobie radził z HTML’em, który jest wygenerowany przez jakieś wysokopoziomowe narzędzie). Oczywiście za pomocą Native Panelu będziemy osiągnąć znacznie więcej. Ciekawe jednak jak będzie się różnić wydajność w przypadku podobnych programów wykorzystujących HTML i Native. Biblioteka, która będzie obsługiwać te Panele napisana jest w C++, ciekawe czy z odrobiną chęci i P/Invoke’a uda się napisać jej C#-owy odpowiednik.

Trochę więcej informacji można przeczytać na: Notatka dla prasy.
SDK do ściągnięcia ze stron Developer World Sony Ericssona.

UPDATE: Po zapoznaniu się z całą specyfikacją tego telefonu nie wiem czy pozostanę wierny marce SE – dużo ciekawych modeli pojawiło się ostatnio 🙂

SDK, telefon, Xperia X1

Paweł Łukasik / August 19, 2008 / No Comments

Jest tu jakiś cwaniak? Czyli zlecenia.przez.net wyciągają piątaka.

Dziś przeglądając sobie oferty na zlecenia.przez.net pod kątem czegoś ciekawego natrafiłem na coś nowego czego wcześniej nie widziałem. Otóż przy niektórych użytkownikach pojawiły się żółte kółka (notabene jak pierwszy raz je zobaczyłem to bardziej mi to wyglądało na coś takiego widziane z góry :)) . Po dokładniejszej inwestygacji dowiedziałem się, iż oznaczają one fakt zweryfikowania konta na portalu zlecenia.przez.net. Dobra rzecz można by pomyśleć gdyby nie fakt na czym polega ów weryfikacja.

Aby otrzymać status użytkownika zweryfikowanego należy wykonać następujący przelew z własnego rachunku bankowego: …

Przelew na kwotę 5 złotych :). Od razu na myśl przyszedł mi cytat z “Chłopaki na płaczą”. Leciał on jakoś tak.

– Mieszka tu jakiś cwaniak?
– Cwaniak? Nie, ja tu mieszkam.
– To daj piątaka.
– To jest jakaś zorganizowana akcja?
– … Taka akcja, żebyś dał piątaka.

Jednym słowem serwis chyba chce dorobić sobie :). Niby dzięki temu będzie można zweryfikować, że użytkownik to faktycznie ta osoba za którą się podaje, ale jakoś nie przypadł mi do gustu sposób w jaki to ma zostać osiągnięte. Raczej lepiej, aby weryfikację przeprowadzali użytkownicy, który skorzystali z usług danej osoby (co jest dostępne choć moim zdaniem, trochę kulawo, ale mniejsza z tym…), bo dużo pozytywnych komentarzy bardziej motywuje do dalszego dobrego działania niż 5 zł, które przecież to nie wielki majątek, odżałować można. Nie wiem jak się na to zapatrywać, skoro taka osoba, którą odżałuje sobie 5 zł skorzysta na tym, bo

licytacje użytkowników zweryfikowanych będą wyświetlane przed licytacjami użytkowników niezweryfikowanych (w obrębie danej aukcji).

Nic…pozostaje chyba tylko wierzyć, że ktoś zweryfikowany z zerem komentarzy nie będzie postrzegany jako lepszy kontrahent niż niezweryfikowany user z 20 pozytywnymi komentarzami…

IT, zlecenia.przez.net

Paweł Łukasik / August 1, 2008 / No Comments

VisualStudio wariuje :)

Dziś Visual Studio sprawia niezłe problemy :). Dosłownie przed chwilą zamiast części Namespace’ów, IntelliSence podpowiadał mi coś takiego 🙂

Może VS zaczęło posługiwać się hieroglifami a może mój kod był automatycznie obfucowany w locie? 🙂 Tak czy tak wyglądało to ciekawie 🙂

humor, Visual Studio

Paweł Łukasik / August 1, 2008 / No Comments

[DebuggerStepThrough]

Ten malutki atrybut pomoże wam, gdy będziecie mieli sporo kodu, który trzeba prześledzić krok po kroku pod debuggerem. Nakazuje on debuggerowi ominięciem oznaczonych metod gdy używamy F11 (Step-Through).
Używa się go bajecznie prosto – jak zresztą każdego atrybutu. Wystarczy oznaczyć metodę tym atrybutem i gotowe.

[DebuggerStepThrough]

public string MethodHideFromStepThrough()

{

}

Oczywiście użycie tego atrybutu ma sens, gdy będziemy mieli sporo tego typu kodu:

var code = GetAction().Execute();

i interesuje nas tylko dowiedzenie się co dzieje się w metodzie Execute, gdyż GetAction jest prostym switch’em zwracającym odpowiedni obiekt i wiemy, że działa ona poprawnie. Jeśli użyjemy tego atrybutu – F11 przeniesie nas od razu do Execute.

Co ciekawe możliwe jest użyte tego atrybutu na właściwościach, choć trochę w inny sposób. Zamiast atrybutować całe property musimy oatrybutować osobno getter i setter.

public string FlagName

{

[DebuggerStepThrough]

get { return this.flagName; }

[DebuggerStepThrough]

set { this.flagName = value;}

}

Oczywiście możemy użyć tego atrybutu tylko na getterze, gdyż możemy mieć coś co chcemy prześledzić podczas podstawiania wartości. Oczywiście jeżeli masze property nie robi nic prócz ustawiania/odczytu wartości to warto zamienić je na AutoProperty – uzyskamy ten sam efekt. Dzięki użyciu tego atrybutu możemy zaoszczędzić sobie czasu, który musimy poświęcić na klikanie F11, CTRL-F11 podczas śledzenia dużego kawałka kodu. Zachęcam także do przyglądnięcia się System.Diagnostics – jest tam jeszcze kilka ciekawych klas.

.NET, Visual Studio

Paweł Łukasik / June 30, 2008 / No Comments

Ukryte możliwości FindBox’a

Ostatnio w pracy zauważyłem, ze moi koledzy używają FindBox’a w sposób dotychczas mi nie znany na dosyć przydatny. Używają go mianowicie jako consolę, w którą wpisują polecenia i które wspiera Intellisense.

Tak, tak to małe okienko zlokalizowane u góry VS każdego z nas potrafi dopomóc w potrzebie 🙂
Gdy zaczniemy nasze polecenie od znaku ‘>’ będziemy mogli skorzystać z dodatkowych funkcji, które dość dobrze opisuje ten dokument http://msdn.microsoft.com/en-us/library/c3a0kd3x(VS.80).aspx
Ja od tego czasu namiętnie korzystam z >open, gdyż w ten sposób w dużym projekcie nie muszę przechodzić po katalogach szukając jakiegoś pliku. Wystarczy, że wpiszę nawet część nazwy pliku a Intellisense podpowie resztę. W dużych projektach jest to nieoceniona pomoc 🙂

Visual Studio

Paweł Łukasik / June 30, 2008 / No Comments

Piosenka o smutnym programiście

Ten post tylko trochę nawiązuje do głównej treści tego bloga. Ostatnio mój kolega Grzesiek pokazał mi interesującą piosenkę o smutnym programiście .NET :). Zachęcam do posłuchania.

Ja osobiście podchodzę z humorem do niej, choć w wypowiedziach na forum można przeczytać różnego rodzaju wypowiedzi od totelnego, podobnego do mojego, luzackiego podejścia do irytacji i oburzenia.
Nie widzę nic złego będąc programistą w .NET. Wręcz przeciwnie – cieszę się, że nim jestem a i wolę to od łopaty 🙂 (bez urazy dla wszystkich machających łopatą :)).

Link do źródła: http://completelyunprofessional.com/?p=song&song=9&cat=4. Na stronie można znaleźć jeszcze więcej ciekawych piosenek, ale chyba tylko jedna jak na razie o programicie .NET :).

humor

Paweł Łukasik / June 9, 2008 / No Comments

codecamp.pl – Wspomnienia

Z racji dość dużego udziału w przygotowaniach do konferencji powstrzymam od komentowania jak było, gdyż mogę nie być obiektywny :).

Dla mnie konferencja ta to był czas i miejsce do nawiązania kontaktów z nowymi osobami ze “światka .NET” :). Czasu na oglądanie sesji i tak nie było (a przynajmniej nie w całości), ale był czas na rozmowy i na poznawanie nowych osób. Sądzę, że czas ten dobrze został dobrze spożytkowany…:)

Na koniec kilka fotek z codecamp.pl. To tylko na przedsmak. Już niedługo powinna pojawić się ich więcej na stronie wydarzenia.

– Chris opowiada do tworzeniu community..

– Marta świetnie radziła sobie przy rejestracji…

– tak samo jak Piotr z prowadzeniem konferencji…

– a sala słuchała uważnie 🙂

codecamp.pl