Software

Software (4)

Wednesday, 22 October 2014 18:29

How to create a 32bit word based hexdump on Linux

Written by

I have to work a lot with 32bit word aligned data. Unfortunately the hexdump tool included with linux uses byte or short alignment by default. I’ve wondered how to make hexdump to print 32bit words instead including an offset indicator as well as the hexdump typical ascii interpretation.

What I came up with was:

monte@mibix:~$ dd if=/dev/urandom bs=4 count=32 2>/dev/null | hexdump -v -e '"%08_ax: "' -e ' 4/4 "%08x " " |"' -e '16/1 "%_p" "|\n"'
00000000: 4d6ec4eb d5b8921d c3bd306a c0d20d1a |..nM....j0......|
00000010: 228d9a4c 4fd68ea7 6a837903 aca46e9a |L.."...O.y.j.n..|
00000020: 513e32f6 2cbc69db ca18bda0 d74bbe71 |.2>Q.i.,....q.K.|
00000030: b27cfd65 8859a08a db92a090 f81e301d |e.|...Y......0..|
00000040: 029a5e6c 23a3d621 ce35a06d e4b48cbd |l^..!..#m.5.....|
00000050: 2bba6da0 2e0c7f84 536eb6ad 94a4827b |.m.+......nS{...|
00000060: 17699fc1 2231d9d1 43210088 37f97a4c |..i...1"..!CLz.7|
00000070: e474aef3 23483fa7 b7f6ed41 cb01d18a |..t..?H#A.......|monte@mibix:~$ 

The dd command reads the data from a binary file. The block size (bs) is 4 so we read 32bit words. The count is 32 which means we read 128 bytes in total. We pipe stderr to null because we do not want to see the in/out statistic. The stdout output is forwarded to the hexdump command.

We specify the -v option to output all data as is. Otherwise hexdump would shorten equal data. The first -e format parameter tells hexdump to print the offset. The second -e format parameter tells hexump to print 4 times 4 bytes (which is 32bits) in the format with 8 nibbles and trailing zeros. The last -e format tells hexdump to print 16 times one byte as character interpretation. The %_p format will print a „.“ for each non printable character. Note that the last two -e formats print the same data. If you specify all formats with one -e you will get the wrong result.

Thursday, 10 July 2014 10:26

Windows Kernel Mode Wait

Written by

Sometimes you have to wait, even when writing a Windows driver. Well, waiting in kernel mode is a bad idea in general but sometimes it is necessary.

Today I stumbled over a code fragment which I know from my experience does not do what the programmer might have expected. The problem is the function KeDelayExecutionThread. KeDelayExecutionThread was used in a wait function which was designed to wait for any time in micro seconds. The value of micro seconds was passed to KeDelayExecutionThread multiplied by ten to generate a wait time in steps of 100 nano seconds.

 

There are two problems in this approach. First is that KeDelayExecutionThread waits for an absolute time event in case of a positive number. Thus to get the requested delay in micro seconds one has to specify a negative value. The second problem here is that KeDelayExecutionThread yields the process which leads to a very inaccurate delay especially for times smaller than about 50 milli seconds.

 

A better kernel wait function would call KeDelayExecutionThread or KeDelayExecutionThread depending on the situaton.

 

Maybe like this :  

wait( ULONG usec )
{
    ULONG ulReturn = 0;
    if( u_sec < 50000 )
    {
        /* KeDelayExecutionThread yields the process */
        /* Waiting times lower than 50ms are not accurate */
        /* Because of this we need to busy wait here */
        KeStallExecutionProcessor( usec );
    }
    else
    {
        LARGE_INTEGER waittime;
        /* specifies the wait time in steps of 100ns */
        /* Negative values specify a relative time offset */
        waittime.QuadPart = -1 * usec * 10;
        if( STATUS_SUCCESS == KeDelayExecutionThread( KernelMode, TRUE, &waittime ) )
            ulReturn = 0;
        else
            ulReturn = 1;
    }
    return ulReturn;
}

 

python utf8

Many programmers including me like short variable names. We consider programming as an art where the source code is the paint and the screen is the canvas. However source code should be written as easy to understand as possible. This is because source code is almost never documented well enough. I believe that well written source code explains itself to the reader through variable, class, object and method names. Of course tricky parts should still be commented.

When looking for descriptive variable names you often end up with very long variable names, which when passed to long function names look rather ugly on the canvas. It came to my mind some years ago how interesting it would be to write software by using languages that can describe words with short characters like Japanese or Chinese. Some days ago I checked out the changes in Python 3 and surprisingly they do now support full Unicode variable names. I instantly upgraded my rasberry pi with python3 which was quite a hassle because python 2.x is still the standard many programs depend on. Once installed I wrote my first Chinese program, a Person class. The class has a constructor as well as the methods walk, run, sit and drink. When drinking you can pass a variable of what kind the person is drinking.

The screen shot above shows the source code in my favorite editor jed. The screen shot below shows the output of the program when executed.

Happy scripting.