Firmware password

From NAS-Central Buffalo - The Linkstation Wiki
Revision as of 12:41, 19 May 2005 by Sec (Talk) (PPC asm for fun and profit (1))

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

How to find the password for the encrypted zip containing the Firmware?

  • First, find out that ls_servd is responsible for decrypting.

How did i find out? Well bg told me :-)

ice:~/tera>strings ls_servd|grep unzip
/bin/unzip -P %s %s/%s -d %s > /dev/null 2>&1

We have a high chance that the password is actually contained in this binary. However, a brief interlude with a zipcracker and the full result of the "strings" output doesn't find a match, so we need to dig a little bit deeper...

How about disassembling the thing?

Okay. We need a disassembler. "objdump" usually does the trick...

ice:~/tera>objdump -d ls_servd 
/usr/libexec/elf/objdump: ls_servd: File format not recognized

Huh? Why this?

ice:~/tera>file ls_servd 
ls_servd: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), for GNU/Linux 2.4.17, dynamically linked (uses shared libs), stripped

Oh, of course. Its a PPC binary, not an x86 binary.

Some googling later, I now have an (linux) ppc-cross-objdump binary.

ice:~/tera>./ppc-linux-objdump -s -d ls_servd >DUMP
ice:~/tera>vim DUMP

Now we have two new problems.

  • First, the file is big. we have about 8k lines assembler code.
  • Second, I don't know PPC assembler. Well, I know 6510 asm and some x86 asm, but the details of PPC are a mystery to me.

Nothing, a quick google couldn't fix. A PPC asm reference can be found here:

Be sure to also check Chapter 6: Extended mnemonics if you don't find a certain assembler mnemonic.

Now, for understanding the code. First, we need to find the system calls:

10005dec:   3c 60 10 01     lis     r3,4097
10005df0:   38 63 b6 44     addi    r3,r3,-18876
10005df4:   48 01 72 01     bl      1001cff4 <system@plt>

Cool, objdump alredy named them for us. This is a call to system(), which calls an external program. ls_servd uses a lot of system() calls.

Now for the parameter passing. We can assume that r3 is the parameter passed to system() which only takes one argument. Lets see what it is:

The first line fills the upper 16 bits of r3 with 4097 (hex 1001), resulting in r3=0x10010000 And the second line substracts 18876, resulting in r4=1000B644

You can now go and look that up in the hexdump part of the objdump output:

1000b638 613d3078 25303258 0d0a0000 2f736269  a=0x%02X..../sbi
1000b648 6e2f7265 626f6f74 00000000 6c69626c  n/reboot....libl

Which makes the whole thing a call to /sbin/reboot. Yay!