Dr Seuss The Lorax
A 12-year-old boy searches for the one thing that will enable him to win the affection of the girl of his dreams. To find it he must discover the story of the Lorax, the grumpy yet charming creature who fights to protect his world.
Advance SystemCare 5
Advanced SystemCare Free (formerly Advanced WindowsCare Personal) has a one-click approach to help protect, repair, clean, and optimize your PC. With over 100 MILLION downloads since 2006, this fantastic, award-winning, free PC repair software is a "must-have" tool for your computer. 100% safe with no adware, spyware, or viruses; a PC maintenance program that's incredibly easy to use.
Having conquered the Asian underworld, Don (Shah Rukh Khan) now has his sights set on European domination. In his way are the bosses of the existing European underworld and all law enforcement agencies. The action shifts from Kuala Lumpur to Berlin as Don must avoid assassination or arrest, whichever comes first, in order for his plan to succeed.
NFS THE RUN
It’s called The Run. Three thousand miles of unforgiving asphalt with no speed limits, no rules, and no allies. Armed with the hottest cars in the world, you'll battle a field of the most notorious drivers ever assembled, as dense city streets, icy mountain passes, and narrow canyons push your driving skills to the limit.
A young pickpocket in the New York subways, living a fast, free, lifestyle is confronted by a woman whom he had a one night affair with, she informs him that she is now pregnant with his child, he must now choose between continuing the lifestyle he lead or take responsibility for his actions.
Saturday, February 25, 2012
Tuesday, January 10, 2012
Saturday, December 31, 2011
1: Download and install Internet download manager.
2: Now close all the files of IDM and apply the patch by opening file named "SnDk&p.exe". Open this file click on Apply Patch and copy the Serial Key to register.
3: Open IDM Go to Registration Tab and click on Registration and Here Enter:
Name : [Any Name]
Email : [Any Fake email]
Serial Key : [Serial Key generated by the Patch]
Sunday, February 6, 2011
This paper assumes a working knowledge of basic shellcoding techniques, and x86 assembly, I will not rehash these in this paper. I hope to teach you some of the lesser known shellcoding techniques that I have picked up, which will allow you to write smaller and better shellcodes. I do not claim to have invented any of these techniques, except for the one that uses the div instruction.
The multiplicity of mul
This technique was originally developed by Sorbo of darkircop.net. The mul instruction may, on the surface, seem mundane, and it's purpose obvious. However, when faced with the difficult challenge of shrinking your shellcode, it proves to be quite useful. First some background information on the mul instruction itself.
mul performs an unsigned multiply of two integers. It takes only one operand, the other is implicitly specified by the %eax register. So, a common mul instruction might look something like this:
This would multiply the value stored in %eax by the operand of mul, which in this case would be 10*10. The result is then implicitly stored in EDX:EAX. The result is stored over a span of two registers because it has the potential to be considerably larger than the previous value, possibly exceeding the capacity of a single register(this is also how floating points are stored in some cases, as an interesting sidenote).
So, now comes the ever-important question. How can we use these attributes to our advantage when writing shellcode? Well, let's think for a second, the instruction takes only one operand, therefore, since it is a very common instruction, it will generate only two bytes in our final shellcode. It multiplies whatever is passed to it by the value stored in %eax, and stores the value in both %edx and %eax, completely overwriting the contents of both registers, regardless of whether it is necessary to do so, in order to store the result of the multiplication. Let's put on our mathematician hats for a second, and consider this, what is the only possible result of a multiplication by 0? The answer, as you may have guessed, is 0. I think it's about time for some example code, so here it is:
What is this shellcode doing? Well, it 0's out the %ecx register using the xor instruction, so we now know that %ecx is 0. Then it does a mul %ecx, which as we just learned, multiplies it's operand by the value in %eax, and then proceeds to store the result of this multiplication in EDX:EAX. So, regardless of %eax's previous contents, %eax must now be 0. However that's not all, %edx is 0'd now too, because, even though no overflow occurs, it still overwrites the %edx register with the sign bit(left-most bit) of %eax. Using this technique we can zero out three registers in only three bytes, whereas by any other method(that I know of) it would have taken at least six.
The div instruction
Div is very similar to mul, in that it takes only one operand and implicitly divides the operand by the value in %eax. Also like, mul it stores the result of the divide in %eax. Again, we will require the mathematical side of our brains to figure out how we can take advantage of this instruction. But first, let's think about what is normally stored in the %eax register. The %eax register holds the return value of functions and/or syscalls. Most syscalls that are used in shellcoding will return -1(on failure) or a positive value of some kind, only rarely will they return 0(though it does occur). So, if we know that after a syscall is performed, %eax will have a non-zero value, and that the instruction divl %eax will divide %eax by itself, and then store the result in %eax, we can say that executing the divl %eax instruction after a syscall will put the value 1 into %eax. So...how is this applicable to shellcoding? Well, their is another important thing that %eax is used for, and that is to pass the specific syscall that you would like to call to int $0x80. It just so happens that the syscall that corresponds to the value 1 is exit(). Now for an example:
mov %esp, %ebx
movb $0xb, %al #execve() syscall, doesn't return at all unless it fails, in which case it returns -1
divl %eax # -1 / -1 = 1
Now, we have a 3 byte exit function, where as before it was 5 bytes. However, there is a catch, what if a syscall does return 0? Well in the odd situation in which that could happen, you could do many different things, like inc %eax, dec %eax, not %eax anything that will make %eax non-zero. Some people say that exit's are not important in shellcode, because your code gets executed regardless of whether or not it exits cleanly. They are right too, if you really need to save 3 bytes to fit your shellcode in somewhere, the exit() isn't worth keeping. However, when your code does finish, it will try to execute whatever was after your last instruction, which will most likely produce a SIG ILL(illegal instruction) which is a rather odd error, and will be logged by the system. So, an exit() simply adds an extra layer of stealth to your exploit, so that even if it fails or you can't wipe all the logs, at least this part of your presence will be clear.
Unlocking the power of leal
The leal instruction is an often neglected instruction in shellcode, even though it is quite useful. Consider this short piece of shellcode.
This will load the value 17 into eax, and clear all of the extraneous bits of eax. This occurs because the leal instruction loads a variable of the type long into it's desitination operand. In it's normal usage, this would load the address of a variable into a register, thus creating a pointer of sorts. However, since ecx is 0'd and 0+17=17, we load the value 17 into eax instead of any kind of actual address. In a normal shellcode we would do something like this, to accomplish the same thing:
I can hear you saying, but that shellcode is a byte shorter than the leal one, and you're quite right. However, in a real shellcode you may already have to 0 out a register like ecx(or any other register), so the xorl instruction in the leal shellcode isn't counted. Here's an example:
Both of these shellcodes call setuid(0), but one does it in 7 bytes while the other does it in 8. Again, I hear you saying but that's only one byte it doesn't make that much of a difference, and you're right, here it doesn't make much of a difference(except for in shellcode-size pissing contests =p), but when applied to much larger shellcodes, which have many function calls and need to do things like this frequently, it can save quite a bit of space.
A Web Standards Checklist, How to make a proper website
A web standards checklist
The term web standards can mean different things to different people. For some, it is 'table-free sites', for others it is 'using valid code'. However, web standards are much broader than that. A site built to web standards should adhere to standards (HTML, XHTML, XML, CSS, XSLT, DOM, MathML, SVG etc) and pursue best practices (valid code, accessible code, semantically correct code, user-friendly URLs etc).
In other words, a site built to web standards should ideally be lean, clean, CSS-based, accessible, usable and search engine friendly.
About the checklist
This is not an uber-checklist. There are probably many items that could be added. More importantly, it should not be seen as a list of items that must be addressed on every site that you develop. It is simply a guide that can be used:
* to show the breadth of web standards
* as a handy tool for developers during the production phase of websites
* as an aid for developers who are interested in moving towards web standards
1.Quality of code
1. Does the site use a correct Doctype?
2. Does the site use a Character set?
3. Does the site use Valid (X)HTML?
4. Does the site use Valid CSS?
5. Does the site use any CSS hacks?
6. Does the site use unnecessary classes or ids?
7. Is the code well structured?
8. Does the site have any broken links?
9. How does the site perform in terms of speed/page size?
2. Degree of separation between content and presentation
1. Does the site use CSS for all presentation aspects (fonts, colour, padding, borders etc)?
2. Are all decorative images in the CSS, or do they appear in the (X)HTML?
3. Accessibility for users
1. Are "alt" attributes used for all descriptive images?
2. Does the site use relative units rather than absolute units for text size?
3. Do any aspects of the layout break if font size is increased?
4. Does the site use visible skip menus?
5. Does the site use accessible forms?
6. Does the site use accessible tables?
7. Is there sufficient colour brightness/contrasts?
8. Is colour alone used for critical information?
9. Is there delayed responsiveness for dropdown menus (for users with reduced motor skills)?
10. Are all links descriptive (for blind users)?
4. Accessibility for devices
1. Does the site work acceptably across modern and older browsers?
2. Is the content accessible with CSS switched off or not supported?
3. Is the content accessible with images switched off or not supported?
4. Does the site work in text browsers such as Lynx?
5. Does the site work well when printed?
6. Does the site work well in Hand Held devices?
7. Does the site include detailed metadata?
8. Does the site work well in a range of browser window sizes?
5. Basic Usability
1. Is there a clear visual hierarchy?
2. Are heading levels easy to distinguish?
3. Does the site have easy to understand navigation?
4. Does the site use consistent navigation?
5. Are links underlined?
6. Does the site use consistent and appropriate language?
7. Do you have a sitemap page and contact page? Are they easy to find?
8. For large sites, is there a search tool?
9. Is there a link to the home page on every page in the site?
10. Are visited links clearly defined with a unique colour?
6. Site management
1. Does the site have a meaningful and helpful 404 error page that works from any depth in the site?
2. Does the site use friendly URLs?
3. Do your URLs work without "www"?
4. Does the site have a favicon?
1. Quality of code
1.1 Does the site use a correct Doctype?
A doctype (short for 'document type declaration') informs the validator which version of (X)HTML you're using, and must appear at the very top of every web page. Doctypes are a key component of compliant web pages: your markup and CSS won't validate without them.
1.2 Does the site use a Character set?
If a user agent (eg. a browser) is unable to detect the character encoding used in a Web document, the user may be presented with unreadable text. This information is particularly important for those maintaining and extending a multilingual site, but declaring the character encoding of the document is important for anyone producing XHTML/HTML or CSS.
1.3 Does the site use Valid (X)HTML?
Valid code will render faster than code with errors. Valid code will render better than invalid code. Browsers are becoming more standards compliant, and it is becoming increasingly necessary to write valid and standards compliant HTML.
1.4 Does the site use Valid CSS?
You need to make sure that there aren't any errors in either your HTML or your CSS, since mistakes in either place can result in botched document appearance.
1.5 Does the site use any CSS hacks?
Basically, hacks come down to personal choice, the amount of knowledge you have of workarounds, the specific design you are trying to achieve.
1.6 Does the site use unnecessary classes or ids?
I've noticed that developers learning new skills often end up with good CSS but poor XHTML. Specifically, the HTML code tends to be full of unnecessary divs and ids. This results in fairly meaningless HTML and bloated style sheets.
1.7 Is the code well structured?
Semantically correct markup uses html elements for their given purpose. Well structured HTML has semantic meaning for a wide range of user agents (browsers without style sheets, text browsers, PDAs, search engines etc.)
1.8 Does the site have any broken links?
Broken links can frustrate users and potentially drive customers away. Broken links can also keep search engines from properly indexing your site.
1.9 How does the site perform in terms of speed/page size?
Don't make me wait... That's the message users give us in survey after survey. Even broadband users can suffer the slow-loading blues.
2. Degree of separation between content and presentation
2.1 Does the site use CSS for all presentation aspects (fonts, colour, padding, borders etc)?
Use style sheets to control layout and presentation.
2.2 Are all decorative images in the CSS, or do they appear in the (X)HTML?
The aim for web developers is to remove all presentation from the html code, leaving it clean and semantically correct.
3. Accessibility for users
3.1 Are "alt" attributes used for all descriptive images?
Provide a text equivalent for every non-text element
3.2 Does the site use relative units rather than absolute units for text size?
Use relative rather than absolute units in markup language attribute values and style sheet property values'.
3.3 Do any aspects of the layout break if font size is increased?
Try this simple test. Look at your website in a browser that supports easy incrementation of font size. Now increase your browser's font size. And again. And again... Look at your site. Does the page layout still hold together? It is dangerous for developers to assume that everyone browses using default font sizes.
3.4 Does the site use visible skip menus?
A method shall be provided that permits users to skip repetitive navigation links.
Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group.
...blind visitors are not the only ones inconvenienced by too many links in a navigation area. Recall that a mobility-impaired person with poor adaptive technology might be stuck tabbing through that morass.
3.5 Does the site use accessible forms?
Forms aren't the easiest of things to use for people with disabilities. Navigating around a page with written content is one thing, hopping between form fields and inputting information is another.
3.6 Does the site use accessible tables?
For data tables, identify row and column headers... For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.
3.7 Is there sufficient colour brightness/contrasts?
Ensure that foreground and background colour combinations provide sufficient contrast when viewed by someone having colour deficits.
3.8 Is colour alone used for critical information?
Ensure that all information conveyed with colour is also available without colour, for example from context or markup.
There are basically three types of colour deficiency; Deuteranope (a form of red/green colour deficit), Protanope (another form of red/green colour deficit) and Tritanope (a blue/yellow deficit- very rare).
3.9 Is there delayed responsiveness for dropdown menus?
Users with reduced motor skills may find dropdown menus hard to use if responsiveness is set too fast.
3.10 Are all links descriptive?
Link text should be meaningful enough to make sense when read out of context - either on its own or as part of a sequence of links. Link text should also be terse.
4. Accessibility for devices.
4.1 Does the site work acceptably across modern and older browsers?
Before starting to build a CSS-based layout, you should decide which browsers to support and to what level you intend to support them.
4.2 Is the content accessible with CSS switched off or not supported?
Some people may visit your site with either a browser that does not support CSS or a browser with CSS switched off. In content is structured well, this will not be an issue.
4.3 Is the content accessible with images switched off or not supported?
Some people browse websites with images switched off - especially people on very slow connections. Content should still be accessible for these people.
4.4 Does the site work in text browsers such as Lynx?
This is like a combination of images and CSS switched off. A text-based browser will rely on well structured content to provide meaning.
4.5 Does the site work well when printed?
You can take any (X)HTML document and simply style it for print, without having to touch the markup.
4.6 Does the site work well in Hand Held devices?
This is a hard one to deal with until hand held devices consistently support their correct media type. However, some layouts work better in current hand-held devices. The importance of supporting hand held devices will depend on target audiences.
4.7 Does the site include detailed metadata?
Metadata is machine understandable information for the web
Metadata is structured information that is created specifically to describe another resource. In other words, metadata is 'data about data'.
4.8 Does the site work well in a range of browser window sizes?
It is a common assumption amongst developers that average screen sizes are increasing. Some developers assume that the average screen size is now 1024px wide. But what about users with smaller screens and users with hand held devices? Are they part of your target audience and are they being disadvantaged?
5. Basic Usability
5.1 Is there a clear visual hierarchy?
Organise and prioritise the contents of a page by using size, prominence and content relationships.
5.2 Are heading levels easy to distinguish?
Use header elements to convey document structure and use them according to specification.
5.3 Is the site's navigation easy to understand?
Your navigation system should give your visitor a clue as to what page of the site they are currently on and where they can go next.
5.4 Is the site's navigation consistent?
If each page on your site has a consistent style of presentation, visitors will find it easier to navigate between pages and find information
5.5 Does the site use consistent and appropriate language?
The use of clear and simple language promotes effective communication. Trying to come across as articulate can be as difficult to read as poorly written grammar, especially if the language used isn't the visitor's primary language.
5.6 Does the site have a sitemap page and contact page? Are they easy to find?
Most site maps fail to convey multiple levels of the site's information architecture. In usability tests, users often overlook site maps or can't find them. Complexity is also a problem: a map should be a map, not a navigational challenge of its own.
5.7 For large sites, is there a search tool?
While search tools are not needed on smaller sites, and some people will not ever use them, site-specific search tools allow users a choice of navigation options.
5.8 Is there a link to the home page on every page in the site?
Some users like to go back to a site's home page after navigating to content within a site. The home page becomes a base camp for these users, allowing them to regroup before exploring new content.
5.9 Are links underlined?
To maximise the perceived affordance of clickability, colour and underline the link text. Users shouldn't have to guess or scrub the page to find out where they can click.
5.10 Are visited links clearly defined?
Most important, knowing which pages they've already visited frees users from unintentionally revisiting the same pages over and over again.
6. Site management
6.1 Does the site have a meaningful and helpful 404 error page that works from any depth in the site?
You've requested a page - either by typing a URL directly into the address bar or clicking on an out-of-date link and you've found yourself in the middle of cyberspace nowhere. A user-friendly website will give you a helping hand while many others will simply do nothing, relying on the browser's built-in ability to explain what the problem is.
6.2 Does the site use friendly URLs?
Most search engines (with a few exceptions - namely Google) will not index any pages that have a question mark or other character (like an ampersand or equals sign) in the URL... what good is a site if no one can find it?
One of the worst elements of the web from a user interface standpoint is the URL. However, if they're short, logical, and self-correcting, URLs can be acceptably usable
6.3 Does the site's URL work without "www"?
While this is not critical, and in some cases is not even possible, it is always good to give people the choice of both options. If a user types your domain name without the www and gets no site, this could disadvantage both the user and you.
6.4 Does the site have a favicon?
A Favicon is a multi-resolution image included on nearly all professionally developed sites. The Favicon allows the webmaster to further promote their site, and to create a more customized appearance within a visitor's browser.
Favicons are definitely not critical. However, if they are not present, they can cause 404 errors in your logs (site statistics). Browsers like IE will request them from the server when a site is bookmarked. If a favicon isn't available, a 404 error may be generated. Therefore, having a favicon could cut down on favicon specific 404 errors. The same is true of a 'robots.txt' file.