Point Of Interest

When I started PowerShell PKI module project, I quickly realized that I will have to deal with abstract syntax notation one (ASN.1) with distinguished encoding rules (DER) encoding subset. This is because all transferrable cryptographic objects are encoded in ASN.1 and in DER encoding. X.509 certificates, revocation lists, trust lists, OCSP, etc., etc..

While reading related literature (ASN.1 — Communication Between Heterogeneous Systems by Olivier Dubuisson) and other ad-hoc articles, I looked for a tool that would visualize ASN-encoded data to test and verify my own ASN.1 parser. There are few and almost all of them are too expensive. Eventually I found a free ASN.1 editor written by Liping Dai.

The tool is great, but wanted few changes there. I downloaded sources, opened in Visual Studio and closed. The tool is written by using WinForms and I wasn’t able to understand the codebase. Since I already have my own ASN.1 parser, I decided to make similar tool, but with brand-new codebase and presentation layer. I’m not a WinForms fan, so presentation is delivered by Windows Presentation Framework (WPF) with MVVM pattern.

Interesting: I caught myself thinking that I almost never did something really my own. All my WPF projects are visual copies of other tools. For example, PS Cmdlet Help Editor is a working copy of non-working Cmdlet Help Editor, SSL Verifier is a working copy of non-working Certificate Expiration Verification Tool. Now, ASN.1 editor. However, existing tool is working. I’d say, this is just a code migration.

Same look new quality?

As a start point, I copied existing tool’s visual behavior, so existing editor users will not have difficulties in working with my own editor. Brand-new codebase means that no code was inherited from original project (actually, I stole few lines from helpers). I think, new codebase provides more extensibility features and is easier to read and maintain. Ok, let’s go, new editor look is similar:

and comparing with previous tool:

Very similar, so existing editor users will not face problems while using my own (if they wish to use new editor).

I reused previous editor tree view icons. However, they might be a subject for copyright, I’m looking for a new icon design. I tried to order a set on fiverr.com, however, I wasn’t satisfied with the result. Although new icons were better, they didn’t fit data type representation.

During UI development I faced a lot of problems and most of them were solved by searching stackoverflow.com web site. For example, TreeView control in WPF do not have horizontal and vertical lines and is very uncomfortable with large tree with various levels. Relatively quickly, I found an answer and used it in the project. In general stackoverflow.com solved all my problems. And it is worth to note that I didn’t asked any question there. Everything got from extensive search of existing topics.

Main Features

Main features in most are the same:

Dump Text Format data

You can view the selected node branch text dump by right-clicking the designated node and selecting “View Node Text”:

This window provides TreeView textual visualization. It defines four columns:

• Offset – specifies the start offset of the specified structure;
• Len – specifies the structure’s payload length in bytes;
• LenByte – specifies how many bytes are required to store length bytes (including transitional length byte). I’m not sure whether it is necessary, maybe we need more interesting data?
• Tree View text visualizer with decoded primitive type value.

You can save this information to a file and print, if necessary.

Hex data viewer

in previous tool, hex data viewer was a separate window. I decided to combine them in the same window. By default, hex viewer is collapsed and can be opened by toggling the button in the toolbar. Hex viewer panel contains two toggle buttons. They are used to hide hex address and ASCII data panes:

When you select node in the Tree View panel, corresponding bytes are highlighted in the hex viewer:

• Red – this color indicates tag byte
• Green – this color indicates length bytes. This includes transitional byte (if any).
• Black: this color indicates the payload bytes.

Node data editor

By double-clicking on a node (or selecting from tree node context menu), a node data editor is opened:

You can edit data for any primitive non-constructed type (except, NULL tag). Explicit value presentation depends on data type. For many types, textual value is displayed and allowed for input. However, not for all types there is encoder and decoder, so for certain types you will see raw hex view (and raw hex text should be inserted):

As already said, NULL and constructed types are not editable:

Node content editor applies restrictions for certain data types. For example, if you are editing numeric strict, the code verifies whether all characters in the text are valid for numeric string.

Save Selected Node Data into Another File

You can save the selected node data into a file by right-clicking the node and selecting "Save selected node as...". Data is saved as a binary copy of the entire selected structure, including tag header and full tag payload.

Operations with nodes

You can cut, copy and paste existing nodes. You can use either context menu or toolbar. There are three options of paste destination:

• Before selected node;
• After selected node;
• Paste a as a last child node of the parent. In other words, as the last node in the current level.

When you operate with nodes, internal raw data and hex viewer are updated accordingly.

Data converter

Data converter window allows you to convert the data between various text encodings:

This window maintains internal data source, so changes here are not reflected in main tree view. When you open data converter, data source from main tree view is copied to data converter window. Alternatively, you can open external file or paste text from clipboard. When you paste text from clipboard, you need to click Validate button, so converter will attempt to decode the pasted data format. Unlike with previous editor, you don’t need to care about source encoding, converter will do it for you. By clicking appropriate radiobutton, the data is converted to a appropriate format:

You can save this view to a file as a text, or as a pure binary copy (converted from pasted text). Also, you can print current view.

The code is smart enough to detect the pasted text format (or opened file content format) and is able to convert, for example, hex view with address and ASCII panes, or base64 with or without header to a raw byte array. In addition, the code correctly handles files saved in UTF-7, UTF-8, Unicode and UTF-32 encoding.

What next?

I don’t know. Currently, the editor is available only in my blog (link for download is below). Will I put it to CodePlex and publish regular updates (with bug fixes and improvements)? It is up to you, my dear readers. To be honest, I’m a bit disappointed with all the stuff I’m doing (except PSPKI module). SSL Verifier got zero feedback, PS Cmdlet Help Editor has very little feedback. Even Microsoft (PowerShell team) showed zero interest in help editor.

I’m not whining, I just don’t think that I should put any effort on tools which nobody needs. Plain and simple. So, if you find an interest in the tool and there will be at least a group of followers, then I will work on the tool with public updates, otherwise, all you see here is all you get and nothing else. Any feedback (positive, neutral or negative) please, in comments.

Just to note, there are several things to work on:

• improve input data format detection. It is hard to differentiate the ANSI text and pure binary content;
• improve input data validation (warn user if he entered invalid data) for node content editor;
• make node content editor more convenient. For example, display date/time picker for UTCTime and GeneralizedTime ASN.1 primitive tags.
• Implement indefinite tag length support for ASN.1 parser.

Download

The article and download links are permanently moved to: ASN.1 Editor directory.