From NAS-Central Buffalo - The Linkstation Wiki
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: http://www-aix.informatik.uni-tuebingen.de/doc_link/en_US/a_doc_lib/aixassem/alangref/toc.htm
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!