Valve explain Steam in-home streaming, as early closed beta begins with a revolution

While Linux ports are becoming increasingly de rigueur among PC developers, Valve's living room focused SteamOS still won't be able to run the majority of Steam's Windows-only catalogue. That's why the SteamOS announcement made mention of game streaming, letting your Windows machine do the heavy lifting. Following on from their creation of an in-home streaming Steam group, now they've kicked off the streaming beta, and created a series of posts explaining how it will work.

"Any two computers in a home can be used to stream a gameplay session and this can enable playing games on systems that would not traditionally be able to run those games," Valve write. "For example, a Windows only game could be streamed from a Windows PC to a Steam Machine running Linux in the living room. A graphically intensive game could be streamed from a beefy gaming rig in the office to your low powered laptop that you are using in bed. You could even start a game on one computer and move to a more comfortable location and continue playing it there." The second computer is used purely to receive audio and video signal, and send controller inputs.

A Q&A clarifies a few of the streaming feature's technicalities, confirming that it will be free, and saying that internet streaming is "currently not supported." Perhaps the more significant, if understandable revelation is that PCs will be unusable during streams. "Your computer is dedicated to running the game and input is coming from both the remote client and the local system. It would be very confusing if someone were trying to use the computer at the same time."

Head over to the In-home Streaming Announcements page for more in-depth technical details. The streaming beta is now running for the first wave of testers. If you'd like to be considered for an expanded beta, sign up to the Steam group

Read More

DEBIAN 7.2 is ready for it's OFFICIALLY RELEASED

The Debian project announced the immediate availability for download of the second maintenance release of the Debian 7 Linux operating system.

Debian 7.2 is just a maintenance update, but it does feature a wide array of updates and fixes for the current stable branch and a lot of packages have been upgraded. 

“Please note that this update does not constitute a new version of Debian 7 but only updates some of the packages included. There is no need to throw away older wheezy CDs or DVDs but only to update via an up-to-date Debian mirror after an installation, to cause any out of date packages to be updated,” reads the official announcement.

This means that users who already have a Debian 7.0 or 7.1 installation won't have to reinstall the system all over again. They just need to perform a regular update, as only a small number of packages will be downloaded from security.debian.org.

Check out the complete changelog in the official announcement.

DOWNLOAD FROM OFFICIAL DEBIAN SITE:

http://www.debian.org/mirror/list

Read More

Five problems of Linux on the desktop.. I think you noticed

There are multiple more or less brainy analyses that attempt to respond to the market share of Linux on desktop systems, very low considering the quality of your code and the great acceptance of the set free in other technology sectors.

Problem of Linux on the desktop that contrasts with the situation of the system in other technological fields. Linux Supercomputing sweeps with 94 per cent of market share and has an estimable bottom-up presence in servers. It dominates in smartphones with Android as a protagonist and a good number of systems back as Tizen, Firefox OS or Ubuntu Mobile.

In terms of its presence in embedded it is essential to give output to the world market and in the tablet sector, Android surpassed in the second quarter of 2012 to Apple in market share, the first time that this happens since the launch of the first iPad.

Why not going to the computer desktop?

Linux-based operating systems added a market share on the desktop that does not reach 1 percent against Windows in the sector with 90 per cent and the share delMac OS X from Apple that is around 8 percent.

The explanation to this share of Linux is not simple though from betanews, a usual editor Linux user, attempts to bring to the debate the five major issues that he considers penalize the market share of the system.

5. The different desktop managers lead to a fragmented experience

A section is vital because it is the set of software that provides the graphical user interface and multiple functions that allow you to interact easily with the team.

In Linux, as well as Gnome and KDE which disputed mastery of desktop managers, there are other few like XFCE, CDE, LXDE, Unity, Cinnamon, that too often 'war' between them dividing the community into a sort of tribal identity that does not lead to anything, indicates the editor.

Although in the "variety is the spice" and this choice is the essence of this free system, for a not well versed user leads to a lack of familiarity and experience that penalizes the increase in use. A screenshot of OS X or Windows is immediately recognizable and countless desktop Linux computers? Not so much, he says.

4. Too many Linux package managers make difficult their learning

Many newbies to Linux start with Ubuntu, turned into the most popular GNU/Linux distribution. In the command line interface (powerful Linux and offers total access and control equipment), these users will learn the apt package manager commands, since it is used Ubuntu.

Unfortunately, these new Linux users think that apt is the only package manager. There are many other managers such as dpkg, YUM, Pacman or the base RPM. Although generally the software is delivered in repositories that facilitate the task, these packages managers use various scripting that can be confusing when the user try other distribution.

3 Lack of software

It is a sensitive issue because the more purist of Linux are running wonderful alternatives to large developments in Windows and Mac (Gimp to Photoshop or OpenOffice for Microsoft Office) which can be used for basic use, this alternative software may not be valid. Examples such as professional video editing is an example of the lack of Linux software, according to betenews.

Beyond professional applications, the video games section is another big problem. Exceptions are counted native games for Linux despite run games Windows Linux emulators or on digital platforms like Steam where Valve is betting Yes on platform Linux though is not going very well.

2. Hardware compatibility

Although the hardware support for Linux has advanced a lot, this section is still punishing the free system and too many are devices not supported, not only for drivers but by the lack of specific software for the same.

This minor with respect to Windows or Mac hardware compatibility is attributable in large part to the manufacturers themselves. The low market share of Linux called not to develop for the system, and this lack of development a penalty use in a vicious circle.

1 Linus Torvalds is deadly

Finnish software engineer is the creator of the Linux kernel. A gigantic project that exceeds the 17 million lines of code and which was attended by almost 10,000 developers of 1,000 different companies and in which all distributions are based.

However, Torvalds is the absolute owner as the primary maintainer of the kernel. His intelligence and skill is comparable for his behavior bizarre and controversial, with examples as insults to the kernel developers or NVIDIA, they say.

Although obviously without Linux would not exist, Torvalds is both a gift and a curse for the Linux community, they point out, wondering by what will happen when you do not want or you can continue with the project and the ability of his successor to lead a development like this.

How do you see it? Do you think that the diversity of desktop environments or systems packages penalize or part of the value of Linux? What happens without Linus Torvalds? It would be useful to find a guarantor system kernel not so personal? How we convince to OEMs so that they bet on Linux or at least offer it as an option on new equipment? Do you - like us - that this is the real problem and less existing desktop environments?

Read More

How to encrypt files stored on our computer of different OS like LINUX,Windows,OSX of all with small details

How to encrypt files stored on our computer

Cases of espionage on the Internet by United States have served so many users become aware of the need to safeguard the privacy of your data. With the idea of improving the security of our information, we dedicate a few minutes to review methods to encrypt files in different operating systems.



How to encrypt files in Windows

Windows offers us the ability to encrypt the contents of folders, natively, from the operating system itself. In general terms, the process is fairly simple and not find too much complications beyond caution keep a safe place, the certificate necessary to decrypt the files.

The choice of encryption that includes Windows natively is, in my opinion, quite simple and I do not think that it is free from unauthorized access. Therefore, I think that we could handle other options and resort to other utilities of recognized solvency.

One of the most popular, and also used within the business sector, utilities is TrueCrypt. This application is a free software that allows us to encrypt information in Windows, OS X and Linux and offers several encryption options. Among other things, TrueCrypt allows you to encrypt the entire contents of the hard drive (including the boot partition), generate a real or virtual partition that is encrypted or, even, to create USB drives that store encrypted content. In addition to all these safety options, once we have the configured application, the process is transparent to the user and this will hardly notice interruptions in their work (with the advantage of having your data more safe).

AES Crypt is another option that is available both for Windows and for OS X and Linux and offers 256-bit AES encryption. In this case, the encryption of files and folders is somewhat more selective and we will be us who manually, we will indicate what we want to store safely. With the idea to make things easier, AES Crypt is integrated into the Windows context menu, so clicking on a file with the right mouse button you can encrypt it comfortably.

Another option to encrypt files without too many complications in Windows is AxCrypt which uses AES (Advanced Encryption Standard) encryption like AES Crypt, though, that Yes, 128-bit.



How to encrypt files in OS X

OS X also includes, natively, the ability to encrypt the entire contents of the hard drive on this operating system. FileVault, which is named this option can be activated from the system preferences (security option, enable FileVault and set a security password). FileVault offers 128-bit AES encryption and, obviously, to cover the content of the system hard disk, at certain times we can see some drop in the performance of the team having to always work with encrypted content.

An alternative more selective than FileVault is iSafe, a fairly cheap application (1.99 euros) that offers us the possibility of creating collections of files encrypted using 256-bit AES encryption. The operation, actually, is very simple; After setting a master password and enter it when starting the application, we will see the collection of encrypted files that we have on the basis of the defined categories (something like folders) and, for each collection, the stored files. With a provision of this form, if you want to store a file in a collection (and thus encrypt it), the only thing we have to do is "drag and drop".

Scrambler and Espionage are two alternatives of payment which, like iSafe, allows us to encrypt files in OS X without too many complications, and of course, being selective in the process (i.e., encrypting only what we want to protect and not entire hard drive).


How to encrypt files in Linux

Finally, for users who are freshly landed in the world of Linux either do not have advanced knowledge in the matter, it is important to know that you can also encrypt your files.

One of the methods known to encrypt files is GnuPG (GNU Privacy Guard) which, incidentally, is a component that requires Enigmail to encrypt emails in Thunderbird. Use is very easy to and, for example, from the Terminal we call gpg and, from the command line, encrypt files comfortably no more than indicate the password that we use for encryption.

eCryptfs is a more advanced option when it comes to encrypt files, a sort of extension of GnuPG applied to the file system with which we can improve the security of our directory home (our personal files). eCryptfs is packaged for multiple distributions and we can install it on Debian, Fedora, Gentoo, openSUSE or Ubuntu.

SeaHorse is a 'classic' project of Gnome that allows us to integrate GnuPG into this desktop environment so we can encrypt files without having to resort to the console. After installing this package we have at our disposal options to encrypt / decrypt files in the menu that appears when you press the right button of the mouse on a file or folder.

Read More

Windows 8 is already the second system on Steam

Windows 8 is the second most used on the Steam game platform operating system, surpassing even the Windows 7 32 bit and despite fierce criticism that the founder of Valve issued against the new Microsoft System.

"Windows 8 is a catastrophe for the whole world of the PC." Thus of hard-hitting Valve CEO was a few months ago and head of Steam, Gabe Newell, a curious guy who worked 13 years at Microsoft before co - founding developer of video games and digital distribution.

Newell charged not only Windows 8 but that used Steam Linux move users out of Windows, since "their platform games run faster on Linux than on Windows," he said.

Whether true or not, the fact is that Windows 8 continues triumphing in Steam, surpassing even the 32-bit Windows 7 to become the second most widely used on Steam operating system. A fee of use among users of the platform of Newell above the 13 percent who already want to Microsoft it in the desktop market for Windows 8. 

Valve on Friday updated its Hardware & Software Survey for February 2013, and the news is once again very good for everyone except Apple. Both Microsoft and Canonical have reason to celebrate Steam usage for their respective platforms as Windows 8 has overtaken Windows XP and Linux has passed the 2 percent mark (the majority of Linux users are running Ubuntu).

Here is how things looked like for February 2013 on Steam, in order of biggest to smallest share:

Windows 7: 69.31 percent
Windows 8: 9.63 percent
Windows XP: 9.33 percent
Windows Vista: 5.84 percent
OS X: 3.07 percent
Linux: 2.02 percent
Breaking down the numbers even more, here is how each operating system version fared:

steam february Windows 8 overtakes Windows XP adoption on Steam, while OS X drops and Linux passes the 2% mark

Ever since its release, Windows 8 has been the only version of Microsoft’s desktop operating system to gain share on Steam. This has continued through February, as gamers ditch Windows 7, Windows Vista, and Windows XP for the latest and greatest.

Three months ago, Windows 8 passed OS X on Steam, and last month, Windows 8 passed Windows Vista.

Now, after just four months of availability, Windows 8 has already passed Windows XP. This puts the operating system neatly into second place on Steam, where it will likely stay for quite a while.

Windows 8 was up 0.87 percentage points between January and February. Meanwhile, Windows 7 was down 0.42 percentage points, Windows Vista dipped 0.18 percentage points, and Windows XP fell 0.72 percentage points.

Microsoft aside, OS X has once again lost share while Linux is seeing big gains. Two weeks ago, Valve released a stable version of its Steam for Linux client and it crossed the 2 percent mark, largely thanks to Ubuntu users.


Going forward, we expect Windows 8 to continue growing, but it won’t pass Windows 7 anytime soon. In the meantime, March will be the first time the Linux client is available for a full month, and we’ll see if it manages to surpass OS X adoption, as unlikely as that may seem.

Read More

A small detailed and 14 Most Interesting Linux Facts

Linux is one of the world’s most powerful and popular operating system. Linux operating system was developed by Linus Benedict Torvalds at the age of 21. At present there are more than 300 flavors of Linux available and one can choose between any of them depending on the kind of applications they want.

Linux is a freeware and generally speaking its free from Virus and other malware infections. In this post I will share few Linux facts which may or may not be know for many of us.

14 Most Interesting Linux Facts

1.Only 2% of the current Linux kernel written by Linus Torvalds.
The Linux kernel version is written in the programming language C.

2.The first commercial distribution GNU / Linux was Yggdrasil was launched Lice-CD format in 1992. Red Hat was one of the first distributions to settle within companies and data centers in 1999.

3. A guy named William Della Croce Jr. registered the name Linux and demanded royalties for use of the mark. Later, he agreed to assign the trademark to the true owner, who is Torvalds.

4.Countries such as Russia, Brazil and Venezuela have put their focus on Linux as a basis for interoperable management , cost efficient and technologically independent.

5. U.S. Department of Defense, U.S. Navy Submarine Fleet, Federal Aviation Administration uses Linux in government offices. Indian state of Tamil Nadu uses Linux for education purpose.

6. 90% of the world’s most powerful supercomputers using an operating system GNU / Linux, in fact, the top ten of supercomputers use Linux. In fact, the penetration of Linux in data centers is very high, 33.8% of the world runs on Linux servers compared to 7.3% does so in a Microsoft operating system.

7.The name of the penguin, Tux , is not entirely clear. On the one hand, it is said that the origin of the name comes from the fact that penguins appear to be wearing a tuxedo, which in English is said max tuxedo tux and is abbreviated. In contrast, another source comes from the letters of the logo of Tux are Unix Torvalds.

8.Torvalds wanted to call the kernel Freax (a combination of “free”, “freak”, and the letter X to indicate that it is a Unix-like), but his friend Ari Lemmke, who administered the FTP server where the kernel was hosted for download, the download directory called kernel of Linux Torvalds.

9.Debian was one of the first GNU / Linux that was constituted and organized as a community of developers.

10.Linux is present in highly critical applications such as Japan’s bullet trains, traffic control, San Francisco, the New York Stock Exchange, CERN, many air traffic control systems or control of nuclear reactors of submarines and ships many nuclear war.

11.Linux programmers are often associated with living “isolated” in the world, however, over 75% of the code developed for the Linux kernel came from private sector developers. In fact, large technology companies like Intel, Google, IBM, AMD, Sun Microsystems, Dell, Asus, HP, Analog Devices, Oracle, Novell or Red Hat help developing applications, contributing to the core or pre-installing any GNU / Linux their machines. In fact, during the 2003 Super Bowl (which paralyzes the United States and remains glued to the TV for many Americans), IBM delivered a beautiful ad talking about Linux and open source options.

12.The GNU kernelhttp://technoworld007.blogspot.in/search?q=kernel in 1991, had no drivers and kernel, that’s what led to Linus Torvalds to address the Linux kernel development. If GNU had had, perhaps, Torvalds had not been put to work on that.

13.The Linux kernel is now the most widely ported operating system, running on a great variety of operating systems.

14.World known companies such as Google, Cisco, Facebook, Twitter, Linkedin etc use Linux as their main operating system.

Read More

Tutorial on Cracking Unix Password Hashes

Cracking Unix Password Hashes with John the Ripper
Few weeks ago we introduced all of you to John the Ripper...now I will show you some cracking Remember that everything is written here is only for educational purposes. Let's begin!

Introduction :»

This post will serve as an introduction to password cracking, and show how to use the popular tool John-the-Ripper to crack standard Unix password hashes.

The Scenario :»

My scenario is the following: We have just compromised and gained root access to a Unix machine on our target's network. Now, to better maintain access, and to facilitate further intrusion, we will attempt to extract and crack the password hashes on the host.

Where are Password Hashes Stored?

Before we can crack the password hashes, we first need to know where they are stored. Traditionally (according to Wikipedia, before 1988) password hashes for account were stored in the /etc/passwd file. However, this caused security issues since the file was readable by all users on the system. Now, instead of a password hash, this file contains an "x" to indicate that the password details are located in a different place: the /etc/shadow file. This file is only readable by the superuser (root), so there is far less of a security risk associated with this file.

Password Cracking Process : »

An important thing to note is that these two files have some overlapping content. John the Ripper's tool suite provides a nifty tool to merge these two files into one called "unshadow". To use it, we simply need to specify the passwd file, and the shadow file. For the sake of this post, we will use the /etc/passwd and /etc/shadow files on my local Backtrack VM. However, in the case of our scenario above we will have copied these files from our compromised machine to our Backtrack machine, and then specify the location of these files to unshadow. Then, we send the output to a new file of our choice. This looks like the following:
[code]
root@bt:~# cd /pentest/passwords/john
root@bt:/pentest/passwords/john# ./unshadow /etc/passwd /etc/shadow > ~/passwords.txt
root@bt:/pentest/passwords/john# cat ~/passwords.txt
root:$6$jcs.3tzd$aIZHimcDCgr6rhXaaHKYtogVYgrTak8I/EwpUSKrf8cbSczJ3E7TBqqPJN2Xb.8UgKbKyuaqb78bJ8lTWVEP7/:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
syslog:x:101:103::/home/syslog:/bin/false
sshd:x:102:65534::/var/run/sshd:/usr/sbin/nologin
landscape:x:103:108::/var/lib/landscape:/bin/false
messagebus:x:104:112::/var/run/dbus:/bin/false
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
mysql:!:105:113::/var/lib/mysql:/bin/false
avahi:*:106:114::/var/run/avahi-daemon:/bin/false
snort:*:107:115:Snort IDS:/var/log/snort:/bin/false
statd:*:108:65534::/var/lib/nfs:/bin/false
usbmux:*:109:46::/home/usbmux:/bin/false
pulse:*:110:116::/var/run/pulse:/bin/false
rtkit:*:111:117::/proc:/bin/false
festival:*:112:29::/home/festival:/bin/false
postgres:!:1000:1000::/home/postgres:/bin/sh

We can immediately notice the password hash for the user root. Let's fire up JTR, and point it to this passwords.txt file. To perform the cracking, we will use the --single option. From the documentation:

"This is the mode you should start cracking with. It will use the login names, "GECOS" / "Full Name" fields, and users' home directory names as candidate passwords, also with a large set of mangling rules applied. Since the information is only used against passwords for the accounts it was taken from (and against password hashes which happened to be assigned the same salt), "single crack" mode is much faster than wordlist mode. This permits for the use of a much larger set of word mangling rules with "single crack", and their use is always enabled with this mode. Successfully guessed passwords are also tried against all loaded password hashes just in case more users have the same password."
- John the Ripper Documentation

Let's see this in action and attempt to crack the password hash for the root user:

root@bt:/pentest/passwords/john# john --single ~/passwords.txt
Warning: detected hash type "sha512crypt", but the string is also recognized as "crypt"
Use the "--format=crypt" option to force loading these as that type instead
Loaded 1 password hash (sha512crypt [32/32])
toor (root)
guesses: 1 time: 0:00:00:00 DONE (Fri Jan 4 10:12:42 2013) c/s: 35.00 trying: toor
Use the "--show" option to display all of the cracked passwords reliably
root@bt:/pentest/passwords/john# john --show ~/passwords.txt
root:toor:0:0:root:/root:/bin/bash

1 password hash cracked, 0 left

Success! After we finished cracking the password hashes found in the passwords.txt file, we can use the command john --show [file] to display the found account details. These details are displayed in the same format as the password file, with the only exception being that the password hash is now replaced by the password 'toor' (the default password for the root user on Backtrack).

I hope this short introduction to password cracking helps you. Keep an eye out for a more comprehensive post covering more JTR cracking techniques, as well as other password cracking tools and methods.

source by thecyberelite.blogspot.com
I am not responsible for any consequences , you dig your own grave of you own risk guys :P

Read More

The five fastest-booting Linux distributions details and along with Linux distribution Logos

     You may not have to reboot Linux very often. But when you do, these peppy distributions will have you up and running in a matter of seconds.

Reboots tend to be rare with Linux. Usually, they’re due to a kernel update or an environmental issue. But regardless of the reason, it’s crucial it come back to life quickly. One issue surrounding Linux of late is boot time. Some distributions have made it a key feature to attract users. Some have even succeeded in reaching that magic 10-second number. But which distributions boot fastest? Let’s take a look.

NOTE: Console logins do not count.

IMP :-- to know more about Linux details click here on [ Linux ] or search and find Linux updates or see and click on Linux details of right side widget.

1: Puppy Linux

Puppy Linux is not the fastest-booting distribution in this crowd, but it’s one of the fastest. And what’s unique about this distribution is that it will boot faster than your standard OS, even when it’s booting from the Live CD. Of course, some may claim, “It’s not a full-blown OS”. But it is. Although many view Puppy more as a rescue distribution, it’s a full-blown distribution that offers nearly every tool you need to do what you need to do.

Average boot time: 26 seconds.


2: Linpus Lite Desktop Edition

Linpus Lite Desktop Edition is an alternative desktop OS featuring the GNOME desktop with a few minor tweaks. Linpus is definitely not a distribution you will use and try to tweak into any sort of server OS — this is desktop only. And although Linpus does have everything you need to use a desktop, you might find some of the applications a little out of date (such as Firefox 6.0).

Average boot time: 21 seconds.


3: Arch Linux

Arch Linux is another lightweight distribution that aims to have a lightning-fast boot time. This distribution focuses on simplicity, minimalism, and elegant code — so naturally it’s going to boast quick boot times. Although out of the box, Arch isn’t the fastest booting Linux in town, it can be tweaked enough to best the best. This distribution is based on the pacman package manager and should be easy enough for most users (maybe not the newest newbies) to manage.

Average boot time: 18 seconds.


4: Slax

Slax is unique in that you can fully customize the distribution you download. Because of this, you can create one seriously lean desktop distribution that will boot nearly as quickly as you like. I managed to create a distribution with Slax (focusing only on specific desktop needs for writing and graphic design) that not only could serve me well, but could do so quickly. To build your unique Slax download, visit the Slax Builder to begin. Believe it or not, it’s not that difficult to create your very own Linux with Slax.

Average boot time: 16 seconds.


5: Ubuntu 11.10

Ubuntu 11.10 is the king of quick boots. It was the first fully loaded desktop distribution that could claim the 10-second boot time. And I have witnessed that boot time firsthand. The 10-second boot doesn’t require seriously overpowered hardware, either. This magic number can be reached, without tweaks, on average hardware you can purchase off the rack. Even with the less-than-desired Ubuntu Unity, you can have your desktop up and running, from cold boot, in around 10 seconds.

Read More

SF-Reboot-To 4.9.0.0 Final Dual booting tool

SF-Reboot-To 4.9.0.0 Final - The solution to Dual Boot of windows [Official Link]

Choose which operating system boot following or reboot your computer easily

Reboot-To is a simple and easy to use that it runs in the system tray and lets you choose which operating system to boot next. 
This application is useful for those who have more than one operating system installed on your computer. With a single click, you will be able to restart your computer.

Requirements:

Microsoft Windows Operating System

.NET framework 4

Support List:

Window Vista - Reboot to is supported

Windows 7 - Reboot to is supported and install is supported

Windows 8 - Reboot to is supported and install is supported

Windows Server 2008 R2 - Reboot to is supported and install is supported

Windows Server 2012 - Reboot to is supported and install is supported

Ubuntu (wubi) - Reboot to is supported

Ubuntu Server (wubi) - Reboot to is supported 


Download link :- http://download.sysfunctions.com/download.php?file=SFRT

Read More

Details about Windows vs Linux vs Mac

If you go from Windows to Mac might be interested...

Current operating systems for computers market is cornered primarily by three solutions, Windows, Mac OS and GNU/Linux. Microsoft is trying to promote the adoption of Windows 8, Apple proposes OS X Lion and GNU/Linux has various distributions star and Ubuntu is one of the most prominent.

Now, if you're a traditional user of Windows and give the jump to Apple there will be many actions you have pre-programmed to perform on Windows computer and which, however, do not know to perform on Mac.

Therefore, I want to leave a little shortcut guide that is no solution to typical actions such as opening control panel, Setup networks or sound, Task Manager, among others.

this is a small detail comparison relationship. which it was designed for the purpose of that if you are going jump from Milk feeding Windows to Labour workout of Linux or fashion designing world of Mac .so from this small info graphic pic I think you understood that every interface has almost of all related items in it .

Read More

A small view about Parameter Manipulation attack like Hacking

Parameter Manipulation ?

Manipulating the data sent between the browser and the web application to an attacker's advantage has long been a simple but effective way to make applications do things in a way the user often shouldn't be able to. In a badly designed and developed web application, malicious users can modify things like prices in web carts, session tokens or values stored in cookies and even HTTP headers. 

No data sent to the browser can be relied upon to stay the same unless cryptographically protected at the application layer. Cryptographic protection in the transport layer (SSL) in no way protects one from attacks like parameter manipulation in which data is mangled before it hits the wire. Parameter tampering can often be done with: 

• Cookies
• Form Fields
• URL Query Strings
• HTTP Headers

Cookie Manipulation ?

Description

Cookies are the preferred method to maintain state in the stateless HTTP protocol. They are however also used as a convenient mechanism to store user preferences and other data including session tokens. Both persistent and non-persistent cookies, secure or insecure can be modified by the client and sent to the server with URL requests. Therefore any malicious user can modify cookie content to his advantage. There is a popular misconception that non-persistent cookies cannot be modified but this is not true; tools like Winhex are freely available. SSL also only protects the cookie in transit.

The extent of cookie manipulation depends on what the cookie is used for but usually ranges from session tokens to arrays that make authorization decisions. (Many cookies are Base64 encoded; this is an encoding scheme and offers no cryptographic protection).
Example from a real world example on a travel web site modified to protect the innocent (or stupid).

   Cookie: lang=en-us; ADMIN=no; y=1 ; time=10:30GMT ;
   

The attacker can simply modify the cookie to;

   Cookie: lang=en-us; ADMIN=yes; y=1 ; time=12:30GMT ;
   

Mitigation Techniques ?

One mitigation technique is to simply use one session token to reference properties stored in a server-side cache. This is by far the most reliable way to ensure that data is sane on return: simply do not trust user input for values that you already know. When an application needs to check a user property, it checks the userid with its session table and points to the users data variables in the cache / database. This is by far the correct way to architect a cookie based preferences solution.

Another technique involves building intrusion detection hooks to evaluate the cookie for any infeasible or impossible combinations of values that would indicate tampering. For instance, if the "administrator" flag is set in a cookie, but the userid value does not belong to someone on the development team.

The final method is to encrypt the cookie to prevent tampering. There are several ways to do this including hashing the cookie and comparing hashes when it is returned or a symmetric encryption , although server compromise will invalidate this approach and so response to penetration must include new key generation under this scheme.

HTTP Header Manipulation ?

Description

HTTP headers are control information passed from web clients to web servers on HTTP requests, and from web servers to web clients on HTTP responses. Each header normally consists of a single line of ASCII text with a name and a value. Sample headers from a POST request follow.

Host: www.someplace.org
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Lynx/2.8.4dev.9 libwww-FM/2.14
Referer: http://www.someplace.org/login.php
Content-type: application/x-www-form-urlencoded
Content-length: 49
   

Often HTTP headers are used by the browser and the web server software only. Most web applications pay no attention to them. However some web developers choose to inspect incoming headers, and in those cases it is important to realize that request headers originate at the client side, and they may thus be altered by an attacker.

Normal web browsers do not allow header modification. An attacker will have to write his own program (about 15 lines of perl code will do) to perform the HTTP request, or he may use one of several freely available proxies that allow easy modification of any data sent from the browser.

Example 1: The Referer header (note the spelling), which is sent by most browsers, normally contains the URL of the web page from which the request originated. Some web sites choose to check this header in order to make sure the request originated from a page generated by them, for example in the belief it prevents attackers from saving web pages, modifying forms, and posting them off their own computer. This security mechanism will fail, as the attacker will be able to modify the Referer header to look like it came from the original site.

Example 2: The Accept-Language header indicates the preferred language(s) of the user. A web application doing internationalization (i18n) may pick up the language label from the HTTP header and pass it to a database in order to look up a text. If the content of the header is sent verbatim to the database, an attacker may be able to inject SQL commands (see SQL injection) by modifying the header. Likewise, if the header content is used to build a name of a file from which to look up the correct language text, an attacker may be able to launch a path traversal attack.

Mitigation Techniques ?

Simply put headers cannot be relied upon without additional security measures. If a header originated server-side such as a cookie it can be cryptographically protected. If it originated client-side such as a referer it should not be used to make any security decisions.

Further Reading

For more information on headers, please see RFC 2616 which defines HTTP/1.1.

HTML Form Field Manipulation ?

Description

When a user makes selections on an HTML page, the selection is typically stored as form field values and sent to the application as an HTTP request (GET or POST). HTML can also store field values as Hidden Fields, which are not rendered to the screen by the browser but are collected and submitted as parameters during form submissions.

Whether these form fields are pre-selected (drop down, check boxes etc.), free form or hidden, they can all be manipulated by the user to submit whatever values he/she chooses. In most cases this is as simple as saving the page using "view source", "save", editing the HTML and re-loading the page in the web browser.

As an example an application uses a simple form to submit a username and password to a CGI for authentication using HTTP over SSL. The username and password form fields look like this.

  

Some developers try to prevent the user from entering long usernames and passwords by setting a form field value maxlength=(an integer) in the belief they will prevent the malicious user attempting to inject buffer overflows of overly long parameters. However the malicious user can simply save the page, remove the maxlength tag and reload the page in his browser. Other interesting form fields include disabled, readonly and value. As discussed earlier, data (and code) sent to clients must not be relied upon until in responses until it is vetted for sanity and correctness. Code sent to browsers is merely a set of suggestions and has no security value.

Hidden Form Fields represent a convenient way for developers to store data in the browser and are one of the most common ways of carrying data between pages in wizard type applications. All of the same rules apply to hidden forms fields as apply to regular form fields.
Example 2 - Take the same application. Behind the login form may have been the HTML tag;

 <input name="masteraccess" type="hidden" value="N">
   

By manipulating the hidden value to a Y, the application would have logged the user in as an Administrator. Hidden form fields are extensively used in a variety of ways and while it's easy to understand the dangers they still are found to be significantly vulnerable in the wild.

Mitigation Techniques ?

Instead of using hidden form fields, the application designer can simply use one session token to reference properties stored in a server-side cache. When an application needs to check a user property, it checks the session cookie with its session table and points to the user's data variables in the cache / database. This is by far the correct way to architect this problem.

If the above technique of using a session variable instead of a hidden field cannot be implemented, a second approach is as follows.

The name/value pairs of the hidden fields in a form can be concatenated together into a single string. A secret key that never appears in the form is also appended to the string. This string is called the Outgoing Form Message. An MD5 digest or other one-way hash is generated for the Outgoing Form Message. This is called the Outgoing Form Digest and it is added to the form as an additional hidden field.

When the form is submitted, the incoming name/value pairs are again concatenated along with the secret key into an Incoming Form Message. An MD5 digest of the Incoming Form Message is computed. Then the Incoming Form Digest is compared to the Outgoing Form Digest (which is submitted along with the form) and if they do not match, then a hidden field has been altered. Note, for the digests to match, the name/value pairs in the Incoming and Outgoing Form Messages must concatenated together in the exact same order both times.

This same technique can be used to prevent tampering with parameters in a URL. An additional digest parameter can be added to the URL query string following the same technique described above.

URL Manipulation ?

Description

URL Manipulation comes with all of the problems stated above about Hidden Form Fields, and creates some new problems as well.

HTML Forms may submit their results using one of two methods: GET or POST. If the method is GET, all form element names and their values will appear in the query string of the next URL the user sees. Tampering with hidden form fields is easy enough, but tampering with query strings is even easier. One need only look at the URL in the browser's address bar.

Take the following example; a web page allows the authenticated user to select one of his pre-populated accounts from a drop-down box and debit the account with a fixed unit amount. It's a common scenario. His/her choices are recorded by pressing the submit button. The page is actually storing the entries in form field values and submitting them using a form submit command. The command sends the following HTTP request. 

http://www.victim.com/example?accountnumber=12345&debitamount=1
   

A malicious user could construct his own account number and change the parameters as follows:

http://www.victim.com/example?accountnumber=67891&creditamount=999999999   

Thee new parameters would be sent to the application and be processed accordingly.

This seems remarkably obvious but has been the problem behind several well-published attacks including one where hackers bought tickets from the US to Paris for $25 and flew to hold a hacking convention. Another well-known electronic invitation service allowed users to guess the account ID and login as a specific user this way; a fun game for the terminally bored with voyeuristic tendencies.

Unfortunately, it isn't just HTML forms that present these problems. Almost all navigation done on the internet is through hyperlinks. When a user clicks on a hyperlink to navigate from one site to another, or within a single application, he is sending GET requests. Many of these requests will have a query string with parameters just like a form. And once again, a user can simply look in the "Address" window of his browser and change the parameter values.

Mitigation Techniques ?

Solving URL manipulation problems takes planning. Different techniques can be used in different situations. The best solution is to avoid putting parameters into a query string (or hidden form field).

When parameters need to be sent from a client to a server, they should be accompanied by a valid session token. The session token may also be a parameter, or a cookie. Session tokens have their own special security considerations described previously. In the example above, the application should not make changes to the account without first checking if the user associated with the session has permission to edit the account specified by the parameter "accountnumber". The script that processes a credit to an account cannot assume that access control decisions were made on previous application pages. Parameters should never be operated on unless the application can independently validate they were bound for and are authorized to be acted on.

However, a second form of tampering is also evident in the example. Notice that the creditamount is increased from 1 to 999999999. Imagine that the user doesn't tamper with the accountnumber but only with the amount. He may be crediting his own account with a very large sum instead of $1. Clearly this is a parameter that should simply not be present in the URL.

There are two reasons why a parameter should not be a URL (or in a form as a hidden field). The above example illustrates one reason - the parameter is one the user should not be able to set the value of. The second is if a parameter is one the user should not be able to see the value of. Passwords are a good example of the latter. Users's should not even see their own passwords in a URL because someone may be standing behind them and because browsers record URL histories. See Browser History Attack.

If a sensitive parameter cannot be removed from a URL, it must be cryptographically protected. Cryptographic protection can be implemented in one of two ways. The better method is to encrypt an entire query string (or all hidden form field values). This technique both prevents a user from setting the value and from seeing the value.

A second form of cryptographic protection is to add an additional parameter whose value is an MD5 digest of the URL query string (or hidden form fields) More details of this technique are described above in the section "HTML Form Field Manipulation". This method does not prevent a user from seeing a value, but it does prevent him from changing the value. 

Miscellaneous ?

Vendors Patches

Vulnerabilities are common within 3rd party tools and products that are installed as part of the web applications. These web-server, application server, e-comm suites, etc. are purchased from external vendors and installed as part of the site. The vendor typically addresses such vulnerabilities by supplying a patch that must be downloaded and installed as an update to the product at the customer's site.

A significant part of the web application is typically not customized and specific for a single web site but rather made up of standard products supplied by 3rd party vendors. Typically such products serve as the web server, application server, databases and more specific packages used in the different vertical markets. All such products have vulnerabilities that are discovered in an ongoing manner and in most cases disclosed directly to the vendor (although there are also cases in which the vulnerability is revealed to the public without disclosure to the vendor). The vendor will typically address the vulnerability by issuing a patch and making it available to the customers using the product, with or without revealing the full vulnerability. The patches are sometimes grouped in patch groups (or updates) that may be released periodically.

A vendors disclosure policy of vulnerabilities is of primary concern to those deploying ciritcal systems. Those in a procurement position should be very aware of the End User License Agreements (EULAs) under which vendors license their software. Very often these EULAs disclaim all liability on the part of the vendor, even in cases of serious neglect, leaving users with little or no recourse. Those deploying software distributed under these licenses are now fully liable for damage caused by the defects that may be a part of this code. Due to this state of affairs, it becomes ever more important that orginizations insist upon open discussion and disclosure of vulnerabilities in the software they deploy. Vendors have reputations at stake when new vulnerabilities are disclosed and many attempt to keep such problems quiet, thereby leaving their clients without adequate information in asessing their exposure to threats. This behaviour is unacceptable in a mature software industry and should not be tollerated. Furthermore, orginizations should take care to ensure that vendors do not attempt to squelch information needed to verify the validity and effectiveness of patches. While this might seem a frivilous concern at first glance, vendors have been known to try to limit distribution of this information in order to provide "security" through obscurity. Customers may be actively harmed in the meanwhile as Black Hats have more information about a problem than White Hats do, again imparing an organizations ability to assess its risk exposure.

The main issue with vendor patches is the latency between the disclosure of the vulnerability to the actual deployment of the patch in the production environment i.e. the patch latency and the total time needed to issue the patch by the vendor, download of the patch by the client, test of the patch in a QA or staging environment and finally full deployment in the production site. During all this time the site is vulnerable to attacks on this published vulnerability. This results in misuse of the patch releases to achieve opposite results by humans and more recently by worms such as CodeRed.

Most patches are released by the vendors only in their site and in many cases published only in internal mailing lists or sites. Sites and lists following such vulnerabilities and patches (such as bugtraq) do not serve as a central repository for all patches. The number of such patches for mainstream products is estimated at dozens a month.

The final critical aspect of patches is that they are not (in most cases) signed or containing a checksum causing them to be a potential source of Trojans in the system.

You should subscribe to vendors' security intelligence service for all software that forms part of your web application or a security infrastructure.

System Configuration

Server software is often complex, requiring much understanding of both the protocols involved and their internal workings to correctly configure. Unfortunantly software makes this task much more difficult by providing default configurations which are known to be vulnerable to devastating attacks. Often "sample" files and directories are installed by default which may provide attackers with ready-made attacks should problems be found in the sample files. While many vendors suggest removing these files by default, they put the onus of securing an "out of the box" installation on those deploying their product. A (very) few vendors attempt to provide secure defaults for their systems (the OpenBSD project being an example). Systems from these vendors often prove much less vulnerable to widespread attack, this approach to securing infrastructure appears to work very well and should be encouraged when discussing procurement with vendors.

If a vendor provides tools for managing and securing installations for your software, it may be worth evaluating these tools, however they will never be a full replacement for understanding how a system is designed to work and strictly managing configurations across your deployed base.

Understanding how system configuration affects security is crucial to effective risk management. Systems being deploying today rely on so many layers of software that a system may be compromised from vectors which may be difficult or impossible to predict. Risk management and threat analysis seeks to quantify this risk, minimize the impact of the inevitable failure, and provide means (other than technical) for compensating for threat exposure. Configuration management is a well understood piece of this puzzle, yet remains maddeningly difficult to implement well. As configurations and environmental factors may change over time, a system once well shielded by structural safeguards may become a weak link with very little outward indication that the risk inherent in a system has changed. Organizations will have to accept that configuration management is a continuing process and cannot simply be done once and let be. Effectively managing configurations can be a first step in putting in place the safeguards that allow systems to perform reliably in the face of concerted attack.

Comments in HTML ?

Description

It's amazing what one can find in comments. Comments placed in most source code aid readability and improve documented process. The practice of commenting has been carried over into the development of HTML pages, which are sent to the clients' browser. As a result information about the structure of the a web site or information intended only for the system owners or developers can sometimes be inadvertently revealed.

Comments left in HTML can come in many formats, some as simple as directory structures, others inform the potential attacker about the true location of the web root. Comments are sometimes left in from the HTML development stage and can contain debug information, cookie structures, problems associated with development and even developer names, emails and phone numbers.

Structured Comments - these appear in HTML source, usually at the top of the page or between the JavaScript and the remaining HTML, when a large development team has been working on the site for some time.

Automated Comments - many widely used page generation utilities and web usage software automatically adds signature comments into the HTML page. These will inform the attacker about the precise software packages (sometimes even down to the actual release) that is being used on the site. Known vulnerabilities in those packages can then be tried out against the site.

Unstructured Comments - these are one off comments made by programmers almost as an "aid memoir" during development. These can be particularly dangerous as they are not controlled in any way. Comments such as "The following hidden field must be set to 1 or XYZ.asp breaks" or "Don't change the order of these table fields" are a red flag to a potential attacker and sadly not uncommon.

Mitigation Techniques ?

For most comments a simple filter that strips comments before pages are pushed to the production server is all that is required. For Automated Comments an active filter may be required. It is good practice to tie the filtering process to sound deployment methodologies so that only known good pages are ever released to production.

Old, Backup and Un-referenced Files ?

Description

File / Application Enumeration is a common technique that is used to look for files or applications that may be exploitable or be useful in constructing an attack. These include known vulnerable files or applications, hidden or un-referenced files and applications and back-up / temp files.

File /Application enumeration uses the HTTP server response codes to determine if a file or application exists. A web server will typically return an HTTP 200 response code if the file exists and an HTTP 404 response code if the file does not exist. This enables an attacker to feed in lists of known vulnerable files and suspected applications or use some basic logic to map the file and application structure visible from the presentation layer.

Known Vulnerable Files - Obviously many known vulnerable files exist, and in fact looking for them is one of the most common techniques that commercial and free-ware vulnerability scanners use. Many people will focus their search on cgi's for example or server specific issues such as IIS problems. Many daemons install "sample" code in publicly accessible locations, which are often found to have security problems. Removing (or simply not installing) such default files cannot be recommended highly enough.

Hidden / Un-Referenced Files - Many web site administrators leave files on the web server such as sample files or default installation files. When the web content is published, these files remain accessible although are un-referenced by any HTML in the web. Many examples are notoriously insecure, demonstrating things like uploading files from a web interface for instance. If an attacker can guess the URL, then he is typically able to access the resource.

Back-Up Files / Temp Files - Many applications used to build HTML and things like ASP pages leave temp files and back-up files in directories. These often get up-loaded either manually in directory copies or automagically by site management modules of HTML authoring tools like Microsoft's Frontpage or Adobe Go-Live. Back-up files are also dangerous as many developers embed things into development HTML that they later remove for production. Emacs for instance writes a *.bak in many instances. Development staff turnover may also be an issue, and security through obscurity is always an ill-advised course of action.

Mitigation Techniques ?

Remove all sample files from your web server. Ensure that any unwanted or unused files are removed. Use a staging screening process to look for back-up files. A simple recursive file grep of all extensions that are not explicitly allowed is very effective.

Some web server / application servers that build dynamic pages will not return a 404 message to the browser, but instead return a page such as the site map. This confuses basic scanners into thinking that all files exist. Modern vulnerability scanners however can take a custom 404 and treat it as a vanilla 404 so this technique only slows progress.

Debug Commands ?

Description

Debug commands actually come in two distinct forms
Explicit Commands - this is where a name value pair has been left in the code or can be introduced as part of the URL to induce the server to enter debug mode. Such commands as "debug=on" or

"Debug=YES" can be placed on the URL like:

http://www.somewebsite.com/account_check?ID=8327dsddi8qjgqllkjdlas&Disp=no
   

Can be altered to:

http://www.somewebsite.com/account_check?debug=on&ID=8327dsddi8qjgqllkjdlas&Disp=no
   

The attacker observes the resultant server behavior. The debug construct can also be placed inside HTML code or JavaScript when a form is returned to the server, simply by adding another line element to the form construction, the result is the same as the command line attack above.

Implicit Commands - this is where seemingly innocuous elements on a page if altered have dramatic effects on the server. The original intent of these elements was to help the programmer modify the system into various states to allow a faster testing cycle time. These element are normally given obscure names such as "fubar1" or "mycheck" etc. These elements may appear in the source as: 

<!-- begins -->
<TABLE BORDER=0 ALIGN=CENTER CELLPADDING=1 CELLSPACING=0>>
<FORM METHOD=POST ACTION="http://some_poll.com/poll?1688591" TARGET="sometarget" FUBAR1="666">
<INPUT TYPE=HIDDEN NAME="Poll" VALUE="1122">
<!-- Question 1 -->
<TR>
<TD align=left colspan=2>
<INPUT TYPE=HIDDEN NAME="Question" VALUE="1">
<SPAN class="Story">
   

Finding debug elements is not easy, but once one is located it is usually tried across the entire web site by the potential hacker. As designers never intend for these commands to be used by normal users, the precautions preventing parameter tampering are usually not taken.

Debug commands have been known to remain in 3rd party code designed to operate the web site, such as web servers, database programs. Search the web for "Netscape Engineers are weenies" if you don't believe us!

Default Accounts ?

Description

Many "off the shelf" web applications typically have at least one user activated by default. This user, which is typically the administrator of the system, comes pre-configured on the system and in many cases has a standard password. The system can then be compromised by attempting access using these default values.

Web applications enable multiple default accounts on the system, for example: 

• Administrator accounts
• Test accounts
• Guest accounts

The accounts can be accessed from the web either using the standard access for all defined account or via special ports or parts of the application, such as administrator pages. The default accounts usually come with pre-configured default passwords whose value is widely known. Moreover, most applications do not force a change to the default password.

The attack on such default accounts can occur in two ways: 

• Attempt to use the default username/password assuming that it was not changed during the default installation.
• Enumeration over the password only since the user name of the account is known.

Once the password is entered or guessed then the attacker has access to the site according to the account's permissions, which usually leads in two major directions:

If the account was an administrator account then the attacker has partial or complete control over the application (and sometimes, the whole site) with the ability to perform any malicious action.

If the account was a demo or test account the attacker will use this account as a means of accessing and abusing the application logic exposed to that user and using it as a mean of progressing with the attack.

Mitigation Techniques ?

Always change out of the box installation of the application. Remove all unnecessary accounts, following security checklist, vendor or public. Disable remote access to the admin accounts on the application. Use hardening scripts provided by the application vendors and vulnerability scanners to find the open accounts before someone else does.copy source by (blackhatcrackers.blogspot)

Comment below for further details .  and Don't Forget to Like my Facebook page Techno world 

as usually this post is for completely educational purpose  and I did not take any responsibility of any misuse, Hacking email accounts is criminal activity and is punishable under cyber crime and you may get upto 40 years of imprisonment, if got caught in doing so. you will be solely responsible for any misuse that you do.

Read More