Lityum iyon bataryalar ve şarj edilmeleri

Akıllı telefonların insan uzuvlarından biri haline gelmesi ile birlikte lityum iyon bataryaların şarjları da en çok konuşulan konulardan birisi oldu.

Kısa bir bilgi; batarya, İngilizcedeki battery kelimesinden geldiği için aslında Türkçe'deki karşılığı pil. Kavramsal olarak şarj edilebilen piller de olduğundan garip gelmesin, akıllı telefonunuzun içindeki de şarjlı pilden başka birşey değil. Ayrıca o pilin tekrar kullanılmak üzere doldurulması işlemi de yine İngilizce'deki (ya da Fransızca'daki) charge kelimesinden geldiği için şarj şeklinde dilimize girmiş durumda. Bunun için şarz gibi bir telaffuzdan kaçınmak gerek.

Şarj olurken patlayan telefonlar [1], durup dururken alev alan bataryalarla [2] ilgili haberler bir süredir herkesin aklını karıştırıyordu. Üstüne üstlük üreticilerin de ürün kitapçıklarında "orijinal şarj cihazından başka cihaz kullanmayın" uyarısı da insanların korkularını bir üst seviyeye taşımıştı.

Şükür ki şu yazı benim kafamdaki soru işaretlerimi belli bir seviyede giderdi. Bu yazıya göre:

- Başka markaların şarj cihazları bataryanıza zarar vermez. Şarj etmek için en iyi seçim olmayabilirler (zaman olarak) ama yine de bir zarar söz konusu değil. Tek koşul, güvenlik ölçütlerini hiçe sayan korsan markalardan kaçınmak. Güvenilir herhangi bir markanın şarj cihazını kullanabilirsiniz.

- Telefonu şarjdayken kullanmanın kimseye bir zararı olmaz. Şarjdaki bir telefonu kullanırken kötü bir deneyimi olan kişilerin merdiven altı şarj cihazları kullandıkları belirtilmiş.

- Telefonu gece boyunca şarjda bırakmakta bir sakınca yok. Ama bu her gece telefonunuzu şarjda bırakmanız gerektiği anlamına da gelmiyor. Hatta bataryanızın %40 ile %80 arasına tutmanın batarya ömrünü de artıracağı belirtilmiş. Yani telefonun şarjını tam bitirip sonra da tam (%100) doldurmak yerine %40-%80 aralığında kullanmak batarya ömrüne olumlu bir katkıda bulunuyor.

- Telefonunuzu ara sıra kapatmak gerek. Bu zaten üzerinde bir yazılım koşan tüm cihazlar için geçerli. Her yazılım belli bir periyotta sıfırlanmalı. Telefonlar da bir istisna değil. Haftada bir kapatın, açın. Bu sayede batarya ömrünüzün de artabileceği belirtilmiş.

Daha fazlasını isteyenler için batteryuniversity.com sitesinde güzel bilgiler de var.

[1] http://www.ntvmsnbc.com/id/25455117/

[2] http://www.ntvmsnbc.com/id/25454332/

Ubuntu'da tam ekran olmayan videolarım

Ubuntu 14.04'te Firefox ile facebook videolarını izlerken tam ekran yapamıyordum. Ne büyük sıkıntı! Ama çözümü varmış!

Şu adresteki gibi uzmanlara hayranım. Hem devilspie gibi bir paketi bileceksin, hem soruna göre uyarlayacaksın, hem de bunu askubuntu'da paylaşacaksın.

Neyse, çözüme geçelim. Bunun sebebi Firefox'un plugin-container prosesinin gıcıklık yapmasından kaynaklanıyormuş. Önerilen çözüm, devilspie gibi istenen pencerenin istenen şekil, konum ve boyutta başlamasını sağlayan bir araç ile her başladığında fokus almasını sağlamakmış. Buna göre önce devilspie'ı yüklememiz gerekiyor.

sudo apt-get install devilspie

Ardından kullanıcı profilinin altında bir klasör oluşturarak bu klasörün içinde bir ds dosyası yaratmak.

mkdir ~/.devilspie
cd ~/.devilspie
nano flash-fullscreen-firefox.ds

Son komuttan sonra boş içerikle nano açılacak. Nano'nun içine şunları yazmak gerek:

(if
(is (application_name) "plugin-container")
(begin
(focus)
)
)

Bundan sonra plugin-container prosesinin sonlandırmak ve tekrar video izleme girişiminde bulunmak gerekiyor.

Devilspie'ın her oturum açışta başlamasını sağlamak içinse gnome-session-properties'e yeni bir giriş yapmak gerek. (alt+f2'ye gnome-session-properties yazıp /usr/bin/devilspie'ı ekleyebiliriz)

Mutluluk!

Google Chrome 64 bit

Açık kaynak kodlu Chromium browser'ın 64 bitlik sürümünün piyasaya çıkışının ardından bu projenin üzerine kurulan Google Chrome'un da 64 bitlik sürümü yayınlandı. Şu ve bu adreste belirtildiği gibi 64 bitlik Chrome'un performansları, 32 bitlik kardeşine göre pek parlak değilmiş.

Emektar Firefox'u, son zamanlarda yaptığı birkaç hatadan ötürü kısa bir süreliğine dinlenmeye aldım. Ama Chrome o kadar cazip ki bir türlü geri dönemiyorum Firefox'a. Bu arada Firefox da hala resmi kararlı 64 bit sürümüne sahip değil. Waterfox projesi güzel ama güncellemeler eş zamanlı gelmiyor. Mozilla Vakfı'nın uzantıların uyumlu olmaması sebebiyle 64 bitlik sürüm yayınlayamadıklarına dair mazereti de Waterfox tarafından çürütüldü bu arada. Waterfox'ta benim denediğim uzantıların tümü sorunsuz çalışıyor.

Neyse, konu dağıldı yine. İnternette doğrudan 64 bitlik sürümü indirmek için bir bağlantı bulamıyordum, şimdi buldum paylaşıyorum.

https://www.google.com/chrome/browser/?platform=win64

Goolge Chrome Hakkında menüsünü kullanarak (chrome://help) 64 bit kullanıp kullanmadığınızı anlayabilirsiniz [1].

[1] http://superuser.com/questions/803748/how-can-i-tell-if-i-have-google-chrome-64-bit-installed

vsepflt'nin sebep olduğu BSoD durumları

Sanal sunucularımızdan bazılarında periyodik mavi ekranlar (BSoD) görülüyordu. Neredeyse düzenli olarak 30 günde bir gerçekleşen bu olaylarda WinDbg hep vsepflt.sys sürücüsünü suçlu olarak buluyordu. Neden sunucuların bazılarında gerçekleştiği ve neden 30 günde bir olduğu bu yazının konusu değil maalesef.

!analyze -v ile de sonuç değişmedi; suçlu vsepflt.sys. Bu dosya, VMware Tools'un vSphere Endpoint Security dosyası. Varolma sebebi virüs taraması konusunda host işletim sistemi ile veri alışverişinin yapılması. Ama sanal makinede bir antivirus yazılımı varsa ve bu antivirus yazılımının da benzer bir minifilter dosyası varsa bu ikisi iyi geçinemiyor. Bu durumda birinin devre dışı kalması lazım. Benim çözümüm vsepflt'yi devre dışı bırakmaktan yana.

İki seçenek var. Birincisinde VMware Tools'u kaldırmak ve kurarken Custom'ı tıklayarak seçeneklerden vsepflt'yi (VMCI Driver>vShield Drivers) hariç bırakarak kuruluma devam etmek.

Eğer söz konusu sanal makineyi kapatmak bir seçenek değilse o zaman aşağıdaki adımları izleyebiliriz. Önce yönetici haklarına sahip bir komut satırı açmak ve 

fltmc unload vsepflt

komunut vermek lazım. Bu komutla yüklenmiş minifilter driver'ını devre dışı bırakıyoruz. Bundan sonraki açılışlarda tekrar yüklenmesini engellemek içinse

HKLM\SYSTEM\CurrentControlSet\Services\vsepflt

anahtarının altındaki Start değişkenininin değerini 4'e eşitlemek lazım.

Ben bu adımları denerken fltmc unload vsepflt'den sonra başka bir mavi ekran ile karşılaştım.

Dolayısıyla birinci yöntemi seçerek sunucuları paşa paşa kapatmak zorunda kaldım.

[1] http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2082588
[2] http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2034490

[3] http://msdn.microsoft.com/en-us/library/windows/hardware/ff549689%28v=vs.85%29.aspx

[4] http://blogs.msdn.com/b/ntdebugging/archive/2013/03/25/understanding-file-system-minifilter-and-legacy-filter-load-order.aspx

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!

Windows Debugging with WinDbg

Windows'un mavi ekranını (Blue Screen of Death, BSOD) görmeyen yoktur herhalde. Her ne kadar sonuç olarak bizi bilgisayar başındaki işimizden alıkoyduğu için mavi ekranlardan nefret etsek de, çoğumuz belki de aslında bizim hayatımzı kurtardığının farkında değilizdir. "Birşey" (ne olduğu bu yazının konusu) arka tarafta Windows'un kurallarına uymadığı için, işletim sisteminin çalışmasına devam etmesi, belki de veri kaybına (ki bu zaten kaçınılması gereken yegane sondur) sebep olabileceğinden, işletim sistemi acil olarak çalışmasını durdurur, biz de tam bu anda mavi ekranı görürüz.

Elbetteki bu durumun tekrarlamamasını sağlamamız gerekir. Bu amaçla arka planda neyin olup bittiğini incelemek için kullanabileceğimiz bir araç var: WinDbg.

Öncelikle nasıl indirilebilir, onu yazalım. Microsoft, her Windows sürümü için bir SDK kiti yayınlıyor. Performans araçlarından hata bulmaya kadar birçok aracı içeren bu kit, Google'da "Windows SDK" aramasıyla bulunabilir. Ben Windows 8.1 için aradığım için "Windows SDK 8.1" araması yaparak şu sayfaya ulaştım.

Burada aşağıda görülen "Install and download" bağlantısını tıklayarak installer'ını indirebiliriz. Bu da aslında installer for installer. Yanı kurulumu yapacak dosyaları indirecek kurulum dosyası. Çalıştırdığımızda bir sürü seçenek arasından hangilerini istediğimiz sorulacak. Windbg için sadece Debugging tools for Windows'u seçmemiz yeterli. Bu aşamada internetten 600 MB'a kadar veri indirilebilir. Bundan sonra indirilen dosyaların arasından Debugging Tools'a ait olan kurulum dosyaları çift tıklanarak kurulmalı. Bu adımlar tamamlandığında Windbg kurulmuş ve başlat ekranında/menüsünde bir kısayol yaratılmış olur.

Andrew Richards'ın Channel9'daki sunumunda bazı özel ve güzel ayrıntılar verilmiş.  Örneğin dmp gibi dosyalarla WinDbg'yi ilişkilendirmek için

windbg -IA

kullanılabilir. Bunun sonucunda HKEY_CLASSES_ROOT altında WinDbg.DumpFile.1 adında yeni bir anahtar yaratılır. Bu anahtar, sunumda da belirtildiği şekilde aynı makinede hem x86 hem de x64 programların debug edilebilmesi için özelleştirilebilir.

Bir de post mortem debugger olarak ayarlama konusu var. Bunun için de

windbg -I

komutu hem x86 hem de x64 sürümler için kullanılmalı.

Mavi ekran oluştuğunda Windows, bir bellek dökümü oluşturur. Bu bellek dökümü %SystemRoot%\MEMORY.DMP dosyasında ya da %SystemRoot%\minidump klasöründe bulunur. İşte WinDbg, bu bellek dökümü dosyalarını açarak en son mavi ekran anında neler olduğunu incelememizi sağlayan bir araç. Windbg'ı kullanmanın en büyük zorluğu uygun komutu bularak bu bellek dökümü dosyasını açmak (Mark Russinovich'in sözü). Windbg'ı çalıştırıp File menüsünden Open Crash Dump... (Ctrl+D) ile bu bellek dökümünü açabiliriz. Aşağıda örnek olarak Windbg ile açılmış bir bellek dökümünün ekran görüntüsü var.

Alttan ikinci satırda hatanın muhtemel sebebi belirtilmiş:

Probably caused by : avgntflt.sys ( avgntflt+17623 )

Önerildiği gibi

!analyze -v

komutunu kullanarak Windbg'ın crash dump dosyasını analiz ederek bize en son şüpheliyi söylemesini de isteyebiliriz. Bu komuttan sonra ekranda şöyle bir görüntü olacak.

Şüpheli değişmedi. Eğer sadece yukarıda yazan bilgiye erişmek isteseydik Nirsoft'un BlueScreenView programını da kullanabilirdik.

Evet, burada da "The problem seems to be caused by the following file: avgntflt.sys" diyor. Burada karar verme süreci şöyle işliyor: Windbg hatanın olduğu anda en son hangi prosesin kodlarının işletildiğine bakıyor. En son Microsoft olmayan prosesi suçlu kabul ediyor (Russinovich'in sözü). Cümlelerin kuruluşundan da anlaşılabileceği gibi bu nihai karar değil. Daha ayrıntılı incelemek gerek. Ama daha ayrıntılı bir analiz yapmadan önce bu sonuçları bir değerlendirmek gerek. Öncelikle hataya sebep olan bileşenin yeni sürümü var mı, kontrol etmeli. Varsa yenisini yüklemeli. Bu mümkün değilse ve kullanılmıyorsa bu bileşenden kurtulmak denenmeli. Bunların hiçbirisi fayda etmiyorsa bu durumda bazı ileri teknikler kullanmak gerekir. Bunları da başka bir yazının konusu.

---

Microsoft dll ve exe dosyaları için sembollere ihtiyaç duyulması durumunda kullanılacak sembol dizesi:

srv*c:\symbols*http://msdl.microsoft.com/download/symbols

olabillir. Ya da ortam değişkeni olarak %_NT_SYMBOL_PATH% içeriğini yukarıdaki dizeye eşitleyebiliriz. İkisi de aynı etkiye sahip.

TİB IP log imzalayıcı - ince ayrıntılar

Yakın zamanda işim düşünce biraz inceleme fırsatı buldum. Log'ları imzalamak için Windows ortamında ihtiyaç duyulan aracı Telekomünikasyon İletişim Başkanlığı geliştirmiş, web sitelerine koymuş. Programı kurdum, ama bir güvenlik duvarının ardında çalışmasını anlamak biraz zaman aldı.

Programın kurulumu gayet basit. Kurulum sırasında sadece programın hangi klasöre kurmak istediğimiz soruluyor. Kurulum klasörünün altında da signed_files klasörü vardır ki bu klasöre imzalanan log dosyaları konur. Bu klasörün yeri sonradan değiştirilemiyor. Bu sebeple planlamayı baştan yapmak gerek. Tüm imzalanan log dosyaları buraya konacağı için yer kaplayacaktır.

Program kurulduktan sonra belli bir klasörü izleyerek gelen log dosyalarını imzalayacak. İzlenecek klasör programın grafik arayüzü aracılığıyla değiştirilebiliyor. Gelen dosyaların imzalanması için de 3 seçenek var; dosyalar kopyalanır kopyalanmaz, her gün aynı saatte ya da 1 saat aralıklarla.

Programın iki bileşeni var. Birincisi Windows'da oturum açtığınızda çalışan client.exe (ki sistem tepsisindeki ikondan da bu sorumlu), diğeri de bir Windows hizmeti olarak çalışacak olan service.exe. Bir kez ayarlar yapıldıktan sonra client.exe'nin çalışır durumda olmasının (ya da sistem tepsisindeki simgenin gözükmesinin) bir gereği yok. Zamanlamayı yapan da, imzalama işlemini gerçekleştiren de service.exe. Bu Windows hizmetinin çalışır durumda olması gerekli.

Sıra geldi en büyük soruya. "İnternet zamanı alınamadı. Dosyalar imzalanmayacak" diye hata!

Bu hata, programın internetten geçerli zamanı alamadığını ve bu sebeple imzalama işleminin gerçekleşmeyeceğini söylüyor. Kontrol edince söz konusu bilgisayardan SNTP veya NTP bağlantısının yapılabildiğin görüp şaşırmıştım. TİB'in kendi dökümantasyonununda programın NTP'yi kullandığı söyleniyor [1]. Ama UDP 123 yerine TCP 37 kullanılıyor ki bu da eski Time Protocol [2].

Bir de imzalama işleminin nasıl olduğundan bahsedelim; C:\islenen_log klasörüne bir şekilde düşen log dosyaları için bir zaman damgası oluşturuluyor. Bu zaman damgası ile log dosyasının kendisi daha sonra signed_files'in içindeki ilgili alt klasöre taşınıyor. Burada ikisi birlikte saklanıyor. Bu klasördeki log dosyaları imzalanma sonrasında hala bir metin editörü ile görüntülenebilir durumda oluyor, ama dosyayı sakın değiştirmeyin. Böyle bir durumda oluşan zaman damgası geçerliliğini kaybeder. Tekrar oluşturmak gerekir, o da log dosyasının haricen bir müdahaleye maruz kaldığını gösterir.

Program, zaman bilgisini almak için, programın içine sabit olarak yerleştirilmiş aşağıdaki sunuculara başvuruyor.

utcnist.colorado.edu
time-a.nist.gov
time-b.nist.gov
time-a.timefreq.bldrdoc.gov
time-b.timefreq.bldrdoc.gov
time-c.timefreq.bldrdoc.gov
time.nist.gov
time-nw.nist.gov
nist1.symmetricom.com
nist1-dc.WiTime.net
nist1-ny.WiTime.net
nist1-sj.WiTime.net
nist1.aol-ca.symmetricom.com
nist1.aol-va.symmetricom.com
nist.expertsmi.com

İnternet zamanını alabilmek için sırayla bu 15 sunucu denenmeye başlanır. Her bir sunucu için cevap zaman aşımı 20 sn. 15x20 = 300 sn (5 dakika) yapar. Yani program internet bağlantısını yapamaması durumunda 5 dakika sonra hata verir ki bu da garip bir durum.

Yapılan işlemlerle ilgili günlük log, signed_files klasörünün altındaki günlük alt klasörlerin içindeki mechanism.log dosyasında tutulur.

Ek@2021-10-14: Uzun lafın kısası, program internetten zaman bilgisi alamadığı için bu hatayı veriyor. Zaman bilgisinin alınamamasının her sistemde farklı çözümü olabilir. Güvenlik duvarı üzerinden erişime izin verilmesi gerekebilir. Ama dikkat edin, UDP123 portuna değil TCP37 portuna izin vermek gerek. Yukarıdaki sunuculara ulaşmaya çalışıyor, hiçbirine ulaşmayıınca da 5 dakika kadar sonra hata mesajı görüntüleniyor. İmzalanan loglar signed_files klasörüne taşınıyor. Bu dosyalarla aynı klasöre, aynı isimle ama uzantısı .imza olan dosyalar oluşturuluyor. Bu log dosyalarının belirtilen saatten sonra değiştirilmediğine dair oluşturulan zaman damgası var içinde. İmzalanan dosyalar üzerinde bu aşamadan sonra değişiklik yapılmaması için hiç açılmaması önemle tavsiye olunur.

[1] http://www.tib.gov.tr/tr/tr-menu-47-internet_icerik_duzenlenmesi_hakkindaki_sorular.html, soru 37
[2] http://en.wikipedia.org/wiki/Time_Protocol

Türk halkının TCP/IP ile imtihanı

Başlık benim değil, manlyphall adlı ekşisözlük yazarının :)

Artık her yaştan internet kullanıcısı DNS değitşrimenin ne demek olduğunu ve ne işe yaradığını öğrendi bu ülkede.

İnternet servis sağlayıcımızın kendi DNS sunucularında yasaklanan URL'ler için gerçeğin dışında bir yönlendirme yapması durumuna karşı bizim de genel kullanıma açık diğer DNS sunucuları kullanarak bu yasakları aşmamıza karşı geliştirlen bir teknik var. Bu teknik uzun zamandır kötü niyetli hacker'lar tarafından kullanılmaktaydı. Hayırlı olsun, şimdi artık bizzat hükümet destekli kendi internet servis sağlayıcılarımız tarafından kullanılıyor.

Uzun zamandır bir dedikodu halinde konuşulup yazılıyor. Bir taraftan "Yuh artık, bu kadarı da yapılmaz herhalde" derken geçtiğimiz günlerde karşlaştığım trace route sonuçlarına bakınca inanmak istemedim bi süre. Sonra acı gerçeği kabullendim.

Yeni internet düzenlemelerine göre yasakları uygulamanın sorumluluğu internet servis sağlayıcılara yüklenince, onlar da youtube'u yasaklamak için kendi içlerinde "fake" DNS sunucular kurmuşlar. Bunlara da popüler OpenDNS, Google DNS gibi DNS sunucuların IP adreslerini  vermişler. Kendi ağlarından gelen bütün trafiği bunlara yönlendirmişler, çakallar!

Diğer ülkelerdeki internet servis sağlayıcıların yaptığı gibi var olmayan adreslerin için reklam dolu sayfalara yönlendirme değil amaç; daha çok yasağı uygulama, belki de kayıt altına alma.

Ben de bu durum üzerine kullandığım DNS sunucunun gerçek mi, yoksa sahtesi mi olduğunu nasıl anlayabilirim diye düşünmeye başladım. DNS sorgularına dönülen cevaplardan bir sonuç çıkarmak imkansız. IP adresini verip coğrafi konumunu sorgulamak da anlamasız, çünkü bu haricen statik bir veritabanından sorgulanıyor.
Ping sonuçları çok az bilgi veriyor (aslıda [3]'te söylendiği gibi korsan bir DNS sunucu, normal sunucuya kıyasla çok daha hızlı cevap verecektir; ama bu kesin bir sonuç değil). Bunun yerine trace route çıktıları faydalı olabilir. Trace route, belirtilen hedefe kadar geçilen her router'a gönderilen ICMP paketlerinin sonuçlarını gösteriyor. Yolumuzda bazı noktalardan cevap alamıyor olabiliriz, ama en azından yol bize bir bilgi verecektir.

Benim aldığım bir örnek aşağıdaki gibi:

C:\>tracert -d 8.8.4.4

Tracing route to 8.8.4.4 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  xxx.xxx.xxx.xxx
  2     1 ms     1 ms     1 ms  xxx.xxx.xxx.xxx
  3     1 ms     1 ms     1 ms  xxx.xxx.xxx.xxx
  4     6 ms     2 ms     1 ms  xxx.xxx.xxx.xxx
  5     2 ms     2 ms     1 ms  xxx.xxx.xxx.xxx
  6     9 ms     9 ms     8 ms  81.212.217.225
  7     8 ms     9 ms    11 ms  81.212.197.62
  8    29 ms    27 ms    31 ms  72.14.217.118
  9    27 ms    26 ms    26 ms  72.14.235.39
 10    33 ms    33 ms    33 ms  8.8.4.4

Trace complete.

Burada önemli olan hedeften birkaç adım öncesi. Mesela yukarıdaki örnekte 72.14 ile başlayan IP adresleri. Bunların konumlarını sorgulamak için Nirsoft'un IPNetInfo aracını kullandım ben.

Yukarıdaki örnekte trace route işlemi 81.212 ile başlayan TTNET router'larından sonra 72.14 ile başlayan Google'a ait IP adreslerine, oradan da 8.8.4.4 hedefine ulaşmış. Bu örnekte DNS sunucumuz temiz gözüküyor. Elbette internet servis sağlayıcımızın sadece hedef IP'sini (yani 8.8.4.4'ü) kopyaladığını, diğer Google IP'lerini (72.14 ile başlayan diğer noktalar) kopyalamadığını (fake olarak) varsayıyoruz. Bunu yapıyor olsaydı eminim Google'ın bir sürü hizmeti Türkiye'den erişilmez olurdu.

Ama örneğin şu bağlantıda anlatılan durumda 81.212 ile başlayan TTNET adreslerinden hemen sonra bir 8.8.8.8 hedefine ulaşılmış. Yani şöyle olmuş:

C:Usersxxx>tracert -d 8.8.8.8

Tracing route to 8.8.8.8 over a maximum of 30 hops

 1     87 ms     1 ms     1 ms  192.168.2.1

 2     11 ms     8 ms     9 ms  xxx.xxx.xxx.xx

 3     11 ms     9 ms     9 ms  xxx.xxx.xxx.xx

 4     *        12 ms    10 ms  xxx.xxx.xxx.1xx

 5     12 ms    10 ms    10 ms  81.212.25.72

 6     20 ms    19 ms    20 ms  81.212.204.205

 7     26 ms    21 ms    22 ms  81.212.219.209

 8     20 ms    18 ms    18 ms  8.8.8.8

Trace complete.

İşte bu DNS sunucusundan şüphe etmek lazım. Google'a ait hiç bir adrese uğramadan doğrudan 8.8.8.8'e gitme şansımız yok. Buna bir kez ben de şahit oldum, ama sonuçlarını kaydedemediğim bir durumdu. Bu sebeple jiyan.org'dan alıntı yaptım.

Bu durum benim veya birkaç kişinin farkettiği bir şey olmaktan uzak. Gayet iyi bir şekilde, üstelik de neredeyse yapılır yapılmaz otoriteler tarafından farkedilmiş ve belgelenmiş [2,3].

Gördüğüm kadarıyla bu işin başlangıcı 29 Mart 2014'e kadar gidiyor.

[1] https://eksisozluk.com/entry/41564376
[2] http://www.bgpmon.net/turkey-hijacking-ip-addresses-for-popular-global-dns-providers/
[3] http://www.renesys.com/2014/03/turkish-internet-censorship/

NTFS birimi ne zaman yaratılmış

Bilgisayarlarla uzun zaman geçirmemin bir sonucu olduğunu düşünüyorum, herşeyin bir log dosyasının olması gerektiğini düşünmemin. Hatta gerçek hayatta bile bazı şeylerin logu otomatik olarak tutuluyor olsaydı, süper olurdu.

Linux'ta bir ext3 disk bölümünün ne zaman yaratıldığını şurada da anlattığım gibi tune2fs aracıyla bulabiliyoruz. Bunu Windows'da NTFS sürücüler için yapabilir miyiz diye ararken şu sonucu buldum. Sistem sürücüsü için bunun yerine systeminfo komutunu kullanabiliriz. Ama harici bir disk için? İşte sorunun cevabı.

Güzel haber olarak ZwQueryVolumeInformationFile() Windows API'si ile bu bilginin sorgulanabildiği, 5. parametre olarak FileFsVolumeInformation sağlanması halinde FILE_FS_VOLUME_INFORMATION tipinde bir veri döndüğü ve bunun da içinde birim etiketi, seri numarası ve yaratılma tarihi olduğu söylenmiş.

Ama kötü haber: bu veriyi okuyabilecek bir program yazılmamış. Ancak JdeBP adlı kullanıcı, bu bilgiyi meşhur sysinternals aracı Process Monitor'ün okuduğu onca bilginin arasında bu bilgiyi de listelediğini söylemiş.

O halde bu veriye ulaşmak için yapılacaklar şöyle:

1. procmon /noconnect ile Process Monitor başlatılır. noconnect anahtarı başlar başlamaz veri yakalamamasını söyler.
2. İlk olarak Ctrl+L ile "Filter" diyaloğu açılır. Burada varsa eski süzgeci sıfırlamak için önce Reset tuşuna basılabilir. Ardından

Operation=QueryInformationVolume

süzgeci girilir.


Tercihen Filter menüsünden de "Drop Filtered Events" seçilerek ilgi alanımız dışında yakalanabilecek olayların saklanmaması da sağlanır ve Capture komutu (Ctrl+E veya büyüteç sembolü) verilir.
3. Ardından bilgisayarda sürücülerin harfleri tıklanarak birkaç gezinme yapılır, kök dizindeki dosyalar listelenir. Olmadı, cmd ile terminal açılır, istenen sürücü için dir komutu kullanılır. Bu arada Process Monitor'e veriler düşmeye başlar.
4. Düşen verilerin içinde Detail sütununda VolumeCreationTime bilgisine bakılır. Aranan veri buradadır.