Ramblings on static deobfuscation 2009/03/06Posted by dividead in Reverse engineering.
add a comment
The past few days while not at work I have been thinking a bit about binary deobfuscation, as I’m spending some of my spare time cracking an obfuscated binary.
The anti-disassembly and anti-debugging tricks used in this binary are fairly extensive, ranging from jmps in the middle of instructions (why does this still throw IDA pro off guard this much? At least in a graph representation it should be easily possible to follow both execution paths, so that they can be displayed in an intuitive manner), to insertion of redundant code, nanomites all over the place and so on.
The redundant code introduced by their protection scheme is fairly standard though, and come down to inserted ranges of nop-equivalent code. These redundancies can be easily eliminated through static peephole optimizations, which I implemented in a simple IDC script. However, when one thinks about this a bit, peephole optimization to eliminate such code is a fairly unsafe process if the introduced redundant code is more sophisticated.
To illustrate this, I often ran into an instruction pair such as:
xchg eax, edx xchg eax, edx
Of course my IDC script quickly eliminated this as redundant code, but now consider the following situation:
xchg eax, edx yadda: xchg eax, edx
Obviously this means we cannot trivially eliminate these xchg pairs as they’re not part of the same basic block. We might be able to eliminate them though if all execution paths leading to ‘yadda’ also contain an instruction such as xchg eax, edx. This is already less trivial, but addressable by static analysis tools.
But how about the situation where the disassembler, say IDA, cannot find a cross reference to yadda in the first place? I.e. when yadda is a dynamically calculated target? This would mean that my script (and likely others that focus on static reduction of redundant code) will eliminate these instructions without a second thought, making it a destructive operation.
Now forceful construction of such situations is also doable; suppose at some point in the original program there is a xchg eax, edx instruction, we could decide to create a stub function in the program containing only assumed noop codes, par examplum the following:
yadda: add eax, 10 sub eax, 20 lea eax, [eax+10] pushf test eax, 0xbadc0de popf xchg eax, edx xchg eax, edx and edx, 0xFFFFFFFF ret
This would appear like a function containing only redundant code, and we could insert calls to it in many places, which deobfuscators would likely eliminate altogether with the function. But if we start replacing xchg eax, edx instructions in our original program with dynamically calculated call instructions to the second xchg instruction in the function such an elimination would be a destructive operation.
This example presented such a trick by abusing two instructions in a row, but it may also be possible to perform this trick when an instruction with multiple bytes is involved, where for instance the operand is an instruction itself. Consider:
yadda: and esi, esi
Dynamically branching to yadda + 1 (which by the way is 0xF6 — the opcode for div) will also wreak havoc on unsuspecting redundancy elimination. Pure static analysis of binaries containing these tricks seems a fairly inadequate approach to me.
Foundry SuperX SSH authentication 2009/03/02Posted by dividead in Networking.
Tags: braindead design, foundry
1 comment so far
Today a new Foundry FastIron SuperX Premium switch was delivered at my work, so of course I took the opportunity to play around with it.
Setting up ssh public-key authentication to login to the management cli was one of my goals, as being a programmer I’m bored with repetitive tasks such as typing the same password over and over again.
Sadly, this process was far more messy than one could hope for — especially when comparing it to Juniper routers which allows you to copy paste an OpenBSD style public-key directly into the configuration, and which just works afterwards.
The firmware version I worked with was the following, in order to see wether your mileage may vary.
Compressed Pri Code size = 3811736, Version 04.0.01aT3e3 (SXR04001a.bin)
Compressed Sec Code size = 3156827, Version 04.0.01aT3e1 (SXL04001a.bin)
Compressed BootROM Code size = 524288, Version 04.0.00T3e5
First we need to create a user account, and allow it to be used for local authentication.
username foobar privilege 0 password fnord
aaa authentication login default local
Now we need to setup the SSH server itself, by generating a host keypair, and making sure that users need to specify a password when logging in.
ip ssh permit-empty-password no
crypto key generate
Please note that setting permit-empty-password to yes turns off password authentication entirely, instead of (what we would intuitively expect) allowing users without a password to login over ssh. This invites for some really messed up ‘secure’ configuration if people do not pay attention.
At this point it should be possible to login through ssh using a password. Ideally I would like to use pubkey based authentication, but sadly the interface allows us to upload public-keys only over TFTP (although scp
seems possible too as long as the management blade has additional PCMCIA flash modules installed).
An additional annoyance is the fact that the firmware only accepts RFC 4716 style keys, so we have to convert any OpenSSH style key by doing the following.
ssh-keygen -e -f id_dsa.pub > id_dsa.pub.ssh2
This file should be offered on a tftp server, so that on the foundry we can import it. According to the documentation these keys are stored on EEPROM immediatly.
ip ssh pub-key-file tftp 126.96.36.199 id_dsa.pub.ssh2
Well, by no means trivial, but finally this should allow for public-key authentication, or not? It seems that as soon as public-key authentication is tried, we suffer from the following message.
Authenticated with partial success.
It seems that after a successful public-key authentication attempt, the Foundry still wants me to perform password authentication, which certainly seems absurd. Of course we can work around this by disallowing password
ip ssh password-authentication no
This is suboptimal when we have a combination of users with passwords and public keys, as well as not allowing me to login through ssh with just a password in case I do not have my pubkey at hand…
Well, this part of the Foundry interface seems more braindead than the average Resident Evil denizen…