Příspěvky

181

Vývoj / Re:Multithreading projekt/příklad

« kdy: 24. 06. 2017, 12:06:28 »

na niektore z tych uloh je potrebna asi aj ina znalost, ako len paralelne programovanie.

Krom znalosti algoritmů (abyste je mohl paralelizovat) moc víc znát nepotřebujete, pokud se nesnažíte o opravdu vysoký výkon (v takovém případě se hodí např. znalost vektorových instrukcí).

Samozřejmě, nepočítejte moc s tím, že pokud algoritmus pustíte v N vláknech, dosáhnete N-krát rychlejšího výpočtu, ale na procvičení se tyhle úlohy určitě použít dají (a na MFF se i pro tyto účely používají).

182

Windows a jiné systémy / Re:Zásek notebooku s Windows

« kdy: 10. 06. 2017, 14:48:58 »

Podívejte se po následujících souborech:

C:\Windows\Minidump\*.dmp
C:\Windows\memory.dmp (lepší varianta)

Jedná se o výpisy paměti, ze kterých se, dají-li se např. do debuggeru WInDbg, dá (někdy) zjistit, proč došlo k záseku/BSOD.

Co se týče těch zpráv o nenačtených ovladačcíh, ty nemusí se zásekem nijak souviset. Ovladače HID a podobných zařízení obvykle využívají UMDF rozhraní a může dojít k problémům v případě, že některé jiné ovladače se snaží komunikaci s těmito zařízeními filtrovat.

Že se stroj nevypnul po odpojení od elektřiny je při záseku logické, neměl možnost tuto situaci zpracovat. Každopádně, podržení vypínacího tlačítko po dobu 3-5 vteřin by jej mělo vypnout.

183

Windows a jiné systémy / Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.

« kdy: 21. 05. 2017, 23:17:31 »

Když to trochu přeženu, tak na mě působíte tak, že pro vás je kritickou zranitelností i např. vypnuté ASLR, protože pokud daná aplikace trpí nějakou jinou zranitelností, ASLR její zneužití může výrazně ztížit, ale ne mu zabránit docela.

184

Windows a jiné systémy / Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.

« kdy: 21. 05. 2017, 23:11:13 »

Hezký hack. Nezkoušel jsem. Vyzkouším a dám vědět, případně doplním do blogu.

Hack to není. Prostě pokud daný uživatel má oprávnění pracovat s ACL daného objektu (ať už mu to dovoluje samotné ACL, nebo je jeho vlastníkem a není přítomno OWNER SID), teoreticky může ACL upravit dle libosti.

185

Windows a jiné systémy / Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.

« kdy: 21. 05. 2017, 20:20:07 »

Konkretne u App Service nemate moznost cokoliv managovat a nastavovat opravneni, tzn. melo by to byt utazeno pokud mozno co nejvice

Nedá se to provést ani z kódu dané aplikace (případně nějaké miniaplikace, kterou pustíte jednou a pak ji odstraníte)? Zejména pokud jste schopen spustit i nativní kód (řekněme načíst DLL knihovnu), měl byste mít přístup k příslušným API, abyste mohl upravit příslušná ACL tak, aby k nim uživatel, pod kterým běží webserver, ztratil přístup, který mu dát nechcete.

Netvrdím, že se jedná o zvlášť úžasné řešení, ale těm, kdo chtějí své aplikaci ubrat nějaké to oprávnění, by mohlo posloužit.

Kdybyste možnost zápisu do www root nenazýval "critical vulnerability", ale spíše popsal možnost, jak podle vás vytvořit pro většinu aplikací bezpečnější prostředí, toto téma by asi vypadalo jinak (pokud by vůbec existovalo). Kritická zranitelnost podle mojí zkušenosti vypadá úplně jinak.

186

Windows a jiné systémy / Re:Windows a linux distribuce na odstraneni hesla

« kdy: 20. 05. 2017, 11:13:12 »

Dále jsem to už rači nezkoumal toto řešení zavrhuji...

Já bych to naopak rozhodně vyzkoušel. Myslím si, že minimálně zpětně kompatibilitu by ten obraz mohl udržovat (tzn. půjde použít i na starší verze Windows, dopředně by ten Locksmith mohl být taky, dokud jej nebudete zkoušet na WIndows 10).

187

Windows a jiné systémy / Re:Windows a linux distribuce na odstraneni hesla

« kdy: 20. 05. 2017, 01:34:34 »

Podle toho, co píše, přijde chntpw tazateli příliš časově náročné. A nedá se ani říci, že by tento nástroj odstraňoval hesla zrovna šetrně (zcela ignoruje způsob, jakým je původní heslo uloženo). Ale zatím to ten systém dokáže zvládnout.

Pokud byste chtěl oficiální řešení, existuje nástroj Locksmith (GUI). Ten je součástí Microsoft Diagnostic and Recovery Toolsetu, jež je ale myslím dostupný jenom pro partnery MS. Ale minimálně ISO obrazy tímto toolkitem vytvořené a obsahující Locksmith by moly být dohledatelné.

188

Vývoj / Re:Proč je Go tak pomalý?

« kdy: 30. 04. 2017, 20:20:10 »

neexistuje nad Céčkem nějaká jazyková OOP nadstavba, která by přío generovala Céčkový kód a až ten by se pak kompiloval?

Nestačilo by prostě vzít C++ a použít z něho jen to, co je potřeba (tzn. třídy, virtuální metody, ale třeba ne šablony)?

Před lety jsem takový projekt implementující OOP do C viděl, bohužel si již nevzpomenu na jméno. Nezkoušel jsem, takže o něm nemohu nic moc říci. Tehdy byl v experimentálním stavu a přišlo mi zbytečné použít jej místo použití malé podmnožiny C++.

189

Software / Re:Antiviry a Anonymita (Proč se o tom nemluví?)

« kdy: 26. 04. 2017, 23:23:21 »

Jenze ve widlich bys potreboval ne 2 dny ale 20let, abys do toho dopsal to vsechno co to neumi a prepsal to vsechno, co to dela uplne blbe. Dyt ten debilni system neumi ani symlink ...

To záleží, co byste tam chtěl dopisovat. Zrovna co se týče firewallu,  všechno vyjma rozhodovací logiky a UI tam máte (pokud vynecháte standardní Windows Firewall). Rozhraní pro detekci a filtrování síťových operací (per-application) a práce s pravidly tam je přímo zabudováno. A je i zdokumentováno.

Symlinky a hardlinky Windows (resp. NTFS) umějí (z Příkazového řádku k tomu slouží utilita mklink).

Mně kdysi (2005) stačilo stáhnout nějakou Kerio věc, Next, Next, Next, hotovo. Určitě to netrvalo 20 let.

Kerio (Subnelt) Personal Firewall byl jednu dobu velmi oblíbený nástroj. Asi se nějak nedostalo ven, jak moc je "kvalitní".

Například hlídal i spouštění neznámých procesů, při kteréžto události zobrazil dotaz a spouštění procesu (resp. jeho hlavního vlákna) bylo pozastaveno. Útočníkovi ale v takovém případě stačilo se pokusit proces (resp. jeho hlavní vlákno) znovu rozběhnout, aby onen dotaz obešel.

Je pravda ale, že co se týče síťových nastavení, to umělo hodně (a to ještě v době XP, kdy žádné dokumentované rozhraní pro firewally v podstatě nebylo).

190

Vývoj / Re:C++ naco jsou hlavičkové soubory když budu psát OOP?

« kdy: 26. 04. 2017, 19:36:07 »

OOP se vzdyt dela v Jave. C++ je jen nepovedeny hack. Vzdyt i samotny kernel je psan radeji v cistem C.

Pokud můžu mluvit za WIndows kernel, tak některé části v C++ jsou (např. Windows Driver Framework) a někteří výrobci své ovladače píší také v tomto jazyku. Pokud si člověk dává pozor, nepředstavuje C++ v jádře problém.

191

Vývoj / Re:C++ naco jsou hlavičkové soubory když budu psát OOP?

« kdy: 26. 04. 2017, 19:29:35 »

Jo? Tak asi zase tak moc bezpecny zpusob to neni, kdyz tady zboj radi operatory new vubec nepouzivat a kdyz uz, tak misto nich shared pointry. Sam v tom nemas jasno, tak radeji mlc a najdi si o tom neco na stackoverflow.

I se smart pointery se interně alokuje dynamicky a je dobré o tom vědět. Moje poznámka o bezpečnosti se vztahovala k tomu, že při použití dynamické alokace se vše bude chovat podobně jako jsou lidé zvyklí z jiných jazyků. Že se práce s čistými pointery nedoporučuje, je jasné. Ani smart pointery ale neřeší všechno.

Když budete používat new a čisté ukazatele, sice se nevyhnete problémům s memory leaky a obecně s pointery (což není nic objevného), ale zase se vyhnete věcem, nad kterými tady nadáváte.

192

Vývoj / Re:C++ naco jsou hlavičkové soubory když budu psát OOP?

« kdy: 26. 04. 2017, 19:09:02 »

Kód: [Vybrat]

Uz chapu, proc se tolik lidi vysralo na statickou alokaci a proste vsude v C++ pouzivaji operator new

Je to bezpečný způsob použití velmi podobný jiným rozšířeným jazykům. Krom toho, při alokaci objektů na zásobníku některé OOP mechanismy nefungují (stejně tak v konstruktorech). Samozřejmě je třeba si hlídat memory leaky, ať už jakýmkoliv způsobem.

C++ nabízí dost prostředků, které se vám mohou hodit např. v případě, že píšete něco náročného na výkon. Ale nikdo je vás nenutí využívat, když nechcete. Prostě si vyberte podmnožinu věcí, co C++ umí, a používejte ji; časem ji můžete obohatit např. o nějaké to šablonové peklo.

193

Distribuce / Re:Odstranění položky ze zavaděče v MBR

« kdy: 25. 04. 2017, 23:00:58 »

Který ze systému tedy potřebujete na tom disku zachovat? Pokud Windows, tak by mělo stačit nastavit jejich oddíl na aktivní a případně opravit MBR (resp. odstranit z něho Grub) srkz bootsect.exe (je součástí instalačního média).

194

Windows a jiné systémy / Re:Někdo mi něco nainstaloval na widle

« kdy: 20. 04. 2017, 18:03:47 »

M. Dráb - jste odborníkem na Windows, jde v tom systému nějak nastavit, aby se nejprve zeptal, jestli opravdu chci zavést/instalovat ovladač bůhví čeho i třeba za cenu, že budu odklikávat více oken? Mě by to nevadilo.

Bohužel se pohybuji zejména na nízkých úrovních (v jádře), takže mnohé možnosti nastavení systému jdou dost mimo mě.

Nevím, jak zařídit to, aby se vás systém ptal při instalaci každého zařízení (uměl bych to naprogramovat – a v základní verzi by možná bylo nejtěžší částí zobrazit dotaz na správný desktop tak, aby jej uživatel viděl :-)... pokud neočítáme fakt, že aktuálně nedisponuji (EV) certifikátem pro tyto účely), ale pomocí Group Policy, jak se zdá, můžete nastavit, která zařízení mohou být ke stroji připojena. Specifikují se pomocí hardware nebo compatible IDs (najdete v Device Manageru).

V zásadě se jedná o metodu č. 2 v tomto článku
https://support.microsoft.com/en-us/help/2500967/how-to-stop-windows-7-automatically-installing-drivers

Minimálně vás dovede do správného ddělení Group Policy. Článek je pro Windos 7, ale stejná nastavení mám i na svých Windows 8.1.

Není to samozřejmě ideální, ale můžete tím zakázat/povolit nejen konkrétní zařízení, ale i celé třídy (např. v compatible ID najdete i řetězce typu USB\Class_XX, případně se SubClass_yy a Prot_zz). Pro seznam tříd, podtříd a protokolů se můžete mrknout třeba sem
http://www.usb.org/developers/defined_class