Aerosol

@quadxenon care e problema ta fiindca postez eu? Daca ai chestii interesante si vrei sa ajuti posteaza nu te opreste nimeni, in momentul de fata ai numai offtopic si spam. Eu postez chestii interesante ( cel putin dupa parerea mea) Te-as ruga sa nu mai faci spam la posturile mele, multumesc mult.

Data recovery has been needed since man started to write things down. Why? Because what ever medium they tried to store the data on, it has always been susceptible to destruction. From earthquakes versus wall paintings to fire versus the library of Alexandria to head crashes versus your corporate file server. There has always been a weakness in how we have stored our information. While the risk mitigation to that sounds easy (back it up), the reality of the matter is that data loss happens all the time. When it does, there are 2 methods of data recovery. Physical recovery — Make sure the physical medium is functional Logical Recovery — Once the physical works, get the data The data recovery process has 4 basic steps. Physical repair Image the device Recover the data Fix the data Now to put this in perspective, the first method and the first step of data recovery go together hand in hand. The second method is more of a software data recovery that takes steps 2-4. Most people can do logical recovery with relatively inexpensive tools such as getdataback, rstudios, or even most of the forensic suites out there today. Physical recovery is an entirely different issue. It takes time, patience, a steady hand, practice, a clean room, the proper equipment, and an almost identical donor to use as a parts replacement cadaver. It is just like surgery and the donor needs to be compatible with the recipient if there needs to be an organ transplant. Just like the human body, the internals or organs of a hard drive are very fragile when not in the most ideal of environments. Platter based hard drives have more moving parts than a Solid State Drive (SSD), but the difficulty is still there. Just as in a normal transplant example, you need to understand that there is never a 100% guarantee that the recipient will come out of the surgery and recover. You can just hope and pray that the hard drive comes out and lives long enough to transfer the data to a secondary host so you can perform logical data recovery. What causes the Click-o-Death? It is because the SA cannot be read. You can have 4 main reasons (and a possible combination of them) for this to happen: Heads are dead Preamp is dead SA corrupted or scratched Firmware on the PCB This is a video of a head stack replacement. There is a donor drive and a recipient drive. As luck would have it, there is only half a head, so the replacement was very fast with minimal risk to the donor head stack. Enjoy the video! Source

Downloading Xplico In this article we’ll present Xplico, which is a network forensics tool installed in major digital forensics Linux distributions like Kali, Backtrack, Security Onion, DEFT, etc. In this tutorial, we’ll take a look at the DEFT Linux distribution, which we can download from here: we need to download the 3GB large deft-8.1.iso file. Additionally, we can also take a look at the enclosed md5.txt file, which presents the MD5 hashes of the present files, presented on the picture below. We can use the MD5 hashes in order to check whether the downloaded file has the same signature, which verifies that we’ve downloaded the same version of the file. Thus, nobody has tampered with the file when being downloaded, which can happen if an attacker has gained access to one of the intermediary points in the data transmission: in most cases, it happens through MITM attacks on your local LAN. It’s fairly easy to check whether the files are the same by using the md5sum program as presented below. # md5sum -b deft-8.1.iso 76bad80c7ea1552c9bd97bcca5de8d50 *deft-8.1.iso Notice that the hash of the deft-8.1.iso matches the one presented at http://www.deftlinux.net/files/md5.txt? This is a clear indication that the files are the same and at this point, we can use the file without a bad aftertaste, since we know the file is valid and legit. After downloading a valid version of DEFT, we can boot it up by using standard virtualization tools like Vmware/VirtualBox, but we’ll use Qemu. First we have to create the Qemu image with the command below: # qemu-img create -f qcow2 /home/deft.qcow2 20G Then, we can use the following script to start DEFT Linux: #!/bin/bash /usr/bin/qemu-kvm -machine accel=kvm -cpu core2duo -name DEFT -cdrom /home/deft-8.1.iso -boot order=d -drive file=/home/deft.qcow2,if=ide,cache=writeback -m 1G -enable-kvm -monitor stdio -smp 1,sockets=1,cores=1,threads=1 -nodefaults -usbdevice tablet -rtc base=localtime -full-screen -vga qxl -device virtio-serial-pci -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -device e1000,netdev=net0,mac=00:26:c6:21:cf:39 -netdev tap,id=net0,script=no,ifname=tap0,downscript=no We can also use simpler script with just a few lines, but the above script is used to set the specific MAC address to the eth0 network interface as well as use user networking and also share the /home/ directory between host and guest. Then, we can boot into the livecd version of the DEFT operating system or install the system to /home/deft.qcow2 as already configured. When the system has finished booting up, we can see the eth0 interface settings, where the IP address 172.16.1.21 has been assigned to the eth0 interface. Next, we must first start the Apache web server and Xplico application in Menu – Service – Apache start/Xplico start, as shown below. When both services are started, we need to load the Xplico application in a browser by going to: Menu – DEFT – Network Forensics – Xplico as shown below. A Firefox web browser will be started on http://172.16.1.21:9876/users/login as shown on the picture below, where we have to login to Xplico with default credentials xplico:xplico. Xplico Components The Xplico system is built on four components: Decoder Manager IP Decoder Data Manipulators Visualization System When connected to the Xplico web interface, we can start a new case by either uploading a PCAP capture file or acquire the data live from existing interfaces. In our case, we’ll create a test use case, which defines the capture point in a network. After creating a new case, we also have to create a new session, where each case can have multiple sessions differentiated by the time interval; note that each session can have multiple pcap files. A new session can be created by clicking on the ‘New Session’ link on the left side of the menu. In the new session, the following will be shown, where all the supported protocols don’t have any numbers assigned to them, since we haven’t yet uploaded a pcap file. The picture below also presents an option where we can choose the pcap file and upload it. When the pcap file is uploaded, the Xplico will automatically start decoding and analyzing the file, which will be shown by a red text ‘File uploaded, start decoding…’ on the top of the page. Once the file has been decoded, we can choose the ‘View all hosts’ option under the ‘Status Hosts’ as seen below; alternatively we can select an individual host. The analyzed results will look something like presented below. We can see that Xplico can automatically analyze a lot of protocols. The great thing about Xplico is that it can automatically parse and analyze the pcap files or acquired network traffic. Imagine the pcap file being analyzed by Wireshark, where we have to input the filter in order to show only a subset of all data; the data which we’re interested in. Then we can select the interesting packet, right-click on it and follow the stream. Doing that for each and every packet would quickly become tiresome, since we don’t have the time or energy to analyze all the traffic in such a way. Therefore, Xplico is a great tool which can be used to considerably reduce the time that would normally be needed for analysis. Let’s now take a look at what Xplico can do by using the analyzed pcap file. If we click on the Graphs – DNS, all the DNS requests will be presented in a easy to understand manner. Each entry has four fields: Date, Host, CName and IP address. The Date presents the time at which the DNS query has been sent, the Host presents the domain name for which IP was requested, the CName presents the DNS cname records (if one exists – cname is an alias of the domain) and IP address presents the requested IP address. Let’s take a look at how Xplico identifies and presents the DNS protocol information, which is presented below. To present the DNS request for twitter.com in a Wireshark, we can use the ‘dns and dns.qry.name==twitter.com’ filter as shown below. The second column on the picture above uses the number of seconds since the start of the capture, but doesn’t show us the exact time at which request was made. That can be changed directly in Wireshark by selecting an option View – Time Display Format – Date and Time of Day. Notice that the first twitter request in Xplico has been issued at 15:08:08, while in Wireshark the date is 17:08:08? The time difference comes because the data was obtained from a computer in a different time zone than the time zone where DEFT Linux has been installed. To solve the issue, we have to change the time zone of the DEFT Linux, which we can do by executing the “sudo dpkg-reconfigure tzdata” command and choosing the right time zone as presented below. After that we have to create a new session and reupload the data for changes in Xplico to take effect. The new DNS requests will now look like below, where we can see that the time is the same as in Wireshark. The Host field as shown in Xplico can just as easily be seen in Wireshark in the Info column; it isn’t as pretty though, because the Wireshark presents some other information not that relevant to some use cases. Therefore, Xplico does a good job abstracting away the details in order to present the information in a clear and concise way. The CName column can also be easily seen in the Wireshark in the Info column. In order to see it we have use the “dns and dns.qry.name==code.jquery.com” filter, since twitter.com didn’t have the CNAME. You can see the same information as in previous Xplico screenshot on the picture below, where the “code.jquery.netdna-cdn.com” is shown. The requested IP address can also be viewed in the Info column in Wireshark as seen below: notice that the returned A DNS records contain four IP addresses all relative to the twitter.com domain? If we look at the packet details in Wireshark, we can see the Answers section, which actually contains the four returned addresses. But Xplico reported just one IP address, which is the first one on the list that is used anyway. Upon subsequent DNS requests for the same domain, the order of IP addresses will very likely be different, which will cause the client to use that IP address. Therefore, we’re not losing much when Xplico doesn’t report all returned IP addresses, because the first one is used anyway. We’ve seen how Xplico compared to Wireshark when analyzing data: Xplico has analyzed the data and abstracted away all the details that we’re not interested in, which makes it great for quickly viewing the results of analyzed data. Let’s also see the other features of Xplico, which allows us to see the actual GET requests, which can be filtered by input string. The picture below presents all the requests to webpage ‘serverfault.com’: One really cool feature of Xplico is reconstruction of images, which is accessible in the Web – Images menu as seen below. Notice that the images can be seen just as they presented in an actual web page. This makes it very easy to see the actual images, while viewing such information in Wireshark is very hard. In the Undetected menu we can observe all the traffic that wasn’t detected and processed by Xplico. Such traffic is presented below, where we can see the date of the actual traffic, the destination domain names and port numbers, as well as other information Conclusion In this article we’ve seen that Xplico is a great tool for analyzing network traffic, since it has multiple protocol dissectors, which can be used to analyze specific protocols inside the .pcap file. The obtained results are presented in an easy to undestand web interface, which does a great job in presenting all the relevant information to the users. We’ve also taken a look at Wireshark and how it compares to Xplico, but let me summarize that Xplico is not an alternative to Wireshark; it’s merely a tool which does a great job in analyzing and presenting information in nice colorful graphs and tables in a web interface. References [1] Xplico, Xplico - Open Source Network Forensic Analysis Tool (NFAT). Source

Computer forensics is a very important branch of computer science in relation to computer and Internet related crimes. Earlier, computers were only used to produce data but now it has expanded to all devices related to digital data. The goal of Computer forensics is to perform crime investigations by using evidence from digital data to find who was the responsible for that particular crime. For better research and investigation, developers have created many computer forensics tools. Police departments and investigation agencies select the tools based on various factors including budget and available experts on the team. These computer forensics tools can also be classified into various categories: Disk and data capture tools File viewers File analysis tools Registry analysis tools Internet analysis tools Email analysis tools Mobile devices analysis tools Mac OS analysis tools Network forensics tools Database forensics tools In this post, we are listing a few important and popular data forensics tools. Before proceeding further, I want to make it clear that tools are added in random order. So, please do not try to consider it as a ranking of the tools. 1. Digital Forensics Framework Digital Forensics Framework is another popular platform dedicated to digital forensics. The tool is open source and comes under GPL License. It can be used either by professionals or non-experts without any trouble. It can be used for digital chain of custody, to access the remote or local devices, forensics of Windows or Linux OS, recovery hidden of deleted files, quick search for files’ meta data, and various other things. Download: Free & open Source digital forensics software 2. Open Computer Forensics Architecture Open Computer Forensics Architecture (OCFA) is another popular distributed open-source computer forensics framework. This framework was built on Linux platform and uses postgreSQL database for storing data. It was built by the Dutch National Police Agency for automating digital forensics process. It is available to download under GPL license. Download: Open Computer Forensics Architecture | SourceForge.net 3. CAINE CAINE (Computer Aided Investigative Environment) is the Linux distro created for digital forensics. It offers an environment to integrate existing software tools as software modules in a user friendly manner. This tool is open source. Read More about it: CAINE Live USB/DVD - computer forensics digital forensics 4. X-Ways Forensics X-Ways Forensics is an advanced platform for digital forensics examiners. It runs on all available version of Windows. It claims to not be very resource hungry and to work efficiently. If we talk about the features, find the key features in the list below: Disk imaging and cloning Ability to read file system structures inside various image files It supports most of the file systems including FAT12, FAT16, FAT32, exFAT, TFAT, NTFS, Ext2, Ext3, Ext4, Next3®, CDFS/ISO9660/Joliet, UDF Automatic detection of deleted or lost hard disk partition Various data recovery techniques and powerful file carving Bulk hash calculation Viewing and editing binary data structures using templates Easy detection of and access NTFS ADS Well maintained file header Automated activity logging Data authenticity Complete case management Memory and RAM analysis Gallery view for pictures Internal viewer for Windows registry file Automated registry report Extracts metadata from various file types Ability to extract emails from various available email clients. And many more.. You can read the full list here: X-Ways Forensics: Integrated Computer Forensics Software 5. SANS Investigative Forensics Toolkit – SIFT SANS Investigative Forensics Toolkit or SIFT is a multi-purpose forensic operating system which comes with all the necessary tools used in the digital forensic process. It is built on Ubuntu with many tools related to digital forensics. Earlier this year, SIFT 3.0 was released. It comes for free or charge and contains free open-source forensic tools. In a previous post at resource.infosecinstitute.com, we already covered SIFT in detail. You can read those posts about SIFT to know more about this digital forensics platform. Download: SANS SIFT Kit/Workstation: Investigative Forensic Toolkit Download 6. EnCase EnCase is another popular multi-purpose forensic platform with many nice tools for several areas of the digital forensic process. This tool can rapidly gather data from various devices and unearth potential evidence. It also produces a report based on the evidence. This tool does not come for free. The license costs $995. Read more about EnCase: https://www.guidancesoftware.com/products/Pages/encase-forensic/overview.aspx 7. Registry Recon Registry Recon is a popular registry analysis tool. It extracts the registry information from the evidence and then rebuilds the registry representation. It can rebuild registries from both current and previous Windows installations. It is not a free tool. It costs $399. Read more about it: Arsenal Recon - Computer Forensics Tools by Computer Forensics Experts 8. The Sleuth Kit The Sleuth Kit is a Unix and Windows based tool which helps in forensic analysis of computers. It comes with various tools which helps in digital forensics. These tools help in analyzing disk images, performing in-depth analysis of file systems, and various other things. Read more about it here: The Sleuth Kit (TSK) & Autopsy: Open Source Digital Forensics Tools 9. Llibforensics Libforensics is a library for developing digital forensics applications. It was developed in Python and comes with various demo tools to extract information from various types of evidence. Read more here: libforensics - A digital forensics library for Python - Google Project Hosting 10. Volatility Volatility is the memory forensics framework. It used for incident response and malware analysis. With this tool, you can extract information from running processes, network sockets, network connection, DLLs and registry hives. It also has support for extracting information from Windows crash dump files and hibernation files. This tool is available for free under GPL license. Read more about the tool: volatility - An advanced memory forensics framework - Google Project Hosting 11. WindowsSCOPE WindowsSCOPE is another memory forensics and reverse engineering tool used for analyzing volatile memory. It is basically used for reverse engineering of malwares. It provides the capability of analyzing the Windows kernel, drivers, DLLs, virtual and physical memory. Read more: WindowsSCOPE Cyber Forensics - Ultimate - WindowsSCOPE: Windows Memory Forensics, Cyber Security Tools 12. The Coroner’s Toolkit The Coroner’s Toolkit or TCT is also a good digital forensic analysis tool. It runs under several Unix-related operating systems. It can be used to aid analysis of computer disasters and data recovery. Read more: The Coroner's Toolkit (TCT) 13. Oxygen Forensic Suite Oxygen Forensic Suite is a nice software to gather evidence from a mobile phone to support your case. This tool helps in gathering device information (including manufacturer, OS, IMEI number, serial number), contacts, messages (emails, SMS, MMS), recover deleted messages, call logs and calendar information. It also lets you access and analyze mobile device data and documents. It generates easy to understand reports for better understanding. More information here: Oxygen*Forensic® Suite - Features 14. Bulk Extractor Bulk Extractor is also an important and popular digital forensics tool. It scans the disk images, file or directory of files to extract useful information. In this process, it ignores the file system structure, so it is faster than other available similar kinds of tools. It is basically used by intelligence and law enforcement agencies in solving cyber crimes. Download it here: Index of /downloads/bulk_extractor 15. Xplico Xplico is an open source network forensic analysis tool. It is basically used to extract useful data from applications which use Internet and network protocols. It supports most of the popular protocols including HTTP, IMAP, POP, SMTP, SIP, TCP, UDP, TCP and others. Output data of the tool is stored in SQLite database of MySQL database. It also supports IPv4 and IPv6 both. Read more about this tool here: Xplico – About 16. Mandiant RedLine Mandiant RedLine is a popular tool for memory and file analysis. It collects information about running processes on a host, drivers from memory and gathers other data like meta data, registry data, tasks, services, network information and Internet history to build a proper report. Read more here: https://www.mandiant.com/resources/download/redline 17. Computer Online Forensic Evidence Extractor (COFEE) Computer Online Forensic Evidence Extractor or COFEE is a tool kit developed for computer forensic experts. This tool was developed by Microsoft to gather evidence from Windows systems. It can be installed on a USB pen drive or external hard disk. Just plug in the USB device in the target computer and it starts a live analysis. It comes with 150 different tools with a GUI based interface to command the tools. It is fast and can perform the whole analysis in as few as 20 minutes. To law enforcement agencies, Microsoft provides free technical support for the tool. Official website: https://cofee.nw3c.org/ 18. P2 eXplorer P2 eXplorer is a forensic image mounting tool which aims to help investigating officers with examination of a case. With this image, you can mount forensic images as a read-only local and physical disc and then explore the contents of the image with file explorer. You can easily view deleted data and unallocated space of the image. It can mount several images at a time. It supports most of the image formats including EnCasem, safeBack, PFR, FTK DD, WinImage, Raw images from Linux DD, and VMWare images. It supports both logical and physical image types. This tool comes for $199, but you can grab the limited feature version of the tool for free. Read more here: https://www.paraben.com/p2-explorer.html 19. PlainSight PlainSight is another useful digital forensics tool. It is a CD based Knoppix which is a Linux distribution. Some of its uses include viewing Internet histories, data carving, checking USB device usage, memory dumps extracting password hashes, information gathering, examining Windows firewall configuration, seeing recent documents, and other useful tasks. For using this too, you only need to boot from the CD and the follow the instructions. This tool is available for free. Read more here: PlainSight | Home 20. XRY XRY is the mobile forensics tool developed by Micro Systemation. It is used to analyze and recover crucial information from mobile devices. This tool comes with a hardware device and software. Hardware connects mobile phones to PC and software performs the analysis of the device and extract data. It is designed to recover data for forensic analysis. The latest version of the tool can recover data from all kind of smartphones including Android, iPhone and BlackBerry. It gathers deleted data like call records, images, SMS and text messages. Read more about it: http://www.msab.com/xry/what-is-xry 21. HELIX3 HELIX3 is a live CD-based digital forensic suite created to be used in incident response. It comes with many open source digital forensics tools including hex editors, data carving and password cracking tools. If you want the free version, you can go for Helix3 2009R1. After this release, this project was overtaken by a commercial vendor. So, you need to pay for most recent version of the tool. This tool can collect data from physical memory, network connections, user accounts, executing processes and services, scheduled jobs, Windows Fegistry, chat logs, screen captures, SAM files, applications, drivers, environment variables and Internet history. Then it analyzes and reviews the data to generate the complied results based on reports. Helix3 2008R1 can be downloaded here: https://e-fenseinc.sharefile.com/d/sda4309a624d48b88 The enterprise version is available here: e-fense :: Cyber Security & Computer Forensics Software Conclusion These are a few popular digital forensics tools used by various law enforcement agencies in performing crime investigations. In this post, I added all kind of tools like premium, free, open source, computer forensics, mobile forensics and others. If you are going to start learning digital forensics, you can download or buy these tools and start working on those. It will help you in better understanding the whole process and tools. These are not the only tools. There are various other free and premium tools available in the market. So, you can do more research on the tools to know more about those tools. These tools are added in random order. So, please don’t consider it as a ranking of the tools. I just tried to make a list of popular digital forensics tools only. With the increasing use of digital data and mobile phones, digital forensics has become more important. Cyber crimes are also increasing day by day. So companies are also trying to launch more powerful version of the tools, and you need to be in touch of latest digital forensics news to know about recent releases. Further reading about digital forensics: http://www.forensics.nl/ Digital forensics - Wikipedia, the free encyclopedia CIO Magazine Issue Archive | CIO Source

In this tutorial we’ll take a look at how we can install and configure the Samba server on a host operating system to create a shared folder, which the guest Qemu virtual machines can use. The first thing we have to do is install Samba, which we can do with one of the following commands based on whichever Linux distribution we have: # Gentoo emerge samba # Ubuntu apt-get install samba Configuration After installing Samba, we have to configure it to allow sharing folders on the host computer. The configuration file can be found under /etc/samba/smb.conf and is divided into sections enclosed into brackets [ and ]. Any line starting with a semicolon ‘;’ or hash ‘#’ is a comment and doesn’t do anything to guide the operation of Samba server except give us the description about what each option does. [global]: global settings that are applied to every other section in the configuration file. [homes]: an example of a shared folder, which we can see when scanning a network. [printers]: an example configuration for sharing printing capabilities over the network. The default configuration smb.conf has the following sections: The smb.conf has the following configuration options: Option Description workgroup The name of the workgroup. server string The NT description field indicating the banner of the Samba service and possibly its version: if %v is used. security Used security mode, where the following modes are available: - user: the user authenticates with a username and password and the server checks whether the correct credentials were submitted. After that the user will be able to access and mount shares on the server. - share: the user sends an authentication request with a password to access a certain share of the server, where the user has to authenticate for each share it wants to access. - server: the user sends username and password to the Samba server, which in turn sends it to another server on the network, which checks for the validity of the credentials. - domain: the user authenticates to the domain controller, which gives it access to the Samba server. - ads: the user authenticates to the active director. hosts allow Used to restrict access to certain IPs on the internal network. We must specify networks in a special format, where the last portion of the network range is not included. For example: when we would like to specify that we want to allow IPs in a network 192.168.1.0/24 access this SMB server, we have to specify it like this: ’192.168.1.’ and not ’192.168.1.0?. load printers Specifies whether we want to automatically rather than manually load the printer list. password server Only applicable to ‘server’ security mode and specifies the password server that will be used to check whether the entered password was correct or not. If we specify the ‘*’ as the value, Samba will try to find the domain controller by itself. interfaces Specifies the interfaces the Samba will use. wins support Specifies whether the WINS server is enabled or disabled. wins server Instructs Samba to act as WINS client and specifies the IP address of WINS server. wins proxy Instructs Samba to answer name resolution queries on behalf of non WINS capable client. dns proxy Specifies whether Samba should try to resolve NetBIOS names via DNS lookups. interfaces Specifies the interfaces on which the Samba will listen for incoming messages. valid users Specifies the users allowed to access the share, where we can list an arbitrary number of users. Alternatively, we can use @group to specify a group that has access to the share; users can then be added to the group in /etc/group to give them access to share. We should use a group when multiple users have to access the same shared folder, so we can give them filesystem access with a simple “chmod 770 /home/share/” and “chgrp group /home/share”. invalid users A list of users who should never be allowed to access the share. We can specify the following in the global configuration, so system users cannot have access to shares: invalid users = root bin daemon … admin users A list of users who will have superuser/root access to the share. write list A list of users who have read/write access to the share, although the share is marked as read-only with “read only = yes” option. read list A list of users who have read only access to the share, although the share is marked as writable with “writable = yes” option. comment A description of the share. path The actual path on the Samba server, which will be shared over the network by using SMB protocol. browseable Specifies whether the clients can browse the share or not. guest ok Specifies whether clients are able to connect to the share with a guest account without providing a password, which works only when using share level security. guest account Is used when we want to enable a guest account, which doesn’t require a password to be able to access the SMB server. We must specify the account on the operating system that Samba will use to access the share on the system, which can be set to: nobody, guest or any other actual user on the system. guest only Restricts access only to guest accounts, so all clients connecting to the share will be connected as guests. read only Specifies whether the share is readable or readable+writeable. writable This configuration variable is basically the same as “read only” and is used for the same purposes. Only one of the “writable” and “guest only” need to be specified. create mask Specifies the mask of permissions under which new files will be created. force user When writing a file to the share, the owner of the file becomes the one specified with “force user”. force group When writing a file to the share, the group of the file becomes the one specified with “force group”. Lets take a look at how clients authenticate to Samba shares. At first Samba checks whether the share supports guest accounts and if it doesn’t, the user must enter username and password to authenticate. When we use share security mode, we’re effectively giving a share a password, which can enable every client that knows the password to connect to that share. If the share is guest only, the user is immediately given access to the share with the user rights as specified with the “guest account” configuration directive; there is no password checking being done. In user security mode, where each client must authenticate with its own username and password, which gives him access to the share. The server and domain security modes are effectively the same as user security mode, except that another server is used to prove whether the entered credentials were correct or not. Note that when a user logs in to a Samba share, it must pass two levels of restriction. First, it must login with an existing username and password according to Samba. Second, it must also have permission to access to the directory according to the filesystem. Samba also check the operating system users as well as the ones used with smbpasswd: we must keep this in mind when working with users with Samba. The only exception is the guest account, which we’ll use in this tutorial. Creating a Shared Folder To create a shared folder, we much configure the “[homes]” configuration section in smb.conf configuration file. The first thing we can do is rename the share to whichever name we want, like “[shared]“. Since we want the same shared folder as with VirtualBox, we need to use the share security mode, which gives us access to guest only share, which we can use without authenticating. To do that we need to use the following configuration option in the “[global]” section of smb.conf. security = share We also need to add the “guest account” configuration option, which specifies the system account under which we’ll have access to the share. In our case this is user nobody and the configuration option is seen below. guest account = nobody Note that the user ‘nobody’ must be present on the system, which we can easily verify by grepping for the word ‘nobody’ when printing the contents of /etc/passwd file. # cat /etc/passwd | grep nobody nobody:x:65534:65534:nobody:/var/empty:/bin/false After that we only need to configure the share we would like to use. We need to specify the comment of the share, the path to the directory we would like to share and whether it’s readable and writable. Configuration options like the ones below are in order: comment = Shared Folder path = /home/user/shared browseable = yes guest ok = yes guest only = yes writable = yes force user = nobody force group = shared create mask = 0770 By declaring the share as guest only, we’ve effectively given access to any user connecting to it without entering a password. If we connect to the share now, it would present us with a shared folder without entering for username and password. On the picture below we can see the contents of the shared folder, which contains only the hello.txt text file. But because we’re accessing the file as user nobody, we don’t have permissions to write to the shared folder, which means we can’t delete the hello.txt file. If we try to delete it nevertheless, the attempt will fail with a message that we don’t have enough permissions to perform this action as seen below. If we list the contents of the shared folder on the host operating system, we can see that only the user has write access to the file, but we’re performing the action in the name of nobody. # ls -l shared total 0 -rw-r--r-- 1 user user 0 Dec 3 16:39 hello.txt In order to give both users access to the shared folder, we need to create another group named shared with groupadd command and add users ‘user’ and ‘nobody’ to that group. That can be achieved with the commands seen below. # groupadd shared # gpasswd -a user shared # gpasswd -a nobody shared After that we need to change the group of the files in the shared directory to shared and chmod 770 to give read and write access to both users on the system. # chown -R nobody:shared /home/user/shared # chmod 770 /home/user/shared After that you should be able to delete the files in the shared folder. Configured smb.conf For completeness, I’ve presented my whole smb.conf configuration file below, where I’ve deleted all the comments and empty lines to make it easier to read. |global| workgroup = WORKGROUP server string = Samba security = share load printers = no guest account = nobody log file = /var/log/samba/log.%m max log size = 50 interfaces = br0 dns proxy = no |shared| comment = Shared Folder path = /home/user/shared browseable = yes guest ok = yes guest only = yes writable = yes force user = nobody force group = shared create mask = 0770 Conclusion In this article we’ve looked at how we can setup a shared folder and use it in Qemu. Basically it has little to do with Qemu; the only thing we need to worry about is the “interfaces” option in smb.conf. In my case it’s set to br0, which instructs Samba to bind on bridge br0 interface where my virtual machines are located. Once more thing to note. On newer versions of Samba, the share security mode is deprecated, which is why you should use the following two options instead: “security = user” and “map to guest = Bad User”; other than that you don’t have to change any of the settings in the smb.conf configuration file. Source

If you’re used WinDbg before, you might already know that you can debug the whole Windows operating system with it. To do that, you must have two Windows operating systems, where the first one is the one we’ll be debugging and the second is where we’ll be debugging from. The very first thing that we need to do is install WinDbg on both operating systems. Usually I download the complete Windows Driver Kit from Download Windows Driver Kit Version 7.1.0 from Official Microsoft Download Center as can be seen on the picture below. After downloading and installing WDK, the WinDbg will be located in the C:WinDDK folder as seen on the picture below. At this point we can start windbg.exe and pin it to the taskbar, so we can easily start/stop it. This must be done on the host virtual machine, where we’ll be debugging from. On the guest virtual machine, we have to change the boot.ini to change the boot options, which are needed if we would like to debug the operating system. We have to run the following commands in the cmd.exe, which has to be started as Administrator to give us enough permissions. > bcdedit /set debug on > bcdedit /set debugtype serial > bcdedit /set debugport 1 > bcdedit /set baudrate 115200 > bcdedit /set {bootmgr} displaybootmenu yes > bcdedit /timeout 10 After restarting Windows, the boot menu when starting Windows will look like this; notice the added “[debugger enabled]” string, which indicates that we’ll start Windows under the previously entered debugging commands. Qemu, Character Devices and Serial Ports A character device on Linux is a special file though which we can send data to devices one character at a time, and is often used for streaming the data communication between the operating system and the hardware device. In Qemu we can create a character device by using the -chardev option, which accepts a number of backends described below. Note that each character device must have an id, which uniquely identifies the device. The options below are summarized after [1]. Backend Description null A device that drops any data it receives and doesn’t send any data. socket Creates a TCP or Unix socket, which we can use for bidirectional communication. udp Creates a UDP socket, which we can use to send traffic over. msmouse Qemu’s emulated msmouse events are forwarded to the guest. vc Is used to connect to the qemu text console. file Creates a character device, which writes all the received data from a guest to a file. pipe Creates a pipe, which we can use for bidirectional communication with the guest. console Sends traffic from guest to qemu’s standard output and is only available on Windows hosts. serial Creates a serial device to which the guest can send data. pty Creates a new pseudo terminal on the host. stdio Connects to stdin/stdout of the qemu process. braille Connects to local BrlAPI server. tty Connects to local tty device. parport Connects to local parallel port. spicevmc Connect to the spice virtual machine channel. We can achieve what we want by creating a serial port with qemu, which can be done by using a “-serial dev” option with qemu, where the dev specifies the character device, which can be one of the devices listed in the table below [1]. Option Description -serial vc[:WxH] Virtual console with optional width and height parameter. -serial pty A new pseudo TTY will be allocated. -serial none No device is allocated. -serial null A void device. -serial file:filename A new file is created, where the output is written. -serial stdio Standard input/output. -serial pipe:filename A new file is created acting as a pipe. -serial unix:path A unix socket is used. Remember that we can use either -chardev, which also needs the accompanying -device isa-serial part, or -serial, which provides both the frontend (host) and the backend (guest) part of the connection. The -serial is therefore there only for convenience, so we don’t have to use two parameters, but only one. Those options apply when we would like to run both VMs on the same host computer, but remember that we can also run the two VMs on different host computers, but at that time we must use sockets to exchange WinDbg messages. Kernel Debugging on the Same Host Let’s first take a look at how we can debug the Windows kernel when both VMs are running on the same host. There are two ways that we can enable kernel debugging. The first is by using the -chardev/-device options, while the shortcut is by using the -serial option. On the first virtual machine we can use one of the following two options to enable the server side of the communication: the debugger. -chardev socket,id=serial0,path=/tmp/debugpipe,server,nowait -device isa-serial,chardev=serial0,id=serial0 or -serial tcp::9090,server,nowait In the second VM, we must enable the appropriate options based on the options set in the first VM. We also have two options that are very similar to what we’ve used with the first VM, but are slightly different. On the second virtual machine we can use one of the following two options to enable the client side of the communication: the debuggee. -chardev socket,id=serial0,path=/tmp/debugpipe -device isa-serial,chardev=serial0,id=serial0 or -serial tcp:127.0.0.1:9090 To start kernel debugging, we need to press the File – Kernel Debug in Windbg (in the first VM of course), and set the baudrate/port (the defaults are fine in our case). After pressing OK, the WinDbg will be waiting for the debuggee to connect. To make that happen, we need to start the second VM, which will connect to the serial port and our WinDbg (in first VM) will be able to catch it. When that happens, we can break the execution of the Windows operating system, which will enable us to enter commands at the “kd>” prompt. At that point we won’t be able to use the debugged Windows VM, because the execution of it is stopped. To run the debuggee again and let us interact with it, we must run it with the “g” command. Kernel Debugging on Different Hosts When we would like to run the two Windows machines on different host computers, we can easily do so by using the serial console based on TCP. This can be done by using the “-serial tcp” command-line option of the Qemu. The first host virtual machine must create the listening port by using the option below: -serial tcp::9090,server,nowait This will start listening on port 9090, which we can verify with the netstat command as seen below. # netstat -luntp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:9090 0.0.0.0:* LISTEN 32745/qemu-system-x The guest virtual machine must then connect to that port with the following command-line option. In this case, we’ll be connecting to the socket on the same computer, which is why we’ll use the 127.0.0.1 IP address, but if you’re on a different computer you just have to change the IP address. -serial tcp:127.0.0.1:9090 At first we must start host virtual machine, which will create the listening socket. After logging into the Windows operating system, we need to start WinDbg and go to File – Kernel Debug, where we can edit the options of debugging over the COM port. On the picture below, we can see the default options, which are already correctly set and correspond with our previously entered bcdedit commands entered in Windows Guest virtual machine. At that point, we must merely press the OK button, which will open the COM1 port and will wait for the Windows Guest virtual machine to connect. This can be seen on the picture below. After that we must start the Windows Guest virtual machine, which will by default try to connect to the COM1 serial port, because we edited the only booting option with bcdedit. Once the Guest virtual machine connects to the serial port, the following will be seen in the WinDbg started in the host virtual machine. Notice that the Windows operating system is connected to WinDbg and stopped, and it’s our job to enter the g command to run the operating system, at which point the booting process will be able to continue. On the picture above we can notice that the symbol file was not found. Whenever using WinDbg for debugging I always set the _NT_SYMBOL_PATH environment variable to the “srv*C:symbols*http://msdl.microsoft.com/download/symbols” value as seen below. After applying the changes, the WinDbg will automatically pick up the changes and download the symbols from Microsoft symbol store and cache them in C:symbols directory. Conclusion In this article we presented how we can debug the Windows kernel under Qemu by using two virtual machines. First we installed the debugging tools in first virtual machine and enabled the debugging options in boot.ini in the second virtual machine. From there on, we only need to set the right parameters to the qemu-kvm command. We’ve looked at the -chardev/-device and -serial parameters that can be used when kernel debugging with WinDbg. I recommend using the -serial parameter, which enables us to communicate over the socket, which is useful when we would like to run the debugger and debuggee machines on different hosts. By using this option, we can merely change the IP address and everything works as before. References: [1] Qemu man page, qemu-kvm(1): QEMU Emulator User Documentation - Linux man page. [2]Qemu, Windows guest debugging, WindowsGuestDrivers/GuestDebugging - KVM. Source

@uncosmar11 in primul rand baietii rad de tine. In al doilea rand nu iti permite tu sa te iei de kent. In al treilea rand nu ii da pm lu aelius cu asemena prosti ca vei lua ban. Cand ai postat aici aveai 8 posturi ( e precizat clar ca ai nevoie de 10 posturi de calitate, tu ai facut doar spam. Suntem in 2014 fratilor nu mai veniti aici cu arhive ,,root" si alte deastea...

@io.kent esti fenomenal bre, sa traiesti! e site de genul pentru care sa nu ai config maestre? ti-as da REP pana maine

@io.kent multam bre, esti cel mai tare uitati aici user ce munceste cu adevarat, tot ce prinde/are baga share.

@FKU. daca tot te intereseaza SQLi uite aici https://rstforums.com/forum/93309-sql-injection-cheat-sheet.rst On:// Bun venit la noi.

Traffic light systems security issues We often see movie scenes in which hackers are able to hack systems for the control of traffic lights, with catastrophic consequences, unfortunately we must be conscious that threat actors are really able these complex infrestructures causing serious problems. Traf?c lights were originally designed as standalone systems, but they evolved with technological progresses into more complex, networked systems. Modern traf?c controllers are able to execute multiple timing plans, communicate in real time with a huge quantity networked sensors and elaborate the collected information to manage traffic flows in the most efficient way Coordinated traf?c signal systems provide great benefits in term of wasted time, environmental impact and public safety, but for their interconnection, public administration have to spend a great effort to ensure an efficient interconnection on a metropolitan geographic distribution. Wireless networking represented the optimal choice to reduce the interconnection cost and quickly implement an interconnected network of traffic light control systems. However, these improvements have raised serious questions in term of security of the overall architectures, the components of traffic light systems are today remotely accessible and wireless interconnected, with serious repercussions in term of security. Cesar Cerrudo … hacking traffic lights and electronic signs worldwide Cesar Cerrudo, chief technology officer at IOActive, is one of the cyber experts that has conducted a study to investigate on the security level of components within control systems for traffic lights and electronic signs in different cities around the world. Cesar Cerrudo analyzed the architecture of traffic light systems installed in many countries, including the United States, the U.K., Australia, China, and Canada. Figure 1 – Sensys Video presentation The researcher discovered a worrying scenario, several devices in traffic light systems are vulnerable to a range of cyber attacks, vulnerabilities in these architectures could be exploited to cause a Denial of Service or to spread a malware within a network connecting with these systems. Electronic signs and traffic light systems are controlled by automated systems that could be targeted by threat actors exacly as any other device. Cerrudo has presented the results of his research at the Infiltrate Security conference, illustrating the details on the security flaws discovered and the components affected by such vulnerabilities, which could be exploited by an attacker using the right equipment at a suitable distance. https://www.youtube.com/watch?feature=player_embedded&v=RviQ3YQTxMo/ Figure 2 – Video Intro Cesar Cerrudo “The vulnerabilities I found allow anyone to take complete control of the devices and send fake data to traffic control systems. Basically anyone could cause a traffic mess by launching an attack with a simple exploit programmed on cheap hardware ($100 or less),” explained Cerrudo in a blog post. Cerrudo also imagined a possible attack vector for the attacks against traffic light systems, bad actors could use a commercially available unmanned vehicle to hack the vulnerable devices. The research demonstrated that equipping a drone with a powerful antenna it is possible to interfere with traffic light systems from more than 600 feet in the air, it’s clear that the range could be extended to a mile with a stronger antenna. The hacker explained that a bad actor could be able to conduct the attack using a wireless transmitter of variable size, with a USB stick receiver attacker could intercept data from 150 feet away, a distance that could be easily extended to 1,500 feet using a greater antenna. “I even tested the attack launched from a drone flying at over 650 feet, and it worked! Theoretically, an attack could be launched from up to 1 or 2 miles away with a better drone and hardware equipment, I just used a common, commercially available drone and cheap hardware. Since it seems flying a drone in the US is not illegal and anyone will be able to get drones on demand soon, I would be worried about attacks from the sky in the US.” To better understand the possible impact of a cyber attack against a traffic light system, let’s consider the statistics proposed in the post: Security of vital infrastructure is a critical goal for every cyber strategy, governments must seriously consider the possible risks related to cyber attacks and traffic light systems are considered a privileged target. Cerrudo started its analysis evaluating the architectures of traffic light systems and discovered that in 40 US cities, including San Francisco, Los Angeles, New York City, Washington DC and also in other nine countries were installed vulnerable controllers Sensys Networks wireless vehicle detection systems. Figure 3 – Sensyn Architecture (Slide) The company installed its systems in 40 states and its network counts more than 50,000 sensors operating in 10 countries, including the United Kingdom, China, Canada, Australia, and France. Vehicle detection systems are composed of magnetic sensors hidden in the roadways that collect information about the traffic flow and wirelessly transmit it, through the proprietary protocol Sensys NanoPower Protocol, to nearby access points and repeaters, which then sent the data to traffic signal controllers. Figure 4 – Sensys sensor A threat actor could hit the system described, and in particular the information exchanged, because the protocol used lack of authentication mechanisms and data sent aren’t encrypted. Theoretically, an attacker could sniff the traffic, reverse engineer the protocol and replace information with fake data. Anyway, sensors are just a component of the overall architecture, it it necessary to submit the information in the correct way to trick control traffic light systems into thinking that the actual traffic flow is different from the real one. Cesar Cerrudo made his tests in principal US cities, including Seattle, New York, and Washington and DC, and the situation was always the same. Another security issue noticed by the researcher Cesar Cerrudo is related to the possibility to alter the firmware running on the sensors. The code is not not digitally signed and is not protected by any security mechanism, this circumstance led the experts to think that a threat actor could access the firmware and modify it to alter the configuration and the behavior of the devices. An attacker for example, could hack the sensor in order to provide fake data or just to transmit data on a different radio channel. In both cases, as highlighted by Cerrudo, it would be very hard to detect a potential attack and identify the compromised sensor. The attacks explained by Cesar Cerrudo could cause serious problems to the tragic flaw, an attacker could manipulate the transition times of traffic lights creating traffic jams and other problems, and such attacks are quite impossible to discover in a short time. The hacking tools The Researcher Cesar Cerrudo explained that is not necessary an expensive instrumentation to hack control traffic light systems, he explained that an attacker could use a small specialized equipment to do it. To build a lab for his tests the researchers purchased an access point from Sensys Networks at a cost of about $4,000. Of course, such kind of access points isn’t available to the public and the researchers have obtained it for testing purposes by telling the vendor he was evaluating it for one of his clients. The access point acquired by the researcher is compatible with all the sensors used by the Sensys to monitor the streets worldwide. The access point intercepts data sent by sensors, for this reason he placed it in a backpack or on his car dashboard during the experiments conducted in the streets of different cities, including Seattle, New York, and Washington, DC. Figure 5 – Sensyn Access Point Anyway, an attacker could intercept data anyway without the Sensys access point, he could simply intercept exchanged data using a wireless transceiver, but this process is more complex without the knowledge of the proprietary protocol used. A threat actor having the knowledge of the protocol could capture the data sent by the sensors to the access points, which includes configuration information about the devices such as the unique ID of the sensors. As explained by the researcher, a sensible improvement of the overall security of networks of traffic light systems could be obtained by encrypting the communications between sensors and the access points. As described in the study, an attacker could also intentionally modify the firmware of the sensors or their configuration data, for this reason another suggestion provided by Cerrudo is to prevent unauthorized users from accessing the firmware. Cerrudo reported the security flaw to ICS-CERT division in July and according to the researcher, he was told that lack of encryption for communication was not a flaw but a design choice requested by Municipal entities to the company Sensys Networks. Sensys also added that firmware updates for the sensors are now encrypted with AES, the measure has been implemented to avoid reverse engineering of the their source code and discover which flaw they fix, an information that could help attacker to build specific exploits. Cerrudo anyway observed that firmware updates are only encrypted for new versions of the sensors, devices already deployed in the streets are not able to update firmware with encrypted updates. This means that old version of sensors have to be disinterred from roadways and replaced with new ones that support encrypted updates. According to Cesar Cerrudo, the position of ICS-CERT on the flaw reported is disconcerting, the CERT in fact accepted the declaration of Sensys Networks company that doesn’t consider the security issues as flaws because the systems weren’t accessible via the internet. The justifications, Cerrudo says, “are mostly nonsense. It’s like the guys at ICS-CERT don’t understand and buy what the vendor says. But I clearly told CERT that there is no encryption and no authentication and that anyone can take over the sensors. Privacy issue Networks of traffic light systems aren’t used only to regulate traffic flow, the sensors can be also used to count vehicles in a specific area of the city or to track the movement of vehicles by detecting the same vehicle with different sensors located in different positions in a metropolitan area. This data could allow bad actors or governments to track specific vehicles violating the users’ privacy. According to the information disclosed by the Sensys company it has deployed more than 1,300 wireless sensors in Washington, DC to collect data on traffic speed, vehicle count, and occupancy to “optimize real-time congestion management and emergency response. But the city is the place where lives the President of the US, for this reason it is to speculate that such systems could be improved to be integrated in a surveillance system which includes also data from cameras located in the city and any other information from different sources related to the local population. For this reason, I think we must be aware that such system could represent a serious threat for privacy and security in case of cyber attacks. An academic point of view Hacking Traffic light systems is an argument even more discussed by security experts that is becoming very popular also within common people thanks to the movie industry. A study conducted by security researchers at the University of Michigan, led by computer scientist J. Alex Halderman, has refuted the findings from cesar Cerrudo. According the ream of researchers it is very easy to hack traffic light systems. The team of experts explained how bad actors without any particular knowledge could hit traffic light networks, also in this case it is sufficient a laptop and a specific radio system. Figure 6 – Traffic interception scheme As shown in the above image a modern traffic interception is composed of the following components: Sensors to detect cars and inspect the infrastructure. Controllers to receive data from sensors and control light states, according different politics, for example, in a totaly automated fashion based on information provided real time by sensors. Communication channels, which could be hard-wired through optical or electric means or wireless. Malfuction Management Unit, which manages potential conflicts through hardware-level safety Mechanisms, practically it ensures that lights are always in a valid state. The researchers published a paper which describes the experiments conducted, the techniques implemented to exploit security vulnerabilities in traffic light systems and the indings. In particular, in a live test the experts very easily and very quickly gained the control of the system of at least 100 traffic signals, in an unnamed city in the Michigan, from a single point of access, a local road agency. The experts identified three major weaknesses in the national traffic systems, which potentially allow anyone to hack the traffic light networks: Unencrypted radio signals. Devices on the network lack secure authentication. The traf?c controller is vulnerable to known exploits. As explained by the experts the use of wireless radio transmissions (a combination of 5.8GHz and 900MHz radio signals) is very common for traffic light systems, this choice allows to reduce the costs of installation and maintenance of the networks. The 900MHz links used in the traffic light systems implement “a proprietary protocol with frequency hopping spread-spectrum (FHSS),” but the 5.8GHz version of the proprietary protocol is similar to 802.11n. Anyone with a laptop and a radio system operating on the same frequency as the networked traffic light (5.8 GHz) could access the network because the communication isn’t encrypted. The researchers demonstrated to be able to infiltrate the networks of control traffic light systems, once gained the access they were able to communicate with controllers that run VxWorks 5.5 version. This version unfortunately by default has a debug port using for for testing, and researchers exploited it. Once again, an unprotected communication allowed the researchers to reverse engineer the protocol used in the communication, once controlled the debug port the experts were able to send commands to control lights or alter the timing of neighboring intersections. The researchers also demonstrated that a bad actor, once infiltrated the network, could perform a wide range of attacks, including: Denial-of-service (DoS) attack on controlled intersections that could cause a traffic jam. As explained by the researchers the attackers could set the all lights to red or trigger the MMU to take over by attempting an unsafe configuration, this last case is serious because need a physical intervention of personnel to restore a normal situation. Traf?c Congestion manipulating timings of an intersection relative to its neighbors with repercussion for the entire traffic infrastructure. Such attacks have a significant financial impact on the community targeted as demonsstrated by numerous studies. Light control for personal gain, as explained by researchers “lights could be changed to red in coordination with another attack in order to cause traf?c congestion and slow emergency vehicle response.” Conclusions The studies presented in this post demonstrate that traf?c control systems are vulnerable to cyber attacks, fortunately improving security of the components of a traffic light control system and of the internal connection is possible to prevent major incidents. We have seen that an attacker can run a denial of service attack or cause a traffic jam as diversive measure in a more sophisticated attack. As remarked by all the actors involved in such interesting studies, the principal problem is the lack of security awareness of the cyber threat, the experts highlighted that traf?c controller vendors haven’t managed properly the vulnerability disclosure by the security community. The companies just ensure the compliance to actual industry standards, which don’t consider properly the security issues. Next generation of control traffic systems must be built with security by design, and fortunatelly governments are understanding the critic of such environments and the risks of major attacks. The researchers suggest manufacturers and operators to improve the security of traffic light systems adopting encrypted communications between components of the infrastructure, digitally signing the firmware running on each component to avoid software modifications, and not using default credentials. Let me close with a reflection, Traffic Light systems are just a sample of the larger family of IoT (Internet of Things), many other devices we daily use have similar vulnerabilities threat actors are increasing targeted them. References Hacking traffic light systems, it's so easy | Security Affairs Hacking Traffic lights and other control systems is not so hard | Security Affairs IOActive Labs Research: Hacking US (and UK, Australia, France, etc.) Traffic Control Systems Hackers Can Mess With Traffic Lights to Jam Roads and Reroute Cars | WIRED https://jhalderm.com/pub/papers/traffic-woot14.pdf IOActive Labs Research: Hacking US (and UK, Australia, France, etc.) Traffic Control Systems Sensor | Sensys Networks Source

Here’s our large collection of SQL Injection related resources. This list has something for everyone, from those just starting out to the most senior ethical hackers. What is an SQL Injection? An Introduction SQL Injection Demo Cookie Based SQL Injection SQL Injection through HTTP Headers SQL Injection with SQLmap Blind SQL Injection: Attack Anatomy Dumping a Database using SQL Injection Testing for SQL Injection with sqlmap Fuzzing for SQL Injection w/ Burp Suite Intruder SQL Truncation Attack Parameterized SQL Query over Dynamic SQL Query Gaining Reverse Shell from SQL Injection SQL Injection through SQLMap Burp Plugin Creating Backdoors Using SQL Injection SQLi Labs Tutorial SQLNuke: MySQL Injection load_file() Fuzzer Double Query Injections Demystified Advanced SQLMap Tutorial Source

Just found an interesting vulnerable machine named Troll. It sounds like the machine will troll the attacker. We booted up the machine in Virtual Box and fired an Nmap scan on it. The scan result: was of three ports FTP, SSH, and HTTP. We did a script-based Nmap scan by using -A argument, so we had some more details of those open ports. As can be seen below, in port no. 21, FTP is allowed to login as Anonymous user and it also contains a lol.pcap file in it, and port no. 80 HTTP service has a secret directory. So we started from the HTTP service. We opened up the target address in the browser and what did we see? A troll image. Ok… cool! So let’s open the secret folder, maybe we found something interesting in this directory. What? Another troll. So there is nothing juicy in the application, so we moved in to the FTP service as we knew Anonymous login is allowed and there is a lol.pcap file available, so let’s grab that file. We used ls command for checking if there are any files or not, and found the lol.pcap file. Used Get command to download the file. Then we opened the capture packet file from Wireshark and started to check all TCP connections by following TCP streams, and we found that a file named secret_stuff.txt has been transferred. File transfer has been done, meaning it was on FTP protocol, so we applied a filter by using ftp-data for filtering all connections. As can be seen below, we found only three connections. In one of the connections, we found a message that “you almost found the sup3rs3cretdirlol”. A directory is what the message denotes. We opened the directory and we found another file over there called roflmao. Just downloaded the roflmao file, let’s see if there is any troll in this file. Executed the bin file and there was “Find address 0x0856BF”. Now where to find it? We opened the address in the browser and that was a directory with two directories: good_luck and this_folder_contains_the _password. We opened the good_luck folder and found a which_one_lol.txt file. The file contains usernames, probably for the SSH. Then we again checked the second directory and that was the obvious one, pass.txt. We opened the password file and found the password Good_job_ Now what to do? We have usernames and a password, it is quite easy to brute force. We fired up the Hydra brute forcer. As can be seen below, we put that username list in user.txt file and put the password as Good_job_ We started the attack and we weren’t able to log in with this password. We tried to figure out what is wrong with the credentials. After some time, we noticed that the folder that contains the Pass.txt name was the folder that contains the password, so what if we use the password as Pass.txt. Again we configured the Hydra, this time the password is Pass.txt. We started the attack and Boom! Logged in. Found the username was overflow and password was Pass.txt. Successfully logged in via SSH. Our next step was to find all worldwritables files in the system, so we used find / -perm -2 -type f 2>/dev/null Found lots of files, but one file was unexpected: a Python file with writeable permissions. The file was located at /lib/log/cleaner.py. Opened the cleaner.py file: Now we just changed the function and added our own functions by adding these two lines: os.system(‘cp /bin/sh /tmp/sh’) os.system(‘chmod 4777 /tmp/sh’) In the first function, we copied bin/sh to tmp/sh and in the second function, we provided the executable permissions. After saving the Python file, we exited the SSH session and re-logged in to the system and changed the directory to /tmp/sh and executed the whoami command for identifying the user, and it was root. Now we are in the root directory, we opened the proof.txt and it’s done. Trolling over! References: http://vulnhub.com/entry/tr0ll-1,100/ Source

You don’t necessarily need to be an android to properly secure your Android device. With a few tips and adhering to a regime of think before you click, we can hopefully demystify some of the otherwise inscrutable security features inherent to the Android platform. As recent reports of rampant malware and Trojans began to surface via media outlets, the average Android user might not know where to turn to address their security concerns. And with market share on the rise, Android is swiftly becoming more attractive to data miners and thieves alike. Thankfully for us, the Android operating system is open source, which means there are no constraints on security. You can make your device as accessible or as airtight as you see fit. Here are some tips you can use to exercise your device’s functionality, spread awareness among other users and — most important of all — increase security: 1.) I shouldn’t have to type this out, but you would be surprised how many people forget to enable a lock screen. Let us not forget that there are still people out there willing to adopt an older form of thievery. Should you realize your phone is suddenly in the physical possession of a third party, a lock screen is essential in providing your data with a first line of defense. Simply browse to ‘Settings’ > ‘Location & security’ to enable a PIN or pattern style lock screen. While you’re in ‘Settings’, change your ‘Screen Timeout’ under ‘Display’ to ensure that your lock screen comes on after a delay of phone activity. 2.) In the event that your phone is compromised, the last thing you would want to do is hand over your data on a silver platter. Avoid storing a master password to access resources on your phone. Encrypt your passwords, or better yet, do not store them at all. This practice is indispensible for keeping your personal data under your own authority. As you browse the web on your device, be aware that any usernames and passwords entered could be saved locally. Use your browser settings to remove stored passwords and/or disable storing altogether. 3.) Recall that your device can sync with your Google account so in essence, your email, contacts, calendar, and now your apps will be stored on the cloud for easy retrieval. Without your device’s sync feature, it becomes very tedious to populate everything manually. For this reason, there are apps that will take steps further protect your data should the lock screen fail to provide adequate protection. One simple way to do this is with App Protector Pro ($1.99 on the Android Market). You can lock down individual applications such as your Gmail, text messages, and more with simple pattern gestures or passwords. There are free alternatives as well but I cannot vouch for the validity of every app on the market…Which brings me to my next point… 4.) Before you go installing any app you run across be sure to read the applications access request for permissions agreement. This often overlooked agreement contains valuable information regarding specific permissions on how the app is to access your device. These permission requests, such as access to GPS, contacts, external storage, etc; are all coded directly into the Android manifest file. Be mindful of what your application purports to do and what it is that it actually does. Chances are a calculator application does not need access to the Internet or your personal information, so read those permission agreements. 5.) Those of us without the greatest carrier coverage sometimes rely on Wi-Fi to do most of our heavy internet browsing. This helps keep data usage down and generally speeds up communications. However, remember that the same rules for standard computers still apply to Android on those free Wi-Fi hotspots. The information your device sends across a Wi-Fi network is not anonymous, so avoid any online banking or financial tracking until you have carrier coverage or access to a more trusted network. 6.) Stay anonymous and, thusly, more secure by turning off your geo-location features. Navigate to ‘Settings’ > ‘Location & security’ to disable the use of GPS satellite location and wireless network location. The wireless network location feature will also make you less traceable to authorities in an emergency situation so choose your battles wisely. Since there is a thin line between security and anonymity, I will not elaborate on the benefits and pitfalls of being anonymous (perhaps in a future article). Although, anyone interested in securing their personal data, whether it be their location on Foursquare or tagged photo on Facebook, every measure counts. 7.) Keep all of your applications and operating system up to date. Your device will periodically remind you of updates ready to be installed from the Android market or OTA via your service carrier. Keeping up to date is crucial for security as there are many exploits and methods for gaining access to restricted data discovered every day. If you find a glitch or unintended use of an application, let the developer know! As a developer myself, feedback is critical – we love getting feedback, both constructive and otherwise. Go back to the Android market to find developer contact information and send them an email. Getting apps patched or updated is vital to the growth and success of Android as a whole. 8.) Take proactive steps to ensure your data is safe in the event of a physical theft of your device. While there is no operating system level security for your SD card built into Android, such as the encryption Blackberry users enjoy – there are still a few ways we can prevent external threats from accessing our data. Where’s my Droid (free and donation version available on the Android market) is a great app I would recommend to everyone. It can help locate your phone in the event of a loss or theft by making it ring or tracking its geo-location on a computer. Where’s my Droid also provides built in protection via a PIN to gain access to the app itself. The ‘attention word,’ specified by the user, activates specified instructions aiding in the recovery of a lost or stolen device. Even if recovery is impossible, it is far better to have your identity intact. 9.) Common practices and preemptive safety precautions aside, no method is perfect. This is why it is so very important to backup your data. Take the time to create regular backups of your applications and settings. Syncing your phone with Google is one thing, but backing up your pictures, texts, videos, and other important files is another. I cannot stress enough how important it is to have redundancy in storing data. Try out: Titanium Backup (requires root access, “Pro” pay and free version available) MyBackup Pro ($4.99) Lookout Mobile Security (Free) Of course there are hideous amounts of applications out there that will do all of the above and more, though referring again to step No. 4, be sure to know what you are installing onto your phone before giving up access. 10.) Finally, as far as security goes for your Android device, use common sense! Do not install apps hastily without reading the permissions agreement or customer reviews. Use caution when browsing to sites via randomly found QR codes. Do not store your passwords in a file on your device or in an email linked to your device. Try not to reuse your passwords for added security in the event of a data breach. Do not give our or share personal information to those you do not expressly trust. These are simple precautions that work for more than just Android devices, that should go without saying. With new ways to access personal information via pioneering technology such as Near Field Communication [NFC] in Google’s Nexus S, one cannot afford to overlook even the most rudimentary security measures. Whether your Android device is your social media muse or your dependable business buddy, the above steps should prove useful in reducing the risk of accidental data loss. Be sure to leave your feedback. (all feedback welcome!) Source

Wireless local-area networks which are also referred to as WLANs or Wi-Fi are prevalent these days. They are so popular that they can be found installed in offices, colleges, hotels, cafes, and even homes. There are many Wi-Fi product vendors and service providers, providing different products with different services and features. The main reason behind them being so popular is the convenience, mobility and ease of implementation they provide compared to the wired network. The end user can easily access the network without the hassle of managing the wires. Wireless networks are basically based on the Institute of Electrical and Electronics Engineers (IEEE) 802.11 set of standards for WLANs. Following is the list of the IEEE 802.11 network protocol standards. Protocols 802.11 network standards are shown in Figure 1. Figure 1. 802.11 Network Standards (source: Wikipedia) Some years back, wireless networks were only a niche technology used for very specific applications. But nowadays they are everywhere and every now and then we find a new Wi-Fi access point through our smart phones, tablets or laptops – most of which are not even secure. Most of us have used these access points at some point in time to access the Internet without realizing how much (In)security they provide. An insecure Wi-Fi network poses a threat not only to the owner but to every user that accesses it. The first line of defense for a Wi-Fi network is encryption, which encrypts the data transmitted between the Wi-Fi enabled device (smart phone, tablet, laptop etc.) and the wireless router. The Wireless Protected Access (WPA) protocol and more recent WPA2 have replaced the older and less-secure practice of Wireless Encryption Protocol (WEP). It is better to go with WPA2 as WEP is relatively easy to crack. Wi-Fi Protected Access (WPA) and Wi-Fi Protected Access 2 (WPA2) are two security protocols and security certification programs developed by the Wi-Fi Alliance to secure wireless computer networks by providing encryption mechanisms. But common users know little about wireless security and are scared by the available options to set up these methods. Because of this unawareness and implementation issues with these protocols, in 2007 Wi-Fi Alliance came up with Wi-Fi Protected Setup (WPS) which allowed home users to easily add new devices to an already existing Wi-Fi network without entering long passphrases. Wi-Fi Protected Setup (WPS), originally known as Wi-Fi Simple Config, is a computing standard that attempts to allow easy establishment of a secure wireless home network. Almost all major Wi-Fi product vendors (Cisco/Linksys, Netgear, D-Link, Belkin, Buffalo, Technicolor, etc.) have WPS-certified devices. WPS is activated by default on almost all the WPS supporting devices. The main purpose of the standard is on providing usability along with security. Usage Methods WPS provides four usage modes for adding a new device to an existing network, which are explained below. But first some terminology that will used in the explanation: Terminology: Enrollee: A new device that needs to be added to the network and does not have settings for the wireless network. Registrar: One which provides wireless settings to the enrollee. Access Point (AP): One which provides normal wireless network hosting and acts as middleware to pass messages between the enrollee and the registrar. The four modes provided by WPS can be classified into two groups: In-band and Out-of-band. This classification is made based upon the channel utilized for the information transfer. In-Band modes: Currently only these two modes are covered by WPS certification. Push-Button-Connect (PBC): The user merely has to push a button, either an actual or virtual one, on both the Access Point (or a registrar of the network) and the new wireless client device (enrollee). Support of this mode is mandatory for Access Points but optional for connecting devices. Figure 2 shows a Windows 7 machine as an enrollee. PBC on the AP will only be active until authentication has succeeded or timed-out after two minutes (or whatever amount of time the vendor has specified). This option is called wps_pbc in wpa_cli (text-based frontend) which interacts with wpa_supplicant; wpa_supplicant is a WPA Supplicant for Linux, BSD, Mac OS X, and Windows with support for WPA and WPA2. Figure 2. Activated virtual push button (Windows 7: Enrollee) Source: http://sviehb.files.wordpress.com/2011/12/viehboeck_wps.pdf PIN Mode: In this method a Personal Identification Number (PIN) has to be read from either a label or the display unit on the new wireless device. Figure 3 shows a WPS PIN on the label of a D-Link router. This PIN must then be inputted at the representant of the network (usually AP). Alternately, a PIN on the Access Point may be entered into the new device. This can also be explained on the basis of registrar, as following. Internal Registrar The user enters the PIN of the Wi-Fi adapter into the web interface of the AP. This option is called wps_pin in wpa_cli. External Registrar The user enters the PIN of the AP into a form on the client device (e.g. computer). This option is called wps_reg in wpa_cli. The PIN Method is a mandatory standard method; every Wi-Fi Protected Setup (WPS) certified product needs to support it. Figure 3.WPS PIN on D-Link router Source: http://sviehb.files.wordpress.com/2011/12/viehboeck_wps.pdf Out-of-Band modes: These two modes are not covered by WPS certification. Near-Field-Communication (NFC) method: In this method the user merely has to bring the new client adjacent to the Access Point to permit a near field communication among the two devices. The NFC method offers strong defense against adding an unintended device to the network. Support of this mode is optional and is not widely deployed. USB method: In this method the user uses a USB drive to transfer data between the new client device and the Access Point of the network. Support of this mode is optional, but denounced. Protocol Wi-Fi Protected Setup doesn’t enhance security features to devices. It simply makes the existing security features easy to enable and configure. One of the key elements of the WPS protocols is Extensible Authentication Protocol (EAP). EAP is an authentication framework often used in wireless networks and Point-to-Point connections. It provides for the transport and usage of keying material and parameters generated by EAP methods. The WPS protocol consists as a sequence of EAP message exchanges that are initiated by a user action and relies on an exchange of descriptive information that should precede that user’s action. This descriptive information is transmitted through a new Information Element (i.e., an information component which when combined with other information provides the required information product) that is added to the beacon (periodically send management frame by AP), probe response and optionally to the probe request and association request/response messages. IEs will hold the possible and the currently installed, configuration methods of the device other than purely informative type-length-values (TLV). A human trigger is required to initiate the actual session of the protocol after the identification of the device’s capabilities on both the ends. The session consists of 8 messages followed by a message to indicate the protocol is completed (in case of a successful session). The exact stream of messages may change when configuring various kinds of devices (AP or STA). Until very recently this protocol was used to provide the users with a feature of easy implementation of security on their Wi-Fi networks, but a recently discovered flaw has again put the wireless networks, and hence the users, at risk. Security Issue In December 2011 a freelance information security researcher Stefan Viehböck reported a design and implementation flaw in WPS that makes it vulnerable to a very basic hacking technique: brute-force attacks, feasible to perform against WPS-enabled Wireless networks. It can be simply understood as an attacker trying thousands of combinations in rapid sequence until he/she happens on the correct 8-digit PIN that allows authentication to the device. A successful attack on WPS allows unauthorized user to gain access to the network. The research paper of Viehböck can be found at http://sviehb.files.wordpress.com/2011/12/viehboeck_wps.pdf. This vulnerability was also independently uncovered by Craig Heffner of Tactical Network Solutions, and involves how the router responds when incorrect PINs are inputted. When a PIN is entered, the router implementing WPS indicates whether the first or second halves of the PIN are correct or not. The vulnerability revolves around the acknowledgement messages transmitted between the registrar and enrollee during the validation process of a PIN. The PIN, which is printed on the side label of each WPS-enabled Wi-Fi router, is an 8 digit number. As the last digit is a checksum of the previous digits, there are seven unknown digits in each PIN, yielding a total of 107 = 10,000,000 possible combinations. The first and second halves of the PIN are separately validated and reported by the registrar when an enrollee tries to gain access through the PIN. Now the maximum number of guesses required for PIN recovery is 11,000 (104=10,000 from the first half + 103=1,000 from the second half). This is a drastic reduction of the orders of degreea from the number of PINs that would have to be tested in the absence of the design flaw (i.e. 107=100,000,000). The result of this flaw is the presence of a practical attack which can be finished within hours. The difficulty of exploiting this flaw is that it is dependent on the implementation of WPS by the vendor, as Wi-Fi router manufacturers could guard against this attacks by slowing down or disabling the WPS feature after some failed PIN validation efforts. Two tools have been developed as proof of concept to demonstrate that the attack is practical. Tactical Network Solutions, the Maryland based firm that released the first tool ‘Reaver’, states that they are aware of the vulnerability since early 2011. Tactical Network Solutions decided to release the tool after the vulnerability was made public. It is also selling a commercial version called ‘Reaver Pro’ with some more features. Reaver is hosted on Google Code at reaver-wps - Brute force attack against Wifi Protected Setup - Google Project Hosting. Its authors say that it can recover a router’s plain-text WPA or WPA2 password in 4 to 10 hours, depending on the access point. The second tool is a PoC brute force tool implemented in Python and is a bit faster than Reaver, but supports less wireless adapters, as stated on the author’s website (.braindump - RE and stuff). This tool can be found at http://dl.dropbox.com/u/22108808/wpscrack.zip. Reaver Reaver, developed by Tactical Network Solutions, runs on Linux. It aims the external registrar functionality mandated by the Wi-Fi Protected Setup requirement. It executes a brute force attack against an access point’s Wi-Fi Protected Setup (WPS) pin number. Once the WPS pin is found, an attacker can recover the WPA PSK and alternately reconfigure the AP’s wireless settings which could lead towards an insecure network. Although Reaver does not support reconfiguring the AP, this can be accomplished with wpa_supplicant once the WPS pin is recovered. Reaver requires the libpcap (packet capture and transmission) and libsqlite3 (database) libraries and can be built and installed by running the command: $ ./configure $ make # make install To remove everything installed/created by Reaver, the following command can be used: # make distclean Once installed the tool can simply be started using the command: # ./reaver The ‘–help’ argument can be used to show all the arguments available within the tool. Figure 4 shows the help list of the Reaver. Figure 4. Help list of Reaver (source: http://www.hack4fun.eu/2012/01/reaver-wps-wpscrack/) The only requirement it has is a wireless card capable of raw packet injection. To start the process the wireless card must be put on monitor mode. This can be easily done using the airmon-ng tool from the wireless security testing aircrack-ng tool suite as shown below. 1 # airmon-ng start wlan0 The only essential arguments to Reaver are the interface name and the BSSID of the target AP, an example of which is shown below. 1 # reaver -i mon0 -b 00:01:02:03:04:05 Sometimes Reaver just tries the same pin over and over again. This might be because WPS is not enabled on the AP. Run the walsh tool (included in the Reaver-1.3 release) to scan for WPS-enabled APs and make sure the target AP is listed. For extra information output, the verbose option may be provided using the argument ‘–v’. Providing the verbose option twice (-vv) will increase verbosity and display each pin number as it is attempted as shown in Figure 5. Figure 5. Reaver in action (source: http://www.hack4fun.eu/2012/01/reaver-wps-wpscrack/) To speed up the attack the delay between pin attempts can be disabled by adding ‘–d 0? on the command line (default delay: 1 second). 1 # reaver -i mon0 -b 00:01:02:03:04:05 -vv -d 0 Another option that can speed up an attack is ‘–dh-small’. This option tells Reaver to use small Diffie-Hellman secret numbers in order to shrink the computational load on the target AP. In case the attacker does not want to reveal his/her MAC address, Reaver also supports MAC spoofing with the ‘–mac’ option, but it must be ensured that the MAC address of your wireless card’s physical interface (wlan0) must be changed – not the monitor mode interface (usually mon0) – otherwise the attack won’t work. Reaver keeps on brute forcing the PINs until a successful attempt. It has been stated that some models/vendors/ISPs come pre-configured with a default pin. Some common pins are 12345670, 00005678, 01230000, etc. Reaver attempts known default pins first as a better heuristic. Figure 6 shows a successfully cracked WPS PIN in 32,286 seconds. Figure 6. Successful Recovery (source: http://www.hack4fun.eu/2012/01/reaver-wps-wpscrack/) Due to interference or low signal strength Reaver sometimes can’t associate with the AP. It might also be a driver issue. Below is a list of wireless drivers tested by Reaver: Supported: The following wireless drivers have been tested or reported to work successfully with Reaver: ath9k rtl8187 carl19170 ipw2000 rt2800pci rt73usb Partially Supported: The following wireless drivers have had mixed success, and may or may not work depending on your wireless card: ath5k iwlagn rtl2800usb b43 Not Supported: The following wireless drivers/cards have been tested or reported to not work properly with Reaver: iwl4965 RT3070L Netgear WG111v3 Technically more than one instance of Reaver can be run against an AP, but this approach is flawed as it will only result in a double resource load on AP. Reaver advanced options (using ‘–a’ attribute) can be utilized to speed up the attack. Mitigation End users can disable WPS to prevent an attack, but because of the unawareness most people do not turn it off. Some access points don’t even provide an option to disable WPS. Vendors can mitigate the flaw by introducing sufficiently long lock down periods (after unsuccessful attempts) to make the attack impractical to implement. This will require a new firmware release. Vendors also need to intensively test the protocols before implementing them on their devices, so that such flaws don’t come up in the future. Conclusion Today we are all surrounded by many Wi-Fi networks and have used them at some point in time without realizing the issues of the security. The issues discussed in this article are not the only issues related to wireless security, but a recent and major one affecting the privacy of the end users. As we already know, almost all major router/AP vendors have WPS-certified devices and WPS–PIN (External Registrar) is mandatory for certification, which makes a lot of devices vulnerable to such an attack. Having a sufficiently long lock-down period (vendor mitigation method) is most likely not a requirement for WPS certification for the device. However it should be a requirement in the new specifications. The vendors need to release new firmware to eliminate the issue. The main argument this issue presents before us is that such other flaws might be already present in other devices/protocols and misused by malicious intruders, hence the only safeguard we need to take is awareness among end users. Also the certifying authorities and the vendors need to thoroughly test the devices/protocols before implementation so that security features ultimately don’t lead towards insecurity. Source

@io.kent crypteaza intr-o metoda nu prea cunoscuta conturile +pass si pentru metoda sa iti dea pm. asa este cel mai ok, le ti evidenta daca nu sunt oameni sa le fie rusine. Sau pune pune ghicitori si da indicii.

Nu ai cum sa faci asa, nu e ruleta ruseasca bre... Cine intra primul nu inseamna ca el schimba parola. ex: intri tu primul si dupa tine alti 3 si unu dintre ei schimba pass, va baneaza pe toti 4,5,6 care ati vazut?

Omul are dreptate fratilor, de ce sunteti nemancati? dupa ce ca va ofera ABSOLUT GRATIS niste conturi voi schimbati parolele, doar ca alti membrii sa nu se bucure de acele conturi. De ce atata rautate... Sper ca cei care schimba parolele sa se simta, sa le fie rusine si sa speram ca nu vor mai continua.

Malware authors are trying hard to create malicious software with more innovative ways to infect victims. A new mobile Trojan horse infection has been discovered by security researchers that comes pre-loaded onto low-cost Chinese-made Android smartphones popular in Asia and Africa. The trojan, dubbed DeathRing, is a Chinese Trojan that masquerades as a ringtone app and comes pre-installed onto some cheap Android smartphones most popular in Asian and African countries including Vietnam, Indonesia, India, Nigeria, Taiwan, and China. DeathRing malware app cannot be uninstalled or removed by the end user or by antimalware software because it comes pre-installed in the system directory of the handsets at an unknown point within the supply chain, making the threat even more severe. WHAT DOES DEATHRING DO? Though the malware pretends to be a genuine ringtone app, but actually downloads SMS and WAP content from its command-and-control server to the victim’s handset, which gives it potential to phish user’s sensitive data through fake text messages. "DeathRing might use SMS content to phish victim’s personal information by fake text messages requesting the desired data," the security firm LookOut wrote in a blog post. "It may also use WAP, or browser AFFECTED SMARTPHONE HANDSETS DeathRing malware pre-loaded on a number of entry-level phones sold by third-tier manufacturers to developing countries and according to the security firm, the handsets affected are: Counterfeit Samsung GS4/Note II A variety of TECNO devices Gionee Gpad G1 Gionee GN708W Gionee GN800 Polytron Rocket S2350 Hi-Tech Amaze Tab Karbonn TA-FONE A34/A37 Jiayu G4S – Galaxy S4 clones, Haier H7 a i9502+ Samsung clone by an unspecified manufacturer However, DeathRing is not the first pre-installed mobile malware spotted by the firm. Earlier this year, LookOut discovered another pre-loaded piece of malware called Mouabad on devices sold by retailers in China, India, and the Philippines. Similar to DeathRing, Mouabad is also somewhere pre-loaded in the supply chain and affected predominantly Asian countries. Source

Night of the demons (1988) -> un film horror foarte bun, pot spune clasic. Asmodexia The town that dreaded sundown

@cotnariUK , in primul rand nu e ok sa vi cu astfel de site-uri la show off. in al doilea rand lasa programele. era frumos daca ii dadeai PM omului si il anuntai ca vrei sa cauti vulnerabilitati dupa ce scanai/gaseai vulnerabilitatea il anuntai pe om ca sa rezolve. abia dupa ce a rezolvat omul poti posta, a da inainte sa postezi era ok sa ii ceri acordul.

RevEngX RevEngX is a freely available extension for the Debugging Tools for Windows. It offers several new commands to simplify the work of reverse engineering, code injection, hooking and other types of instrumentation that are useful when analyzing 3rd party software, malware, or developing commercial Windows applications that utilize code injection and hooking. This article will demonstrate how one might produce and test a hook on-the-fly using the debugger alone. In practice, it would be easier to code up hook functions in C++ in a DLL, inject the DLL using !loadlibrary (a RevEngX command), and then set hooks pointing to the injected code using any of a number of methods. The technique presented in this article is designed more for demonstrating the power of the tools being presented, and to introduce the reader to a new world of possibilities. Prerequisites It is expected that the reader is familiar with the basics of the Debugging Tools for Windows package. Windbg.exe will be used in the example, but ntsd.exe and cdb.exe may also be used if preferred. The reader should also be familiar with x86 assembly language and have some understanding of the techniques used to hook APIs on Windows. Obviously a basic understanding of Windows APIs is also necessary. RevEngX is needed as well. It can be downloaded from RevEngX.com - Reverse Engineering Extensions - Andrew L. Sandoval. Obtain the most recent version and install RevEngX.dll in the winext directory for the matching bitness of the debugger. Newer versions of the Debugging Tools for Windows package install both the 32-bit and 64-bit versions of the tools. It is important to match of the RevEngX extension to the right bitness of the debugger, and to use the 32-bit version of windbg.exe for debugging 32-bit applications with RevEngX, and the 64-bit version for 64-bit applications. Many of the RevEngX command are bit-immune, but some are not, and it is always best to match your debugger to the bitness of the application being debugged, unless you are debugging or reversing WOW64 thunks, etc. Note that while the example is using x86 assembly language, it could easily be done with x64 (amd64) assembly as well, given a bit of work rewriting the hook function mnemonics. A Visual Example This example will use a simple Import Address Table (IAT) hook. Such a hook employs no stealth – it is easily detectable using RevEngX or other tools that can locate hooks (such as GMER). A very stealthy hook can also be implemented using RevEngX and the debugger, but this is beyond the scope of this article. In order to make the demonstration very visual as well as simple, we will hook the GDI function responsible for displaying text. Our hook function will reverse the strings being sent to ExtTextOutW before invoking the original function. You can choose any target you would like, but in the example below I will use the 32-bit version of Calculator (calc.exe). The visual result will be hard to miss. Step 1: Launch Calculator (or your preferred target) Step one is simple, launch calc.exe. If you are running on a 64-bit version of Windows, be sure to run the 32-bit version. To do this just run c:/windows/syswow64/calc.exe. It should look … well, very normal: Step 2: Attach the Debugger The second step is to start the debugger and attach it to the target application. There are numerous ways to do this, and it depends upon where your Debugging Tools for Windows are installed. For this example I’m going to assume you know how to start the debugger. Just use F6 and select calc.exe to attach the debugger. (Yes, I know it sounds like a baby-step, and it is, but that’s just in case someone blew off that particular prerequisite.) You should now be able to enter commands into the debugger, with it stopped in the debugger injected thread: Step 3: Load RevEngX Okay, this is a baby step too if you are familiar with debugger extensions, but just in case… Just run: .load RevEngX as shown below. To get a list of the currently supported commands available in RevEngX, enter !help: The list of commands is too long to display in a single screenshot, but you get the idea. There is a lot here and only a few commands will be used in this article. Many of the ones shown are helpers used in breakpoints for analyzing a target process or system (yes, some of them were even meant to be used from a kernel debugger.) Step 4: Setup Memory for our Hook Function To set up the memory for our hook function we could simple use .dvalloc (see the debugger’s help for details). In this example, however, I’m going to use RevEngX’s !callfn function to do the same thing. The difference is that .dvalloc will allocate memory from the debugger using VirtualAllocEx, supplying the handle to the target process. !callfn on the other hand will invoke VirtualAlloc in the target process. Either one will work, but when I originally wrote the commands it was for a lecture in which the target processes were already hooked and the students needed to discover how it was done. To simplify setting this up on 30 machines, the debugging commands were all designed to be copy-pasted into the debugger. !callfn conveniently tracks the return value from the call to VirtualAlloc for us, where we would otherwise have to copy-paste it, or re-type it from the output of .dvalloc. Enter the first command as follows: !callfn @$t0 = kernel32!VirtualAlloc(NULL, 1000, MEM_COMMIT, PAGE_EXECUTE_READWRITE) This will cause RevEngX to build and inject the code needed to call VirtualAlloc with the parameters shown in the target process. It will also invoke the call and store the return value in the pseudo-register $t0. The debugger output should reassure you of this: Step 5: Setup Synthetic Variables Strictly speaking, you can get by without any synthetic variables, but you will see that when we assemble our hook function, having them is much easier! In fact, I’m surprised that I had to add this to my extension. It is such a powerful thing that it should be built-in to the debugger. To declare our variables, run the following commands (you can copy-paste them all at once): !synmod HOOKTEST @$t0 !synsym g_pfnExtTextOutWp2 @$t0 !synsym g_pfnwcsrev g_pfnExtTextOutWp2+4 !synsym g_pfnwcslen g_pfnExtTextOutWp2+8 !synsym g_pfnwcsncpy g_pfnExtTextOutWp2+c !synsym HookExtTextOutW g_pfnExtTextOutWp2+20 By way of explanation, !synmod sets up a synthetic module. That means that the block of memory we allocated, and which is pointed to by $t0 will look like a DLL called HOOKTEST to the debugger. Each !synsym command names a synthetic variable or “symbol” and associates an address with it. The variables created are as follows: g_pfnExtTextOutWp2 This symbol holds the address of the real ExtTextOutW function. It will be invoked by our hook after reversing the input string. g_pfnwcsrev This is a pointer to the _wcsrev function in the CRT which our hook will utilize. g_pfnwcslen This is a pointer to the wcslen function in the CRT g_pfnwcsncpy_ This is a pointer to the wcsncpy function in the CRT HookExtTextOutW This is the address of our Hook Function, called HookExtTextOutW. Step 6: Fill in our “variables” The first 4 synthetic symbols setup in step 5 are all pointers to function pointers. We need them to hold the actual values of the target functions to which they point. Copy-paste or enter the following commands to fill them in: ed g_pfnExtTextOutWp2 GDI32!ExtTextOutW+2 ed g_pfnwcsrev msvcrt!_wcsrev ed g_pfnwcslen msvcrt!wcslen ed g_pfnwcsncpy msvcrt!wcsncpy dds g_pfnExtTextOutWp2 g_pfnwcsncpy This should be fairly self-explanatory. If not, look at the debugger’s help for the ed command. The last command will display the result of what we just did. The output should look like that shown in the screenshot below where the highlight is found: Step 7: Build the Hook Function The hook function is fairly simple. If it were more complex we would want to write it in C or C++ (there are very good reasons to use C++ that you might not realize, such as those outlined in this article: Exceptions In Injected Code - InfoSec Institute). In this example however, we are only going to reverse the input string – and only if it isn’t too long for us to reasonably do so in simple assembly code. For now, just copy-paste the assembly commands below. Be sure to hit enter one final time to get out of “Input>” mode. a HookExtTextOutW push ebp mov ebp, esp sub esp, 1000 push ebx mov ebx, dword ptr [ebp+1C] push esi push edi mov edi, dword ptr [ebp+20] test ebx, ebx je HookExtTextOutW+0x6c test edi, edi je HookExtTextOutW+0x6c mov esi, edi cmp edi, FFFFFFFF jne HookExtTextOutW+0x2e push ebx call dword ptr [g_pfnwcslen] pop ecx mov esi, eax cmp esi, 800 ja HookExtTextOutW+0x6c push esi lea eax, [ebp-1000] push ebx push eax call dword ptr [g_pfnwcsncpy] xor eax, eax mov word ptr [ebp+esi*2-1000], ax lea eax, [ebp-1000] push eax call dword ptr [g_pfnwcsrev] add esp, 10 push dword ptr [ebp+24] lea eax, [ebp-1000] push edi push eax jmp HookExtTextOutW+0x71 push dword ptr [ebp+24] push edi push ebx push dword ptr [ebp+18] push dword ptr [ebp+14] push dword ptr [ebp+10] push dword ptr [ebp+C] push dword ptr [ebp+8] call dword ptr [g_pfnExtTextOutWp2] pop edi pop esi pop ebx leave ret 20 When you are done, you should be back to a prompt that looks like this: Now I will briefly explain the assembly. I’m not going to go into detail – you should see what I’m pointing out right away if you are comfortable with x86 assembly language. Feel free to skip to the next step if you already get it 0:004> uf HookExtTextOutW HOOKTEST!HookExtTextOutW: 02400020 55 push ebp 02400021 8bec mov ebp,esp 02400023 81ec00100000 sub esp,1000h 02400029 53 push ebx 0240002a 8b5d1c mov ebx,dword ptr [ebp+1Ch] 0240002d 56 push esi 0240002e 57 push edi 0240002f 8b7d20 mov edi,dword ptr [ebp+20h] 02400032 85db test ebx,ebx 02400034 7456 je HOOKTEST!HookExtTextOutW+0x6c (0240008c) This first section starts with a normal prologue. The stack is setup to reserve 0×1000 bytes of space. That is so that we have a good sized buffer in which to hold our reversed copy of the input string. You will recall that the prototype for ExtTextOutW is as follows: BOOL ExtTextOut( _In_ HDC hdc, _In_ int X, _In_ int Y, _In_ UINT fuOptions, _In_ const RECT *lprc, _In_ LPCTSTR lpString, _In_ UINT cbCount, _In_ const INT *lpDx ); After our prologue code runs, ebp is used to access the input parameters. This means that [ebp+1Ch] points to the input string. This pointer is copied into ebx. After preserving registers on the stack, edi will hold the cbCount (length) of the string from [ebp+20h]. Finally, the test and je check for a nullptr input string. When the input string is NULL we simply call the original function with the original parameters and return its return value. The three instructions at HOOKTEST!HookExtTextOutW+0x6c: are used just for this purpose. The next block of disassembly shows us doing exactly the same thing if the string length is 0: HOOKTEST!HookExtTextOutW+0x16: 02400036 85ff test edi,edi 02400038 7452 je HOOKTEST!HookExtTextOutW+0x6c (0240008c) At this point we should have a valid input string and either a length or -1 indicating that the string is null terminated. The next block of code looks for the -1, and if found it calls wcslen to get the length of the string: HOOKTEST!HookExtTextOutW+0x1a: 0240003a 8bf7 mov esi,edi 0240003c 81ffffffffff cmp edi,0FFFFFFFFh 02400042 750a jne HOOKTEST!HookExtTextOutW+0x2e (0240004e) HOOKTEST!HookExtTextOutW+0x24: 02400044 53 push ebx 02400045 ff1508004002 call dword ptr [HOOKTEST!g_pfnwcslen (02400008)] 0240004b 59 pop ecx 0240004c 8bf0 mov esi,eax In either case, the length of the string is stored in esi. If the value is not -1 to start with, that happens at 0240003a, otherwise esi is updated at 0240004c with wcslen results. Next one more test is made to see if the string is longer than 0×800 bytes. 0×800 times 2 for wide characters is 0×1000. That is all we can handle. If the string is longer the original function is invoked without reversing the string: HOOKTEST!HookExtTextOutW+0x2e: 0240004e 81fe00080000 cmp esi,800h 02400054 7736 ja HOOKTEST!HookExtTextOutW+0x6c (0240008c) The next block of code copies the original string to our stack buffer, and then reverses it by calling _wcsrev: HOOKTEST!HookExtTextOutW+0x36: 02400056 56 push esi 02400057 8d8500f0ffff lea eax,[ebp-1000h] 0240005d 53 push ebx 0240005e 50 push eax 0240005f ff150c004002 call dword ptr [HOOKTEST!g_pfnwcsncpy (0240000c)] 02400065 31c0 xor eax,eax 02400067 6689847500f0ffff mov word ptr [ebp+esi*2-1000h],ax 0240006f 8d8500f0ffff lea eax,[ebp-1000h] 02400075 50 push eax 02400076 ff1504004002 call dword ptr [HOOKTEST!g_pfnwcsrev (02400004)] 0240007c 83c410 add esp,10h 0240007f ff7524 push dword ptr [ebp+24h] 02400082 8d8500f0ffff lea eax,[ebp-1000h] 02400088 57 push edi 02400089 50 push eax 0240008a eb05 jmp HOOKTEST!HookExtTextOutW+0x71 (02400091) You will notice that there is also some code in there to ensure NULL termination prior to calling _wcsrev. This is needed because while ExtTextOutW doesn’t require a null terminated string, _wcsrev does. Also, of all of the functions invoked, only _wcsrev is cdecl, requiring its parameters to be cleaned from the stack at 0240007c. Starting at 02400088, the pointer to our reversed string and its length (length first) are pushed to the stack to setup the last two arguments of the call to the real ExtTextOutW function. The jmp at 0240008a is used to jump over our code that pushes the original string and original length values when they do not meet our criteria in the tests prior to the copy and reverse: HOOKTEST!HookExtTextOutW+0x6c: 0240008c ff7524 push dword ptr [ebp+24h] 0240008f 57 push edi 02400090 53 push ebx The final block of code pushes the remaining original arguments on to the stack and invokes the original ExtTextOutW function. HOOKTEST!HookExtTextOutW+0x71: 02400091 ff7518 push dword ptr [ebp+18h] 02400094 ff7514 push dword ptr [ebp+14h] 02400097 ff7510 push dword ptr [ebp+10h] 0240009a ff750c push dword ptr [ebp+0Ch] 0240009d ff7508 push dword ptr [ebp+8] 024000a0 ff1500004002 call dword ptr [HOOKTEST!g_pfnExtTextOutWp2 (02400000)] 024000a6 5f pop edi 024000a7 5e pop esi 024000a8 5b pop ebx 024000a9 c9 leave 024000aa c22000 ret 20h Starting at 024000a6 the epilogue code cleans up our stack and returns the results of ExtTextOutW to the caller. That is it. It is fairly simple. (Did you see a bug?) And, it is short enough to be easily tested in the debugger. Step 8: Setting the Hook RevEngX offers the !iatentry command to allow viewing IAT (Import Address Table) entries. The same command may also be used to setup an IAT hook. Before we set a hook, run the !iatentry command to see where ExtTextOutW is invoked via import table in this process. Enter !iatentry ExtTextOutW. The output should look something like this: 0:004> !iatentry ExtTextOutW Symbol Address: GDI32!ExtTextOutW (76df8b7a) Module Name: GDI32 Image Name: C:/Windows/syswow64/GDI32.dll Loaded Image Name: C:/Windows/syswow64/GDI32.dll IAT_ADDR ACTUAL SYMBOL IMPORTER 724d0544 GDI32!ExtTextOutW (76df8b7a) GDI32!ExtTextOutW C:WindowsSysWOW64UxTheme.dll 7113115c GDI32!ExtTextOutW (76df8b7a) GDI32!ExtTextOutW C:WindowsWinSxSx86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2COMCTL32.dll 6ed51168 GDI32!ExtTextOutW (76df8b7a) GDI32!ExtTextOutW C:WindowsWinSxSx86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.18120_none_72d2e82386681b36gdiplus.dll 767d0254 GDI32!ExtTextOutW (76df8b7a) GDI32!ExtTextOutW C:Windowssystem32IMM32.DLL 75341078 GDI32!ExtTextOutW (76df8b7a) GDI32!ExtTextOutW C:Windowssyswow64LPK.dll 764e14a8 GDI32!ExtTextOutW (76df8b7a) GDI32!ExtTextOutW C:Windowssyswow64MSCTF.dll 75372158 GDI32!ExtTextOutW (76df8b7a) GDI32!ExtTextOutW C:Windowssyswow64SHELL32.dll 76b4123c GDI32!ExtTextOutW (76df8b7a) GDI32!ExtTextOutW C:Windowssyswow64SHLWAPI.dll 75230258 GDI32!ExtTextOutW (76df8b7a) GDI32!ExtTextOutW C:Windowssyswow64USER32.dll 75181004 GDI32!ExtTextOutW (76df8b7a) GDI32!ExtTextOutW C:Windowssyswow64USP10.dll From this you can see that several DLLS call gdi32!ExtTextOutW through their import tables. Calc.exe itself does not, but other DLL’s it uses for displaying strings are listed. We can now set an IAT hook on all of those imports using: !iatentry ExtTextOutW -set HookExtTextOutW. The output should look similar to what is in the screenshot below: Step 9: Detach the Debugger and let the application run… We are now ready to let this rip. You could simply enter ‘g’ at the prompt and let it run in the debugger. I recommend that for the first time. Once you are confident you have it right you can simply enter .detach to detach the debugger from the process and let it run. From there you can ‘q’uit or exit the debugger. Your running copy of Calculator should now have visual evidence of your hook as shown below: You will notice that things don’t just reverse automatically. They have to be redrawn. Running the mouse over the buttons is all it takes in calc to get them to redraw. Menus are drawn when pulled down and so they are reversed. The spacing is off. That is because of the kerning ExtTextOutW does behind the scenes. We really mess it up when we reverse the string – at least in some cases. Where to go next… Besides giving you a new practical joke to pull on a co-worker, this article demonstrates a few of the most powerful commands available to you through the debugger while using RevEngX. Probably the most powerful command, and the one I am most proud of, is the !callfn command. It will let you invoke any function in the target process, and it has access to a database of thousands of definitions that match those in the Windows SDK header files, to allow for a more natural looking call. You can use other commands such as !define to add new definitions to the database if you find that one you use often is missing. You can change definitions that might be wrong for your version of Windows. Database entries are persistent, and the database can be copied to new machines as needed. (Search for RevEngX.db in your home directory.) In addition to calling functions, there are many other commands available in RevEngX that will make your life as an Engineer, Reverse Engineer, or researcher easier! And there is more to come in future versions of RevEngX! One that I’ve started, but not had time to finish is a hex editor window that will allow you to define structure definitions based on regions of memory in the target process. The Hex Editor is done, I just need to finish up the new !dt command and some of the UI work for displaying structural elements with their respective data. This should be a powerful addition to the debugger for reverse engineers. Whatever the cause, just have fun and be responsible! Remember that no matter how clever you think you are, someone can always figure out what you did! As an example, when I reattach the debugger to our hooked calc.exe, and run RevEngX’s !iathooks command (see also !eathooks), I can quickly spot our hooks: 0:004> !iathooks IAT_ADDR EXPECTED ACTUAL SYMBOL IMPORTER 724d0544 76df8b7a 02400020 GDI32.dll!ExtTextOutW C:WindowsSysWOW64UxTheme.dll 7113115c 76df8b7a 02400020 GDI32.dll!ExtTextOutW C:WindowsWinSxSx86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2COMCTL32.dll 6ed51168 76df8b7a 02400020 GDI32.dll!ExtTextOutW C:WindowsWinSxSx86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.18120_none_72d2e82386681b36gdiplus.dll 767d0254 76df8b7a 02400020 GDI32.dll!ExtTextOutW C:Windowssystem32IMM32.DLL 75341078 76df8b7a 02400020 GDI32.dll!ExtTextOutW C:Windowssyswow64LPK.dll 764e14a8 76df8b7a 02400020 GDI32.dll!ExtTextOutW C:Windowssyswow64MSCTF.dll 75372158 76df8b7a 02400020 GDI32.dll!ExtTextOutW C:Windowssyswow64SHELL32.dll 76b4123c 76df8b7a 02400020 GDI32.dll!ExtTextOutW C:Windowssyswow64SHLWAPI.dll 75230258 76df8b7a 02400020 GDI32.dll!ExtTextOutW C:Windowssyswow64USER32.dll 75181004 76df8b7a 02400020 GDI32.dll!ExtTextOutW C:Windowssyswow64USP10.dll (Note that quick isn’t really accurate. Without any extra parameters !iathooks has to search *every* IAT entry to see if it has been hooked. Most processes have a lot of DLLs with a lot of entries, so be patient!) My hope is that this tool is an aid to the honest and the good, and that it simply will not appeal to those with ill intent! Source

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

While doing security audit of iOS apps, there are a lot of tasks that we have to repeat every time. This includes finding out the class information for the app, checking if the application stores any important data in plist files, analyzing the content in the database files etc. These tasks can be a little time consuming every time and so it doesn’t make quite a lot of sense to repeat them over and over again for every app. We have also looked at some tools like Snoop-it and iNalyzer that make our job easier by automating some of these tasks. In this article, we will talk about a new tool named iOS Reverse Engineering Toolkit (iRET) that has just been released to assist penetration testers in automating most of the tasks involved in a iOS penetration test. The project is developed and maintained by @S3Jensen. In the author’s own words, here is what the toolkit does. It’s a toolkit that allows you to automate many of the manual tasks an iOS penetration tester would need to perform in order to analyze and reverse engineering iOS applications. And the bonus is this can all be performed right on the device. Also, please note that iRET is a static analysis tool rather than a dynamic analysis tool. So let’s jump right into it. You can download the toolkit from here. So download this zip file on your device and unzip it. Inside it, there will be a .deb file. You can install it using the dpkg command. Also make sure to install python on your device otherwise iRET won’t work. Now respring or reboot your device (in my case, i had to reboot the device) and you will see a new icon with the name iRET. Tap on it to launch the app. As you can see, we can start the server and then connect to it via our browser. So let’s tap on start and navigate our browser to the mentioned address. We are provided the interface as shown in the image below. Please note that the first time you navigate browser to this address, it takes a little bit of time, so be a little patient. On the left hand side, i can see whether the tools needed by iRET to perform its tasks are installed or not. It looks like i have almost all the tools that i need except a few like file and dumpdecrypted. Installing file is very straightforward as you can download it just by searching via Cydia. However, installing dumpdecrypted on the iOS device could be a bit tricky for beginners so i am going to cover it here. Make sure you have all these tools installed otherwise iRET won’t be able to perform some of its functions. To install dumpdecrypted, you need to download the zip file from its github url on your computer, compile it and then upload the resulting .dylib file on your device. So download the zip file and use the make command to compile the application. As you can see, this will create a .dylib file. So now let’s move this dylib file to our device. In my case, i just did a drag and drop inside the folder /Library using iExplorer. So now when we refresh the interface, we can see that we have all the tools installed. From the right side, we can select the application that we want to analyze. In this case, let me select the Damn Vulnerable iOS App (DVIA). Once the application is selected, iRET gives us this info in the binary analysis tab. iRET uses otool to analyze the binary and gives information such as whether PIE is enable, whether stack smashing protection and automatic referencing counting (ARC) is enabled or not. The next tab shows info that the application has stored in the keychain. iRET uses Keychain_dumper tool to figure this out. Normally, i would be running keychain_dumper using the command line. Using iRET makes it much more easy to find out this information. For me, this feature didn’t work though. The next tab is database analysis. iRET searches for all the database files (.db or .sqlite) in the application sandbox and dumps out all the content from these database files for us to analyze. The log files tab searches for all the log and text files and allows us to monitor the contents of it. For me, iRET wasn’t able to find out the system log file though. The next tab is the plist viewer. The application looks for all the .plist files in the application sandbox and displays us the list so we can analyze the contents of each of the files. This feature could be very useful in quickly analyzing the contents stored by the application in NSUserDefaults, the main plist file that can give us information like the url scheme for the app or any other plist file that might contain some important information. The next tab which is Header files does the following. If the application is encrypted, iRET will decrypt the application. It then dumps the class information for this file and dumps them into seperate header files that are displayed in the dropdown as shown below. Once you select a header file, the content of the header is converted into a theos logify format, which the user can use in the theos tab for quick theos tweak creation. For me, this feature didn’t work and after a brief discussion with the author on twitter we still were not able to figure out the problem. However, here is the screenshot from the author’s blog that shows the contents of the header file being converted into logify format. The Theos tab allows us to create, build and deploy a theos tweak for the application in just a few minutes. Once you enter the information for your tweak, it can allow you to edit the theos files (Tweak.xm, Makefile) , build and deploy the tweak. Please note in order to build and deploy the tweak, you will need to have alteast one SDK installed in the folder /var/theos/sdks on your device. You can find the sdk installed on your Mac (if you have Xcode installed) in the location /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk We will cover writing tweaks using Theos later in this series. The screenshot tab shows the application snapshot taken by iOS when the application enters into the background. These snapshots are stored in the application sandbox without any encryption and might reveal some confidential informaiton. iRET is a very handy tool for analyzing the security of iOS apps and can really save you a lot of time with some of its features. The tool has just been released and hence contain a few bugs but i can clearly see this becoming into a very handy tool in the near future. The purpose of this article was to just give you an introduction with this tool. This article will be updated as iRET receives more features and bug fixes. You can find the blog post regarding the tool from the author here. Source

Introduction In this tutorial we’ll take a look at a Pafish tool, which performs anti debugger/vm/sandbox tricks to detect whether the malware is being executed in a debugger, in a virtual machine or in a sandbox. Malware analysis today depends on a great deal of factors, but we’re often using a virtual machine in order to analyze malware: this is because virtual machines are easy to reinstall and configure. There are a lot of options regarding networking, where we can use host-only, internal, NAT or bridged networking that enables virtual machines to have full, partial or none access to the network. One great feature of virtual machines is that they provide snapshots where we can create a snapshot, install malware and infect the whole system, and later revert the snapshot to restore the system to the old state (without malware infection). This happens in a matter of minutes, but imagine how long it would take to reinstall a system or restore from the last image when a physical host is involved. Malware is often also executed in a sandbox, which is how most of the online scanning solutions are analyzing malware. Additionally, we’re also using different debuggers to analyse malware samples to figure out their internals. All those techniques greatly speed up malware analysis, which is why authors are thinking of ways to detect when malware is being executed under such environment/conditions in order to make the analysis more difficult. When malware detects that it’s being executed under a debugger/vm/sandbox, it can deviate from its original path and do something legitimate or terminate immediately. On the other hand, when malware doesn’t detect it’s being executed under debugger/vm/sandbox, it will run its malicious payload and infect the system. Getting the Code Pafish is being developed in wxDev-C++ as it says on its official Github website. First we have to download wxDev-C++ from [11] and click on the “wxDev-C++ Full Installer”, so we will have the full environment installed and won’t have to download additional parts of the installation package afterwards. The installation executable is 117MB large, so the download will take a while. The installation of wxDev-C++ will look as presented on the picture below. After the installation, we have to open the Pafish wxDev-C++ configuration file, which will also initialize the wxDev-C++ when run for the first time (if defaults are accepted). Once we’ve opened the project there will be different source files each used for different detection purposes: Detect a debugger: debuggers.c Detect a sandbox: gensandbox.c Detect hooked functions: hooks.c Detect Sandboxie: sandboxie.c Detect Wine: wine.c Detect VirtualBox: vbox.c Detect VMWare: vmware.c Detect Qemu: qemu.c Each of the outlined source files contains checks used to detect the specific environment. In the next sections we’ll take a look at each of the methods used to detect the environment. Detecting a Debugger First method: the IsDebuggerPresent function is a Win32 API function that can be used to determine whether the calling process is being debugged by a debugger. The CheckRemoteDebuggerPresent function checks whether the process is debugged by a remote debugger, which doesn’t necessarily reside on a separate computer, but is a separate process. The OutputDebugString function sends a string to the debugger for display. If the application is not running under a debugger, the string will be sent to system’s debugger to be displayed with the DbgPrint function. If the application is not running in a debugger and there is no system debugger, then the OutputDebugString does nothing. If the function doesn’t return an error, the process is not being debugged, otherwise it’s running under a debugger. Detecting a Sandbox Pafish contains four methods to detect the sandbox. The first method is using a quick mouse movement, where the GetCursorPos is used to retrieve the position of the mouse cursor. The GetCursorPos has the following syntax [1], where the lpPoint parameter accepts a pointer to a POINT structure where the screen’s coordinates of the cursor will be saved. The function returns nonzero if it was completed successfully, otherwise it returns zero. Let’s now take a look at the actual detection function as used by Pafish to detect whether the program is running in a sandbox (seen on the picture below). The function first calls the GetCursorPos in order to receive cursor coordinates and saves them into the position1 variable. After that it sleeps for a while and then calls the GetCursorPos for the second time and saves the mouse coordinates into the position2 variable. Afterwards, the x and y coordinates of the mouse cursor are compared to each other, which determines whether the mouse cursor has changed during the last GetCursorPos function call. If the position of the mouse cursor has changed, then there was mouse activity during the sleep function, which means it’s probably running in a simulated environment (most probably in a sandbox). A clear indication of the application running in a sandbox is that a human couldn’t possibly move the mouse in such a short period of time. The second method that’s used by Pafish to detect a debugger is using a GetUserName function that retrieves the name of the user associated with the current thread [2]. The syntax of the function can be seen below, where it’s evident that a function accepts two parameters. The first parameter lpBuffer is a pointer to the buffer where the user’s logon name will be saved. The buffer must be large enough to enable the whole username to be saved to the buffer, otherwise the function will fail. The second parameter lpnSize specifies the size of the lpBuffer buffer, which is overwritten upon the function’s completion – the lpnSize will contain the length of the username copied to the lpBuffer buffer. The function will return a nonzero value when successful, otherwise a zero is returned and a detailed error log can be obtained by calling GetLastError. The code used in Pafish can be seen below, where we’re first reserving a buffer on the stack to hold the username buffer of size 200 bytes and integer number i. After that we’re calling the GetUserName, which will copy the logon username to the username buffer previously allocated. After that all the lowercase letters are changed to their upper-case letters and the name is compared to the following strings: SANDBOX, VIRUS and MALWARE. The strstr function returns a pointer to the first occurrence of the presented strings if found, otherwise it returns NULL. If the SANDBOX, VIRUS or MALWARE strings are found inside the username, the function will return 0, which specifies that the program is being run inside a sandbox. Otherwise 1 is returned, which signifies that the program is not being run in a sandbox: more specifically, that the logon username doesn’t contain the strings SANDBOX, VIRUS or MALWARE. The next method is using GetModuleFileName, which retrieves the fully qualified path for the file that contains the specified module [3]. The function syntax can be seen below. The function accepts three parameters, the hModule, the lpFilename and the nSize. The hModule contains a pointer to the requested module whose path we would like to obtain. If the parameter is NULL (as it is in our case), then the function will retrieve the path of the current executable instead. The lpFilename parameter is a pointer to a buffer, where the module/executable path will be stored; the buffer size must be larger than the size of the returned path if we want the function to succeed. The nSize parameter specifies the size of the lpFilename buffer, which must exceed the length of the returned path. We should also describe the DeviceIoControl function, which sends a control code to the device driver instructing the device to perform a certain action [5]. The function accepts eight parameters: hDevice, dwIoControlCode, lpInBuffer, nInBufferSize, lpOutBuffer, nOutBufferSize, lpBytesReturned and lpOverlapped. The hDevice contains a handle to the device on which the action will be executed, which can be a file, a directory, or a stream of a volume (the handle is obtained by previous call to the CreateFile function). The dwIoControlCode specifies the operation to be executed on the device. The lpInBuffer specifies the buffer, which contains the data required to perform the requested operation, but can be set to NULL if the dwIoControlCode doesn’t require any input data (the nInBufferSize contains the size of the input buffer). The lpOutBuffer specifies the buffer where the data of the operation will be written to, while the nOutBufferSize specifies the number size of the buffer. If the function completes successfully, a nonzero return value will be returned. Detecting Sandboxie Sandboxie is a program that enables us to run a program in a sandbox to prevent malware from making permanent changes to our machine [6]. Sandboxie can easily be downloaded from the official Sandboxie website and installed on our machine. After Sandboxie has been installed, it will start a window like the one below. I won’t go into the details about how Sandboxie works, but let’s just look in the C:\Program Files\Sandboxie\ folder to check what it contains. I’ve specifically highlighted the SbieDll.dll library, which is used by Sandboxie. Detecting VirtualBox The code below uses the RegOpenKeyEx function to open the registry key seen on the picture below. If the function finds the specified registry entry, it will return ERROR_SUCCESS, otherwise a value of nonzero will be returned. Afterwards the type and data of “Identifier” registry key is retrieved: the value is stored in the lpData parameter. The retrieved data is then converted to uppercase letters and compared to the VBOX string. The value represents the SCSI disk name, which contains VBOX when the program is running under VirtualBox, otherwise it is not. The method below is actually very similar to the method above, except that we’re checking whether the SystemBiosVersion value contains the string VBOX, in which case the program is running under VirtualBox. The function below is practically the same as the function above, which checks whether the VideoBisVersion contains a string VIRTUALBOX, in which case the program is running in a debugger. The code below checks whether the “SOFTWAREOracleVirtualBox Guest Additions” exists in a registry, in which case the program is running under VirtualBox; otherwise it is not. The code below checks whether the mouse driver for the VirtualBox exists: C:WINDOWSsystem32driversVBoxMouse.sys. If the file exists, the program is running in a VirtualBox. Detecting VMWare The function below is the same as the one used to detect VirtualBox, but it compares the SCSI hard drive identifier with a string VMWARE. If the string is found inside the identifier, the program is running under VMWare, otherwise it is not. The function below checks whether the “Vmware Tools” registry key exists in a registry, which means the system is running under VMWare. The function below checks whether the driver which enables the shared folders exists in the C:\WINDOWS\system32\drivers\ directory, in which case the operating system is running inside VMWare. Detecting Qemu The function below checks whether the SCSI hard driver identifier contains the word QEMU, in which case the operating system is running inside Qemu. Let’s now check whether the specified registry key exists in the operating system running in Qemu. We’ve run regedit and opened the DEVICEMAP entry, where there is no such field as Scsi, which is being checked by the previous function. Since the Scsi entry doesn’t exist, that Pafish function won’t be able to detect that our Windows operating system is running inside Qemu. It should be noted that the Scsi identifier is available only if SCSI disk is enabled by using the “-drive file=file,if=scsi” option in qemu. Since we’re not using the SCSI interface, that option is not available under the registry and the function above won’t be able to detect Qemu. The next function checks whether the SystemBiosVersion contains the string QEMU, in which case the operating system is running inside Qemu. If we open registry editor and open the HKLM\HARDWARE\Description\System\SystemBiosVersion key, we’ll see the “ACRSYS – 1? value as presented below. Since the value doesn’t contain a substring QEMU, the function above won’t be able to detect Qemu. Now it’s finally the time to run pafish.exe to check whether any of the checks inside Pafish can actually detect whether the code is being executed in debugger/vm/sandbox. When pafish.exe is being run inside Windows 7 running under the Qemu virtual machine, none of the functions will be able to detect it (as we’ve already figured out). The output from running the pafish.exe can be seen on the picture below, where the most interesting part is the Qemu section – this is where the already identified checks are executed, but neither is able to detect that the Qemu virtual machine is used. Conclusion In this article we’ve presented different methods of checking whether the program is running under a debugger, virtual machine or a sandbox, where we’ve specifically taken a look at each function used to check that. Malware authors today are using the same checks to check whether their malware malicious sample is being executed under a controller environment, in which case the malware will not perform any malicious checks to avoid detection for as long as possible. Malware authors are often using VirtualBox or VMWare virtual machines where the analysis of malware samples is taking place. We’ve seen a number of checks used to detect whether malware is being executed under VirtualBox/VMWare, which need to be bypassed in order perform a complete analysis of the malicious malware sample. Since bypassing all those checks takes a lot of time and knowledge, wouldn’t it be better if we could simplify things? One of the options is using Qemu as virtualization technology, which is a very customizable program; I’m not saying that VirtualBox/VMWare can’t be customized, but it’s far easier to do so with Qemu (especially when wanting to change an option not usually supported by a graphical user interface used by VirtualBox/VMWare). When analyzing a malicious sample we have to remember that any of the above checks can be employed by an attacker to determine whether the malware is being run in a controlled environment, in which case, the malware will most probably terminate its execution. If we suspect that some of the above checks are being used by the malware sample, we can install the appropriate operating system (usually Windows) into Qemu and try to analyze the malware there. That means only that we’ve bypassed the WMWare/VirtualBox/Qemu checks, but if we want to use a debugger, we must also bypass the debugger checks, but that is a story for another time. This short introduction was meant for all malware analysts out there to improve their knowledge about analyzing malicious malware samples. Remember that an attacker can put arbitrary checks into the malware in order to check whether the code is being executed in other environments, like different online malware scanners: VirusTotal, Anubis, etc. When a user receives an executable, he usually submits it to the online malware scanner, which is used to give the first insight into the program’s execution. If the executable was able to detect whether it is being executed in such an environment, incomplete data could be given back to the user as a result of an online malware scan. The user could conclude that the executable is not malicious and execute it, unknowingly installing a backdoor on their own system. This is particularly useful for spreading malware among normal users, who are not malware analysis experts. We have to remember that such checks play an important role in malware analysis, and we have to check whether they are contained in an executable to confirm whether the executable is malicious or not. Remember that even if all automatic analysis tools are reporting that an executable is not malicious, that might not necessarily be the case, as we’ve seen in this article. An executable might still be malicious with proper checks in place to deter the analysis systems into flagging the executable as a valid non-malicious executable. References: [1] GetCursorPos function, GetCursorPos function (Windows). [2] GetUserName function, GetUserName function (Windows). [3] GetModuleFileName function, GetModuleFileName function (Windows). [4] CreateFile function, CreateFile function (Windows). [5] DeviceIoControl function, DeviceIoControl function (Windows). [6] Protection from rogue software, spyware and malware is just a click away…, Sandboxie - Sandbox software for application isolation and secure Web browsing. [7] GetModuleHandle function, GetModuleHandle function (Windows). [8] GetProcAddress function, GetProcAddress function (Windows). [9] RegOpenKeyEx function, RegOpenKeyEx function (Windows). [10] Github Pafish, https://github.com/a0rtega/pafish. [11] wxDev-C++ Downloads, Downloads | wxDev-C++. Source