BSD törés CMOS sérüléssel?

BSD felhasználók, (itt most konkrétan DESKTOP) - nem tapasztaltatok a "putyini"-napon, félelmetes gépbe "bikázásokat"?

A jelenség egyszerű volt. A gép megfagyott, újraindítás után a BIOS gyakorlatilag nem ismerte fel, a hardver egyetlen elemét sem. - Csak CMOS reset (elem ki) után, állt vissza a gép a normális használható állapotba. (Lehet nincs köze ehhez, de a gépet helyére téve, a Wireshark rengeteg a 60-66 port-ra irányuló kommunikációt jelzett.)

Kérdésem, mivel a fejlesztők kedvéért a tűzfalat alapértelmezett telepítés állapotában "használom", (pl. a TrueOS-en naponta néha többszáz csomagot frissít, tehát gőzerővel dolgoznak rajta.) Mi lehet a műszaki megoldása a vázolt, szinte biztosan szándékos "chrash" kiváltásnak? Azaz (HP gépek lévén,) hogyan törhetik meg az oprendszeren keresztül a CMOS-t? Csak kíváncsiság, - ha valakinek van ötlete, - nem ártana, ha nem kellene a jövőben aggódni az ilyen gép "tönkremenések" miatt... (A másik gép még korábbi PC-BSD, ott nincs frissítés engedélyezve, - egy órán belül lőték ki mindkettőt. Eddig más oprendszeren ilyet nem tapasztaltam, mondjuk 2 éve BSD-n is ez volt az első.)

Hozzászólások

Építőbb hozzáállást várok! - Mondjuk esetleg feltevéseket, ha van. (Mert nekem gőzöm nincs, most tehát csak találgathatok.. Tehát másnál ilyen még nem fordult elő? - Kétszer is, két különböző hardveren ugyanaz a jelenség, más oprendszer verzió - amit folyamatosan használok, mindkettő "pazar" és működőképes jelenleg is. - Vajon ti mivel magyaráznátok? (Persze log semmi a történésről, mert pillanatok alatt lezajlott.) Alaplapi elemek, - mértem, - rendben 3v-on voltak.

" de miért csak azon az egy csütörtök délután? (Azóta sem, és előtte sem.)"
Azok az eszközök, amik tönkre fognak menni, általában nem úgy kezdik, hogy 100%-osan jól működnek, majd puff, egyből tönkremennek.
Hanem az idő előrehaladtálva szépen lassan elkezdenek egyre gyakrabban előíráson kívül viselkedni.
Az, hogy egy szünetmentes tápegységben az akkumulátorok újak, még nem jelenti azt, hogy maga a táp jól működik.
Az, hogy most a táp jól működik, nem jelenti azt, hogy a táp mindig jól működött a múltban. Valamint nem jelenti azt, hogy a táp jól fog működni a továbbiakban.

Azért az erős, hogy 1 darab hardverhiba miatt (ami rengeteg dolog miatt előjöhet, de a legtöbbször ilyenkor a tápellátás a probléma forrása) egyből arra gyanakodsz, hogy megtámadták a rendszereidet a gonoszok. Nem vagy te egy kicsit paranoid?

Azonnal hardverhibára gyanakodtam. (Felfújt kondira, tápra, stb.) Hogy kizárjam, kértem is egy barátomat, mérje ki, Ő profi ebben. De semmilyen hibát nem talált. Csinált egy CMOS ki-be-t, és tökéletesen működött. (Na ebbe a "para"-ba érkezett az időközben bekapcsolt másik BSD-s gép. Azaz, ahogyan írtam az is elszállt. (Ez "atomstabil" Xeon-os gép, 1 éve használom, jelenleg is arról írok.)

UFO-k? - Esetleg gravitációs hullám, azaz összeolvadt két nagy, sötét, fekete lyuk?

"És na majd pont a te gépedet fogják támadni mert annyira fontos adatok vannak"

A támadások nagy részét meghatározott feltételek szerint kiválasztott IT-s eszközökön, ma már szoftverek hajtják végre és tömegesen. Néha "belelóghatunk" mi is. - tehát nem hiszem, hogy engem "személy szerint" támadnak, csak keresem a magyarázatott egy, az elmúlt 20 évemben még fel nem merült problémára...

A kérdést fogalmazom másképpen, ha valaki a leírt CMOS tartalom "elszállást" kívánja előidézni, mit kellene egy internetre kötött gépen routeren, NAT-on kívülről (ADSL) tenni? Ha "napszél", akkor a Windows 10, 7 gépet miért nem érte el? Miért csak a BSD-ket? (egymás után, - nem egyidejűleg - igaz egy szempontból megfeleltek egymásnak, HP volt mindkettő, de nagyon eltérő korúak)

bootp, tftp, dhcp szavaknak guglizz már utána, persze alumíniumcsákóban!

Teszem..., - csákó persze elmarad, :-) de nem teljesen értem, hogyan kapcsolódik a "végeredmény" CMOS-sérüléshez?
(Gondolom, ez egy működő oprendszer alatt, a lehető legkevésbé kívánatos eredmény lenne, valószínű, meg is tesznek mindent a programozók ennek elkerülésére.)

- Az jutott eszembe, az ME-nek lehet-e valamilyen BSD-oprendszer alatti, szoftveres "támogatása" az Intel felé?

Nem kell az intel ME-nek kulon oprendszer tamogatas, akkor is teljes remote admin funkciot biztosit, ha "ki van kapcsolva" a gep, ha le van fagyva a fo OS, vagy ha nincs is OS a gepen. Kozvetlenul, sajat jogon hozzafer a halozathoz (kulon MAC addressen mutatja magat).

Nem ertek az ME-hez - csak kiserletbol probaltam ki egy olcso FuSi desktoppal, azt sikerult tavolrol kezelnem az inteles tool-okkal - de valaki, aki adminolt mar ilyen rendszert biztos megmondja, hogy elofordulhat-e, hogy ezek a HP-k is be voltak jelentkeve az elozo gazdajukhoz es kaptak mondjuk egy felresikerult firmware frissitest.

(Egy idoben rendszeresen vettunk "hasznalt markas" gepeket, ezeket kulfoldi cegek selejtezik nagy tetelben, utana jonnek magyarorszagra. Talaltam koztuk olyat, ami nem volt rendesen letisztitva es meg engedelyezve volt ez a remote admin, valami sved vagy nemet ceg infoi voltak az asset ID-ban, stb.)

Hát ezt köszi, - jelenleg számomra ez a leggyanúsabb, hogy ezen keresztül oldottak meg, valakik valamit.
Piszok paranoid leszek, Most mondom a számomra (de én szeretem a jó Sci-Fi-t is, meg a mindenféle Sci-Fi-t is.) nem elképzelhetetlen történetet.

Úgy tudom, hogy a BSD-k erőteljes NSA támogatással fejlesztődnek. Megjelent Putyin Magyaro-n, a saját kibervédelmi csapat figyelt, azonnal vették, hogy a jelenleg helyben működő BSD-k, (volt esetleg, - hasamra ütök, - adott időben kb. egy tucat működő desktop BSD,) megnövekedett érdeklődést mutatnak megfelelő irányokba, nem teketóriáztak, hanem egy gombnyomással hatástalanították, biztos ami biztos mindet, (mivel sok orosz fejlesztő van, jól is ismerik a rendszert.)

Vagy egy másik variáció: A "saját" kibervédelmis csapat halálra unta magát, az alatt a 6 óra alatt, mert a mieink megoldottak minden lehetséges védelmi funkciót. De volt köztük több BSD hacker aki körülnézett, és talált néhány érdektelen működő desktop-pot, miután jól megnézte, kiköpött a páncélozott repülőkabinból és tanulságképpen, hogy végre legyen valami "akció-demonstráció" is, "lerúgta" az elsőt, majd némiképp meglepetten, (ti.a zenebohóc, hogy "van máásiiik"...) a rövidesen jelentkező második érdektelenre kellett reagálnia hasonlóképpen. (Könnyű, említésre sem méltó esetek.)

Na a meséhez mit szóltok?
:-)

:-)

Hát nem (csak!) erre való a blog!? (Meg hát tudod, szinte fantázia sem kell hozzá, annyi lehetséges más ok van még. De hát vannak hajlamosító tényezők, a média, és miattuk az ember alapból a leginkább "jelenlévőket" szedi elő. (Azután jöhet szomszéd autista gyermek "script-kidy", meg a "jin-jang" tartományból egy 2.1-es android teló is.) Ha majd egyáltalán egyszer megérem a nyugdíjas kort, a "Wireshark" "proxy"-gép nélkül nem megyek az "utcára" sem. (Elleszek a napi pár százmilliárd IPV6-os IP elemzésével. Igazi nyugdíjas időtöltés.)

:-)

nagy energiájú tachion nyaláb haladt át a gépen..
esetleg gravitációs hullám, bár ez elég bizonytalan..

cseréld ki a gombelemet az alaplapon.
ez megakadályozza a tachionokat az alaplap rongálásában.

Napfolt tevékenység vagy mágneses légköri anomália, ezeket mindig beszopják a júzereim, használd szeretettel ;-)

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

A BIOS NVRAM terletét elég egyszerű mind BSD, mind Linux alatt átütni. BSD-nél a device nvram -ot kell beütni a kernel konfig fileba, a loader.conf-ba meg nvram_load="YES"-t. Innen kezdve /dev/nvram-on keresztül írható a ram területe a BIOS-nak.
A flash terület átütése kicsit macerásabb, de BSD-hez is elérhető a flashrom tool, de ennek a használatához root jogosultság kell.
Természetesen, egy hirtelen feszültségingadozás és szar BIOS akku még véletlenül sem lehetett. ...
A portra menő forgalmat látni kellene, de sanda gyanúm PXEboot és a DHCP a játékos.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "