# Denetim istemi — kullanıcı perspektifi (v2.0) **Ne işe yarar:** herkes bu metni, kaynak kodla (veya APK ile) birlikte bağımsız bir denetçiye — insan ya da yapay zekâ modeli — verebilir ve gerçek parasını emanet edecek bir uygulamayı yüklemeden önce acemi bir kullanıcının soracağı soruları yanıtlayan bir rapor alabilir. **İstem sürümü:** 2.1 — 20/10/2026 (1.0'ın yerini alır; bkz. §1.1 ve §1.2) **Uygulama:** 0x2ALL (Android, yerel anahtar saklama, Hyperliquid) **1.0'dan 2.0'a ne değişti:** kapsam, sahibin tasarım kararlarını açıkça beyan eder (§1.1). Bunlar bulgu **değildir**: denetçi, beyan edildiği gibi uygulanıp uygulanmadığını doğrular ve bunları ayrı bir bölümde açıklar (§4, madde 2b). Ayrıca raporda operasyonel saklama değerlerinin (adresler, tutarlar, kimlik bilgileri) yayımlanması yasaktır (§1.2). --- ## 0. Rolünüz Bağımsız bir güvenlik denetçisisiniz. Sizi işe alan kişi, **geliştiriciyi hiç duymamış bir kullanıcıdır**: bir site buldu, site indirilecek bir APK sunuyor ve APK, gerçek parası olan bir cüzdanın özel anahtarını saklayacak. Geliştirici anonim. Şirket, vergi kaydı, uygulama mağazası ya da kamuya açık bir geçmiş yok. Göreviniz mimariyi övmek değil. Tek bir soruyu kanıtla yanıtlamaktır: > **Bu uygulamayı kurup para yatırırsam, fonlarımı çalabilir mi, beyan edilenden fazlasını > benden tahsil edebilir mi ya da cihazımda kötü niyetli bir şey yapabilir mi?** Varsayılan olarak şüphecisiniz. İspat yükü geliştiricide, sizde değil. --- ## 1. Kanıt kuralları 1. **Geliştiricinin hiçbir beyanı kanıt sayılmaz.** README, site, kod yorumları, önceki denetim belgeleri ve commit mesajları iddiadır, kanıt değildir. Alıntılanabilirler, ancak her biri kodda, ikili dosyada veya bir komutun çıktısında doğrulanmalıdır. 2. **Her yanıt birincil kanıt gerektirir:** `dosya:satır`, yeniden üretilebilir komut çıktısı, APK alanı veya ağ kaydı. Bu yoksa yanıt "doğrulanmadı"dır — ve "doğrulanmadı" kabul edilebilir bir yanıttır; uydurmak değildir. 3. **Olumsuz kanıt zorunludur.** Var olmadığını beyan ettiğiniz her vektör için ne aradığınızı söyleyin ve aramanın boş döndüğünü gösterin (komut ve sonuç). Kayıtlı arama olmadan "şüpheli bir şey bulamadım" hiçbir şeyi kanıtlamaz. 4. **Kodu değiştirmeyin.** Bu yalnızca rapor üreten bir iştir. Bir kusur bulursanız kusuru ve önerilen düzeltmeyi tanımlayın; düzeltmeyin. 5. **Mekanik olanı yargıdan ayırın.** Hash, izin listesi, alan adı listesi ve imza hedefleri herkesin doğrulayabileceği olgulardır. "Kod iyi yazılmış" bir yargıdır — bunun yargı olduğunu söyleyin. ### 1.1 Beyan edilmiş tasarım kararları (bulgu kapsamı dışında) Sahip, aşağıdaki kararları **bilinçli tasarım tercihleri** ve kabul edilmiş riskle beyan eder. Bunlar bulgu, güvenlik açığı veya ret olarak sınıflandırılamaz. Her biri için **yapmanız gerekenler**: - beyan edildiği gibi **birebir uygulanıp uygulanmadığını** doğrulamak (`dosya:satır` ile); - kullanıcı için etkiyi ve kabul edilen riski sade bir dille açıklamak; - uygulama beyanla **çelişiyorsa** bu bir bulgudur — ciddiyetini belirleyin ve normal şekilde sınıflandırın. **DD1 — %2'lik ücreti alan adres yayımlanmaz.** Ücret, koda gömülü sabit bir saklama adresine gider , çalışma zamanında setter yoktur ve onu değiştirebilecek hiçbir ağ verisi yoktur. Adresin gerçek değeri uygulamada, sitede veya bu raporda görünmez. Beyan edilen gerekçe: ücret imzacılarının fiziksel baskıya (*wrench attack*) maruz kalmasını azaltmak. Kabul edilen risk: varış yeri kamuya açık metinle doğrulanamaz. **DD2 — Keystore saklama anahtarı özerktir (biyometrik bağ yoktur).** Seed'lerin blob'u `setUserAuthenticationRequired(false)` ile oluşturulmuş bir Android Keystore AES anahtarıyla şifrelenir; çünkü robotun otomatik çekimi cihaz kilitliyken imzalamak için seed'i çözmesi gerekir. Elle yapılan saklama eylemlerinin (seed'i gösterme, gönderme, çekme, konsolide etme, offboard, silme) ayrı bir varlık kapısı vardır (biyometri → cihaz kimlik bilgisi → reddetme). Kabul edilen risk: root'lu veya ele geçirilmiş cihaz seed'leri açığa çıkarır; uzaktan vektör değildir. **DD3 — Otomatik kâr çekimi (D12 politikası).** Bir pozisyon US$ 22 veya daha fazla kâr gerçekleştirdiğinde uygulama bu kârın %50'sini kullanıcının kendi adresine çeker; diğer yarısı anaparayı oluşturmak üzere borsada kalır. İmza, seed'den türetilen master kimlik bilgisini kullanır, kullanıcının varlığı gerekmez. Kabul edilen risk: anahtar saklaması otomatik yol için kullanılabilir olmalıdır (D2'nin sonucu). **DD4 — Varlığın %100'ü ile pozisyon boyutu ve 10x ile 50x arası kaldıraç.** Her pozisyon cüzdanın toplam varlığı (marj + gerçekleşmemiş kâr) üzerinden, varlığın mevcut azami kaldıracı (10x–50x) kullanılarak boyutlandırılır; hedefler uzaktır (+%30, +%90, +%210…) ve stop, sonucu koruyacak şekilde yükselir. Kabul edilen risk: sert bir piyasa dönüşünde sermayenin tamamen veya kısmen kaybı mümkündür — bu uygulamada, Koşullar'da ve sitede beyan edilmiştir. > Dört karar da **ürün riski ve sahibin tehdit modeli** ile ilgilidir. > Bulgu, beyan edilenle çelişen şeydir; beyan edilen şey değil. ### 1.2 Raporun YAYIMLAMADIĞI şeyler - Saklama adreslerinin, anahtarların, seed'lerin, kimlik bilgilerinin veya herhangi bir operasyonel sırrın gerçek değeri. **Modeli** tanımlayın ("sabit saklama adresi"), asla değeri değil. - Adım adım yeniden üretilebilir saldırı tarifi. Arıza sınıfını, etkiyi ve önerilen düzeltmeyi tanımlayın; teknik ayrıntı geliştiriciye gider, kamuya açık sayfaya değil. Bu, yayımlanan rapor için geçerlidir. Rapor, **ne** bulunduğunu ve **hangi kanıtla** bulunduğunu kaydetmekle yükümlüdür — var olan bir bulguyu atlamak otomatik rettir (§3, madde 8). --- ## 2. Raporun YANITLAMAK ZORUNDA olduğu sorular Her maddeyi **EVET / HAYIR / DOĞRULANMADI** olarak yanıtlayın, ardından kanıtı verin. Yanıt "evet" ise tam olarak nerede olduğunu, paranın nereye gittiğini ve kimin yetkilendirdiğini söyleyin. ### Grup A — Para - **A1.** Uygulamada, beyan edilen **her para yatırma işlemindeki %2 aktivasyon ücretinin ötesinde** kullanıcıdan para alan bir yol var mı? (yinelenen ücret, kâr payı, abonelik, işlem başına ücret, bahşiş, "bağış") - **A2.** Fonların **tüm** olası varış yerlerini listeleyin: zincir üstü transferler, borsadaki çekimler, ücret ödemesi. Her biri için varış yerinin kullanıcının kendi adresi mi, koda gömülü beyan edilmiş sabit bir adres mi, yoksa çalışma zamanında hesaplanan bir şey mi olduğunu söyleyin. Ağdan alınan veriye bağlı bir varış yeri var mı? (Adreslerin gerçek değerini yeniden üretmeyin — §1.2.) - **A3.** Ücret **aynı para yatırma işlemi için iki kez** alınabilir mi? (uygulamanın yeniden başlatılması, robotun sürdürülmesi, yeniden kurulum, aynı cüzdanın içe aktarılması, aynı seed'e sahip iki cüzdan, onaydan önce ağ arızası) - **A4.** Bir işlemin **varış yerini, tutarını veya alıcısını** değiştirebilecek arka kapı, "geliştirici modu", özellik bayrağı, uzaktan yapılandırma veya sunucu yanıtı var mı? Uygulama, paranın nereye gönderileceğine dair ağdan gelen herhangi bir talimata uyuyor mu? - **A5.** Uygulama herhangi bir anda token için **onay (approve/allowance)** istiyor mu? İstiyorsa onaylanan limit nedir ve bu limit üçüncü bir tarafça harcanabilir mi? - **A6.** Seed veya özel anahtar herhangi bir yolda **cihazdan çıkıyor** mu? (ağ, günlük, yedek, pano, intent, harici dosya, bildirim, ekran görüntüsü) - **A7.** APK'yı elinde tutan biri seed'i çıkarabilir mi? Şunları değerlendirin: root'lu cihaz, `adb backup`, harici depolama, logcat, bellek dökümleri, APK yeniden paketleme. **D2** ile ilişkilendirin (beyan edilmiş karar). - **A8.** Kullanıcı, açıkça yetkilendirmediği bir yoldan fon kaybedebilir mi? En kötü gerçekçi senaryoyu ve en kötü saldırgan senaryoyu tanımlayın. **D4** ile ilişkilendirin (beyan edilmiş karar). ### Grup B — Kötü amaçlı yazılım / cihazdaki davranış - **B1.** Beyan edilen **tüm** izinleri ve her birinin neden gerekli olduğunu listeleyin. Riskli olan var mı: SMS, kişiler, aramalar, konum, erişilebilirlik, cihaz yöneticisi, ekran kaplaması, paket kurulumu, harici depolama okuma? - **B2.** Uygulama çalışma zamanında kod yüklüyor mu? (`DexClassLoader`, `PathClassLoader`, DEX/JAR indirme, `eval`, JavaScript köprüsü olan WebView, eklentiler) - **B3.** Hangi bileşenler dışa açık (`exported=true`)? Aynı cihazda kurulu üçüncü taraf bir uygulama bunlarla ne yapabilir? - **B4.** Telemetri, analitik, reklam, çökme raporlama veya tanımlayıcı toplama yapan üçüncü taraf bir kütüphane var mı? Tüm bağımlılıkları ve her birinin ağ üzerinden ne gönderdiğini listeleyin. - **B5.** Uygulama kendini gizliyor veya kaldırılmaya direniyor mu? (sahte simge, uygulama listesinden kaybolma, kaldırmayı engelleme, görünür bildirim olmadan çalışma) - **B6.** Uygulama root, emülatör, hata ayıklayıcı veya cihaz "parmak izi" tespiti yapıyor mu? Hangi amaçla ve bu veri nereye gidiyor? - **B7.** Uygulama kendi kendini güncelliyor, APK kuruyor veya kullanıcının açık rızası dışında kod indiriyor mu? - **B8.** Kullanıcı robotu durdurduktan, uygulamayı kapattıktan veya izni geri aldıktan sonra çalışmaya devam eden bir arka plan hizmeti var mı? ### Grup C — Ağ ve gizlilik - **C1.** Uygulamanın iletişim kurabileceği alan adlarını ve IP'leri **eksiksiz** listeleyin. Her varış yeri gerekli mi (borsa, ağ RPC'si, resmî site)? Beyan edilmemiş bir alan adı, analitik, üçüncü taraf CDN veya toplama uç noktası var mı? - **C2.** Tüm trafik HTTPS mi? `cleartextTrafficPermitted` var mı? Sertifika pinleme var mı — ve hassas veri alan tüm ana bilgisayarları kapsıyor mu? - **C3.** Her istekte tam olarak ne gidiyor (genel adres, imza, emir, uygulama sürümü)? Cihaz, kullanıcı veya kurulum tanımlayıcısı gönderiliyor mu? - **C4.** Sitenin sunucusu IP, user-agent veya erişim tarihini kaydediyor mu? Ne saklanıyor ve ne kadar süreyle? Bu, gizlilik politikasında beyan edilmiş mi ve politika kodla karşılaştırıldığında doğru mu? - **C5.** Gizlilik politikası, kodun yerine getirmediği bir şey vaat ediyor mu? (beyan edilmemiş toplama, beyan edilmemiş saklama, listelenmemiş üçüncü taraf) ### Grup D — Özgünlük ve bütünlük - **D1.** Dağıtılan APK imzalı mı? Sertifika nedir (SHA-256 parmak izi), sitede yayımlananla aynı mı ve dosyanın SHA-256'sı beyan edilenle eşleşiyor mu? - **D2.** Denetlenen kaynak kod, dağıtılan APK'ya karşılık geliyor mu? Kullanıcı bunu kendi başına nasıl doğrulayabilir? Yeniden üretilebilir bir derleme ya da en azından raporla birlikte yayımlanmış APK ve sertifika hash'i var mı? - **D3.** Uygulama, APK'yı paylaşmadan (P2P dağıtım) veya güncellenmeden önce kendi imzasını doğruluyor mu? - **D4.** Denetim raporunun yayımlanmış bir hash'i var mı? Kullanıcı, okuduğu metnin denetlenen metinle aynı olduğunu ve sonradan düzenlenmediğini nasıl doğrular? ### Grup E — Arıza, kayıp ve kurtarma - **E1.** Kullanıcı, borsada açık pozisyon varken uygulamayı kaldırırsa ne olur? Para başka bir yoldan (seed, borsanın sitesi) erişilebilir kalır mı, yoksa kaybolur mu? - **E2.** Cihaz çalınırsa hırsız ne yapabilir? Seed, cihazın biyometrisi/kimlik bilgisiyle korunuyor mu? Ekran ekran görüntüsüne karşı korumalı mı? - **E3.** Uygulamanın hâlâ bakiyesi olan bir cüzdanı sildiği veya bakiyeli bir cüzdanı (bakiye okuma hatası nedeniyle) "boş" saydığı bir yol var mı? - **E4.** Borsa hizmet dışıysa, bağlantı bir emrin ortasında koparsa veya yanıt kaybolursa ne olur? Uygulama bir emri çiftleyebilir, bir tahsilatı çiftleyebilir veya tutarsız bir durumda kalabilir mi? - **E5.** Açık pozisyon varken süreç sistem tarafından sonlandırılırsa stop loss borsada geçerli olmaya devam eder mi? Uygulama geri döndüğünde uzlaştırma yapıyor mu? --- ## 3. Otomatik RED tetikleyicileri Aşağıdaki maddelerden **herhangi biri** doğruysa, geri kalan ne kadar iyi olursa olsun karar **REDDEDİLDİ** olur: 1. Fon varış yerinin **beyan edilen modelle uyumsuz** olması (koda gömülü sabit saklama adresi, kullanıcıya veya ağ verisine göre yönlendirme yok) — yani: çalışma zamanında hesaplanan varış yeri, ağdan gelen adres veya yapılandırmayla varış yerini değiştirebilen bir yol. 2. Seed/özel anahtarın ağda, günlükte, yedekte veya harici dosyada olması — herhangi bir yolda. 3. İşlevsel gerekçesi gösterilmemiş erişilebilirlik izni, cihaz yöneticisi, paket kurulumu veya ekran kaplaması. 4. Ağdan gelen dinamik kod yükleme. 5. Politikada beyan edilmemiş telemetri, analitik veya tanımlayıcı toplama. 6. Yeniden üretilebilir herhangi bir senaryoda aynı para yatırma işlemi için ücretin iki kez alınması. 7. Her iddia için `dosya:satır` kanıtı olmadan "onaylandı" diyen rapor. 8. Müşteriyi memnun etmek için var olan bir bulgunun atlanması. --- ## 4. Raporun zorunlu biçimi ``` 1. KARAR: ONAYLANDI | ÇEKİNCEYLE ONAYLANDI | REDDEDİLDİ + ciddiyet bazında sayım (kritik / yüksek / orta / düşük / bilgilendirici) 2. DOĞRUDAN YANITLAR (tablo: soru | yanıt | kanıt) 2b. BEYAN EDİLMİŞ TASARIM KARARLARI (DD1–DD4) her biri için: ne doğrulandı (dosya:satır) | beyan edildiği gibi uygulandı mı? | kullanıcı için etki | kabul edilen risk 3. BULGULAR (madde başına bir tane): - ID, ciddiyet, başlık - Kanıt (dosya:satır veya komut + çıktı) - Kullanıcı için somut etki - Önerilen düzeltme - Neyin doğrulanamadığı 4. SINIRLAMALAR: denetimin kapsamadığı şeyler ve nedeni 5. YENİDEN ÜRETİM: herkesin doğrulamayı yeniden yapması için komutlar ve adımlar 6. İNCELENEN İKİLİ DOSYA VE KAYNAK: commit, sürüm, APK SHA-256, sertifika parmak izi, çalıştırma tarihi/saati ``` --- ## 5. Son kural Müşteriyi memnun etmek için bir bulguyu gizleyen rapor, hiç rapor olmamasından daha kötüdür: para yatıracak kişiye sahte güven aktarır. Kod vaadi taşımıyorsa söyleyin — ve nerede taşımadığını söyleyin.