Binarni serializace a vlastni za hesovani vystupniho souboru – .NET – Fórum – Programujte.com

Zdravim

Pomoci binární serializace na disk ukládám nějaká dat potud OK.

A já bych potřeboval ještě nějak zabránit to aby lidské oči v tom file nepoznaly žádný obsah. Myslel jsem na ZIP s heslem ale to mi přijde jako drbání se levou rukou za pravým uchem.

Nebyl by nějaký lepší nápad jak ty data "zakódovat"

 jsem v tomto vývojovém stadiu

 private static object LoadSave(string fn, object data)
        {
            IFormatter serializer = new BinaryFormatter();
            {
                if (File.Exists(fn))
                {
                    try
                    {
                        using (FileStream fs = new FileStream(fn, FileMode.Open))
                        {
                            return serializer.Deserialize(fs);
                        }
                    }
                    catch
                    {
                        File.Delete(fn);
                        return LoadSave(fn, data);
                    }
                }
                else
                {
                    if (data != null)
                    {
                        using (FileStream fs = new FileStream(fn, FileMode.Create))
                        {
                            serializer.Serialize(fs, data);
                        }
                    }
                }
            }
            return null;
        }

patřičné přetypování provádím až ve výše postaveném kodu

dik za každou myslenku

#1 VladislavK
Normálně bych použil vestavěnou kompresi, přidání je otázkou cca dvou řádků kódu.

http://msdn.microsoft.com/en-us/library/3z72378a%28v=vs.80%29.aspx

Díky za námět

ale ptám se ???? Tato technologie mi dovolí použít nějaký nějaký vlastní HAS klíč ????

nenašel jsem to tam.

Doplňující info:

Jde mi o to aby se jiný programátor byť za použití vlastní hlavy se k těmto informacím nedostal.

#3 VladislavK
Tomu se neubráníš, leda bys ty data zašifroval nějakým klíčem a uživatel by ten klíč musel zadat (nebo ho třeba načíst ze souboru apod.), protože pokud je zašifruješ bez klíče, tak stačí tvůj program disassemblovat a dešifrační algoritmus si tam najít.

Pokud přes klíč, tak nejjednodušší je třeba zkomprimovaná data zXORovat s nějakým klíčem a zpátky je dostaneš zase tak, že je znova zXORuješ s tím klíčem a pak rozbalíš.

Tomu se neubráníš

A zde je ten problém ja se tomu potřebuji ubránit - a nechce se mi tvořit nějaké pseudo bezpečné XORovaní spíše mi jde o nějaký nástroj (nejlépe od MS), který zavolám cca následovně

VypadneNejakyTyp xxx= publicVypadneNejakyTyp ZaBukujto(string filename, nejakyTyp mujklic);

FileStream fs=new.....

fs.write(xxx)

atd

Jo a ještě jedna myšlenka klidně bych použil WINApi, jen jde o to aby ta metoda / funkce byla historicky stabilní, neboli abych pro každou verzi widlí nemusel psát nějaké IFI

diky

O žádné takové funkci nevím, ale nevylučuji, že nějaká existuje, .NET poslední dobou tolik nesleduji.

Žádná ochrana není 100%, co to má být za aplikaci? Jak moc důležité je ty data mít nepřečtitelná?

ZXORování zkomprimovaných dat (vynechal bych hlavičku, z ní by se dalo celkem lehce začátek klíče vyčíst) je proti základním útokům dostatečně silná ochrana, při dostatečně dlouhém a různorodém klíči nemáš moc jak jednoduše ověřit, že je tvůj klíč správný, protože zkomprimovaná data jsou na první pohled jen shluk náhodných dat, takže třeba frekvenční analýzou z toho nic moc nevykoukáš.

Případně to místo XORování prohnat přes něco jiného, třeba AES :) .

#5 VladislavK
#7 Satik
Jenom doplnim: pokud je klic kombinaci nahodnych znaku a je stejne dlouhy jako text k zasifrovani, pak sifrovani metodou XOR je dosud jedina znama technicky neprolomitelna sifra. Musi se ale zarucit nahodnost, delka a utajeni klice.

V praxi je bohuzel tezke zajistit takovy klic, ktery splnuje tyto kritera. Proto je lepsi pouzit napriklad AES, kde klicem muze byt cokoli. .NET framework uz ma v sobe tridy, pomoci kterych lze jednoduse touto sifrou zasifrovat text/soubor. 

Celkove je ale uplne jedno co zvolis, protoze pokud ma potencionalni utocnik pristup k binarkam tve aplikace a ma dost schopnosti, a velkou motivaci, pak se urcite k temto tajnym datum dostane. Pouze mu to vic, nebo min zkomplikujes.

Popremyslej jestli znas nejakou pocitacovou hru, ktera nikdy nebyla cracknuta.

Taky se připojim a řeknu to asi takto... zvolil bych běžné šifrovací metody, případně přidal nějaký náhodný byte do výsledku, přeházel pořadí bytů podle klíče a úplně to postačuje.. případně přidej ještě certifikát pro dekódování (ale to už je extrém)

nemyslim si, že by to co děláš bylo tak velkolepý, že si všichni crackeři řeknou "joo, tohle musim prolomit..", teď to neber tak, že bych tě podceňoval, ale ruku na srdce... bylo už tolik lidí (včetně mě), co se snažili vymyslet speciální alg., aby byl neprůstřelnej, a bezpečnej, ale jakmile má uživatel přístup k binárce a může to dekompilovat a podívat se jak to funguje, tak ti i nejdokonalejsí alg. je na nic (a že to v .NET platí dvojnásob - snadno se dekompiluje)

věř, že drtivá většina lidí nemá moc zájem se snažit prolamovat zašifrovanej soubor i když má k dispozici  přímo zdroják

spíš bych se snažil to udělat tak, aby se používaly běžný technologie a bylo to rychlý a jednoduchý na použití, než vymýšlět super hyper ultra řešení, který ti dá jen uspokojivý pocit, ale výsledek bude stejný :)

PS: pokud se jedná u šifrování "sejvů" do hry, tak se vyser na serializaci, ale udělej vlastní binární zápis, kde následne výsledek hodíš do gzipu a případně proházíš bity podle klíče.. tohle bohatě stačí, je to celý rychlý a nečitelný

Díky všem

Už jsem se rozhodl že použiji AES - ještě jsem to nezpracoval.

Každopádně nejde o hru a ani o program v bankovním sektoru, a nad crackrem jsem vůbec nepřemýšlel tam je takřka 100% jistota že to prolomí.

Tady jde pouze o chytřejší Lamy kteří vědí že si ten malej BIN soubor otevřou v nottepadu a oči vidí a oči čtou. Současně vím že informace tam schované nemají takový význam aby si kvůli tomu někdo objednával a platil práci programátora. No a proto jsemnechtěl znova vymýšlet nějaký KSOROVACI mechanismus (i já to zkoušel) a myšlenka se ZIPEM mě napadla hned na začátku.

No a kde byl problém, neboli proč vzniklo toto vlákno. Vysvětlení je zcela jednoduché až k pozasmání

Zapoměl jsem na existenci System.Security.Cryptography takže příspěvek od P označuji jako řešení.

Diky všem   

#11 VladislavK

Tady jde pouze o chytřejší Lamy

V tom případě na to bohatě stačí ta komprese :)