pstools araçlarıyla ilgili sorun

Eski Windows XP günlerinden beri severek kullandığım pslist, pskill gibi Sysinternals komut satırı araçlarının uzak bilgisayarlar üzerinde çalışırken bazen

Cannot connect to remote registry on computername:

The network path was not found.

Failed to take process snapshot on computername.

Make sure that the Remote Registry service is running on the remote system, that you havefirewall ports allow RPC access

, and your account has read access the following key on the remote system:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Perflib

hatası ile çalışmayı reddetmesinin arkasıda çok basit bir sebep var. Windows XP'den beri varsayılan olarak otomatik çalışır durumda gelen Remote Registry (Uzak Kayıt Defteri) hizmetinin yeni Windows sürümlerinde Manuel olarak gelmesi. Bu hizmetleri uzaktan çalıştırabilirsek araçlarımız sorunsuz çalışıyor. Örneğin uzaktaki bir bilgisayarın Uzak Kayıt Defteri hizmetini çalıştırmak için şu komut kullanıyorum.

psservice \\bilgisayar-adi start RemoteRegistry

Windows 8 ile birlikte bu hizmet, Trigger Start olarak geliyor. Bu da, gerektiği durumlarda çalışabiliyor olması demek. Ama daha önceki Windows sürümlerinde manuel'di. Yani elle müdahale ile çalıştırılabiliyordu.

Trigger start ile biraz uğraştım. Örneğin Windows 8'de remoteregistry hizmetinin tetikleme koşulu şöyle:

C:\>sc qtriggerinfo remoteregistry
[SC] QueryServiceConfig2 SUCCESS

SERVICE_NAME: remoteregistry

        START SERVICE
          NETWORK EVENT                : 1f81d131-3fac-4537-9e0c-7e7b0c2f4b55 [NAMED PIPE EVENT]
            DATA                       : winreg

Amacım bu tetiklemeyi Windows 7 bilgisayarlara da uygulamaktı. Burada 1f81d131-3fac-4537-9e0c-7e7b0c2f4b55 ile geçen bir UUID (universally unique identifier) çoğu durumda bir ETW logunun UUID'si oluyordu. Windows 8 ve Windows 7 bilgisayarlarda mevcut ETW'lerin UUID'lerini inceledim, ama eşleşme bulamadım.

C:\>logman query providers | find /i "1ce20aba-9851-4421-9430-1ddeb766e809"

Şu adreste denmiş ki, remoteregistry hizmeti için tetikleme bağlantısını kaldırmak için şu komut yeterli:

sc triggerinfo "remoteregistry" delete

Eğer istenirse bu tetikleme tekrar şu komutla devreye alınabilir:

sc triggerinfo remoteregistry start/namedpipe/1f81d131-3fac-4537-9e0c-7e7b0c2f4b55

Çok güzel, peki bu komutu Windows 7'de çalıştırabiliyor muyuz? Tabi ki hayır. O UUID her neyse, Windows 7'de hiçbir şeye tekabül etmiyor.

Google Şeffaflık Raporu

Google 6 ayda bir Şeffaflık Raporu yayınlıyor. Bu raporda, dünydaki bütün devletlerin Google'a yaptığı özel istekler ve sansürler talepleri var. Gelen talepler, Google'ın hizmet politikalarına  göre bir değerlendirmeden geçirilip kendi iç karar verme mekanizmalarına göre talep yerine getiriliyor veya reddediliyor. Göze çarpan yüksek rakamlar şöyle:

Ülke	Talep sayısı
ABD	438
Brezilya	237
Türkiye	184
Almanya	96
Birleşik Krallık	46

Türkiye ile ilgili yapılan açıklamada ise şöyle denmiş:

Truecrypt öldü mü? BitLocker kaldı mı?

Truecrypt'in www.truecrypt.org olan sitesi truecrypt.sourceforge.net sitesine yönlendiğinde ve ekranımda da "Dikkat: Truecrypt güvenli değil, çünkü kapatılmamş güvenlik açıkları olabilir" yazdığında çok şaşırdım. Ekrandaki yönlendirmelerin de yolu Windows BitLocker'a çıkarmasının ardından şaşkınlık bir kat daha artı. Proje sonlanmış, üstüne üstlük bir de sonlanma sebebinin Microsoft'un Windows XP desteğini kaldırması olduğu söyleniyordu. Peh!

Truecrypt, açık kaynak kodlu bir şifreleme yazılımıydı. Pek çok insan tarafından güveniliyordu. Sonradan öğrendim ki geliştiriciler anonim kalarak isimlerini ifşa etmek istememişler. Ama son zamanlardaki devletler seviyesindeki güvenlik soruşturmalarının ucu taa Truecrypt'e kadar dayanmış. Gelişitiriciler de bir sebepten projeyi sonlandırmak zorunda bırakılmış. Bu senaryolardan birisi.

Başka bir senaryoya göre web sitesi hacklendi, proje sonlandırıldı, haklarına el konuldu. Buradaki hacklenme işi öyle beyaz şapka/siyah şapka falan değil, bizzat devletin yumruğu! Bu sebeple geliştiricilerin ABD sınırları içinde faaliyet gösterme şansı kalmamış olabilir.

Truecrypt, hiç bir denetleme ve güvenlik incelemesinden geçmemiş bir araçmış. Ama buna karşılık BitLocker, çeşitli denetlemelerden geçmiş. Yanlış anlaşılmasın; bu BitLocker'ın daha güvenli olduğu anlamına gelmiyor. Uzun hikaye, merak eden biraz okusun.

Nihayet Softpedia sitesinde orijinal geliştiricilerin yeni bir adreste projeyi tekrar hayata geçirecekleri müjdesi verilmiş. Lakin #IsTruecryptAuditedYet ht'de çokça dile getirildiği gibi bir çok kişinin aklına o üstte yazan "Truecrypt güvenli değil" mesajı kalmış olabilir. Eski güveni tekrar kazanmak zaman alır mı?

Yeni proje ile güvenler tekrar kazanılıncaya kadar sourceforge'un sayfasına yönlendirilen sayfadaki yazılımı yüklemememiz öneriliyor. Projenin hiçbir zaman yayınlanmamış 7.2 sürümüne ait dosyada sadece şifrelenmiş birimleri açmak için bileşenler var ve yeni şifrelenmiş birimler oluşturmak mümkün değil. Bunun tamamen kötü niyetli bir yazılım olması ihtimali de var.

Kendini İsviçre'nin güvenli kollarına bırakan orijinal projenin web sayfasında ise eski güzel 7.1a sürüm indirilebiliyor.

[1] https://gigaom.com/2014/05/29/heres-what-you-need-to-know-about-the-sudden-and-mysterious-death-of-truecrypt/
[2] http://bradkovach.com/2014/05/the-death-of-truecrypt-a-symptom-of-a-greater-problem/
[3] http://istruecryptauditedyet.com/
[4] http://www.infosecurity-magazine.com/news/sudden-death-of-free-encryption/
[5] http://www.reddit.com/r/sysadmin/comments/26pxol/truecrypt_is_dead/
[6] http://heathermeeker.squarespace.com/news/2014/7/11/truecrypt-lives-again.html

Nokia bu saatten sonra ne diye Android telefon üretir?

Yıllar önce yolunu Android'den ayırdı. Yemin billah gitti Windows Phone'u tercih etti. O kadar dibe vurdu ki şirketin eski Microsoft çalışanı olan CEO'su Stephen Elop, gitti şirketi Microsoft'a sattı. Bu olay çok konuşuldu. Stephen Elop için truva atı suçlaması bile yapıldı. İşin arkasında büyük paralar, büyük adamlar varken bu gibi şeylerin rastlantısal olarak gerçekleşmesi olasılığına inanmam. Yani bu iş büyük bir planlama işidir.

Nokia gibi büyük bir aktörün sahneden çekilmesinin kimlerin işine geleceğini düşünmek lazım. Google, Samsung ve hatta Microsoft için çok faydalı olduğu kesin. Android'in rekabet edeceği rakip sayısı bir azaldı. Samsung, Nokia'dan boşalan pazarındaki boşluğu seve seve doldurdu. Microsoft da emrine amade kelepir bir telefon üreticisi satın almış oldu.

Nokia'nın Microsoft'a satılmasının ardından bir yıl geçti. Artık Nokia markasının kullanılmaması, Windows Phone adındaki "Phone" kelimesinin düşmesinden, sadece Windows'un kalmasından bahsediliyor. Bu arada da Nokia, Microsoft'a satılmışken Android'li X serisi telefonları pazara sürüyor.

Bununla ilgili olası komplo teorilerini aradım, ama kayda değer bir şeye ulaşamadım. Her yerde, Android'li Nokia'ların piyasaya sürülmesinin arkasında çeşitli sebeplerden bahsedilmiş [1], [2]. Microsoft'un Android dünyasına arka kapıdan girerek Windows Phone estetiğini enjekte etmesinden ve Microsoft servislerinin yaygınlaştırma amacından bahsedilmiş. Eğer Microsoft bunu yapmasaydı başkası yapardı denmiş. Yapsaydı ne olurdu, bilemedim. Bu gibi düşünceler bana fazla iyimser geliyor. Microsoft, yıllardır rekabet halinde olduğu linux çekirdeğini apaçık kullanan bir ürün piyasaya sürecek! Duy da inanma.

Ben farklı bir şeyler olduğunu düşünüyorum. Şu yazımda da bahsettiğim gibi, ABD gizli servisi, tüm dünyanın elektronik haberleşmesini dinlediğini yalanlamamış, bunları vatandaşlarının aleyhine değil, ABD firmalarının lehine kullandığını itiraf etmişti.

Şimdi elimizde bu bilgi varken, Google ile Microsoft'un gizli bir ittifak yapıp Nokia'yı devirmiş olması çok uçuk bir senaryo gibi gelmiyor bana. Ama aralarında ne gibi bir anlaşma olduysa Google, Microsoft'u kendine borçlu bırakıp, Android'li bir telefon üretmek zorunda bırakmış olabilir. Microsoft da "Tamam, üretirim. Ama Android'i kendi tarzımda özelleştiririm" deyip hiç Android'e benzemeyen, daha çok Windows Phone estetiğine yakın, Google servislerini minimal olarak kullanan, daha çok OneDrive gibi Microsoft servislerini kullanan bir ürün çıkarmış olabilir.

Eğer Microsoft gerçekten söylendiği gibi Android dünyasına Windows Phone estetiği enjekte etme amacıyla çalıyorsa Nokia X serisinden sonra en az bir seri daha Android'li cihaz üretir ve beni daha da şaşırtır. Ya da Snowden veya başka birinin itiraflarında bu tip bilgileri görürüz. Biraz beklemek lazım.

[1] http://www.fastcodesign.com/3026824/why-in-the-world-is-microsoft-owned-nokia-releasing-an-android-phone#4
[2] http://www.bbc.com/news/technology-27992439

Outlook'ta yavaşlama ve takılmalar

Bir kullanıcının uzun süredir Outlook'ta süren şikayetleri ile ilgilenme zamanı buldum. Yavaşlama dediysem aslında ortada bir yavaşlık yok. Daha ziyade takılmalar var. Outlook'u başlatmak dakikalar sürüyor. Gelen bir hatırlatmaya cevap verdikten sonra Outlook penceresi dakikalarca cevap vermiyor.

İşe Process Monitor ile başladım. Oulook 2010'u başlatmadan hemen önce başlattığım capture'ı, pencere tümüyle işlevsel olana kadar sürdürdüm. Toplamda 5 dakikaya yayılan 660.000 olay yakaladı. Bunları bir süzgeç (filter) kullanmadan yakaladığım için, içinde antivirüs yazılımının olayları da var, hiç ilgisi olmayan Windows hizmetlerinin registry erişimleri de. Ama süzgeç kullanınca muhtemel bir bilgiyi gözden kaçırma ihtimali olduğu için böyle kullanmayı tercih ettim.

Yakalanan onca olayı çeşitli süzgeçlerden geçirdim. Önce sadece Outlook.exe'nin yarattıklarını inceledim. Bir çok şüphelim oldu. ost dosyasını mı tarasam, yoksa antivirüs yazılımını mı geçici olarak kapatsam diye düşünürken şüphelilerin bir kısmını eledim. Windows Event Log'da da bulduğum hataların doğrudan olaylarla bir ilişkisi çıkmadı.

Nihayetinde Google'da yaptığım bir aramada, yine Mark Russinovich'in blogunda bahsettiği Process Monitor'de varsayılan olarak gösterilmeyen duration (işlem süresi) alanını göstermeye başlayınca olay çözüldü.

2 saniyeden daha uzun süren işlemleri süzdüm.

Aslında bu süzgeç ile daha fazla olay görüntülenmişti ama ben sonradan olayı netleştirmek için Outlook.exe tarafından üretilen olayları süzdüm. Sonuçta aşağıdaki gibi bir görüntü çıktı ki Outlook nedense pst dosyasını sürekli yeniden yaratmaya çalışıyor ve bu işlemlerin en kısası 12 saniye falan sürüyor.

Orada gözüken pst dosyası ile ilgili bir sorun olduğu belli. Erişimlerin tümünün başarılı olmasına da dikkat! Aslında bir sorun durumunda ilk yaptığım şey SUCCESS yazan olayları ihmal etmek olurdu.

Neyse, pst dosyasını geçici olarak kaldırdığımda Outlook hiç bir takılma olmadan gayet başarılı bir şekilde çalışıyordu. Zaten bu pst dosyası da eski e-postaların arşiviydi ve taa eski zamanlardan kalma, Outlook'un 2002 sürümünde yaratılan UNICODE desteği olmayan bir dosyaydı. Scanpst ile tarayınca hatalar çıktı, hatalar düzeltildi, ama fayda etmedi. Bu sebeple Outlook 2010'da yeni bir pst dosyası yaratıldı, son bir çaba ile eski öğeler yeni pst dosyasına taşındı ve bu pst dosyasının Outlook ile ilişkisi kesildi. Outlook artık yine ilk günlerindeki gibi sorunsuz çalışıyor.

Ne demişler, alet işler el övünür. Keşke bir fırsatını bulabilsem de şu Mark Russinovich'e bir teşekkür edebilsem :)

Google ile vedalaşmak isterseniz

O kadar çok veri birikti ki Google hesaplarımızda, olurda bir gün Google ile yollar ayrılırsa diye herkesin pılını pırtını toplayıp gidebilmesi için bir çözüm bulmuşlar. İlle bizde kalın demiyorlar.

İşte Google hizmetlerinde biriken verilerin arşivinin oluşturulabileceği sayfa:

https://www.google.com/settings/takeout

Şu adreste de durum ayrıntılı anlatılmış. Aslında benzer hizmetler sunan Yandex veya Bing tarafında bu verileri yedekleme şansımız da olsaydı fena olmazdı hani. Disaster Recovery'de son nokta!