piatok 25. decembra 2015

Android CrackeMe

Toto bude netradičný článok. Osobne sa pohybujem v android vývoji už určitý čas a začal som sa zaujímať o to, ako funguje ochrana aplikácií na tejto platforme. Pár aplikácii som si pre zvedavosť crackol, ale nepoužívam ich a ani nedistribuujem ďalej. Vysvetľovať to, ako som postupoval na takejto aplikácií nie je dobré a ani férové voči vývojárovi, je to nelegálne. Preto som si vybral na to špecialne určenú aplikáciu CrackMe, ktorá bolá napísaná vývojárom ako challenge pre tých, čo sa radi vŕtajú v aplikáciách a zisťujú ako fungujú, teda ovládajú taje umenia reverzného umenia.

Na naše účely poslúži aplikácia od Deurus užívateľa, ktorý napísal viacej druhov crackme pre rôzne platformy, link Dereus. Užívateľ ako požaduje vo výzve vytvorenie generátora sériových čísel alebo patchovanie aplikácie. Prikladám odkaz na súbor, na ktorom vysvetlím postup, treba sa registrovať a stiahnúť: CrackMe04. Toto opisujem ako moje zmýšľanie pri riešení tohto crackme.

Ako nástroje som použil:
  1. notepad++  so svýraznovačom syntaxe (link na zvýraznovač syntax highlight)
  2. apktool, ktorý slúži na reverzne inžinierstvo súborov apk, link Apktool 
  3. decompilér JEB, použil som demo verziu.
Ako prvé som nahral aplikáciu do mobilu (pri malware radšej do virtuálneho stroja AVD). Pozrel som ako vyzerá, zistil som, že má tri obrazovky (Activity). Samotné apk som prešiel cez apktool:

java -jar apktool d AndroidCrackme.apk -o CrackMe

 Pozrel som si verziu a VersionName aplikácie (netradičné hodnoty). Pozrel som si certifikát:

keytool.exe -printcert -jarfile AndroidCrackme04.apk

Obr.1 Certifikát aplikácie
Otvoril som manifest a pozrel som štruktúru aplikácie. Jeden vstupný bod do aplikácie je súbor Splash a niekoľko povolení ako čítanie pamäťovej karty, stav WIFI, Bluetooth.


Obr.2 Manifest.xml aplikácie

Pozrel som na štruktúru adresárov a súborov. V zdrojových súboroch som v adresári Raw našiel zvukové súbory. Pozrel som ešte layouty ako vyzerajú. Z názvov súborov je jasné, že je použitá obfukácia kódu.  Dal som si vypísať reťazce vo všetkých smali súboroch:

findstr /i /n "const-string" *.smali

Z výpisu som nemohol nič užitočné vyčítať. Otvoril som si teda súbor Splash.smali v notepad++.  Keďže je to aktvita (Activity), tak vstupným bodom do nej je metóda onCreate, ale hľadal som aj onResume a onStart (tie sa ale v tomto súbore nenachádzajú). V metóde onCreate vloží do premenných b="classes.dex" (súbor nachádzajúci sa v AndroidCrackme04.apk, teda dalvik kód celej aplikácie) , c="cr4.dat", d="MD5" (pre použitie hashovania). Potom zavolá metódu a()V, kde kontroluje to, či aplikácia bola upravená. Tam som našiel túto podmienku, ktorú stačí iba zmeniť na opačnú (viď. zakomentovaný kód a pod ním nekomentovaný kód).

Obr.3 Nájdena ochrana

Ok, to je ochrana aplikácie proti zmene v kóde(patchovaniu). Aktivita Splash nakoniec spustí nový Handle, ktorá bude aktivita CrackMe a seba ukončí. V CrackMe aktivite je znova vstupom, len onCreate metóda. Pozrel som aj ostatné metódy, čo robia ako a(Landroid/content/Context;)Ljava/lang/String;  vráti VersionName
b(Landroid/content/Context;)I vráti Verziu aplikácie. Znova metóda  d()V, kde je ochrana proti patchovaniu aplikácie, na konci som upravil podmienku tak, aby prešla opatchovaná aplikácia. Metóda a()Ljava/lang/String;  číta CID karty, teda jej ID. Ostatne metódy robili úpravy s údajmi, ktoré dostali ako napr. odstránenie znaku ":" z MAC adresy a pod..
Zameral som sa teda na Metódu onCreate, kde je nakoniec algoritmus na overovanie Mena, Serial kľúča. Neštudoval som ho do detailov. V metóde ale vidím, že aplikácia získava MAC adresu wifi karty, adresu bluetooth karty, ale aj ID SD karty, ktoré spacuváva. Našiel som ale toto viď. obrázok obr.4, porovanie sériového čísla, tak som zmenil podmienku, čo bola kontrola zadaného sériového čísla.
Obr.4 Druhá časť overenia

Nakoniec som uložil zmeny, zabalil aplikáciu znova pomocou apktool:

java -jar apktool.jar b Eset -o AndroidCrackme_TEST.apk

Ešte som podpísal aplikáciu:

jarsigner -verbose -sigalg MD5withRSA -digestalg SHA1 -keystore [moj keystroke]
[AndroidCrackme_TEST.apk] alias_nam

Ohľadom nástroja JEB, nemám licenciu a mohol som použiť len demo, takže niektoré metódy neboli dekompilované, tak som kontroloval a porovnával smali kód s JEB aplikáciu. Ak toto používate, tak máte ľahšiu analýzu,  čo je veľmi dobré, a teda je jednoduchšie robiť analýzu v jave.
Vyjadrenie na záver, aplikácia obsahuje aj prehrávač hudby AndModPlug od Peculiar Games, do projektu sa dostane v podobe knižnice. Autor tohto cracku vytvoril viacej druhov cracku, ako pre desktopy, tak pre android.



sobota 19. septembra 2015

Keď niečo nefunguje v SharePointe - Get-SPLogEvent

Utilita Get-SPLogEvent je užitočná pre SharePoint Administrátorov, ale aj programátorov. Štandardne je zabudovaná v SharePoint-e ako súčasť SharePoint snappin. Slúži na zobrazovanie a vyhľadávanie v diagnostických logoch, čo vytvorí SharePoint. Na jej použitie ju treba zaviesť do PowerShell sessiony ako snappin. Dá sa to dvoma spôsobmi, a to automaticky, keď spustíme z Ponuky Štart>All Programs>Microsoft SharePoint 2013 Products>SharePoint 2013 Management Shell, čo je najjednoduchšia varianta viď. obr.1.
Obr.1 Ponuka Štart pre výber SharePoint 2013 Management Shell

Alebo snappin zavedieme manuálne, ale najprv musíme vedieť, ako máme zaregistrovaný snappin v systéme, na to pomôže riadok v PoweSshell-y, jeho výpis vidieť na obr.2:

get-pssnapping -registered

Obr. 2 get-pssnappin
Po obhliadnutí zaregistrovaných snappinov vidieť, že máme SharePoint snappin pod menom Microsoft.SharePoint.PowerShell  v systéme ho môžme zaviesť do sessionu pomocou cmdletu:

add-spsnappin -name Microsoft.SharePoint.PowerShell

Keďže používam na serveri PowerShell v spojení so SharePoint-om, tak som si pridal do profilu PowerShell-u predchádzajúci cmdlet, aby sa mi zaviedol SharePoint snappin vždy po otvorení PowerShell-u. Po zavedení snappinu môžme používať všetky cmdlety určené pre SharePoint. Nás ale zaujíma Get-SPLogEvent. Samotný cmdlet bez parametrov zobrazí všetky logy. Ok, ale výhoda utility nespočíva v tom, že môžme si zobraziť všetky logy, ale v tom, že môžme filtrovať na základe určitých parametrov v logoch.  Pozrime sa na nápovedu od cmdletu, obr.3.

get-help get-splogevent

alebo skrátená verzia

help get-splogevent

Obr.3 Nápoveda alebo manuálová stránka pre get-splogevent
Vidieť je niekoľko užitočných parametrov ako Directory, EndTime, StartTime, MinimumLevel. Príklady použitia si môžme pozrieť aj v nápovede, aby sme videli len priklady stačí uviesť cmdlet:

help get-splogevent -examples

Výstup príkazu je vidieť na obr.4.
Obr.4 Príklady použitia get-splogevent
Ok, to sú už menšie možnosti filtrovania, ale stále to nie je všetko a ani postačujúce. Čo tak filtrácia na základe Correlation, Category alebo Area, resp. iných v logu obsiahnutých informácií. Tým, že je PowerShell objektovo orientované skriptovacie prostredie, tak máme širšie možnosti práce s údajmi z príslušných cmdlet-ov. Pozrime na členov get-splogevent cez príkaz, viď. obr.5:

get-splogevent | get-members

Obr.5 Členovia cmdlet-u Get-SPLogEvent

Na základe určitého Correlation vieme získať potrebný výstup:

get-splogevent | where-object {$_.Correlation -eq '79012b9d-692f-f014-a228-52715da5e838'}

alebo získať všetky chyby úrovne Critical:

get-splogevent | where {$_.Level -eq 'Critical'}

Čo tak zobraziť ako výstup iba potrebné informácie ako message, category všetkých chýb úrovne critical:

get-splogevent | where {$_.Level -eq 'Critical'} | select-object Message,Category

Môžme kombinovať vlastnosti a vytvárať tak zložitejšie filtre. Za pomoci ďalších cmdlet-ov ako Where-Object, Select-Object, Format-List, Format-Table a ďalších vieme pekne dolovať informácie z logov a následne si ich zobraziť v PowerShell-y. 
SharePoint obsahuje veľké množstvo cmdlet-ov a v priebehu následujúcich článkov ich bližšie predstavím. Koľko ich je a ktoré to sú, si môžme pozrieť pomocou:


get-command -module Microsoft.SharePoint.PowerShell

sobota 15. augusta 2015

Keď niečo nefunguje v SharePointe

Osobne nemám so SharePointom 2013 skúsenosti. V práci som sa podujal ako jediný získať znalosti zo SharePoint-u ako vývojar. Čo to obnáša, som si úplne neuvedomil. Prechod od vývojára mobilných zariadení so systémom Android k platforme SharePoint je obrovský skok. A to musím povedať, že mám skúsenosti aj s platformou Net Framework.
V IT oddelení som požiadal kolegov, aby mi zriadili dedikovaný server na vývoj pre SharePoint 2013, s Windows Server-o. Dali mi prístupy a zvyšok nechali na mňa. Pochopiteľne som im povedal s akými parametrami chcem mať server. Aké požiadavky treba si nájdete na stránkach Technet-u Microsoftu viď. link:
https://technet.microsoft.com/en-us/library/cc262485.aspx .
Po stiahnutí inštalácie SharePoint 2013, som okamžite začal inštalovať. Po inštalácií rýchla obhliadka. Vidím SharePoint beží na dvoch portoch a to 80 a druhý je náhodne vygenerované 5 miestne číslo, kde beží SharePoint Central Administration. Po inštalácií vytvorí odkaz v ponuke Štart na Central Administratin. Pre riešenie niektorých problémov budeme potrebovať práve Central Administration. Po obhliadke som doinštaloval Visual Studio 2013 a mohol som začať kódiť. Po vytvorení jednoduchého projektu následnom deploynutí vytvorenej aplikácie nastala chyba inštalácie, o ktorej som ani s  popisu v SharePoint nič nevedel(SharePoint v chybovej hláške ma odkázal na diagnostické logy). Aké logy, kde uložené? Po kratšiom googlení som zistil, že SharePoint má ULS (Unified Logging Service). Otvoril som si teda Central Administration, obr.1.

Obr.1. Central Administration Main page
V sekcii Monitoring obr.2 som vošiel do "Configure diagnostic logging", obr.2 a obr3.
Obr.2. Monitoring
 
Obr.3. Diagnostic Logging časť1

Obr.4. Diagnosti Logging časť 2

V Diagnostic Logging som zaškrtol všetky možnosti,  aby som vedel, čo sa deje, vyplnil údaje o ceste, kde bude logy ukladať a potvrdil. Pre bližšie info ohľadom  nastavení na obrazovke Diagnostic Logging je dobré si pozrieť web technet microsoftu, viď. link:
https://technet.microsoft.com/en-us/library/ee748656.aspx .
Po konfigurácií logov začne SharePoint automaticky vytvárať logy. Za krátky čas dokáže vytvoriť SharePoint veľké množstvo logov. Na ich prezeranie má ShrarePoint zabudovaný PowerShell nástroj Get-SPLogEvent.  Jednoduchý návod na prácu s nástrojom:

https://technet.microsoft.com/en-us/library/ff463595.aspx .
 Na prezeranie logov v GUI je tu nástroj z produkcie Microsoftu:
http://www.microsoft.com/en-us/download/details.aspx?id=44020 .
Ja osobne som použil nástroj pre GUI na prvotné zoznámenie. Po krátkej prehliadke som zistil, že nemám nakonfigurovanú aplikačnú doménu, pod ktorou bude bežať aplikácia. Ok, znova som použil google na vyhľadanie  riešenia (google je ale pomocník čo?).  V tomto prípade tu mám dva články:
http://sharepointchick.com/archive/0001/01/01/setting-up-your-app-domain-for-sharepoint-2013.aspx  a https://technet.microsoft.com/en-us/library/fp161236.aspx .
V oboch sú informácie, prečo treba App Domain pre aplikácie v SharePointe.
Záverom spomeniem, že ULS môžu využiť vývojári a nemusia vyvíjať vlastné riešenie, ale môžu použiť existujúce. Ako sa to robí, to napíšem nabudúce. Ešte podotknem, že treba byť opatrný pri prezeraní logov, ako cez powershell, tak cez GUI aplikáciu. Ak máte menšiu RAM (ja mám 8 GB), tak spustené služby SharePointu a ďalšie zaberú značnú ram. Po otvorení väčšieho množstva logov v GUI nástroji, môže zahltiť ram a nemusíte sa dopracovať k ničomu. Podobné to je aj pri powershell nástroji. Cez GUI odporúčam otvoriť menšie množstvo logov, prezrieť ich a znova otvoriť ďalšie menšie množstvo logov a prezrieť ich. Pri powershell nástroji zase odporúčam zapnúť filtráciu a pozor na použitie nástroja "more" v powershelli.