Příspěvky

166

Software / Re:Crack hesla dokumentu MS Word

« kdy: 20. 10. 2017, 11:20:11 »

A nebo se zkusit zeptat Google na Office Password Recovery.
Doplním, že pro Linux existuje velmi málo software v porovnání k Windows a je trochu hloupé říct "nejlépe na Linux".

• Takový software obvykle není zadarmo
• Kdo mohl, nabízí to SAS nebo přímo Online, aby jim jejich produkty nikdo necrackoval
• Tohle se dalo vyřešit jedním dotazem do Googla, zbytečné zakládat téma
• Cracky VŽDY, ALE VŽDY pouštíme ve virtuálu, no a kdo ne, tak je trochu blbej

Sorry, jsem zlej...

No to sice jo, ale Google najde cokoliv, i cracky s virem. A nerekne, jaka je uzivatelska zkusenost. Proto se tazatel ptal tady.

Ja jsem to nikdy nedelal, ale neslo by to nejak otevrit v TXT editoru (gedit, vim), a heslo smazat ? Nekde tam je v parametrech. Sifrovany dokument nejspis nebude. Ale jisty si tim nejsem.

167

Software / Re:Nejlepší nastavení komprese v 7zip

« kdy: 20. 10. 2017, 11:12:51 »

Tady jsou vysledky testu 7z vs. paq8px

V pripade lzma2 je pro kazde zapocate vlakna u multi-threading alokovan v ram novy slovnik, proto byly pouzity jen 2 vlakna.
Maximalni velikost slovniku je 1536 MB, misto drivejsich 1024 MB. Maximalni slovnik zabere 16.5 GB RAM plus filelist.

Prikaz pro maximalni moznou kompresi je (co se mi podarilo najit a vyzkouset):
7z a -t7z -m0=lzma2 -mqs -mx=9 -mfb=273 -md=1536m -ms=on -ms=65536g -mmt=2 JmenoArchivu.7z

Pro maximalni kompresi 7z je dulezite uvest prepinac -mqs, jez radi soubory podle typu, jinak jsou razeny abecedne.
Starsi verze 7zip nemaji prepinac -mqs a radi soubory vzdy podle typu.

Rychlost podle typu CPU a dat 500-5000 kB/s, vetsinou 1000-2000 kB/s.
Dekomprese je mnohonasobne rychlejsi.
Drivejsi komprese lzma u starsich verzi 7z mohla byt o par setin lepsi,pri maximalnim 1024 MB slovniku, zato vic to sezralo RAM, pri velkem poctu souboru.
ms je velikost bloku, v GB, takze az do 65.536 TB je archiv z jednoho bloku. Ale nekdy si 7z udela dalsi blok s jinou metodou komprese, kdyz je ta metoda lepsi pro urcity typ dat.

U paq8px je moznost vyuzit jen rizdilnou velikost slovniku. Nejvetsi slovnik (prepinac -8) zabere neco prez 1600 MB RAM a jedno vlakno CPU.
Rychlost v zavislosti na CPU je 2-5 kB/s jen, 1 GB trva nekolik dni, u me okolo tydne.

1. archiv - hodne souboru Excel 2003 s grafy, daty, par textovejch souboru, nekolik malo (stovky kB) PNG obrazku.
Type = 7z
Physical Size = 129067144
Headers Size = 79190
Method = LZMA2:1536m
Solid = +
Blocks = 1
Folders: 213
Files: 6444
Size:       2 370 465 554
Compressed: 129 067 144
Doba vytvareni okolo 1.5 hodiny

Velikost paq8px: 126 906 868
Doba vytvoreni okolo 15000 minut. Jen tady vyhrava paq8px.

Druhy archiv - specialni textovy soubor velky presne 1 GiB. V tomto souboru jsou pouze jednicky a znaky noveho radku - aby to slo co nejvic zmensit.
Type = 7z
Physical Size = 156707
Headers Size = 138
Method = LZMA2:30
Solid = -
Blocks = 1
Size:       1 073 741 824
Compressed: 156 707
Doba vytvareni okolo 15 minut

Velikost paq8px: 378 374
Doba vytvoreni okolo 10000 minut

Treti archiv - PNG obrazky s barevnou hloubkou 8 bit, maximalni komprese PNG 9. Zde bude komprese 7z vicemene nulova.
Data maji jen 569 MiB, proto 7z zvoli maximalni mozny slovnik pro cely archiv 768 MB
Type = 7z
Physical Size = 596451652
Headers Size = 70334
Method = LZMA2:768m
Solid = +
Blocks = 1
Folders: 49
Files: 5867
Size:       634 094 047
Compressed: 596 451 652
Doba vytvareni okolo 7 minut

Velikost paq8px - 1 187 866 833 - naprosto necekane nastal narust.
Doba vytvoreni okolo 7000 minut.

Ctvrty archiv - mnoho rozsahlych i malych skriptu bash, jejich ruzne verze v case a par souradnicovych textovych souboru.
Vzhledem k ruznym verzim je podobnost mezi soubory vyskoka.
Type = 7z
Physical Size = 26653854
Headers Size = 101573
Method = LZMA2:1536m LZMA:20 BCJ2
Solid = +
Blocks = 2
Folders: 1208
Files: 13144
Size:       3 287 918 624
Compressed: 26 653 854
Doba vytvareni cca 2 hodiny

Velikost paq8px: 28 693 188
Doba vytvoreni okolo 22000 minut

Paty archiv - skripty a casto rozsahle textove soubory se souradnicemi. Lisi se vice-mene jen nastaveni, podobnost mexi soubory je obrovska.
Type = 7z
Physical Size = 44914889
Headers Size = 17300
Method = LZMA2:1536m
Solid = +
Blocks = 1
Folders: 60
Files: 2298
Size:       3 470 148 572
Compressed: 44 914 889
Doba vytvareni cca 2.5 hodiny

Velikost paq8px: 305 756 083
Doba vytvoreni okolo 28000 minut

Ted archiv s extremnim poctem souboru - vetsinou jsou t grafy - PNG obrazky 256 barev, konverze -quailty 95, rozliseni 1280x960
Krome grafu je asi 18% velikosti a 5% poctu souboru jako textova data.
Slovnik byl pouzit 1024 MB, 2 vlakna (jeden slovnik naraz). lzma si vzala 27 GB RAM, lzma2 20.5 GB RAM. Jen kontrola spotrebuje RAM 4103 MB virt, 3.9 GB RES.
Pri velkem poctu souboru je lzma2 uspornejsi na pamet nez lzma.
paq8px zde samozrejme nezkouseno, asi by to ani nemelo smysl.
Doba vytvareni 7z okolo 30 hodin (cca 3300 minut CPU casu)
Type = 7z
Physical Size = 58605641722
Headers Size = 86105422
Method = LZMA2:30
Solid = +
Blocks = 1
Folders: 451 319
Files: 10 344 588
Size:       98 566 411 542
Compressed: 58 605 641 722

Archiv s mnoho malymi soubory TXT. Soubory jsou hodne podobne, jeden tadovy soubor v ruznych verzich je na ruznych mistech.
Z duvodu hodne malych souboru je komprese (cca 40 hod) i rozbaleni (cca 10 hod) o dost pomalejsi.
Type = 7z
Physical Size = 307417835
Headers Size = 13591949
Method = LZMA2:30
Solid = +
Blocks = 1
Folders: 251
Files: 8 808 081
Size:       19 431 833 053
Compressed: 307 417 835
Archiv ma 294 MiB, bez pouziti -mqs okolo 1500 MiB. Pokud se data nejdriv zataruji, ma archiv okolo 1500 MiB. paq8px nezkouseno.

A jeste jeden archiv. Jedna se o slozku s desetitisici datovymi soubory v kazde verzi a tech verzi je 47.
Datove soubory jsou si v jednotlivych verzich dosti podobne. Podobnosti mezi soubory je tu mnoho.
Jeden tadovy soubor v ruznych verzich je na ruznych mistech.
Velikost dat je temer 2 TiB.
Pouzit byl slovnik 1024 MB, vzalo si to RAM 11.5 GB virt 11 GB RES.
Doba vytvareni 7z okolo 36 000 minut CPU casu, 23.3 dni to bezelo, prumerna zatez 106% CPU (2 vlakna na jeden slovnik v RAM)
Type = 7z
Physical Size = 3702993437
Headers Size = 8373990
Method = LZMA2:30
Solid = +
Blocks = 1
Folders: 86
Files: 1388977
Size:       2 022 208 880 899
Compressed: 3 702 993 437


paq8px SE TEDY ANI NEMUSI VYPLATIT, DOBRE NASTAVENY 7Z MUZE CASTO VYHRAVAT - 4 Z 5 PRIPADU VYHRAL 7zip.
Navic u paq8px je rychlost brutalne nizka, velka narocnost CPU. U paq8px je navic cca stejna narocnost rozbaleni jako zabaleni.
7z je pri rozbalovani mnohem rychlejsi - 10-15 MB/s archivu (nikoliv nerozbalenych dat, tam casto limituje disk).
7zip vyhrava tam, kde je velke mnozstvi hodne podobnych souboru, jinak si vede lip spis paq8px
paq8px nema kontrolu dat, rozbaleni i zabaleni trva hodne dlouho, neni mozne uzit multi-threading.

168

Software / Re:Nejlepší nastavení komprese v 7zip

« kdy: 16. 05. 2017, 22:30:35 »

Tak nove razeni podle jmena je od verze 15.06 - tam je moznost dvojiho razeni. Deafultne podle jmena abecedne, druha moznost je podle pripony-typu, prepinac -mqs , v graficke verzi pak zaskrtnuti volby qs. Predchozi verze radily vzdy podle pripomy-typu.
Razenim podle pripony-typu je komprese ucinnejsi a vysledny archiv mensi.

Celkovy prikaz pro maximalni kompresy od verze 15.06:

Kód: [Vybrat]

7z a -t7z -m0=lzma2 -mqs -mx=9 -mfb=273 -md=1024m -ms=on -ms=65536g -mmt=2 JmenoArchivu.7z

169

Software / Re:Nejlepší nastavení komprese v 7zip

« kdy: 16. 05. 2017, 20:07:29 »

Opet jeden dalsi test. Jednalo se o 91.72 GiB dat, grafy a texttove soubory. Celkovy pocet souboru je 10 344 588 a pocet slozek 451 319.

Textove soubory tvori priblizne 17-18% dat (okolo 16-17 GiB) textovych souboru je okolo 460 000, zbytek jsou grafy, png obrazky s kompresi quality 95, barevna hloubka 8 bit, rozliseni 1280x960.

Kód: [Vybrat]

p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,16 CPUs x64)

Nejdriv LZMA1:

Kód: [Vybrat]

7z a -t7z -m0=lzma -mx=9 -mfb=273 -md=1024m -ms=on Archive.7z

Vysledek:

Kód: [Vybrat]

Physical Size = 58343558019
Headers Size = 84804868
Method = LZMA:30
Solid = +
Blocks = 23

Everything is Ok                                                               

Folders: 451319
Files: 10344588
Size:       98566411542
Compressed: 58343558019

Po te jako LZMA2, jako jeden blok (jinak je velikost bloku deafultne 4 GB nebo 4 GiB, jak to bylo v prvnim pripade).

Kód: [Vybrat]

7z a -t7z -m0=lzma2 -mx=9 -mfb=273 -md=1024m -ms=on -ms=65536g -mmt=2 Archive.7z

Vysledek:

Kód: [Vybrat]

Physical Size = 58006341138
Headers Size = 84905891
Method = LZMA2:30
Solid = +
Blocks = 1

Everything is Ok                                                               

Folders: 451319
Files: 10344588
Size:       98566411542
Compressed: 58006341138

Pri velkem poctu souboru je LZMA2 uspornejsi na pamet podle vseho. V pripade LZMA1 to sezralo az 26.5 GB RAM,  v pripade lZMA2 "jen" 20.5 GB RAM, k dispozici je 32 GB.

Zatimco stara verze p7zip do verze 9.20 minimalne radila pri kompresi soubory nejdriv podle pripony, pak podle jmena, pak az podle umisteni v adresari, nova verze radi soubory presne abecedne podle cele cesty (nejdriv podle umisteni v adresari, pak podle jmena abecedne, pak az podle pripony). To ma za vysledek, ze u nove verze je vysledny archiv zbytecne vetsi, u specifickych dat to muze byt obrovsky rozdil.
Snad by tam mel byt nejaky prikaz, jak data radit korektne (tak jako v drivejsich verzich). Zatim nevim jaky.

170

Software / Re:Vytvoření AVI videa z obrázků

« kdy: 05. 05. 2017, 21:42:21 »

SHRNUTI

Vsechny navrhovane cesty prez seznamy a pod. nefungovaly, jen pomoci Glob pattern * to slo

Kód: [Vybrat]

ffmpeg -framerate 30 -pattern_type glob -i '*.png' -c:v h264 -s 2000x1000 -x264-params crf=0 OutputFile.mkv

Nerozbalilo to vsechny obrazky v RAM, obsazeni RAM je mensi nez 4 GB. Proces je multi-vlaknovy, az 12  vlaken ze 16 bylo vyuzito.

Ale vse se asi lisi s jinou verzi ffmpeg podle diskuze.

171

Software / Re:Sloučení stažených webových stránek do jednoho souboru

« kdy: 05. 05. 2017, 21:35:22 »

Dalsi moznosti je udelat ze slozky se soubory iso archiv (format ISO-UDF je lepsi). Z velkeho mnozsti souboru je pak jeden soubor, se soubory v nem se da pracovat bez extrakce. Staci iso soubor pripojit prez virtualni mechaniku. Je to vyhodne tak, kde mame hodne malych souboru ve slozce.

Tento obraz ISO-UDF neni vazan na konkretni velkost CD nebo DVD ale muze byt libovolne velky (desitky MB az treba nekolik TB). ISO bez UDF neumi v obraze soubory vetsi nez 2 GB a prilis dlouhe nazvy. UDF je mnohem volnejsi. Ale i tak jsou extreme dlouhe a slozite nazvy problem.

Obraz ISO-UDF neni nijak komprimovany, naopak zabira vetsi velikost o neco, nez soubory uvnitr. Je ale mozne obraz ISO cimkoliv zkomprimovat.

Vytvreni ISO obrazu ze slozky umi napr. ImgBurn (freeware pro widle, pri instalaci pozor, je tam adware). V Linuxu existuje i program, co to umi prez prikazovou radku (volne siritelny a bez adware), ted si nevzpominam na jmeno.

172

Software / Re:Kazi se archivy 7z ?

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

Jine soubory pokazene nemam.

Jak to poznáš? Některé soubory mají uvnitř checksumy, ale u spousty na první pohled nějaký jeden bitflip uprostřed vůbec nepoznáš.

Jako že zkopíruješ funkční archiv a na kopii to řekne, že to není archiv? Porovnej SHA256 hashe těch souborů a pak to binárně diffni… (předtím se možná vyplatí zahodit pagecache, echo 3 > /proc/sys/vm/drop_caches)

Kdyz dam kontrolu vsech archivu, tak to hodi porad ty same chybne (pravdepodobne chybne od vytvoreni pred cca 2 roky). Kontrola archivu by mela chyby odhalit. Kdyz zkopiruju funkcni archiv, porad je funkcni a soubory se binarne nelisi.

Naopak archiv, ktery ma chybu, tak ma chybu i na jinych mistech (zalohy). Muselo dojit k chybe pred 2 lety, na jinem PC, pred presunem na externi disk.

Zaheslovani neni chyba, to proste 7z napise spatne heslo. Jinak pri rekurzivni kontrole 7z t slozka/ to bere jako archivy vsechny soubory, bez ohledu na priponu. Tedy kdyz se u archivu zmeni pripona na avi, stejne to pozna ze jde o archiv a testuje to jako archiv (mimo jine zmenou pripony archiv, byt zaheslovany se rovnez neda ukryt).

Naopak u souboru,ktere archivy nejsou se to snazi otevrit jako archiv a hodi to hlasku, chyba, soubor neni archiv, bezohledu na priponu.

Rekurzivni kontrolu umi jen novy 7z (z roku 2016) , starsi verze ne.

173

Software / Re:Kazí se archivy 7z?

« kdy: 05. 05. 2017, 21:08:52 »

Mohu-li se zeptat, jestli ta úspora byla tak významná, že to stálo za to komprimovat s tak extrémním slovníkem, že mohla dojít paměť.

Uspora je jak kdy, podle typu dat a rozsahu podobnosti. U velkeho mnozstvi souboru je uspora 1024 MB slovnik oproti 64 MB slovkik 10-30 %, vyjimecne i 70% u specifickych dat. V naproste vetsine pripadu je vysledny archiv mensi minimalne (1-5 %), u obrazku pod 1% . Ale pamet by dojit jen tak nemela, i kdyz v par pripadech asi ano, pricina muze byt i jinde. Hlavni chybou je nedumyslna kontola dat.

Ad. Lol Phirae spamer. Tazatel na dotaz nesere, jen su nevsiml, ktere prispevky jsou nove.

174

Software / Re:Kazí se archivy 7z?

« kdy: 05. 05. 2017, 11:21:18 »

7z a -t7z -m0=lzma -mx=9 -mfb=273 -md=1024m -ms=on JmenoArchivu.7z

Podle man lzma (viz CompMem; je to sice LZMA2, ale myslím, že to sedí i na 7z) je skutečná spotřeba paměti při kompresi asi desetinásobek velikosti slovníku -- určitě bylo na stroji, kde se to komprimovalo, 10GB RAM? Pokud ne, tak to po zkomprimování příslušně velké části vstupu (něco jako velikost RAMky děleno deseti) zhavarovalo na nedostatek paměti.

RAM je dostatek, LZMA pri tomto slovkiku vezme 10,7 GB RAM, LZMA2 o neco mene (rozdil je tusim jen okolo 100-200 MB), celkem cca 11x nasobek slovniku. K dispozici je 16 MB RAM nebo i 32 GB RAM tak se to vejde OK (pri 16 GB RAM to zabere 67%). K tomu se ale jeste pricte filelist, coz je okolo 1-2 GB na milion souboru. Az na par extremu se to vejde vzdy i do tech 16 GB.

175

Software / Re:Kazí se archivy 7z?

« kdy: 05. 05. 2017, 11:15:57 »

Proč by to nemělo jít poznat? Ať před nohup nebo ne, tak to vrací nějaký exit code:

Kdyz poustim nohup, tak je to proto, ze terminal-putty muzu zavrit a proces bezi dal. Pak se da vystup najit v nohup.out, pokud to nepresmeruji jinam (do /dev/null/)

176

Software / Re:Kazí se archivy 7z?

« kdy: 04. 05. 2017, 18:45:12 »

A kdyz to jede prez nohup, neni poznat nic.

Proč by to nemělo jít poznat? Ať před nohup nebo ne, tak to vrací nějaký exit code:

No jo, kdyz uz si clovek myslel, ze skript funguje OK a presmeroval nohup dp /dev/null . Bez presmerovani jde vystup do nohup.out . On je ten soubor nekdy i docela velky a presmerovani do /dev/null setri systemove prostredky.

Mozna tam i nohup.out byl, ale pak jsem ho smazal s tim, ze vse je OK. Malokdo si zalohuje vystupy z terminalu.

177

Software / Re:Kazí se archivy 7z?

« kdy: 04. 05. 2017, 16:45:41 »

kdyz komprimuje, tak pise do stejne pojmenovaneho, ale rozpracovaneho nedokonceneho souboru nebo ma pracovni jmeno? jestli jo, tak to bude nepoznatelny, kdyz to zabije oom, tak to neni vada 7zip, ale spravce.

Pravdepodobne to bude cele reseni. Pri vytvareni archivu nejak dosla pamet, coz se muze stat nahlym spustenim jineho procesu navic, i kdyz by pamet dojit nemela. &z pak pri vycerpani RAM padne. A nekdy se nesmaze rozpracovany nedodelany archiv,i kdyz by mel. A kdyz to jede prez nohup, neni poznat nic.

Rozpracovany archiv ma stejne jmeno a neni poznat ze je nedokoncen. Nektera data k  archivu (filelist, typ komprese pod.) se pravdepodobne ukladaji az na konec archivu.

Pri kontrole ve Win32 s nedostatkem pameti (Pri 1024 MB slovniku je potreba je na kontrolu okoko 2,2 GB +Filelist) napsal 7z ze nestaci pamet, a tak jsem archiv ignorovoal, coz byla chyba. Dva zkazene archivy maji okolo milionu suboru, ale dalsi zkazene archivy tolik souboru nemaji.

Opravovat ma smysl mozna jeden archiv, ale asi by to vubec nebylo jednoduche, co jsem hledal.

178

/dev/null / Re:Co je to svet 4.0?

« kdy: 02. 05. 2017, 22:03:56 »

Uz ted se projevuji vazne bezpecnostni chybu (zejmena ze strany uzivatele) a pak nam tu chytre zarovky, kamery, meteostanice, rychlovarne konvice predstavuji silny bootnet.

Co teprve potom.

179

Software / Re:Kazí se archivy 7z?

« kdy: 02. 05. 2017, 21:59:33 »

Konverze CRLF/LF?

O zaheslovane archivy se nejedna. U tech se zepta na heslo, v pripade nohup napise jako chybu spatne heslo (pri nohup neceka na vstup).

180

Software / Re:Kazí se archivy 7z?

« kdy: 02. 05. 2017, 21:57:30 »

ByCzech

To prave spis ne ne - naopak spis zdechne v prubehu. Pamet VIRT si alokuje na zacaatku, a neresi moc, jestli je dostatek. Pamet RES az v prubehu a jak pamet RES stoupa, nekdy v prubehu komprimace proste zdechne.

Taky jsem to vyzkousel, a prave az po urcite dobe, kdy presahne pamet RES volne misto v RAM, to zdechne. Tedy v pripade, ze potrebna pamet je priblizne stejne velka, jako pamet, co je k dispozici. A to jak u stare, tak i nove verze. Hlaska k tomu je uplne stejna.

Kdyz je ale velikost slovniku o dost vetsi, nez co se vejde do RAM. tak to 7zip pozna a zahlasi hned na zacatku, proces se zastavi.

Takze vlastne jak kdy.

Právě jsem to vyzkoušel. Když to přeženu s velikostí slovníku, skončí to hned při startu na tuhle chybu:

Kód: [Vybrat]

ERROR: Can't allocate required memory!