Nytro

Firefox 4 Set to Improve Security September 8, 2010 By Sean Michael Kerner The race to accelerate browser features continues as Mozilla developers race towards the finish line to get the finished version of the Firefox 4 Web browser out the door. The first Firefox 4 beta was released in early July of this year and the final release is due by the end of the year. Along the way to its final generally available release, Mozilla developers have been issuing milestone releases with new features and bug fixes. Firefox 4 development is occurring at a time when rival browser vendor Google (NASDAQ: GOOG) is updating it Chrome browser to version 6 and Microsoft is working on Internet Explorer 9. Firefox 4 Beta 5 is set to debut this week providing testers with new hardware accelerated graphics capabilities and an implementation of the IETF HTTP Strict Transport Security (HSTS) draft standard. "A while ago, we talked about Force-TLS that lets sites say 'hey, only access me over HTTPS in the future' and the browser listens," Mozilla developer Sid Stamm blogged. "Well, this idea has been solidified into a draft spec for HTTP Strict Transport Security (HSTS) and we’ve landed support for it into our source tree. This means that HSTS will be shipped with Firefox 4, and will be deployed as soon as the next beta release." The HSTS specification will enable site owners to ensure that browsers visit the SSL (define) secured version of a website instead of going through an unencrypted non-SSL HTTP address first. SSL secured sites help to ensure that password, login and other sensitive information is encrypted. "If Firefox knows your host is an HSTS one, it will automatically establish a secure connection to your server without even trying an insecure one," Stamm blogged. "This way, if I am surfing the 'net in my favorite cafe and a hacker is playing MITM with paypal.com (intercepting http requests for paypal.com and then forwarding them on to the real site), either I'll thwart the attacker by getting an encrypted connection to paypal.com immediately, or the attack will be detected by HSTS and the connection won't work at all." What will Firefox 4 Include – and leave out? While the Beta 5 release includes new features, the final feature freeze for Firefox 4 is likely coming soon. A number of features that were originally set for inclusion of Firefox 4 have already been dropped including a new Account Manager tool. On Mozilla's platform wiki, the open source organization has also noted in its latest meeting notes that new Windows silent updating feature may be at risk from being dropped from the final release. The silent update feature is one that is intended to run in the background and update the Firefox browser as new security releases come out. With Beta 5 out the door, Mozilla developers are turning their attention to Beta 6 which is currently scheduled for a code freeze on Friday September 10th. During a conference call on Tuesday, Mozilla's director of Firefox, Mike Beltzner noted that there are currently 114 blockers (items still to be fixed and/or completed) and as such he's not sure that the September 10th date for a Beta 6 code freeze will be achievable. "I would also like to avoid a repeat of landing particularly risky changes right before a code freeze, which is what happened with Beta 5," Beltzner said. "As a result, Beta 5 will ship with some drawing regressions, especially on Mac."

Mozilla Labs Launches Gaming Initiative Sep 08, 2010 Platform based on open Web technologies. Mozilla Labs announced its newest initiative, a gaming platform appropriately named Mozilla Labs: Gaming. The goal of the platform is to create browser-based games built on Open Web standards. "We invite the wider community to play with cool, new tech and aim to help establish the Open Web as the platform for gaming across all your Internet connected devices," Pascal Finette from Mozilla Labs said. Some of the technologies Mozilla Labs Gaming utilizes include webGL, touch controls, geolocation, Javascript, and open video and audio. Games built on HTML5 are available freely on sites like HTML5games.com, but with Mozilla's new initiative looks to advance games. Mozilla Labs Gaming is also launching an international gaming competition to drive developer interest to the burgeoning platform. Aptly titled Game_On 2010, the competition will open at the end of September. (Trevan McGee)

Sean Michael Kerner Wednesday, September 8, 2010 11:14:55 AM Recent years have seen the Ubuntu Linux distribution, led by Canonical, experiencing rapid growth in both users and features. With the upcoming Ubuntu 10.10 Maverick Meerkat release, set for October, Ubuntu developers will continue to push the boundaries further of both server and desktop Linux. Sitting at the upper rung of Ubuntu's engineering efforts is Matt Zimmerman, Canonical's CTO, who helps to lead Ubuntu's technical direction. That's no small feat: Keeping the project and its developers organized is a mammoth undertaking, requiring the daily coordination of activities across the globe. But as Zimmerman describes it, he has the tools and processes in place to keep the Ubuntu project running strong. One way that Zimmerman keeps the project on track is ensuring close communication among members of his team, a disparate organization that mirrors how the Ubuntu community itself builds and develops its Linux distribution. For one thing, While Canonical has offices in multiple countries, most of Zimmerman's engineers aren't located in those offices. "My team is about 120 people and I think we have less five people who are in offices," Zimmerman told InternetNews.com. While Zimmerman noted that he does get together face-to-face fairly regularly with his staff once a quarter, facilitating regular interaction requires a long list of common tools. For instance, Zimmerman said that Canonical engineers do a lot of work through IRC , wikis and teleconferences. The team also uses the open source Gobby tool for collaborative editing and Mumble for voice chatrooms. "Mumble is sort of like IRC for voice," Zimmerman said. "You have a set of channels and then people come and go from one channel to another and whatever channel you're in, there is live voice between the people that are in the room." Engineering organizations are often big users of whiteboards to build and share ideas, and Ubuntu is no exception. While his staff and contributors are distributed, Zimmerman said that they do rely on some desktop and screen-sharing, though he added that there isn't a one-to-one whiteboard substitute. For overall project and goal management, Canonical is using its own Launchpad platform. "Launchpad provides some basic project management support," Zimmerman said. "We've developed other tools around that for tracking." Zimmerman described the project's overall management as using a blueprint -- a project plan on which individual tasks are broken out. Canonical also has a tool that extracts data out of Launchpad and does reporting. One of the key reporting elements used by Zimmerman is a burn-down chart, an important element of the Scrum agile software development methodology. "It's basically a bar chart that shows you how much work you have remaining to do in your iteration," Zimmerman said. "So if you start off with, say, 200 tasks, you then draw it down to zero and you track it as you go if you're above or below the trend line." Though Zimmerman is using a Scrum-style burn-down chart to track project progress, he added that he isn't strictly adhering to any one particular development methodology. "We're using bits and pieces of different methodologies," Zimmerman said. "We use some components from Extreme Programming (XP), Scrum, and others. Different engineering teams have different requirements so we're experimenting with different approaches." From an accounting perspective, however, Zimmerman noted that by using elements of the Scrum approach, he is able to report on the output capacity of his team. "So we know in this amount of time how much we are able to get done and that enables more accurate forecasting," Zimmerman said. From a testing perspective, the Ubuntu engineering organization has multiple efforts underway. Zimmerman explained that hardware certification testing occurs in a hardware lab where daily, automated compatibility testing occurs. There are also automated functional tests to ensure that users can upgrade cleanly from one release to another. Then there is also manual testing, which is crowdsourced by the Ubuntu community. Ubuntu developers don't operate in a vacuum and are part of the broader upstream open source ecosystem. As a result, patches and contributions are made upstream by Zimmerman's team in an ongoing process. Sometimes, Ubuntu will have patches that have not yet been merged upstream. "We do carry patches on top of upstream, but we have to in order to meet our deadlines," Zimmerman said. "Our goal is to keep the delta as small as we can. Every release cycle, we spend a good amount of our engineering time bringing our patch set forward." Ubuntu also relies heavily on its relationship with the Debian Linux distribution, and Zimmerman noted that the vast majority of Ubuntu patches submitted to Debian are accepted. He added that with other upstream projects, where Ubuntu doesn't do as much work, there can be challenges. "It's tough since we have to work across so many different projects with Ubuntu," Zimmerman said. "We can't have a close personal relationship with everyone in the open source community, but at the same time, we've got to be able to work together."

Inca un ban. Multi ratati pe aici. Un fisier se inchidea imediat dupa rulare, ascundea fisierele ascunse, bloca task manager. Nu am stat sa verific mai multe.

Greerasu nu poate veni, nu e in Romania. Da-mi ID-ul tau pe MP.

Lasati complimentele. Deci, cine e din VL si da de baut?

Nu ruleaza pe masina virtuala, se inchide imediat la rulare, deci ban

Mi-a venit si mie update-ul pentru asta de la OpenSUSE. Avantajul open-source-ingului... Si mi-au venit mai multe update-uri de securitate pentru kernel, faceti update.

E de la rewrite 1337 e ID-ul acelui topic.

Dai de baut? 2-3 beri acolo.

dwtf v1.0 and its Features dwtf creates a fake.dll from real.dll Features: 1- It exports all symbols of real.dll (also Forwarder). 2- It imports all exports of real.dll (also Forwarder). 3- It creates an area code with a JMP DWORD [ADDRESS] for each export. 4- The exports of fake dll is assigned to a JMP area which jumps to original export of real.dll. Working of dwtf v1.0 If you are making PEB HOOKING, when the APP calls to fake dll export it jumps to original export, everything works fine: Before PEB HOOKING: APP -> IAT OF APP -> REAL DLL EXPORT After PEB HOOKING: APP -> IAT OF APP -> FAKE DLL EXPORT -> IAT OF FAKE DLL -> REAL DLL EXPORT You can add or remove payloads with any IAT HOOKING in the IAT of the fake dll: APP -> IAT OF APP -> FAKE DLL EXPORT -> IAT OF FAKE DLL -> PAYLOAD STACK -> (or never) REAL DLL EXPORT Syntax: dwtf.exe fake_dll real_dll Example: dwtf.exe k32.dll c:\windows\system32\kernel32.dll All .exes are in bin folder: You can execute the: Generate fake kernel32.bat This bat executes dwtf creating a fake kernel32.dll called k32.dll from c:\windows\system32\kernel32.dll After, you can make a pebhooking executing: PEB hooking poc with fake kernel32.bat IMPORTANT: You need the NETCAT for send commands to the console: This bat inject a console.dll in the poc.exe process using InjectorDll.exe This console listen by default in 127.0.0.1 1234, This console is the interface to do PEB Hooking: Next, the bat connect to 127.0.0.1 1234 using nc command (netcat) In the console with netcat you can write: pebhook kernel32.dll k32.dll resume exit In this moment poc.exe is running and it is waiting a user enter: poc.exe try creates files with two APIs of kernel32.dll: CreateFileW and CreateFileA When you press enter all works fine (good lucky) and the process exits creating files. In this scenario all works by this way: poc.exe -> IAT of POC.EXE -> k32.dll (fake kernel32.dll) -> IAT of k32.dll -> kernel32.dll Loading payloads dynamically: For this scenario: poc.exe -> IAT of POC.EXE -> k32.dll (fake kernel32.dll) -> IAT of k32.dll -> payload/s Remember: You can add a payload stack with IAT HOOKING over IAT HOOKING ... The payloads can calls to original kernel32.dll export. You need: Generate fake kernel32.bat PEB hooking poc with fake kernel32.bat command: pebhook kernel32.dll k32.dll Add a payload for CreateFileW, inserting a iat hook in k32.dll: Inject the dll: InjectorDll.exe poc_dll.dll -p PID_OF_POC_EXE In the POC.EXE you can see: Creating files... press enter DLL INJECTED! ADDR OF OwnCreateFileA: 0x70651030 < --- For EXAMPLE It is the time of IAT hooking of CreateFileA of k32.dll to OwnCreateFileA of poc_dll.dll Example of searching CreateFileA IAT ADDR in k32: Using peview (google: download peview): Search the oridinal of CreateFileA like this image: Search IAT ADDR in k32 of CreateFileA like this image: In the IMAGE the IAT ADDR is: 0x1000C1A6 Change the IAT to payload addr: write_process_memory.exe PID_OF_POC_EXE 0x1000C1A6 0x70651030 0x70651030 is the addr of OwnCreateFileA of poc_dll.dll injected in POC.exe In the console with netcat you can write: resume exit Credits dwtf 1.0 (MIT License) engine by Dreg, from evil fingers: - making FULL dll (PEB/file) hooking more easy... - Greetz: Lacon 2k9 Spain & Hispasec team. - Note: Use with real DLLs, a lot of bugs in this version contact me: dreg@fr33project.org Video: http://www.youtube.com/watch?v=t7UXEJieliM Download: http://rootkitanalytics.com/downloadCounter.php?id=7

SpyDLLRemover v3 SpyDLLRemover is the standalone tool to effectively detect and delete spywares from the system. It comes with advanced spyware scanner which quickly discovers hidden Rootkit processes as well suspcious/injected DLLs within all running processes. It not only performs sophisticated auto analysis on process DLLs but also displays them with various threatlevels, which greatly helps in quick identification of malicious DLLs. The DLL search feature helps in finding DLL within all running processes using just partial or full name. Then user can choose to remove the dll from single process or from all loaded processes with just one click. One of the unique feature of SpyDLLRemover is its capability to free the DLL from remote process using advanced DLL injection method which can defeat any existing Rootkit tricks. It also uses sophisticated low level anti-rootkit techniques to uncover hidden userland Rootkit processes as well as to terminate them. SpyDLLRemover comes with support for Microsoft's latest operating system, Windows 7. Apart from this, it introduces new 'Scan Settings' option to allow the user to fine tune the scanning operation. Also it features improved heurestic analysis, enriched user interface, Intelli-Refresh of 'Process Viewer' and more. Current version provides support for malicious DLL removal from system processes across session boundaries breaking the limitations imposed in Vista/Win7. Features of SpyDLLRemover v3 Here are some of the prominent and unique features of SpyDLLRemover which set it apart from any other tool of its kind. * Advanced Spyware Scanner which efficiently discovers hidden Rootkit processes as well as suspicious/injected DLLs within all running processes in the system. * Detection and removal of hidden userland Rootkit processes using sophisticated techniques such as - Direct NT System Call Implementation - Process ID Bruteforce Method (PIDB) as first used by BlackLight - CSRSS Process Handle Enumeration Method * State of art technique for completely freeing the injected DLL from remote process based on advanced DLL injection method using low level implementation which defeats any blocking attempts by Rootkits. This is one of those unique features found only in SpyDLLRemover. * Sophisticated DLL auto analysis which helps in seperating out the legitimate modules/DLLs from the malicious ones. Such DLLs are displayed using different colors representing various threat levels for quicker and easier identification. * 'Scan Settings' option to fine tune the scanning operation based on user needs. * Inteli-Refresh of 'Process Viewer' leading to flicker free user experience. * Integrated online verification mechanism through ProcessLibrary.com to validate any suspcious DLLs. This makes it easy to differentiate between the spyware & legitimate DLLs. * DLL Tracer feature to search for dll within the running processes using partial or full name. Then user can choose to remove the dll from single process or from all loaded processes with just one click. * Sort the process/DLL in the list based on various parameters for easier and quicker analysis. * Detailed report generation of Spyware scanning result as well as process/DLL list in standard HTML format for offline investigation. * View the process/DLL properties for more information by just double clicking on the process/DLL entry in the list. * Feature to show all running processes in the system which has loaded the selected DLL. Also user can click on "Remove DLL from ALL' button to quickly remove any such malicious DLL from all loaded processes. * Termination of suspicious or hidden process based on low level implementation which makes it very effective against any Rootkit techniques. * Support for malicious DLL removal from system processes across session boundaries breaking the limitations imposed in Vista/Win7. * Displays detailed information about all running processes on the system - Process name - Process Id - Session Id - Company Name - Product Name - Process Description - Memory Utilization - Process Binary Path - Process File Size - File Install Date * Shows detailed information about each loaded DLLs within process to make it easier for manual analysis. - DLL Name - Company Name - Description - Comment about type of DLL (System, Hidden, Suspicious) - Load/reference count of DLL - Loading Type (static/dynamic) - DLL File Size - File Install Date - Base Address of DLL - Entry point of DLL - Full DLL File Path * It is standalone tool which does not require any installation and can be executed directly. * Enriched user interface along with more user friendly options makes it the cool tool. Download: http://rootkitanalytics.com/downloadCounter.php?id=6

A, credeam ca esti tu. Ca tu esti singurul din VL de aici pe care il stiu. Daca dai o bere, doua vin Oricum, cred ca avem prieteni comuni, cred ca am vazut poze cu tine pe facebook-urile unor amici, nu mai stiu.

E din Valcea? Cred ca Axu ala e.

E vechi de 2 ani, nici nu cred ca il mai am (nu l-am gasit). Oricum e inutil, nu ai ce face cu el.

Toata lumea "cearta" cartegoria Offtopic. Ok, ce ziceti daca va dau ban daca va prind pe acolo (Online list)? Cine e de acord sa primeasca ban daca intra acolo? In mare, nu o sa fie mari schimabari. Nu forumul trebuie schimbat ci mentalitatea membrilor. Nu pot obliga pe nimeni sa citeasca un tutorial sau sa scrie un articol. Incepeti prin a da propriul exemplu. Chiar vreau sa va vad in zilele ce urmeaza "la treaba". Nu stiu de ce, dar sunt sigur ca nu o sa vad nimic. Vreti o schimbare? Incepeti prin a va schimba pe voi insiva.

Nu cred ca e mai bun nici decat Cain & Abel nici decat Wireshark, nici decat CommView sau altele. E simplu si asta imi place cel mai mult la el. In plus, e open-source. Oricum, nu am spus ca este mai bun decat Cain & Abel.

Tot legat de acest subiect, ar fi frumos sa fie promovat open-source-ingul si pe Windows... Hmm, cred ca aici incepe sa apara legatura hacking <-> Linux.

Cum sa spun... Programul probabil apeleaza niste functii pe care le apeleaza si niste troieni. Si probabil semnatura antivirusilor facuta pe aceste apeluri. Asta cred ca este cauza. Nu l-am incercat, dar eu am incredere in cei de la securityxploded.

Evitati astfel de comentarii. ICEBREAKER101010: De ce nu ai postat tu ultima versiune? In plus, eu poate vreau versiunea asta. OnTopic: E foarte bun programul asta, vi-l recomand.

By Mark Russinovich 8 Jul 2009 2:21 AM This is the fourth post in my Pushing the Limits of Windows series that explores the boundaries of fundamental resources in Windows. This time, I’m going to discuss the limits on the maximum number of threads and processes supported on Windows. I’ll briefly describe the difference between a thread and a process, survey thread limits and then investigate process limits. I cover thread limits first since every active process has at least one thread (a process that’s terminated, but is kept referenced by a handle owned by another process won’t have any), so the limit on processes is directly affected by the caps that limit threads. Unlike some UNIX variants, most resources in Windows have no fixed upper bound compiled into the operating system, but rather derive their limits based on basic operating system resources that I’ve already covered. Process and threads, for example, require physical memory, virtual memory, and pool memory, so the number of processes or threads that can be created on a given Windows system is ultimately determined by one of these resources, depending on the way that the processes or threads are created and which constraint is hit first. I therefore recommend that you read the preceding posts if you haven’t, because I’ll be referring to reserved memory, committed memory, the system commit limit and other concepts I’ve covered. Here’s the index of the entire Pushing the Limits series. While they can stand on their own, they assume that you read them in order. Pushing the Limits of Windows: Physical Memory Pushing the Limits of Windows: Virtual Memory Pushing the Limits of Windows: Paged and Nonpaged Pool Pushing the Limits of Windows: Processes and Threads Pushing the Limits of Windows: Handles Pushing the Limits of Windows: USER and GDI Objects – Part 1 Pushing the Limits of Windows: USER and GDI Objects – Part 2 Processes and Threads A Windows process is essentially container that hosts the execution of an executable image file. It is represented with a kernel process object and Windows uses the process object and its associated data structures to store and track information about the image’s execution. For example, a process has a virtual address space that holds the process’s private and shared data and into which the executable image and its associated DLLs are mapped. Windows records the process’s use of resources for accounting and query by diagnostic tools and it registers the process’s references to operating system objects in the process’s handle table. Processes operate with a security context, called a token, that identifies the user account, account groups, and privileges assigned to the process. Finally, a process includes one or more threads that actually execute the code in the process (technically, processes don’t run, threads do) and that are represented with kernel thread objects. There are several reasons applications create threads in addition to their default initial thread: processes with a user interface typically create threads to execute work so that the main thread remains responsive to user input and windowing commands; applications that want to take advantage of multiple processors for scalability or that want to continue executing while threads are tied up waiting for synchronous I/O operations to complete also benefit from multiple threads. Thread Limits Besides basic information about a thread, including its CPU register state, scheduling priority, and resource usage accounting, every thread has a portion of the process address space assigned to it, called a stack, which the thread can use as scratch storage as it executes program code to pass function parameters, maintain local variables, and save function return addresses. So that the system’s virtual memory isn’t unnecessarily wasted, only part of the stack is initially allocated, or committed and the rest is simply reserved. Because stacks grow downward in memory, the system places guard pages beyond the committed part of the stack that trigger an automatic commitment of additional memory (called a stack expansion) when accessed. This figure shows how a stack’s committed region grows down and the guard page moves when the stack expands, with a 32-bit address space as an example (not drawn to scale): The Portable Executable (PE) structures of the executable image specify the amount of address space reserved and initially committed for a thread’s stack. The linker defaults to a reserve of 1MB and commit of one page (4K), but developers can override these values either by changing the PE values when they link their program or for an individual thread in a call to CreateThread. You can use a tool like Dumpbin that comes with Visual Studio to look at the settings for an executable. Here’s the Dumpbin output with the /headers option for the executable generated by a new Visual Studio project: Converting the numbers from hexadecimal, you can see the stack reserve size is 1MB and the initial commit is 4K and using the new Sysinternals VMMap tool to attach to this process and view its address space, you can clearly see a thread stack’s initial committed page, a guard page, and the rest of the reserved stack memory: Because each thread consumes part of a process’s address space, processes have a basic limit on the number of threads they can create that’s imposed by the size of their address space divided by the thread stack size. 32-bit Thread Limits Even if the thread had no code or data and the entire address space could be used for stacks, a 32-bit process with the default 2GB address space could create at most 2,048 threads. Here’s the output of the Testlimit tool running on 32-bit Windows with the –t switch (create threads) confirming that limit: Again, since part of the address space was already used by the code and initial heap, not all of the 2GB was available for thread stacks, thus the total threads created could not quite reach the theoretical limit of 2,048. I linked the Testlimit executable with the large address space-aware option, meaning that if it’s presented with more than 2GB of address space (for example on 32-bit systems booted with the /3GB or /USERVA Boot.ini option or its equivalent BCD option on Vista and later increaseuserva), it will use it. 32-bit processes are given 4GB of address space when they run on 64-bit Windows, so how many threads can the 32-bit Testlimit create when run on 64-bit Windows? Based on what we’ve covered so far, the answer should be roughly 4096 (4GB divided by 1MB), but the number is actually significantly smaller. Here’s 32-bit Testlimit running on 64-bit Windows XP: The reason for the discrepancy comes from the fact that when you run a 32-bit application on 64-bit Windows, it is actually a 64-bit process that executes 64-bit code on behalf of the 32-bit threads, and therefore there is a 64-bit thread stack and a 32-bit thread stack area reserved for each thread. The 64-bit stack has a reserve of 256K (except that on systems prior to Vista, the initial thread’s 64-bit stack is 1MB). Because every 32-bit thread begins its life in 64-bit mode and the stack space it uses when starting exceeds a page, you’ll typically see at least 16KB of the 64-bit stack committed. Here’s an example of a 32-bit thread’s 64-bit and 32-bit stacks (the one labeled “Wow64” is the 32-bit stack): 32-bit Testlimit was able to create 3,204 threads on 64-bit Windows, which given that each thread uses 1MB+256K of address space for stack (again, except the first on versions of Windows prior to Vista, which uses 1MB+1MB), is exactly what you’d expect. I got different results when I ran 32-bit Testlimit on 64-bit Windows 7, however: The difference between the Windows XP result and the Windows 7 result is caused by the more random nature of address space layout introduced in Windows Vista, Address Space Load Randomization (ASLR), that leads to some fragmentation. Randomization of DLL loading, thread stack and heap placement, helps defend against malware code injection. As you can see from this VMMap output, there’s 357MB of address space still available, but the largest free block is only 128K in size, which is smaller than the 1MB required for a 32-bit stack: As I mentioned, a developer can override the default stack reserve. One reason to do so is to avoid wasting address space when a thread’s stack usage will always be significantly less than the default 1MB. Testlimit sets the default stack reservation in its PE image to 64K and when you include the –n switch along with the –t switch, Testlimit creates threads with 64K stacks. Here’s the output on a 32-bit Windows XP system with 256MB RAM (I did this experiment on a small system to highlight this particular limit): Note the different error, which implies that address space isn’t the issue here. In fact, 64K stacks should allow for around 32,000 threads (2GB/64K = 32,768). What’s the limit that’s being hit in this case? A look at the likely candidates, including commit and pool, don’t give any clues, as they’re all below their limits: It’s only a look at additional memory information in the kernel debugger that reveals the threshold that’s being hit, resident available memory, which has been exhausted: Resident available memory is the physical memory that can be assigned to data or code that must be kept in RAM. Nonpaged pool and nonpaged drivers count against it, for example, as does memory that’s locked in RAM for device I/O operations. Every thread has both a user-mode stack, which is what I’ve been talking about, but they also have a kernel-mode stack that’s used when they run in kernel mode, for example while executing system calls. When a thread is active its kernel stack is locked in memory so that the thread can execute code in the kernel that can’t page fault. A basic kernel stack is 12K on 32-bit Windows and 24K on 64-bit Windows. 14,225 threads require about 170MB of resident available memory, which corresponds to exactly how much is free on this system when Testlimit isn’t running: Once the resident available memory limit is hit, many basic operations begin failing. For example, here’s the error I got when I double-clicked on the desktop’s Internet Explorer shortcut: As expected, when run on 64-bit Windows with 256MB of RAM, Testlimit is only able to create 6,600 threads – roughly half what it created on 32-bit Windows with 256MB RAM - before running out of resident available memory: The reason I said “basic” kernel stack earlier is that a thread that executes graphics or windowing functions gets a “large” stack when it executes the first call that’s 20K on 32-bit Windows and 48K on 64-bit Windows. Testlimit’s threads don’t call any such APIs, so they have basic kernel stacks. 64-bit Thread Limits Like 32-bit threads, 64-bit threads also have a default of 1MB reserved for stack, but 64-bit processes have a much larger user-mode address space (8TB), so address space shouldn’t be an issue when it comes to creating large numbers of threads. Resident available memory is obviously still a potential limiter, though. The 64-bit version of Testlimit (Testlimit64.exe) was able to create around 6,600 threads with and without the –n switch on the 256MB 64-bit Windows XP system, the same number that the 32-bit version created, because it also hit the resident available memory limit. However, on a system with 2GB of RAM, Testlimit64 was able to create only 55,000 threads, far below the number it should have been able to if resident available memory was the limiter (2GB/24K = 89,000): In this case, it’s the initial thread stack commit that causes the system to run out of virtual memory and the “paging file is too small” error. Once the commit level reached the size of RAM, the rate of thread creation slowed to a crawl because the system started thrashing, paging out stacks of threads created earlier to make room for the stacks of new threads, and the paging file had to expand. The results are the same when the –n switch is specified, because the threads have the same initial stack commitment. Process Limits The number of processes that Windows supports obviously must be less than the number of threads, since each process has one thread and a process itself causes additional resource usage. 32-bit Testlimit running on a 2GB 64-bit Windows XP system created about 8,400 processes: A look in the kernel debugger shows that it hit the resident available memory limit: If the only cost of a process with respect to resident available memory was the kernel-mode thread stack, Testlimit would have been able to create far more than 8,400 threads on a 2GB system. The amount of resident available memory on this system when Testlimit isn’t running is 1.9GB: Dividing the amount of resident memory Testlimit used (1.9GB) by the number of processes it created (8,400) yields 230K of resident memory per process. Since a 64-bit kernel stack is 24K, that leaves about 206K unaccounted for. Where’s the rest of the cost coming from? When a process is created, Windows reserves enough physical memory to accommodate the process’s minimum working set size. This acts as a guarantee to the process that no matter what, there will enough physical memory available to hold enough data to satisfy its minimum working set. The default working set size happens to be 200KB, a fact that’s evident when you add the Minimum Working Set column to Process Explorer’s display: The remaining roughly 6K is resident available memory charged for additional non-pageable memory allocated to represent a process. A process on 32-bit Windows will use slightly less resident memory because its kernel-mode thread stack is smaller. As they can for user-mode thread stacks, processes can override their default working set size with the SetProcessWorkingSetSize function. Testlimit supports a –n switch, that when combined with –p, causes child processes of the main Testlimit process to set their working set to the minimum possible, which is 80K. Because the child processes must run to shrink their working sets, Testlimit sleeps after it can’t create any more processes and then tries again to give its children a chance to execute. Testlimit executed with the –n switch on a Windows 7 system with 4GB of RAM hit a limit other than resident available memory: the system commit limit: Here you can see the kernel debugger reporting not only that the system commit limit had been hit, but that there have been thousands of memory allocation failures, both virtual and paged pool allocations, following the exhaustion of the commit limit (the system commit limit was actually hit several times as the paging file was filled and then grown to raise the limit): The baseline commitment before Testlimit ran was about 1.5GB, so the threads had consumed about 8GB of committed memory. Each process therefore consumed roughly 8GB/6,600, or 1.2MB. The output of the kernel debugger’s !vm command, which shows the private memory allocated by each active process, confirms that calculation: The initial thread stack commitment, described earlier, has a negligible impact with the rest coming from the memory required for the process address space data structures, page table entries, the handle table, process and thread objects, and private data the process creates when it initializes. How Many Threads and Processes are Enough? So the answer to the questions, “how many threads does Windows support?” and “how many processes can you run concurrently on Windows?” depends. In addition to the nuances of the way that the threads specify their stack sizes and processes specify their minimum working sets, the two major factors that determine the answer on any particular system include the amount of physical memory and the system commit limit. In any case, applications that create enough threads or processes to get anywhere near these limits should rethink their design, as there are almost always alternate ways to accomplish the same goals with a reasonable number. For instance, the general goal for a scalable application is to keep the number of threads running equal to the number of CPUs (with NUMA changing this to consider CPUs per node) and one way to achieve that is to switch from using synchronous I/O to using asynchronous I/O and rely on I/O completion ports to help match the number of running threads to the number of CPUs.

CyberWolf08: Iei un tutorial in engleza, care iti place tie si ti se pare interesant, il traduci si il postezi. Nu e chiar atat de greu. Ideea e sa fie mai multi membri care sa contribuie, care sa ajute comunitatea. Si daca nu fac asta din placere, e degeaba... Uitati cum fac eu de cateva zile: Am gasit cateva site-uri interesante, si ce gasesc interesant pe ele, postez si aici. E un inceput. O sa mai scriu cate un articol, vedeti voi

Nu inteleg de ce va complicati. Nu stiti SQL, nu veti sti niciodata SQL Injection. Invatat SQL (orice, MySQL, Postgre, Oracle...), apoi va apucati de SQL Injection.

Backdoor.Win32.UltimateDefender.gtz - Reversing In this paper (Backdoor.Win32.UltimateDefender.gtz - Reversing) we analyze install.exe that presents the typical structure of an Medium Evoluted Malware, with basical Obfuscated-Dummy Code, some layer of Encryption decoded at Runtime and Custom Hash Functions used as Integrity Check. We can also see an intersting technique that retrieves API's Addresses OnDemand through a series of hardcoded values that corresponds to some API, the correspondent API Address is computated at runtime and chosen in function of the Hardcoded Value. Download: http://rootkitanalytics.com/papers/pdf/Backdoor-UltimateDefender.pdf

Kernelland Rootkits Kernel rootkits are the tools that run in the kernel, hence making it really hard to detect. The entire operating system would be altered in the process, which would help in the process of hiding the fact that the system is compromised. Kernel rootkits are of the most malicious nature -- they completely undermine a systems integrity and capacity for self-diagnosis. Essentially any tool that could be used for detecting such a rootkit is susceptible to false results due to syscall hijacking. Some tools however does not have to run in memory of the target system itself may benefit from running on a remote machine to avoid certain syscalls (i.e over NFS) -- this can be explained in more detail sometime. There are a many ways to subvert. Here are some of them: -- Directly modifying the syscall table -- Syscall jump -- IDT -- IA32 Debug Kernel - Working To understand the working of kernel rootkit, it is important to understand how a kernel works. Though we talk a lot more about Linux related samples at most cases, all kernels behave the same way. Kernel is a mediator between user apps and the hardware. Hence, kernel should interact/talk-to both the user-mode apps and the hardware. To do this in a secure way, operating systems has ensured that all processes communicate with the kernel through system libraries and the system libraries sends system calls to the kernel mode, which reaches the system call table. The system call table then interacts with the text or data segment of the kernel depending on the nature of Syscall or the function to be performed. Once that is processed in the kernel, the kernel then interacts with the hardware accordingly. The following figure shows a simple interaction diagram: Kernel Rootkit - Ring Terminology In the ring terminology, kernel rootkits run on ring0. Since, ring0 is under all the other layers, monitoring kernel rootkits is almost impossible if the monitoring software is run on the same system, except for certain detection techniques that compares the different states or interacts with kernel using different stimulus signals and compares the response. Though once again, since the kernel rootkit modifies the entire operating system properties, functions and anything and everything possible to deceive a user from noticing the compromise by completely hiding itself, detection is quite hard in case of kernelland rootkits. As said in the ring terminology section, ring0 has the highest privilege and ring3 has the least privilege. Most anti-rootkit tools that are created to detect kernel rootkits, really do not do the stuff that they were created for if the kernel rootkit does its job as it was meant to. Kernel Modification Techniques Kernelland rootkits are known for overwriting the entire operating system. They do this by modifying the kernel. Loadable Kernel Module [LKM] is used to expand the kernel for adding new hardware or Filesystem without a system reboot. LKM is used only when required and when they are used, they run in the memory and when done they are removed. In this process, an attacker/rootkit can run the infected process that would load the EVIL_LKM to modify the kernel. LKM runs in ring0 of the system as it is running on the kernel itself, which means that it is running on the highest privilege. To do this, the EVIL_PROCESS loads the EVIL_LKM. There are several ways to do this and there are several things that can be done once this is done. Syscall hijack is one way that we talk about in our other paper and also the Syscall modification too. Once this is loaded, the rootkits can alter the Syscall to EVIL_SYSCALL or intercept the good Syscall with EVIL_FUNCTION, depending on the technique that the rootkit chooses to use. Once this is done, the kernel access is obtained by running the code that the rootkit tries to access in the Text segment. Another way to subvert the kernel is to alter kernel memory. /dev/kmem is used for mapping the kernel memory at run-time in Linux. In Windows systems, Hence to change the kernel at runtime, direct memory I/O could alter kmem. Even though there are patches to protect kmem, there are other ways to override the patches for the rootkits to do what they were meant to. Directly modifying the Syscall table The syscall table is generally an array of function pointers; these function pointers can be redirected to point to functions implemented in the rootkit, often times an LKM. This type of kernel rootkit is easy to detect compared to other kernel rootkits. A hands on approach is to analyze /proc/kcore with gdb and verify the syscalls against the System.map file (A file created at kernel compilation time for debugging purposes). A simpler approach is to run a tool like ktraq, which also has the benefit of disabling this type of rootkit by resetting the syscall function pointers. Syscall jump This is a more stealth method of syscall hijacking without having to directly modify the syscall table; instead the first 7 bytes of the syscall are overwritten with a jump to the new code -- i.e "movl $0x0, %eax; jmp *%eax". Keep in mind the original 7 bytes are saved and copied back into the original syscall so that it may be called within the evil syscall. This type of syscall hijacking cannot be detected by tools like ktraq, however a tool like ElfStat which analyzes the text segment of the running kernel and compares it to vmlinux can detect this method. This method is also used in kernel function hijacking (Not only syscalls). Sursa: Kernelland - Linux kernel rootkit - RootkitAnalytics.com