Ganav

Sa nu ai incredere in nimic ce vine din Africa. Desi este contrar curentelor politice actuale acele fiinte nu intrunesc atributele necesare unor fiinte umane capabile sa functioneze intr-o societate civilizata.

TC pana vine cu un update.

Ar fi foarte indicat sa spui si in ce domeniu sa aiba pregatire, ce vrei sa ii dai de lucru si cam cat si cum ai fi dispus sa-l platesti. Te rog specifica aceste detalii in post-ul tau.

Simplu. Iti trebuie intai un mijloc de a map-a(a stabili o relatie) intre simbolurile grafice(poza) si simboluri logice(operanzi si operatori). Pentru aceasta poti folosi un detector de tip SIFT/SURF pentru a extrage punctele cheie din imagini. Acestea se compara intr-un mod euristic cu un set de simboluri existent in memoria aplicatiei. Este probabil ca aceasta etapa sa nu fie necesara intrucat font-ul folosit este unul de tip standard. Pentru latura matematica ne ajuta google: http://en.wikipedia.org/wiki/Recursive_descent_parser

Interesant. Stie sa rezolve si sisteme de ecuatii diferentiale de ordin n, unde n este un numar natural care poate varia. Oare cum se descurca cu calculul integral? Cum calculeaza o integrala nedefinita de ordin n unde din nou n poate varia.

Mare grija sa nu se ajunga la discutii despre frauda. Altminteri vom inchide thread-ul si vom fi nevoiti sa dam cateva ban-uri. Acum, abordeaza problema din punct de vedere logic. In ceea ce ai scris pana acum deducem ca tu ai un amic care la randul sau are o cunostiinta care are un statut economic favorabil(cel putin din modul in care l-ai descris raportat la punctul tau de vedere). Poti sa iti pui urmatoarele intrebari: Ce pregatire are persoana respectiva(liceu, facultate, loc de munca, etc.)? De cand o cunoaste amicul tau? Care sunt persoanele pe care le cunosti care la randul lor cunosc "cunostiinta" in cauza? Intreaba persoana daca mai are ceva de lucru pentru tine(sau voi)? Astfel, vei afla mai multe despre posibilele surse de venit. Are persoana respectiva o prezenta pe divers medii sociale(twitter, facebook, etc.)? Poti sa-i formulezi o intrebare asemanatoare cu: am xxxx euro. Tu in locul meu in ce i-ai investi si de ce? Imprieteneste-te cu acea persoana. Ai mentioanat ca se ocupa de sport(sala). Cauta sa afli unde si aboneaza-te si tu.

Sa vedem ce are @filatdegarda de spus.

TC

Probabil este conduita scolii respective. Nu mi se pare in neregula; si eu am fost obligat sa port uniforma(cred ca si acum am undeva camasuta in vreun dulap). Acum studiez in Germania si am vazut tot felul de specimene urbane: multi imbracati in garderoba hip-hop(este destul de practica intrucat mai matura strazile cand se deplaseaza). Altii insa isi bat cuie in capul acoperit de par vopsit in toate culorile curcubeului. Sincer nu mi-as dori sa vad asa ceva la noi. In Suedia travestitii sunt incurajati sa se manifeste si sa ii influenteze pe cei din jur cu mentaliatea lor. Eu iti spun sa te tii de invatat si sa nu te preocupi de astfel de detalii. Eventual sa incerci sa imbunatatesti scoala din punct de vedere profesional(carti mai bune, explicatii mai clare, etc.).

Nu jucati la forex. Sunt sanse foarte mari sa pierdeti banii pe care i-ati investit.

Nu este foarte clar. Prima poza este din 2012 parca si arata un membru al unei persoane. Celelate stiri sustin ca victima ar fi fost sugrmata.

Te referi la coailii? Il gasesti aici: https://rstforums.com/forum/89745-coailii-stealer.rst

Dupa cum spunea si @aelius plecarea de la Ubuntu o consider gresita. Sistemul este extrem de instabil si plin de bug-uri(uneori operatia de update poate fi o adevarata aventura(pentru mine se traduce intr-un weekend pierdut); x-server este foarte fragil). Ce as propune este sa luam toate tool-urile de pe kali, archlinux, backtrack si sa le includem intr-o singura imagine. Este absurd sa scrii un nucleu de la zero. Pentru cei curiosi, kernel-urile sunt printre cele mai complexe sisteme create de om rivalizand in complexitate o statie spatiala sau un portavion de ultima generatie. S-ar putea folosi acest thread pentru a face un brainstorm-ing pentru ce sa se includa/omita in imagine.

"Nu conteaza cine voteaza, conteaza cine numara voturile" I.V. Stalin.

Mostrele, cel putin dupa definitie, sunt gratuite. Apropos ce dimensiuni au?

A Simple Makefile Tutorial

O scurta cautare pe google dupa Paul Nielsen duce la urmatorul link: 7 Cool and Unique Business Card Designs Practic card-ul de business arata un numar de telefon o data ce este intins. Poza de mai sus este modificata iar acesta afiseaza o valoare binara 01100110. In a treia poza(stanga jos avem o matrice) formata din puncte albe si negre(valori binare). 0110110 in baza 10 este 102 care este caracterul 'f' in ASCII. Punctele albe/negre ne dau celelalte caractere.

Nu descarcati programe de la utilizatori noi care nu au suficienta activitate pe forum. Mai mult ca sigur ca este infectat acel executabil.

1. Sunt foarte multe conturi nereglate intre PDL si PSD. Ponta isi va petrece mandatul ca si marioneta a altora, conturile fiind astfel reglate prin el. Vom participa la nenumarate scandaluri si miselii ieftine. Cine nu ar vrea asta?

Use prepared statements and parameterized queries. These are SQL statements that are sent to and parsed by the database server separately from any parameters. This way it is impossible for an attacker to inject malicious SQL. You basically have two options to achieve this: Using PDO: $stmt = $pdo->prepare('SELECT * FROM employees WHERE name = :name'); $stmt->execute(array('name' => $name)); foreach ($stmt as $row) { // do something with $row } Using MySQLi: $stmt = $dbConnection->prepare('SELECT * FROM employees WHERE name = ?'); $stmt->bind_param('s', $name); $stmt->execute(); $result = $stmt->get_result(); while ($row = $result->fetch_assoc()) { // do something with $row } PDO Note that when using PDO to access a MySQL database real prepared statements are not used by default. To fix this you have to disable the emulation of prepared statements. An example of creating a connection using PDO is: $dbConnection = new PDO('mysql:dbname=dbtest;host=127.0.0.1;charset=utf8', 'user', 'pass'); $dbConnection->setAttribute(PDO::ATTR_EMULATE_PREPARES, false); $dbConnection->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); In the above example the error mode isn't strictly necessary, but it is advised to add it. This way the script will not stop with a Fatal Error when something goes wrong. And it gives the developer the chance to catch any error(s) which are thrown as PDOExceptions. What is mandatory however is the first setAttribute() line, which tells PDO to disable emulated prepared statements and use real prepared statements. This makes sure the statement and the values aren't parsed by PHP before sending it to the MySQL server (giving a possible attacker no chance to inject malicious SQL). Although you can set the charset in the options of the constructor, it's important to note that 'older' versions of PHP (< 5.3.6) silently ignored the charset parameter in the DSN. Explanation What happens is that the SQL statement you pass to prepare is parsed and compiled by the database server. By specifying parameters (either a ? or a named parameter like :name in the example above) you tell the database engine where you want to filter on. Then when you call execute, the prepared statement is combined with the parameter values you specify. The important thing here is that the parameter values are combined with the compiled statement, not an SQL string. SQL injection works by tricking the script into including malicious strings when it creates SQL to send to the database. So by sending the actual SQL separately from the parameters, you limit the risk of ending up with something you didn't intend. Any parameters you send when using a prepared statement will just be treated as strings (although the database engine may do some optimization so parameters may end up as numbers too, of course). In the example above, if the $name variable contains 'Sarah'; DELETE FROM employees the result would simply be a search for the string "'Sarah'; DELETE FROM employees", and you will not end up with an empty table. Another benefit with using prepared statements is that if you execute the same statement many times in the same session it will only be parsed and compiled once, giving you some speed gains. Oh, and since you asked about how to do it for an insert, here's an example (using PDO): $preparedStatement = $db->prepare('INSERT INTO table (column) VALUES (:column)'); $preparedStatement->execute(array('column' => $unsafeValue)); You've got two options - escaping the special characters in your unsafe_variable, or using a parameterized query. Both would protect you from SQL injection. The parameterized query is considered the better practice, but escaping characters in your variable will require fewer changes. We'll do the simpler string escaping one first. //Connect $unsafe_variable = $_POST["user-input"]; $safe_variable = mysql_real_escape_string($unsafe_variable); mysql_query("INSERT INTO table (column) VALUES ('" . $safe_variable . "')"); //Disconnect See also, the details of the mysql_real_escape_string function. Warning: As of PHP 5.5.0 mysql_real_escape_string and the mysql extension are deprecated. Please use mysqli extension and mysqli::escape_string function instead To use the parameterized query, you need to use MySQLi rather than the MySQL functions. To rewrite your example, we would need something like the following. <?php $mysqli = new mysqli("server", "username", "password", "database_name"); // TODO - Check that connection was successful. $unsafe_variable = $_POST["user-input"]; $stmt = $mysqli->prepare("INSERT INTO table (column) VALUES (?)"); // TODO check that $stmt creation succeeded // "s" means the database expects a string $stmt->bind_param("s", $unsafe_variable); $stmt->execute(); $stmt->close(); $mysqli->close(); ?> The key function you'll want to read up on there would be mysqli::prepare. Also, as others have suggested, you may find it useful/easier to step up a layer of abstraction with something like PDO. Please note that the case you asked about is a fairly simple one, and that more complex cases may require more complex approaches. In particular: If you want to alter the structure of the SQL based on user input, parameterised queries are not going to help, and the escaping required is not covered by mysql_real_escape_string. In this kind of case you would be better off passing the user's input through a whitelist to ensure only 'safe' values are allowed through. If you use integers from user input in a condition and take the mysql_real_escape_string approach, you will suffer from the problem described by Polynomial in the comments below. This case is trickier because integers would not be surrounded by quotes, so you could deal with by validating that the user input contains only digits. There are likely other cases I'm not aware of. You might find Home - Web Application Security Consortium a useful resource on some of the more subtle problems you can encounter. Sursa: mysql - How can I prevent SQL-injection in PHP? - Stack Overflow

man dig: DIG(1) BIND9 DIG(1) NAME dig - DNS lookup utility SYNOPSIS dig @server name type where: server is the name or IP address of the name server to query. This can be an IPv4 address in dotted-decimal notation or an IPv6 address in colon-delimited notation. When the supplied server argument is a hostname, dig resolves that name before querying that name server. If no server argument is provided, dig consults /etc/resolv.conf; if an address is found there, it queries the name server at that address. If either of the -4 or -6 options are in use, then only addresses for the corresponding transport will be tried. If no usable addresses are found, dig will send the query to the local host. The reply from the name server that responds is displayed. name is the name of the resource record that is to be looked up. type indicates what type of query is required — ANY, A, MX, SIG, etc. type can be any valid query type. If no type argument is supplied, dig will perform a lookup for an A record. OPTIONS The -b option sets the source IP address of the query to address. This must be a valid address on one of the host's network interfaces or "0.0.0.0" or "::". An optional port may be specified by appending "#<port>" The default query class (IN for internet) is overridden by the -c option. class is any valid class, such as HS for Hesiod records or CH for Chaosnet records. The -f option makes dig operate in batch mode by reading a list of lookup requests to process from the file filename. The file contains a number of queries, one per line. Each entry in the file should be organized in the same way they would be presented as queries to dig using the command-line interface. The -m option enables memory usage debugging. If a non-standard port number is to be queried, the -p option is used. port# is the port number that dig will send its queries instead of the standard DNS port number 53. This option would be used to test a name server that has been configured to listen for queries on a non-standard port number. The -4 option forces dig to only use IPv4 query transport. The -6 option forces dig to only use IPv6 query transport. The -t option sets the query type to type. It can be any valid query type which is supported in BIND 9. The default query type is "A", unless the -x option is supplied to indicate a reverse lookup. A zone transfer can be requested by specifying a type of AXFR. When an incremental zone transfer (IXFR) is required, type is set to ixfr=N. The incremental zone transfer will contain the changes made to the zone since the serial number in the zone's SOA record was N. The -q option sets the query name to name. This useful do distinguish the name from other arguments. Reverse lookups — mapping addresses to names — are simplified by the -x option. addr is an IPv4 address in dotted-decimal notation, or a colon-delimited IPv6 address. When this option is used, there is no need to provide the name, class and type arguments. dig automatically performs a lookup for a name like 11.12.13.10.in-addr.arpa and sets the query type and class to PTR and IN respectively. By default, IPv6 addresses are looked up using nibble format under the IP6.ARPA domain. To use the older RFC1886 method using the IP6.INT domain specify the -i option. Bit string labels (RFC2874) are now experimental and are not attempted. To sign the DNS queries sent by dig and their responses using transaction signatures (TSIG), specify a TSIG key file using the -k option. You can also specify the TSIG key itself on the command line using the -y option; hmac is the type of the TSIG, default HMAC-MD5, name is the name of the TSIG key and key is the actual key. The key is a base-64 encoded string, typically generated by dnssec-keygen(8). Caution should be taken when using the -y option on multi-user systems as the key can be visible in the output from ps(1) or in the shell's history file. When using TSIG authentication with dig, the name server that is queried needs to know the key and algorithm that is being used. In BIND, this is done by providing appropriate key and server statements in named.conf. QUERY OPTIONS dig provides a number of query options which affect the way in which lookups are made and the results displayed. Some of these set or reset flag bits in the query header, some determine which sections of the answer get printed, and others determine the timeout and retry strategies. Each query option is identified by a keyword preceded by a plus sign (+). Some keywords set or reset an option. These may be preceded by the string no to negate the meaning of that keyword. Other keywords assign values to options like the timeout interval. They have the form +keyword=value. The query options are: +[no]tcp Use [do not use] TCP when querying name servers. The default behavior is to use UDP unless an AXFR or IXFR query is requested, in which case a TCP connection is used. +[no]vc Use [do not use] TCP when querying name servers. This alternate syntax to +[no]tcp is provided for backwards compatibility. The "vc" stands for "virtual circuit". +[no]ignore Ignore truncation in UDP responses instead of retrying with TCP. By default, TCP retries are performed. +domain=somename Set the search list to contain the single domain somename, as if specified in a domain directive in /etc/resolv.conf, and enable search list processing as if the +search option were given. +[no]search Use [do not use] the search list defined by the searchlist or domain directive in resolv.conf (if any). The search list is not used by default. +[no]showsearch Perform [do not perform] a search showing intermediate results. +[no]defname Deprecated, treated as a synonym for +[no]search +[no]aaonly Sets the "aa" flag in the query. +[no]aaflag A synonym for +[no]aaonly. +[no]adflag Set [do not set] the AD (authentic data) bit in the query. This requests the server to return whether all of the answer and authority sections have all been validated as secure according to the security policy of the server. AD=1 indicates that all records have been validated as secure and the answer is not from a OPT-OUT range. AD=0 indicate that some part of the answer was insecure or not validated. This bit is set by default. +[no]cdflag Set [do not set] the CD (checking disabled) bit in the query. This requests the server to not perform DNSSEC validation of responses. +[no]cl Display [do not display] the CLASS when printing the record. +[no]ttlid Display [do not display] the TTL when printing the record. +[no]recurse Toggle the setting of the RD (recursion desired) bit in the query. This bit is set by default, which means dig normally sends recursive queries. Recursion is automatically disabled when the +nssearch or +trace query options are used. +[no]nssearch When this option is set, dig attempts to find the authoritative name servers for the zone containing the name being looked up and display the SOA record that each name server has for the zone. +[no]trace Toggle tracing of the delegation path from the root name servers for the name being looked up. Tracing is disabled by default. When tracing is enabled, dig makes iterative queries to resolve the name being looked up. It will follow referrals from the root servers, showing the answer from each server that was used to resolve the lookup. +dnssec is also set when +trace is set to better emulate the default queries from a nameserver. +[no]cmd Toggles the printing of the initial comment in the output identifying the version of dig and the query options that have been applied. This comment is printed by default. +[no]short Provide a terse answer. The default is to print the answer in a verbose form. +[no]identify Show [or do not show] the IP address and port number that supplied the answer when the +short option is enabled. If short form answers are requested, the default is not to show the source address and port number of the server that provided the answer. +[no]comments Toggle the display of comment lines in the output. The default is to print comments. +[no]rrcomments Toggle the display of per-record comments in the output (for example, human-readable key information about DNSKEY records). The default is not to print record comments unless multiline mode is active. +split=W Split long hex- or base64-formatted fields in resource records into chunks of W characters (where W is rounded up to the nearest multiple of 4). +nosplit or +split=0 causes fields not to be split at all. The default is 56 characters, or 44 characters when multiline mode is active. +[no]stats This query option toggles the printing of statistics: when the query was made, the size of the reply and so on. The default behavior is to print the query statistics. +[no]qr Print [do not print] the query as it is sent. By default, the query is not printed. +[no]question Print [do not print] the question section of a query when an answer is returned. The default is to print the question section as a comment. +[no]answer Display [do not display] the answer section of a reply. The default is to display it. +[no]authority Display [do not display] the authority section of a reply. The default is to display it. +[no]additional Display [do not display] the additional section of a reply. The default is to display it. +[no]all Set or clear all display flags. +time=T Sets the timeout for a query to T seconds. The default timeout is 5 seconds. An attempt to set T to less than 1 will result in a query timeout of 1 second being applied. +tries=T Sets the number of times to try UDP queries to server to T instead of the default, 3. If T is less than or equal to zero, the number of tries is silently rounded up to 1. +retry=T Sets the number of times to retry UDP queries to server to T instead of the default, 2. Unlike +tries, this does not include the initial query. +ndots=D Set the number of dots that have to appear in name to D for it to be considered absolute. The default value is that defined using the ndots statement in /etc/resolv.conf, or 1 if no ndots statement is present. Names with fewer dots are interpreted as relative names and will be searched for in the domains listed in the search or domain directive in /etc/resolv.conf. +bufsize=B Set the UDP message buffer size advertised using EDNS0 to B bytes. The maximum and minimum sizes of this buffer are 65535 and 0 respectively. Values outside this range are rounded up or down appropriately. Values other than zero will cause a EDNS query to be sent. +edns=# Specify the EDNS version to query with. Valid values are 0 to 255. Setting the EDNS version will cause a EDNS query to be sent. +noedns clears the remembered EDNS version. EDNS is set to 0 by default. +[no]multiline Print records like the SOA records in a verbose multi-line format with human-readable comments. The default is to print each record on a single line, to facilitate machine parsing of the dig output. +[no]onesoa Print only one (starting) SOA record when performing an AXFR. The default is to print both the starting and ending SOA records. +[no]fail Do not try the next server if you receive a SERVFAIL. The default is to not try the next server which is the reverse of normal stub resolver behavior. +[no]besteffort Attempt to display the contents of messages which are malformed. The default is to not display malformed answers. +[no]dnssec Requests DNSSEC records be sent by setting the DNSSEC OK bit (DO) in the OPT record in the additional section of the query. +[no]sigchase Chase DNSSEC signature chains. Requires dig be compiled with -DDIG_SIGCHASE. +trusted-key=#### Specifies a file containing trusted keys to be used with +sigchase. Each DNSKEY record must be on its own line. If not specified, dig will look for /etc/trusted-key.key then trusted-key.key in the current directory. Requires dig be compiled with -DDIG_SIGCHASE. +[no]topdown When chasing DNSSEC signature chains perform a top-down validation. Requires dig be compiled with -DDIG_SIGCHASE. +[no]nsid Include an EDNS name server ID request when sending a query. +[no]keepopen Keep the TCP socket open between queries and reuse it rather than creating a new TCP socket for each lookup. The default is +nokeepopen. MULTIPLE QUERIES The BIND 9 implementation of dig supports specifying multiple queries on the command line (in addition to supporting the -f batch file option). Each of those queries can be supplied with its own set of flags, options and query options. In this case, each query argument represent an individual query in the command-line syntax described above. Each consists of any of the standard options and flags, the name to be looked up, an optional query type and class and any query options that should be applied to that query. A global set of query options, which should be applied to all queries, can also be supplied. These global query options must precede the first tuple of name, class, type, options, flags, and query options supplied on the command line. Any global query options (except the +[no]cmd option) can be overridden by a query-specific set of query options. For example: dig +qr [url]www.isc.org[/url] any -x 127.0.0.1 isc.org ns +noqr shows how dig could be used from the command line to make three lookups: an ANY query for [url]www.isc.org[/url], a reverse lookup of 127.0.0.1 and a query for the NS records of isc.org. A global query option of +qr is applied, so that dig shows the initial query it made for each lookup. The final query has a local query option of +noqr which means that dig will not print the initial query when it looks up the NS records for isc.org. IDN SUPPORT If dig has been built with IDN (internationalized domain name) support, it can accept and display non-ASCII domain names. dig appropriately converts character encoding of domain name before sending a request to DNS server or displaying a reply from the server. If you'd like to turn off the IDN support for some reason, defines the IDN_DISABLE environment variable. The IDN support is disabled if the variable is set when dig runs. FILES /etc/resolv.conf ${HOME}/.digrc SEE ALSO host(1), named(8), dnssec-keygen(8), RFC1035. BUGS There are probably too many query options. COPYRIGHT Copyright © 2004-2011, 2013 Internet Systems Consortium, Inc. ("ISC") Copyright © 2000-2003 Internet Software Consortium. BIND9 June 30, 2000 DIG(1)

Nu este inutil. Este un exercitiu de programare foarte bun. Insa sunt site-uri care ofera o gama mult mai variata de facilitati(traceroute, reverse dns-lookup, dig, etc.)

Poti instala easyphp. Pe Windows in mod implicit este instalat in C:\Program Files(x86)\EasyPHPxxx\. Acolo cauti un folder numit data in acela urci script-urile PHP. Pentru a vedea cum functioneaza navighezi in browser la adresa: http://localhost

Salut, Momentan nu sunt in tara insa am auzit ca lupta pentru voturi se intensifica de la o zi la alta. Imi poate cineva oferi, pe scurt, o imagine(text, nu neaparat poze) a situatiei politice din Romania? Am inteles ca se mananca intre ei, acum, inainte de final(se vantura dosare, lumea dispare de pe scena politica, locurile la Popa Sapca se ocupa, etc.). Care candidat pare a avea in momentul de fata cele mai ridicate sanse de a carmui tarisoara noastra?

Este cumva REC?