Merhabalar, bu sıralar uğraştığım bir projede android cihazdaki yerel bir veri tabanında kullanıcının paylaşılmaması gereken gizli bilgilerini kaydediyorum.
Tecrübenizden faydalanmak istediğim husus şu, yerel klasöre bakıyoruz ve eğer bir vt yoksa oluşturuyoruz. Peki bu vt’yi şifre ile giriş yapılacak şekilde oluşturmak yeterli mi? Programlama diliyle bu vt dosyasını şifresi ile açıp CRUD yapabiliyoruz. Proje derlendikten sonra APK haline geldiğinde vt dosyasının şifresinin yazdığı kodlar makine diline çevrildiği için güvenilir hale gelmiş midir? Siz bu durum için nasıl yöntemler kullanıyorsunuz merak ettim.
1 Beğeni
Kiminle paylasilmamasi gereken?
Cep telefonu isletim sistemleri sandboxing ve veri guvenligi konusunda iyi. Bir programin veritabani dosyasina bir baska program erisemiyor normal sartlar altinda.
APK’yi acip bakmayi denediniz mi?
Icindeki kod makine dili degil.
Makine dili olsa bile veritabani parolasi kod degil.
Kod olsa bile makine dili ozel bir dil degil.
Mevcut guvenlik modellerinde kullanicinin programini kullanicidan veya calistirmak istedigi baska bir programdan ayiran mekanizmalar pek alisilagelmis (veya yaygin diyelim) degil.
1 Beğeni
Açıkçası bunu da merak ediyordum. Söylediğiniz iyi oldu.
Şöyle bir soru da sormak isterim. Diyelim yaptığımız uygulamayı kullanıcı açtı ve ilk açılışta vt oluşturulmadan önce oluşturulacak vt için parola belirlemesini istedik. Bu parolayı nerde tutmak mantıklı olur? Şifrelenmiş bir txt belgesinde mi? Yoksa böyle yapmak yerine program kodları içinde sabit bir vt parolası vermek mi daha mantıklı olur?
Kullanicinin aklinda?
Onun parolasini nerede tutacagiz?
Hic biri mantikli degil, sifresiz olarak kullanman en mantiklisi.
Su soruyu atlamissiniz:
1 Beğeni
Peki teşekkürler.
Paylaşılmaması gerekenden kastım kimseyle paylaşılmaması gereken. Şöyle örnek vereyim mesela emekli birisi e-devlet şifresi, bankacılık uygulamaları şifresi, eşinin çocuklarının TC numarası gibi şeyleri ezberlemek ya da bir yere yazmak durumunda. Şifre güvenlik prosedürleri gereği bazı sistemler 6 ayda bir şifreyi değiştirmeyi zorunlu kılıyor. Bir süre sonra akılda tutulmayacak hale geliyor. Benim çevremde bu tarz insanlar var, şunun şifresini kaybettim giremiyorum yardımcı olur musun falan. Ben de basit bir şifre saklama uygulaması yapayım dedim fakat şifreyi saklayacak vt yi en iyi nasıl sağlama alırım o konu hakkında tecrübelerinizi merak ettim.
Hah tamam, simdi daha acik oluyor…
Bu sorulari soruyorum cunku guvenlik analizi yaparken bilinmesi gereken seyler. Mesela kullaniciyi kendisinden, veya telefonu ele gecirmis kotu niyetli bir aktorden koruyacak miyiz. Telefonda sakli her bite potansiyel erisimi olan Google’dan veya telefon operatorlerinden, bunlari kontrol eden devletlerden koruyacak miyiz…
Oncelikle: Android hakkinda cok sey bilmiyorum. Tek bildigim, ozellikle son versiyonlarda, sandboxing’in guclendirildigi. Yani kotu niyetli bir programin bir baska programin dosyalarina erismesi mumkun, veya en azindan kolay degil. Incelenmesi gerek.
Hatta su aralar bir suru program guvenli verileri isletim sistemi destekli biyometrik dogrulama arkasinda tutuyor. Muhtemelen oyle bir sey cok kolay ve cok yeterli olacaktir ve bosuna tartisiyoruz.
Ama PC uygulamasi yapan, ve guvenlik ve sifreleme islemleriyle ilgilenen bir suru insan var, o yuzden Android’e ozgun bu guzellikleri bir kenara koyalim:
Ben de bu tarz insanlardan biriyim. Garanti parolam, butun guvenlik tavsiyelerine meydan okuyacak sekilde, #####1 → #####2 → #####8 → #####7 → #####5 ⮌ olarak degisiyor. Fakat Kongregate parolam Fx8PvExZSrm7lCZK.
Bu noktada “parola kasasi” (password vault) uygulamalarini incelemek lazim (orn. KeePassXC) Surada baya detayli bilgi var. Daha basit olarak bir KDF (mesela PBKDF2) ve urettigi key ile encryption (AES256) kullanilabilir. Tabi KDF’e girdi olacak gizli bir sey lazim.
Anahtari kodda istediginiz kadar tutun, aciga cikmasi engellenemeyecektir. Buna uygulamali ornek gormek isteyen veya algoritmasini test etmek isteyen varsa bana gonderebilir; crackme cozmeyeli baya oldu, ozluyorum.
Ama zaten amac bilgiye erismekse anahtari ogrenmeye gerek yok; calismakta olan programin hafizasi okunup bilgiye erisilebilir. Hatta bu noktada rastgele bir anahtar uretilip bir dosyaya yazilmasi daha guvenli olabilir: En azindan baskasinin veritabani dosyasina sahip biri onu acamaz.
Sanirim en mantiklisi KeePass tarzinda master password ile calisan bir db ("vt"yi “virtual terminal” olarak okuyorum). Master password’un unutulmasina karsi db’nin baska sekilde sifrelenmis kopyalari kullanilabilir. Ilk olarak aklima private key’i baskasinda olan bir asimetrik sifreleme sistemi geldi ama guvenlik uzmani degilim, oncelikle mevcut yontemleri arastirmak gerekeir.
2 Beğeni
Vt yerine db ye bir türlü alıştıramadım kendimi 
Güzel bir yazı oldu teşekkürler, becerebildiğim ölçüde birşeyler yapmaya çalışacam artık. En kötü durumda sadece bir db oluşturup içine yazarım.
Bayağı kavram öğrenmeme vesile oldunuz.
KeePass dökümantasyonu biraz karışık geldi, ingilizcemin yetersizliğinden olabilir. Araştırdım, Flutter için bununla ilgili paket varmış [1].
Bunu da biraz araştırdım, bir tür zip dosyası gibi paket halinde bir yapıdaymış .apk dediğimiz yapı. Hibrit uygulamalar çok kolayca kaynak koda dönüştürülebilir iken native uygulamalar da Java olarak dönüştürülebiliyormuş [2].
Bu geri dönüşüm işini daha zorlaştırma adına kod karıştırma (Obfuscating) denilen mevzular falan varmış. Bundan da haberim oldu bu sayede [3].
Her yeni şey öğrendiğimizde yeni deryalara kapı aralamış oluyoruz, bilginin sonu yok gerçekten. Güzel olan da böyle olması, merakla durmadan devam ediyor araştırma süreci 
REFERANSLAR
1 Beğeni
Bir de, bazen on arastirma olarak eldeki aletler yetiyor:
$ file UnCrackable-Level1.apk
UnCrackable-Level1.apk: Zip archive data, at least v0.0 to extract, compression method=deflate
$ unzip UnCrackable-Level1.apk
[...]
$ file **/*
AndroidManifest.xml: Targa image data - RLE 868 x 65536 x 24 +1 +28 ""
classes.dex: Dalvik dex file version 035
META-INF: directory
META-INF/CERT.RSA: data
META-INF/CERT.SF: ASCII text, with CRLF line terminators
META-INF/MANIFEST.MF: ASCII text, with CRLF line terminators
res: directory
res/layout: directory
res/layout/activity_main.xml: Android binary XML
res/menu: directory
res/menu/menu_main.xml: Targa image data - RLE 176 x 65536 x 8 +1 +28 ""
res/mipmap-hdpi-v4: directory
res/mipmap-hdpi-v4/ic_launcher.png: PNG image data, 72 x 72, 8-bit/color RGBA, non-interlaced
res/mipmap-mdpi-v4: directory
res/mipmap-mdpi-v4/ic_launcher.png: PNG image data, 48 x 48, 8-bit/color RGBA, non-interlaced
res/mipmap-xhdpi-v4: directory
res/mipmap-xhdpi-v4/ic_launcher.png: PNG image data, 96 x 96, 8-bit/color RGBA, non-interlaced
res/mipmap-xxhdpi-v4: directory
res/mipmap-xxhdpi-v4/ic_launcher.png: PNG image data, 144 x 144, 8-bit/color RGBA, non-interlaced
res/mipmap-xxxhdpi-v4: directory
res/mipmap-xxxhdpi-v4/ic_launcher.png: PNG image data, 192 x 192, 8-bit/color RGBA, non-interlaced
resources.arsc: data
$ strings classes.dex
!n0#
'/dev/com.koushikdutta.superuser.daemon/
/system/app/Superuser.apk
/system/bin/.ext/.su
/system/etc/.has_su_daemon
/system/etc/.installed_su_daemon
"/system/etc/init.d/99SuperSUDaemon
/system/xbin/daemonsu
,5UJiFctbmgbDoLXmpL12mkno8HT4Lv8dlat8FxR2GOc=
8d127684cbc37c17616d806cf50473cc
<init>
AES error:
AES/ECB/PKCS7Padding
App is debuggable!
CodeCheck
Landroid/app/Activity;
!Landroid/app/AlertDialog$Builder;
Landroid/app/AlertDialog;
Landroid/content/Context;
1Landroid/content/DialogInterface$OnClickListener;
!Landroid/content/DialogInterface;
$Landroid/content/pm/ApplicationInfo;
Landroid/os/Build;
Landroid/os/Bundle;
Landroid/text/Editable;
Landroid/util/Base64;
Landroid/util/Log;
Landroid/view/View;
Landroid/widget/EditText;
#Ldalvik/annotation/EnclosingMethod;
Ldalvik/annotation/InnerClass;
Ljava/io/File;
Ljava/lang/CharSequence;
Ljava/lang/Character;
Ljava/lang/Exception;
Ljava/lang/Object;
Ljava/lang/String;
Ljava/lang/StringBuilder;
Ljava/lang/System;
Ljava/security/Key;
Ljavax/crypto/Cipher;
!Ljavax/crypto/spec/SecretKeySpec;
Lsg/vantagepoint/a/a;
Lsg/vantagepoint/a/b;
Lsg/vantagepoint/a/c;
-Lsg/vantagepoint/uncrackable1/MainActivity$1;
-Lsg/vantagepoint/uncrackable1/MainActivity$2;
+Lsg/vantagepoint/uncrackable1/MainActivity;
Lsg/vantagepoint/uncrackable1/a;
Nope...
PATH
Root detected!
Success!
TAGS
That's not it. Try again.
This is the correct secret.
3This is unacceptable. The app is now going to exit.
VILL
[Ljava/lang/String;
accessFlags
append
charAt
contains
create
decode
digit
dismiss
doFinal
equals
exists
exit
findViewById
flags
getApplicationContext
getApplicationInfo
getInstance
getMessage
getText
getenv
init
length
name
onClick
onCreate
setButton
setCancelable
setContentView
setMessage
setTitle
show
split
test-keys
toString
value
verify
&~~D8{"min-api":19,"version":"v1.0.35"}
Bu arada, kodu analiz etmeden anlamasi zor, ama su 3 string crackme’nin cozumunu veriyor:
,5UJiFctbmgbDoLXmpL12mkno8HT4Lv8dlat8FxR2GOc=
8d127684cbc37c17616d806cf50473cc
AES/ECB/PKCS7Padding
1 Beğeni
Beni aştı şu an 
.apk’nın kolayca açılabileceğini görmek adına güzel örnek sağol.
file ve strings gibi aletlerin genis kullanim alanlarini gostermekte de.
Hocam, dediginiz gibi konular o kadar genis derya ki, tek yapabildigim arastirilabilecek terimleri ve guzel oldugunu dusundugum hikayeleri/ornekleri birakip kacmak. (Sorulari cevaplamanin yaninda yani.)
Valla bir ton bir şeylerden haberdar oluyoruz işte sağolasın. Saygılar