Search the Community

Propun o noua problema care necesita o logica buna. Se da un array de numere intregi si pozitive. Singura alterare permisa a elementelor din array este incrementarea acestora, strict cu valoarea 1. Toate numerele din array trebuie sa devina pare, intr-un final, cu un numar minim de incrementari, dar respectand regula urmatoare: atunci cand se face o incrementare pe pozitia i din array, in mod obligatoriu se face incrementare fie pe pozitia i-1, fie pe pozitia i+1. Se cere returnarea numarului minim de incrementari, astfel incat, in final, toate numerele din array sa fie pare. In cazul in care input-ul nu este valid, deci nu se poate ajunge la un rezultat corect, se va returna -1. Constrangeri: Se considera N a fi numarul de elemente din array, iar 2 <= N <= 1000 1 <= V[i] <= 10, iar 0 <= i <= N-1 Exemplu #1: Se da V = [4,5,6,7]. Se face incrementare, la primul pas, pe i = 2 si respectiv i = 3, deci va rezulta array-ul V = [4,5,7,8]. Acum, la pasul urmator, se va face incrementare pe i = 1 si respectiv i = 2, deci va rezulta array-ul V = [4,6,8,8]. In final, se intoarce numarul de incrementari facute, mai exact 4. Exemplu #2: Se da V = [2,3,4,5,6]. Se face incrementare, la primul pas, pe i = 1 si respectiv i = 2, deci va rezulta array-ul V = [2,4,5,5,6]. Acum, la pasul urmator, se va face incrementare pe i = 2 si respectiv i = 3, deci va rezulta array-ul V = [2,4,6,6,6]. In final, se intoarce numarul de incrementari facute, mai exact 4. Exemplu #3: Se da V = [1,2]. Oricum s-ar face incrementare, una dintre valori va fi mereu para, iar cealalta impara. Prin urmare, nu se poate ajunge la un rezultat corect, deci se intoarce -1. Limbajul care va fi folosit este la alegere libera. Sunt acceptate toate solutiile, indiferent de complexitatea timp, dar trebuie incercat sa se rezolve in maxim O(N). O solutie personala va fi pusa ulterior. Spor!

#Type of vuln : Flash Cross Domain Policy #Target : www.*.nokia.com #Author : KRONZY #P.O.C : #References : 1. https://www.owasp.org/index.php/Test_RIA_cross_domain_policy_%28OTG-CONFIG-008%29 2. CWE - CWE-942: Overly Permissive Cross-domain Whitelist (2.8) 3. https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-2227 Raportata. , low level.

Google and Firefox have upgraded their flagship browsers, crushing bugs and cracking down on bad certificates along the way. The Choc Factory's Chrome 41 swats 51 bugs of which at least 13 are classified as high severity and six considered medium risks. Google engineer Penny MacNeil thanked security researchers for the effort to identify the bugs. "We would also like to thank all security researchers that worked with us during the development cycle to prevent security bugs from ever reaching the stable channel," MacNeil says. Here's this month's ameliorated messes: [$7500][456516] High CVE-2015-1212: Out-of-bounds write in media. Credit to anonymous. [$5000][448423] High CVE-2015-1213: Out-of-bounds write in skia filters. Credit to cloudfuzzer. [$5000][445810] High CVE-2015-1214: Out-of-bounds write in skia filters. Credit to cloudfuzzer. [$5000][445809] High CVE-2015-1215: Out-of-bounds write in skia filters. Credit to cloudfuzzer. [$4000][454954] High CVE-2015-1216: Use-after-free in v8 bindings. Credit to anonymous. [$3000][456192] High CVE-2015-1217: Type confusion in v8 bindings. Credit to anonymous. [$3000][456059] High CVE-2015-1218: Use-after-free in dom. Credit to cloudfuzzer. [$3000][446164] High CVE-2015-1219: Integer overflow in webgl. Credit to Chen Zhang (demi6od) of NSFOCUS Security Team. [$3000][437651] High CVE-2015-1220: Use-after-free in gif decoder. Credit to Aki Helin of OUSPG. [$2500][455368] High CVE-2015-1221: Use-after-free in web databases. Credit to Collin Payne. [$2500][448082] High CVE-2015-1222: Use-after-free in service workers. Credit to Collin Payne. [$2000][454231] High CVE-2015-1223: Use-after-free in dom. Credit to Maksymillian Motyl. [449610] High CVE-2015-1230: Type confusion in v8. Credit to Skylined working with HP’s Zero Day Initiative. [$2000][449958] Medium CVE-2015-1224: Out-of-bounds read in vpxdecoder. Credit to Aki Helin of OUSPG. [$1000][446033] Medium CVE-2015-1225: Out-of-bounds read in pdfium. Credit to cloudfuzzer. [$1000][456841] Medium CVE-2015-1226: Validation issue in debugger. Credit to Rob Wu. [$1000][450389] Medium CVE-2015-1227: Uninitialized value in blink. Credit to Christoph Diehl. [$1000][444707] Medium CVE-2015-1228: Uninitialized value in rendering. Credit to miaubiz. [$500][431504] Medium CVE-2015-1229: Cookie injection via proxies. Credit to iliwoy. Mozilla's updates Firefox version 37 include a revocation feature to bolster the killing of bad intermediate certificates. The OneCRL replaces the Online Certificate Status Protocol which is less effective because it relies on third parties to keep updated registries of their valid and revoked certificates. Certificates were often accepted as soft-fails when the status could not be determined due to some technical or connectivity failure. Mozilla's new list operates in the browser and is populated by issuers who push certificate status instead of the browser having to do the fetching. This block-list, already used for blacklisting bad plugins and drivers, will now speed up checking times because it avoids the need for Mozilla to push out updates that require browser restarts, Mozilla security boffin Mark Goodwin says. "OneCRL helps speed up revocation checking by maintaining a centralised list of revoked certificates and pushing it out to browsers. Currently, if a serious incident occurs that requires certificates to be revoked, we release an update to Firefox to address the problem. "This is slow because it takes some time for users to get the security update and restart their browsers. There’s also cost involved in producing an update and in users downloading it." Goodwin points to a blog by Google guy Adam Langley who said last year that the old revocation checking did little to improve security. OneCRL for now covers intermediate certificates to reduce the size of Mozilla's blocklist and will be later sped up by automating the collection of revoked certificates. Source

Google pushed out on Wednesday a new version of its Chrome browser (40.0.2214.91) and along with it paid out more than two dozen bounties, including 16 for memory corruption vulnerabilities. In all, 62 security vulnerabilities were patched, 17 of those considered high severity bugs by Google. Most of those high-severity vulnerabilities were memory corruption or use-after-free vulnerabilities in a number of Chrome components, including ICU, V8, FFmpeg and DOM. A researcher credited as cloudfuzzer cashed in with $12,000 worth of bounties, including three critical bugs. Another reporter known as yangdingning was awarded $9,000 for his finds. Here is the list of public vulnerabilities patched in Chrome 40. [$5000][430353] High CVE-2014-7923: Memory corruption in ICU. Credit to yangdingning. [$4500][435880] High CVE-2014-7924: Use-after-free in IndexedDB. Credit to Collin Payne. [$4000][434136] High CVE-2014-7925: Use-after-free in WebAudio. Credit to mark.buer. [$4000][422824] High CVE-2014-7926: Memory corruption in ICU. Credit to yangdingning. [$3500][444695] High CVE-2014-7927: Memory corruption in V8. Credit to Christian Holler. [$3500][435073] High CVE-2014-7928: Memory corruption in V8. Credit to Christian Holler. [$3000][442806] High CVE-2014-7930: Use-after-free in DOM. Credit to cloudfuzzer. [$3000][442710] High CVE-2014-7931: Memory corruption in V8. Credit to cloudfuzzer. [$2000][443115] High CVE-2014-7929: Use-after-free in DOM. Credit to cloudfuzzer. [$2000][429666] High CVE-2014-7932: Use-after-free in DOM. Credit to Atte Kettunen of OUSPG. [$2000][427266] High CVE-2014-7933: Use-after-free in FFmpeg. Credit to aohelin. [$2000][427249] High CVE-2014-7934: Use-after-free in DOM. Credit to cloudfuzzer. [$2000][402957] High CVE-2014-7935: Use-after-free in Speech. Credit to Khalil Zhani. [$1500][428561] High CVE-2014-7936: Use-after-free in Views. Credit to Christoph Diehl. [$1500][419060] High CVE-2014-7937: Use-after-free in FFmpeg. Credit to Atte Kettunen of OUSPG. [$1000][416323] High CVE-2014-7938: Memory corruption in Fonts. Credit to Atte Kettunen of OUSPG. [$1000][399951] High CVE-2014-7939: Same-origin-bypass in V8. Credit to Takeshi Terada. [$1000][433866] Medium CVE-2014-7940: Uninitialized-value in ICU. Credit to miaubiz. [$1000][428557] Medium CVE-2014-7941: Out-of-bounds read in UI. Credit to Atte Kettunen of OUSPG and Christoph Diehl. [$1000][426762] Medium CVE-2014-7942: Uninitialized-value in Fonts. Credit to miaubiz. [$1000][422492] Medium CVE-2014-7943: Out-of-bounds read in Skia. Credit to Atte Kettunen of OUSPG. [$1000][418881] Medium CVE-2014-7944: Out-of-bounds read in PDFium. Credit to cloudfuzzer. [$1000][414310] Medium CVE-2014-7945: Out-of-bounds read in PDFium. Credit to cloudfuzzer. [$1000][414109] Medium CVE-2014-7946: Out-of-bounds read in Fonts. Credit to miaubiz. [$500][430566] Medium CVE-2014-7947: Out-of-bounds read in PDFium. Credit to fuzztercluck. [$500][414026] Medium CVE-2014-7948: Caching error in AppCache. Credit to jiayaoqijia. Google said it awarded an additional $35,000 in bounties to Atte Kettunen of OUSPG, Christian Holler, cloudfuzzer and Khalil Zhani for work done during the development cycle to keep vulnerabilities out of the stable release. This is the first Chrome release of the year; in November, Chrome 39 was released and included removal of support for the fallback to SSL 3.0, the target of the POODLE attack. Source

Odata cu ziua parolei scrisa de em a aparut in aceeasi sfera si un articol despre parole. Sursa articolului: Ars Technica Does your password go up to 11? Probably not. But one day it could. If you've ever been nagged about the weakness of your password while changing account credentials on Google, Facebook, or any number of other sites, you may have wondered: do these things actually make people choose stronger passcodes? A team of scientists has concluded that the meters do work—or at least they have the potential to do so, assuming they're set up correctly. The researchers—from the University of California at Berkeley, the University of British Columbia in Vancouver, and Microsoft—are among the first to test the effect that the ubiquitous password meters have on real users choosing passwords. They found that meters grading the strength of passwords had a measurable impact in helping users pick stronger passcodes that weren't used on other accounts. But the group also discovered these new, stronger passwords weren't any harder for users to remember than weaker ones. The scientists were quick to point out caveats to their findings. For one, the meters provided little benefit when users were choosing passwords while setting up a new account, as opposed to changing passwords for an already established account. And the meters provided no improvement for accounts people considered unimportant. "Within that context they're much more likely to just enter a password that they already used elsewhere because they either don't care about those accounts or that's just normally what they do when they enroll in a new account," Serge Egelman, a research scientist at UC Berkeley and the lead author of the paper, told Ars. "Whereas we show that in a different context—when changing passwords for high-value accounts—then the meters actually do have an observable effect on behavior in that people do choose stronger passwords. And ironically that's the context where we're least likely to see real meters in real life." The researchers' paper—titled Does My Password Go up to Eleven? The impact of Password Meters on Password Selection—is important because it provides useful guidance to both end users and the security professionals who work to protect them. While more and more sites now offer these meters, Egelman said a surprising number of online banking services and corporate intranets don't yet offer them. Remarkably, neither Microsoft Windows nor Apple's OS X for Macs uses meters for users who are choosing or changing account passwords. The findings come from an experiment in which affiliates of the University of British Columbia were brought to a laboratory and asked to test the usability of a portal that students, faculty, and staff use to access e-mail, view grades, and check out library books. As soon as they successfully logged into their account, they were presented with a notice requiring them to change their password. While the plaintext was never recorded, the laboratory computer did store a cryptographic hash of the passwords. It also measured other characteristics of both the old and new passwords, including the length and whether they used upper- and lower-case letters, numbers, and special characters. Some of the subjects were presented with one of two types of password meters that rated the strength of the new password, while a control group saw no meter at all. The password meters presented to the test subjects used "zero-order entropy," a technique many meters use to measure password strength. One set of "existing motivator" meters used the measures to rate passwords as "weak," "medium," or "strong." A second set of "peer-pressure motivator" meters used the same data to present the strength of the new password relative to all the users of the system. In turns out that the subjects who were presented with either type of meter picked significantly "stronger" passwords than those in the control group. The average zero-order entropy of passwords chosen with guidance from the existing motivator meter increased to 60.8 and the entropy of passwords chosen with the peer-pressure motivator grew to 64.9 bits. This means the total number of combinations required to brute-force crack the passwords would be 260.8 and 264.9 respectively. Subjects who saw no meter at all chose passwords that on average were 49.3 bits strong, about the same as the old passwords from all three groups. "Overall, we observed that both password meters yielded statistically significant differences when compared to the control condition," the researchers reported in the paper. (The findings were recently presented at the CM SIGCHI Conference on Human Factors in Computing Systems in Paris.) In addition to increasing entropy metrics, the researchers found other indications of improved strength. Passwords generated with the help of meters increased from a median of 9.0 to 10.0 characters, included more special characters, and contained more lower-case letters (from a median of 6.0 to 7.0). "Thus, the meters motivated participants to create longer passwords through the inclusion of symbols and additional lower-case letters," the researchers said. The subjects were invited back to the laboratory two weeks later and another encouraging finding came up. Those who had chosen stronger passwords with the help of the meter had no more trouble remembering their new passcodes than those who had chosen weaker passwords without using a meter. What's more, those with stronger passwords were no more likely to have reverted back to their old one than those who had chosen weaker passwords. Building a better mousetrap It's encouraging to know that password meters have a measurable effect on the passwords chosen by end users. But sadly there's no guarantee meters will actually help people choose passcodes that are more resistant to real-world cracking techniques. That's because the widely used zero-order entropy rating system is a poor metric for measuring the strength of passwords. The strength of the passcodes "Pa$$word1" and "$ecretPa$$word1" (minus the quotes) is 59.1bits and 98.5bits respectively. That's much higher than many passwords offer. What the scoring system fails to account for is that both passwords are so widely used that they're inevitably included in wordlists used in cracking attacks. These are among the first passwords to fall in typical cracking attacks. By contrast, the password "lkx8q2pe0" is considerably stronger because it would require time-consuming brute-force techniques to crack it, and yet it offers just 46.5 bits. (Bits are calculated by x * log_2(y), where x is the number of characters in a passcode and y is the number of available letters, numbers, or special characters). What this means is that password meters have the ability to help end users choose more crack-resistant passcodes only if the meters are set up correctly. As Ars documented last week, a password advice site from Intel can't be trusted to help users pick passcodes because the methodology it uses is hopelessly flawed. The password meters used in the study and offered on many sites suffer from the same type of weakness, but there's no reason they can't be drastically improved—for instance, by banning the one million most commonly used words. Egelman said there's no evidence to suggest improved meters wouldn't generate the same measurable effect in guiding people's choice of passwords. "They don't know what algorithm we're using to drive the meter," he said. "They just know that they do some behavior, they get some feedback, and they keep trying until [they get] feedback they're happy with. I suspect that if we changed what the feedback is based on we would still have the impact on them."

Pe acesta am facut-o in graba, e destul de usoara. In curand vine si CrackThisApp3, care e mai interesanta. O pun cand va fi rezolvata 2. Programul va da un cuvat in cazul raspunsului corect. Il postati aici. CrackThisApp2 Solvers: CrackThisApp1: executiv

Am pregatit niste cracking challenguri. Nu voi pune de alea super simple in care rezultatul se vede direct in Hex, sau la care trebuie sa schimbi o conditie doar pentru a primi rezultatul. Deci nu vor fi pentru incepatori, dar primele nu vor fi foarte grele. CrackThisApp 1 Aplicatia o parte de patch si alta de key finding. Desi se poate face si fara patch, cea mai usoara cale e s-o faceti asa. Vreau aici sa postati parola corecta, si partea careia ia-ti facut patch. NU vreau o schimbare simpla de cod care da mesajul de confirmare, vreau parola. Have fun! Download: http://depositfiles.com/files/nflm67m4h