Fórum Root.cz
Hlavní témata => Server => Téma založeno: Darkhunter 06. 08. 2016, 18:22:59
-
Ahoj,
pronajímám zákazníkům rpi stroje, kde máme náš program v pythonu, který máme na luks encrypted partition.
Otevíráme ho, pokud zákazník zapne raspberry a autorizuje se na našem serveru.
Chtěl bych odemykat tu partition vzdáleně stylem:
echo "heslo" | ssh root@IP "cryptsetup open /dev/mmcblk0p3 cryptopt"
ssh root@IP "mount -t ext4 /dev/mapper/cryptopt /opt"
Chtěl bych se zeptat, zda-li se někam vzdálené příkazy logují a kam.
Pak bych se chtěl zeptat, jestli takhle zadané passphrase heslo se odesílá zašifrované a jestli ho nemůže vesměs nikdo ukrást. (To by ani nemělo jít, protože všechno tohle probíhá ve VPN.)
-
Rikate, ze mate VPN a jeste skrz to tlacite ssh a ptate se, jestli heslo jde sifrovane? To je ale blba otazka, ze jo.
Ovsem na druhe strane vam heslo vyleze ven v cleartextu a pokud vam nekdo treba misto prikazu cryptsetup podstrci skript, ktery zaloguje heslo a dale zavola ten spravy cryptsetup, tak vam heslo slohne a vy se o tom nedozvite. A pokud ma nekdo vyzicky pristup k RPi, tak nevim, co by mu v tom zabranilo, kdyz ude chtit.
-
Já se ptal ohledně toho šifrování na přijímací straně...
No a dá se to nějak zabezpečit lépe? No já počítám s tím, že stát se to asi může, ale zákzaníci nejsou počítačově moc zruční...Navíc ten cryptsetup heslo se pošle jen, když je správně detekované ID desky a spousty dalších věcí. Já bych potřeboval, aby se ty příkazy vzdálené vůbec nikam nelogovaly...
-
Tak ja logovani prikazu pres ssh nikdy nesledoval, pokud vim, tak v logu je leda to, ze se nekdo prihlasil pres ssh nebo ze bylo blbe heslo/user a spojeni bylo odmitnuto. Nicmene co vam brani vzit jedno takove RPI, pustit si ho doma a pak si prohrabnout logy?
-
No já to právě nikde nenašel a jestli žádné takové logy nejsou, tak by zjišťování, jak se ta partition odemyká a všechno kolo, mělo být o dost složitější.
-
Tak otázkou je, proč to děláš, před kým chráníš data, jaký přístup k té aplikaci má zákazník, co ta aplikace obecně umožňuje. Heslo je šifrovaný dvakrát, jednou po VPN server VPNkou a podruhé SSHčkem až do cíle, takže o to bych se nebál. Příkaz jako takový se nikam nezaloguje, pokud se o to sám nebudeš snažit (není to tak jednoduché, ssh jako takové to neumí), největším problémem potom zůstává přístup k aplikaci a co ta aplikace umožní.
Pokud ti na tom opravdu moc záleží a stojí ti to za to, nech si udělat od někoho schopného penetrační testy - v tomto případě je zásadní to "nech si udělat", protože i kdyby jsi byl schopný si je udělat sám (což dle dotazu asi není tvůj případ), stejně budeš příliš ovlivněnej tím, co o svém řešení víš a co si o něm myslíš.
-
Ahoj,
pronajímám zákazníkům rpi stroje, kde máme náš program v pythonu, který máme na luks encrypted partition.
Otevíráme ho, pokud zákazník zapne raspberry a autorizuje se na našem serveru.
Chtěl bych odemykat tu partition vzdáleně stylem:
echo "heslo" | ssh root@IP "cryptsetup open /dev/mmcblk0p3 cryptopt"
ssh root@IP "mount -t ext4 /dev/mapper/cryptopt /opt"
Chtěl bych se zeptat, zda-li se někam vzdálené příkazy logují a kam.
Pak bych se chtěl zeptat, jestli takhle zadané passphrase heslo se odesílá zašifrované a jestli ho nemůže vesměs nikdo ukrást. (To by ani nemělo jít, protože všechno tohle probíhá ve VPN.)
- Pokud ma zakaznik nad tim RPI plnou kontrolu celou dobu (vcetne casu odemykani LUKS), tak na to asi reseni neexistuje.
- Pokud zakaznik po autorizaci (mimo to RPI) ceka na odemceni LUKS a pak ziska pristup k RPI, je to resitelne:
- zkontrolujete zda jsou na cilovem RPI vsechny soubory potrebne pro odemceni LUKS nemodifikovane zakaznikem => tim zamezite podvrzeni skriptu nebo binarky
- heslo (ale lepe odemykaci klic) se posle trubkou pres to SSH a odemce LUKS
- system se preda zakaznikovi
- po ukonceni uzivani zakaznikem, zkontrolujete fs na modifikace systemu (zajima vas vlastne diff distribuce pred a po)
- zkontrolujete LUKS jestli nema nove klice
- zavrete/zamcete LUKS
Riziko co mne napada:
- pokud ma zakaznik plnou kontrolu nad systemem, muze si vlozit do odemceneho LUKS svuj vlastni klic (ted z hlavy nevim zda je to treba pri uz otevrenem LUKSu autorizovat existujicim klicem nebo heslem)
-
Tak otázkou je, proč to děláš, před kým chráníš data, jaký přístup k té aplikaci má zákazník, co ta aplikace obecně umožňuje.
Přesně tak, tímhle je potřeba začít, ne dumáním nad logováním ssh.
- zkontrolujete zda jsou na cilovem RPI vsechny soubory potrebne pro odemceni LUKS nemodifikovane zakaznikem => tim zamezite podvrzeni skriptu nebo binarky
Nedovedu si teď úplně představit, jak to udělat dobře na nedůvěryhodném systému. Když budu dělat sha checksumy, jak zjístím, že samotná binárka sha256sum není modifikovaná? Ok, můžu si tam přes ssh nakopírovat svoji binárku, jak zjistím, že není jádro modifikováno tak, že mi pro checksum předhotí správné binárky, ale jinak použije kompromitované?
Jediný způsob, jak to udělat fakt dobře, o kterým vím, je TPM, který RasPi nemá.
- system se preda zakaznikovi
Btw, nebylo ani řečeno, co tohle přesně znamená. Zákazník má to RasPi v ruce? Má k němu ssh přístup? Na roota nebo uživatele? Má přístup jenom přes nějakou aplikaci? Je ta aplikace nějak auditovaná?
Riziko co mne napada:
- pokud ma zakaznik plnou kontrolu nad systemem, muze si vlozit do odemceneho LUKS svuj vlastni klic (ted z hlavy nevim zda je to treba pri uz otevrenem LUKSu autorizovat existujicim klicem nebo heslem)
No já hlavně úplně nechápu, jaký smysl by mělo LUKS otevřít a dá k němu uživateli plný přístup. Tak si celý obsah zkopíruje a dál klíč nepotřebuje... ...a jsme zpátky u toho, že se musí začít sepsáním toho, co proti komu chráním a jaké má potenciální útočník v ruce prostředky.
-
Tak otázkou je, proč to děláš, před kým chráníš data, jaký přístup k té aplikaci má zákazník, co ta aplikace obecně umožňuje.
Přesně tak, tímhle je potřeba začít, ne dumáním nad logováním ssh.
+1. A není to tak dlouho, co tady někdo sáhodlouze hloubal nad stejnou pitomostí (znásilnění LUKSu jako DRM). A ne a ne a nenechal si vysvětlit, že to k tomu není určeno.
-
- zkontrolujete zda jsou na cilovem RPI vsechny soubory potrebne pro odemceni LUKS nemodifikovane zakaznikem
Což ale bude kontrolovat na zařízení, které má pod kontrolou zákazník - takže samozřejmě může předstírat, že soubory modifikované nejsou, i když budou.
Chtěl bych se zeptat, zda-li se někam vzdálené příkazy logují a kam.
V normálním nastavení sshd neloguje vstup ani výstup, který přes něj prochází. sshd jen spustí shell a vstup mu předává a přebírá od něj výstup.
jestli takhle zadané passphrase heslo se odesílá zašifrované
Ano, po výměně klíčů je už celá SSH komunikace šifrovaná.
jestli ho nemůže vesměs nikdo ukrást.
Může. Vymění sshd za svůj, vymění cryptsetup za svůj, vymění celé RPi za své...
pronajímám zákazníkům rpi stroje, kde máme náš program v pythonu, který máme na luks encrypted partition.
Nebylo by lepší věnovat energii na zlepšování toho programu, než se pokoušet o nemožné? Pokud je ten váš program takový zázrak, stejně se k němu někdo dostane.
-
Takže. Zákazník nemá do raspi přístup. Má ho sice u sebe, ale žádného uživatele na raspi nemá.
Na raspi poběží restapi pro mobilní appku, z které bude zákazník přistupovat.
Samozřejmě při otvírání LUKSu čekuju i IDčko základní desky a další parametry, aby nebylo možné to zkoušet odemykat z jiného raspi.
Tohle řešení mi zatím nezabralo ani hodinu a moc do toho investovat nechci. Nějaký expert se tam vždycky nějak dostane. Mně jde o to, aby se tam nedostalo 99% lidí. Většina toho našeho kódu se stejně vydá jako opensource, ale pak je tam databáze atd a to bych chtěl mít zabezpečené pořádně.
-
Jestli mate sifrovane data na hardware ktery sam o sobe bezpecny neni, tak zadna extra SW vrstva vam ochranu neprida. Staci vytahnout SD kartu z RPi, pozmenit par skryptu a maji vse co se snazite chranit. A bude to trvat rozhodne mene casu, nez do toho sami investujete.
Jestli chcete chranit data nebo sve algoritmy - dejte je k sobe na server a pristup jen pres API.
Jste milionty clovek co nechape, ze takto veci chranit nejde. A ochrana ve stylu "pokryt 99% uzivatelu" neni ochrana! Je to jenom promarneny cas a jine zdroje, ktere jste mohli investovat lepe.
-
Nějaký expert se tam vždycky nějak dostane. [...] a to bych chtěl mít zabezpečené pořádně.
Není to náhodou v rozporu?!
Zákazník nemá do raspi přístup. Má ho sice u sebe, ale žádného uživatele na raspi nemá.
Čili nejen že do raspi přístup má, ale efektivně má root přístup ke všemu před rozkódováním LUKSu. Může upravit libovolnou binárku, včetně ssh a jádra. Ergo žádné dobré řešení neexistuje.
-
Dobře, v tom máte pravdu, ale já to nemůžu dát k sobě na server, protože potřebuju, aby jim to fungovalo i bez internetu... :/
Tak já už nevím...Leda ten python překompilovat nějak.
-
Tak já už nevím...Leda ten python překompilovat nějak.
A nebo se na to schovávání vykašlat. Protože je to stejně k ničemu. Opravdu si myslíte, že je ta vaše implementace takový zázrak? Že to někdo jiný nedokáže napodobit i tehdy, když zdrojáky vůbec neuvidí, a bude zkoumat jenom to, jak se aplikace chová navenek z pohledu uživatele? Pokud ta vaše aplikace bude tak úžasná, že se bude masově krást, budete mít stejně tolik platících zákazníků, že vám to bude jedno.
-
Dobře, v tom máte pravdu, ale já to nemůžu dát k sobě na server, protože potřebuju, aby jim to fungovalo i bez internetu... :/
Tak já už nevím...Leda ten python překompilovat nějak.
Tak vam zbyva leda nejaka tezka obfuskace a sifrovani kodu ve stylu Skype. Klic k LUKSu by byl zasity primo v aplikaci a jeho dobyti by byl takovy opruz, ze se na to radsi vetsina lidi vykasle.
-
Dobře, v tom máte pravdu, ale já to nemůžu dát k sobě na server, protože potřebuju, aby jim to fungovalo i bez internetu... :/
Jak "fungovalo bez internetu"? Vždyť jsi říkal, že se má LUKS otevřít přes ssh. To jako to zařízení bude chvilku na netu a pak (bez ztráty napájení!) odpojeno?
Tak já už nevím...Leda ten python překompilovat nějak.
A jsme zase u toho: ujasni si, co chceš chránit a proti komu. Chceš chránit kód aplikace? Tak ji hlavně nepiš v pythonu! Nebo chceš chránit nějaký ty data (databázi)?
Hele, pokud s tím chceš fakt poradit, tak napiš naprosto polopaticky, co ta aplikace dělá, kdy je připojená k netu, kam ukládá data, co je v datech/binárkách citlivého, proti komu to chceš chránit. Jinak se tady budeme honit jak kočka s myší pořád dokola...
(Už teď je i tak docela jasné, že nejrozumnější by bylo se na pokus o ochranu vykašlat, jak radí kolegové, ale třeba se přece jenom nějaký rozumný kompromis najde, když situaci pořádně a polopaticky popíšeš)
-
Při startu RPI je potřeba internetu, ale pak může klidně vypadnout.
No my chceme automatizovat hospody a restaurace atd.
Máme tam pár věcí, které chceme dát placené, ale jako základ chceme dát zadarmo základní balíček víceméně jen čistě EET.
Tudíž s našemi servery to komunikuje v případě záloh toho raspberry nebo při komunikaci, jakou má zákazník licenci.
Poté také na našich serverech jsou určité části pro manažery podniku, když není zrovna ve vnitřní síti rpi.
Jinak všechen backend jede na djangu na raspberry. Nám jde o to, aby si člověk sám neodemkl plnou licenci jentak a samozřejmě, aby neukradli kód, ale není to nějaký extra terno. Tudíž chceme to raspberry zabezpečit aspoň proti klasickým uživatelům - barmanům atd. Dále chci mít co nejvíce zabezpečená data databáze, protože přecijen jsou to soukromé věci toho podniku.
-
Máme tam pár věcí, které chceme dát placené, ale jako základ chceme dát zadarmo základní balíček víceméně jen čistě EET.
Pokud vím, tak EET nemůže být trvale bez internetu. Jsou tam záložní postupy, jak řešit, když internet zrovna nejde, ale u obecně musíte počítat s tím, že zařízení bude připojené k internetu a jen ve výjimečných případech se odpojí, ne že nebude připojené k internetu a jen ve výjimečných případech se připojí.
Nám jde o to, aby si člověk sám neodemkl plnou licenci jentak a samozřejmě, aby neukradli kód, ale není to nějaký extra terno. Tudíž chceme to raspberry zabezpečit aspoň proti klasickým uživatelům - barmanům atd.
Barmany, kteří vám budou hackovat Python, bych klidně zanedbal. Až na nějakého takového narazíte, tak ho prostě zaměstnejte u vás - on si výrazně polepší, a vy vyřešíte problém s nelicencovaným použitím.
Dále chci mít co nejvíce zabezpečená data databáze, protože přecijen jsou to soukromé věci toho podniku.
To ale nemůžete zabezpečovat tak, že to vy budete otevírat nějakým klíčem na dálku. K těm datům byste neměli mít v ideálním případě přístup ani vy, naopak ten podnik by k tomu měl mít přístup. Šifrujte to bezpečným heslem nebo klíčem, který bude znát jenom ten podnik - zadá ho při startu, nebo ho tam třeba vloží nějaký USB token, nebo se odněkud naskenuje (záleží na tom, co tam máte k dispozici za hardware a jak se s tím zachází).
-
Já si četl specifikace a vím, že je tam nějaký buffer. My to chceme ovšem i pojistit 4G modemem. Řeknu to takhle. Jsou tam další věci krom EET, které prostě musí běžet na raspberry, protože raspberry je k nim připojeno přímo přes GPIO.
S tím zabezpečením databáze nevím. My tam mít přístup ani nechceme, ale když se stane nějaký problém a oni se na nás obrátí, tak bychom měli mít přístup všude, abychom to mohli co nejrychleji vyřešit.
-
S tím zabezpečením databáze nevím. My tam mít přístup ani nechceme, ale když se stane nějaký problém a oni se na nás obrátí, tak bychom měli mít přístup všude, abychom to mohli co nejrychleji vyřešit.
Hm. A jak to mate zabezpecene proti ztrate dat? Ta data jsou na cem? Na SD? To muze kdykoliv bez varovani odejit. Je nekde kopie, kdyz u vas na serveru zretelne ne?
Pokud vím, tak EET nemůže být trvale bez internetu. Jsou tam záložní postupy, jak řešit, když internet zrovna nejde, ale u obecně musíte počítat s tím, že zařízení bude připojené k internetu a jen ve výjimečných případech se odpojí, ne že nebude připojené k internetu a jen ve výjimečných případech se připojí.
Aha, to jako vazne? Takze stankari si budou muset poridit mobilni Internet, aby mohli prodavat burty?
-
Jinak všechen backend jede na djangu na raspberry. Nám jde o to, aby si člověk sám neodemkl plnou licenci jentak a samozřejmě, aby neukradli kód, ale není to nějaký extra terno. Tudíž chceme to raspberry zabezpečit aspoň proti klasickým uživatelům - barmanům atd. Dále chci mít co nejvíce zabezpečená data databáze, protože přecijen jsou to soukromé věci toho podniku.
No ale to je úplně jiná situace, než jak jsi to doteď popisoval :)
Takže chcete, aby se zákazník nedostal k funcím, které nemá licencované - na to je snadná odpověď: prostě mu je tam neinstalujte. A když si zaplatí, vzdáleně je tam nahrajete. Problem solved.
A databázi chcete tímpádem chránit úplně jinak a proti úplně jiné hrozbě (jaké? Krádež dat po netu vámi? Třetí osobou? Fyzická krádež média s daty?) Asi bych souhlasil s kolegama, že není potřeba nic vymýšlet - prostě jenom heslo/token, které ví/má jenom personál.
-
Aha, to jako vazne? Takze stankari si budou muset poridit mobilni Internet, aby mohli prodavat burty?
Můžou použít offline kódy a nahrát to večer z domova.
-
Hm. A jak to mate zabezpecene proti ztrate dat? Ta data jsou na cem? Na SD? To muze kdykoliv bez varovani odejit. Je nekde kopie, kdyz u vas na serveru zretelne ne?
-Jednou denně se synchronizují data s naším serverem, pokud je raspberry připojeno na internetu, který není mobilní.
Pokud vím, tak EET nemůže být trvale bez internetu. Jsou tam záložní postupy, jak řešit, když internet zrovna nejde, ale u obecně musíte počítat s tím, že zařízení bude připojené k internetu a jen ve výjimečných případech se odpojí, ne že nebude připojené k internetu a jen ve výjimečných případech se připojí.
Aha, to jako vazne? Takze stankari si budou muset poridit mobilni Internet, aby mohli prodavat burty?
[/quote]
Přesně tak. Mám variantu s 4G modemem...
-
Jinak všechen backend jede na djangu na raspberry. Nám jde o to, aby si člověk sám neodemkl plnou licenci jentak a samozřejmě, aby neukradli kód, ale není to nějaký extra terno. Tudíž chceme to raspberry zabezpečit aspoň proti klasickým uživatelům - barmanům atd. Dále chci mít co nejvíce zabezpečená data databáze, protože přecijen jsou to soukromé věci toho podniku.
No ale to je úplně jiná situace, než jak jsi to doteď popisoval :)
Takže chcete, aby se zákazník nedostal k funcím, které nemá licencované - na to je snadná odpověď: prostě mu je tam neinstalujte. A když si zaplatí, vzdáleně je tam nahrajete. Problem solved.
A databázi chcete tímpádem chránit úplně jinak a proti úplně jiné hrozbě (jaké? Krádež dat po netu vámi? Třetí osobou? Fyzická krádež média s daty?) Asi bych souhlasil s kolegama, že není potřeba nic vymýšlet - prostě jenom heslo/token, které ví/má jenom personál.
Jenže tam jde o to, aby člověk, který si extra služby zaplatí třeba na rok, je nemohl používat i po uplynutí doby. Jinak samozřejmě je tam instalovat nebudem, dokud to nebudou mít koupené.
-
Taky lze použít nějaký HW klíč a do něj nahrát licenci. Aplikace nemá HW klíč -> režim zadarmo. Aplikace má HW klíč -> platná licence -> režim za peníze, jinak režim zadarmo.
Problém je ten, že málokdo chce platit na HW klíče.
-
Problém je ten, že málokdo chce platit na HW klíče.
Pokud je premisa, že to má být odolné jenom proti normálnímu laikovi, tak se dají udělat i všelijaké levné skopičiny simulující hw klíč - třeba licenční soubor rozšifrovávat pomocí sériového čísla libovolného donglu (klidně pidi bluetooth dongle za pár kaček).
-
Jenže tam jde o to, aby člověk, který si extra služby zaplatí třeba na rok, je nemohl používat i po uplynutí doby. Jinak samozřejmě je tam instalovat nebudem, dokud to nebudou mít koupené.
Tak to už je váš problém, že jste si zvolili (z hlediska správy licencí) nepraktický licenční model "my vám něco dodáme jednou, ale vy budete platit měsíčně". Kdybyste zůstali u klasického "platba za dodání nové verze" nebo teď modernějšího "platba za pronájem remote sw" (jak psal RDa), tak byste tenhle problém neměli.
-
Nechapu co resite, proste to napiste mdularne s managerem ktery bude odemykat jednotlive poduly podle toho jaky klic dodate. Nicmene podle meho je to zastarale a pomerne nestasne reseni.
-
No a jak to udělat nějakým moderním řešením?
-
Takže. Zákazník nemá do raspi přístup. Má ho sice u sebe, ale žádného uživatele na raspi nemá.
Takže vyndám SD kartu a přidám si do /etc/passwd svého uživatele, ideálně s právy roota?
Riziko co mne napada:
- pokud ma zakaznik plnou kontrolu nad systemem, muze si vlozit do odemceneho LUKS svuj vlastni klic (ted z hlavy nevim zda je to treba pri uz otevrenem LUKSu autorizovat existujicim klicem nebo heslem)
"dmsetup table --show" ti ochotně ukáže klíče.
Chceš chránit kód aplikace? Tak ji hlavně nepiš v pythonu!
Dropbox má nějaký obfuskovaný Python, ale nerozumím tomu jak to dělají.
Pokud je premisa, že to má být odolné jenom proti normálnímu laikovi, tak se dají udělat i všelijaké levné skopičiny simulující hw klíč - třeba licenční soubor rozšifrovávat pomocí sériového čísla libovolného donglu (klidně pidi bluetooth dongle za pár kaček).
No což o to, nějakou jednoduchou challenge-response kryptografii by snad zvládla i AtTiny za 30 Kč a když se nastaví fuses, tak dostat to z toho je pěkná pakárna (typicky je potřeba čip rozpouzdřit a přímo na křemíku bity fyzicky nebo UVčkem flipnout). Ale pořád to má v Pythonu, takže si ten dešifrovaný kód stačí prostě zkopírovat.
Podle mě to předplacení na rok a používání potom bude eliminováno tím, že v EET budou furt dělat nějaké změny, takže zákazníkovi bude stará ukradená verze k ničemu.
nebo teď modernějšího "platba za pronájem remote sw" (jak psal RDa)
Tak takovou věc si celej žhavej běžím koupit. Abych nebyl závislý jenom na funkčnosti internetu a babišových serverů, ale ještě k tomu na nějakém startupu co řeší lamácké dotazy na rootu a doufal, že to nepoloží…
-
Dropbox má nějaký obfuskovaný Python, ale nerozumím tomu jak to dělají.
Obfuskátory na Python existují, stačí zagooglovat. Ale Python je prostě jeden z jazyků, které nejsou na utajovaný kód moc vhodné :)
No což o to, nějakou jednoduchou challenge-response kryptografii by snad zvládla i AtTiny za 30 Kč a když se nastaví fuses, tak dostat to z toho je pěkná pakárna (typicky je potřeba čip rozpouzdřit a přímo na křemíku bity fyzicky nebo UVčkem flipnout).
Jo, s ATtiny se dá udělat ledasco, i OTP :) Ale za tu cenu donglu z Číny to ve stejné estetické kvalitě nevyrobíš a efekt je stejnej - odradit laiky. Takže jestli je tam challenge response nebo jenom přečteš statický kód, je úplně jedno.
Podle mě to předplacení na rok a používání potom bude eliminováno tím, že v EET budou furt dělat nějaké změny, takže zákazníkovi bude stará ukradená verze k ničemu.
Taky si myslím. Ale OP zřejmě není tím, kdo by cenovou politiku tvořil... To už je úděl nás smrtelníků, nějak vyřešit nevhodná zadání ;)
Tak takovou věc si celej žhavej běžím koupit. Abych nebyl závislý jenom na funkčnosti internetu a babišových serverů, ale ještě k tomu na nějakém startupu co řeší lamácké dotazy na rootu a doufal, že to nepoloží…
Když budou v EET "furt dělat nějaké změny", tak jsi úplně stejně závislý na tom, jestli to položí nebo ne.
-
Ještě mě napadlo, co kdybych místo rpi použil něco, co má vnitřní paměť? Tudíž by aspoň nešlo sdčko dát jinam a nedostali by se pod jakéhokoliv usera.
-
@Darkhunter: Na Olimexech je nejaka NAND pamet. Udajne se nejakym lidem podarilo dostat na to Linux. Ja osobne jsem byl rad, ze se mi podarilo vygooglovat alespon jakousi funkcni image pro SD, protoze soudruzi z Olimexu jsou paka a nejsou schopni dodat funkcni minimalni obraz, ale pouze nefunkcni maximalni obraz a to pouze pro SD, ne pro NAND.
-
Ještě mě napadlo, co kdybych místo rpi použil něco, co má vnitřní paměť? Tudíž by aspoň nešlo sdčko dát jinam a nedostali by se pod jakéhokoliv usera.
neBGA NANDku jsem takhle dal bez přípravy přes noc. Odpájet, udělat breakout, připojit k MCU, přečíst (, zapsat, vrátit). Ale jo, lepší než SDčko.