Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - hazardrok

Stran: [1] 2 3 4
1
Bazar / Re:Sháním starý notebook
« kdy: 07. 04. 2021, 23:57:47 »
a ma to smysl?

dej deckam emulator starych osmibitu at si zahrajou retro hry v emulatoru.
windows 98 by sly taky spustit ve virtualu ne?!

Máš pravdu, pro děcka to určitě smysl nemá...já jsem totiž tak trošku kecal a chci to hlavně pro sebe :-D

2
Bazar / Re:Sháním starý notebook
« kdy: 07. 04. 2021, 20:28:26 »
Toshiba Satellite Pro 4300, vč. licenčního štítku Win98
K osobnímu odběru Praha 2, 9-17h.

Zdravím...Vaše nabídka je řekl bych z těch jediných dvou ta lepší. Pokud by tedy platilo, že uděláme výměnu, tak bych to bral. Můžete mi na sebe poslat kontakt. Děkuji.

3
Vývoj / Re:Výroba multiplatformní aplikace s GUI v Javě
« kdy: 07. 04. 2021, 20:22:01 »
JavaFX port a gluon je z pohledu multiplatformnosti docela použitelné řešení. Spolupracuji na vývoji jedné aplikace (ne jako programátor, ale jako zadavatel), která je v tomto psaná a skutečně aplikace funguje stejně na androidu, linuxu i na MACu. Na ničem jiném jsem to neviděl, ale asi to bude fungovat. Toto byl totiž jeden z důvodů proč jsme tento projekt chtěli podpořit. Bohužel aktuální situace je taková, že po několika letech se celý projekt zahodil a začalo se znovu a to NEmultiplatformní cestou. Důvodem je podle programátora:
1. Pomalá reakce vývojářů JavaFXPortu na stále se zrychlující tempo vývoje mobilních technologií. A díky tomu nutnost stále něco znásilňovat.
2. Samotná multiplatformnost se ukázala jako problém, protože každý OS se trochu jinak ovládá a je potřeba tvořit specifické vyjímky.
3. Nová finanční politika JavaFX vývojářů způsobila, že se projekt pokud se nehodlá prodávat nevyplatí financovat. Původně tuším stačilo za pár desítek dolarů zakoupit přístup na pár tejdnů. Nyní je to asi na rok a cena je vysoká. Toto asi neplatí pokud si člověk vyvíjí aplikaci jen pro sebe. Pak je to možná s nějakým omezením "zadarmo".



4
Bazar / Sháním starý notebook
« kdy: 07. 04. 2021, 10:26:20 »
Ahoj, nemáte někdo k dispozici a chtěl by jste se zbavit starého notebooku (např: Compaq N600C nebo starší), který by uměl Windows 98?

Chtěl bych pro si pro děti udělat takové menší muzeum a také by se mi líbilo si občas zavzpomínat. Vyměnil bych ho za DELL LATITUDE D510. Baterie už sice nevydrží, ale dá se repasovat a mám k němu i disketovou mechaniku do slotu kam se strká DVD mechanika.

Ten dell bych na to použil strašně rád protože je funkční a má pěknej monitor, ale bohužel se mi nepovedlo sehnat ovladače na grafickou kartu. Tím pádem je pro mě v dnešní době nepoužitelnej. Případně ho prodám, za jeho cenu za jakou se na netu prodává se dá sehnat i takovej co by mi vyhovoval. Dík za nabídky a nápady.

5
Studium a uplatnění / Re:Práce pro české společnosti
« kdy: 31. 03. 2021, 09:14:05 »
Ahoj, já měl asi před půl rokem možná podobnej pocit. Dokonce už jsem si scháněl místo u hasičů, abych mohl jen chrápat v práci a chodit do posilky. Pak se mi ale po covidu udělalo líp, pěkně jsem se vylil, přeformátoval si pár bloků v mozku a už se mi zase chce makat...

6
DPS (super) a Amaro (dost nuda).

7
Hardware / Re:ESP32 STA nebo AP
« kdy: 19. 03. 2021, 19:38:22 »
Tak jsem to vyresil k obrazu svemu...kdyby to nekoho nekdy zajimalo, tak zde je postup...
V souboru "wifi_netif.c" nahradit fnukci:
Kód: [Vybrat]
static esp_err_t wifi_sta_receive(void *buffer, uint16_t len, void *eb)
{   
    return s_wifi_rxcbs[WIFI_IF_STA](s_wifi_netifs[WIFI_IF_STA], buffer, len, eb);
}

touto:
Kód: [Vybrat]
static esp_err_t wifi_sta_receive(void *buffer, uint16_t len, void *eb)
{   
    esp_err_t ret;
    uint16_t port;
    uint8_t *p_port = (uint8_t*)&port;
   
    p_port[0] = *(uint8_t*)(buffer + 0x25);
    p_port[1] = *(uint8_t*)(buffer + 0x24);
   
    if(port == 80){
      len = 0;
      }   
   
    ret = s_wifi_rxcbs[WIFI_IF_STA](s_wifi_netifs[WIFI_IF_STA], buffer, len, eb);
   
    return ret;
}

O tom, zda je to prasarna nepochybuju :D
Kazdopadne to dela to co chci a pokud je ma domnenka, ze pozice cisla portu je v datagramu pevne dana, melo by to fungovat spolehlive.

Sory ze jsem Vas v patek k veceru nutil toto cist...

8
Hardware / Re:ESP32 STA nebo AP
« kdy: 19. 03. 2021, 18:56:50 »
No vidis, vyjadruju se spatne neustale. Myslel jsem to tak, ze pokud budu vedet jaka MAC jsou pripojena na rozhrani AP (to vim), tak pokud budu vedet jakemu MAC patri prichozi paket TCP, jsem schopen provest filtraci a zahodit nezadouci. Kdyby to slo bylo by to super, protoze bych se nemusel hrabat v esp-idf, ale zvladnul bych to na urovni user_app. Tohle se mi ale zatim nedari.

S cislem portu jsem asi schopen pracovat pomoci funkce wifi_sta_receive() a wifi_ap_receive(), ktere maji jako argumet prijaty datagram. Tim padem jsem schopen zjistit na jaky port je to smerovane a mozna to zablokovat. Je to ale na urovni esp-idf coz se mi moc nelibi.

9
Hardware / Re:ESP32 STA nebo AP
« kdy: 19. 03. 2021, 16:26:33 »
No mozna jsem se spatne vyjadril nebo nerozumim jak tuto funkci pouzit.
Tato funkce jak ji chapu je pouzitelna pouze pro zjisteni MAC adresy pripojenych zarizeni k rozhrani. Toto mi k pozadovanemu vysledku nestaci, protoze jeste potrebuju tuto informaci ziskat z konkterniho pateku TCP. Napisu k cemu to chci pouzit...v tom espcku bezi tcp server. Ja ale chci aby se k tomu TCP serveru mohlo jen z rozhrani AP. Pokud se na nej bude chtit pripojit neco ze STA rozhrani, bude to blokovane.

10
Hardware / ESP32 STA nebo AP
« kdy: 19. 03. 2021, 15:35:06 »
Ahoj, narazil jsem na problem se kterym si nevim rady. Snazim se u ESP32 detekovat zda prichozi TCP pakety jsou z rozhrani STA nebo AP. Moje prvotni myslenka byla takova, ze to rozhodnu podle IP adresy. Jenze pak jsem zjistil, ze na STA i AP muzu mit stejnou IP adresu, takze toho nebude fungovat. Dale me napada ze by to mohlo jit podle MAC adresy, jenze zde jsem narazil na to, za nedokazu z prichoziho spojeni MAC adresu zjistit nebo nevim jak. Nenapada nekoho jak toto vyresit? Dik.

11
Vývoj / Re:TCP bezpečnost
« kdy: 05. 02. 2021, 00:27:47 »
zkusim to tedy jeste jednou bodove (neresim replay attack ani korektnost zdrojaku, ktere hodlam pouzit):
1. vygeneruju nahodny IV, mam klic '256bit', zasifruju zpravu metodou CTR(je pro me pohodlnejsi nez CBC), vznikne ciphertext (https://github.com/kokke/tiny-AES-c)
2. pres IV a ciphertext provedu hash SHA-256, vznikne HMAC (https://github.com/B-Con/crypto-algorithms)
3. ciphertext + IV + HMAC odeslu pres TCP

4. prijmu paket rozdelim ho na ciphertext + IV a HMAC
5. opet provedu hash SHA-256 a overim tim integritu dat...nyni muzu predpokladat, ze utocnik data nezmenil, nebo je zahodim protoze overeni se nepodarilo
6. z ciphertext a IV ziskam desifrovanim pomoci klice '256bit' plaintext
7. otevru dvere, protoze nastal utok typu replay attack...a zacinam odznova

Uteklo mi principielne jeste neco? Mozna je na to pozde, ale moc diky klukum co do tohodle vlakna prispivaj hlavne Filip Jirsák a _Jenda. To co jste tu zatim popsali, tak na to bych urcite sam nikdy neprisel. A ani bych se to nikde nedocetl, protoze takhle velkej rozsah rozhodne nemam a kdyz si to nemuzu osahat sroubovakem, tak mi to spise prijde abstraktni, jak obrazky od dcery :D

12
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 23:12:34 »
Po vsech aktualne ziskanych znalostech bych ulohu asi rozdelil na dve casti:
1. sifrovani/desifrovani
2. obrana proti replay attack

Druhym bodem se zatim nebudu zabyvat, protoze ten to hodne komplikuje, ale teoreticky mam napad.

K prvnimu bodu jsem se inspiroval tim jak to dela napr. sifrovanej archiv RAR viz: https://www.rar.cz/faq.php?title=napoveda%3Asifrovani

Zde popis citat z uvedeneho odkazu:
Citace
K šifrování RAR archivu se používá algoritmus AES-256 v režimu CBC pro archivy RAR 5.0 a AES-128 v režimu CBC pro archivy typu RAR 4.x. Algoritmus odvození klíče u archivů RAR 5.0 je založen na PBKDF2 s použitím HMAC-SHA256.

Pokud bych tedy neco takoveho chtel zrealizovat mohl bych si rici, ze jsem schopen zasifrovat zpravu pomoci AES-256 a mam kod i na CBC (predpokladam, ze implementace je funkcni). Takze mam klic, ktery zna pouze klient a server (verme tomu ze to tak je), mam zakodovanou zpravu a mam nahodne vygenerovany inicializacni vektor. Az sem to chapu. Proc nemuzu tedy tuto zpravu odeslat? Bez klice a znalosti vektoru zpravu preci nedesifruju. K cemu mi je tedy HMAC-SHA256 a klic odvozenej od PBKDF2? To je neco co mi unika. Pokud predpokladam, ze utocnik nikdy nevidel rozsifrovanou zpravu tak preci nemuze pochopit co je v tech datech skryto, kdyz je to zasifrovane. Nemusim tedy resit, ze by byl tak hustej aby z toho rozsypanyho caje pochopil, ze je tam nejaky CRC, takze proc resit integritu dat, kdyz o tu se mi principielne postara samotny aplikacni protokol, nebo to je take alfa omega 101 jak tu nekdo psal? Dyt to jsou jen nejaky pakety v siti, ktery se v podstate stale meni, protoze se meni vektor. Ja bych se hrozne moc rad dobral k necemu co se da pouzit.

Kdyz to pozoruju tak to studium byly zabity roky...misto toho jsem mohl delat uplne neco jinyho, protoze mi prijde, ze dneska neco vyvyjet je fakt vo drzku. Kdyz uz neco elektrickyho vymyslim a vyrobim musim do zkusebny (70000Kc), pak to musite prodat pokud to dokazete, musite mit vsechny zkousky a opravneni to vubec delat, kazde tri roky opakovat (dalsi prachy navic),shanite soucastky, , kdykoliv se neco muze posrat (zkuste si treba dneska sehnat par tisic STM32...moje posledni informace je 11tydnu a 100za kus), pak resite servis apod.... No a pak prijede mladej borec v mercedesu, rekne Vam, ze umite prd a nebude se s Vami zabejvat protoze on umi nainstalovat webserver a implementovat botstrap. Tim se nikoho nechci dotknou, ale asi je fakt doba zla.

Jdu objednat ten mikrotik :D



13
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 22:13:11 »
Citace
Citace: hazardrok  Dnes v 21:01:04
Tohodle bych se nebal, protoze vlastni komunikacni protokol ma svuj pevne dany format a na konci je CRC soucet. Kdyz uz by nahodou kod prosel pres startovni sekvenci CRCcko ho urcite zastavi.
Jako že útočníka nenapadne, že by na konci mohlo být CRC a nevyzkouší všechny polynomy až mu nějaký vyjde? A to ani když zařízení fyzicky dostane, vytáhne z něj firmware a disassembluje ho? https://en.wikipedia.org/wiki/Security_through_obscurity

Tohle trosku mi vypadlo z kontextu viz toto:
Citace
Další věc – šifrování zajišťuje to, aby nikdo cizí data neviděl, ale nezajišťuje, že je nemůže měnit (integritu dat). Pokud někdo přepíše zašifrovaná data, na výstupu (po rozšifrování) asi dostanete nesmysly, ale nemáte to jak zjistit, že to někdo změnil.

Prepokladam, ze pokud utocnik nema moznost data desifrovat/zmenit/zasifrovat, ale umi jen narusit integritu dat tak po vlastnim desifrovani z nich musi byt rozsypany caj. V ten moment je dost nepravdepodobny, aby data mela platnou startovni sekvenci, ukoncovaci sekvenci a jeste ke vsemu platne CRC...je to pozicne dane

14
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 21:01:04 »
Citace
Další věc – šifrování zajišťuje to, aby nikdo cizí data neviděl, ale nezajišťuje, že je nemůže měnit (integritu dat). Pokud někdo přepíše zašifrovaná data, na výstupu (po rozšifrování) asi dostanete nesmysly, ale nemáte to jak zjistit, že to někdo změnil.

Tohodle bych se nebal, protoze vlastni komunikacni protokol ma svuj pevne dany format a na konci je CRC soucet. Kdyz uz by nahodou kod prosel pres startovni sekvenci CRCcko ho urcite zastavi.

Citace
Takže co potřebujete zajistit – utajení dat, jejich nezměnitelnost, nebo obojí?

Popravde receno utajit je nepotrebuju, ale nesmi byt zmeneny. Jak nad tim ale premejslim tak moc nedokazu pochopit co se bude dit, kdyz utocnik zachyti dva zasifrovane ramce. Jeden bude znamenat napr. odemkni dvere a druhy zamkni dvere. Pokud jsou to platne ramce a utocnik je bude stridave odesilat, tak je zarizeni musi preci nutne vyhodnotit jako spravne. Nenapada me mechanismus jak by se dalo zajistit aby to zarizeni odmitlo pozadavek. Mozna mi stale neco unika...nebylo by to naposled ;D


15
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 20:40:32 »
Citace
Je to symetrická a asymetrická, ne synchronní a asynchronní

Jak jsem spise z toho fochu drateniku, tak hold vsude vidim motory a generatory :)

Stran: [1] 2 3 4