Category Archives: Defense

Reducing the friction™ with social medias thanks to Netvibes

I have been a big fan of the “Reducing the friction” series of article published by Scott Lowe a while back.

These articles consist in tips to automate or improve the smoothness of repeated professional tasks. If you haven’t, I recommend you to read them.

Some are specific to the Mac OS X environments, but most of time it is easy to find alternative stuff for Linux. By the way, I am thinking of sharing my own tips for Linux some day.

The issues with technology watch

Today, I will start with an article on how I tackled the issues I have with technology watching : too much information, too many sources, too much noise, too much time wasted… Hmm, yes, that’s a lot of issues!

Before, below are the sources that I used to visit plenty of times a day:

  • RSS/Atom feeds, from Feedly with a few hundreds of sources.
  • Twitter
  • Reddit (most often /r/netsec, but also others)
  • Hacker News

So my typical checks consisted in visiting these places subsequently, several times a day. With all the hassle of using different interfaces and the distractions that you can find there, it used to be very time costly and not really efficient.

Typically, I would save interesting topics there (“like” in Twitter, “save” for Feedly…) for a later check. Sometimes I would also use Pocket to read them offline, or a simple PDF export.

As I already said, such a process with many tools is far from ideal and from the Reduce the friction™ theory.

Reducing the friction with Netvibes

Netvibes is a Web platform allowing to gather many kinds of contents within dashboards. It is in fact possible to use it as a news aggregator like Feedly, but it has much more capabilities.

First, it can handle sources from various technologies or social media actors (at least, major ones are supported):

  • RSS/Atom
  • Twitter
  • Reddit
  • Facebook

After adding some sources (they call them applications), you can get a classic feed view like below:

Feed view on Netvibes

Feed view on Netvibes

Nice! We now have a lot of stuff in one place and you can easily distinct what you have read or not (which is not easy to achieve in Twitter, for instance).

Then, similar to what IFTT offers, you can create automated actions easily.

Here are some of the supported triggers:

Services supported by Netvibes

Services supported by Netvibes

Based on a trigger like marking an article from within Netvibes, I can decide to send that article to Pocket or by e-mail for offline reading:

Netvibes action

Netvibes action

I have also another action: when a new post appears on a subreddit, I also send it to Pocket.

The possibilities, while not yet infinite, are huge.

You can do a lot with the free version, but for 2€ a month, you get content indexing to quickly find back some items in your feeds. I took this option, as it is useful but also as it is a way to support this project.

There is a premium offer, by far more expensive, but it is not really aimed to individual (analytics and collaborative features). See this page for more information.


I have tried, I believe, all possible alternatives. Including integrating Feedly with IFFT, which is nice but does not solve the issue of reading many sources.

Netvibes is so far very interesting and powerful. It is not perfect, however.

Sometimes the interface is a little clumsy or cumbersome. I also miss a mobile application (for Android), even though the mobile HTML 5 interface is not that bad (

Finally, I could not find a way to republish a dashboard feed as RSS, so that I could use a mobile reader. Let’s hope that this powerful tool will continue to improve, and for that I hope it gains in popularity.

Lessons learned with Docker, Nodejs apps and volumes


I have kept playing with Docker recently, just for fun and to learn.

It is very powerful, but still young. It quickly shows some limit when it comes to security or persistence. There are some workarounds, yet more or less complex, more or less hacky.

Indeed, I had some issues with Etherpad, which is a Nodejs application, and its integration into Docker.

Initially, I made something quite simple, so my Dockerfile ended like that:

USER etherpad
CMD ["node","/opt/etherpad-lite/node_modules/ep_etherpad-lite/node/server.js"]

Thus, I simply start the app with a low privileges user.

It worked, but I had two issues:

  1. Docker was not able to stop it nicely. Instead, it timed out after 10 sec and finally killed the app and the container altogether.
  2. No persistence of any kind, of course.

I decided to tackle these two issues to understand what was going on behind.

The PID 1 issue

I could not understand immediately the first issue: why was Docker unable to terminate the container properly?

After wandering a few hours on wrong paths (trying to get through with Nodejs nodemon or supervisor), I finally found some good articles, explaining that Docker misses an init system to catch signals, wich causes some issues with applications started with a PID = 1, which cannot be killed, or with Bash (the shell doesn’t handle transmitted signals.

I am not going to repeat poorly what has already been explained very well, so I encourage you to read this two excellent posts:

You will also find a lot of bug reports in the Docker github about this issue, and a lot of hacky or overkilling solutions.

In my opinion, the most elegant solution among them is to use a launcher program, very simple and dedicated to catch and handle signal.

I chose to use Dumb-init, as it is well packaged (there are plenty of options) and seems to be well maintained.

So, after installing Dump-init in the Dockerfile, the CMD line should now look like this:

USER etherpad
CMD ["dumb-init","node","/opt/etherpad-lite/node_modules/ep_etherpad-lite/node/server.js"]

And indeed, as expected, docker stop now works flawlessly.

Volume permissions

This is where I had the toughest issue, although it is supposed to be straightforward with volumes.

Volumes enable to share files or folders between host and containers, or between containers solely. There are plenty of possibilities, nicely illustrated on this blog:

And it works very well…. as long as you application runs as root.

In my case, for instance, Etherpad runs with a low privileged user, which is highly recommended. At startup, it creates a sqlite database, etherpad.db,  in its ./var folder.

Mounting a volume, of any kind, over the ./var folder, would result in a folder with root only permissions. Subsequently, of course, the launch of Etherpad from the CMD command would fail miserably.

Simple solutions like chown in the Dockerfile don’t work, because they apply before the mount. The mount occurs at runtime and works like a standard Linux mount: it is created by the docker daemon, with root permissions, over possibly existing data.

My solution was to completely change the way Etherpad is started. I now use an external script which is started at runtime:

  1. First, it applies the appropriate permissions to the mounted volume with chown,
  2. Then, it starts Etherpad with a low privileged user thanks to a su hack.

So now the Dockerfile ends with:

VOLUME /opt/etherpad-lite/var
ADD ./bin/
CMD ["./bin/"]

And here is the script:


chown -R etherpad:etherpad /opt/etherpad-lite/var
su etherpad -s /bin/bash -c  "dumb-init node /opt/etherpad-lite/node_modules/ep_etherpad-lite/no

I use a data volume for persistency, so the run command looks like this:

docker run -d --name etherpad -p 80:9001 -v etherpad:/opt/etherpad-lite/var -t debian-etherpad

Far from being ideal, but it works. I really hope some features are coming to bring more options in this area, especially in the Dockerfile.

Some final thoughts

Globally, we can still hope a lot of improvements in security, because when I look at many Dockerfiles around, I see two behaviors:

  • A lot of people don’t care and everything is happily running as root, from unauthenticated third-party images or binaries…
  • Some people do care but end up with dirty hacks, because there is no other way to do so.

It is scary and so far from the Linux philosophy. Let’s wait for the enhancements to come.

You can find the complete updated Dockerfile on this github page.

While we are on this topic, have a look to this nice post with some nice tips and tricks for Docker.

Quick tip: harden your ARP table the easy way (Linux)

ARP spoofing is a good old attack on LAN and still a devastating one, leading to trafic interception (MiTM). You may want to make sure that nobody is tricking on you at office, at a security conference, at you local coffee shop, etc.

Yet, most networks do not have port security and ARP inspect on their switches to mitigate such attacks. So you have to count on yourself.

Most people know how to protect a client , e.g. by maintaining a static mapping of MAC / IP addresses on the operating systems. But almost no one does it, because it would be a pain to manage…

But, really ? No, here is what I do to get a reasonable protection.

I do a few compromises at first:

  1. I am not looking to protect ALL my traffic toward  other peers on the LAN, but at least outbound communications with the gateway and, optionally, with a few critical servers.
  2. An attacker may still poison the gateway and eavesdrop on responses directed to my machine, and get some interesting stuff anyway.
  3. So, this is not a protection on its own. You have to think defense-in-depth : encryption on all your services (TLS), VPN, etc. Especially, depending on where you are, do not rely on the DNS / DHCP servers.

With that said, what follows is a hardening move that you can do on most of Linux distributions, with little pain.

Get the MAC address of the gateway, either by finding it out physically (tag) or by checking it at a safe moment (when ARP spoofing is supposedly not happening).

Fill in a flat file, like /etc/ethers, with mappings like :


Now, NetworkManager will do all the magic.

Create a script like :

 % cat /etc/NetworkManager/dispatcher.d/40-arp 
 arp -f /etc/ethers

All scripts in the above folder will be executed every time an interface gets up, as long as you give it executable rights :

% chmod +x /etc/NetworkManager/dispatcher.d/40-arp

Now, either execute it directly or unplug / plug back in your interface. You should have a permanent static MAC address now, effectively bypassing the ARP protocol and its weaknesses :

% arp -a -n
? ( at 00:15:17:9d:d6:d1 [ether] PERM on eth0

Voilà! Should you not use NetworkManager for some reason, you can do something equivalent with ifup scripts in respect with the syntax of you current Linux distribution.

But, let me stress it out once more, to be sure you don’t get me wrong :

Despite an enhancement, this is no a sufficient protection and you may still get pwned ! Authentication and encryption MUST also come into the play, so use only TLS enabled services, HTTPS sites and, ideally, a good IPSEC / SSH / TLS tunnel to carry ALL of your traffic !

The evolution of ICS security

This article, which comes with nice screencasts, is an interesting state of art on industrial system – or rather lack of – security. These systems are popularly known as SCADA systems, but SCADA systems are just a subpart of ICS (Industrial Control Systems).

Well, there is no surprise that they have been highly insecure from their conception, and that many are exposed on the Internet.

What is interesting is to note the recent evolution:

  • As ICS are getting more media coverage, they are more and more targeted by both security researchers and activists (e.g. Anonymous). The latter is especially scary if you think of what some of them are capable to do for their cause and their degree of amateurism.
  • More and more automatic exploitation tools are developed, making the task of the attacker easier: Metasploit modules, WinCC Harvester, PLCScan…
  • Stuxnet was discovered about 3 years ago, but vendors have yet to fix systems and publish security hardening guides (still drafts). I am even talking about end-users awareness…

Conclusion: we are still at the beginning of the ICS insecurity era and we can expect more hack news…

Review of McAfee Application Control (ex-SolidCore): the ultimate solution to patching?

What is McAfee Application Control

I had the opportunity to review this security software, and I want to share here the results of my tests.

McAfee bought the SolidCore solution and renamed it into McAfee Application Control (along with other features). For convenience, we will keep referring the solution as SolidCore.

In a few words, this tool falls into the category of white-listing defense systems. It hardens a Windows system by fingerprinting all executables files of the disk drive and enforcing access control based on this hash. Somehow a sort of Tripwire but with access control and attack detection.

The problem is that McAfee claims that the solution will protect unpatched systems. Such a claim is appealing, because in real life it is not always easy to patch systems in production. Beyond technical considerations, there is always business and management constraints. The solution of McAfee is supposed to prevent vulnerabilities to be triggered thanks to the memory protection features. Look on their website, they say it loudly: “you can delay patching and it protects from buffer overflows”.

MacAfee Application Control commercial sheet

Really? When you check more thoroughly, you find that the solution operates only in user-mode, leaving all kernel-mode issues on the side. Already, any security specialist should become suspicious and think about the numerous limitations it implies…

Anyway, such a statement deserves serious testing. Here we go.

Testing Lab

The testing environment is composed of:

  • a Windows XP SP1 virtual machine (no patch),
  • a Windows XP SP1 virtual machine (no patch) with SolidCore installed and enabled,
  • a Windows virtual machine running WinDBG for kernel debugging,
  • a Linux virtual machine running Metasploit (Backtrack),
  • a few vulnerable programs: aurora.html for heap overflows and two executables vulnerable against buffer overflow,
  • OllyDbg on both machines to observe the exploitation process.

The point is simple: test some vulnerabilities against unpatched systems, with and without SolidCore, and compare the results.

The purpose here is only to focus on what SolidCore is doing (though we are not going to attempt to reverse the application). I will not get here into explanations on assembly and memory exploitation, so please refer to the many great tutorials that can be found on the Internet.

As mentioned, I am myself a noob in reversing and shellcoding so please drop a comment if you see something wrong.

Installing SolidCore

Like Tripwire, SolidCore needs to take an image of the system when it is sane.

So, basically, after setting it, there are a few commands to type into a command window to scan the whole disk:

sadmin so
sadmin enable

It will look for executables (.exe, .dll, etc.) and build a database using SHA-1 hashes.

SolidCore Activation

SolidCore commands and status after activation

Now, only applications installed before the scan will be allowed. If you drop a new file or move an existing one to a new patch and try to execute it, it will fail like this:

SolidCore blocking execution of a program

SolidCore blocks the execution of a new executable file

After that, whenever you need to install a new application, you have to go through the “update mode”. Just enter:

sadmin bu

At this moment, the protection is deactivated and you can execute anything. Then, you need to do a new scan and re-enable the protection as done previously.

Also, not all memory protections are activated by default. This is supposed to enable memory randomization (aka ALSR but McAfee made):

sadmin features enable mp-vasr

Now, see the enabled features:

SolidCore features list

SolidCore features list and memory protection (mp-vasr, mp-casp)

So far so good, now we can play!

Let’s see what is behind the scene…

The first thing to notice is that SolidCore installs a service launched with the LocalSystem account.

SolidCore service

SolidCore service

SolidCore background service process

SolidCore background service process

Let’s have a look within a kernel debugging session with WinDbg.

While booting, the target displays a lot of interesting info concerning the McAfee solution:

Solidcore log buf: F8418B60, F84415C0
K.0004.0008: Nov 30 2012:04:49:09.812: SYSTEM: rtinit.c : 1474: McAfee Solidifier driver version 6.0.1-9049
K.0004.0008: Nov 30 2012:04:49:09.828: SYSTEM: rtinit.c : 1476: DriverEntry @F846E500
K.0004.0028: Nov 30 2012:04:49:10.093: SYSTEM: imgp_rebase.c: 196: Rebased \Device\HarddiskVolume1\WINDOWS\system32\ntdll.dll to \Device\HarddiskVolume1\Solidcore\vasr\ntdll.dll at 0x5cda0000.
K.0004.0028: Nov 30 2012:04:49:10.500: SYSTEM: rtinit.c : 129: Booting up with RTEMode = 1
K.0432.0436: Nov 30 2012:04:49:15.671: ERROR: cap_kern.c : 1106: Failed to compute checksum for '\Device\HarddiskVolume1\WINDOWS\system32\autochk.exe'. err = 1099
K.0432.0436: Nov 30 2012:04:49:15.796: SYSTEM: imgp_rebase.c: 196: Rebased \Device\HarddiskVolume1\WINDOWS\system32\kernel32.dll to \Device\HarddiskVolume1\Solidcore\vasr\kernel32.dll at 0x65d60000.
K.0432.0436: Nov 30 2012:04:49:15.828: SYSTEM: imgp.c : 3114: Starting decoying of \Device\HarddiskVolume1\Solidcore\vasr\kernel32.dll (\Device\HarddiskVolume1\Solidcore\k32_c__v.dll)
K.0432.0436: Nov 30 2012:04:49:15.890: SYSTEM: imgp.c : 3118: Finished decoying of \Device\HarddiskVolume1\Solidcore\vasr\kernel32.dll (\Device\HarddiskVolume1\Solidcore\k32_c__v.dll) with err = 0
K.0432.0436: Nov 30 2012:04:49:15.953: SYSTEM: imgp_rebase.c: 196: Rebased \Device\HarddiskVolume1\WINDOWS\system32\user32.dll to \Device\HarddiskVolume1\Solidcore\vasr\user32.dll at 0x48c60000.
K.0732.0828: Nov 30 2012:04:49:20.859: SYSTEM: utl.c : 500: Failed to find username, err 0xc000020c, perhaps the service is not running.
K.1312.1316: Nov 30 2012:04:49:21.281: SYSTEM: pkgc_misc.c : 679: Rebased \Device\HarddiskVolume1\Solidcore\pkgc\10980000\Device\HarddiskVolume1\WINDOWS\system32\_si.dll to 10980000
K.1312.1316: Nov 30 2012:04:49:21.390: ERROR: imgp.c : 3190: 0001 Failed to set branch target 0x10c46740 from 0x00000000 at VA 0x10a56760.
K.0732.0828: Nov 30 2012:04:49:23.875: SYSTEM: utl.c : 520: Retrying usermode lookup of username [1].
K.0732.0828: Nov 30 2012:04:49:23.890: SYSTEM: utl.c : 476: Found username as WINXP-MCAFEE\phocean
K.1904.1932: Nov 30 2012:04:49:27.078: SYSTEM: pkgc_misc.c : 679: Rebased \Device\HarddiskVolume1\Solidcore\pkgc\20170000\Device\HarddiskVolume1\WINDOWS\system32\_si.dll to 20170000
K.1904.1932: Nov 30 2012:04:49:27.453: ERROR: imgp.c : 3190: 0002 Failed to set branch targ et 0x20436740 from 0x00000000 at VA 0x20246760.

We learn the driver entry point and that it is relocating a few strategic DLL: ntdll, kernel32, user32 and _si.dll. Ntdll, kernel32 and user32 are obviously the main user-mode API of Windows and we can expect that SolidCore is also putting a few hooks inside them. _si.dll is part of SolidCore and appear to be unlinked while the system is running.

Let’s look around modules to confirm the position fo the driver:

SolidCore driver

SolidCore driver (WinDbg kernel debugging)

So, the McAfee driver is named swin. Quickly looking around, we also find that a DLL is injected in all processes: scinject.dll. Also, see on the screenshot, how kernel32 was effectively relocated. So every time the machine will start, the library will be located at a different address (it could be interesting to check the entropy of this randomization, by the way, but this is another topic).

McAfee SolidCore, injection of scinject.dll in processes

McAfee SolidCore injects the DLL “scinject.dll” in running processes.

Just to make sure, I checked that the dll does not get injected by the registry setting:

McAfee SolidCore AppInit_DLLs

McAfee SolidCore does not use AppInit_DLLs

Nothing there, so it must be done through a hook.

First tests: Metasploit

I was told that SolidCore was doing good against Metasploit, so one of the first thing I did was to fire up Backtrack and play with it against the SP1 “solidified” target.

And I have to say that I was quickly disapointed.

Sure, I could not get a Meterpreter session or get a standard payload to work out of the box, whereas it was a piece of cake on the standard SP1.

SolidCore and payload failure

SolidCore prevents standard Metasploit payloads (including Meterpreter) to run successfully.

But if SolidCore was at least disturbing the exploitation, it did not protect at all against the vulnerability itself. So I got things like this:

SolidCore and Metasploit DoS

Denial of Service during exploitation attempt with Metasploit: SolidCore will not magically “patch” vulnerabilities!

A good old denial of service. Note that on the event log, SolidCore itself doesn’t log the exploitation attempt.

I did several tests and depending on the vulnerability I got:

  • service crash
  • system instability
  • complete DoS (system shutdown)
So if a script skiddie will not be able to control the target, he will still obviously be able to cause a lot of damage!

It was not really a surprise: McAfee will not patch the system! But think twice when you are said the contrary…

More tests, about memory protection: buffer overflows

As I was also told that McAfee was protecting user-mode apps against buffer overflows, I was even more excited.

I prepared various representative tests:

  • heap overflow, based on Aurora
  • stack overflows (one base on strcpy, the other one on Windows CreateFile)

But first, one thing I wanted to quickly eliminate was the memory randomization feature, named mp-vasr:

SolidCore mp-vasr

SolidCore mp-vasr IS NOT ALSR

mp-vasr is not ALSR! The function gets always loaded at the same memory address, so there is not process memory randomization at all… Another disappointment…

Next step was to try to exploit the stack overflow. The first payload I used displays a message box. It calls LoadLibrary and GetProcAddress to dynamically resolve function addresses.

When we try to exploit the buffer overflow, we get this:

SolidCore blocking a shellcode

SolidCore causes memory access violation during shellcode injection

We have a memory access violation, because the code is trying the access to the address NULL. Weird, let’s see it with OllyDbg.

First, there is something that looks like a hook in ntdll:

SolidCore checking against PE signature

SolidCore checking against PE signature

So this thing is checking the code for a PE signature (5A4D). Then, it will go through scinject.dll (by calling casp_inject_save_addr, wich is the only exported function).

I could not reverse it (which would require much more time and skills than I have now), but at least we know where it is sitting and how it is triggered.

If we continue the execution, we can then see that the buffer overflow is happening very well:

SolidCore and buffer overflow

SolidCore does not prevent stack overflow!

Yes, we have the stack is fully overflowed and we can control EIP! So nothing should prevent us from exploiting it, shouldn’t it? ;-)

Here we go:

This first payload is low-tech, with hardcoded addresses of MessageBoxA and ExitProcess:

global _start


 mov ebx, 0xEEEEEEEF
 add ebx, 0x11111111 ;\0
 push ebx
 push 0x293a2064 ;d :)
 push 0x656e7770 ;pwne
 mov ecx, esp
 xor edx,edx
 push edx ;OK button
 push ecx ;title
 push ecx ;message
 push edx ;NULL window handle
 mov eax, 0x6a216476 ;MessageBoxA
 call eax
 xor edx,edx ;empty edx out
 push edx ;move address of MessageBoxA onto stack
 mov eax, 0x5cdb98fd ;ExitProcess(exitcode);
 call eax ;exit cleanly so we don't crash parent

Let’s how it looks in OllyDbg:

Buffer overflow exploitation despite McAfee Application Control

Buffer overflow exploitation despite McAfee Application Control

I then tested with another more sophisticated shellcode (sorry, I cannot publish this one as I am not the author), which resolves dynamically the addresses of kernel32 and GetProcAddress. It works as well. The only caveat that I observed is that LoadLibraryA is systemically blocked (after going through some scinject.dll routines, it always returns 0 in EAX, wich means failure).

In other words, a simple shellcode will work as long as the necessary library are loaded. Though most real life programs will already come with at least kernel32 and user32, it still gives a lot of opportunities.

And then, with more shellcoding kung-fu, I am sure it is possible to get something even more target independant. The following two articles from Phrack probably give most hints to achieve this:

But I need much more knowledge and practice in shellcoding before I can get something to work. I will see it later, and let me know if you could go ahead yourself.


Clearly, McAfee Application Control aka SolidCore is not an efficient protection against buffer overflows. If you want something much better, update your systems to something like Windows 7 64 bits and use Microsoft EMET to force DEP and ALSR on programs that don’t support it by default.

Also, no way to delay patching because you have SolidCore. Full exploitation (shellcode) is just made a little bit more difficult, and that’s it. The systems will still be exposed to many risks like denial of service unless they are patched. Like always, defense in depth and a proper security policy are the foundations to decide on the patching policy, not a tool or a feature.

This is a pity that the marketing teams give the wrong message, because McAfee still surely addresses many use cases. It is surely efficient enough to improve the control on workstations, that, for some reason, are difficult to control. For example, SolidCore will probably be enough to prevent the average Joe to mess the system. Why not being honest and keeping focus on this feature?

On the other hand, if the McAfee guys want to be as ambitious as they claim,  they will have to move SolidCore to the kernel-mode and enhance the memory protections from there.


Soktspy is a small script that may be helpful for some investigation.

Sometimes, you may detect that some suspicious network traffic coming out from a machine. In general, it is easy to spot the process from which the packets originate. You somehow connect to the PC and look for open sockets.

But sometimes, the behavior may be very sneaky, consisting of one or two packets, at rare and random intervals. Unless you spend all the day before the screen, it may be very difficult to trace.

Especially with stock tools or without installing any intrusive hardware, which is also the reason why I did this tool. On a production server, you want to install as little dependencies as possible, right?

So here is the Soktspy, a python script that easily build into a portable and standalone executable to deploy on the target machine.

Once launched, it just loops in the background and log sockets that are created for some given peers (the IP addresses you found involved in the suspicious network activity).

Maybe, some other tool exist, but I could not find anything similar. Let me know if you have any suggestion. Anyway, it was a nice exercise to do :)


soktSpy v1.2


  • Install Visual C++ Runtime libraries with vcredist_x86.exe (not necessary if the target machine happens to have Python already installed)
So far, I tested it successfully on Windows XP, Windows 2003, Ubuntu 11.10 and Mac OS Lion. But as it is a simple Python script, it is supposed to work on all platform.


You may recompile the program as a Windows binary executable by issuing this command:

> py2exe

How to use

  • Copy soktSpy.exe and its configuration file config.cfg.
  • Edit config.cfg with the IP you want to monitor
  • Start soktSpy.exe.

Then, as soon as the sneaky process will send out a packet toward the monitored IP, a log record will be triggered:

The log file contains the following info, in that order:

  • Detection time (based on the system local time)
  • Process creation time
  • PID
  • Process Name
  • Protocol Family (2 = IPv4, 23 = IPv6)
  • Process Owner
  • Source socket (IP, port)
  • Destination socket (IP, port)
  • Socket Status

Future Plans

Please tell me if you have any idea on how to improve it.

For now, I plan to add a feature that will dump the memory of the suspicious processes when it is executing.