Vlákno názorů k článku
Čína kompletně přejde na Linux do roku 2020 od X125 - Čína se bojí zadních dvířek od Majkrosoftu. Proč...

Samozřejmě může být, že se jim to podaří. Ale ten poslední pokus celkem jasně ukazuje, že to zdaleka nemusí vyjít.

Binárky se můžou lišit i jinak než digitálním podpisem, stačí aby bylo v kódu třeba __TIME__. Potom by musel nastoupit reverse engineering, jinak se nezjistí, jestli je to neškodná změna nebo backdoor. Navíc se to musím překládat kompilátorem od MS, který sám o sobě může generovat ve výsledném kódu backdoory, takže jsou potřeba i zdrojáky od kompilátoru... Pak taky musí MS dodávat zdrojáky/patch ke každé aktualizaci...

Proč by bylo v kódu makro __TIME__? To by se pak i MS lišily překlady stejné verze z různých časů.
Navíc i kdyby to makro v kódu bylo, je to string literal, a při srovnání jasně vidíte o co jde (zvlášť když máte PBD a DBG soubory).

Ad kompilátor - záleží na úrovni NDA, ale v principu není problém ho dostat.

Ad musí MS dodávat zdrojáky/patch ke každé aktualizaci - na to má MS webový portál.

Vobec si neviem predstavit kompilaciu Windows. Videl som kompilacie velkych projektov a to bola teda fuska. Koli efektivite sa tam programovalo v specialnom prekompilatore ktory sam vygeneroval ceckovy kod a az ten sa skompiloval. Samotny ceckovy kod bol gulas, nieco ako obfuskovana java. Bolo treba poznat pseudojazyk prekompilatora a vtedy sa dal citat kod. Dalej tam boli nastavenia prekompilatora podla ktoreho generoval kod, boli ich tony, nastavit ich vedeli piati ludia na svete. Predpokladam ze Microsoft to ma rovnako inak by sa jeho programatori zblaznili. Ked vidim ako kazdy tyzden pride jedno giga updatov na office tak neverim ze to programatori pisu v cecku.

Kód Windows je poměrně čistý a čitelný, alespoň pro lidi kteří píšou pro Win32. Jde o směsici C, C++ a C#.

MS provádí buildy s různou frekvencí podle produktu a fáze vývoje. V "hot phase" se zpravidla builduje každý den. Vývojáři nejprve kompilují a testují na svých strojích, a pokud je to OK, provedou check-in s případným řešením konfliktů. Za největší ostudu se považuje, když váš kód rozbije denní build. Svého času jste mohl dokonce vidět vývojáře, kteří nosili kozí rohy, dokud nerozbil denní build někdo jiný :)

Laeli, jeden takový detail. V rámci zvýšení bezpečnosti se doporučuje zapnout při kompilaci aplikace a knihoven jednu funkci linkeru, která funkce / metody v programu náhodně rozhází. Mělo by se tím zkomplikovat hackování stylem "na adrese 0xabcde123 přepiš.... a pak spusť kód od adresy 0x123456". Takže po kompilaci bude binárka úplně jiná!!! Takže ani SHA1, ani bin diff, ani disassembly bez kvanta ruční práce navíc nezajistí, že ten zdroják je stejný.

Ve Windows ne

No, ona to spíš měla být reakce na předchozí příspěvek. ASLR se dělá až za běhu (a jen někdy), ale kromě toho mají DLLka předpočítané adresy, které jsou pro každý build jiné (něco jako dělá linuxový prelink).

Knihovnám se dá nastavit fixní base address pomocí option /BASE. Nicméně s ASLR to odpadá. Navíc /BASE se chová deterministicky, takže ze stejného zdrojáku vyleze vždy stejná binárka.

Pokud máte na mysli něco co opravdu vede při každém překladu stejného zdrojáku k různému výsledku, dejte sem víc informací.

O kterou option linkeru se jedná? A je použitá při kompilaci Windows?

MS dokonce poskytuje školení, na kterém vás naučí se ve zdrojácích orientovat, vysvětlí konvence použité v kódu, a naučí vás ty zdrojáky přeložit.

Mno hlavne to musis kompilovat kompilatorem ... od M$ ... a kdo ti zaruci, ze zadni vratka nevlozi primo ten.

V principu není problém dostat i zdrojáky kompilátoru. Záleží samozřejmě na úrovni NDA.

A jde ten jejich kompilator zkompilovat treba v GCC ? nebo jen v kompilatoru od M$ ? :D

Takze se asi shodneme v tom, ze mit pristup ke zdrojakum je vyhoda.

Pokud chcete dělat security audit zdrojáku, tak je samozřejmě nezanedbatelnou výhodou mít ten zdroják :D