Borland C++ 2.0'ın kaynağı, ikili dosyadan bayt bayt geri çıkarıldı

Bir derleyiciyi yeniden derlemek bile başlı başına bir iştir. Peki elinizde yalnızca onun hazır çalıştırılabilir dosyası varsa ve hedef, o dosyanın tek bir baytına kadar aynısını üretecek kaynak kodu sıfırdan geri çıkarmaksa? GitHub'da "abedegno" adıyla yayın yapan bir geliştirici tam bunu yaptı. 1991 tarihli Borland C++ 2.0'ın komut satırı derleyicisi BCC.EXE'nin kaynağı, orijinal Borland araçlarıyla derlendiğinde Borland'ın kendi dosyasıyla bayt bayt özdeş çıkıyor.

Çalışmayı Hackaday 13 Kasım 2026'da duyurdu. Yazı, projenin deposuna ve yöntem belgesine bağlanıyor. Aşağıdaki bilgilerin çoğu, doğrudan projenin kendi README, NOTICE ve yöntem sayfalarından geliyor.

Borland C++ 2.0 neydi?

Borland, 1987'de Turbo C'yi çıkardı. Wikipedia'daki özete göre ürün; bütünleşik geliştirme ortamı, küçük boyutu, hızlı derlemesi ve düşük fiyatıyla öne çıkıyordu. Mayıs 1990'da Turbo C'nin yerini Turbo C++ aldı. Borland C++ ise bunun ardılıydı ve daha çok profesyonel geliştiriciye yönelikti. Numara 2.0'dan başladı, yani "Borland C++ 1.0" diye bir sürüm hiç çıkmadı. 2.0 sürümü 1991'de MS-DOS için yayımlandı, aynı yıl 3.0 geldi, 1992'de de Windows tabanlı ortamıyla 3.1 çıktı.

Yani söz konusu derleyici, C++ dilinin henüz standartlaşmadığı bir dönemin ürünü. Projenin yan hedeflerinden biri de bu derleyiciyi, Borland'la derlenmiş eski DOS oyunlarını tersine çevirmekte kullanılacak bir araca dönüştürmek. Böyle bir iş için önce derleyicinin tam olarak ne yaptığını bilmek gerekiyor.

Kaynak koddan değil, ikiliden geri dönüş

Proje, Borland'ın yayımlanmış çalıştırılabilir dosyalarından kaynağı kurtarıyor. Yöntem sayfasındaki ölçüt şu: Aynı derleyici, aynı anahtarlar, aynı baytlar. Yazarın ifadesiyle bayt özdeşliği "tartışılamayacak tek sınama". Yeniden derlenen program orijinaline eşitse, kaynak onun sadık bir dökümüdür.

Süreç adım adım şöyle ilerliyor:

• Araç zincirini belirlemek: BCC.EXE'nin Borland C++ 2.0 ile, elle yazılan kısımların TASM 2.51 ile, bağlama işinin ise TLINK 4.0 ve VROOMM bindirme yöneticisiyle yapıldığı saptandı. Bir işlev ancak derleyici, sürüm ve her anahtar doğruysa tutuyor. Sonradan 29 çalışma zamanı kütüphanesi modülünün daha eski bir derleyiciyle, Turbo C 2.01 ile derlendiği anlaşıldı.
• Programı haritalamak: Çalıştırılabilir dosya bölümlere, bindirmelere ve yordamlara ayrıldı. Modüller arasındaki dolgu baytları, yer değiştirme sırası ve bölüm adları, özgün kaynak dosyalarının sınırlarını gösteren kanıt oldu.
• Dosya dosya eşleştirmek: Her dosya için C ya da TASM kodu yazılıyor, DOS'ta orijinal derleyiciyle derleniyor, her işlev orijinaliyle karşılaştırılıyor ve fark kalmayıncaya kadar kaynak değiştiriliyor.
• Eşleştirmenin göremediğini doğrulamak: Bayt karşılaştırması, bağlayıcının sonradan dolduracağı yerleri maskeliyor. Bu yüzden dış başvuruların doğru simgeye gittiği ve veri ile BSS bölümünün aynı dizildiği ayrıca denetleniyor.
• Bütünü bağlamak: Tüm nesneler TLINK ile yeni bir BCC.EXE'de birleştiriliyor ve sonuç Borland'ınkiyle SHA-256 özetiyle karşılaştırılıyor.

Yöntem belgesindeki ilginç bir ayrıntı, derleyicinin alışkanlıklarının kaynağın nasıl yazılacağını belirlemesi. Örneğin Borland C++ 2.0, erişilemeyen sıçramaları ortak kod kuyruklarını birleştirmeden önce temizliyor. Bu yüzden bazı işlevler, bir insanın doğal olarak yazacağı biçimde değil, erken bir return ya da yinelenen bir deyimle yazıldığında tutuyor. Bu noktalar kaynakta "match:" yorumlarıyla işaretli. Yazar iki kural koyduğunu söylüyor: Elle yazılmış assembly modülleri assembly, derlenmiş C modülleri C olarak kalıyor; satır içi assembly ya da bayt yaması gibi kestirme yollar kullanılmıyor.

Rakamlarla sonuç

Ölçü	Değer (projenin README'sine göre)
Kaynak dosyası	298, 15 alt sistem dizininde
C dosyası	265 (Borland C++ 2.0 ve Turbo C 2.01 ile derlenenler)
El yazısı TASM modülü	33
Kurtarılan ya da betimleyici adlandırılan öğe	yaklaşık 3.100 işlev, genel değişken ve etiket
Adlandırılan kayıt alanı / kayıt düzeni	300 / 40
Yorum satırı	yaklaşık 10.000
BCC.EXE durumu	tamamlandı, bayt özdeş (SHA-256 özeti dd5744b9... ile başlıyor)
CPP.EXE (bağımsız önişlemci) durumu	tamamlandı, bayt özdeş (SHA-256 özeti 39879c60... ile başlıyor)

Kurtarılan kaynak okunabilir hale de getirilmiş: Adlar, kayıt alanları ve her dosyaya rol satırı ile işlev yorumları eklenmiş. Yöntem belgesine göre ad hiçbir zaman tahminle verilmemiş; her adın dayanağı "betimleyici" ya da "çıkarımsal" diye kayda geçmiş. Amacı belirsiz kalan kodlar bile ne yaptıklarını anlatan adlarla (örneğin kullanılmayan bir havuza verilen ad) etiketlenmiş. Her okunabilirlik adımından sonra aynı bayt denetimi yeniden çalıştırılmış. Yani yorum eklemek ya da ad değiştirmek kodu bozmuyor; denetim bunu zorunlu kılıyor.

Derleyicinin içinden notlar

Projenin bulgular dosyası, Borland'ın derleyicisinin içini de gösteriyor. Dosyada her madde "doğrulandı", "olası" ya da "mümkün" diye güven düzeyiyle etiketlenmiş. Birkaç örnek:

• Ayrıştırıcı elle yazılmış bir özyinelemeli iniş ayrıştırıcısı; ifadeler için işlem önceliğine dayalı bir ayrıştırıcı kullanıyor. yacc gibi bir ayrıştırıcı üretici yok.
• strrchr işlevi boş bir dizgede dizginin bir bayt öncesine bakıyor. Bulgular dosyasına göre pratikte zararsız, ama bir taşımanın bunu kopyalamaması gerekiyor.
• Hiçbir yerden çağrılmayan, yalnızca kendini çağıran bazı yordamlar var. Dosya bunların Borland'ın kaynağındaki yer tutucular olabileceğini söylüyor, ancak bu bir tahmin.
• Bir yapı alanını uzak gösterici üzerinden artırmak, bazı bellek modellerinde "Register allocation failure" hatasıyla derlemeyi durduruyor. Bu, Borland'ın kendi BCC.EXE'si çalıştırılarak doğrulanmış.

Değiştirilebilir sürüm ve sınamanın sınırı

Bayt özdeşliği, kodu kıpırdatmadığınız sürece geçerli. Projenin ayrıca bir "modlama derlemesi" var: Aynı kaynakları TLINK'in seçtiği düzenle bağlıyor, böylece işlevler büyüyüp küçülebiliyor ve yeni dosyalar eklenebiliyor. Bu derlemenin doğruluğu, Borland'ın kendi örnek programları ile eski GCC ve cfront sınamalarının da içinde olduğu 1.836 derlemenin, hem Borland'ın hem yeniden oluşturulan derleyiciyle çalıştırılıp çıktılarının karşılaştırılmasıyla denetleniyor.

Burada sınır açık yazılmış: İzleyen bir öykünücü, bu sınama derlemelerinin derleyicinin kodunun yüzde 83'ünü çalıştırdığını gösteriyor. Kodun kalan yüzde 17'si, modlama derlemesinde bu sınamalarla denetlenmiş değil. Kapsam belgesine göre yerleşik bölümde bu oran yüzde 65, bindirme bölümlerinde yüzde 85. Bayt özdeş yeniden derleme ise bunun dışında, tüm program için geçerli.

Araç: Exhume ve yapay zekâ kısmı

Çalışmada Exhume adlı bir araç takımı kullanılmış. Aracın kendi README'si onu "bayt eşleştirmeli decompilation için bir araç takımı ve bir dizi Claude Code becerisi" diye tanıtıyor; parmak izi çıkarma, ikili haritalama, dosya eşleştirme ve doğrulama-birleştirme gibi aşamaların her biri için ayrı bir beceri tanımlı. Araç, Ultima Underworld II'nin tersine çevrilmesiyle doğmuş. Hackaday da Exhume'un Claude Code tabanlı olduğunu belirtiyor. Öte yandan Borland-reborn deposunun yöntem belgesi yapay zekânın bu projede tam olarak nasıl kullanıldığını ayrıntılamıyor; bulgular dosyasında yalnızca "adlandırma ajanları"nın bulduğu maddelerin koda karşı denetlendiği geçiyor. Bu yüzden iş bölümünün ayrıntısı, yani hangi adımı kimin ya da neyin yaptığı, kaynaktan kesin olarak çıkmıyor.

Telif ve lisans durumu

Projenin NOTICE dosyasına göre Borland C++, Turbo C, Turbo Assembler ve Turbo Linker, Borland International'ın ürünleri; hakları bugün Embarcadero Technologies'e ait ve proje bu şirketlerle bağlantılı değil. Depoda iki tür içerik var. Proje için yazılan betikler ve belgeler MIT lisanslı. Kurtarılan kaynaklar ise Borland'ın telifli programlarından türetilmiş; "inceleme, koruma ve birlikte çalışabilirlik araştırması" için sunuluyor ve "hiçbir hak talep edilmiyor ya da verilmiyor". MIT lisansı bu kaynakları kapsamıyor.

Depoda Borland'a ait hiçbir program, kütüphane, başlık dosyası ya da disk görüntüsü yok. Derlemek isteyen kişinin orijinal programları kendisinin edinmesi gerekiyor. Yazar, bu materyalde hakkı olanların bir kaygısı bulunursa deponun sorun bölümü ya da kendisi aracılığıyla ulaşabileceğini yazıyor. Kurtarılan kaynakların hukuken nasıl değerlendirileceği konusunda kaynaklarda bir yorum yok; bu yazı da bir değerlendirme yapmıyor.

Sırada ne var?

Depo, ileride başka Borland ve Turbo sürümlerinin de aynı düzenle ekleneceğini söylüyor. Ayrıca BCC.EXE'nin, Borland ile derlenmiş oyunları tersine çevirmek için yerel bir araç olarak taşınması "başlatıldı" durumunda: Bir çağrı kaydedicisi, yeniden oynatma düzeneği ve ilk çalışma zamanı işlevleri hazır. Açık kalan soru şu: Bayt özdeşliği, bir ürünü tarihsel olarak belgelemek için yeterli bir ölçüt mü, yoksa "neden böyle yazılmış" sorusunun cevabı yine yalnızca Borland'ın kendi arşivinde mi? Proje, bayt eşleşmesini kanıt, yorumları ise dürüstçe işaretlenmiş çıkarım olarak sunarak ikisini ayrı tutmaya çalışıyor.

Fotoğraf: SAMNAD.S, CC BY-SA 3.0, Wikimedia Commons