Nytro

Jailed terrorist gets extra time for refusing to divulge USB stick password by Lisa Vaas on January 17, 2014 A British man already in jail for terrorist activity was given another four months for refusing to give police the password to a memory stick that they couldn't crack. According to The Register, Judge Richard Marks QC sentenced Syed Hussain, 22, from Luton, for refusing to give up his password, contrary to section 53 of the Regulation of Investigatory Powers Act 2000 (RIPA), the UK's wiretapping law. The encrypted memory stick had been seized from Hussain's home during an April 2012 counter-terrorism operation. Hussain and three other men were jailed in 2012 after they admitted to discussing an attack on a local Territorial Army base headquarters. They had planned to send a homemade bomb to their targeted site via a remote controlled toy car, but the men were arrested before the attack could be carried out. Hussain's lawyers insisted that he couldn't remember the password to the memory stick, citing stress as the cause of his memory lapse. He kept up the "I forgot because I'm so stressed" argument for 11 months. During that time, police called in experts from GCHQ, the government's intelligence agency, but even they couldn't get at the stick's contents. So police and prosecutors set a deadline: they gave Hussain until last January to cough up the password. Then, 11 months after the deadline came and went, police told the convicted man's lawyers that they'd launched a fresh investigation: this one into alleged credit card fraud by Hussain. That seemed to jolt Hussain's memory. Within days, he handed over the password. It was "$ur4ht4ub4h8", which the Register reports is a play on words relating to a chapter of the Koran. When police used the password to unlock the contents of the memory stick, they found it held information relevant to the investigation into alleged fraud, but nothing relating to terrorism or national security. Sursa: Jailed terrorist gets extra time for refusing to divulge USB stick password | Naked Security

Recomandarea SIE c?tre demnitari: V? rug?m frumos nu vorbi?i pe mobil, mai ales în str?in?tate Recomandarea SIE c?tre demnitarii români este de a nu vorbi de pe telefoane mobile obi?nuite, mai ales atunci când se afl? în str?in?tate, ?i de a folosi liniile de comunica?ii de la misiunile diplomatice române?ti. Directorul Serviciului de Informa?ii Externe, Teodor Mele?canu, a declarat, la Digi 24, în contextul în care comenta scandalul iscat de dezv?luirile lui Eduard Snowden, c? 95% din totalul sateli?ilor declara?i ca fiind "de studiu" sunt sateli?i de spionaj. "Evident c? se ascult?. 95% din sateli?ii care se învârt în spa?iul extraatmosferic pentru «studierea pa?nic? a Cosmosului» sunt sateli?i de spionaj. Dac? lumea s-a sup?rat pentru asta, înseamn? c? e infantil?. Aaa, dac? sup?rarea a fost de cum a fost posibil s? se afle ?i a?a mai departe, asta e altceva", a spus Mele?canu. Directorul SIE a ad?ugat c? nu interceptarea mesajelor este problema, ci decriptarea lor. "Tot ce este semnal audio, video ?i a?a mai departe ?i iese în atmosfer? este interceptat. Majoritatea sunt îns? criptate ?i problema e dac? po?i s? le decriptezi. Dar de interceptat, se intercepteaz?. ?i noi facem asta, ?i toat? lumea (...) Sigur, dac? sunt criptate, ajungi mai greu la ele. Înseamn? c? au valoare mai mare", a punctat Teodor Mele?canu. Întrebat dac? ?i SIE ascult? deciden?i politici din alte ??ri, directorul institu?iei a r?spuns: "Nu, dar de multe ori ajung asemenea semnale ?i la noi". ?eful SIE a precizat c? România, odat? intrat? în NATO, s-a obligat prin tratat s? nu aib? opera?iuni pe teritoriul altor state "nici de interceptare, nici de alt tip". Pe de alt? parte, Mele?canu a dat de în?eles c? este posibil ca deciden?i români s? fi fost asculta?i de servicii str?ine, mai ales dac? au avut convorbiri din str?in?tate, de pe telefoane necodificate. "Eu, personal, nu exclud. Mai ales dac? au vorbit din str?in?tate pe telefoane mobile obi?nuite, e foarte posibil (...) Noi facem aceast? recomandare tuturor beneficiarilor: v? rug?m frumos nu vorbi?i pe telefonul mobil, mai ales dac? sunte?i în str?in?tate, într-o deplasare. Ave?i ceva de vorbit? E o ambasad?, sunt posibilit??i de a comunica. Dac? beneficiarul respect? sau nu, sigur c? e op?iunea lui", a declarat Teodor Mele?canu. Sursa: Recomandarea SIE c?tre demnitari: V? rug?m frumos nu vorbi?i pe mobil, mai ales în str?in?tate - Mediafax

Da. Daca vreti sa faceti teste pe alte conturi (decat al vostru), incercati dintr-un "Private window" sau dati "Clear cookies" inainte.

Nu e tocmai ceva nou, dar nu e de ajuns pentru a schimba parola. Am incercat si eu acum ceva timp pe contul unei prietene si am reusit sa obtin acces identificand 5 prieteni ai sai: am nimerit vreo 3 + vreo 2 pe care ii stiam. Altcineva ii schimbase parola prin aceeasi metoda si eu i-am recuperat contul. Incercai si azi si dadui peste 2 optiuni: 1. Sa trimita un cod catre 3 persoane si sa obtii acele coduri 2. Raspuns la intrebarea de securitate Poate merge in anumite conditii dar sansele sunt destul de mici.

Use this SSL Converter to convert SSL certificates to and from different formats such as pem, der, p7b, and pfx. Different platforms and devices require SSL certificates to be converted to different formats. For example, a Windows server exports and imports .pfx files while an Apache server uses individual PEM (.crt, .cer) files. To use the SSL Converter, just select your certificate file and its current type (it will try to detect the type from the file extension) and then select what type you want to convert the certificate to and click Convert Certificate. For more information about the different SSL certificate types and how you can convert certificates on your computer using OpenSSL, see below. https://www.sslshopper.com/ssl-converter.html

Antivirus Evasion: Lessons Learned – thelightcosine Derbycon 2013 Description: Over the past year, the speaker has spent alot of time talking with people in the infoSec Community and doing research on antivirus evasion techniques. Learning what works and what doesn't. There are a lot of good ideas floating around out there. In this talk we're going to pull those ideas all together. We'll discuss the basics of the AV evasion problem, what techniques work, which ones don't and why. The talk will have a particular focus on AV evasion as it relates to Metasploit payloads. Bio: David "thelightcosine" Maloney is a Senior Software Engineer on the Metasploit team at Rapid7. Before that he was a Penetration Tester for some large Corporations, specializing in Web Applications and was a longtime contrutor to the Metasploit Framework. He is a member of the Corelan Security Team, and sort of an auxiliary member of the FALE locksport group. He is one of the founders of Hackerspace Charlotte in NC. Sursa: Antivirus Evasion: Lessons Learned – thelightcosine Derbycon 2013 (Hacking Illustrated Series InfoSec Tutorial Videos)

[h=1]How to «open» microchip and what's inside?[/h]Microchips - are indeed can be considered a black box - as long as it's working you normally don't look inside. But what if you want to? Today we'll show how to "open" chips and what's inside. WARNING! All operations with concentrated (and especially hot) acids are extremely dangerous. Only trained persons should work with them using required protective equipment (acid-prof gloves, protection glasses, protective suit, fume hood and more). Remember that you only have 2 eyes! This article is for educational purposes only, do not try to repeat!. [h=1]Opening microchips[/h]Take some microchips of interest and add concentrated sulfuric acid. Container should be closed, but not airtight, so that fumes can escape (that is extremely important). Heat it to boiling temperature (300 °C). White substance at the bottom is baking soda - it's here to neutralize accidental spills and part of fumes. After 30-40 minutes, acid "burns" plastic to carbon: After it cools down, we can sort what is ready for next step and what needs another acid bath (thick, bulky packages usually need 2-3 rounds): If pieces of carbon stuck to the microchip itself and cannot be removed mechanically, one can remove them in hot concentrated nitric acid (temperature is much lower, ~110-120 °C): [h=1]Taking a look[/h]Images are clickable (beware of 5-25Mb JPEG's). Colors are enhanced, in reality they are much less saturated. PL2303HX — USB<>RS232 converter, chips like this are used in Arduino-like boards for example: LM1117 — low-dropout linear regulator: 74HC595 — 8-bit shift register: NXP 74AHC00 — quad 2-input NAND gate. This is a nice example that 'old' tech nodes (1µm and older) are still in use. Also, note how many spare via are there for improved yield.. Micron MT4C1024 — 1 mebibit (220 bit) dynamic ram. Widely used in 286 and 386-era computers, early 90's. Die size - 8662x3969µm. AMD Palce16V8h GAL is an 32x64 array of AND elements. GAL(Generic array logic) microchips are FPGA and CPLD grandfathers. Die size - 2434x2079µm, 1µm technology. ATtiny13A — one of the smallest Atmel's microcontrollers: only 1kb of flash and 32 bytes of SRAM. Die size though appeared to be unexpectedly big (1620x1640 µm). 500nm technology node. ATmega8 — one of the most popular 8-bit microcontrollers. Die size - 2855x2795µm, technology node 500nm. KR580IK80A (later renamed to KR580VM80A) - one of the most widespread soviet processors. Contrary to popular belief, it appeared to be not an Intel 8080A (or 8080) clone, but a code-compatible redesign (while several parts are quite similar, routing is different as well as pad placement). Thinnest lines are 6µm. STM32F100C4T6B — is the smallest microcontroller made by STMicroelectronics based on ARM Cortex-M3 core. Die size - 2854x3123µm. Altera EPM7032 — Altera EPM7032 - CPLD that have seen a lot... One of the last using 5V supply. Die size - 3446x2252µm, technology node 1µm. MIFARE chip, used in Moscow's subway RFID tickets. Die size - 640x620 µm. Now black box is open Follow us on Twitter @Zeptobars or subscribe to our RSS feed - we'll continue opening chips. Sursa: How to «open» microchip and what's inside? : ZeptoBars

[h=2]Oracle Database 11g stealth password cracking vulnerability in logon protocol (CVE-2012-3137)[/h]Posted February 20, 2013 by TeamSHATTER Admin The vulnerability I will describe in this blog post has some aspects that make it especially noteworthy, which are derived from the fact that the issue lies in a critical portion of the authentication protocol. The vulnerability can be exploited in a stealth way, going undetectable because all the attacker needs is information that the Server sends freely as part of a normal authentication process. In addition, the vulnerability is so intimately part of the authentication protocol that it couldn’t be fixed without requiring an update of the client software, consequently fixing the vulnerability required to deprecate the affected protocol version and use older or newer versions. There has been some back and forth with Oracle regarding the fix for this vulnerability from the moment I reported it on April 2010. In the second half of 2011, Oracle provided a fix in the latest patchset release 11.2.0.3 and closed the issue as the fix would be included in future releases. But there were some clear problems with this fix that concerned us. The fix was not enabled by default (it required configuration changes) and it was not going to be part of a Critical Patch Update, therefore there would be no fix for all existing supported affected releases. Fortunately, the story had a happy ending, when Oracle decided to include a proper fix in October 2012 CPU for all supported affected releases and with the fix being enforced without the need of a configuration change. I will describe later how to protect a system from this vulnerability, by applying the fixes provided by Oracle and also a few workarounds for those that are not able to apply the fixes at this time, but first let’s go over the details of the vulnerability to understand where the problem lies and how risky it is. Overview of the vulnerability The Oracle Logon protocol is the native authentication mechanism that Oracle Database provides to authenticate its database users. As part of the initial process during the authentication, the client sends the username to be authenticated to the Server, which then responds with a random Session Key and the password salt of the user. There is a flaw in the way in which this Session Key, a critical component of the protocol, is protected. This flaw allows an attacker to apply password cracking techniques to guess the correct password of the user. All the attacker needs is a Session Key and the Salt which are freely sent by the Database server to anyone requesting a connection, prior to the authentication taking place. It is important to note that the attacker only needs to start the normal authentication process to obtain this Session Key, therefore the server can’t differentiate an attacker from a genuine user connection. Who is vulnerable? Oracle Database servers using logon protocol version 11 (i.e. based on SHA-1 password hashes). This includes releases 11.1.0.6, 11.1.0.7, 11.2.0.1, 11.2.0.2 and 11.2.0.3 (unless protocol version 12 is required) on all platforms. Releases 10.2.0.X are vulnerable only if Enterprise User Security (EUS) is used and the directory has SHA-1 password verifiers generated. All database users that are authenticated by the Database (user identified by password) are susceptible to this attack. This excludes external users, such as OS users, which are not authenticated by the Database. Specifically this vulnerability affects database user accounts using SHA-1-based password hashes for authentication. Accounts with SHA-1-based password verifiers appear as “11G” in the PASSWORD_VERSIONS column of DBA_USERS view. Database user accounts using exclusively a DES-based password verifier (“10G”) for authentication are unaffected. Who can exploit the vulnerability? Anyone who has network access to the database server can exploit the vulnerability, no authentication is required. The attacker only needs to know the Service name or SID of the database and a username that is authenticated using a password. For example, the highly privileged SYS user is a good attack target. What can an attacker do? A remote attacker can perform a stealth offline password brute force attack for a given username. No audit is trail left on the server for an invalid login attempt. The time that it takes to crack the password depends on the strength of the password (length, complexity, character set used, etc.) and the processing power of the attacker. For example on current mainstream CPUs it is possible to crack an 8 character lower case alphabetic password in approximately 5 hours. For more complex passwords attackers can use dictionary or hybrid approaches with high end GPUs which have a lot more processing power to crack passwords than standard CPUs. The effort is equivalent to password brute forcing of a known password hash and salt. Vulnerability Details Now I would like to describe more in detail where the vulnerability resides. As I mentioned earlier, during the initial phase of the authentication sequence, the client sends the username of the authenticating user to the Server, which responds with a random Session Key and the password salt. This Session Key is a random value that will be used to protect the password that is sent by the Client. It is encrypted using an AES block cipher with the key being the password hash for the user (stored in the SYS.USER$ table or the password file) and using PKCS7 padding. The use of PKCS7 padding is the major design flaw in this implementation. The encrypted Session Key that is sent by the Server is 48-bytes long but when decrypted (with the padding removed) it is 40-bytes long. This padding is a fixed sequence of bytes that are automatically removed when decrypted using the padding algorithm, a technique often used in conjunction with block ciphers like AES when the sequence of bytes to be encrypted is not a multiple of the block size (16-bytes for AES). If the Session Key is decrypted without removing the padding we find that all Session Keys end with a sequence of eight bytes with a value of 0×08 when the correct password hash is used as the key. E_sk = AES_192_CBC (sk || {0x08}*8, key=Password Hash) Sk (40 bytes long) = Session Key generated by the server. E_sk (48 bytes long): The session key generated by the Server (sk) encrypted with AES cipher using the password hash as the key, adding PKCS7 padding. This is what the server sends to the client. Knowing this, it is possible to verify any password and determine if it is the correct password by calculating the hash and using it to decrypt the Session Key. If the result ends with the above 8-byte padding, then the password is correct. To be precise, the probability that it is the correct password is 1-1/2^64 which means there may be 1 false positive in every 10^19 tries. This is a very large number and if we want to be sure that this is not a false positive we can double check with another Session Key. This effort decreases the chance of false positives to 1 in 10^38 which is negligible. In short, the problem is the use of PKCS7 padding to protect the Session Key that is encrypted using the password hash. A proper implementation would have used random data for the remaining bytes of the block. This is the fix implemented in logon protocol version 12. This padding provides a way to link a Session Key with the password hash. The attack is stealth because the Oracle Database server can’t differentiate a genuine authentication attempt with that of an attacker trying to get a Session Key for brute forcing. Also, as the attacker can stop the authentication process before sending a password, the authentication is never completed, therefore the native database auditing won’t record any trace of the intrusion. How to protect Limiting the network accessibility of the Oracle Database server is a good starting point to reduce exposure to potential attackers. This can be done using a network firewall or by setting node checking in SQLNET.ORA file (the settings are TCP.VALIDNODE_CHECKING, TCP.EXCLUDED_NODES and TCP.INVITED_NODES). History of the fixes TeamSHATTER reported this vulnerability to Oracle on April 21, 2010. One year and a half later, the vulnerability was fixed by releasing a new logon protocol version 12 as part of patchset 11.2.0.3 (both at client and server level). Logon protocol version 12 is no longer susceptible to this vulnerability because the padding in the Session Key is filled with random data instead of a fixed value, thus making impossible to determine if the password hash is correct or not when decrypting it. The problem with this initial fix was that the server by default was still vulnerable because the older vulnerable version 11 of the logon protocol was still allowed, most probably for backward compatibility with clients older than 11.2.0.3. To stop being vulnerable it was required to set SQLNET.ALLOWED_LOGON_VERSION equal to 12. This way only logon protocol version 12 was allowed on the server. However, this configuration change required that all client software also be upgraded to 11.2.0.3, to support the new version of the protocol. This requirement to upgrade all client software was another problem with this fix that made it very difficult to implement. Oracle closed the issue after providing this fix and told TeamSHATTER that the fix would not be included in a future Critical Patch Update. In this way the vulnerability would continue to be exploitable for most of the affected databases. Fortunately Oracle changed their mind and decided to provide a proper fix in October 2012 Critical Patch Update for all supported affected releases (not only 11.2.0.3). This time the fix is enforced by default because logon protocol version 11 is no longer allowed on the server, without the need of a configuration change. Also the fix doesn’t require a client software upgrade (there are some exceptions noted in the following section) because protocol version 10 is also allowed and clients that don’t support version 12 are automatically downgraded to version 10. In the following sections I will describe how to protect from this vulnerability. First I will explain what fixes can be installed to address the vulnerability and then I will go over some workarounds that can be applied for those that can’t install the patches right now. IMPORTANT NOTE: Make sure to test any configuration change on a test environment before implementing it on production systems. Apply October 2012 Critical Patch Update The October 2012 CPU contains fixes for this vulnerability. Oracle fixed the vulnerability by forbidding the use of logon protocol version 11 in the Oracle Database server. After applying the CPU the server will exclusively use earlier versions of the protocol, like 10 or the new version 12. It is important to understand that ending the use of logon protocol version 11, enforced by applying the CPU, could impact the ability of some clients to connect to the database server. Thus it is important to spend some time before applying the CPU to analyze if your database users or applications will be impacted by this or not. First of all, if the CPU is going to be applied to all clients before applying the CPU to the server, or all clients are release 11.2.0.3, then there is nothing to worry about because those clients support protocol version 12. The compatibility issues arise when there is no way for a client to communicate using protocol versions other than 11, like 10 or 12. If the client does not support logon protocol version 12, then version 10 will be used. If the Server does not have 10g verifiers (hashes), maybe because it is configured to only allow protocol version 11 (and above), then there is no way for the client to authenticate. If your sqlnet.ora file (located by default at {ORACLE_HOME}/network/admin) contains the line SQLNET.ALLOWED_LOGON_VERSION=11 then there is significant chance that users will be affected by applying the CPU. Running the following query will determine the user accounts that do not have 10g version verifiers: SELECT username FROM dba_users WHERE nvl(PASSWORD,'X') <> 'EXTERNAL' AND nvl(PASSWORD,'X') <> 'GLOBAL' AND password_versions NOT LIKE '%10G%'; See the Patching for CVE-2012-3137 [iD 1493990.1] document available at Oracle Support for more information on how to determine if the clients will be affected by applying the CPU. The use of logon protocol version 10 and consequently the use of DES-based password verifiers may not be adequate for some customer’s security compliance requirements. These customers may be forced to work exclusively with protocol version 12 that uses the SHA-1 passwords verifiers and contains a fix to the vulnerability described in this blog post. The following section explains this solution. Exclusive use of the new logon protocol version 12 (only compatible with client software higher than 11.2.0.3 or that has October 2012 CPU applied) This is the best way to fix this vulnerability, but it comes with some requirements that may be difficult to fulfill. This is the ideal solution because there is no need to fall back to logon protocol version 10 and lose all the security improvements introduced in version 11, like case sensitive passwords and SHA-1 salted password hashes. Implementing this protection requires to have client software that supports logon protocol version 12. The clients that support this protocol version are release 11.2.0.3 (or higher) and also clients with October 2012 (or later) CPU applied. Once the server and all clients have been upgraded, apply October 2012 CPU to the Oracle Database Server (not needed if the server is release 11.2.0.3 or higher) and configure the server to allow only logon protocol version 12: Add (or edit) the following line in the sqlnet.ora file (located at ORACLE_HOME/network/admin): SQLNET.ALLOWED_LOGON_VERSION=12 Oracle Database Server release 11.2.0.3 already has support for logon protocol version 12, even if the October 2012 CPU is not applied, but to stop being vulnerable it is required to set SQLNET.ALLOWED_LOGON_VERSION=12. IMPORTANT NOTE: After this configuration change is implemented Oracle clients that don’t support logon protocol 12 (currently client version lower than 11.2.0.3 without the October 2012 CPU applied) will not be able to connect to the server. The following sections contain information on workarounds to protect from this vulnerability for those who are unable to apply patches at this moment. Workaround 1: Implement strong password policies This workaround poses some difficult questions. How long and complex should a password be in order to be certain that no attacker can crack it in reasonable time? How long should the lifetime of a password be so that the attacker can’t crack it during that period? These questions are difficult to answer because we don’t know the resources that the attacker possesses. Password cracking techniques are advancing quickly and what seems secure today can be insecure tomorrow. In general a password longer than 12 characters (using the full character set: numbers, lower and upper case and special characters) and not derived from a Dictionary word, is considered secure. In addition to password complexity, it is also important that the password expiration is set to 90 days or less. A strong password policy can be enforced by the use of Oracle Profiles. After the password policy is modified, organizations must require users to change passwords to conform to the new requirements. Keep in mind that this workaround does not eliminate the vulnerability; instead the idea is to make an attack impractical by having passwords so difficult to crack that can’t be compromised during its restricted lifetime. Workaround 2: Use external authentication Users authenticated by external means (not by the Database) do not have a password hash stored in the database and consequently are not affected by this vulnerability. This includes users authenticated by the Operating System and the Network (SSL or third-parties like Kerberos). See Configuring Authentication for more information on implementing these authentication methods. Workaround 3: Disable protocol version 11 and use version 10 or lower (SEC_CASE_SENSITIVE_LOGON = FALSE) Protocol version 10 or lower is not vulnerable to this attack. Oracle by default keeps two different hashes for each password, a DES based hash for version 10 and lower and the SHA-1 based hash for version 11. This workaround has been divided into separate steps for better understanding. All steps are required. Step 2a must be completed first. Steps 2b and 2c can be completed subsequently in any order. Step 2b protects regular users. Step 2c protects administrative users (users granted SYSDBA , SYSOPER or SYSASM). Step 2a) Before implementing this workaround we must ensure that all users authenticated by passwords will be able to connect using protocol version 10. To verify this we need to make sure that SQLNET.ALLOWED_LOGON_VERSION setting in sqlnet.ora file is not present, or if it is present it is set to 10 or lower. We also need to make sure that all users authenticated by passwords have a version 10 password hash. The following SQL query (when executed as SYS) lists all the users which are missing 10g hashes: SELECT username FROM dba_users WHERE nvl(PASSWORD,'X') <> 'EXTERNAL' AND nvl(PASSWORD,'X') <> 'GLOBAL' AND password_versions NOT LIKE '%10G%'; If this query returns any rows, the users listed must change passwords in order to generate proper version 10 DES based hashes. Step 2b) The next step is to change SEC_CASE_SENSITIVE_LOGON initialization parameter to FALSE, so that 11g authentication is not available and 10g or lower is used (which is not vulnerable to this attack). Execute the following SQL: ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = FALSE; Step 2c) SYSDBA, SYSOPER and SYSASM users are authenticated remotely using the password file instead of the hash in the SYS.USER$ table, thus, the password file needs to be recreated. After successfully recreating the password file, only the SYS user will be present, so for any other users with SYSDBA, SYSOPER or SYSASM privileges granted on the database, you must GRANT the SYSDBA/SYSOPER/ SYSASM privilege again to add them to the new password file. To get the list of SYSDBA/SYSOPER/SYSASM users currently present in the password file execute the following query: SELECT * FROM V$PWFILE_USERS; Rename the current password file or move it to another location. The location of the password file is: {ORACLE_HOME}/dbs/orapw{SID} for Unix/Linux , or {ORACLE_HOME}\database\PWD{SID}.ora for Windows. Next, use the orapwd utility to create a password file that uses 10g password hash. This can be done by specifying parameter ignorecase=y so that a version 10 case insensitive password is used. You will be asked for the SYS password. orapwd file={password_file_location} ignorecase=y After this only the SYS user will be present on the password file. If you want other users to have SYSDBA, SYSOPER or SYSASM privileges you need to grant them now by using GRANT SYSDBA/SYSOPER/SYSASM TO … statement. Conclusion After reading this blog post, I hope you will be convinced that this is a serious issue that requires immediate attention. If patching is not an option at this moment, one of the workarounds should be implemented to minimize the risk of exposure to this vulnerability. Sursa: Oracle Database 11g stealth password cracking vulnerability in logon protocol (CVE-2012-3137) | TeamSHATTER

Python tools for penetration testers If you are involved in vulnerability research, reverse engineering or penetration testing, I suggest to try out the Python programming language. It has a rich set of useful libraries and programs. This page lists some of them. Most of the listed tools are written in Python, others are just Python bindings for existing C libraries, i.e. they make those libraries easily usable from Python programs. Some of the more aggressive tools (pentest frameworks, bluetooth smashers, web application vulnerability scanners, war-dialers, etc.) are left out, because the legal situation of these tools is still a bit unclear in Germany -- even after the decision of the highest court. This list is clearly meant to help whitehats, and for now I prefer to err on the safe side. Network Scapy: send, sniff and dissect and forge network packets. Usable interactively or as a library pypcap, Pcapy and pylibpcap: several different Python bindings for libpcap libdnet: low-level networking routines, including interface lookup and Ethernet frame transmission dpkt: fast, simple packet creation/parsing, with definitions for the basic TCP/IP protocols Impacket: craft and decode network packets. Includes support for higher-level protocols such as NMB and SMB pynids: libnids wrapper offering sniffing, IP defragmentation, TCP stream reassembly and port scan detection Dirtbags py-pcap: read pcap files without libpcap flowgrep: grep through packet payloads using regular expressions Knock Subdomain Scan, enumerate subdomains on a target domain through a wordlist Mallory, extensible TCP/UDP man-in-the-middle proxy, supports modifying non-standard protocols on the fly Pytbull: flexible IDS/IPS testing framework (shipped with more than 300 tests) Debugging and reverse engineering Paimei: reverse engineering framework, includes PyDBG, PIDA, pGRAPH Immunity Debugger: scriptable GUI and command line debugger mona.py: PyCommand for Immunity Debugger that replaces and improves on pvefindaddr IDAPython: IDA Pro plugin that integrates the Python programming language, allowing scripts to run in IDA Pro PyEMU: fully scriptable IA-32 emulator, useful for malware analysis pefile: read and work with Portable Executable (aka PE) files pydasm: Python interface to the libdasm x86 disassembling library PyDbgEng: Python wrapper for the Microsoft Windows Debugging Engine uhooker: intercept calls to API calls inside DLLs, and also arbitrary addresses within the executable file in memory diStorm: disassembler library for AMD64, licensed under the BSD license python-ptrace: debugger using ptrace (Linux, BSD and Darwin system call to trace processes) written in Python vdb / vtrace: vtrace is a cross-platform process debugging API implemented in python, and vdb is a debugger which uses it Androguard: reverse engineering and analysis of Android applications Capstone: lightweight multi-platform, multi-architecture disassembly framework with Python bindings PyBFD: Python interface to the GNU Binary File Descriptor (BFD) library Fuzzing Sulley: fuzzer development and fuzz testing framework consisting of multiple extensible components Peach Fuzzing Platform: extensible fuzzing framework for generation and mutation based fuzzing (v2 was written in Python) antiparser: fuzz testing and fault injection API TAOF, (The Art of Fuzzing) including ProxyFuzz, a man-in-the-middle non-deterministic network fuzzer untidy: general purpose XML fuzzer Powerfuzzer: highly automated and fully customizable web fuzzer (HTTP protocol based application fuzzer) SMUDGE Mistress: probe file formats on the fly and protocols with malformed data, based on pre-defined patterns Fuzzbox: multi-codec media fuzzer Forensic Fuzzing Tools: generate fuzzed files, fuzzed file systems, and file systems containing fuzzed files in order to test the robustness of forensics tools and examination systems Windows IPC Fuzzing Tools: tools used to fuzz applications that use Windows Interprocess Communication mechanisms WSBang: perform automated security testing of SOAP based web services Construct: library for parsing and building of data structures (binary or textual). Define your data structures in a declarative manner fuzzer.py (feliam): simple fuzzer by Felipe Andres Manzano Fusil: Python library used to write fuzzing programs Web Requests: elegant and simple HTTP library, built for human beings HTTPie: human-friendly cURL-like command line HTTP client ProxMon: processes proxy logs and reports discovered issues WSMap: find web service endpoints and discovery files Twill: browse the Web from a command-line interface. Supports automated Web testing Ghost.py: webkit web client written in Python Windmill: web testing tool designed to let you painlessly automate and debug your web application FunkLoad: functional and load web tester spynner: Programmatic web browsing module for Python with Javascript/AJAX support python-spidermonkey: bridge to the Mozilla SpiderMonkey JavaScript engine; allows for the evaluation and calling of Javascript scripts and functions mitmproxy: SSL-capable, intercepting HTTP proxy. Console interface allows traffic flows to be inspected and edited on the fly pathod / pathoc: pathological daemon/client for tormenting HTTP clients and servers Forensics Volatility: extract digital artifacts from volatile memory (RAM) samples LibForensics: library for developing digital forensics applications TrIDLib, identify file types from their binary signatures. Now includes Python binding aft: Android forensic toolkit Malware analysis pyew: command line hexadecimal editor and disassembler, mainly to analyze malware Exefilter: filter file formats in e-mails, web pages or files. Detects many common file formats and can remove active content pyClamAV: add virus detection capabilities to your Python software jsunpack-n, generic JavaScript unpacker: emulates browser functionality to detect exploits that target browser and browser plug-in vulnerabilities yara-python: identify and classify malware samples phoneyc: pure Python honeyclient implementation PDF Didier Stevens' PDF tools: analyse, identify and create PDF files (includes PDFiD, pdf-parser and make-pdf and mPDF) Opaf: Open PDF Analysis Framework. Converts PDF to an XML tree that can be analyzed and modified. Origapy: Python wrapper for the Origami Ruby module which sanitizes PDF files pyPDF: pure Python PDF toolkit: extract info, spilt, merge, crop, encrypt, decrypt... PDFMiner: extract text from PDF files python-poppler-qt4: Python binding for the Poppler PDF library, including Qt4 support Misc InlineEgg: toolbox of classes for writing small assembly programs in Python Exomind: framework for building decorated graphs and developing open-source intelligence modules and ideas, centered on social network services, search engines and instant messaging RevHosts: enumerate virtual hosts for a given IP address simplejson: JSON encoder/decoder, e.g. to use Google's AJAX API PyMangle: command line tool and a python library used to create word lists for use with other penetration testing tools Hachoir: view and edit a binary stream field by field py-mangle: command line tool and a python library used to create word lists for use with other penetration testing tools Other useful libraries and tools IPython: enhanced interactive Python shell with many features for object introspection, system shell access, and its own special command system Beautiful Soup: HTML parser optimized for screen-scraping matplotlib: make 2D plots of arrays Mayavi: 3D scientific data visualization and plotting RTGraph3D: create dynamic graphs in 3D Twisted: event-driven networking engine Suds: lightweight SOAP client for consuming Web Services M2Crypto: most complete OpenSSL wrapper NetworkX: graph library (edges, nodes) Pandas: library providing high-performance, easy-to-use data structures and data analysis tools pyparsing: general parsing module lxml: most feature-rich and easy-to-use library for working with XML and HTML in the Python language Whoosh: fast, featureful full-text indexing and searching library implemented in pure Python Pexpect: control and automate other programs, similar to Don Libes `Expect` system Sikuli, visual technology to search and automate GUIs using screenshots. Scriptable in Jython PyQt and PySide: Python bindings for the Qt application framework and GUI library The Python Arsenal for Reverse Engineering is a large collection of tools related to reverse engineering. There is a SANS paper about Python libraries helpful for forensic analysis (PDF). For more Python libaries, please have a look at PyPI, the Python Package Index. Sursa: Dirk Loss: Python tools for penetration testers

Linux Kodachi Posted by W. Almaawali on Oct 20, 2013 The purpose of Linux Kodachi is to provide a secure, anti forensic, and anonymous operating system considering all features that a person who is concern about privacy would need to have in order to be secure. Kodachi is very easy to use all you have to do is boot it up on your pc then you should have an operating system with a vpn connection established + Tor Connection established + DNScrypt service running. No setup or linux knowledge is required from your side we do it all for you. The entire OS is functional from your temporary memory RAM so once you shut it down no trace is left behind all your activities are wiped out for quick guide please click here. Kodachi is based on the solid Linux Debian with customized Gnome3 this makes Kodachi stable, secure, and unique. View screenshots: 1 – 2 – 3 – 4 – 5 – 6 – 7 – 8 – 9. How to use it: First option (recommended): Download the ISO file and burn it on a USB flash memory using a free tool like Rufus or Linux Live then boot your PC from it. You will need to boot and press F12 key to get the boot menu and select your USB on old PCS you have to change your BIOS settings to allow the system to boot from USB as the first option. Second option: Download the ISO file and burn it on a DVD using a free tool like DAEMON Tools then boot your PC from it. Third option: Download the ISO file boot it up using Vmware player or Virtualbox. Fourth option: From first or second option you can permanently install it on your PC. Sursa: Linux Kodachi | Eagle Eye Digital Solutions | Muscat Oman

[h=1]Adobe SWF Investigator[/h] [h=2]Perform quick, comprehensive, analysis of SWF applications[/h] Adobe® SWF Investigator is the only comprehensive, cross-platform, GUI-based set of tools, which enables quality engineers, developers and security researchers to quickly analyze SWF files to improve the quality and security of their applications. With SWF Investigator, you can perform both static and dynamic analysis of SWF applications with just one toolset. SWF Investigator lets you quickly inspect every aspect of a SWF file from viewing the individual bits all the way through to dynamically interacting with a running SWF. [h=3]Download and Discuss[/h] Download SWF Investigator Discuss SWF Investigator [h=3]SWF Investigator Features[/h] From a static perspective, you can disassemble ActionScript 2 (AS2) and ActionScript 3 (AS3) SWFs, view SWF tags and make binary changes to SWF files. SWF Investigator also lets you view associated information, including local shared objects (LSOs) and per site settings. From a dynamic perspective, you can call functions within the SWF, load the SWF in various contexts, communicate via local connections and send messages to Action Message Format (AMF) endpoints in order to test more effectively. SWF Investigator contains an extensible fuzzer for SWF applications and AMF services, so you can search for common Web application attacks. This toolset also provides a variety of utilities including encoders and decoders for SWF data, as well as a basic compiler for testing small pieces of ActionScript code. [h=4]Additional Benefits[/h] SWF Investigator is the only application of its kind that's built on Adobe AIR – a versatile runtime that supports ActionScript, the language used to create SWF applications. This allows for native interaction between the SWF Investigator and the SWF application. Using ActionScript also makes the source code of the tool more intuitive for SWF developers. SWF Investigator has the ability to auto-update, so you don't need to worry about whether or not you have the most current version. Since it's an open source AIR application, SWF Investigator can be modified to fit your environment, and it is cross-platform. Download: Download Adobe SWF Investigator - Adobe Labs

[h=1]LANs.py[/h] Multithreaded asynchronous packet parsing/injecting ARP poisoner. Individually poisons the ARP tables of the target box, the router and the DNS server if necessary. Does not poison anyone else on the network. Displays all most the interesting bits of their traffic and can inject custom html into pages they visit. Cleans up after itself. Prereqs: Linux, python-scapy, python-nfqueue (nfqueue-bindings 0.4-3), aircrack-ng, python-twisted, BeEF (optional), and a wireless card capable of promiscuous mode if you choose not to use the -ip option Tested on Kali 1.0. In the following examples 192.168.0.5 will be the attacking machine and 192.168.0.10 will be the victim. All options: python LANs.py [-a] [-h] [-b BEEF] [-c CODE] [-u] [-ip IPADDRESS] [-vmac VICTIMMAC] [-d] [-v] [-dns DNSSPOOF] [-r IPADDRESS] [-set] [-p] [-na] [-n] [-i INTERFACE] [-rip ROUTERIP] [-rmac ROUTERMAC] [-pcap PCAP] [h=2]Usage[/h] [h=3]Simplest usage (including active user targeting):[/h] python LANs.py Because there's no -ip option this will ARP scan the network, compare it to a live running promiscuous capture, and list all the clients on the network including their Windows netbios names along with how many data packets they're sending so you can immediately target the active ones. The ability to capture data packets they send is very dependent on physical proximity and the power of your network card. then you can Ctrl-C and pick your target which it will then ARP spoof. Simple target identification and ARP spoofing. Sursa: https://github.com/DanMcInerney/LANs.py

[h=3]Evil Foca - IPv4 and IPv6 Penetration testing tool[/h] Evil Focais a tool for Pentesters and Security Auditors to perform security testing in IPv4/ IPv6 data networks. The tool is capable to do different attacks such as: MITM on IPv4 networks using ARP Spoofing and DHCP ACK injection. MITM on IPv6 networks using Neighbor Advertisement Spoofing, SLAAC Attack, fake DHCPv6. DoS (Denial of Service) on IPv4 networks using ARP Spoofing. DoS (Denial of Service) on IPv6 networks using SLAAC Attack. DNS Hijacking. Download: http://www.informatica64.com by d3v1l at 7:45 PM Sursa: Security-Shell: Evil Foca - IPv4 and IPv6 Penetration testing tool

[h=1]tundeep[/h] Tundeep is a layer 2 VPN/injection tool that resides [almost] entirely in user space on the victim aside from the pcap requirement. This can be handled via a silent install however. The tool will build on Linux and Windows victims. Windows compilation is achieved using Cygwin. The attacker must be a Linux machine however as kernel TUN/TAP support is required. It works just fine on Backtrack/Kali. —– DOWNLOAD/CHANGELOG: v0.1a_20130910: [DOWNLOAD tundeep_v0.1a_20130910.tgz] v0.2a_20130916: [DOWNLOAD tundeep_v0.2a_20130916.tgz] tundeep_v0.2a_20130916: - IPv6 support (-6, -T) - Compression support (-C) – must be enabled on both sides - Better error checking and debugging - Misc bug fixes and code improvements - Makefile improvements to detect Cygwin/Linux without manual edits - README updates - Added default checksum feature (-K disables) – added overhead, improved reliability. Must be disabled on both sides Tundeep can also be found on GitHub Sursa + Tutorial: Tundeep | IO Digital Sec

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