Developing system applications in C# requires a lot of PInvoking. Although there are many great PInvoke Nuget libraries, for smaller projects I still prefer to import only the definitions I use. The pinvoke.net site is an excellent source of stub definitions. However, it happens that the online definition does not contain all the needed constants or lacks something. In such a case you have to look into the Windows headers (which btw. contain not only definitions but also a lot of interesting comments). I used to search through those files using Total Commander “Find Files” dialog, but it was slow and inefficient. So I switched to Sublime Text and created a project for the Windows headers folder (C:\Program Files (x86)\Windows Kits\10\Include\10.0.x.x). Once the folder index is cached, Sublime becomes a great tool for analyzing the source code (not only for C++!). However, when you read a lot of code and switch between various projects, Sublime replaces the old cached projects with the new ones to keep the cache at a reasonable size. That triggers the cache rebuilt when you open the “old” project again, which takes time and makes your search inefficient again.
I then started looking for a way to build a permanent index on the folders I regularly scan (such as the Windows headers directory). At first, I was thinking about running a local instance of Elasticsearch or Apache Solr server, but that seemed like overkill. I was looking for something simpler, some kind of a wrapper over the Apache Lucene library, which is the core engine for the servers mentioned above. Then I stumbled upon the Lee Holmes article about Scour, a PowerShell module that wraps the Lucene.Net library and provides cmdlets to create full-text indexes for your folders. After using it for some time, I am happy with the results so I decided to share my simple setup with you.
I was recently looking for a tool which would allow me to limit the total execution time of a process and its children. I haven’t found anything, so I decided to implement such a feature in Process Governor, my open-source process-monitoring application. You may download the v2.3 version from GitHub. In this post, I want to present you the new functionality and describe its implementation details.
When we know the PIDs of our running processes, we could use a simple command to wait for the processes to finish (the
Wait-Process cmdlet is an ideal example) and kill the remaining ones if they pass the limit. However, what if we only know the PID of the initial process? Tracking processes hierarchy in a script could become problematic. A simple and clear solution would be to assign a job object to the initial process, let it create new processes, wait the specified period and terminate the job if any of the processes is still running (terminating the job exits all the processes). There are, however, few questions we need to answer:
- How do we know all processes associated with the job finished their execution?
- What types of process execution time should we measure?
The article describes how to decipher encrypted strings in an old (5.7.2) version of Bamboo. I don’t have access to other versions, so I am not able to tell if it works there too (it won’t work for the latest version). Please leave a comment if you were able to test it on other versions of Bamboo.
When we create a build plan or a deployment project in Bamboo we need to define tasks which compose it. Bamboo internally stores these task definitions in a database column as an XML blob. Some of the tasks, such as SSH or SCP, require a password to connect to the remote server. In this short post, I will show you how to decrypt such passwords. Although we will decipher the remote server password, it looks that Bamboo uses the same algorithm to encrypt other data too (for example, credentials to access the external code repositories).
While analyzing the logic behind the “remember” cookie in Grafana 5.2.2, I discovered a bug in the authentication mechanism. It affected users authenticating to Grafana with an external provider (such as Azure AD). By generating a special “remember” cookie, an attacker could sign in as such a user, knowing only her/his username. The bug’s CVE id is CVE-2018-15727.
After I reported the problem to the Grafana team, they fixed the issue on the next day and started rolling out a new release. So if you are vulnerable, don’t hesitate and go update your Grafana.
There are various situations when you need random data in your application. Maybe you want to mix the order of the returned items, or maybe you create nonces for your encrypted messages. Those two sample scenarios require different approaches, and while choosing a non-cryptographic PRNG works just fine in the first situation, using it in the latter is entirely wrong. You may be wondering what a non-cryptographic PRNG is. A PRNG, or pseudorandom number generator, is an algorithm for generating a sequence of numbers whose properties almost equal to the properties of sequences of random numbers. The way how the algorithm creates these sequences could be either cryptographically secure (cryptographic PRNG) or not (non-cryptographic PRNG). A non-cryptographic PRNG cares only about the uniform distribution of random bits and not about their predictability. As we will see in a moment, using the same seed twice in the Non-crypto PRNG, results in two sequences of bytes equal to each other. Cryptographic PRNGs, on the other hand, provide random bits but are also unpredictable. In the coming paragraphs, we will examine in detail the ways we use PRNGs in .NET.
By default when you record a trace in Wireshark, you won’t find process IDs in it. And sometimes this information is necessary to investigate the problem you are facing. I run into one of such issues this week. I needed to locate a process on a Virtual Machine (local address 10.0.2.5) which was still using TLSv1 to connect to our load balancer. At first, I only recorded traces in Wireshark and filtered them (
ssl.record.version == "TLS 1.0"):
This is a repost of my article, originally published on CodeProject on 24 May 2016.
The Story of a Memory Dump
Memory dumps are a common way to diagnose various problems with our applications (such as memory leaks or application hangs). You may think of them as photos which allow you to have a look at the past and notice all the details you might have missed. There are different types of memory dumps which we may compare to different types of photos we take:
- minimal – focus is on one element (such as an exception) and the whole background is blurry, they take very little space on the hardrive (eg. 2MB)
- minidumps with thread and process data/heaps/stacks/exception data, etc. – depending on how many options we choose, they might be very detailed high-resolution pictures or very blurry ones, the range of space they take can vary from tens of MBs to several GBs
- full memory dumps – those can be compared to high-resolution pictures, they are as big as the whole process committed virtual memory
Every developer knows that unit testing improves the quality of the code. We also profit from static code analysis and use tools such as SonarQube in our build pipelines. Yet, I still find that many developers are not aware of a much older way of checking the validity of the code: assertions. In this post, I will present you the benefits of using assertions, as well as some configuration tips for .NET applications. We will also learn how .NET and Windows support them.
I recently spent some time analyzing OutputDebugString method. For my another experiment I needed a version of OutputDebugString which depends only on Native API. While implementing it, I discovered few interesting facts about OutputDebugString that maybe will interest you too. The title mentions System.Diagnostics.Trace. It is because the default trace configuration in .NET sends trace messages to an instance of the DefaultTraceListener class, which uses OutputDebugString. And if you do not remove it explicitly from the trace listener collection, your logs will always go through it. You will later see why sometimes it might not be a good idea.
On the occasion of releasing wtrace 2.2, I decided to write a short post about new functionalities I added to this tool in the recent months. I hope you will find them interesting. Wtrace is a command line application which collects ETW traces from the system and the selected processes and outputs them to the console. It is very simple to use and runs on Windows 7+. Currently, it supports the collection of File I/O, TCP, ALPC, RPC, ISR, DPC, and PowerShell events.