Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 01/10/13 in all areas

  1. În acest tutorial voi descrie o metod? interesant? de a ascunde fi?ierele ce nu vor putea fi accesate de c?tre utilizatorii sistemului de operare Windows (începând de la versiunea Win2000 ?i terminând cu ultima — Win8). De fapt merge vorba despre un bug, din cauza c?ruia procesul explorer.exe este obligat s? p?r?seasc? locul de munc? (pe scurt — se închide automat ?i se restarteaz?). Ideea const? în modificarea folderului ?i „transformarea” acestuia într-un shortcut ce face referire la fi?ierul desktop.ini din acela?i folder. Iat? de ce, atunci când explorer.exe încearc? s? afle propriet??ile folderului, acesta din urm? face din nou referire la obiectul s?u ?i... ?i tot a?a pân? când procesul se d? b?tut (iar acest lucru se întâmpl? foarte repede). Creators of „New folder” and „New folder (2)” proudly present — „New folder (3): The killer” — the drama of explorer.exe Istorie Persoana care a descoperit acest bug, fiind în anii studen?iei pe vremea când internetul „picura” cu un scâr?âit de mul?i cunoscut („pierzând toat? noaptea pentru a vedea 4-5 poze” ©) ?i dischetele erau la mod?, (persoana) dorea s? se asigure c? datele salvate într-un PC de la universitate nu vor fi ?terse sau copiate de c?tre al?i studen?i. Dat fiind faptul c? dischetele erau unicul ?i cel mai nesigur mod de a „transporta” datele din/c?tre acel PC, eroul nostru a hot?rât s? g?seasc? o metod? de a ascunde ?i de a proteja folderul personal pentru ca nimeni s? nu-l poat? ?terge sau copia. Despre ascunderea unui folder folosind func?iile Windows nici nu mergea vorba — to?i ?tiau cum pot fi g?site acestea. Îns?, dup? mai multe încerc?ri ?i teste, a g?sit un bug foarte interesant care opre?te for?at procesul explorer.exe atunci când utilizatorul deschide folderul personal sau folderul în care se afla acesta. El (eroul) ?tiind calea complet? putea accesa direct fi?ierele ascunse în folderul personal. Explica?ie De exemplu, fiecare utilizator avea dreptul de a crea/?terge/edita datele din folderul D:\usr\, în care fiecare student î?i salva informa?iile necesare. Eroul nostru îns?, dorind s? p?streze ?i ceva date mai importante a creat folderul D:\usr\name\key1\key2\ unde f?cea backup de pe dischet? ?i/sau salva alte informa?ii importante. Pentru D:\usr\name\key1\ îns? a folosit trucul de care vorbeam mai sus. Astfel, oricine încerca s? deschid? D:\usr\name\ sau D:\usr\name\key1\ (ace?tia probabil erau mai pu?ini, c?ci nu to?i reu?eau s? ?in? minte numele folderului \key1\) nu vedea altceva decât eroarea de r?mas bun al procesului explorer.exe. Autorul îns?, ?inând minte numele folderelor \key1\ ?i \key2\ insera direct calea c?tre acest ultim folder, iar explorer.exe r?mânea pe pozi?ii deoarece nu trebuia s? afle propriet??ile folderului \key1\. Transformare Pentru a proteja folderul folosind metoda de mai sus, e necesar s? parcurge?i urm?torii pa?i (în ordinea specificat?): Crea?i un folder în locul dorit Marca?i folderul ca fiind te tip „System” În acest folder crea?i un fi?ier desktop.txt în care scrie?i: [.ShellClassInfo] CLSID2={0AFACED1-E828-11D1-9187-B532F1E9575D} Flags=2 Redenumi?i fi?ierul desktop.txt în desktop.ini Crea?i un shortcut c?tre desktop.ini cu numele target.lnk Privi?i cum explorer.exe se zbate în ghiarele ciclului infinit. Bonus Totu?i, este ?i o mic? problem? — în cazul eroului, oricine putea ?terge folderul D:\usr\name\ f?r? a-l deschide. Îns?, voi oferi un mic bonus, pentru a interzice ?tergerea folderului personal. Chestia e foarte simpl? — pentru sistemele de operare Windows, exist? o list? de cuvinte cheie ce nu pot fi folosite la crearea unui folder sau fi?ier. Culmea e c?, a?a cum nu pot fi create astfel de obiecte, ele nu pot fi nici ?terse dac? s-a reu?it crearea unui astfel de obiect. Unul dintre aceste cuvinte cheie este ?i NUL. Ideea mea e simpl?, cre?m un folder cu numele NUL în folderul personal ?i în modul acesta interzicem ?tergerea acestuia din urm?. Automatizare Pentru a simplifica tot ce a fost scris mai sus, am f?cut un mic script în VBScript care trebuie salvat în folderul personal ca pe un fi?ier cu extensia .vbs — executând scriptul de mai jos în folderul personal, acesta v-a fi modificat corespunz?tor, iar procesul explorer.exe se v-a restarta. ' Indic?m dac? folderul poate fi ?ters sau nu Removable = false ' Ob?inem loca?ia folderului curent Set fs = WScript.createObject("Scripting.FileSystemObject") folder = fs.GetAbsolutePathName(".") ' Dac? e nevoie, folosim un mic truc pentru a proteja ?tergerea folderului If Not Removable Then ' Cre?m un folder aleatoriu Randomize secretFolder = folder & "\" & Int(Rnd(1) * 99999999) & "\" fs.createFolder(secretFolder) ' NUL folder On Error Resume Next fs.createFolder(secretFolder & "\NUL\") End If ' Marc?m folderul ca fiind de tip "system" fs.getFolder(folder).attributes = 4 ' Liniile ce vor fi scrise în fi?ierul desktop.ini lines = Array("[.ShellClassInfo]", "CLSID2={0AFACED1-E828-11D1-9187-B532F1E9575D}", "Flags=2") ' Scriem datele necesare în desktop.ini Set file = fs.openTextFile(folder + "\desktop.ini", 2, True) file.write join(lines, vbCrLf) file.close ' Cre?m shortcut-ul target.lnk c?tre fi?ierul desktop.ini Set link = WScript.CreateObject("WScript.Shell").createShortcut(folder + "\target.lnk") link.targetPath = folder + "\desktop.ini" link.save msgBox "Folder-ul a fost modificat cu succes", 64, "Explorer.exe: Au revoir mon cheri" Sfaturi Nu crea?i folderul personal pe desktopul propriu (ghici?i de ce) Nu uita?i c? folderul personal poate fi accesat din alt sistem de operare Nu uita?i c? discul local poate fi formatat (astfel nu v? mai protejeaz? nimic datele) Nu uita?i c? cuvântul cheie NUL este valabil doar pentru Windows Nu uita?i s? experimenta?i — e un bug foarte iste? Nu uita?i s? posta?i întreb?rile ?i ideile voastre
    2 points
  2. Autor: Xash Stub: asm Builder: Delphi https://www.box.com/s/rf1g4w3mu109ifdr6ggv
    1 point
  3. Using API Monitor to crack copy protected software This tutorial demonstrates how to use API Monitor to crack copy protected software. For this tutorial we will be using Mirial Softphone which is a HD video conferencing application. This tutorial is for educational purposes only, so please do not use this to create or distribute a cracked copy of the software. When you first install the application, it prompts you for a license file. After installing the license you have 30 days to evaluate the application. The expiration date is displayed on this screen; in our case it is March 15, 2011. Download,Mirial Softphone Step 1 Trial applications usually store license information in either the registry or on the file system. Since this application prompted us for a license file, we know that it uses the file system. Start up the 32-bit version of API Monitor and enable API’s from the File Management category. Step 2 Select Hook Process from the File menu to start monitoring the application. API Monitor will start monitoring and displaying API calls. The application should now display a message indicating that it is an evaluation version. Hit cancel to quit the application. Step 3 Now that we have captured the API calls made by the application, we need to find the one that reads the license file. Scan through the calls in the API summary view until you find the right one. The application is reading from mirial.lic file. The name suggests that it might be a license file, so let’s open it up. We’ve located the license file and it has the expiration date in it. Step 4 Modify the expiration date in the license file to 2012-03-15 and save the file. Now launch the application again. The application should now display an error indicating that the license is invalid. Hit cancel to quit the application. Step 5 Our next step is to start debugging the application right after it has read the license file. From Step 3, we know that the application uses CreateFileA to open the file and ReadFile to read the file. Setup a Breakpoint on CreateFileA and launch the application in API Monitor. The breakpoint will be hit multiple times; continue until you reach the one that opens the license file. Switch back to API Monitor and enable a post-call breakpoint on the ReadFile API and disable the CreateFileA breakpoint. Now hit Continue to let the application run. API Monitor should now display the ReadFile breakpoint. Now hit the Break button to have API Monitor generate a breakpoint in the application. You should now be able to attach to the application using a debugger. Step 6 Your debugger should now display disassembled instructions from the application If you look at the call stack, you’ll notice that the current frame is in apimonitor-drv-x86.sys. Use the debugger to step out until you reach code in the application. Step 7 The debugger is currently at a location right after the application has finished reading the license file and before it checks the validity of the license. We need to locate the code that performs this check and disable it. ''The most common software crack is the modification of an application’s binary to cause or prevent a specific key branch in the program’s execution. This is accomplished by reverse engineering the compiled program code using a debugger such as SoftICE, OllyDbg, GDB, or MacsBug until the software cracker reaches the subroutine that contains the primary method of protecting the software (or by disassembling an executable file with a program such as IDA). The binary is then modified using the debugger or a hex editor in a manner that replaces a prior branching opcode with its complement or a NOP opcode so the key branch will either always execute a specific subroutine or skip over it. – Wikipedia'' Stepping though some of the code, we come across this location which looks like a possible match to the code we’re looking for. Step 8 The value of register eax is 0, right after the function call. Let’s modify the value to 1 and continue running the application. The application displays a different error message this time; instead of an invalid license, the application is telling us that it is unable to locate the file. Step 9 Now that we have pinpointed the location where the application checks for a valid license, all we need to do is to play around with the values and jmp instructions to find one that works. In this case, inverting the jump instruction from je to jne tells the application that it has a valid license file. Running the application with the modified code displays our new expiration date of March 15, 2012. Source: Using API Monitor to crack copy protected software | rohitab.com Download link,api-monitor-v2r12
    1 point
  4. This guy recently found a Stored XSS on Facebook worth 3500USD dollars. This is his story how he did it: I was actually working on finding flaws on Dropbox to begin with. I noticed that when using their web interface there were some restrictions on what filenames that were allowed. If you tried to rename a file to for example: '"><img src=x onerror=alert(document.domain)>.txt it was not possible. You got this error: The following character are not allowed: \/:?*<>"| But, if you instead, connected a local directory, created a file there and synced it, you got it inside Dropbox without any problems. Using this method I was able to find two issues with their notification messages showing unescaped filenames. I reported these issues to Dropbox, they patched it really fast and I was placed on their Special Thanks page for the responsible disclosure. It didn’t end here. As I was testing out this stuff on Dropbox, I also tried to figure out how this issue could be connected with other services. I noticed their Facebook-connection and got curious on how it worked. It turned out that they had a pretty nice function going on there: “Dropbox has teamed up with Facebook so that you can do cool things like add files from Dropbox to your Facebook groups or send shared folder invitations to your Facebook friends.” Nice! I created a group, and found the connection using the “Add File” icon on the Group wall: I selected the file that I synced to Dropbox, it was called: '"><img src=x onerror=alert(document.domain)>.txt and shared it. Nothing awesome happened except the file being shared. But then, I clicked the Share-link on the entry. BAM! The title of the entry was not escaped correctly and I was able to get the Stored XSS triggered. By using the files in my Dropbox I could inject script code that was executed on Facebook.com. I reported this to Facebook directly using their Whitehat Vulnerability Reporting system, told them it was an urgent issue and how I managed to get it executed. The issue was at that time only affecting the Share-popup inside the Group page and could only be triggered by user interaction, serious or not, it was clearly not affecting all users on Facebook. At the same time I started looking on the URL of this Share-popup: https://www.facebook.com/ajax/sharer/?s=44&appid=210019893730&p%5B0%5D=entry_id&p%5B1%5D=user_that_shared_it_first This URL did not work if you tried it stand-alone. That was good, the XSS issue looked like it could only be triggered by user interaction. But then I started googling and found that you were able to create a Share-URL by using this format: https://www.facebook.com/sharer/sharer.php? So I changed my URL to that format: https://www.facebook.com/sharer/sharer.php?s=44&appid=210019893730&p%5B0%5D=entry_id&p%5B1%5D=user_that_shared_it_first BAM again! If you were logged in into Facebook, the code was executed as soon as you visited the link. Bad. Really bad. I emailed Facebook again, explaining that you could actually trigger the XSS by only visiting a link. I was also trying out if I could get other services to behave in the same way. Dropbox and Facebook had this special connection, so I was curious if this issue was isolated or if I could reproduce it by using another service. Went to Pinterest. Created a Pin named: '"><img src=x onerror=alert(document.domain)> and shared it on Facebook using my test account. I pressed the Share button on it. I was amazed – it had the same issue. Facebook replied to me, asking me how I was able to place the files on Dropbox with that filename. I explained how this was done and also told them that the service that you shared from didn’t matter, it was a general issue with the escaping that created a vulnerable vector on the Share-page. They responded and said that it was indeed the same issue and they should look into it ASAP. In the meantime, I tried the link on different devices. My iPhone could not get the XSS executed. As soon as I visited the page, I was redirected to https://m.facebook.com and that page did not have the same issue. But I also realized that you could force Facebook to skip the redirect by using a parameter called m2w, so if I appended that to the URL: https://www.facebook.com/sharer/sharer.php?s=44&appid=210019893730&p%5B0%5D=entry_id&p%5B1%5D=user_that_shared_it_first&m2w I was able to trigger the URL on both mobile devices and on desktop. Another email to Facebook. One day after that I noticed that the POC-link did not work anymore, it was finally patched. I told them I could not reproduce it anymore and it looked like it was fixed. One day later I got this email: Source: Detectify Blog – How I got a $3,500 USD Facebook Bug Bounty
    1 point
  5. https://www.box.com/s/vas8c236mkmeq4onmgbu
    -1 points
  6. download: https://www.dropbox.com/s/pbhq93etcvhbzf1/Aryenal.zip PassworD: CKcwBe2egS22A7GG (Encrypt -> GILA7) descriere : acest program elimina password din Deep Freeze. Sper ca stiti ce este Deep Freeze!
    -1 points
×
×
  • Create New...