Jump to content

begood

Active Members
  • Posts

    3972
  • Joined

  • Last visited

  • Days Won

    22

Everything posted by begood

  1. begood

    Gym

    nu la aparatul la care lucrez, ci in fata mea, oriunde m-as uita eu )))) doar la banda se intampla sa fie langa mine, dar la restul la 2-3 m in fata se indoaie bine bine sa se vada ce e de vazut. de notat faptul ca la aerobic si ce se mai face, din 12 fete, 1 e mai grasa. iar eu care credeam ca se merge la slabit ... adevarul e ca, fiind grase, nu au tupeul sa-si expuna suncile la 30-40 oameni. restul papusi. (esti motivat la banda, ele fiind in spatele tau (cu oglinda in fata)) asa cred ca am ajuns la de la 1km la 10 km intr-o luna 3>
  2. begood

    Gym

    frumos spate mariane. cred ca cele mai mari realizari cu sala asta, ar fi, pentru mine, faptul ca mi-a crescut moralul, simtul umorului, starea de bine, pofta de mancare, increderea de sine, si nu in ultimul rand rezistenta. inainte, dimineata, eram semi-mahmur, ma trezeam 'bine' abia dupa juma de ora sau mai mult, acum sar in picioare fresh, in fiecare zi, indiferent de cat dorm (chiar si dupa 2-3 ore de somn)
  3. begood

    Gym

    cate kg zici ca ai ? pe mine ma bantuie vreo 3 fete nu ma pot concentra pe antrenament, unde ma duc, se baga si ele 'preferabil' in fata si incep sa se indoaie sau eu stiu ce avem 6 benzi si ma pun in mijloc, hop si una in dreapta, ailalta vine, ii trage o privire de vipera la asta si se pune in stanga mea. si dai si dai si dai, faceau curse intre ele sa demonstreze care'i mai cu mot
  4. begood

    Gym

    lil' update : 1.acum alerg 10km pe zi (6miles=9.6km) 2.se pare ca e cel mai eficient mod de a slabi : cate 2km/sapt. am dat jos deja 8 km ! 3.am ajuns la concluzia ca dupa juma de litru de lapte seara, a doua zi chiar daca nu se simte energie dimineata, dupa un mic dejun bun, pe la ora 15 daca merg la sala, am o energie de pusc practic nici nu transpir dupa 10km cu 13km/h . 4. 4-5 zile pe sapt sala.
  5. filelist.ro :: Login http://pastebin.com/f12502524 acum il urc pe 2shared.com genu asta ?
  6. We love daddy
  7. e varsta ideala.
  8. Trebuie sa recunosc ca nu prea cred stirea... Intr-adevar e geniala.
  9. Il mai completez pe masura ce imi vin idei, am lucrat vreo 5 ore la el.
  10. ro : In sfarsit m-am hotarat sa scriu un tutorial cuprinzator care sa descrie metoda de a genera tabele rainbow perfecte, de calitate ridicata (viteza sporita, rata de succes mare). en : I finally decided to create a comprehensive tutorial in witch I describe the method on how to generate perfect rainbow tables of high quality (high speed & high success rate) First of all, if we want to create a rainbow table set, we need to know what type of passwords we want to crack with it. We have the password : frt2ns9 The characters in the password are loweralpha (f,r,t,n,s) and numeric (2,9). loweralpha = [abcdefghijklmnopqrstuvwxyz] numeric = [0123456789] If we combine the two charsets we will end up with : loweralpha-numeric = [abcdefghijklmnopqrstuvwxyz0123456789] Now, the password length is 7. In order to crack this password we will need a rainbow table set with the following properties : charSet : loweralpha-numeric charSetLen = 36 maxPwLen = 7 (length of the password) Now we need to calculate the keySpace of the above configuration. The ecuation is : keySpace = charSetLen * (charSetLen^maxPwLen - 1)/(charSetLen - 1)) The keySpace is actually the number of possible password combinations that are loweralpha-numeric and have the length between 1 and maxPwLen. For example: loweralpha-numeric, 1-7. {a,b,c,...,z,0,1,2,...,9,aa,ab,...,az,a0,a1,...,a9,ba,bc,...,zz,...,99,aaa,...,bbb,...,ccc,...,zzz,...,999,...aaaaaaa,aaaaaab,aaaaaac,...,zzzzzzz,...,9999999} There are 26 characters in loweralpha, 10 in numeric. So there are 26+10=36 possible passwords with length 1, 36^2=1296 passwords with length 2, and so on until maxPwLen = 7 : 36^7=78364164096. If we add these, we end up with the actual keySpace: 36^1+36^2+36^3+...+36^7 = 80603140212 = 2^36.23 . As you can see, the keySpace could be written also as : charSetLen^1 + charSetLen^2 + charSetLen^3 +...+ charSetLen^maxPwLen. So the keySpace is 80603140212. BarsWF's bruteforcer (3.14.by), on Core2Duo E2140@3Ghz, has a speed of 100Mhashes/sec. So to calculate the time to bruteforce the above config we only need to divide keySpace with the hash speed : 80603140212/100000000=806 sec. This means that in the worst case (password : 9999999) it will take up to ~13 minutes to crack (one MD5 hash). So far, if we want to create a rt set, we need to keep in mind : 1. The type of passwords to be cracked, the charset, and maximum password length. 2. If the keySpace is small and we have a small amount of hashes to crack, it is more efficient to bruteforce the keySpace. If we have a large list of hashes to crack, and/or the keySpace is larger, it's better to create a set of rainbow tables. Because rainbow tables have the time over memory trade-off property, and they are based on statistical functions => it's more efficient to generate rt's with the success probability of 99.9%. These tables will crack 999 hashes in 1000 (miss 1 in 1000). The higher the success probability, the higher the table size and generation time. Sc00bz from FreeRainbowTables.com worked out the math behind the rainbow tables, and we ended up with the following conclusion : the best configuration is 5 perfect tables with the tableWorkFactor = 4.48860x in order to get 99.9% success probability. Here are the charts Sc00bz created : Perfect Rainbow Tables "99.9%" | | | Less | Smaller Than | Smaller Than | | | | Total | Previous | Previous | | Work Per | Total | Work Than | (Const Chain | (Const Total | Total Success Tables | Table | Work | Previous | Length) | Pre-work) | Rate ---------+-----------+-----------+-----------+--------------+--------------+----------------- 1 Tables | N/A | N/A | | | | 86.46462849% Max 2 Tables | N/A | N/A | | | | 98.16793718% Max 3 Tables | N/A | N/A | | | | 99.75202349% Max 4 Tables | 12.78300x | 51.13200x | | | | 99.90100293% 5 Tables | 4.48860x | 22.44300x | 56.11% | 0.0001% | -11.80% | 99.90100191% 6 Tables | 2.72220x | 16.33320x | 27.22% | 0.0007% | -9.54% | 99.90099547% 7 Tables | 1.95350x | 13.67450x | 16.28% | -0.0006% | -8.01% | 99.90099836% 8 Tables | 1.52334x | 12.18672x | 10.88% | -0.0006% | -6.91% | 99.90100114% Non-Perfect Rainbow Tables "99.9%" | | | Less | Smaller Than | Smaller Than | | | | Total | Previous | Previous | | Work Per | Total | Work Than | (Const Chain | (Const Total | Total Success Tables | Table | Work | Previous | Length) | Pre-work) | Rate ---------+-----------+-----------+-----------+--------------+--------------+----------------- 1 Table | 61.52000x | 61.52000x | | | | 99.90100449% 2 Tables | 9.27400x | 18.54800x | 69.85% | 69.8505% | 57.36% | 99.90099964% 3 Tables | 4.33500x | 13.00500x | 29.88% | 29.8846% | 14.13% | 99.90100885% 4 Tables | 2.74900x | 10.99600x | 15.45% | 15.4479% | 2.37% | 99.90106579% 5 Tables | 1.99450x | 9.97250x | 9.31% | 9.3079% | -1.40% | 99.90100455% 6 Tables | 1.55950x | 9.35700x | 6.17% | 6.1720% | -2.78% | 99.90099853% 7 Tables | 1.27810x | 8.94670x | 4.38% | 4.3850% | -3.28% | 99.90099297% 8 Tables | 1.08180x | 8.65440x | 3.27% | 3.2671% | -3.41% | 99.90101465% Also, Sc00bz had a brilliant idea : to calculate the bruteForcePoint. This number is nothing else but how many times a rainbow table is more "efficient" than a bruteforcer. For a "good" rainbow table set, he said that the bruteForcePoint should be between 1,000 and 10,000, the higher, the faster the rainbow table, the better. chainLen shrinks and chainCount grows when bruteForcePoint grows. This means that the table size grows with bFP. bruteForcePoint = keySpace / (chainLen * (chainLen + 1) / 2 * numTables), numTables = 5 so we can calculate chainLen . chainLen = (sqrt(bruteForcePoint) * sqrt(numTables) * sqrt(8 * keySpace + bruteForcePoint * numTables) - bruteForcePoint * numTables) / (2 * bruteForcePoint * numTables) I know, it's a ugly formula, but we have a friend : Wolfram|Alpha. We only need to enter 10000 = 80603140212 / (x * (x + 1) / 2 * 5), we are interested in the positive solution : x~~1795.09, where x is chainLen . And we can aproximate it to 1800. chainLen = 1800. The next step is to calculate chainCount. It's easy : chainCount = tableWorkFactor * keySpace / chainLen . We know tableWorkFactor = 4.48860, keySpace = 80603140212, chainLen = 1800. chainCount = 200997364. 16bytes/chain => Table size = 3215957824 Bytes ~= 3GiB. 5 tables => 15 GiB, don't forget, we create non-perfect tables ! Actually they are : perfectSize = non-perfectSize / ((tableWorkFactor / 2) + 1), tableWorkFactor = 4.48860 so perfectSize = non-perfectSize / 3.2443 perfectSize = 991264008 bytes = 945 MiB. After indexing, the table size will be ~half the perfect size. Perfected&indexed table set size ~= 2.3 GiB. In the end we have the following configuration : loweralpha-numeric, 1-7, chainLen = 1800, chainCount = 200997364. Running WinRTGen (oxid.it) on my (slow and old) computer (intel Celeron D @ 3Ghz) I get 3.8 Mhashes/sec, stepSpeed = 820,500 links/sec. Table precomputation time : 5 days, total precomputation time : 25 days, max cryptanalysis time : 10 sec. The config will be : md5_loweralpha-numeric#1-7_0_1800x200997364_oxid#000.rt md5_loweralpha-numeric#1-7_1_1800x200997364_oxid#000.rt md5_loweralpha-numeric#1-7_2_1800x200997364_oxid#000.rt md5_loweralpha-numeric#1-7_3_1800x200997364_oxid#000.rt md5_loweralpha-numeric#1-7_4_1800x200997364_oxid#000.rt ------------------------------------------------------- I also have some specifications. If chainLen is between 2 and 65,537 we use table index like in the above configuration {0,1,2,3,4} but if chainLen is higher than 65,537, table index needs to be weird. Chain Length Range | Table Indexes ----------------------+-------------------------- 2 - 65,537 | 0, 1, 2, 3, 4 ... 65,538 - 131,073 | 0, 2, 4, 6, 8 ... 131,074 - 262,145 | 0, 4, 8, 12, 16 ... 262,146 - 524,289 | 0, 8, 16, 24, 32 ... 524,290 - 1,048,577 | 0, 16, 32, 48, 64 ... 1,048,578 - 2,097,153 | 0, 32, 64, 96, 128 ... 2,097,154 - 4,194,305 | 0, 64, 128, 192, 256 ... 4,194,306 - 8,388,609 | 0, 128, 256, 384, 512 ... Sc00bz sugested that the chainCount should be higher than 200. The speed of a quad core computer is 3 milion links/sec (3*10^6, that's ~3.5 times faster than mine ) The current [14.10.2009] speed of the Freerainbowtables.com project is 1 - 1.6 bil links/sec (10^9). tableGenerationTime = keySpace * tableWorkFactor / stepSpeed = chainCount * chainLen / stepSpeed BarsWF CPU hash speed = 100Mhashes/sec (Core2Duo@3Ghz) BarsWF CUDA hash speed = 350Mhashes/sec (nVidia 9600GT, Core2Duo@3Ghz) Examples : mixalpha-numeric-space, 1-8 bruteforce speed (CPU) = 100Mhashes/sec bruteforce speed (GPU) = 350Mhashes/sec stepSpeed (1computer) = 3mil links/sec (3*10^6) stepSpeed (frt.com) = 1bil links/sec (10^9) 5 perfect tables, success probability = 99.9% tableWorkFactor = 4.48860 1. charSetLen = 26+26+10+1 = 63 2. keySpace = 252158292852480 = 2^47.84 http://www.wolframalpha.com/input/?i=log_2((63*(63^8-1)/(63-1))) 3. bruteforce time (CPU)= 2521582 sec = 700 h = 30 days (1 MD5 hash) http://www.wolframalpha.com/input/?i=252158292852480/100000000 bruteforce time (GPU)= 720452 sec = 8.5 days (1 md5 hash) http://www.wolframalpha.com/input/?i=252158292852480/350000000 4. note : bFP = bruteForcePoint np-ts = non-perfect table size (GiB) np-tss = non-perfect table set size (GiB) p-ts = perfect table size (GiB) p-tss = perfect table set size (GiB) p&i-ts = indexed perfect table size p&i-tss = indexed perfect set size (GiB) np-time(CPU) = non-perfect table set generation time on one computer (md5 algo on WinRTGen) np-time(frt) = non-perfect table set generation time on FreeRainbowTables.com np-time(GPU) = non-perfect table set generation time on one GPU bFP | chainLen | chainCount | np-ts | np-tss | p-ts | p-tss | p&i-ts | p&i-tss --------+----------------+-----------------+---------+---------+--------+-------+--------+---------- 5000 | 142030 | 7969004529 | 119 | 594 | 37 | 184 | 19 | 92 10000 | 100430 | 11269916492 | 168 | 840 | 52 | 259 | 26 | 130 20000 | 71014 | 15938233493 | 238 | 1187 | 74 | 366 | 37 | 183 np-time(CPU) = 60 years np-time(GPU) = atm i don't have any benchmarks. np-time(frt) = 65 days note : the generation time is about the same for all configurations because keySpace and stepSpeed are constants. chainLen http://www.wolframalpha.com/input/?i=5000=252158292852480/(x*(x+1)/2*5) chainCount http://www.wolframalpha.com/input/?i=4.48860=142030*x/252158292852480 np-ts http://www.wolframalpha.com/input/?i=7969004529*16/1024/1024/1024 np-tss http://www.wolframalpha.com/input/?i=7969004529*16/1024/1024/1024*5 p-ts http://www.wolframalpha.com/input/?i=7969004529*16/1024/1024/1024/3.2443 p-tss http://www.wolframalpha.com/input/?i=7969004529*16/1024/1024/1024/3.2443*5 p&i-ts http://www.wolframalpha.com/input/?i=7969004529*16/1024/1024/1024/3.2443/2 p&i-tss http://www.wolframalpha.com/input/?i=7969004529*16/1024/1024/1024/3.2443/2*5 5. Because chainLen is between 131,074 and 262,145 we will have the following index for each table {0,4,8,12,16} The final configurations : 131074 < 142030 < 262145 => {0,4,8,12,16} p&i-tss = 92 GiB hashAlgo_mixalpha-numeric-space#1-8_0_142030x7969004529_oxid#000.rt hashAlgo_mixalpha-numeric-space#1-8_4_142030x7969004529_oxid#000.rt hashAlgo_mixalpha-numeric-space#1-8_8_142030x7969004529_oxid#000.rt hashAlgo_mixalpha-numeric-space#1-8_12_142030x7969004529_oxid#000.rt hashAlgo_mixalpha-numeric-space#1-8_16_142030x7969004529_oxid#000.rt 65538 < 100430 < 131073 => {0,2,4,6,8} p&i-tss = 130 GiB hashAlgo_mixalpha-numeric-space#1-8_0_100430x11269916492_oxid#000.rt hashAlgo_mixalpha-numeric-space#1-8_2_100430x11269916492_oxid#000.rt hashAlgo_mixalpha-numeric-space#1-8_4_100430x11269916492_oxid#000.rt hashAlgo_mixalpha-numeric-space#1-8_6_100430x11269916492_oxid#000.rt hashAlgo_mixalpha-numeric-space#1-8_8_100430x11269916492_oxid#000.rt 65538 < 71014 < 131073 => {0,2,4,6,8} p&i-tss = 183 GiB hashAlgo_mixalpha-numeric-space#1-8_0_71014x15938233493_oxid#000.rt hashAlgo_mixalpha-numeric-space#1-8_2_71014x15938233493_oxid#000.rt hashAlgo_mixalpha-numeric-space#1-8_4_71014x15938233493_oxid#000.rt hashAlgo_mixalpha-numeric-space#1-8_6_71014x15938233493_oxid#000.rt hashAlgo_mixalpha-numeric-space#1-8_8_71014x15938233493_oxid#000.rt my first tutorial for FreeRainbowTables.com _haxxor_ Download it, share it. source : Free Rainbow Tables | Forum • View topic - [tutorial] How to create a rainbow table set
  11. Nu este Ludwig Van Beethoven autorul celebrei Fur Elise, una dintre cele mai cantate piese pentru pian din toate timpurile. Aceasta este surprinzatoarea concluzie a unui studiu prezentat de cercetatorul italian Luca Chiantore la Universitatea din Barcelona, la finalul a opt ani de investigatii. Potrivit lui Chiantore, adevaratul autor al Fur Elise ar fi fost muzicologul german Ludwig Nohl, cel care in 1865 a descoperit manuscrisul autograf cu notitele lui Beethoven intr-o colectie privata din Munchen. Studiul cercetatorului italian a plecat de la constatarea ca aceasta piesa a iesit la lumina de-abia dupa 40 de ani de la moartea celebrului compozitor si ca notitele respective nu corespund versiunii sub care este cunoscuta piesa la ora actuala. In teza sustinuta la Universitatea din Barcelona, Chiantore a furnizat o serie de elemente care indica faptul ca Nohl ar fi utilizat acel manuscris pentru a "compune" o noua piesa. Si asa s-ar fi nascut Fur Elise. YouTube - Ludwig Van Beethoven-- Fur Elise sursa : Studiu soc: Fur Elise n-a fost compusa de Beethoven - TORRENTs.RO
  12. Infected Mushroom - Heavyweight
  13. begood

    dictionar

    superb, foarte bine faci.
  14. begood

    dictionar

    Te ajut, daca vrei. Ma ai in lista, da, ajuta foarte mult mai ales cu lista mea de "mutatii" ce pot fi aplicate pe cuvinte pentru a rezulta cele mai frecvente tipuri de parole. Am studiat destul ca sa pot sa-ti dau informatii utile despre cele mai dese tipuri de parole intalnite - statistici pe zeci de mii de parole - organizate pe diferite ramuri de utilizatori etc. LE : Eu am cativa gb buni de dictionare adunate de peste tot, majoritatea limbi internationale - en,fr,ger. Numa intreaba-i pe hertz, unu, si restul de pe rst cat i-am ajutat cu ele. (evident sortate, curatate )
  15. @loki ce tip se salvie ? )) is enspe specii List of Salvia species - Wikipedia, the free encyclopedia
  16. intrebarea e : ti-ar mai pasa ?
  17. nu te juca cu dracu', e destul de foarte tare. pe youtube e full de vid'uri. de incercat as incerca, dar doar alaturi de unu care deja a luat.
  18. cine le aduna intr-o arhiva ?
  19. begood

    ./nasa.gov/proof

    bv tin
  20. begood

    Filme Online

    Stargate Universe 1x00 Access All Areas Special Stargate Universe 1x00 Access All Areas Special (DivX Mirror) Stargate Universe 1x00 Access All Areas Special (Flash) Stargate Universe 1x01-02 Air Stargate Universe 1x01-02 Air (Flash) NinjaVideo.net - Stargate Universe Season 1
  21. begood

    Filme Online

    Stargate Atlantis Stargate SG-1 Stargate Universe Merge cu DivX WEB player Ruleaza pe tehnologia bittorrent si nu numai. Cu bittorrent, bufferingul nu dureaza mai mult de 3 secunde. So no worries. Sunt filme, seriale si filme documentare pe acest site. http://www.ninjavideo.net
  22. E genial site-ul, iti faci cont, iar apoi incepi sa dai ratinguri la filmele vazute, pe baza acestora site-ul iti recomanda foarte exact filme care s-ar putea sa-ti placa. Il recomand tuturor ! http://www.jinni.com/home.html
  23. btw imi place ca esti subtil tin, nu faci reclama la niciun forum
  24. nu-i rau, nota 9
  25. Pulso.ro - Afla cine e invizibil in Yahoo! Messenger pulso.ro/avatare.php pulso.ro/imessage.php?id=[number] <META HTTP-EQUIV="Refresh" CONTENT="0; URL=ymsgr:sendim?[id]"> Tot ce trebuie facut este un script care sa verifice din 10 in 10 minute ultimul numar de la imessage.php, sa faca diferenta dintre actuala si ultima valoare, apoi sa incrementeze cu 1 fiecare mesaj, si sa extraga [id]. Asa va puteti umple de mailuri [y!] in cateva zile. as dori sa ma contacteze cel care implementeaza tehnica asta.
×
×
  • Create New...