Nytro

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

About RemoteDLL RemoteDLL is the tool which makes it easy to inject the DLL or free the DLL from remote process. This tool is based on popular DLL Injection technique which has already been used in many top programs such as pwdump. Many spyware programs uses this technique to hide their presence. Many of these comes as DLL and injects themselves to legitimate windows process and operates from that process so that normal user will not suspect its presence. Using RemoteDLL you can easily remove such DLL from the process and then delete it from the system completely. How RemoteDLL works? This tool is entirely based upon the DLL Injection concept. In short DLL Injection uses CreateRemoteThread API to invoke LoadLibrary or FreeLibrary on remote process. Here is a very good article which explains this technique in detail. I suggest you to read that article to better understand working of RemoteDLL. Injecting the DLL into Remote Process Below are the steps for injecting the DLL into another process using RemoteDLL. * Select the "Load DLL" option. * Now select the process to which you want to inject the DLL. * Next specify the the DLL and press the "Load DLL" button * The specified DLL will be injected into the target process and the result of entire operation will be displayed in status window. Removing the DLL from Remote Process Follow the below mentioned steps to remove DLL from any process using RemoteDLL. Note that removing DLL from process may crash it or destabilize the entire system. So make sure you know what you are doing before using it. * Select the "Free DLL" option from the main screen. * Next select the process from which you want to remove the DLL. * Now select the DLL to be removed from the process using DLL selection dialog. It displays following information about each DLL o DLL Name o Base Address o Entry Point of DLL o Size of the DLL in memory o Load count or Reference Count of DLL o Static or dynamically loaded * Next press the "Free DLL" button to remove the DLL from process. Result will be displayed step by step in the status window. Note that only dynamically loaded DLLs can be removed from the process. Reference count : Unique feature of RemoteDLL Reference count or load count indicates how many times the DLL is loaded into the process. Each time the DLL is loaded , process increases that DLL's reference count. So when you want to remove the DLL from the process, you have to invoke the FreeLibrary function that many times to completely free it. Reference count is the unique feature of RemoteDLL which is not present in any other similar tools. This is because there is no direct way or API function to get this information. Reference count for the DLL is stored in the PEB (Process Environment Block) for that process. PEB contains the linked list of DLL Module Structure which contain complete information about that particular DLL. One can retrieve the PEB data of remote process by using ReadProcessMemory() API. For detailed information on finding reference count read the detailed article here. Download: http://securityxploded.com/getfile.php?id=7111

About ProcHeapViewer This is the tool to enumerate process heaps on windows. It uses much better technique than slower Windows heap API functions which makes it faster and efficient. You can enumerate the heaps from normal Windows processes as well as system services. Its very useful tool for anyone involved in analyzing process heaps. Vulnerability researchers can use it as a side tool for discovering heap related vulnerabilities. The new version provides support for Windows 7. It also presents the enhanced user interface with cool look & feel. Making of ProcHeapViewer Some time back I was doing password strength related research on Yahoo Messenger. It used to store the password on the heap and I wrote an sample tool using normal heap functions to locate and retrieve the password. The password was basically located on one of the heap block which was near the end of 60,000th block. So I had to traverse all the 60,000 heap blocks using Heap32Next function and it took more than 10 minutes..! I tried running the program on multiple machines but it took almost same amount of time. I was getting irritated as I had to wait for so long every time I run my program. To find a way around this timing problem, I tried looking on the internet for answers but found nothing. Then I finally resort to finding the truth myself and started reverse engineering the Windows heap functions. Finally after few hours of work, I found the reason behind the delay and wrote my own implementation which took little more than few seconds. For the complete story behind the creation of ProcHeapViewer, read the detailed article here. Download: http://securityxploded.com/getfile.php?id=7211

About WinSniff WinSniff is the basic network packets sniffer for Windows developed using Winpcap library. It displays all the packets that are transmitted on the local network and gives detailed information about each header in the packet. In order to keep it simple, I am not dealing with application level protocols. If you are interested, you can add features to support various application level protocols such as SMTP, FTP, NETBIOS etc. Working of WinSniff When your machine is on the network, packets with different destinations arrive. By default (i.e., when the network adapter is in normal mode) these packets are rejected by the network adapter since they are intended to different hosts. But if you want, you can receive these packets by putting the network adapter in promiscuous mode. In this mode, it will accept all the packets irrespective of the destination address. Hence you can analyze the packets transmitted on your network. This trick is used for network management to determine the network traffic... etc. However, there is one problem here...!!! You will receive the packets with different destinations if you are using HUB. Since, HUB uses broadcasting technique for transmitting packets to all the hosts attached to it. However, if you are using SWITCH (an intelligent device), then you won't receive any packet sent to other hosts on the network. Best place to install this application is on the gateway where you can keep track of incoming and outgoing packets Implementation This part is meant for developers who are interested in coding their own sniffer. You may wants read to understand the internals of WinSniff. To start with, first step is to find out the right network interface and and then open it in promiscuous mode. While opening the device, you can also specify the size of the packet and time out value. //Get all devices for capturing the packet pcap_findalldevs(&devlist,err); //Open device in promiscous mode hdev=pcap_open_live( devname[index], //name of the device 65536, //size ->Capture whole packet 1, //promiscous mode 1000, //read timeout err ); Once you have opened the device, you will receive all packets. If you are interested in a particular packet, for example, only QUAKE packets (port 27960), ARP packets (ARP) etc., then you can specify the filter expression. For more details on filter expression, you can refer WinPcap documentation. // compile the filter pcap_compile(hdev,&fcode,filter,1,netmask); // now set the filter pcap_setfilter(hdev,&fcode); Once you have opened the device and set the filter, now you are ready to receive the packets. Once the packet is received, header contains the length, time and other information about the packet. Structure pkt_data contains the exact contents of the packet starting from Ethernet header. while(true) { pcap_next_ex(hdev,&header,&pkt_data); /* play with the captured packet */ } In order to analyze the packet contents, you must be familiar with various header formats. Mainly, you must know the format of the following headers... ETHERNET, ARP, IP, TCP, UDP, ICMP and IGMP. I have included the file 'protocol.h' which contains the format information about all these headers. If you want more details, you can refer RFCs for respective protocols. Once you have done the job, it's time to safely close the device. //close the device... pcap_close(hdev); Requirements 1) Developers can find all the header files and libraries in 'Winpcap developer pack' 3.0 or higher version. Don't forget to specify the include and lib files within the project settings. 2) Before running this application you need to install Winpcap version 3.0 or higher. Download: http://securityxploded.com/getfile.php?id=9121 Source code: http://securityxploded.com/getfile.php?id=9155

AdvancedWinServiceManager About AdvancedWinServiceManager 'Windows Service' is a program designed to perform specific service which is started automatically when Windows boots and runs as long as System is up and running. Services normally run with 'System' privilege thus enabling them to execute higher privilege operations which otherwise cannot be performed by normal processes. Due to these advantages, often malware applications use services to monitor and control the target system. In this direction, AdvancedWinServiceManager makes it easy to eliminate such malicious services by separating out third party services from Windows services. By default it shows only third party services along with more details such as Company Name, Description, Install Date, File Path etc at one place which helps in quickly differentiating between legitimate and malicious services. It comes with rich features such as detecting hidden rootkit services, exporting the service list to html based log file, displaying only third party services etc. All these unique things make it stand apart when compared to 'Windows Service Management Console'. Features of AdvancedWinServiceManager Here is the complete feature list of AdvancedWinServiceManager * Detection of hidden Rootkit services It can detect the services hidden by malicious Rootkit applications using bypass hook method. Such hidden services will be shown in red color to differentiate it from normal services. * Enhanced user interface with dynamic resize functionality. It comes with really cool GUI interface with catchy banner. Also it has dynamic resizing capability which makes it to adjust the screen according to the user needs. * Arrange the services based on various parameters It comes with sorting functionality to arrange the services based on service name, description, status, user account, company name, binary path, file size etc. This helps in quick searching of the service. * Easier detection of malicious service By default only third party services are displayed along with detailed information which makes it easy to differentiate between legitimate and malicious services. * Export the services list to standard html format 'Export to File' option provides easy way to save the displayed service list to html based log file for offline analysis. * Show services based on status and vendor. User can view the services based on its status. For example one can view only third party services or all running services. * Smooth and quick management of services It provides option to start, stop, enable or disable services with just a click. * Displays detailed information for each service For each service following information is shown, o Service Name o Description o Company Name o Service Status o User account o File version o File Size o Install Date o Full Binary Path Download: http://securityxploded.com/getfile.php?id=8275

ProcNetMonitor About ProcNetMonitor ProcNetMonitor is the free tool to monitor the network activity of all running process in the system. It displays all open network ports (TCP/UDP) and active network connections for each process. It has advanced color based auto analysis system to make it easy to distinguish network oriented processes from others with just one glance at the list. It also presents unique 'Port Finder' feature to easily search for particular port in all running processes with just one click. It also comes with export feature to save the entire process-port list to standard HTML file for offline analysis. All these features combined together make it very effective tool in combating the Trojans and Spywares installed on the system which continuously send keyboard strokes, online account data and other sensitive information to remote server. In the newer version by default only network oriented processes are displayed. As a result user don't have to spend time in figuring out the network processes from the big process list. ProcNetMonitor works on all Windows platforms starting from XP to latest Windows 7 version. Features of ProcNetMonitor Here is the highlight of ProcNetMonitor's features. * Informative running process list with TCP/UDP/connection count displayed per process. * Unique 'Port Finder' feature to search for network port in all running processes. * Advanced color based auto analysis system makes it easy to separate out network based process from others with just one glance. * AutoRefresh feature to automatically update the process network parameters on selection. * Faster remote host name resolution using multi thread based approach. * Display open network ports (TCP/UDP) and active network connections for selected process. * Sort the process list based on various parameters such as process name, process id, TCP count, UDP count, connection count etc. * Shows detailed properties of process on double click. * Option to terminate the selected process. * Export feature to save the entire displayed list to standard HTML file for offline analysis. * Refresh option to manually refresh the process and network port/connections list. Download: http://securityxploded.com/getfile.php?id=7255

Sunteti cativa pe aici care dezbateti aceasta problema punand trup si suflet, dar sunt sigur ca la 2 zile dupa uitarea acestui topic (ultimul post) o sa va faceti veacul tot pe la Offtopic. Incercam mai de mult un proiect: Traducerea tutorialelor din engleza in romana. Nu a fost tradus nici macar un singur tutorial, desi ar fi fost multi dispusi sa o faca. Si eu sunt unul dintre ei! Asadar, fapte, nu vorbe.

Sunt multi baieti isteti, foarte isteti. Dar, fie lucreaza la diverse companii pentru bani, fie sunt imprastiati peste tot, ceea ce nu ii avantajeaza. Da, incepe si mie sa imi displaca din ce in ce mai mult aceasta foame de bani, sa ceri bani pentru orice, chiar daca e vorba de un rahat de 2 lei, si de 10 linii de cod, pe care apropo, sunt zeci de mii de oameni care il pot scrie. Dar din acei zeci de mii de oameni, 90% ar cere bani pentru cele 10 linii de cod. Nu e de vina lipsa de cunostinte, ci mentalitatea asta fomista de bani.

Mie imi place filelist. Chiar am vorbit cu God (care nu e orice pusti de 12 ani care nu stie ce e ala PHP, se pricepe) mai de mult, facusem scriptul sa se poata aranja torrentele in functie de seeds, peers... Dar a facut niste modificari tehnice la cautare, si nu stiu daca se mai poate.

Numiti flood porcaria asta de udp.pl? Pfff...

Orice sugestie BUNA si utila e binevenita.

Nu cred ca a facut nimic pe VM, cred ca doar a detectat ca e pe VM si s-a inchis. Nu stau sa il verific in detalii, nu are rost.

Nu a rulat in Sandbox, iar pe masina virtuala s-a inchis singur. Asta e al dracu de suspect. In plus, continea mai multe fisiere (executabile). Din moment ce l-am rulat, a facut ceva (verific acum ce) si s-a inchis singur, e clar, e cine stie ce porcarie. Deci ban.

Pff, no comment, un articol de nota 10. Al dracu de interesant si de bine scris. Ia puneti mana si cititi ba, mai ales cei care vreti schimbari pe aici. Eu pana acum gandeam ca baietii de la Offensive Security (cei care au "facut" Backtrack) sunt hackeri. Dar cand ma gandesc ce preturi exorbitante cer pentru cursurile lor... Un hacker face totul din placere, nu pentru bani. Ideea asta s-a pierdut in timp, si foamea de bani a adus aceste modificari absurde in lumea hackingului.