vineri, 5 iulie 2019

Scranos

Stire de la Bitdefender care poate  va intereseaza ...

"Specialiștii Bitdefender au descoperit că atacatorii din spatele amenințării informatice Scranos, apărută la finele anului trecut, au găsit un nou mod de a infecta victime, după ce Bitdefender a desființat mecanismul exploatat inițial prin care se răspândea.
Infractorii manipulează acum programe legitime ale Microsoft cu ajutorul cărora își asigură persistența pe dispozitiv. Bitdefender a sesizat autoritatea emitentă a certificatului digital care masca amenințarea Scranos în legătură cu compromiterea și folosirea ilicită a acestuia, iar semnătura digitală a driverului a fost apoi revocată pentru suspiciuni temeinice de activități frauduloase. Astfel, atacatorii s-au văzut nevoiți să găsească un alt vector de atac.
Dacă inițial Scranos infecta victime prin programe aparent legitime disponibile pe site-uri de piraterie, precum e-readere, playere video, drivere sau chiar soluții de securitate, acum amenințarea este diseminată printr-o aplicație nouă, denumită CClear, care, în teorie, optimizează funcționarea calculatorului. Atacatorii mizează pe denumirea similară cu CCleaner, un instrument legitim binecunoscut, ca să determine utilizatorii să instaleze programul infectat.
Scranos are acum noi funcționalități, suplimentare celor inițiale când sustrăgea toate parolele și informațiile bancare ale victimelor și le compromitea activitatea pe rețelele de socializare. Astfel, noul Scranos permite atacatorilor să redirecționeze traficul de pe orice site accesat de utilizator către cele proprii și, în plus, să injecteze cod în paginile vizitate ca să afișeze reclame. După ce instalează programul infectat, Scranos oprește serviciile de securitate ale Windows, folosește calculatorul victimei ca să mineze monedă virtuală și întreprinde atacuri de tip DDoS ca să paralizeze pagini de internet. Funcționalitățile legate de furtul datelor din contul de Facebook rămân în continuare des întâlnite.
Originar din China, Scranos a fost descoperit de specialiștii în securitate informatică ai Bitdefender în luna aprilie, când se răspândea agresiv în Europa și Statele Unite și contamina dispozitive cu Windows și Android, având acces la toate datele personale ale victimelor.
Pentru a evita infectarea cu Scranos, recomandările pentru utilizatori sunt să descarce și să instaleze numai aplicații licențiate, să verifice suplimentar numele programelor pe care le instalează, să folosească o soluție de securitate performantă și să actualizeze mereu sistemul de operare și programele folosite la cea mai recentă versiune. "

sursa: www.bitdefender.ro/news/

AUTOSAR(6)- Communication Services In AUTOSAR – CAN Network Management (CanNm)


În acest articol vom discuta despre interfața NM (Network Management) și modulul NM specific pentru magistrala CAN, care fac parte din stratul de Servicii al arhitecturii Software Layered AUTOSAR.

Interfața de gestionare a rețelei:

Interfața de administrare a rețelei este un modul între modulul ComM și modulul NM (specific pentru un anumit tip de bus - CAN, LIN, FlexRay, Ethernet). În acest articol vom lua în considerare CANNM ca  parte a NM.
Interfața NM are două funcționalități:


  • Funcționalitatea de bază - este să acționeze ca un modul de adaptare între modulul NM  și modulul ComM. Interfețele pentru comunicații între interfața NM și modulul ComM sunt independente de bus.





  • Coordonator NM - utilizat de ECU-ul gateway-ului pentru a opri sincronizarea bus-urilor de comunicații. Utilizează un algoritm de coordonare NM pentru a opri busu-urile de comunicare la care este conectat un ECU. Un ECU care utilizează funcționalitatea NM este denumit Coordonator NM.


Oprirea trebuie să fie coordonată în rețeaua care este trează (comunicatie activă) și nu în modul "Bus-Sleep". Rețeaua care se află în modul "Bus-Sleep" este monitorizată. Atâta timp cât o magistrală din clusterul de coordonare (NM Cluster - Set de noduri NM coordonate cu utilizarea algoritmului NM) este trează,atunci coordonatorul NM trebuie să mențină în continuare rețeaua trează (comunicatie activă).

Când algoritmul de coordonare este pornit, se lansează un temporizator de întârziere de oprire pentru canalele actuale active în rețeaua de coordonare. Când expiră temporizatorul de oprire a închiderii, NM ar trebui să elibereze rețeaua NM. Când toate rețelele au fost lansate și toate rețelele sunt în modul "bus-sleep", închiderea coordonată a fost finalizată.

CAN Network Management:

CANNM are rolul de a coordona tranziția între modul normal de funcționare și modul "bus-sleep" al rețelei. Acesta poate fi, de asemenea, utilizat pentru a detecta toate nodurile prezente sau pentru a detecta dacă toate nodurile sunt gata să treaca in modul "sleep" în rețea.

CANNM pentru fiecare ECU trebuie să efectueze activități autosuficiente în funcție de PDU-urile de management al rețelei, care sunt recepționate sau transmise în cadrul sistemului de comunicații.

Algoritmul CANNM se bazează pe PDU-uri periodice de administrare a rețelei, care sunt recepționate de toate nodurile din cluster prin transmisie . Recepția PDU-urilor de gestionare a rețelei indică faptul că nodurile de trimitere doresc să țină clusterul de gestionare a rețelei trezite. Dacă un nod este gata să meargă în modul Bus-Sleep, acesta nu mai trimite PDU-uri de administrare a rețelei, dar atâta timp cât sunt primite PDU-uri de gestionare a rețelei de la alte noduri, acesta amână trecerea la modul Bus-Sleep. În cele din urmă, dacă scade un cronometru dedicat deoarece nu mai sunt primite PDU-uri de gestionare a rețelei, fiecare nod inițiază trecerea la modul Bus-Sleep.

Dacă un nod din clusterul de gestionare a rețelei necesită o comunicație prin magistrală, acesta poate să trezească clusterul de gestionare a rețelei din modul Bus-Sleep prin transmiterea PDU-urilor de administrare a rețelei.



Conceptul CANNM se bazează pe:

Nodul de rețea din clusterul NM ar trebui să transmită periodic mesaje NM până când are nevoie de acces la magistrala, altfel nu ar trebui să transmită niciun PDU NM.
Dacă este lansată comunicarea prin magistrala într-un cluster CanNm și nu există PDU-uri de administrare a rețelei pe magistrală pentru o perioadă de timp configurabilă determinată de CANNM_TIMEOUT_TIME + CANNM_WAIT_BUS_SLEEP_TIME (ambii parametri de configurare), se va efectua trecerea în modul Bus-Sleep.

Stările diferite pentru CANNM:

REPEAT MESSAGE: Fiecare ECU transmite propriul mesaj NM ciclic până la expirarea timerulului configurabil.

READY SLEEP: ECU este gata de "Sleep", nu este transmisă niciun mesaj NM, timerul este repornit când este recepționat un mesaj NM.

NORMAL OPERATION: Transmisia mesajelor NM și repornirea timer-ului la expedierea și recepția mesajelor.

PREPEARE BUS SLEEP MODE: Dacă expiră timer-ul și nu a fost transmis sau primit niciun mesaj NM.

BUS SLEEP MODE: Dacă un timer ajunge la limită, atunci rețeaua trece la modul Bus-Sleep, în care nu se poate comunica  pe magistrala.

Weekend plăcut tuturor!

joi, 23 mai 2019

Quadcopter (8) - Versiunea 3

Descriere proiect:
Am făcut un re-design la dronă, și i-am montat motoare noi. Cadrul de plastic l-am înlocui cu tije de aluminiu de 50cm montate în cruce. În rest configuratia electronica, controlerul Hkpilot, GPS-ul, controler radio, controlerele de viteza pentru motoare (ESC-urile) și power distribution board le-am păstrat. Testele fără elici au mers bine, calibrarea compasului deasemenea , la fel accelerometrul si calibrarea pentru radio au mers brici. Dar cred ca e prea frumos să fie adevărat și testul suprem este zborul efectiv.

Documentatie proiect:
Componente:


Configuratia elicilor:
Greutatea fara elici este de 650 de grame:
GPS-ul este montat sus (cu LED-ul verde):
Noile motoare Turnigy D2205-2300KV 28g Brushless montate pe conectorii făcuți de mine:
Controlerul radio si conexiunile, cutiuta neagra cu multe fire:

Imagine de ansamblu:
Urmează testul de zbor. O seară faină tuturor!

miercuri, 8 mai 2019

AUTOSAR(5) - ComStack CANTP

În acest articol vom discuta despre interacțiunea dintre module precum PDU Router (Layer Services), Layer de transport CanTP (Layer Services), CanIf (Layer Abstraction ECU) și CAN Driver (MCAL Layer). Acest articol va fi mai concentrat pe modulul CanTp, deoarece celelalte module sunt discutate în articolele anterioare. Dar se va atinge de celelalte module (PduR, CanIf și CanDrv) atunci când există o interacțiune între ele și CanTp.

CAN Transport Layer

Serviciile de bază oferite de modulul Can Tp sunt segmentarea mesajelor care au o sarcină utilă de peste 8 octeți, transmiterea mesajelor cu controlul fluxului și reasamblarea mesajelor segmentate la receptor.

În imaginea de mai jos este reprezentat un frame CAN, iar in segmentul Data ar fi informația utilă. În cazul nostru informații de diagnoză specifice CanTp. Pentru cazul în care semnalele CAN urmează să ajungă în modulul COM -> RTE iar apoi in applicatie, atunci cei 8 bytes de date contin semnalele utile.



Modulul CanTp trebuie să respecte standardul ISO 15765-2 pentru segmentarea mesajelor, transmisia segmentată și reasamblarea datelor segmentate. Protocolul de transport este folosit în principal pentru comunicarea peer-to-peer în CAN.

Protocolul ISO-TP

ISO 15765-2, cunoscută și ca ISO-TP, este un standard pentru trimiterea de pachete pe magistrala CAN care extinde limita CAN de 8 octeți pentru a suporta până la 4095 octeți prin legarea pachetelor CAN împreună. Cea mai obișnuită utilizare a ISO-TP este pentru diagnosticare (vezi "Servicii de diagnoză unificată") , dar poate fi fo,losit și în orice moment, pentru a transfera cantități mari de date.

Network Layer Protocol efectuează transmiterea / recepția de date de până la 4095 octeți și raportarea finalizării transmisiei / recepției.



Single Frame (SF) Transmisie:

Transmiterea / recepția mesajului de până la 7 octeți de date se realizează utilizând un N_PDU unic. Frame-ul unic este utilizat de către tester numai în cazul adresării funcționale în care testerul nu cunoaște adresa fizică a ECU sau dacă funcționalitatea ECU-ului este implementată ca un server distribuit pe mai multe ECU-uri.

Transmisie cu mai multe cadre:

Transmiterea mesajelor cu octeți de date mai lungi se realizează prin segmentarea mesajului și transmiterea ca mai multe N_PDU-uri. Recepția se realizează prin reasamblarea mai multor receptoare N_PDU.

First Frame (FF): Unitatea de date FF conține cea mai mare parte a lungimii datelor în octeți care va face parte din cadrul consecutiv (CF), iar octeții rămași pot fi utilizați octeți de date.

Flow control (FC): Receptorul are posibilitatea de a adapta capacitatea transmițătorilor folosind cadrul FC. Utilizând cadrul FC, receptorul poate solicita emițătorului să trimită octeți de date cu o anumită dimensiune a blocului (BS - numărul maxim de N_PDU, receptorul permite expeditorului să trimită înainte ca acesta să permită expeditorului să trimită din nou N_PDU) și la o rată fixă ​​(STmin - timpul minim pe care expeditorul trebuie să îl aștepte înainte de transmiterea următorului N_PDU consecutiv), astfel încât receptorul să proceseze datele recepționate.

Consecutive frame (CF): Conține octeții de date transmise împreună cu numărul de ordine (SN) care specifică numărul CF și acest SN este utilizat în timpul asamblării datelor la receptor.


Există mulți parametri de sincronizare implicați în comunicarea protocolului de transport. Mergeți la ISO 15765-2 pentru descrierea tuturor acestora.

Luați în considerare dacă 49 octeți de date trebuie transmise folosind adresarea obișnuită, atunci fluxul PDU ar putea să arate, primul cadru va conține numărul de octeți care urmează să fie transmiși, 49 numărul de CF-uri care vor fi utilizate pentru transmiterea acestor 49 octeți, 7. Cadrul FC va avea valorile BS și STmin specifice receptorului. Cele șapte cadre CF vor conține octeții de date.

Interacțiunea CanTp cu alte module

CanIf interacționează cu CanTp si va apela functiile TxConfirmation și RxIndication pentu primirea si trimiterea de PDU-uri.

CanTp nu are propriul buffer, deci folosește bufferul straturilor superioare (PDUR, DCM sau COM). Deci, pentru a menține consistența datelor în timpul Tx / Rx, bufferul este blocat. În timpul recepționării datelor, modulul CanTp notifică stratul superior (PDUR), iar stratul superior își rezervă și blochează bufferul pentru recepție.

Dacă stratul superior nu poate creea bufferul  disponibil pentru recepție din cauza unei erori sau a unei limitări a resurselor, acesta returnează o eroare. Apoi CanTp întrerupe recepția și transmisia cadrului FC depinde de codul de eroare din stratul superior.

În timpul transmisiei, CanTp utilizează formatul de adresare pentru a trimite cadrele SF, FF și CF. Transmisia poate să nu funcționeze dacă straturile superioare nu pot pune la dispoziție datele de transmisie înainte de trecerea timpului intern (consultați ISO 15765-2). CanTp reia transmisia atunci când datele sunt disponibile din stratul superior.

Modulul PDUR este notificat în prealabil cu un început de notificare de recepție atunci când primește un primul frame (FF) sau un singur frame (SF). Acest apel va fi trimis la modulul stratului superior respectiv. Sarcina utilă a fiecărui segment (N-PDU) este copiată în modulul stratului de destinație superior (DCM). După recepția ultimului N-PDU, modulul CanTP va indica modulului  PDUR că primită I-PDU-ul complet și modulul PDUR va transmite această indicație către modulul stratului superior respectiv.



Operația de transmisie a modulului PDUR este declanșată de o cerere de transmitere a unui PDU de la un modul sursă și înaintează cererea către un modul de pe un strat de destinație inferioară. În timpul transmisiei, PDUR nu stochează PDU-ul.

Gateway-on-the-fly: rutarea între două module TP unde se pornește redirecționarea datelor (când se atinge un prag specificat) înainte ca toate datele să fi fost primite. Dacă este transferată o cantitate mai mare de date între două interfețe, este de dorit să puteți porni transmisia în rețeaua de destinație înainte de a primi toate datele din rețeaua sursă. Acest lucru economisește memoria și timpul.

Bonus:
The Car Hacker's Handbook: A Guide for the Penetration Tester - Craig Smith (2016)

duminică, 14 aprilie 2019

AUTOSAR(4) - ComStack CAN

În acest articol vom discuta despre serviciile de comunicare în AUTOSAR w.r.t. Protocolul CAN. În acest articol mă voi limita la module CAN Interface (CanIf) și CAN Driver (CanDrv). Alte module ale ComStack referitoare la protocolul CAN vor fi explicate în articolele următoare.


Stivă de comunicare w.r.t. la protocolul CAN în AUTOSAR constau din module cum ar fi AUTOSAR COM (Layer de servicii), Router PDUR (strat de servicii), CAN Status Manager CANSM (Layer servicii), CAN Network Manager CANNM (Layer de servicii), CAN Transport Protocol  CANTP(Strat de abstractizare ECU), Driver extern CAN (strat de abstractizare ECU) și driver CAN (strat MCAL). Unele module legate de diagnosticare CANTP, multiplexarea PDU și CAN-Transceiver  CANTrcv sunt, de asemenea, parte din stivă.



Interfața CAN (CanIf) este un modul din stratul de abstractizare ECU, care este responsabil pentru servicii cum ar fi solicitarea de transmisie, confirmarea transmisiei, indicația recepției, controlul modului controlerului și controlul modului PDU.

Termenii de bază utilizați în CAN

Manevrabilitatea obiectelor hardware:

Mijloacele pentru obiectele hardware (HOH) pentru transmisie (HTH) precum și pentru recepție (HRH) reprezintă o referință abstractă la o structură de obiecte hardware CAN care conține parametri CAN, cum ar fi CanId, DLC și date. În timpul transmisiei, aceste handles sunt cunoscute sub numele de handle transmițătoare hardware (HTH) și în timpul recepției Hardware Receive Handles (HRH). CanIf apelează interfețele CAN driver folosind aceste referințe abstracte și niciodată nu utilizează hardware-ul real CanId, prin urmare CanIf rămâne independent de hardware.

BasicCAN și FullCAN:

CanIf distinge între manipularea BasicCAN și FullCAN pentru activarea filtrării de acceptare a software-ului.

Un obiect hardware CAN pentru operarea FullCAN permite doar transmisia sau recepția unor canale simple.

Un obiect hardware CAN pentru operarea BasicCAN a unui singur obiect hardware permite transmiterea sau recepționarea unei game de CanIds.

Obiectele BasicCAN și FullCAN pot coexista într-o singură configurare a configurației.

CanIf abstractizează obiectul hardware CAN, adică structura cadru CAN de la driverul MCAL CAN, folosind obiecte abstracte numite Hardware Object Handles (HOH).  PDU-ul este directionat către diferite controlere CAN și transceivere. CanIf controlează cererea de tranziții de stare a controlerului CAN de la CANSM și comunică modificările de stare către stratul superior.

În cazul transmisiei unui PDU, CanIf este responsabil pentru cartografierea handlerul transmisiei hardware cu obiectele hardware CAN, determinând driverul CAN pe care trebuie să fie transmis PDU, declanșând un apel către Can_Write api. Odată ce Can_Write este terminat, notificând partea superioară despre starea transmisiei PDU.



În cazul recepției unui PDU, CanIf este responsabil pentru filtrarea PDU-ului primit, verificarea DLC, tamponarea PDU-ului primit și indicarea stratului superior despre recepția PDU. Cele mai multe dintre aceste caracteristici furnizate de CanIf sunt configurabile.



Modulul CAN Driver (CanDrv) face parte din stratul MCAL și oferă acces hardware la serviciile superioare ale stratului și o interfață independentă de hardware pentru straturile superioare. CanIf este singurul modul care poate accesa driver-ul CAN.

CAN Driver CanDrv controlează transmisia cadrelor CAN pe hardware și notifică nivelul superior al recepției apelând funcțiile callback. De asemenea, furnizează interfețele pentru a controla starea  CAN-ului.

Mai jos am reprezentat interfetele folosite pentru activarea sau dezactivarea comunicatiei CAN:

Și la nivel de apeluri a le funcțiilor API starile CAN-ului :




Weekend plăcut !