Search the Community

Salutare,am revenit cu un topic destul de interesant zic eu pentru cei pasionati de jocurile Rockstar. Am pentru voi GTA 5 varianta pentru [PC]! Link download torrent: Download Grand Theft Auto V / GTA 5 (v1.0.323.1, CRACKED, MULTI11) [FitGirl Initial Repack] Torrent - Kickasse Link download crack for GTA 5: Download Grand Theft Auto V [Crack V2 - for Windows 7 / 8 / 8.1] Torrent - Kickasse Cerinte de sistem minime: Operating System: Windows 8.1 64 Bit, Windows 8 64 Bit, Windows 7 64 Bit Service Pack 1, Windows Vista 64 Bit Service Pack 2* (*NVIDIA video card recommended if running Vista OS) Processor: Intel Core 2 Quad CPU Q6600 @ 2.40GHz (4 CPUs) / AMD Phenom 9850 Quad-Core Processor (4 CPUs) @ 2.5GHz - actually works on dual-core CPUs as well RAM: 4 GB Video Card: NVIDIA 9800 GT 1GB / AMD HD 4870 1GB (DX 10, 10.1, 11) DirectX: 10 HDD Space: 57 GB (~95 GB during installation of this repack) Sper ca vam fost de ajutor si am postat unde trebuie(CRED) Multumesc pentru timpul acordat! Cu stima,JrNasti.PPOW

IBM has announced it’s surmounted one of the biggest hurdles on the road toward creating the world’s first true usable quantum computer. A number of analysts have predicted that the jump from traditional computing to quantum chips could be on par with the revolution we saw when the world moved from vacuum tubes to integrated circuits back in the early sixties. The reason for this increased power is that quantum computers are capable of processing multitudes more calculations than traditional CPUs at once, because instead of a transistor existing in one of either two states — on, or off — independently of one another, a quantum bit can be both at the same time. How is that possible? Well, while the specifics of the mechanism that makes it work involves a bit more math than I could sit through in college, at its essence the computer is taking advantage of a quantum phenomena known as “superposition,” wherein an atom can act as both a wave and a particle at once. In short, this means that at least in theory, quantum bits (or “qubits”), can process twice as much information twice as fast. This has made the race to create the world’s first true quantum computer a bit of a Holy Grail moment for big chip makers, who have found themselves inching closer to maxing out Moore’s Law as 22 nano-meter transistors shrink to to 14nm, and 14nm tries to make the jump to 10. Related: Leaked table of Intel’s sixth-generation processors packs few surprises So far we’ve seen just one company pull out in front of the herd with its own entry, D-Wave, which first debuted all the way back in 2013. Unfortunately for futurists, the D-Wave is more a proof of concept that quantum computing is at least possible, but still not necessarily all that much quicker than what we have to work with today. Now though, according to a statement released by IBM Research, it seems Big Blue may have found a way around one of the biggest qualms in quantum computing by sorting out the problem of something known as “quantum decoherence.” Decoherence is a stumbling block that quantum computers run into when there’s too much “noise” surrounding a chip, either from heat, radiation, or internal defects. The systems that support quantum chips are incredibly sensitive pieces of machinery, and even the slightest bit of interference can make it impossible to know whether or not the computer was able to successfully figure out that two plus two equals four. IBM was able to solve this by upping the number of available qubits laid out on a lattice grid to four instead of two, so the computer can compensate for these errors by running queries against itself and automatically compensating for any difference in the results. In laymen’s, this means that researchers can accurately track the quantum state of a qubit, without altering the result through the act of observing alone. “Quantum computing could be potentially transformative, enabling us to solve problems that are impossible or impractical to solve today,” said Arvind Krishna, senior vice president and director of IBM Research, in a statement. Related: Intel may turn to Quantum Wells to enforce Moore’s Law While that may not sound huge, it’s still a big step in the right direction for IBM. The company believes the quantum revolution could be a potential savior for the supercomputing industry, a segment that is projected to be hardest hit by the imminent slowdown of Moore’s trajectory. Other possible applications up for grabs include solving complex physics problems beyond our current understanding, testing drug combinations by the billions at a time, and creating unbreakable encryption through the use of quantum cryptography. Se pare ca aceste tipuri de calculatoare vor conduce la "securitatea suprema". Sursa:Quantum computing may not be as far off as we think, says IBM | Digital Trends

In one of more impressive hacks in recent memory, researchers have devised an attack that exploits physical weaknesses in certain types of DDR memory chips to elevate the system rights of untrusted users of Intel-compatible PCs running Linux. The technique, outlined in a blog post published Monday by Google's Project Zero security initiative, works by reversing individual bits of data stored in DDR3 chip modules known as DIMMs. Last year, scientists proved that such "bit flipping" could be accomplished by repeatedly accessing small regions of memory, a feat that—like a magician who transforms a horse into a rabbit—allowed them to change the value of contents stored in computer memory. The research unveiled Monday showed how to fold such bit flipping into an actual attack. "The thing that is really impressive to me in what we see here is in some sense an analog- and manufacturing-related bug that is potentially exploitable in software," David Kanter, senior editor of the Microprocessor Report, told Ars. "This is reaching down into the underlying physics of the hardware, which from my standpoint is cool to see. In essence, the exploit is jumping several layers of the stack." Getting hammered DDR memory is laid out in an array of rows and columns, which are assigned in large blocks to various applications and operating system resources. To protect the integrity and security of the entire system, each large chunk of memory is contained in a "sandbox" that can be accessed only by a given app or OS process. Bit flipping works when a hacker-developed app or process accesses two carefully selected rows of memory hundreds of thousands of times in a tiny fraction of a second. By hammering the two "aggressor" memory regions, the exploit can reverse one or more bits in a third "victim" location. In other words, selected zeros in the victim region will turn into ones or vice versa. The ability to alter the contents of forbidden memory regions has far-reaching consequences. It can allow a user or application who has extremely limited system privileges to gain unfettered administrative control. From there, a hacker may be able to execute malicious code or hijack the operations of other users or software programs. Such elevation-of-privilege hacks are especially potent on servers available in data centers that are available to multiple customers. The vulnerability works only on newer types of DDR3 memory and is the result of the ever smaller dimensions of the silicon. With less space between each DRAM cell, it becomes increasingly hard to prevent one cell from interacting electrically with its neighbors. By repeatedly accessing one or more carefully selected memory locations, attackers can exploit this volatility, causing the charge to leak into or out of adjacent cells. With enough accesses, the technique can change the value of a cell. The attack doesn't work against newer DDR4 silicon or DIMMs that contain ECC, short for error correcting code, capabilities. Mark Seaborn, described as a "sandbox builder and breaker," along with reverse engineer Thomas Dullien, developed two "rowhammer" exploits that, when run as unprivileged processes, were able to gain kernel privileges on an x86-64 Linux system. The first exploit ran as a Native Client module on top of Google Chrome. Once Google developers became aware of the exploit, they disallowed the CLFLUSH instruction that's required to make the exploit work. The second exploit, which ran as a normal Linux process and gained access to all physical memory, will be harder to mitigate on existing machines. There are other things that made the exploits impressive. Irene Abezgauz, a product VP at Dyadic Security and an experienced penetration testing professional, told Ars: The attackers didn't identify the specific models of DDR3 that are susceptible to the attack. While their proof-of-concept exploits targeted a Linux computer running x86-64 hardware, the same technique would likely work against a variety of platforms. The results are impressive, but for a variety of reasons right now, the attacks appear to be more theoretical than practical. For one, the attack appears to allow only local, rather than remote, exploitation, a limitation that significantly curtails its appeal to real-world hackers. And for another, bit flipping works only against certain pre-determined rows. What's more, rowhammering requires more than 540,000 memory accesses in just 64 milliseconds. Unless refinements are made, the demands could make it impractical for attackers to use the technique to reliably hijack a system. Bit flipping shouldn't be mistaken as a class of memory corruption exploit, such as a buffer overflow or a use-after-free, both of which allow attackers to funnel malicious shell code into protected regions of a computer. Rowhammering, by contrast, allows for escalation of privileges, which while serious, is a much more nuanced type of incursion. Rob Graham, CEO of Errata Security, published this blog post that details additional challenges and technical details. Still, the ability to exploit physical weaknesses in the hardware is a highly novel type of attack that breaks new ground and may not be easy to remedy. "This is not like software, where in theory we can go patch the software and get a patch distributed via Windows update within the next two to three weeks," Kanter, of the Microprocessor Report, said. "If you want to actually fix this problem, we need to go out and replace, on a DIMM by DIMM basis, billions of dollars' worth of DRAM. From a practical standpoint that's not ever going to happen." Source

Sources: http://googleprojectzero.blogspot.ca/2015/03/exploiting-dram-rowhammer-bug-to-gain.html https://code.google.com/p/google-security-research/issues/detail?id=284 Full PoC: http://www.exploit-db.com/sploits/36311.tar.gz This is a proof-of-concept exploit that is able to escape from Native Client's x86-64 sandbox on machines that are susceptible to the DRAM "rowhammer" problem. It works by inducing a bit flip in read-only code so that the code is no longer safe, producing instruction sequences that wouldn't pass NaCl's x86-64 validator. Note that this uses the CLFLUSH instruction, so it doesn't work in newer versions of NaCl where this instruction is disallowed by the validator. There are two ways to test the exploit program without getting a real rowhammer-induced bit flip: * Unit testing: rowhammer_escape_test.c can be compiled and run as a Linux executable (instead of as a NaCl executable). In this case, it tests each possible bit flip in its code template, checking that each is handled correctly. * Testing inside NaCl: The patch "inject_bit_flip_for_testing.patch" modifies NaCl's dyncode_create() syscall to inject a bit flip for testing purposes. This syscall is NaCl's interface for loading code dynamically. Mark Seaborn mseaborn@chromium.org March 2015 Source

Sources: http://googleprojectzero.blogspot.ca/2015/03/exploiting-dram-rowhammer-bug-to-gain.html https://code.google.com/p/google-security-research/issues/detail?id=283 Full PoC: http://www.exploit-db.com/sploits/36310.tar.gz This is a proof-of-concept exploit that is able to gain kernel privileges on machines that are susceptible to the DRAM "rowhammer" problem. It runs as an unprivileged userland process on x86-64 Linux. It works by inducing bit flips in page table entries (PTEs). For development purposes, the exploit program has a test mode in which it induces a bit flip by writing to /dev/mem. qemu_runner.py will run the exploit program in test mode in a QEMU VM. It assumes that "bzImage" (in the current directory) is a Linux kernel image that was built with /dev/mem enabled (specifically, with the the CONFIG_STRICT_DEVMEM option disabled). Mark Seaborn mseaborn@chromium.org March 2015 Source

Rowhammer: NaCl Sandbox Escape PoC Rowhammer: Linux Kernel Privilege Escalation PoC Software, from web apps, to operating systems to firmware, has been abused and exploited every which way from Sunday for decades by both researchers and attackers. Now, it is hardware’s turn in the spotlight, as researchers have published details of a new method for exploiting a problem with some DRAM memory devices that can allow attackers to get low-level access to target machines. The problem is being called “rowhammer”, as it’s a method for repeatedly hammering on rows of cells of memory in DRAM devices to induce cells to flip from one state to another. Using a new technique to exploit the rowhammer issue, researchers at Google were able to produce these bit flips in cells and gain kernel-level privileges. Security researchers say the technique is some of the more important work done on exploitation in recent years and could affect a huge number of laptops and desktop machines. “[it] is a brilliant attack and because it’s a hardware flaw, there are really no ways to patch it,” said Alfredo Ortega, a longtime security researcher and co-founder of Groundworks Technologies. Researcher Mark Seaborn on Monday published a detailed technical explanation of techniques to exploit the rowhammer issue, which was described earlier in an academic paper by researchers from Intel and Carnegie Mellon University. The basic concept behind rowhammer relies on the fact that the cells of memory on DRAM devices have become closer and closer together over time, meaning that it has become more difficult to prevent electrons from jumping from one cell to another. By accessing target cells in DRAM over and over again, an attacker can disturb a cell adjacent to the target cells, causing it to “bit flip” under some circumstances. “‘Rowhammer’ is a problem with some recent DRAM devices in which repeatedly accessing a row of memory can cause bit flips in adjacent rows. We tested a selection of laptops and found that a subset of them exhibited the problem. We built two working privilege escalation exploits that use this effect. One exploit uses rowhammer-induced bit flips to gain kernel privileges on x86-64 Linux when run as an unprivileged userland process,” Seaborn wrote in his post. “When run on a machine vulnerable to the rowhammer problem, the process was able to induce bit flips in page table entries (PTEs). It was able to use this to gain write access to its own page table, and hence gain read-write access to all of physical memory.” Seaborn tested his technique on 29 different machines with several different CPUs and DRAM from several vendors and observed a bit flip in 15 cases. However, he stressed that the lack of an observed bit flip does not mean that the DRAM isn’t necessarily exploitable. “While an absence of bit flips during testing on a given machine does not automatically imply safety, it does provide some baseline assurance that causing bit flips is at least difficult on that machine,” Seaborn said. Ortega said that the new technique is effective thanks to the way that DRAM devices are designed now. “Modern memory is flawed, vendors cut corners a lot to save power and make cheap tiny chips, so if you access too quickly a section of it, or if you turn on and off a memory cell too quickly, the adjacent memory cells will also be affected,’ he said. “The trick is to find a memory cell that stores something important and that you cannot access for security reasons, for example a memory cell storing a password, or file permissions, and then flip a cell next to it. Eventually the memory cell will flip, even if you don’t have access to it.” Mitigating rowhammer attacks is possible, Seaborn said. For example, manufacturers can make sure that when a system refreshes DRAM memory that it doesn’t activate a given row too often without also refreshing nearby rows. The rowhammer issue is not unknown to DRAM manufacturers, as some of them may already have implemented some mitigations. “Looking backward, had there been more public disclosures about the rowhammer problem, it might have been identified as an exploitable security issue sooner. It appears that vendors have known about rowhammer for a while, as shown by the presence of rowhammer mitigations in LPDDR4. It may be that vendors only considered rowhammer to be a reliability problem,” Seaborn said. Security researcher Dan Kaminsky, chief scientist of White Ops, said that the attack is effective in a surprising number of cases. “This sort of bug fills memory — the grand collection of buckets in your computer — with lots and lots of areas where checks for God like power depend on the bucket being empty. Then it shakes specially chosen buckets — ‘aggressor buckets’ — to try to leak a 1 into all those 0’s. And on a surprising amount of hardware, it works,” Kaminsky said via email. However, one good defense against the attack is the use of ECC memory, which has extra bits to help correct errors. ECC is more expensive, though, and mainly is used in servers rather than laptops and desktops, said researcher Robert Graham of Errata Security. “The biggest threat at the moment appears to be to desktops/laptops, because they have neither ECC memory nor virtual machines. In particular, there seems to be a danger with Google’s native client (NaCl) code execution. This a clever sandbox that allows the running of native code within the Chrome browser, so that web pages can run software as fast as native software on the system. This memory corruption defeats one level of protection in NaCl. Nobody has yet demonstrated how to use this technique in practice to fully defeat NaCl, but it’s likely somebody will discover a way eventually,” Graham said. The new techniques, Seaborn said, are a good example of why manufacturers and researchers should be paying close attention to hardware vulnerabilities. “History has shown that issues that are thought to be “only” reliability issues often have significant security implications, and the rowhammer problem is a good example of this. Many layers of software security rest on the assumption the contents of memory locations don’t change unless the locations are written to,” he said. “Though the industry is less accustomed to hardware bugs than to software bugs, we would like to encourage hardware vendors to take the same approach: thoroughly analyse the security impact of ‘reliability’ issues, provide explanations of impact, offer mitigation strategies and — when possible — supply firmware or BIOS updates. Such discussion will lead to more secure hardware, which will benefit all users.” Source

There's a story on Hacker News asking what the hell is going on with the Truecrypt audit. I think that's a fair question, since we have been awfully quiet lately. To everyone who donated to the project, first accept my apologies for the slow pace. I want to promise you that we're not spending your money on tropical vacations (as appealing as that would be). In this post I'd like to offer you some news, including an explanation of why this has moved slowly. For those of you who don't know what the Truecrypt audit is: in late 2013 Kenn White, myself, and a group of advisors started a project to undertake a crowdfunded audit of the Truecrypt disk encryption program. To the best of my knowledge, this is the first time anyone's tried this. The motivation for the audit is that lots of people use Truecrypt and depend on it for their security and safety -- yet the authors of the program are anonymous and somewhat mysterious to boot. Being anonymous and mysterious is not a crime, but it still seemed like a nice idea to take a look at their code. We had an amazing response, collecting upwards of $70,000 in donations from a huge and diverse group of donors. We then went ahead and retained iSEC Partners to evaluate the bootloader and other vulnerability-prone areas of Truecrypt. The initial report was published here. That initial effort was Part 1 of a two-part project. The second -- and much more challenging part -- involves a detailed look at the cryptography of Truecrypt, ranging from the symmetric encryption to the random number generator. We had some nice plans for this, and were well on our way to implementing them. (More on those in a second.) Then in late Spring of 2014, something bizarre happened. The Truecrypt developers pulled the plug on the entire product -- in their typical, mysterious way. This threw our plans for a loop. We had been planning a crowdsourced audit to be run by Thomas Ptacek and some others. However in the wake of TC pulling the plug, there were questions. Was this a good use of folks' time and resources? What about applying those resources to the new 'Truecrypt forks' that have sprung up (or are being developed?) There were a few other wrinkles as well, which Thomas talks about here -- although he takes on too much of the blame. It took us a while to recover from this and come up with a plan B that works within our budget and makes sense. We're now implementing this. A few weeks ago we signed a contract with the newly formed NCC Group's Cryptography Services practice (which grew out of iSEC, Matasano and Intrepidus Group). The project will evaluate the original Truecrypt 7.1a which serves as a baseline for the newer forks, and it will begin shortly. However to minimize price -- and make your donations stretch farther -- we allowed the start date to be a bit flexible, which is why we don't have results yet. In our copious spare time we've also been looking manually at some portions of the code, including the Truecrypt RNG and other parts of the cryptographic implementation. This will hopefully complement the NCC/iSEC work and offer a bit more confidence in the implementation. I don't really have much more to say -- except to thank all of the donors for their contributions and their patience. This project has been a bit slower than any of us would like, but results are coming. Personally, my hope is that they'll be completely boring. Sursa: A Few Thoughts on Cryptographic Engineering: Another update on the Truecrypt audit

Primul care rezolva primeste cheia. Trimiteti raspunsul pe PM. Hint: 128 Bit

Adobe Premiere Pro CC 2014.1 64 Bit Final Adobe Premiere Pro CC 2014.1 64 Bit Final | 1.09 GB Adobe Premiere Pro CC 2014 software offers breakthrough performance for video production, enabling you to work dramatically faster thanks to the revolutionary native 64-bit, GPU-accelerated Adobe Mercury Playback Engine. Adobe Premiere Pro CC works natively with the video formats you want and accelerate production from scriptwriting to editing, encoding, and final delivery. System requirements: Intel Core2 Duo or AMD Phenom II processor with 64-bit support Microsoft Windows 7 with Service Pack 1 (64 bit) or Windows 8 (64 bit) 4 GB of RAM (8 GB recommended) 4 GB of available hard-disk space for installation; additional free space required during installation (can not install on removable flash storage devices) Additional disk space required for preview files and other working files (10 GB recommended) 1280 x 800 display 7200 RPM or faster hard drive (multiple fast disk drives configured for RAID 0 recommended) Sound card compatible with ASIO protocol or Microsoft Windows Driver Model QuickTime 7.6.6 software required for QuickTime features Optional: Adobe-certifi ed GPU card for GPU-accelerated performance Internet connection and registration are necessary for required software activation, validation of subscriptions, and access to online services. * DOWNLOAD LINKS: http://u22088411.letitbit.net/download/82491.89e52ec61a412ac05cb44666ec7d/Premiere.Pro.CC.2014.1.Win64.part1.rar.html http://u22088411.letitbit.net/download/94395.9f17d58f6e558518553092f019b0/Premiere.Pro.CC.2014.1.Win64.part2.rar.html http://u22088411.letitbit.net/download/23062.20aefc298d97b22652ece291d4a0/Premiere.Pro.CC.2014.1.Win64.part3.rar.html http://rapidgator.net/file/e2dea0db92f96a29dd422e833acdcc98/Premiere.Pro.CC.2014.1.Win64.part1.rar.html http://rapidgator.net/file/813ec7667f370c4cd52722f19e4b3084/Premiere.Pro.CC.2014.1.Win64.part2.rar.html http://rapidgator.net/file/0cf3d0608ca59b3de95bf2a9d5505161/Premiere.Pro.CC.2014.1.Win64.part3.rar.html http://uploaded.net/file/28740jle/Premiere.Pro.CC.2014.1.Win64.part1.rar http://uploaded.net/file/v1ywmby8/Premiere.Pro.CC.2014.1.Win64.part2.rar http://uploaded.net/file/om7rrjnd/Premiere.Pro.CC.2014.1.Win64.part3.rar http://u18391561.shareflare.net/download/93753.9c88e9cf1faf52ea6d16d419e00e/Premiere.Pro.CC.2014.1.Win64.part1.rar.html http://u18391561.shareflare.net/download/17919.16bc58af775ca169f386119fa919/Premiere.Pro.CC.2014.1.Win64.part2.rar.html http://u18391561.shareflare.net/download/52332.5c8ff0e1ccd2cfabf851af165d85/Premiere.Pro.CC.2014.1.Win64.part3.rar.html