Hackstock

 Egy icipicit megint változott az iTunes anti-debug. Mivel megtanultuk, hogy az iTunes.dll-t kell vizsgálnunk, ezt dolgoztattam fel IDA-val. Az importok között azonnal az IsDebuggerPresent cimkét kerestem. Három hivatkozást találtam az import-ra amelyek közül egy az __invoke_watson és egy a ___report_gsfailure eljárásban helyezkedett el. A harmadik egy nem nevesített eljárásban van. Az első kettő érthető módon nem a védelem része, ezért a harmadikra terelődött a figyelmem.

Ezt pedig már nem is bonyolult megfejteni. A feltételes ugrást írjuk át feltétel nélkülire a 10163F55 címen és elkészült a nagy mű!

 Indítottam egy másik blog-ot. Nem tudom, hogy lesz belőle. Talán semmi vagy az lesz majd a nagy durranás... ki tudja!

http://byteforge.blogspot.com/

 Az iTunes 10-es verzió sem engedi debugolni magát. Éppen úgy, ahogy az előzők sem engedték ezt.

Ahogy korábban is, megint a szokásos rutin részletet kell keresnünk.

Szinte már rutinszerűen patcheljük át, hogy minden esetben nullás EAX értékkel térjen vissza.

Csakhogy ebben az esetben egy kicsit más a történet, mert a kérdéses programrészleteket nem az iTunes.exe-ben találjuk meg, hanem az iTunes.dll-ben!

Most, hogy elárultam a megoldást, lássuk röviden, hogyan akadhatunk a nyomára - nyilván ez egy olyan kérdés, ami többek oldalát fúrhatja.

Az iTunes.exe IDA-ba töltése után indítsuk el és a dll-ek töltése közben egy időre állítsuk meg a folyamatot, hogy az ExitProcess-t megkereshessük és megszakítást tehessünk le a belépési pontjára - [G] ExitProcess. Ha ez megtörtént, akkor hagyjuk, hogy a betöltődés és a programfutás folytatódjon. Egyszercsak üzenet érkezik, hogy megszakítási ponthoz érkeztünk, ami nem más, mint az ExitProcess. Én itt a stack view-t az ESP regiszter értékére igazítottam és a legtetején levő érték címén levő pozíciót töltettem be a disassembly képernyőre, ahol a meghívott ExitProcess utáni utasításon jelent meg a kijelölés érthető módon. Innentől pedig már gyerekjáték feltérképezni a hatásmechanizmust.

Ennyi a történet.

Vajon eddig miért nem valósított meg senki sem egy valódi, natív emulációs környezetet az OSX rendszer számára Windows alatt? Egy ilyen rendszer lehetővé tenné alkalmazások futtatását egy hibrid rendszerben.

Erre a kérdésre próbáltam választ keresni a két rendszer architekturális összehasonlításával.

Eddig a Dinamikus Linker fő programágát vizsgáltuk, de adós maradtam még néhány nagyobb alprogram működésének magyarázatával.

Most hadd törlesszek ebből azzal, hogy az ImageLoader link metódusának mélységeiben nézek körül.

 Bizonyára nem csak bennem maradtak kérdések az előző bejegyzés kapcsán. Az szép és jó, hogy a program bináris állománya betöltődött, de ezen kívül más nem történt igazán, ha a veremszegmens, a taszk státuszának feltöltését és a dinamikus linker betöltését nem számítjuk. Egy igen fontos elem hiányzik a kirakóból, ez pedig az importált függvények betöltés, feloldása, csatolása vagy linkelése.

Tehát most azt kell megvizsgálnunk hogy mi történik akkor, amikor a kernel zöld utat ad és a thread elkezd működni az /usr/lib/dyld belépési pontjától. Szerencsére ennek a modulnak a forráskódja is szabadon hozzáférhető,ezért töltsük is le.

A napokban kezdtem el MacOSX rendszerben a MachO binárisok betöltődését vizsgálni. Látni akartam, hogy mi történik a file-lal, hogyan kerül a memóriába a tartalma és hogyan történik a rendszerbe illesztése.

Szerencsére az Apple nyílt forráskódúvá tette ezeket a részleteket és - hasraütésszerűen - letöltöttem a MacOSX 10.5.1 XNU csomagjának forráskódját. Ezen kívül még érdekes információkat találtam több írásban is szerte a web-en; az "Apple binárisok védelme" című írásban, találtam egy másik írást, ahol szintén az OSX alkalmazásvégrehajtását taglalják. Jó leírások, de mindegyik esetben, amikor a dinamikus linkerhez érkeznek, akkor csak azzal intézik el, hogy az /usr/lib/dyld töltődik be, ez elvégzi a linkelést viszont arra vonatkozóan, hogy milyen fázisban történik ez meg illetve milyen módon, milyen funkció hívódik meg, nem találtam információt. Ilyen és ehhez hasonló kérdések miatt kezdtem foglalkozni a témával.

Csupán megjegyzés szinten érdemes megemlíteni, hogy dinamikus linker univerzális binárisában négy rendszer image-et találtam, ami azért volt meghökkentő első látásra, mert korábban csak két rendszerét találtam (Intel X86 és PowerPC). Ez a négy image Intel X86 32 bit, Intel X86 64 bit, PowerPC 32 bit és Power PC 64 bit. Ráadásul egy 10.4.8-as disztribució került a kezembe. Természetesen ez nem akadálya a kutakodásomnak, hiszen az IDA 5.5 remekül kezeli ezeket az állományokat.

 Ma olvasgattam MSDN-en a window class-ok regisztrálásán és teljesen véletlenül akadt meg a szemem egy bekezdésen (itt). Lehet, hogy nem nagy újdonság, de megmozgatta a fantáziámat.

Ez az én olvasatomban azt jelenti, hogy ha készítek egy DLL-t, abba akármilyen kódot írok (az inicializáló eljárásba), az le fog futni minden processz indulása előtt... érdekes. :)

 Honnan is ered a blog neve? Hát innen! Hackers - Lord Nikon búvóhelyének ajtaját díszítette ez a felirat.

 

Végre elkészült a BossPrefs egy működő verziója, aminek a segítségével szolgáltatásokat lehet ki és be kapcsolni a telefonon. Azért hasznos alkalmazás, mert az SSH szervert is így lehet parkoltatni, amíg nincs rá szükség, mert korábbi tapasztalatok szerint jelentősen csökkenti az akkumlátor feltöltés nélküli használati időtartamát.

Böngészve a könyvtárstruktúrát azt láttam, hogy azok szerkezete a korábbi firmware verziókhoz képest jelentősen átalakult. Itt kezdtem el vizsgálni a lokalizált erőforrásokat.

Finder-ben a rejtett file-okat és mappákat a következőképpen lehet megjeleníteni

Ezt kikapcsolni pedig értelemszerűen így lehet.

Amióta letöltöttem és feltelepítettem a MacOSX 10.5.1-es verzióját, el is felejtettem, hogy milyen release, így a neten fellelhető frissítések nem jöhettek szóba. A csavar a dologban, hogy más verziókat nem sikerült telepítenem, mert az install folyton leállt, "Still no root device" üzenettel, ami azt jelenti, hogy az ATA vezérlőt nem sikerült felismertetni. Ezen túl még az is bonyolította a helyzetet, hogy AMD alapú laptopot használok.

Elhatároztam, hogy a tanulás miatt is megpróbálom saját kezűleg frissíteni.

Első tennivalóm az EFI telepítése volt, amit innen töltöttem le. A használata nagyon egyszerű, mindent elvégez az installer, csak el kell indítani.

Zephyroth készített egy ügyes frissítő programot, ami hasonlóan működik, mint a rendes updater. Letölti a frissítő csomagot és átfésüli CPUID utasítások után kutatva. Tudniillik a MacOSX ezzel az utasítással ellenőrzi, hogy dedikált hardveren futtatják-e, tehát még Intel PC-n futó operációs rendszert is lehet vele frissíteni. További funciója, hogy a frissítésekből minden olyan érzékeny koponenst eltávolít, ami elronthatná a futó verziót (kernel frissítés, stb.). Érdemes minden frissítést vele letölteni, mert a QuickTime 7.5-ösben is előfordultak ellenőrzések.

A 10.5.4-es frissítés után a billentyűzet vezérlése romlott el és ezzel nem voltam egyedül, számos fórumon panaszkodtak mások is. A probléma az, hogy a frissítésben átdolgozták kicsit a PS2-es eszközök kezelését. Szerencsére Chun-Nan elkészítette az áthidaló kernel bővítőt, amit itt találunk meg AppleAPCIPS2Nub néven (fordított project itt).

Záró lépésként modbin 9.4.0 kernel-t telepítettem. A működő operációs rendszerben _new utótagokkal elhelyeztem a frissítendő modulok mellett: /mach_kernel_new és /System/Libary/Extensions/System.kext_new. Itt a régi MacOSX telepítő DVD-mmel bootoltam és amint megjelent a grafikus felület, felül a menüből elindítottam egy terminált.

A jogok helyes beállítására feltétlenül figyeljünk oda!

Minden tökéletesen működik (kivéve az ATI Radeon Xpress 200m, mert a QE/CI nem működik, de ez eddig is így volt) és meg tudom erősíteni azt, hogy sokkal zökkenőmentesebben működik a rendszer az új, módosított kernellel.

 Az Appleblog-on olvastam, hogy fejlesztés során az alkalmazásokban maradtak - buta automatizált fordító scriptek - bizonyos designable.nib-ek, amelyek az alkalmazások futásához egyáltalán nem szükségesek.

Nosza, nekiálltam, hogy faragjak egy kicsit, aminek az áldozata a Mail alkalmazás lett. Első kísérleti állat lévén belehalt szegény; véletlenü letörlődött. Sebaj, majd a telepítő DVD-ről visszanyerem, ha nagyon hiányzik.

Második kísérleti állat az iChat lett és rajta már eredményesen alkalmaztam az alábbi scriptnek sem nevezhető epigrammát.

sudo find . -type f -name designable.nib | xargs sudo rm

Az eredmény magáért beszél.

 

Előtte	Utána

 

Természetesen mindenki csak saját felelősségére használja!

A legutolsó jelentkezése óta történt pár előrelépés és módosítás a projektekkel kapcsolatban.

A fejlesztések egy másik alprojektet ereményeztek, aminek eredményeképpen a Mach-O file formátum szerkesztője mellett megjelent egy disassembler is. Ennek kapcsán a korábbi formátum kezelő keretrendszeren is esközöltem módosításokat.

Nézzük, mi is történt:

• a file formátum parser átalakítása úgy, hogy egy kvázi runtime memória kiosztást állít össze (elemzésekhez, netán a későbbiekben emulációhoz)
• az utasítás felismerési mechanizmus absztrakt réteg mögé helyezése, ami a későbbiekben már processzorok utasításkészletének implementálását is lehetővé teszi
• keresztreferenciát feloldása a programkódban (adatpointereknél még nem)
• mnemonic elemek stilizált renderelése és az absztrakt utasítás elemek összekötése egy kezdetleges GUI-val

Az eredmény pedig:

A blog tetszhalottsága ellenére a kulisszák mögött nagy szabású projektek bontakoznak ki. Egyik ilyen eredményét szeretném megmutatni. Egyelőre le kell szövegnem, hogy még nagyon kezdetleges fázisban tart.
Elöljáróban annyit, hogy ezzel az alkalmazással egy iPhone-ról lemásolt alkalmazást dolgoztam fel. Amire képes eddig:

• MachO file-ok megnyitása (PPC, Intel, iPhone)
• Attribútumok átírása
• MachO file-ok újraépítése (betöltés és módosítás után)
• ARM processzor utasítások visszafejtése (opcode --> mnemonic) - még fejlesztés alatt

Tegnap frissítettem néhány alkalmazást az InstallerApp-pal, az egyik komponenes újraindítást kért. Ma meglepve tapasztaltam, hogy nem tudok telefonálni; kicseng és csörgeti a másik oldalt, de nem hallok semmit a telefonban és nem is visz át semmit.

Vajon mi lehet a gond?

Ha hazaérek uninstall minden 3rd party alkalmazást...

 

---

Ah... rémületemben uninstalláltam mindent és újraindítottam az egész telefont, de ugyanaz volt az eredmény.

 

Utána eszembe jutott, hogy vajon fülhallgatóval működik-e az MP3 lejátszás hangja és igen. Fülhallgatóval telefon, igen. Fülhallgató nélkül telefon, igen.

Érdekes volt és most pakolhatok fel megint mindent. :)

---

Hivatalos iPhone SDK, oktató videók tölti-tölti-tölti...

Láttam próbálkozásokat az iPhone.SDK dokumentációjának összegyüjtésére, de sehol sem találtam kezelhető formátumot. Arra gondoltam, hogy miért ne vágnék bele. Billentyűzetet ragadtam és automatizáltam az elkészítését, aminek az eredménye itt található meg. Javadoc-os utánérzet előfordulhat, mert nagyon sokáig azt használtam és a szerkezetét nagyon egyszerűnek és kényelmesnek találtam.
Még erősen fejlesztés alatt van, hibák nagy számban fordulhatnak elő, sőt a header-ekben is számos hibát fedeztem fel, ezeket javítom és az SDK könyvtáramat is közkinccsé teszem valamikor. Természetesen ötleteket is szívesen fogadok.

Elvadult pillanatomban a Mach-O file formátumának leírását kerestem. Nem kellett sokáig kutakodnom, mert nyílt és az Apple szépen leírja az elképzeléseit és bárki számára elérhető itt.

Ami felkeltette az érdeklődésemet éppen a dokumentum végén található: Universal Binaries. Az unverzális bináris állományok lényege, hogy több architektúrára fordított program egy file-ban helyezkedik el és az operációs rendszer a neki megfelelőt tölti be és futtatja.

Az IDA 5.2 for MacOSX elindításában két nehéz dolgot ismerek. Az első a beszerzése; nem egyszerű, mert nem kering minden csatornán. Ha az első problémát megoldottuk, akkor a mac_server és idal modulon a procmod-ot kell engedélyezni (chmod g+s vagy chgrp procmod).

Ezen túl a nyomkövetésben is némi eltérés mutatkozik. Egy terminálablakban el kell indítani a mac_server-t. Én ezt a következőképpen szoktam.

sudo ./mac_server -Pmypass

A hosszas hallgatás mögött a háttérben fejlesztés és kutatómunka folyik, általában két-három dolgon dolgozom egyszerre.
A legutolsó eredményem a képernyő érintésének leolvasása. Talán nem árulok el nagy titkot, ha azt mondom, hogy az érintések egérműveletekként jelennek meg. Egérműveletek. Tehát akkor van bal és jobb gomb? Egyelőre csak mondjuk úgy, hogy bal gomb, pontosabban csak egy érintés érzékeléséig tudtam eljutni. A több érintés megoldását még keresem.
Egérműveleteket a UIResponder-ből leszármazó objektumok mouseDown, mouseDragged metódusai segítségével kaphatjuk el. Tehát implementáltam egy UIView-t és a következőket kell kiemelni a header file-ban a működés szempontjából. Nem árulok zsákbamacskát. A két pontot vonalak rajzolásához fogom felhasználni. Az ujj elmozdulásának leolvasását a két mouse függvény segítségével végezem el. A drawRect függvény a képernyőtartalom frissítésének callback-je.
A privát adattag és az osztály konstruktora így néz ki. Talán a mouse függvények implementációja sem okoz nagy izgalmat. A pont koordinátáinak konverziójára érdemes odafigyelni. Meglehet, hogy UIView-ba ágyazott UIView esetében kap szerepet. A setNeedsDisplay értesíti az ablakkezelő rendszert, hogy frissíteni kellene. Ennek meghívása váltja ki a drawRect függvény elindítását. A rect paraméter a frissítendő területet jelöli ki, de ettől nyugodtan rajzolhatunk bárhova a UIView-nkon.
Ezen a ponton arra a furcsaságra szeretném felhívni a figyelmet, hogy először minden drawRect híváson belül rajzoltam egy vonaldarabot a CGContextAddLineToPoint metódussal. Ekkor azt  figyeltem meg, hogy vibrált a kép, ahogy az ujjamat mozgatva rajzoltam. Mintha kettős bufferelés lenne és hol egyik, hol másik bufferre rajzoltam volna, tehát a két kép tartalmazta az egész képet (egyes részeit az egyik, másokat a másik). Ezt oldottam meg úgy, hogy egy globális Mutable Path-t hoztam létre és minden alkalommal az új elemeket ahhoz adom hozzá és az egész vonalhalmazt kirajzolom rá. Tartottam némi lassulástól, de ilyet nem tapasztaltam.
A CoreGraphics és GraphicsServices include-olásáról is gondoskodjunk a megfelelő helyeken (az include/CoreGraphics könyvtárban a header-ek tanulmányozásai is érdekes lehet, pl: CGContext, CGPath).

Enjoy

Nézegettem a header-eket és azon gondolkodtam, hogy most melyikről kellene írni. Rátaláltam a UIAlertSheet-re, ami hasonlóan működik, mint a Windows-os megfelelője, a MessageBox.
A következő példát ütöttem össze. Egy tömbbe a megjelenítendő gombok nevét kell bedobálni. Itt figyeljük meg, hogy egy lezáró nil-t is hozzá kell adni. Az objektum inicializálása során megadhatjuk a címet, a gombok címeit, az alapértelmezett gomb sorszámát - -1 esetén nincs ilyen -, delegált objektumot és kontextust. Ezután egy üzenetet is megadhatunk, ami majd szépen a cím és a gombok között fog megjelenni.
Ide még egy kis magyarázat kívánkozik. A button és a tvMessage úgy kerül a képbe, hogy előzőleg egy UINavigationBar-t tettem ki és a szokásos log view-t. A navigációs sor két gombjának delegált metódusában helyeztem el a kódrészletet, így szabályozni tudtam, hogy a kétfajta megjelenítési módból melyik jelenjen meg.
Két fajta megjelenítési mód?
Az első, amikor alulról csúszik fel, a másik, amikor a képernyő közepén jelenik meg. Mindkét esetben modálisan jelenik meg, ami azt jelenti, hogy az input fókuszát nem lehet tőle elvenni. Végül említsük meg, hogy a delegált metódusban tüntessük el a UIAlertSheet-et, animálva vagy animáció nélkül tetszés szerint.
Sajnos a modalitás miatt nem tudtam képet készíteni, ezért is kívánok hozzá jó szórakozást.

A látogatottsági statisztikákat elnézve arra gondoltam, hogy ezentúl angolul fogom írni a bejegyzéseket, valamint a meglevőket is lefordítom. Keresőkön keresztül több külföldi is idetéved és próbálják lefordítatni kevés sikerrel. Ha bármilyen komment, hozzászólás lenne a témához, azt kérem, itt tegyétek meg vagy dobjatok e-mail és megpróbálok valamit kitalálni nagyobb nem tetszés esetén. Itt szeretném megragadni az alkalmat, hogy mindenkinek sikeres, boldog új évet kívánjak mindenkinek!

Nem akartam rövid bejegyzéssel untatni maréknyi olvasóimat, de ezt feltétlenül meg kell osztanom.
A következő make file beállítással sikerült jól linkelnem az SQLite3 library-t. Csak egyszerűen megmondtam, hogy hol található az ARM release (mivel a /usr/lib helyen az Inter release található, amivel nem lehet linkelni).
Ezen túl pedig a UIKit/UIScroller.h file-hoz adjuk hozzá a következő sort, mert a fordítás leáll néhány hiányzó struktúra okán.

Jogosan merül fel, hogy használjuk az XCode-ot, ha már feltelepítettük és nem utolsósorban az intelligens kódkiegészítés, szintaxis szerinti szinezés is nagyon hasznos lenne, mert vi, TextEditor nagyon fapados. Különben sem mondta senki, hogy feszüljön meg, aki iPhone programozásra adta a fejét és már XXI. századot írunk.
Lássunk hozzá. Nem kisebb dolgot fogunk elkövetni, mint iPhone.sdk-t fogunk összeállítani. Néhány napos nézelődés és kísérletezés után arra jutottam, hogy a következő néhány könyvtár létrehozásával ki lehet alakítani az alap struktúrát. Természetesen nem a feladat bonyolultsága miatt tartott ilyen sokáig, hanem szerettem volna rendesen körüljárni minden lehetőséget és kísérleteztem. Másik SDK könyvtárakban a System/Library/Frameworks könyvtárában a framework-ök érdekes struktúrája van, de erre nekünk nincs szükségünk. A telefon framework-jeit a következőképpen linkeltem. Itt még azt szeretném megjegyezni, hogy ezek a framework-ök csak azok, amiket az SVN-ből letöltött változat tartlmaz. Ennél többet találtam Erica Sadun chaintool-jában, de ezeket később varázsolom a helyükre. Egyenlőre még nem tanulmányoztam, de elképzelésem szerint csupán annyiból fog állni a művelet, hogy a megfelelő könyvtárakat header-ekkel együtt a /usr/local/arm-apple-darwin/include könyvtárba fogom másolni és ugyanilyen módon linkeket fogok létrehozni. Most legyen elég az, ami rendelkezésünkre áll.
Elkészítettem egy sablon projektet, amit innen lehet letölteni. Kicsomagolás után a /Developer/Library/Xcode/Project Templates/Application könyvtárban kell elhelyezni.
Mondhatni el is készültünk vele.
Itt szeretném még megjegyezni, hogy némely header file-ban hibákat fedeztem fel. Például a BluetoothManager framework-ben a file-ok importjában a következő szerepel. Mivel tudjuk, hogy ha macskakörmökkel írjuk az #import után a file nevét, akkor a file-hoz képest relatíven értelmezi a helyét. Ha kisebb-nagyobb jelekkel, akkor az include könyvtárakhoz képest relatíven kerül értelmezésre. A magam részéről a következőképpen javítottam. Ilyen és ehhez hasonló hibákra még számítani lehet és célszerű javítani őket (sudo vi).
Ha mindent jól csináltunk, akkor a build zökkenésmentesen működik. Ha mégis probléma adódna, akkor a Build/Build Results menüpont alatt láthatjuk az üzeneteket.

Gondoltam egy merészet és telepítettem MacOSX Leopard 10.5.1-et és Xcode 3.0 fejlesztő környezetet. Minden erőfeszítés nélkül tökéletesen működik olyannyira, hogy ezt a post-ot is már belőle írom, bár a blog szerkesztője nem működik tökéletesen, de ez a Safari problémája (majd telepítek Mozillát).
Ha már MacOSX, akkor jó lenne iPhone alkalmazásokat fejleszteni is. A toolchaint kicsit másként kell felépíteni, mint Cygwin-ben.
Itt is az első dolgunk a megfelelő modulok letöltése a megfelelő SVN repository-kból. Egyik konzolban az iPhone fejlesztő könyzetet, mivel ez kicsit több időt vesz igénybe. Ha befejeződött a letöltés, ezt a konzolt nyugodtan bezárhatjuk. Másik konzolban az LLVM forrását. Fontos, hogy ezt a konzolt hagyjuk nyitva, mert ezzel fogunk dolgozni a későbbiekben. Amint ez utóbbi befejeződött, kezdhetjük is a fordítást. A toolchain könyvtárát is hozzuk létre. Ha az első konzolban az LLVM letöltése befejeződött, akkor folytathatjuk az ODCCTools fordításával. Most hozzuk létre a könyvtárat, ahova a telefonról a file-okat másoljuk és a HEAVENLY környezeti változót állítsuk be. A file-ok lemásolását mindenkinek a saját fantáziájára bízom, én a Windows particióról lemásoltam az előző tartalmat. Egyenlőre a symlink-eket nem javítottam, majd ha szükségem lesz rájuk, majd akkor megcsinálom. Tudniillik a Cygwin a Linux-os symlinkeket Windows rendszerben lnk file-okkal oldotta meg és azokat kellene lecserélni.
A header file-okat másoltassuk a helyükre. Készítsuk el a CSU-t is. Mielőtt az utolsó lépésbe velevágunk, ellenőrizzük a $LLVMOBJDIR és a $HEAVENLY változók tartalmát. Ha minden rendben van, akkor kezdjük el a fordító elkészítését. Ha az llvm-gcc-4.0-iphone/configure futtatása során permission denied üzenetet kaptam és a következőt csináltam. A lépést ismételten megpróbáltam és így már működött.
A puding próbja az evés, a HelloWorld alkalmazás jól fordul, azonban volt némi problémám. Az első, amit könnyebb orvosolni, hogy header file-okba belenyúltam és az enumerációs típusok hiányoznak. Mivel nem akarok erről a szokásomról lemondani és a továbbiakban is szeretném javítgatni, léltrehoztam egy symlinket a root-ban. Így már a Finder-ben is be lehet jutni a headerek közé. Azonban még így is van egy kis probléma. A header file-ok permission-jei állítgatásának ellenére sem tudtam módosítani a fejlécfileokat Xcode-ban. Ezt úgy hidaltam át, hogy Admin jogosultsággal indítottam el a programot. Adminisztrátori jelszó megadása után már működik minden. Ugyan ez a megoldás körülményes, de járható út, ráadásul a fejlécek módosításáre nincs szükség gyakran.
A másik bánatom, hogy az SQLite-ot használó alkalmazásokat nem tudok lefordítani. Erre még nem találtam ki semmit.