Monday, November 5, 2012

On bzr-svn and svn-buildpackage

You might think that it would be hard to build a Debian package maintained in Subversion that you've checked out using bzr-svn; I certainly couldn't find anything actually about it when I searched for bzr-svn svn-buildpackage, whereas for git-svn svn-buildpackage I found some stuff obviously about that (but which didn't turn out to actually work).

However, it looks like the real reason nobody seems to say much about this is that it's actually drop-dead easy: just use bzr-builddeb as if it were really just a bzr branch! (It certainly seems to work with cm-super.)

Hopefully, this blog post will aid future searchers, even if I don't have much google-juice…

Saturday, June 2, 2012

Note on PowerPC relocations

It turns out that the #ha function, defined as #ha(x) = (((x >> 16) + ((x & 0x8000) ? 1 : 0)) & 0xFFFF) in the System V Application Binary Interface: PowerPC Processor Supplement, can also be implemented as #ha(x) = ((x + 0x8000) >> 16) & 0xFFFF, or simply #ha(x) = #hi(x + 0x8000):

Prelude Data.Bits Data.Int> let ha :: Int32 -> Int16; ha x = fromIntegral (x `shiftR` 16) + (if testBit x 15 then 1 else 0)
Prelude Data.Bits Data.Int> let hi :: Int32 -> Int16; hi x = fromIntegral (x `shiftR` 16)
Prelude Data.Bits Data.Int> all (\x -> ha x == hi (x + 0x8000)) [-0x20000..0x20000]

This could be useful in IDA, which does not have an offset type appropriate for R_PPC_ADDR16_HA relocations.

Wednesday, October 12, 2011

GDB: Quickly attach to the only instance of a program

Wouldn't it be nice if, instead running shell pidof foo and pasting the resulting PID into an attach command, you could just run one command to attach to your inferior? Sort of like this:
(gdb) qattach crawl
[Thread debugging using libthread_db enabled]
0xb7d1588e in __open_nocancel () at ../sysdeps/unix/syscall-template.S:82
82      ../sysdeps/unix/syscall-template.S: No such file or directory.
        in ../sysdeps/unix/syscall-template.S
(gdb)
Well, now you can! Just arrange for GDB to run the following Python code first, which (gdb) Python Commands and (gdb) Startup will show you how to do:

# Copyright (c) 2011 Samuel Bronson
#
# This software is made available under the same license as the
# "expat" XML library for C, or the "do whatever you want" license, at
# your option.

# Note: The subprocess.check_output() function is new in Python 2.7.

class QAttach(gdb.Command):
    """Quickly attach to the only instance of a program."""

    def __init__(self):
        super(QAttach, self).__init__("qattach", gdb.COMMAND_RUNNING, gdb.COMPLETE_FILENAME)

    def invoke(self, arg, from_tty):
        import subprocess

        if not arg:
            print "qattach: Missing target name!"
            return

        pids = subprocess.check_output(['pidof', arg]).split()

        if len(pids) != 1:
            print subprocess.check_output(['ps'] + pids)
        else:
            try:
                gdb.execute("detach")
            except:
                pass
            gdb.execute("attach "+pids[0])

QAttach()

Saturday, May 28, 2011

CRC: A Paper On CRCs

Check out this CRC paper, it really makes it easier to understand CRC implementations.

This CRC web was created because of the popularity of a paper on CRC algorithms written by Ross Williams and posted to some Internet newsgroups on 19 August 1993. This paper is available here:

Here is the title and abstract of the paper:

A Painless Guide to CRC Error Detection Algorithms

This document explains CRCs (Cyclic Redundancy Codes) and their table-driven implementations in full, precise detail. Much of the literature on CRCs, and in particular on their table-driven implementations, is a little obscure. This document is an attempt to provide a clear and simple no-nonsense explanation of CRCs and to absolutely nail down every detail of the operation of their high-speed implementations. In addition to this, this document presents a parameterized model CRC algorithm called the "Rocksoft™ Model CRC Algorithm". The model algorithm can be parameterized to behave like most of the CRC implementations around, and so acts as a good reference for describing particular algorithms. A low-speed implementation of the model CRC algorithm is provided in the C programming language. Lastly there is a section giving two forms of high-speed table driven implementations, and providing a program that generates CRC lookup tables.

Saturday, September 18, 2010

Sunday, July 18, 2010

Undocumented [debug] section in boot.ini enables boot debugger

In order to use the .kdfiles command to replace a boot driver on the target for NT kernel debugging, it is necessary to use the ntldr "boot debugger", BD. This is because ntldr, not the NT kernel, is responsible for reading these drivers off of disk and loading them into memory: by the time the ordinary kernel debugging connection is established, it is far too late to do anything about the boot drivers. Ordinarily, the way you are supposed to do this is by using a special version of ntldr which automatically waits for a kernel debugging connection every time you start it. This version is included in the Driver Development Kit with the name ntldr_dbg. Unfortunately, each DDK only includes the ntldr_dbg for one version of Windows; there's no telling what might happen if e.g. you try to use the Windows Server 2003 SP1 ntldr_dbg with XP SP2. (At least, I didn't want to risk trying it. Maybe it would work fine.) However, it turns out that there is another way: at least in the checked build of ntldr, it is possible to enable the boot debugger using an undocumented section in boot.ini. For example, I just started it with a boot.ini that begins:
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

[debug]
/debug /debugport=COM1 /baudrate=115200 /debugstop

[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="XP with Serial Debugging" /fastdetect /debug /debugport=COM1 /baudrate=115200

Warning: these flags will make it impossible to boot without attaching a kernel debugger to your system. It is therefore vital that you:

  1. Have access to a second system on which to run the kernel debugger
  2. Have a null-modem cable
  3. Remember to remove the option when you're done, and while you still have the second system handy!

If you end up with a system that doesn't boot, don't say I didn't warn you... but you could probably fix things by using e.g. a copy of Knoppix to take out the offending lines of boot.ini.

The /DEBUGBREAK flag breaks into the debugger immediately after it is initialized, allowing you to single-step through the rest of the boot process. Note that in order to actually debug the bootloader, you will probably need to do something like the following after extracting the embedded PE image (internally called osloader.exe) from your ntldr:
kd> .readmem C:\code\deadweight-syms\ntldr.chk.pe 0x400000 L0x1000
Reading 1000 bytes..
kd> .imgscan /l /r 00400000 
MZ at 00400000 - size 81000
  Name: osloader.EXE
  Loaded osloader.EXE module
The value 0x400000 in these commands is the address at which the PE image got loaded; in my case, osloader.exe was a non-relocatable image with the usual image base address of 0x400000. I needed to run these commands because the ntldr I tried this on, the one from the checked build of Windows XP SP2, (a) did not have the PE header in memory at the time it broke into the debugger and (b) did not tell the debugger about it's base address and so on. There was a call to DbgLoadImageSymbols immediately prior to the breakpoint, but the DbgLoadImageSymbols in question did not actually do anything. I'm guessing that things are different if you actually use the version distributed as ntldr_dbg. Anyway, once you do the above dance, you should get symbols loaded just fine, assuming you've got the MS Symbol Server in your symbol path.

Tuesday, July 13, 2010

MSVC SEH handlers & signature strings

This is just a table of the assembly-level names of SEH handling routines used by MSVC, along with the the (non-null-terminated) signature string that appears immediately prior to each of them. Each signature string is eight ASCII bytes, though even IDA usually mistakes it for machine code and disassembles it.

SignatureHandler name
db 'VC10XC00'__except_handler2
db 'VC20XC00'__except_handler3

For more information about SEH and its implementation in MSVC, see A Crash Course on the Depths of Win32™ Structured Exception Handling and Reversing Microsoft Visual C++ Part I: Exception Handling . The latter will even give you enough information that you should be able to figure out why the information in this table might be useful ;-).