Leaderboard

Am creeat o animatie in java script care reprezinta moleculele de gaz in miscare continua si dezordonata intr-un corp https://www.khanacademy.org/computer-programming/corptermodinamic/4955027818151936

Your argument is invalid !!! Declar pe proprie reaspundere ca imi asum orice warn posibil si imposibil primit pt aceste offtopicuri )

Pwnthecode este o platform? educa?ional? care are ca scop dezvoltarea, responsabilizarea ?i antrenarea pasiona?ilor de securitate. Scopul definit al platformei este s? demonstreze cât de periculoase sunt vulnerabilit??ile web dar ?i s? înve?e utilizatorul despre anumite bre?e de securitate pe care acesta, ulterior, va înv??a s? le repare în vederea îmbun?t??irii securit??ii pe pia?a IT. Platforma se adreseaz? în special celor mai pu?in specializa?i în domeniul IT ?i celor care de?in un website sau care activeaz? în domeniul web. Link: Pwnthecode | Proiect despre Securitatea Web Momentan platforma este la la versiunea BETA, urmând ca în scurt timp s? ad?ugam atât un numar mare de tutoriale pentru vulnerabilit??ile existente (în cadrul platformei) cât ?i câteva tipuri de vulnerabilit??i noi. De asemenea, vom mai ad?uga/modifica examene. User control panelul este în dezvoltare deci este posibil s? întâmpina?i unele probleme. Orice fel de problem? v? rog s? mi-o trimite?i prin PM mie sau lui @danyweb09. Cei care dorest s? sus?in? proiectul pot face o dona?ie (g?si?i pe site mai multe detalii). Dac? cineva doreste s? doneze prin alt? metod? decât PayPal, s? imi trimit? PM. Orice sugestie este bine-venit?!

Video archives of security conferences Just some links for your enjoyment List of security conferences in 2014 Video archives: Blackhat 2012 Botconf 2013 Bsides Bsides Cleveland 2012 BsidesCLE Chaos Communication Congress Chaos Communications Channel YouTube 31c3 Recordings Defcon Defcon: All Conference CDs and DVDs with Presentation PDF files (updated 2014 for DEF CON 22): Torrent Defcon: all other Derbycon Digital Bond's S4x14 Digital Bond's S4x14 ISC Security Circle City Con GrrCON Information Security Summit & Hacker Conference Hack in the box HITB 2011 InfowarCon InfowarCon 2014 Free and Open Source Software Conference 2014 froscon2014 International Cyber Security Conference KIACS Cyber Security Conference KIACS 2014 Louisville NATO Cyber Security Conference Notacon Notacon 2013 Nullcon Nullcon 2014 Nullcon 2013 Nullcon 2012 OWASP AppSec EU Research 2013 AppSecUSA 2012 AppSecUSA 2011 RSA Videos Ruxcon Shmoocon Shmoocon 2014 Troopers OISF OHM OHM2013. Observe, Hack, Make Special thanks to Adrian Crenshaw for his collection of videos Posted by Mila Sursa: contagio: Video archives of security conferences

Bitstamp, a Bitcoin exchange based in the United Kingdom, remains offline this afternoon following what appears to have been a compromise over the weekend. The company tweeted shortly after 4 a.m. Monday that it had to temporarily halt all withdrawals because it believes one of its wallets was compromised Sunday. In a warning on its site, Bitstamp apologized for the inconvenience and claimed that following an investigation it would return to service and amend its security measures as appropriate. The exchange, which until 2013 was operated out of Slovenia, is the world’s third largest exchange by volume, according to BitcoinCharts.com. Another warning on the exchange’s site stresses that users refrain from making deposits to their previously issued Bitcoin addresses and that only deposits made prior to today can be covered by Bitstamp’s reserves. Users who try to deposit Bitcoin are confronted with the following message: Emails sent from Bitstamp customer support to verified users early this morning claim that its transaction processing server “detected problems” with its hot wallet and that effective immediately, it was suspending withdrawals. In Bitcoin-speak, a hot wallet refers to a wallet – a collection of private keys – that’s connected to the Internet. To quell users’ fears, Nejc Kodri?, Bitstamp’s co-founder and CEO insisted via tweet this morning that the bulk of the company’s Bitcoin are in cold storage – offline – and are unaffected by this incident. As Bitstamp’s site makes clear, the company only keeps a “small fraction” of Bitcoin in its online systems and that its offline reserves could cover any Bitcoin compromised. Kodri?, who currently is en route to the annual Consumer Electronics Show (CES) in Las Vegas, said he hoped to have an ETA for when Bitstamp could restore service later today. Many news outlets are speculating that what may have forced Bitstamp offline is potentially a random number generator (RNG) attack. More than 800 Bitcoin ($220,000 USD) was swept from blockchain.info wallets last month following a RNG security issue with blockchain.info wallets. johoe, a white hat hacker took credit for the sweep but later, as a sign of good faith, refunded the stolen Bitcoin to users who could prove it belonged to them. In an interview with CryptoCoinsNews last year, johoe claimed he was able to sweep any Bitcoin associated with addresses generated by a buggy Blockchain.info random number generator. Blockchain.info ultimately blamed the RNG vulnerability, which failed to ensure private keys were generated in a secure fashion, on a scheduled software update that was deployed overnight. It hasn’t even been a year since Mt. Gox – at one point, the largest Bitcoin exchange – collapsed after losing more than $450 million in Bitcoin. It wasn’t long after that the Tokyo-based exchange shuttered its website and filed for bankruptcy. Source

This tool, developed in 2010 by Justin Collins (@presidentbeef) is specifically for finding vulnerabilities and security issues in Ruby on Rails apps at any development stage. Brakeman is used by the likes of Twitter (where Justin is employed), GitHub, and Groupon to look for vulnerabilities. Justin gave a talk at RailsConf 2012 that’s worth watching describing the value of using SCA early on and how Brakeman accomplishes that. The Good: Easy setup and configuration and fast scans. Because it’s specifically built for Ruby on Rails apps, it does a great job at checking configuration settings for best practices. With the ability to check only certain subsets, each code analysis is able to be customizable to specific issues. The developer has been maintaining and updating the tool on a regular basis since its first release. The Not-So-Good: Because of its suspicious nature, the tool can show a high rate of false positives As written on the tool’s FAQ page, just because a report shows zero warnings doesn’t mean your application is flaw-free; “There may be vulnerabilities Brakeman does not test for or did not discover. No security tool has 100% coverage.” Sursa: Brakeman - Rails Security Scanner

------------------------------------------------------------------ GetSimple CMS <= 3.3.4 (api.php) XML External Entity Vulnerability ------------------------------------------------------------------ [-] Software Link: http://get-simple.info/ [-] Affected Versions: All versions from 3.1.1 to 3.3.4. [-] Vulnerability Description: The vulnerable code is located in the /admin/api.php script: 22. #step 2 - setup request 23. $in = simplexml_load_string($_POST['data'], 'SimpleXMLExtended', LIBXML_NOCDATA); 24. $request = new API_Request(); 25. $request->add_data($in); User input passed via the "data" POST parameter is not properly sanitized before being used in a call to the "simplexml_load_string()" function at line 23. This can be exploited to carry out XML External Entity (XXE) attacks, resulting in arbitrary file disclosures. Successful exploitation of this vulnerability requires the External API to be enabled from within the gsconfig.php file and the application running on PHP before version 5.3.23 or 5.4.13. NOTE: this vulnerability might be abused to disclose sensitive data stored in XML files, which might allow attackers to bypass the authentication mechanism and access the administration panel in order to achieve arbitrary PHP code execution. [-] Solution: Update to version 3.3.5 Beta 1 or disable the External API. [-] Disclosure Timeline: [22/10/2014] - First attempt to contact the vendor [28/10/2014] - Issue reported to http://git.io/HEjBUg [29/10/2014] - CVE number requested [13/11/2014] - CVE number assigned [02/12/2014] - Version 3.3.5 Beta 1 released [31/12/2014] - Publication of this advisory [-] CVE Reference: The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2014-8790 to this vulnerability. [-] Credits: Vulnerability discovered by Egidio Romano. [-] Original Advisory: http://karmainsecurity.com/KIS-2014-17 Source

In my last post, you may remember how the latest Uroburos rootkit was able to disarm Patchguard on Windows 7. I was recently looking into how Patchguard is implemented in Windows 8.1 and decided to dig into Exception Handling on x64. As a matter of fact, all the new 64-bit Windows operating systems have entirely changed the way they manage error conditions from their state in older 32-bit versions of Windows (C++ exceptions and OS Structured Exception handling). There are a lot of papers available on 64-bit Windows exception handling on the web, but I decided to increase my knowledge on this topic with the goal to understand how it is implemented and to correctly characterize some strange behavior associated with the implementation of Patchguard on Windows 8.1. Here are some interesting articles that can be found online: Exceptional Behavior - x64 Structured Exception Handling - OSR Online. The NT Insider, Vol 13, Issue 3, 23 June 2006. Skape, Improving Automated Analysis of Windows x64 Binaries - Uninformed, June 2006. A great article from Matt Miller Johnson, Ken. "Programming against the x64 exception handling support." - Nynaeve. N.p., 5 Feb. 2007. A very good serie of articles that deals with Windows Vista x64 SEH implementation written by Ken Johnson (Skywing) I strongly recommend that all the readers check out these 3 papers. I won't be rehashing any of the work there. I will also assume that the reader already knows how Windows Structured Exception Handling and C++ exceptions handling can be exploited to manage errors conditions. If not, I personally recommend the following book that explains very well how this is done: Richter, Jeffrey, and Christophe Nasarre. Windows via C/C++. Redmond, WA: Microsoft, 2007 Quick introduction As the 3 articles mentioned above explain, x64 exception handling is not stack-based. Therefore, a lot of Structured Exception Handling (SEH) attacks have became ineffective against 64 bit binaries. 64-bit Windows Portable Executables (PE) have what is called the "Exception Directory data directory". This directory implements the 64-bit version of exception handling. It’s the compiler’s duty to add the relative RUNTIME_FUNCTION structure in the exception directory for each chunk of code directly or indirectly involved with exception handling. Here's what this structure looks like: typedef struct _RUNTIME_FUNCTION { DWORD BeginAddress; // Start RVA of SEH code chunk DWORD EndAddress; // End RVA of SEH code chunk DWORD UnwindData; // Rva of an UNWIND_INFO structure that describes this code frame } RUNTIME_FUNCTION, *PRUNTIME_FUNCTION; Each runtime function points to an UNWIND_INFO structure that describes one of the most important feature of Windows error handling: the Frame Unwind. Before I describe what frame unwinding is, let’s take a look at the key structures related to the stack unwind (the “UnwindData” member of the RUNTIME_FUNCTION structure points to a UNWIND_INFO): // Unwind info flags #define UNW_FLAG_EHANDLER 0x01 #define UNW_FLAG_UHANDLER 0x02 #define UNW_FLAG_CHAININFO 0x04 // UNWIND_CODE 3 bytes structure typedef union _UNWIND_CODE { struct { UBYTE CodeOffset; UBYTE UnwindOp : 4; UBYTE OpInfo : 4; }; USHORT FrameOffset; } UNWIND_CODE, *PUNWIND_CODE; typedef struct _UNWIND_INFO { UBYTE Version : 3; // + 0x00 - Unwind info structure version UBYTE Flags : 5; // + 0x00 - Flags (see above) UBYTE SizeOfProlog; // + 0x01 UBYTE CountOfCodes; // + 0x02 - Count of unwind codes UBYTE FrameRegister : 4; // + 0x03 UBYTE FrameOffset : 4; // + 0x03 UNWIND_CODE UnwindCode[1]; // + 0x04 - Unwind code array UNWIND_CODE MoreUnwindCode[((CountOfCodes + 1) & ~1) - 1]; union { OPTIONAL ULONG ExceptionHandler; // Exception handler routine OPTIONAL ULONG FunctionEntry; }; OPTIONAL ULONG ExceptionData[]; // C++ Scope table structure } UNWIND_INFO, *PUNWIND_INFO; The compiler produces a RUNTIME_FUNCTION structure (and the related unwind info data) for almost all procedures directly or indirectly related with SEH (or C++ exceptions). The only exception, as outlined in "Programming against the x64 exception handling support.", is for the leaf functions: these functions are not enclosed in any SEH blocks, don’t call other subfunctions and make no direct modifications to the stack pointer (this is very important). Let’s assume that a parent function surrounded by a __try __except block calls another function from its __try code block. When an exception occurs in the unprotected sub function, a stack unwinding occurs. The Windows kernel MUST indeed be able to restore the original context and find the value of the RIP register (instruction pointer) from before the call to the sub function had occurred (or a call to a function that subsequently jumps to the leaf function). This procedure of unwinding the stack is called Frame Unwind. The result of Frame Unwind is that the state of the key registers, including the stack, are restored to the same state as before the call to the exception-causing function. This way, Windows can securely detect if an exception handler (or terminator handle) is present, and subsequently call it if needed. The frame unwind process is the key feature of the entire error management. The unwind process is managed in the Windows kernel and can be used even in other ways (take a look at RtlVirtualUnwind kernel function, which is highlighted in Programming against the x64 exception handling support). Exception Handling implementation - Some internals The Skywing articles (mentioned at the beginning of the paper - Programming against the x64 exception handling support) cover the nitty gritty details of the internals of stack unwind in the 64-bit version of Windows Vista. The current implementation of unwind in Windows 8.1 is a bit different but the key concepts remain the same. Let's take a look at exception handling. The internal Windows function RtlDispatchException is called whenever an exception occur. This function is implemented in the NTDLL module for user mode exceptions, and in the NTOSKRNL module for kernel mode exceptions, although in a slightly different manner. The function begins its execution by performing some initial checks: if a user-mode “vectored” exception handler is present, it will be called; otherwise standard SEH processing takes place. The thread context at the time of exception is copied and the RtlLookupFunctionEntry procedure is exploited to perform an important task: to get the target Image base address and a Runtime Function structure starting with a RIP value, that usually points to the instruction that has raised the exception. Another structure is used: the Exception History Table. This is, as the name implies, a table used by the Windows kernel to speed up the lookup process of the runtime function structure. It is not of particular interest, but for the sake of completeness, here's its definition: #define UNWIND_HISTORY_TABLE_SIZE 12 typedef struct _UNWIND_HISTORY_TABLE_ENTRY { ULONG64 ImageBase; PRUNTIME_FUNCTION FunctionEntry; } UNWIND_HISTORY_TABLE_ENTRY, *PUNWIND_HISTORY_TABLE_ENTRY; typedef struct _UNWIND_HISTORY_TABLE { ULONG Count; // + 0x00 USHORT Search; // + 0x04 USHORT bHasHistory; // + 0x06 ULONG64 LowAddress; // + 0x08 ULONG64 HighAddress; // + 0x10 UNWIND_HISTORY_TABLE_ENTRY Entries[UNWIND_HISTORY_TABLE_SIZE]; } UNWIND_HISTORY_TABLE, *PUNWIND_HISTORY_TABLE; If no runtime function is found, the process is repeated using the saved stack frame pointer (RSP) as RIP. Indeed in this case, the exception is raised in a leaf function. If the stack frame pointer is outside its limit (as in the rare case when a non-leaf function does not have a linked RUNTIME_FUNCTION structure associated with it), the condition is detected and the process exits. Otherwise, if the RUNTIME_FUNCTION structure is found, the code calls the RtlVirtualUnwind procedure to perform the virtual unwind. This function is the key of exception dispatching: starting with the Image base, the RIP register value, the saved context and a RUNTIME_FUNCTION structure, it unwinds the stack to search for the requested handler (exception handler, unwind handler or chained info) and returns a pointer to the handler function and the correct stack frame. Furthermore, it returns a pointer to something called the “HandlerData”. This pointer is actually the SCOPE TABLE structure, used for managing C++ exceptions. This kind of stack unwind is virtual because no unwind handler or exception handler is actually called in the entire process: the stack unwind process is actually stopped only when a suitable requested handler is found. With all the data available, the NT kernel code now builds the DISPATCHER_CONTEXT structure and exploits RtlpExecuteHandlerForException to perform the transition to the language handler routine (_C_specific_handler in the case of SEH and C++ exceptions). It is now the duty of the language handler routine to correctly manage the exception. // Call Language specific exception handler. // Possible returned values: // ExceptionContinueExecution (0) - Execution must continue over saved RIP // ExceptionContinueSearch - The language specific dispatcher has not found any handler // ExceptionNestedException - A nested exception is raised // ExceptionCollidedUnwind - Collided unwind returned code (see below) // NO Return - A correct handler has processed exception EXCEPTION_DISPOSITION RtlpExecuteHandlerForException(EXCEPTION_RECORD *pExceptionRecord, ULONG64 *pEstablisherFrame, CONTEXT *pExcContext, DISPATCHER_CONTEXT *pDispatcherContext); he implementation of RtlDispatchException in kernel mode is quite the same, with 3 notable exceptions: No Vectored exception handling in kernel mode A lot of further checks are done, like data alignment and buffer type checks RtlVirtualUnwind is not employed (except for collided unwinds), but an inlined unwind code is exploited (that relies on the internal procedures RtlpUnwindOpSlots and RtlpUnwindEpilogue) SEH and C++ Language specific Handler The standard SEH and C++ exception handler is implemented in the _C_specific_handler routine. This routine is, like the RtlDispatchException, implemented either in user mode or in the kernel. It starts by checking if it was called due to a normal or collided unwind (we will see what a collided unwind is later on). If this is not the case, it retrieves the Scope Table, and starts cycling between all of the entries in table: if the exception memory address is located inside a C++ scope entry segment, and if the target member of the scope table is not zero, the exception will be managed by this entry. The handler member of the scope entry points to an exception filter block. If the pointer is not valid, and the struct member is 1, it means that the exception handler has to be always called. Otherwise the exception filter is called directly: DWORD ExceptionFilter(PEXCEPTION_POINTERS pExceptionPointers, LPVOID EstablisherFrame); The filter can return one of these three possible dispositions: EXCEPTION_CONTINUE_EXECUTION - The C specific handler exits with the value ExceptionContinueExecution; code execution is then resumed at the point where the exception occurred (the context is restored by the internal routine RtlRestoreContext) EXCEPTION_CONTINUE_SEARCH - The C specific handler ignores this Scope item and continues the search in the next Scope table entry EXCEPTION_EXECUTE_HANDLER - The exception will be managed by the _C_specific_handler code If the filter returns the code EXCEPTION_EXECUTE_HANDLER, the C specific handler prepares all the data needed to execute the relative exception handler and finally calls the routine RtlUnwindEx. This function unwinds the stack and calls all the eventual intermediate __finally handlers, and the proper C exception handler. The routine is called by the C-specific handler in a particular way: the target C++ exception handler pointer is passed in the “TargetIp” parameter, while the original exception pointer is located in the exception record structure. This is a very important fact, as this way all the eventual intermediate terminator handlers are called. If the C-specific handler had call the specific exception handler directly, all the intermediate __finally handlers would have been lost, and the collided unwinds (a particular unwind case) would have been impossible to manage. RtlUnwindEx doesn’t return to the caller if it’s able to identify the real exception handler. Here we provide all the data structures related to the Scope table: // C Scope table entry typedef struct _C_SCOPE_TABLE_ENTRY { ULONG Begin; // +0x00 - Begin of guarded code block ULONG End; // +0x04 - End of target code block ULONG Handler; // +0x08 - Exception filter function (or “__finally” handler) ULONG Target; // +0x0C - Exception handler pointer (the code inside __except block) } C_SCOPE_TABLE_ENTRY, *PC_SCOPE_TABLE_ENTRY; // C Scope table typedef struct _C_SCOPE_TABLE { ULONG NumEntries; // +0x00 - Number of entries C_SCOPE_TABLE_ENTRY Table[1]; // +0x04 - Scope table array } C_SCOPE_TABLE, *PC_SCOPE_TABLE; The important thing to note is that if there is a valid handler routine in the Scope Table entry but the target pointer is NULL, it means that the related target code is enclosed by a "finally" block (and only managed by the unwinding process). In this case the handler member points to the code located in the finally block. Particular cases Frame Consolidation Unwinds As outlined in "Programming against the x64 exception handling support", this is a special form of unwind that is indicated to RtlUnwindEx with a special exception code, STATUS_UNWIND_CONSOLIDATE. This exception code slightly changes the behavior of RtlUnwindEx; it suppresses the behavior of substituting the TargetIp argument to RtlUnwindEx with the Rip value of the unwound context (as already seen in the C-specific handler routine). Furthermore, there is special logic contained within RtlRestoreContext (used by RtlUnwindEx to realize the final, unwound execution context) that detects the consolidation unwind case, and enables a special code path that treats the ExceptionInformation member of ExceptionRecord structure as a callback function, and calls it. Essentially, consolidation unwinds can be thought of as a normal unwind, with a conditionally assigned TargetIp whose value is not determined until after all unwind handlers have been called, and the specified context has been unwound. This special form of unwind is in often used in C++ exceptions. Collided unwinds A collided unwind, as the name imply, occurs when an unwind handler routine initiates a secondary unwind operation. An unwind handler could be for example a SEH terminator handle (routine that implements the __finally block). A collided unwind is what occurs when, in the process of stack unwind, one of the call frames changes the target of an unwind. This definition is taken from "Programming against the x64 exception handling support", and I found quite difficult to understand at the first sight. Let’s see an example: int _tmain(int argc, _TCHAR* argv[]) { // Let's test normal unwind and collided unwind TestUnwinds(); return 0; } // Test unwind and Collided Unwinds BOOLEAN TestUnwinds() { BOOLEAN retVal = FALSE; // Returned value DWORD excCode = 0; // Exception code // Test unwind and Collided Unwinds __try { // Call a function with an enclosed finally block retVal = TestFinallyFunc(); } __except( // Filter routine excCode = GetExceptionCode(), EXCEPTION_EXECUTE_HANDLER ) { wprintf(L"Exception 0x%08X in TestUnwinds.\r\n " L"\tThis message is not shown in a Collided Unwind.\r\n", excCode); } wprintf(L"TestUnwinds func exiting...\r\n"); return retVal; } // Test unwind and Collided Unwinds BOOLEAN TestFinallyFunc() { LPBYTE buff = NULL; BOOLEAN retVal = FALSE; BOOLEAN bPerformCollided = 0; // Let’s set this to 1 afterwards buff = (LPBYTE)VirtualAlloc(NULL, 4096, MEM_COMMIT, PAGE_READWRITE); do { __try { // Call Faulting subfunc with a bad buffer address retVal = FaultingSubfunc1(buff + 3590); // Produces CALL _local_unwind assembler code if (!retVal) return FALSE; // <-- 1. Perform a regular unwind // Produces JMP $LN17 label (finally block inside this function) //if (!retVal) __leave; } __finally { if (!_abnormal_termination()) wprintf(L"Finally handler for TestFinallyFunc: Great termination!\r\n"); else wprintf(L"Finally handler for TestFinallyFunc: Abnormal termination!\r\n"); if (buff) VirtualFree(buff, 0, MEM_RELEASE); if (bPerformCollided) { // ? 2. Perform COLLIDED Unwind // Here we go; first example of COLLIDED unwind goto Collided; // Second example of a collided unwind break; // Other example of collided unwind: return FALSE; } } Sleep(5000); } while (!retVal); return TRUE; collided: wprintf(L"Collided unwind: \"Collided\" exit label.\r\n"); return 0; // Std_Exit: } The example shows some concepts explained in this analysis. TestUnwinds is the main routine that implements a structured exception handler. For this routine, a related RUNTIME_FUNCTION structure, followed by a C_SCOPE_TABLE, is generated by the compiler. The scope table entry contains either an handler, and a target valid pointers. The protected code block transfers execution to the TestFinallyFunc procedure. The latter shows how a normal unwind works: when FaultingSubfunc1 raises an exception, a normal stack unwind takes place: the stack is unwound and the first __finally block is reached. Keep in mind that in this case only the code in the __finally block is executed (the line with the “Sleep” call is never reached), then the stack frame unwind goes ahead till the __except block (exception handler) of the main TestUnwinds procedure. This is the normal unwind process. A normal unwind process can even be manually initiated, forcing the exit from a try block: the “return FALSE;“ line in the __try block is roughly translated by the compiler to the following: mov byte ptr [bAutoRetVal], 0 lea rdx, $LN21 mov rcx,qword ptr [pCurRspValue] call _local_unwind $LN21: mov al, byte ptr [bAutoRetVal] goto Std_Exit The compiler uses the _local_unwind function to start the stack unwind. The _local_unwind function is only a wrapper to the internal routine RtlUnwindEx, called with only the first 2 parameters: TargetFrame is set to the current RSP value after the function prolog; TargetIp is set to the exit code chunk pointer as highlighted above... This starts a local unwind that transfers execution to the __finally block and then returns to the caller. The stack unwind process is quite an expensive operation. This is why Microsoft encourages the use of the “__leave” keyword to exit from a protected code block. The “__leave” keyword is actually translated by the compiler as a much faster “jmp FINALLY_BLOCK” opcode (no stack unwind). Now let’s test what happens when a bPerformCollided variable is set to 1…. In the latter case, FaultingSubfunc1 has already launched a stack unwind (due to an exception) that has reached the inner __finally block. The three examples of collided unwind code lines generate quite the same assembler code like the manually initialized normal stack unwind (but with a different TargetIp pointer). What happens now? A stack unwind process begins from an already started unwind context. As result, the RtlpUnwindHandler internal Nt routine (the handler associated with RtlpExecuteHandlerForUnwind) manages this case. It restores the original DISPATCHER_CONTEXT structure (except the TargetIp pointer) and returns ExceptionCollidedUnwind constant to the caller (the second call to RtlUnwindEx). We don’t cover the nitty gritty implementation details here, but we encourage the reader to check the Skywing articles (http://www.nynaeve.net/?p=113). A side effect of the Collided unwinds in the SEH implementation is that we lose the parent function exception handler: the code flow is diverted and the compiler informs the developer with the C4532 warning message. The message located in the TestUnwinds exception handler routine of our example is indeed never executed when a collided unwind occurs. Conclusion In this blog post we took a hard look at the implementation of the Windows 8.1 64-bit Structured Exception handling. We even analysed one of the most important concepts related to SEH: the stack unwind process, and two of its particular cases. The implementation of the last case, the so called “Collided unwind”, is very important for the Windows 8.1 Kernel, because the Kernel Patch Protection feature uses it heavily, rendering its analysis much more complicated. In the next blog post we will talk about how Patchguard is implemented in Windows 8.1. I'll also go over how the Uroburos rootkit defeated Patchguard in Windows 7 and how those techniques no longer work on Windows 8.1. Stay tuned! Source

Exista aici vre-un admin sau mod pe forumul ComputerGames ?

Merge destul de greu cu tutorialele/examenele pentru ca am r?mas doar eu sa ma ocup de ele. Avem o serie de tutoriale care inca nu le-am urcat. Urmeaz? sa schimbam tot ce tine de frontend si sa modificam examenele. In scurt timp vom introduce versiunea in engleza a platformei. Ps: c?utam persoane care stiu php si securitate web care sa ne ajute.

Deci nu în?eleg de ce sar cu gura ni?te mocofle?i s? comenteze ei cum c? e penibil @Elohim s-a legat de semn?tura ?i modul de scriere a prostului ?la numit zachary1337. Domni?oarelor.

Cand a facut reckon topic de retragere l-ati injurat si ati spus ca nu trebuia sa faca topic...

Iti trebuie un buget de +5k euro pentru ceva nou si bun.

Returneaz?-l prin curier la magazinul de unde l-ai luat.dai PM pentru detalii

Salut, Plot A?i avut acces fizic la calculatorul lui Viorel. În cele 10 secunde cât a?i avut acces pe ecran a?i putut observa c? are un fi?ier linkuri.txt plin de site-uri funny. Viorel, plictisit fiind, viziteaza aproape zilnic, o singur? dat? pe zi, link-uri de pe acolo. A?i reu?it s? v? scrie?i link-ul c?tre un site propriu acolo, cu scopul de a avea acces la calculatorul lui mai târziu. Tehnic Posta?i ca reply un link hostat de voi, ce vre?i voi. Viorel cel mai probabil îl va vizita. Ce trebuie s? fac? S? afla?i numele hamsterului lui Viorel. Premiu O carte de structuri de date sau un cozonac. Probabil Sâmb?t? seara Viorel va fi prima oar? plictisit. Pute?i colabora între voi. Mult succes.

Ám fácut contul áseárá si nici ácum nu e áctivát

Imi doream de mult sa invat si sa pot sa si testez fara a dauna altora. PS: Ceva bug-uri CSS la fereastra de feedback. Z-index issues. PS2 : O varianta pt mobile n-ar dauna sa pot citi pe drum spre munca.

Felicitari foarte dragut site-ul. Ma voi apuca si eu de citit. Keep doing the good work !

si o mentiune: vedeti ca mailul de inregistrare intra in spam, va rog marcati ca NOT SPAM. LE: asta apare scris cu alb pe alb la mine: <div class="current_progress redd" style="width:0%;border-top-right-radius:100px;border-bottom-right-radius:100px;">0% COMPLETE</div> LE2: citesc sa zicem asta: http://www.pwnthecode.org/learn/xss/capitolul1.php sterg din url coada si ramane doar asta: http://www.pwnthecode.org/learn/xss/ se regaseste tot articolul fara CSS si cu imaginile nefunctionale... feature sau bug arata urat.

In curand va fi adaugat un loc special pentru tutoriale despre Networking / Linux / Unix / Tutoriale PHP , HTML , CSS etc. testate si scrise de echipa PWNTHECODE.

Inainte era error on line 8 ( categorii ); Acum imi da eroare pe 10 :s

Ceva de mentionat ar fi faptul ca functioneaza doar pe interfata Gnome, deci celor care au Linux Mint(sau orice alta distributie) cu interfata Cinnamon/MATE/Unity(Ubuntu)/orice altcv nu le va merge

Linux: command to open URL in default browser - Stack Overflow

Hello all, this is a little tutorial for takeover a website by using simple session variables at first we need a shell on the target with rights to excute php comands. and we need a target like a admin panel maybe you want to grab the pw & username but you failed because the hash is hashed in sha256 or something like that. so we need a other way to login in this time we can use they own login method if(!empty($_POST["pw"]) && !empty($_POST["us"])){ $row = mysql_fetch_object($res); if(md5($_POST["pw"])==$row->password && $_POST["us"]==$row->username){ $_SESSION["adminID"] = $row->adminID; $_SESSION["username"] = $row->username; $_SESSION["login"] = "1"; header("Location: users.php"); } }else{exit();} we see here a login with using sessions Note : Sessions are server-side variables. if we wont access to that admin panel we need just to do that : $_SESSION["adminID"] = "0"; $_SESSION["username"] = "admin"; $_SESSION["login"] = "1"; and we call the php file with that content and we can access the admin panel and we bypass the site authentication Credits to: T3N38R15

Dupa cum spune titlul aveti 15 zile moca si primiti 30 zile per refferal. Puteti aduce maxim 6 oameni . Aveti la dispozitie 8 tari iar vpn-ul chiar este bun si viteza la net este umpic mai buna , cel putin pentru mine. http://goo.gl/2Nwtva