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!
2014-09-09
2014-07-22
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.
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.
2014-06-08
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!
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
2014-05-15
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.
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.
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.
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.
2014-04-07
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:
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:
- procmon /noconnect ile Process Monitor başlatılır. noconnect anahtarı başlar başlamaz veri yakalamamasını söyler.
- İ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
- 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.
- Düşen verilerin içinde Detail sütununda VolumeCreationTime bilgisine bakılır. Aranan veri buradadır.
Operation=QueryInformationVolumesüzgeci girilir.
2026-06-30 Ek: Burada anlatılan ZwQueryVolumeInformationFile() yerine NtQueryVolumeInformationFile() fonksiyonu kullanılarak powershell ile bu verilere ulaşan bir yöntem için lütfen tıklayın.
2013-12-09
İnternet reklamları ve izlenebilirlik
Son birkaç gündür bir ayakkabı almak için internette geziniyorum.
Henüz satın almamı gerçekleştirmedim. Bu satın alma amaçlı gezinmelerimden tamamen bağımsız olarak (farklı bir sekmede, diğer sekme kapatıldıktan sonra) bambaşka bir sitede kenar reklamlarında incelediğim ürünlerin resimlerinin olması ilgimi çekti.
Hani bir nevi alış-veriş için çarşıya çıktım, birşeyler baktım. Sonra alış verişimi tamamlamadan oturdum bir yerde birşeyler yiyip içiyorum. O arada garsonun servisle birlikte masaya aradığım ürünlerle ilgilli broşürler bırakması gibi birşey bu. Nerden biliyor bu adam benim az önce nereleri dolaştığımı?
Buna ben bilgisayarımda nasıl izin verdim? Girdiğim alış veriş sitesinin çerezlerini diğer site okuyabilir mi? Hayır. E o zaman demek ki alış veriş sitesi üçüncü parti çerezler (third party cookies) bırakıyor. Demek ki tarayıcımın üzerinden üçüncü parti çerezleri engellemek lazımmış.
Firefox'ta:
Seçenekler>Gizlilik sayfasına gelip, pencerenin "Geçmiş" kısmında "Geçmiş için özel ayarlar kullan" seçimi yaptıktan sonra aşağıda çıkacak olan "Üçüncü parti çerezleri kabul et=Asla" seçimini yapmak gerek.
Chrome'da:
Ayarlar sayfasını açtıktan sonra önce sayfanın altındaki "Gelişmiş Ayarları Göster"i tıklayıp Gizlilik'in altından İçerik Seçenekleri'ni tıklamak gerekiyor. Burada Çerezler bölümünün altındaki checkbox'ı işaretleyerek üçüncü parti çerezleri engelleyebiliriz.
IE:
Internet Seçenekleri'nin Gizlilik sayfasına gelerek Gelişmiş butonuna basarak açılan sayfadan üçüncü parti çerezlerin engellenmesini seçmek gerek.
Henüz satın almamı gerçekleştirmedim. Bu satın alma amaçlı gezinmelerimden tamamen bağımsız olarak (farklı bir sekmede, diğer sekme kapatıldıktan sonra) bambaşka bir sitede kenar reklamlarında incelediğim ürünlerin resimlerinin olması ilgimi çekti.
Hani bir nevi alış-veriş için çarşıya çıktım, birşeyler baktım. Sonra alış verişimi tamamlamadan oturdum bir yerde birşeyler yiyip içiyorum. O arada garsonun servisle birlikte masaya aradığım ürünlerle ilgilli broşürler bırakması gibi birşey bu. Nerden biliyor bu adam benim az önce nereleri dolaştığımı?
Buna ben bilgisayarımda nasıl izin verdim? Girdiğim alış veriş sitesinin çerezlerini diğer site okuyabilir mi? Hayır. E o zaman demek ki alış veriş sitesi üçüncü parti çerezler (third party cookies) bırakıyor. Demek ki tarayıcımın üzerinden üçüncü parti çerezleri engellemek lazımmış.
Firefox'ta:
Seçenekler>Gizlilik sayfasına gelip, pencerenin "Geçmiş" kısmında "Geçmiş için özel ayarlar kullan" seçimi yaptıktan sonra aşağıda çıkacak olan "Üçüncü parti çerezleri kabul et=Asla" seçimini yapmak gerek.
Chrome'da:
Ayarlar sayfasını açtıktan sonra önce sayfanın altındaki "Gelişmiş Ayarları Göster"i tıklayıp Gizlilik'in altından İçerik Seçenekleri'ni tıklamak gerekiyor. Burada Çerezler bölümünün altındaki checkbox'ı işaretleyerek üçüncü parti çerezleri engelleyebiliriz.
IE:
Internet Seçenekleri'nin Gizlilik sayfasına gelerek Gelişmiş butonuna basarak açılan sayfadan üçüncü parti çerezlerin engellenmesini seçmek gerek.
2013-09-03
Microsoft'un Truva Atı
Yaklaşık 3 sene kadar önce Nokia, Google'ın açık kaynak kodlu işletim sistemi Android'i kullanmak yerine Windows Phone'a yöneleceğini duyurduğunda durumu herkes gibi ben de şaşkınlıkla karşılamıştım. "Canlı ve heyecanlı" Android trenine binmek yerine uzun süredir iki ileri bir geri ilerlemeye çalışan Windows Mobile ve sonradan Windows Phone işletim sistemlerine tutunmasını çok garipsemiş, nedenini bir türlü anlayamamıştım. Son zamanlarda ortaya çıkan birkaç yazıda görmüştüm ki Nokia, Anroid'i seçmesi durumunda Samsung gibi bir pazar devi ile çarpışamayacağını farkederek pazarın ikincisi hatta üçüncüsü konumunda olmamak için farklı bir tercih yapmıştı. Ama Android pazarının üçüncüsü olmak bugünkü durumundan daha mı kötü olurdu?
Daha önce eski dost Symbian'ı rafa kaldırdığını duyurmasına rağmen son aylarda tekrar Symbian'lı telefonları pazara sürmesi de durumu iyice garipleştirmişti. Firmanın zaten içler acısı olan durumuna biraz daha mı acıklı bir hava getirilmek istenmişti?
Nihayet bugün gördüğüm haberler durumun nereye getirilmek istendiği konusuna bir açıklık getirdi [1,2,3]: Nokia, Microsoft'a satılıyordu. Ben hala gidişata şaşırırken, "gören" gözler olayların bu noktaya geleceğini tahmin etmiş olmalılar. Çünkü şu andaki Nokia CEO'su Stephen Elop, eski bir Microsoft çalışanıymış. Nokia'nın tüm pusulalarını Microsoft'a çevirdikten sonra şirketin anahtarını da Microsoft'a teslim ederek görevini tamamlamış. Yazılanlara göre bu birleşmenin ardından Microsoft'a geçerek şirketin "Cihazlar" bölümünün başına geçecekmiş. Bu duruma açık ve net olarak "Truva Atı" olayı deniyor.
Bana da aynı çağrışımları yaptı. Bir zamanların cep telefonu devinin acıklı bir şekilde "içerden" yıkılarak tüketilmesi kimin işine yarar? Nokia bir Finlandiya firmasıydı. Bu devi birkaç sene öncesinde kendine rakip olarak görebilecek firma olan Google ise bir ABD firması. Başka bir ABD firması olan Microsoft ile el ele verip, ikisinin de kazanacağı bir kumpasın içine çekilmiş olması hiç de bir komplo teorisi gibi gelmiyor bana. Daha birkaç ay öncesinde ABD gizli servisinin neredeyse tüm dünyanın elektronik iletişimini izlediği ortaya çıkmış ve bunun ABD vatandaşlarının aleyhine değil de ABD firmalarının lehine kullanıldığı resmen kabul edilmişken kesnilikle değil.
Daha önce eski dost Symbian'ı rafa kaldırdığını duyurmasına rağmen son aylarda tekrar Symbian'lı telefonları pazara sürmesi de durumu iyice garipleştirmişti. Firmanın zaten içler acısı olan durumuna biraz daha mı acıklı bir hava getirilmek istenmişti?
Nihayet bugün gördüğüm haberler durumun nereye getirilmek istendiği konusuna bir açıklık getirdi [1,2,3]: Nokia, Microsoft'a satılıyordu. Ben hala gidişata şaşırırken, "gören" gözler olayların bu noktaya geleceğini tahmin etmiş olmalılar. Çünkü şu andaki Nokia CEO'su Stephen Elop, eski bir Microsoft çalışanıymış. Nokia'nın tüm pusulalarını Microsoft'a çevirdikten sonra şirketin anahtarını da Microsoft'a teslim ederek görevini tamamlamış. Yazılanlara göre bu birleşmenin ardından Microsoft'a geçerek şirketin "Cihazlar" bölümünün başına geçecekmiş. Bu duruma açık ve net olarak "Truva Atı" olayı deniyor.
Bana da aynı çağrışımları yaptı. Bir zamanların cep telefonu devinin acıklı bir şekilde "içerden" yıkılarak tüketilmesi kimin işine yarar? Nokia bir Finlandiya firmasıydı. Bu devi birkaç sene öncesinde kendine rakip olarak görebilecek firma olan Google ise bir ABD firması. Başka bir ABD firması olan Microsoft ile el ele verip, ikisinin de kazanacağı bir kumpasın içine çekilmiş olması hiç de bir komplo teorisi gibi gelmiyor bana. Daha birkaç ay öncesinde ABD gizli servisinin neredeyse tüm dünyanın elektronik iletişimini izlediği ortaya çıkmış ve bunun ABD vatandaşlarının aleyhine değil de ABD firmalarının lehine kullanıldığı resmen kabul edilmişken kesnilikle değil.
Kaydol:
Kayıtlar (Atom)