Reverse Engineering on Kartone's Reversing Garage

An extensive step by step reverse engineering analysis of a Linux CTF binary

Mon, 25 Mar 2019 09:00:00 +0000

…or, in other words, when failing to reverse a CTF binary makes you lose that job.

During a past job interview, I was tasked to reverse four linux binaries of increasing difficulties as proof of my ability into the reverse engineering field. I solved the first two in a matter of an hour, the third one required me an entire day of work but sadly, I was not able to solve the last one. I don’t know if I wasn’t selected because of this fail, but it proved me one sure thing: I wasn’t prepared enough or, at least, as much as I wanted. Flash forward, I successfully ended up with another job, but that challenge kept staying there, like a small needle, in my head. During the following months, I studied and practiced a lot, mainly into firmware reversing field and, every now and then, I’ve tried to solve that sneaky challenge.

This is my extensive and detailed description of my fails and success.

Important note

Please note that as this analysis started some months ago and this post was reviewed a huge number of times, you won’t find same memory addresses or function names across the screenshots and code snippets.

Running the binary

With what are we dealing?

root@kali:/opt/ctf# file original
original: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=d0d5b9a34a4fe4c52a3939c75bd71cfa0dc23825, stripped
root@kali:/opt/ctf# checksec -f ./original
RELRO STACK CANARY NX PIE RPATH RUNPATH Symbols FORTIFY Fortified Fortifiable FILE
Partial RELRO No canary found NX enabled PIE enabled No RPATH No RUNPATH No Symbols No 0 2 ./original

A standard, stripped, Linux 32bit binary with no fancy protection active. We’re not aiming to exploit it but only to find the flag. A picture is worth a thousand words, they say:

root@kali:/opt/ctf# ./original
[-] No vm please ;)
root@kali:/opt/ctf# ./original AAAA
[-] No vm please ;)
root@kali:/opt/ctf# ./original -h
[-] No vm please ;)
root@kali:/opt/ctf# ./original AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
[-] No vm please ;)
root@kali:/opt/ctf#

It doesn’t run inside a virtual machine and I definitely don’t want to build a physical linux box. Would you tell me some of your internals, please?

root@kali:/opt/ctf# strace ./original
execve("./original", ["./original"], 0x7fff2a7dc4f0 /* 48 vars */) = 0
strace: [ Process PID=121645 runs in 32 bit mode. ]
brk(NULL) = 0x572fb000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7f05000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=133840, ...}) = 0
mmap2(NULL, 133840, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf7ee4000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/i386-linux-gnu/libc.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\254\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1947056, ...}) = 0
mmap2(NULL, 1955712, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7d06000
mprotect(0xf7d1f000, 1830912, PROT_NONE) = 0
mmap2(0xf7d1f000, 1368064, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19000) = 0xf7d1f000
mmap2(0xf7e6d000, 458752, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x167000) = 0xf7e6d000
mmap2(0xf7ede000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d7000) = 0xf7ede000
mmap2(0xf7ee1000, 10112, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf7ee1000
close(3) = 0
set_thread_area({entry_number=-1, base_addr=0xf7f060c0, limit=0x0fffff, seg_32bit=1, contents=0, read_exec_only=0, limit_in_pages=1, seg_not_present=0, useable=1}) = 0 (entry_number=12)
mprotect(0xf7ede000, 8192, PROT_READ) = 0
mprotect(0x565b8000, 4096, PROT_READ) = 0
mprotect(0xf7f34000, 4096, PROT_READ) = 0
munmap(0xf7ee4000, 133840) = 0
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xf7f06128) = 121646
waitpid(121646, [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0) = 121646
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=121646, si_uid=0, si_status=1, si_utime=0, si_stime=0} ---
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x1), ...}) = 0
brk(NULL) = 0x572fb000
brk(0x5731c000) = 0x5731c000
brk(0x5731d000) = 0x5731d000
write(1, "**[-] You fool, nobody debugs me!!**"..., 34[-] You fool, nobody debugs me!!!
) = 34
write(1, "1\n", 21
) = 2
exit_group(-1) = ?
+++ exited with 255 +++

“You fool, nobody debugs me!!!”

Great, after a few couples of runs, we know that there are some anti-VM and anti-debug code in place. Let’s look inside.

First thing, I searched and found the strings pretty quickly, and I noticed also two other interesting strings: one for a fail, one for a success.

Digging a little more, we can find where are placed the strings and from where they’re used for.

It’s clear that the subroutine placed at address 0x566429DC has something to do with them and with the anti-VM/anti-debug tricks.

Analyzing the anti-debug and anti-vm routine

Once I have identified where are the strings involved in this anti-debug and anti-vm tricks, it’s easy to find them and visualize the blocks in IDA. Please note that sub_566429DC was here renamed in AntiDebugAntiVM.

This is the graph of the AntiDebugAntiVM functions. In the first block of code, we can see the standard function call convention that setup the stack frame. After that, a bunch of NOPS and a call to fork(). Let’s understand the fork call, what’s its purpose?

fork() creates a new process by duplicating the calling process. The new process, referred to as the child, is an exact duplicate of the calling process, referred to as the parent. On success, the PID of the child process is returned in the parent, and 0 is returned in the child. On failure, -1 is returned in the parent, no child process is created, and errno is set appropriately. (ref)

Basically, right after the fork call, its return value is saved into the EAX register and then moved into a local variable that is compared with the zero value. The first branch is important: if the JNZ is true, we’re into the parent process so we’re going into the right path. Vice versa, if the instruction is false we’re heading to the left or into the child process.

Into the child process

If EAX is zero, or in other terms, we’re into the child process, we can see a call to getppid()function that returns the process ID of the parent of the calling process. But the important call is the next one, the call to the ptrace() function. The standard definition of this function is:

The ptrace() system call provides a means by which one process (the"tracer") may observe and control the execution of another process(the “tracee”), and examine and change the tracee’s memory and registers. It is primarily used to implement breakpoint debugging and system call tracing.

And is defined as:

long ptrace(enum __ptrace_request request, pid_t pid, void *addr, void *data);

In assembly, the call is built with these lines of code:

push 0 ; *data
push 0 ; *addr
push [ebp+var_1C] ; Parent PID
push 10h ; _ptrace_request
call _ptrace

Basically, the child retrieve its PPID and tries to attach a debugger [1], if it fails, it’s the evidence that it is being debugged so sleep 5 seconds, detach and returns [2] . Otherwise returns anyway [3]. Going up a level, if the fork() return -1 so returns with the status code 1 [5]

Into the parent process

If EAX is not zero, we’re in the right path, so in the parent process. As you can remember, we have the PID of the child into the EAX register. After the check with -1 into the block [1], it goes into the block [2]. Here, the parent performs a call to waitpid():

push 0 ; options
lea eax, [ebp+stat_loc]
push eax ; stat_loc
push [ebp+pid] ; child PID
call _waitpid

The waitpid() system call is used to wait for state changes in a child of the calling process, and obtain information about the child whose state has changed. A state change is considered to be: the child terminated; the child was stopped by a signal; or the child was resumed by a signal. In the case of a terminated child, performing a wait allows the system to release the resources associated with the child; if a wait is not performed, then the terminated child remains in a “zombie” state. (ref)

On success, waitpid() returns the process ID of the child whose state has changed; On error, -1 is returned. In the next blocks 2, 3, 4 and 5 what happens is described in this answer I got on ReverseEngineering. There’s no need to add anything more.

Anti-VM code

This is where things become fun and interesting. We can observe a bunch of mov instructions into the stack, a loop and inside of it an interesting xor instruction: xor eax, 75h. It seems to be a loop that cycle 0x32 times (50in decimal) and starting from [ebp+command] it xors one byte at a time to a fixed value equal to \x75. Pretty standard XOR decryption routine, right? We can try to replicate this routine in python:

#!/usr/bin/python
hexdata = "19061605005509551207100555523D0C051007031C061A07525509550107555811555255525509551600015558114F55581347"
binary = hexdata.decode("hex")
def xor_strings(data):
return "".join(chr(ord(data[i]) ^ 0x75) for i in range(len(data)))
xored = xor_strings(binary)
print "Your decrypted string is: " + xored

root@kali:/opt/ctf# ./script.py
Your decrypted string is: lscpu | grep 'Hypervisor' | tr -d ' ' | cut -d: -f2

Basically, it decrypts in memory a shell command and execute it via the next popen syscall that verifies, using the lscpu command, if the CPU name contains a string Hypervisor. This syscall looks pretty interesting:

The popen() function opens a process by creating a pipe, forking, and invoking the shell. Since a pipe is by definition unidirectional, the type argument may specify only reading or writing, not both; the resulting stream is correspondingly read-only or write-only. The command argument is a pointer to a null-terminated string containing a shell command line. This command is passed to /bin/sh using the -c flag; interpretation, if any, is performed by the shell. The type argument is a pointer to a null-terminated string which must contain either the letter ‘r’ for reading or the letter ‘w’ for writing. popen(): on success, returns a pointer to an open stream that can be used to read or write to the pipe; if the fork(2) or pipe(2) calls fail, or if the function cannot allocate memory, NULL is returned.

After the stream is opened, another syscall fgetc() is executed.

fgetc() reads the next character from stream and returns it as an unsigned char cast to an int, or EOF on end of file or error.

What happens is simple: it opens a stream, in read-only mode, and executes the command 'lscpu | grep 'Hypervisor' | tr -d ' ' | cut -d: -f2' . If it returns something, so the grep returns something, we’re in a virtual machine, prints the string: [-] No vm please ;) and exit. If the stream fails or it does not return anything, it closes the stream via the fclose() syscall and returns.

Everything becomes clear if we look now into the pseudo-code, with important variables renamed as their role.

int AntiDebugAntiVM()
{
char command; // [esp+4h] [ebp-54h]
char v2; // [esp+5h] [ebp-53h]
char v3; // [esp+6h] [ebp-52h]
char v4; // [esp+7h] [ebp-51h]
char v5; // [esp+8h] [ebp-50h]
char v6; // [esp+9h] [ebp-4Fh]
char v7; // [esp+Ah] [ebp-4Eh]
char v8; // [esp+Bh] [ebp-4Dh]
char v9; // [esp+Ch] [ebp-4Ch]
char v10; // [esp+Dh] [ebp-4Bh]
char v11; // [esp+Eh] [ebp-4Ah]
char v12; // [esp+Fh] [ebp-49h]
char v13; // [esp+10h] [ebp-48h]
char v14; // [esp+11h] [ebp-47h]
char v15; // [esp+12h] [ebp-46h]
char v16; // [esp+13h] [ebp-45h]
char v17; // [esp+14h] [ebp-44h]
char v18; // [esp+15h] [ebp-43h]
char v19; // [esp+16h] [ebp-42h]
char v20; // [esp+17h] [ebp-41h]
char v21; // [esp+18h] [ebp-40h]
char v22; // [esp+19h] [ebp-3Fh]
char v23; // [esp+1Ah] [ebp-3Eh]
char v24; // [esp+1Bh] [ebp-3Dh]
char v25; // [esp+1Ch] [ebp-3Ch]
char v26; // [esp+1Dh] [ebp-3Bh]
char v27; // [esp+1Eh] [ebp-3Ah]
char v28; // [esp+1Fh] [ebp-39h]
char v29; // [esp+20h] [ebp-38h]
char v30; // [esp+21h] [ebp-37h]
char v31; // [esp+22h] [ebp-36h]
char v32; // [esp+23h] [ebp-35h]
char v33; // [esp+24h] [ebp-34h]
char v34; // [esp+25h] [ebp-33h]
char v35; // [esp+26h] [ebp-32h]
char v36; // [esp+27h] [ebp-31h]
char v37; // [esp+28h] [ebp-30h]
char v38; // [esp+29h] [ebp-2Fh]
char v39; // [esp+2Ah] [ebp-2Eh]
char v40; // [esp+2Bh] [ebp-2Dh]
char v41; // [esp+2Ch] [ebp-2Ch]
char v42; // [esp+2Dh] [ebp-2Bh]
char v43; // [esp+2Eh] [ebp-2Ah]
char v44; // [esp+2Fh] [ebp-29h]
char v45; // [esp+30h] [ebp-28h]
char v46; // [esp+31h] [ebp-27h]
char v47; // [esp+32h] [ebp-26h]
char v48; // [esp+33h] [ebp-25h]
char v49; // [esp+34h] [ebp-24h]
char v50; // [esp+35h] [ebp-23h]
char v51; // [esp+36h] [ebp-22h]
char v52; // [esp+37h] [ebp-21h]
int stat_loc; // [esp+38h] [ebp-20h]
__pid_t ParentPID; // [esp+3Ch] [ebp-1Ch]
FILE *stream; // [esp+40h] [ebp-18h]
__pid_t ChangedStateChildPID; // [esp+44h] [ebp-14h]
__pid_t ChildPID; // [esp+48h] [ebp-10h]
unsigned int i; // [esp+4Ch] [ebp-Ch]
ChildPID = fork();
if ( !ChildPID )
{
ParentPID = getppid();
if ( ptrace(PTRACE_ATTACH, ParentPID, 0, 0) )
{
stat_loc = 1;
exit(1);
}
sleep(5u);
ptrace(PTRACE_DETACH, ParentPID, 0, 0);
exit(0);
}
if ( ChildPID == -1 )
exit(1);
do
ChangedStateChildPID = waitpid(ChildPID, &stat_loc, 0);
while ( ChangedStateChildPID == -1 && *__errno_location() == 4 );
if ( BYTE1(stat_loc) )
{
printf("[-] You fool, nobody debugs me!!!\n%d\n", BYTE1(stat_loc));
exit(-1);
}
command = 0x19;
v2 = 6;
v3 = 0x16;
v4 = 5;
v5 = 0;
v6 = 0x55;
v7 = 9;
v8 = 0x55;
v9 = 0x12;
v10 = 7;
v11 = 0x10;
v12 = 5;
v13 = 0x55;
v14 = 0x52;
v15 = 0x3D;
v16 = 0xC;
v17 = 5;
v18 = 0x10;
v19 = 7;
v20 = 3;
v21 = 0x1C;
v22 = 6;
v23 = 0x1A;
v24 = 7;
v25 = 0x52;
v26 = 0x55;
v27 = 9;
v28 = 0x55;
v29 = 1;
v30 = 7;
v31 = 0x55;
v32 = 0x58;
v33 = 0x11;
v34 = 0x55;
v35 = 0x52;
v36 = 0x55;
v37 = 0x52;
v38 = 0x55;
v39 = 9;
v40 = 0x55;
v41 = 0x16;
v42 = 0;
v43 = 1;
v44 = 0x55;
v45 = 0x58;
v46 = 0x11;
v47 = 0x4F;
v48 = 0x55;
v49 = 0x58;
v50 = 0x13;
v51 = 0x47;
v52 = 0;
for ( i = 0; i <= 50; ++i )
*(&command + i) ^= 0x75u;
stream = popen(&command, "r");
if ( stream && fgetc(stream) != -1 )
{
puts("[-] No vm please ;)");
exit(-1);
}
return fclose(stream);
}

First round of conclusions

Right now it may seem pretty easy, but for me at that time, this was impossible to understand and represented the first big fail: I was not prepared with interpreting assembly XOR instruction, decryption loops and Linux syscalls. I spent almost an entire weekend on this and failed so hard. Because of the time constraints of the job selection, I sent my results without this last exercise and maybe this influenced my performance into the selection. How to bypass all these checks? We need to find from where this function is called and maybe we could modify the code flow to avoid this calling.

Jumping away

With the IDA basic functionalities, we can find where this function is called and, luckily for us, it’s called from a single location:

The instruction that calls the function is located inside this sub_E00 and, in particular, IDA shows that’s the instruction: call ds:(off_2EF0-3000h) [ebx+edi*4]. Looking around this code we can patch the jz short loc_E55 into a jmp, so we would be able to circumvent all of the above protections.

Cheating with the shell

If you don’t want to patch the binary, there’s another way to fool this VM check, but not the anti-debug. If you notice, the command passed as an argument to the popen syscall is a normal shell command but with a relative path. So quick and dirty trick would be to create a fake lscpu like this:

#!/bin/bash
echo "I will run you anyway in this VM"

Be sure to export the directory inside the PATH variable and, basically, you’re done: when the binary will try to execute the lscpu command, it will run the fake one, it won’t return anything containing Hypervisor string, the grep would return nothing and the fgetc consequently will read nothing. Basically, all checks are positive. Easy as it seems.

Analyzing the self decrypting and injecting routine

We can take advantages of the debugging capabilities of IDA and playing with breakpoints. Single stepping into the program flow, after the above routines, we land into this interesting piece of code:

I spent a lot of days trying to understand this routine: but it was worth it because I learned a lot: I learned about linux syscalls like mprotect, calloc and also memcpy. I learned about how the code could auto-decrypt and auto-inject inside the binary itself. Moreover, how can be possible to change memory protections back and forth. Indeed, it was very helpful to look around this code, side by side, with its decompiled version:

int sub_CB5()
{
char v0; // si
size_t v1; // eax
char s; // [esp+8h] [ebp-30h]
char v4; // [esp+9h] [ebp-2Fh]
char v5; // [esp+Ah] [ebp-2Eh]
char v6; // [esp+Bh] [ebp-2Dh]
char v7; // [esp+Ch] [ebp-2Ch]
char v8; // [esp+Dh] [ebp-2Bh]
char v9; // [esp+Eh] [ebp-2Ah]
char v10; // [esp+Fh] [ebp-29h]
char v11; // [esp+10h] [ebp-28h]
char v12; // [esp+11h] [ebp-27h]
char v13; // [esp+12h] [ebp-26h]
char v14; // [esp+13h] [ebp-25h]
char v15; // [esp+14h] [ebp-24h]
char v16; // [esp+15h] [ebp-23h]
char v17; // [esp+16h] [ebp-22h]
char v18; // [esp+17h] [ebp-21h]
char v19; // [esp+18h] [ebp-20h]
char v20; // [esp+19h] [ebp-1Fh]
char v21; // [esp+1Ah] [ebp-1Eh]
char v22; // [esp+1Bh] [ebp-1Dh]
void *src; // [esp+1Ch] [ebp-1Ch]
_BYTE *v24; // [esp+20h] [ebp-18h]
void *addr; // [esp+24h] [ebp-14h]
size_t n; // [esp+28h] [ebp-10h]
size_t i; // [esp+2Ch] [ebp-Ch]
n = 320;
addr = 0;
v24 = &unk_E78;
mprotect(0, (size_t)((char *)&unk_E78 - 0xFFFFD000 - 12288), 6);
s = 0xF9u;
v4 = 0xFCu;
v5 = 0xFFu;
v6 = 0xE6u;
v7 = 0xF5u;
v8 = 0xE0u;
v9 = 0xF1u;
v10 = 0xF3u;
v11 = 0xFBu;
v12 = 0xF9u;
v13 = 0xFEu;
v14 = 0xF7u;
v15 = 0xFDu;
v16 = 0xE9u;
v17 = 0xF3u;
v18 = 0xFFu;
v19 = 0xF4u;
v20 = 0xF5u;
v21 = 0;
src = calloc(0x141u, 1u);
for ( i = 0; i < n; ++i )
{
v22 = *((_BYTE *)sub_89B + i);
v0 = v22 ^ 0x90;
v1 = strlen(&s);
*((_BYTE *)src + i) = *(&s + i % v1) ^ v0;
}
memcpy(sub_89B, src, n);
return mprotect(addr, v24 - (_BYTE *)addr, 4);
}

TL;DR

Before we go deep into the details of the single blocks of code, giving a general overview of what its final purpose is, may help its comprehension. First thing, the code changes via mprotect function the memory protections, adding the write permission, of a specific part of its .text section. After that, it copies, into the stack, some bytes that will be revealed as a key for an afterward decryption. Before entering into the main loop, it allocates an array of bytes into the heap via calloc. Specifically, the length of the array is 0x140 bytes; this value is saved into a local variable placed into the stack at [ebp+n] offset. The main loop is somehow complicated because it xors byte per byte some of its code, placed at sub_89B+i offset, with a fixed constant 0x90 and after, it xors it again with the aforementioned key on the stack. After that, it overwrites the code placed at sub_89B offset, with these new values via the memcpy call and returns after changing again the memory protections of that code section back to read-execute. Let’s break in line by line, considering only the useful ones.

Here, it setups the length of the future array in the variable placed on the stack at [ebp+n] with the size of 0x140 or 320 elements of 1 byte. After that, it prepares the arguments of the next call to mprotect, that will change the protection, enabling write permission, on the the address 0x5657D000. Looking up the stack:

Having ESP pointing at 0xFFC344F0, the calling convention dictate that the arguments of a function must be pushed into the stack in reverse order. The mprotect call is defined as: int mprotect(void *addr, size_t len, int prot); with

prot = 6
len = 0xE78
*addr = 0x5657D000

In other words: change the permission of the memory area of 3704 bytes starting from address 0x5657D000, granting the writability via the PROT_WRITE constant. More info of this syscall here. But what’s inside this address? We’re inside the ELF header, basically the start of the entire binary.

Going further, we can see the moving into the stack of some bytes, a call to calloc to allocate an array of 320+1 null bytes into the heap and the setup of a loop counter variable, placed at [ebp+var_C], with the same size of the array. We’re setting up a loop that will scan, byte per byte, a specific area of the binary located at 0x5657D89B - that is a fixed value - and xor every byte, first with 0x90 and after with those bytes that were moved into the stack. For better understand this loop, I suggest to read the answer I got here. When this decryption loop ends, we have the decrypted code inside the heap, into the allocated array. Code can now be replaced with the decrypted one via the memcpy syscall. Finally, write permission can now be disabled and the routine can finish and return.

Second round of conclusions

Many days and months passed staring at me failing so hard into the understanding of this routine. But the feeling was still the same: I wanted to have that "[+] Good job! ;)" string and I’ve always had the Try Harder approach. Understanding this loop wasn’t easy, not even close. I asked for help and, luckily, I got plenty. This is what I got: don’t be afraid to ask for help but don’t blindly ask for a solution. Work on that, demonstrate that you studied that thing and failed; People, eventually, will get that and will help you.

Towards the victory

After executing the decryption function we land into the code below. First it verifies that the user submitted a password of the length of exactly 0x27, that is a fixed value coming from this instruction: mov eax, (dword_56561058 - 56561000h) [ebx].

Only if the password is exactly 39 characters, it moves on into the DecryptedFunction, passing the user’s password as the argument. The previous experience helped a lot to understand this function and the pseudo code generated by IDA is pretty nice.

int __cdecl DecryptedFunction(int UserSubmittedPassword)
{
int result; // eax
char v2; // [esp+0h] [ebp-38h]
char v3; // [esp+1h] [ebp-37h]
char v4; // [esp+2h] [ebp-36h]
char v5; // [esp+3h] [ebp-35h]
char v6; // [esp+4h] [ebp-34h]
char v7; // [esp+5h] [ebp-33h]
char v8; // [esp+6h] [ebp-32h]
char v9; // [esp+7h] [ebp-31h]
char v10; // [esp+8h] [ebp-30h]
char v11; // [esp+9h] [ebp-2Fh]
char v12; // [esp+Ah] [ebp-2Eh]
char v13; // [esp+Bh] [ebp-2Dh]
char v14; // [esp+Ch] [ebp-2Ch]
char v15; // [esp+Dh] [ebp-2Bh]
char v16; // [esp+Eh] [ebp-2Ah]
char v17; // [esp+Fh] [ebp-29h]
char v18; // [esp+10h] [ebp-28h]
char v19; // [esp+11h] [ebp-27h]
char v20; // [esp+12h] [ebp-26h]
char v21; // [esp+13h] [ebp-25h]
char v22; // [esp+14h] [ebp-24h]
char v23; // [esp+15h] [ebp-23h]
char v24; // [esp+16h] [ebp-22h]
char v25; // [esp+17h] [ebp-21h]
char v26; // [esp+18h] [ebp-20h]
char v27; // [esp+19h] [ebp-1Fh]
char v28; // [esp+1Ah] [ebp-1Eh]
char v29; // [esp+1Bh] [ebp-1Dh]
char v30; // [esp+1Ch] [ebp-1Ch]
char v31; // [esp+1Dh] [ebp-1Bh]
char v32; // [esp+1Eh] [ebp-1Ah]
char v33; // [esp+1Fh] [ebp-19h]
char v34; // [esp+20h] [ebp-18h]
char v35; // [esp+21h] [ebp-17h]
char v36; // [esp+22h] [ebp-16h]
char v37; // [esp+23h] [ebp-15h]
char v38; // [esp+24h] [ebp-14h]
char v39; // [esp+25h] [ebp-13h]
char v40; // [esp+26h] [ebp-12h]
unsigned __int8 v41; // [esp+27h] [ebp-11h]
int counter; // [esp+28h] [ebp-10h]
int v43; // [esp+2Ch] [ebp-Ch]
v43 = 0;
v2 = 0x93u;
v3 = 0x5E;
v4 = 0xB0u;
v5 = 0xB8u;
v6 = 0xC5u;
v7 = 0xD7u;
v8 = 0xACu;
v9 = 0x23;
v10 = 0xC3u;
v11 = 0xF0u;
v12 = 6;
v13 = 0x72;
v14 = 0xF4u;
v15 = 0x74;
v16 = 0x93u;
v17 = 0x52;
v18 = 0x74;
v19 = 0x72;
v20 = 0x30;
v21 = 0xEDu;
v22 = 0x8Bu;
v23 = 0x3D;
v24 = 4;
v25 = 0x58;
v26 = 0xD8u;
v27 = 0xE5u;
v28 = 0xA2u;
v29 = 0xCFu;
v30 = 0x8Au;
v31 = 0xEDu;
v32 = 0x8Bu;
v33 = 0x5C;
v34 = 0x5E;
v35 = 0x61;
v36 = 0xDCu;
v37 = 0x31;
v38 = 0xCFu;
v39 = 0x91u;
v40 = 0x82u;
for ( counter = 0; counter < PasswordLength; ++counter )
{
v41 = *((_BYTE *)AntiAnalysisFunction + counter + 0xC7);
if ( (v41 ^ *(_BYTE *)(counter + UserSubmittedPassword)) != *(&v2 + counter) )
{
v43 = 1;
break;
}
}
if ( v43 )
result = puts("[-] Nope!");
else
result = puts("[+] Good job! ;)");
return result;
}

It scans the user’s password, character by character, xoring it with a string retrieved from the binary itself. If every character matches it goes on and continue in the loop, otherwise it breaks. In the end, if everything is correct, it prints the beloved success string. How can we retrieve the correct flag? If we dump the 39 bytes from the binary, from the correct addresses, and xor them with the hardcoded string, we can take advantage of the xor bidirectional nature. Although you can find more details here, we’re basically telling this:

A xor B = C
A xor C = B
B xor C = A

My first approach was to bruteforce the routine: if the string submitted is, eventually, \x41\x41\x41\x41\x41\x41\x41... we can step by step into the code and go into the final cmp instruction, retrieve the byte that it compares to and change the ZERO flag to force the loop to continue and not to stop. Otherwise we can dump the contents of the memory and xor with the hardcoded string, as result we get the flag that needs to be submitted to the binary.

We know that we need to get 39 bytes from address *((_BYTE *)AntiAnalysisFunction + 0 + 0xC7) to *((_BYTE *)AntiAnalysisFunction + 0x27 + 0xC7). Or from (0x5662A9DC + 0 + 0xC7) = 0x5662AAA3 to 0x5662AACA = (0x5662A9DC + 0x27 + 0xC7). We can apply the xor operation with the known string and we’re able retrieve the flag, finally.

Hardcoded: 93 5E B0 B8 C5 D7 AC 23 C3 F0 06 72 F4 74 93 52 74 72 30 ED 8B 3D 04 58 D8 E5 A2 CF 8A ED 8B 5C 5E 61 DC 31 CF 91 82
Memory dump: E8 18 FC FF FF 83 C4 10 85 C0 74 11 C7 45 E0 01 00 00 00 83 EC 0C 6A 01 E8 90 FB FF FF 83 EC 0C 6A 05 E8 46 FB FF FF
Flag hex: 7B 46 4C 47 3A 54 68 33 46 30 72 63 33 31 73 53 74 72 30 6E 67 31 6E 59 30 75 59 30 75 6E 67 50 34 64 34 77 34 6E 7D
Flag ascii: { F L G : T h 3 F 0 r c 3 1 s S t r 0 n g 1 n Y 0 u Y 0 u n g P 4 d 4 w 4 n }

Conclusions

This was a long journey that required a lot of effort and countless sleepless nights. It was worth it? Every single minute, without any doubt. I hope this post will help you in your studies and if you spot any errors or want to help me in my journey into the reverse engineering world please leave a comment, tweet or e-mail.

As always, Try Harder.

Reverse engineering the router Technicolor TG582N

Thu, 07 Feb 2019 09:00:00 +0000

During last months, my interest in hardware hacking got an exponential growth due to the fact I had the chance to get my hands on some so-ho routers unretired from local Telcos. So what a great opportunity to open and try to crack them, without worrying about irreparable damage?

Inspecting the device

My first device was the Technicolor TG582N distributed in Italy by Fastweb.

Front side

Back side

Nothing too much interesting externally: for this purpose, common useless informations about wireless access code, serial number, mac-address, etc.

A much more interesting view is the internal one: I was able to remove the two lower screws, under the rubbers and, with a gentle lever, the upper part can be unhooked giving access to the router motherboard.

Router motherboard with the relevant ICs

Internal components analysis

A pretty standard design for this kind of device, we can clearly see the main CPU Broadcom BCM63281KFBG and its two memory ICs (Integrated Circuits): RAM and Flash memory. There’s also another Broadcom chip but its role is to manage wireless functionalities and, for now, is out of scope.

Winbond W9751G6KB-25

Spansion FL064PIF

For the volatile data, the device uses a DDR2 SDRAM module produced by Winbond with the capacity 512 Mbit (64 MByte). Obviously I’m interested in the EEPROM chip, because it’s where the non-volatile data is stored and persists across reboots and shutdowns. This device has a flash memory module produced by Spansion (now Cypress) with the capacity of 64 Mbit (8 Mbyte).

Accessing to UART console

I didn’t put too much effort in this because the nice guys of OpenWRT project did all the dirty job. Although the board perfectly matches to the devices described in that page, I noted a slight difference on the EEPROM chip. They mention three board type: DANT-1, DANT-T, and DANT-V. These boards have three types of EEPROM chip but none of them have this Spansion chip, only the DANT-V version has a Spansion chip but it’s an FL129P, a 128 Mbit flash memory. We’re definitely dealing with a slightly smaller memory chip. Anyway, UART pins are the same of other boards and we need to solder 3 pins (Tx, Rx, and GND) and short circuit R62 and R63 as noted in the above link.

Soldered UART pins

After this little soldering, we can attach a common interface based on the FTD232 and have a console access. Remember to NOT attach the VCC pin because the required power will be provided by the standard supply.

With this simple setup we can finally have access to the router console and see all the boot messages:

Welcome to minicom 2.7.1
OPTIONS: I18n
Compiled on May 3 2018, 15:20:11.
Port /dev/ttyUSB0, 17:40:25
Press CTRL-A Z for help on special keys
D%G
Decompressing Bootloader..............................
Gateway initialization sequence started.
Version BL: 1.0.5
Multicore disable; Booting Linux kernel
BOOTING THE LINUX KERNEL
Starting the kernel @ 0x801dfcd0
Extra parameters passed to Linux:
[0]: bootloader
[1]: memsize=0x3EDD000
Linux version 2.6.30 (gcc version 3.4.6) #1 Mon Mar 26 18:25:38 CST 2012
BCM63XX prom init
CPU revision is: 0002a075 (Broadcom4350)
Determined physical RAM map:
memory: 03edb000 @ 00002000 (usable)
Wasting 64 bytes for tracking 2 unused pages
Zone PFN ranges:
DMA 0x00000002 -> 0x00001000
Normal 0x00001000 -> 0x00003edd
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000002 -> 0x00003edd
On node 0 totalpages: 16091
free_area_init_node: node 0, pgdat 80238480, node_mem_map 81000040
DMA zone: 32 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 4062 pages, LIFO batch:0
Normal zone: 94 pages used for memmap
Normal zone: 11903 pages, LIFO batch:1
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 15965
Kernel command line: root=31:0 ro noinitrd memsize=0x3EDD000 console=ttyS0,115200 root=/dev/mtdblock2 rootfstype=squashfs
wait instruction: enabled
Primary instruction cache 32kB, VIPT, 4-way, linesize 16 bytes.
Primary data cache 32kB, 2-way, VIPT, cache aliases, linesize 16 bytes
NR_IRQS:128
PID hash table entries: 256 (order: 8, 1024 bytes)
console [ttyS0] enabled
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 61152k/64364k available (1882k kernel code, 3192k reserved, 331k data, 108k init, 0k highmem)
Calibrating delay loop... 318.46 BogoMIPS (lpj=159232)
Mount-cache hash table entries: 512
--Kernel Config--
SMP=0
PREEMPT=0
DEBUG_SPINLOCK=0
DEBUG_MUTEXES=0
net_namespace: 584 bytes
NET: Registered protocol family 16
registering PCI controller with io_map_base unset
registering PCI controller with io_map_base unset
bio: create slab <bio-0> at 0
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pci 0000:00:09.0: reg 10 32bit mmio: [0x10002600-0x100026ff]
pci 0000:00:0a.0: reg 10 32bit mmio: [0x10002500-0x100025ff]
pci 0000:01:00.0: PME# supported from D0 D3hot
pci 0000:01:00.0: PME# disabled
pci 0000:02:00.0: reg 10 64bit mmio: [0x000000-0x003fff]
pci 0000:02:00.0: supports D1 D2
pci 0000:01:00.0: PCI bridge, secondary bus 0000:02
pci 0000:01:00.0: IO window: disabled
pci 0000:01:00.0: MEM window: 0x10f00000-0x10ffffff
pci 0000:01:00.0: PREFETCH window: disabled
PCI: Enabling device 0000:01:00.0 (0000 -> 0002)
PCI: Setting latency timer of device 0000:01:00.0 to 64
BLOG Rule v1.0 Initialized
Broadcom IQoS v0.1 Mar 26 2012 18:23:40 initialized
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
NET: Registered protocol family 1
squashfs: version 4.0 (2009/01/31) Phillip Lougher
squashfs: version 4.0 with LZMA457 ported by BRCM
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
msgmni has been set to 119
io scheduler noop registered (default)
pcieport-driver 0000:01:00.0: device [14e4:6328] has invalid IRQ; check vendor BIOS
PCI: Setting latency timer of device 0000:01:00.0 to 64
Gateway flash mapping
flash mapping initialized
Creating 4 MTD partitions on "thomson-spi":
0x000000040000-0x0000000b0000 : "userfs"
0x000000020000-0x000000040000 : "mtdss"
0x000000180000-0x000000800000 : "rootfs"
0x0000000b0000-0x000000180000 : "kernel"
brcmboard: brcm_board_init entry
Serial: BCM63XX driver $Revision: 3.00 $
ttyS0 at MMIO 0xb0000100 (irq = 36) is a BCM63XX
ttyS1 at MMIO 0xb0000100 (irq = 36) is a BCM63XX
ttyS2 at MMIO 0xb0000120 (irq = 47) is a BCM63XX
TCP cubic registered
NET: Registered protocol family 17
NET: Registered protocol family 15
VFS: Mounted root (squashfs filesystem) readonly on device 31:2.
Freeing unused kernel memory: 108k freed
init started: BusyBox v1.00 (2012.03.26-10:27+0000) multi-call binary
init started: BusyBox v1.00 (2012.03.26-10:27+0000) multi-call binary
Starting pid 116, console /dev/ttyS0: '/etc/init.d/rcS'
Initializing random number generator
Using /lib/modules/kserport.ko
kserport: module license 'unspecified' taints kernel.
Disabling lock debugging due to kernel taint
Using /nmon/nmon.ko
loading geniodb kernel modules...
Using /lib/modules/geniodb.ko
geniodb driver: Loading ...
geniodb driver: Loading finished with SUCCESS
Button char device has been created and initialized.
[BCM ADSL] BcmAdsl_SetOverlayMode = 85 new=0
tmm_skb_desc.queuesize = 300
queue: 0xc09aa744
queue: 0xc09aa744, rp: 0xc09aa744, wp: 0xc09aa744
[BCM ADSL] ------ dslFileLoadImage : OverlayMode = 0 fname=ZXD3AA
pci 0000:00:09.0: firmware: requesting ZXD3AA
pSdramPHY=0xA3FFFFF8, 0x5CF9A 0xDEADBEEF
[BCM ADSL] Firmware load : 548088 548088 LMEM=(0xB0D80000, 11380) SDRAM=(0xA3F00000, 536700)
pci 0000:00:09.0: firmware: requesting phy
*** PhySdramSize got adjusted: 0x8307C => 0x98A20 ***
AdslCoreSharedMemInit: shareMemAvailable=423360
AdslCoreHwReset: pLocSbSta=c09a2fd0 bkupThreshold=1600
AdslCoreHwReset: AdslOemDataAddr = 0xA3F78090
[DSL driver] !-!-!-!-!-!-! ***** AFE ID = 0x1040a200
ADSL PHY version is A2pDT002a.d23k
b6w_init
FOUND WL DEVICE 0, bus=2, device=0, func=0, vendorid=14E4, deviceid=A8DC, regaddr=10F00000, irq=31
wl:srom not detected, using main memory mapped srom info(wombo board)
veth0 (): not using net_device_ops yet
NET: Registered protocol family 3
NET: Registered protocol family 9
NET: Registered protocol family 6
NET: Registered protocol family 4
NET: Registered protocol family 5
NET: Registered protocol family 18
NET: Registered protocol family 25
Device ipsec not present.
voice will be loaded
Device endpoint not present.
Device ikanos not present.
Starting pid 338, console /dev/ttyS0: '/etc/init.d/rc'
Switching to RUNLEVEL 1 ...
Disabling hotplug helper
route: SIOC[ADD|DEL]RT: File exists
linux application start ...
wait for linux_appl to initialize (1)
wait for linux_appl to initialize (2)
************* ERROR RECORD *************
000000:00:00.000000
Application NMON started after POWERON.
****************** END *****************
wait for linux_appl to initialize (3)
appl_init: BUILD VERIFIED!
wait for linux_appl to initialize (4)
[SS EMUL] ERR: opening config file /active/ss.conf failed
End of initialisation
wait for linux_appl to initialize (5)
start fseventd ...
fseventd is started.
start storagepl ...
storagepl is started
start vfspl ...
vfspl is started
MVFS plugin started
cifs plug-in: initializing ...
cifs plug-in is started
upnpavpl start ...
/usr/bin/fusermount
Loading fuse modulefuse init (API version 7.11)
.
Mounting fuse control filesystem.
linuxappl: start loading after [ 4459ms ]
WARNING: Unknown Parameter Type ifmfilter
WARNING: Unknown Parameter Type ifmfilter
S67stopload: wait until configuration load reaches phase 9...
S67stopload: wait until configuration load reaches phase 9 (now -1, 1s)
adsl: adsl_open entry
ADSL Line state is: DOWN
[adsl] trace = 5 0
S67stopload: wait until configuration load reaches phase 9 (now -1, 2s)
The OBC bridge interface cannot be removed from this VLAN, because OBC is defined as untagged.
S67stopload: wait until configuration load reaches phase 9 (now 3, 3s)
S67stopload: wait until configuration load reaches phase 9 (now 3, 4s)
S67stopload: wait until configuration load reaches phase 9 (now 3, 5s)
S67stopload: wait until configuration load reaches phase 9 (now 3, 6s)
S67stopload: wait until configuration load reaches phase 9 (now 3, 7s)
DyingGasp RIP BIT is set!
[ERROR : [DIAG 1004] -1 ]
ADSL configuration:
adslmultimode = adsl2plus
syslog = disabled
S67stopload: wait until configuration load reaches phase 9 (now 3, 8s)
S67stopload: wait until configuration load reaches phase 9 (now 3, 9s)
The OBC bridge interface cannot be removed from this VLAN, because OBC is defined as untagged.
Option not allowed => HostNotLocalDomain
Unsupported URL. The url must include http:// or https://.
Failed to add host 9c:97:26:0c:0c:e9
S67stopload: wait until configuration load reaches phase 9 (now 6, 10s)
S67stopload: wait until configuration load reaches phase 9 (now 6, 11s)
S67stopload: wait until configuration load reaches phase 9 (now 6, 12s)
S67stopload: configuration load reached phase 9...
Intel MicroStack 1.0 - Digital Media Server (DLNA 1.5)(pid = 835),
loc_generate_uuid:25e05aa9-8206-5b77-9aad-d5547194a957
nlplugd start ...
Initializing.
Starting netlink plugin
Daemonize netlink plugin
udhcpcd start ...
monitoripd start ...
anti_spoofd start ...
anti_spoofd : process exit !
start mud ...
Using /lib/modules/2.6.30/kernel/drivers/usb/host/ehci-hcd.ko
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
PCI: Enabling device 0000:00:0a.0 (0000 -> 0002)
PCI: Setting latency timer of device 0000:00:0a.0 to 64
ehci_hcd 0000:00:0a.0: EHCI Host Controller
ehci_hcd 0000:00:0a.0: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:0a.0: Enabling legacy PCI PM
ehci_hcd 0000:00:0a.0: irq 50, io mem 0x10002500
ehci_hcd 0000:00:0a.0: USB f.f started, EHCI 1.00
monitoripd start ...
anti_spoofd start ...
anti_spoofd : process exit !
start mud ...
Using /lib/modules/2.6.30/kernel/drivers/usb/host/ehci-hcd.ko
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
PCI: Enabling device 0000:00:0a.0 (0000 -> 0002)
PCI: Setting latency timer of device 0000:00:0a.0 to 64
ehci_hcd 0000:00:0a.0: EHCI Host Controller
ehci_hcd 0000:00:0a.0: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:0a.0: Enabling legacy PCI PM
ehci_hcd 0000:00:0a.0: irq 50, io mem 0x10002500
ehci_hcd 0000:00:0a.0: USB f.f started, EHCI 1.00
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
Using /lib/modules/2.6.30/kernel/drivers/usb/host/ohci-hcd.ko
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
PCI: Enabling device 0000:00:09.0 (0000 -> 0002)
PCI: Setting latency timer of device 0000:00:09.0 to 64
ohci_hcd 0000:00:09.0: OHCI Host Controller
ohci_hcd 0000:00:09.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:09.0: irq 49, io mem 0x10002600
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
Using /lib/modules/2.6.30/kernel/drivers/usb/class/usblp.ko
usbcore: registered new interface driver usblp
Using /lib/modules/2.6.30/kernel/drivers/usb/serial/usbserial.ko
usbcore: registered new interface driver usbserial
USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial Driver core
Using /lib/modules/2.6.30/kernel/drivers/scsi/scsi_mod.ko
SCSI subsystem initialized
Using /lib/modules/2.6.30/kernel/drivers/scsi/sd_mod.ko
Driver 'sd' needs updating - please use bus_type methods
Using /lib/modules/2.6.30/kernel/drivers/usb/storage/usb-storage.ko
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
Using /lib/modules/2.6.30/kernel/fs/fat/fat.ko
Using /lib/modules/2.6.30/kernel/fs/fat/vfat.ko
Using /lib/modules/2.6.30/kernel/fs/nls/nls_cp437.ko
Using /lib/modules/2.6.30/kernel/fs/nls/nls_iso8859-1.ko
Using /lib/modules/2.6.30/kernel/fs/nls/nls_cp850.ko
Name: /etc/usbmgr/usbmgr.conf
Starting power manager...
Username :

After the boot, there’s the good old login screen but without a valid username/password there’s not much we can do. One way to proceed is to investigate the filesystem without any sort of access control. Filesystem can be obtained by dumping it directly from the flash memory.

Dumping the flash

Reading the flash memory contents is not something overcomplicated but requires a bit of understanding of how integrated circuits work and how you can obtain the raw contents of the chip using the same interfaces and protocols used by the main CPU during the normal operation of the device.

For this purpose we’re targeting the flash memory chip that was inspected above: a Spansion chip FL064pif with its datasheet is available on the manufacture site.

In order to read - and eventually write - its contents, we need to interface with the chip itself, using its pins and using a serial protocol, named SPI. The useful pins are Vcc, CS, SO, SI, SCK and GNDand their description is available on the datasheet.

Dumping the chip can be done with BusPirate and Flashrom. In order to avoid any desoldering, we’ll use a Pomona SOIC clip model 5252. In this case, power we’ll be supplied by the BusPirate itself and the board must be switched off. This is because we don’t want any interaction from the main CPU that will interfere with the memory chip while we’re dumping its contents.

In-system programming

In this case we were lucky, because powering up the chip itself didn’t wake up any other component of the board, like the main CPU. This can happens and depends on how the board is designed and how the components are connected and can vary from board to board. If there’s such interference you’ll end up with a corrupted dump and flashrom won’t alert you in that case. This is why it’s a good practice to verify the correctness of the dumping process.

Dumping the flash

Verifying the dump

We now have the entire content of the flash memory. We can read, eventually, bootloader, Linux kernel and, more interesting, the root filesystem. Basically we have the entire software stack the manufacturer has deployed on the device.

Firmware extraction

For the extraction we will use the Binwalk utility. It will read the dump and try to recognize and extract any known file format.

root@kali:~/Projects/tg582n# binwalk dump.bin
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
45066 0xB00A LZMA compressed data, properties: 0x5D, dictionary size: 2097152 bytes, uncompressed size: 250804 bytes
132350 0x204FE PEM certificate
133927 0x20B27 PEM certificate
135518 0x2115E PEM certificate
262144 0x40000 JFFS2 filesystem, big endian
262496 0x40160 Zlib compressed data, compressed
262760 0x40268 JFFS2 filesystem, big endian
267824 0x41630 Zlib compressed data, compressed
269016 0x41AD8 Zlib compressed data, compressed
269332 0x41C14 Zlib compressed data, compressed
269648 0x41D50 Zlib compressed data, compressed
269844 0x41E14 JFFS2 filesystem, big endian
269960 0x41E88 Zlib compressed data, compressed
270176 0x41F60 Zlib compressed data, compressed
270444 0x4206C Zlib compressed data, compressed
270892 0x4222C Zlib compressed data, compressed
271452 0x4245C Zlib compressed data, compressed
271552 0x424C0 JFFS2 filesystem, big endian
272436 0x42834 Zlib compressed data, compressed
273012 0x42A74 Zlib compressed data, compressed
273548 0x42C8C Zlib compressed data, compressed
273888 0x42DE0 Zlib compressed data, compressed
274424 0x42FF8 Zlib compressed data, compressed
274764 0x4314C Zlib compressed data, compressed
275300 0x43364 Zlib compressed data, compressed
275640 0x434B8 Zlib compressed data, compressed
276136 0x436A8 Zlib compressed data, compressed
276476 0x437FC Zlib compressed data, compressed
277052 0x43A3C Zlib compressed data, compressed
277268 0x43B14 Zlib compressed data, compressed
277536 0x43C20 Zlib compressed data, compressed
278608 0x44050 Zlib compressed data, compressed
279672 0x44478 Zlib compressed data, compressed
280084 0x44614 JFFS2 filesystem, big endian
280200 0x44688 Zlib compressed data, compressed
280684 0x4486C JFFS2 filesystem, big endian
280872 0x44928 Zlib compressed data, compressed
281124 0x44A24 Zlib compressed data, compressed
281240 0x44A98 Zlib compressed data, compressed
281336 0x44AF8 Zlib compressed data, compressed
281432 0x44B58 Zlib compressed data, compressed
281460 0x44B74 JFFS2 filesystem, big endian
281676 0x44C4C Zlib compressed data, compressed
281768 0x44CA8 Zlib compressed data, compressed
281864 0x44D08 Zlib compressed data, compressed
281960 0x44D68 Zlib compressed data, compressed
282056 0x44DC8 Zlib compressed data, compressed
282176 0x44E40 Zlib compressed data, compressed
282300 0x44EBC Zlib compressed data, compressed
282668 0x4502C JFFS2 filesystem, big endian
282808 0x450B8 Zlib compressed data, compressed
282932 0x45134 Zlib compressed data, compressed
283152 0x45210 JFFS2 filesystem, big endian
283772 0x4547C Zlib compressed data, compressed
284068 0x455A4 Zlib compressed data, compressed
284624 0x457D0 JFFS2 filesystem, big endian
285552 0x45B70 Zlib compressed data, compressed
286000 0x45D30 JFFS2 filesystem, big endian
286764 0x4602C Zlib compressed data, compressed
287224 0x461F8 JFFS2 filesystem, big endian
288020 0x46514 Zlib compressed data, compressed
288456 0x466C8 JFFS2 filesystem, big endian
289736 0x46BC8 Zlib compressed data, compressed
290484 0x46EB4 JFFS2 filesystem, big endian
291892 0x47434 Zlib compressed data, compressed
292352 0x47600 JFFS2 filesystem, big endian
293416 0x47A28 Zlib compressed data, compressed
294336 0x47DC0 JFFS2 filesystem, big endian
295984 0x48430 Zlib compressed data, compressed
296564 0x48674 JFFS2 filesystem, big endian
297632 0x48AA0 Zlib compressed data, compressed
298040 0x48C38 JFFS2 filesystem, big endian
299428 0x491A4 Zlib compressed data, compressed
299856 0x49350 JFFS2 filesystem, big endian
300880 0x49750 Zlib compressed data, compressed
301620 0x49A34 JFFS2 filesystem, big endian
303128 0x4A018 Zlib compressed data, compressed
303684 0x4A244 JFFS2 filesystem, big endian
304808 0x4A6A8 Zlib compressed data, compressed
305152 0x4A800 JFFS2 filesystem, big endian
305828 0x4AAA4 Zlib compressed data, compressed
306220 0x4AC2C JFFS2 filesystem, big endian
306940 0x4AEFC Zlib compressed data, compressed
307904 0x4B2C0 JFFS2 filesystem, big endian
309392 0x4B890 Zlib compressed data, compressed
309908 0x4BA94 JFFS2 filesystem, big endian
313324 0x4C7EC Zlib compressed data, compressed
313900 0x4CA2C Zlib compressed data, compressed
314436 0x4CC44 Zlib compressed data, compressed
314776 0x4CD98 Zlib compressed data, compressed
315312 0x4CFB0 Zlib compressed data, compressed
315652 0x4D104 Zlib compressed data, compressed
316188 0x4D31C Zlib compressed data, compressed
316528 0x4D470 Zlib compressed data, compressed
317024 0x4D660 Zlib compressed data, compressed
317364 0x4D7B4 Zlib compressed data, compressed
317940 0x4D9F4 Zlib compressed data, compressed
318236 0x4DB1C Zlib compressed data, compressed
319308 0x4DF4C Zlib compressed data, compressed
320616 0x4E468 Zlib compressed data, compressed
323744 0x4F0A0 JFFS2 filesystem, big endian
323884 0x4F12C Zlib compressed data, compressed
323944 0x4F168 JFFS2 filesystem, big endian
591524 0x906A4 Zlib compressed data, compressed
592100 0x908E4 Zlib compressed data, compressed
592808 0x90BA8 Zlib compressed data, compressed
593516 0x90E6C Zlib compressed data, compressed
594224 0x91130 Zlib compressed data, compressed
594892 0x913CC Zlib compressed data, compressed
595468 0x9160C Zlib compressed data, compressed
595764 0x91734 Zlib compressed data, compressed
596836 0x91B64 Zlib compressed data, compressed
598144 0x92080 Zlib compressed data, compressed
599460 0x925A4 Zlib compressed data, compressed
600036 0x927E4 Zlib compressed data, compressed
600744 0x92AA8 Zlib compressed data, compressed
601452 0x92D6C Zlib compressed data, compressed
602160 0x93030 Zlib compressed data, compressed
602828 0x932CC Zlib compressed data, compressed
603404 0x9350C Zlib compressed data, compressed
603700 0x93634 Zlib compressed data, compressed
604772 0x93A64 Zlib compressed data, compressed
606080 0x93F80 Zlib compressed data, compressed
606568 0x94168 JFFS2 filesystem, big endian
607900 0x9469C Zlib compressed data, compressed
608608 0x94960 Zlib compressed data, compressed
609316 0x94C24 Zlib compressed data, compressed
610024 0x94EE8 Zlib compressed data, compressed
610692 0x95184 Zlib compressed data, compressed
611200 0x95380 JFFS2 filesystem, big endian
611564 0x954EC Zlib compressed data, compressed
612568 0x958D8 JFFS2 filesystem, big endian
613128 0x95B08 JFFS2 filesystem, big endian
720922 0xB001A LZMA compressed data, properties: 0x5D, dictionary size: 2097152 bytes, uncompressed size: 2394632 bytes
1572864 0x180000 Squashfs filesystem, little endian, non-standard signature, version 4.0, compression:gzip, size: 6626892 bytes, 1298 inodes, blocksize: 131072 bytes, created: 2012-10-15 13:38:44

Honestly, this is the first time I had so much results from binwalk. The first thing I noted is the SquashFS signature. From the boot log messages, we know that the root filesystem is in that format:

Kernel command line: root=31:0 ro noinitrd memsize=0x3EDD000 console=ttyS0,115200 root=/dev/mtdblock2 rootfstype=squashfs

So we’ll start to dig in that directory first:

root@kali:~/Projects/tg582n/_dump.bin.extracted/squashfs-root# ll
total 68K
drwxrwxr-x 15 root root 4,0K ott 15 2012 .
drwxr-xr-x 34 root root 12K gen 20 12:06 ..
drwxrwxr-x 3 root root 4,0K ott 15 2012 archive
drwxrwxrwx 2 root root 4,0K mar 26 2012 bin
drwxrwxrwx 6 root root 4,0K mar 26 2012 dev
lrwxrwxrwx 1 root root 6 mar 26 2012 dl -> /rw/dl
drwxrwxr-x 10 root root 4,0K mar 26 2012 etc
drwxrwxrwx 3 root root 4,0K mar 26 2012 lib
drwxrwxrwx 2 root root 4,0K mar 26 2012 nmon
drwxrwxrwx 2 root root 4,0K mar 26 2012 proc
drwxrwxrwx 3 root root 4,0K mar 26 2012 rw
drwxrwxrwx 2 root root 4,0K mar 26 2012 sbin
drwxrwxrwx 2 root root 4,0K mar 26 2012 sys
lrwxrwxrwx 1 root root 8 mar 26 2012 tmp -> /var/tmp
drwxrwxrwx 2 root root 4,0K mar 26 2012 userfs
drwxrwxrwx 5 root root 4,0K mar 26 2012 usr
drwxrwxrwx 2 root root 4,0K mar 26 2012 var
root@kali:~/Projects/tg582n/_dump.bin.extracted/squashfs-root#

We’re interested into passwd file but looking up in the /etc directory, we find that, like most embedded device, that file is autogenerated and what we see is only a placeholder.

root@kali:~/Projects/tg582n/_dump.bin.extracted/squashfs-root/etc# ll
total 100K
drwxrwxr-x 10 root root 4,0K mar 26 2012 .
drwxrwxr-x 15 root root 4,0K ott 15 2012 ..
-rw-r--r-- 1 root root 513 mar 26 2012 advancedservices.conf
-r--r--r-- 1 root root 377 mar 26 2012 autoconf.conf
-r--r--r-- 1 root root 133 mar 26 2012 autoip.conf
drwxrwxrwx 2 root root 4,0K mar 26 2012 config
-rw-rw-rw- 1 root root 345 mar 26 2012 fileprofiler.conf
-r--r--r-- 1 root root 73 mar 26 2012 fstab
-r--r--r-- 1 root root 17 mar 26 2012 fuse.conf
lrwxrwxrwx 1 root root 15 mar 26 2012 group -> ../rw/etc/group
lrwxrwxrwx 1 root root 17 mar 26 2012 gshadow -> ../rw/etc/gshadow
-r--r--r-- 1 root root 26 mar 26 2012 host.conf
drwxrwxr-x 2 root root 4,0K mar 26 2012 init.d
-r--r--r-- 1 root root 513 mar 26 2012 inittab
-r--r--r-- 1 root root 17K mar 26 2012 mime.types
lrwxrwxrwx 1 root root 14 mar 26 2012 mtab -> ../proc/mounts
-r--r--r-- 1 root root 465 mar 26 2012 nsswitch.conf
lrwxrwxrwx 1 root root 16 mar 26 2012 passwd -> ../rw/etc/passwd
drwxr-xr-x 2 root root 4,0K mar 26 2012 rc0.d
drwxr-xr-x 2 root root 4,0K mar 26 2012 rc1.d
drwxr-xr-x 2 root root 4,0K mar 26 2012 rc2.d
drwxr-xr-x 2 root root 4,0K mar 26 2012 rc3.d
lrwxrwxrwx 1 root root 21 mar 26 2012 resolv.conf -> ../rw/etc/resolv.conf
lrwxrwxrwx 1 root root 16 mar 26 2012 shadow -> ../rw/etc/shadow
drwxrwxr-x 2 root root 4,0K mar 26 2012 udhcpc
drwxrwxrwx 2 root root 4,0K mar 26 2012 usbmgr
-rw-rw-rw- 1 root root 8 mar 26 2012 version
root@kali:~/Projects/tg582n/_dump.bin.extracted/squashfs-root/etc#


`passwd` file is a link to another file in the `/rw` directory that, right now, is empty. How that file is generated during every boot? What script is in charge of managing it? We need to find the answers...
## Hunting for the system users
Poking around in `/etc` directory can be useful because, in the end, this is a standard Linux based system and something in that directory must exist that will reveal us what are the allowed users to the system.

root@kali:~/Projects/tg582n/_dump.bin.extracted/squashfs-root/etc# tree . ├── advancedservices.conf ├── autoconf.conf ├── autoip.conf ├── config │ ├── secrets.tdb -> /rw/etc/secrets.tdb │ ├── smb.conf -> /rw/etc/smb.conf │ └── smbpasswd -> /rw/etc/smbpasswd ├── fileprofiler.conf ├── fstab ├── fuse.conf ├── group -> ../rw/etc/group ├── gshadow -> ../rw/etc/gshadow ├── host.conf ├── init.d │ ├── anti_spoofd │ ├── autoipd │ ├── checkd │ ├── cifs │ ├── clinkd │ ├── cryptomount │ ├── dropbear │ ├── fseventd │ ├── fuse │ ├── initrandom │ ├── jffs2contentcheck │ ├── ledstatus │ ├── linuxappl │ ├── longops │ ├── mbusd_util │ ├── mocad │ ├── monitoripd │ ├── mud │ ├── mvfs │ ├── mvfspl │ ├── network │ ├── nlplugd │ ├── no_hotplug_helper │ ├── powermgr │ ├── print_server │ ├── pureftp │ ├── rc │ ├── rcS │ ├── rcS.mountfs │ ├── rcS.ro │ ├── rssplugin │ ├── samba │ ├── stopload │ ├── storagepl │ ├── todd │ ├── udhcpcd │ ├── upnpavpl │ ├── usb-host │ ├── usb_storage │ └── vfspl ├── inittab ├── mime.types ├── mtab -> ../proc/mounts ├── nsswitch.conf ├── passwd -> ../rw/etc/passwd ├── rc0.d ├── rc1.d │ ├── K01mvfs -> ../init.d/mvfs │ ├── S01jffs2contentcheck -> ../init.d/jffs2contentcheck │ ├── S10no_hotplug_helper -> ../init.d/no_hotplug_helper │ ├── S20network -> ../init.d/network │ ├── S21vega -> ../init.d/vega │ ├── S21wps -> ../init.d/wps │ ├── S22linuxappl -> ../init.d/linuxappl │ ├── S41fseventd -> ../init.d/fseventd │ ├── S45storagepl -> ../init.d/storagepl │ ├── S45vfspl -> /etc/init.d/vfspl │ ├── S46mvfspl -> ../init.d/mvfspl │ ├── S47checkd -> ../init.d/checkd │ ├── S47cifs -> ../init.d/cifs │ ├── S48todd -> ../init.d/todd │ ├── S48upnpavpl -> ../init.d/upnpavpl │ ├── S49rssplugin -> ../init.d/rssplugin │ ├── S55fuse -> ../init.d/fuse │ ├── S56mvfs -> ../init.d/mvfs │ ├── S67stopload -> ../init.d/stopload │ ├── S68su_intf -> ../init.d/su_intf │ ├── S69la_intf -> ../init.d/la_intf │ ├── S71nlplugd -> ../init.d/nlplugd │ ├── S72udhcpcd -> ../init.d/udhcpcd │ ├── S73monitoripd -> ../init.d/monitoripd │ ├── S74anti_spoofd -> ../init.d/anti_spoofd │ ├── S80dropbear -> ../init.d/dropbear │ ├── S97mud -> ../init.d/mud │ ├── S97usb-host -> ../init.d/usb-host │ └── S99powermgr -> ../init.d/powermgr ├── rc2.d ├── rc3.d │ ├── S01jffs2contentcheck -> ../init.d/jffs2contentcheck │ ├── S10no_hotplug_helper -> ../init.d/no_hotplug_helper │ ├── S20network -> ../init.d/network │ ├── S21vega -> ../init.d/vega │ ├── S22linuxappl -> ../init.d/linuxappl │ ├── S47checkd -> ../init.d/checkd │ ├── S67stopload -> ../init.d/stopload │ ├── S71nlplugd -> ../init.d/nlplugd │ ├── S72udhcpcd -> ../init.d/udhcpcd │ ├── S73monitoripd -> ../init.d/monitoripd │ └── S74anti_spoofd -> ../init.d/anti_spoofd ├── resolv.conf -> ../rw/etc/resolv.conf ├── shadow -> ../rw/etc/shadow ├── udhcpc │ └── udhcpc.script ├── usbmgr │ ├── class -> /var/usbmgr/class │ ├── dextension │ ├── host -> /var/usbmgr/host │ ├── preload.conf │ ├── storage │ ├── umts_custom │ ├── update_usbmgrconf │ ├── usbledctrl │ ├── usbmgr.conf -> /var/tmp/usbmgr.conf │ ├── usbmgr.conf.ro │ └── vendor -> /var/usbmgr/vendor └── version


For what it seems, interesting files in `/etc` directory are symlinks to the relative ones in `/rw` and, for me, `rw` has something to do with `Read` and `Write` operations. Let's search some evidence of this path in configuration files:

root@kali:~/Projects/tg582n/_dump.bin.extracted/squashfs-root/etc# grep -ir rw init.d/clinkd:CLINKCONF_DEST=/rw/etc/ init.d/clinkd: #CPE_P00075123:CJ:Change clink.conf to a rw location init.d/usb_storage: # eb 3c 90, we’re definitely dealing with a FAT boot sector. Otherwise, we init.d/usb_storage: SMBD_STATUS=0 # 0 means that cifs service is stopped (otherwise it is running) init.d/jffs2contentcheck:# push down of dl partition content into /rw/dl init.d/jffs2contentcheck: # New layout: (USERFS mounted on /rw) init.d/jffs2contentcheck: # /dl –> /rw/dl init.d/jffs2contentcheck: if [ “cat /proc/mounts | grep /dev/mtdblock0 | grep /rw” ]; then init.d/jffs2contentcheck: [ -d /rw/etc ] || mkdir -m 775 /rw/etc init.d/jffs2contentcheck: if [ ! -d /rw/dl ]; then init.d/jffs2contentcheck: echo " Detected old jffs2 partition layout! Converting /rw to new layout" init.d/jffs2contentcheck: mkdir -m 775 /rw/dl init.d/jffs2contentcheck: for file in /rw/*; do init.d/jffs2contentcheck: ([ “${file}” = “/rw/dl” ] || [ “${file}” = “/rw/etc” ]) && continue init.d/jffs2contentcheck: mv ${file} /rw/dl/ init.d/jffs2contentcheck: # /rw –> /userfs/config-bank-X init.d/jffs2contentcheck: # /dl –> /rw/dl init.d/jffs2contentcheck: # Set /rw correctly: since /rw is on rootfs which is read-only, we init.d/jffs2contentcheck: mount -o bind $CONFDIR /rw advancedservices.conf:HDTOOLSDIR="/rw/disk" advancedservices.conf:FLASHCONFIGDIR="/rw/etc/" mime.types:application/vnd.vectorworks


We found that`clinkd`, `jffs2contentcheck` and `advancedservices.conf` have something to do with the `/rw` directory. Let's review these evidence.
- `clinkd`: in the comment section of the script: "*This is the init script for the Entropic clinkd daemon*". I wasn't able to find useful informations about this daemon.
- `advancedservices.conf`: nothing too much interesting here, only a small nudge to the fact that `/rw/etc` is the writable part of the flash.
- `jffs2contentcheck`: this is interesting, we found plenty of informations in this script. For better understand its purpose, this is the full source and, actually, it's pretty well commented.

#!/bin/sh

This script checks and converts the layout of the writable partition to its

latest version.

Changelog:

* 7.4.4 > 8.1.1:

push down of dl partition content into /rw/dl

[Steven Aerts – 2008/03/12]

. /etc/autoconf.conf

start () {

# Verify 7.4.4 to 8.1.1 userfs migration
# Old layout: (USERFS mounted on /dl)
# USERFS/user.ini
# USERFS/etc/...
# USERFS/tls/...
# New layout: (USERFS mounted on /rw)
# USERFS/etc/...
# USERFS/dl/user.ini
# USERFS/dl/tls/...
# /dl --> /rw/dl
if [ "`cat /proc/mounts | grep /dev/mtdblock0 | grep /rw`" ]; then
[ -d /rw/etc ] || mkdir -m 775 /rw/etc
if [ ! -d /rw/dl ]; then
echo " Detected old jffs2 partition layout! Converting /rw to new layout"
mkdir -m 775 /rw/dl
for file in /rw/*; do
([ "${file}" = "/rw/dl" ] || [ "${file}" = "/rw/etc" ]) && continue
mv ${file} /rw/dl/
done
fi
fi
# Migrate to dual bank layout
# New layout: (USERFS mounted on /userfs)
# USERFS/config-bank-X/etc/...
# USERFS/config-bank-X/dl/...
# /rw --> /userfs/config-bank-X
# /dl --> /rw/dl
# Determine booted bank from command line
BOOTID=$(sed -n "s/.*btab_bootid=\([0-9]\+\).*/\1/p" /proc/cmdline)
# If BOOTID is empty, set it to a certain value (single-bank case)
[ -z "$BOOTID" ] && BOOTID=999
CONFDIR="/userfs/config-bank-$BOOTID"
# Create a config directory for the booted bank if it does not yet exist
[ ! -d $CONFDIR ] && mkdir $CONFDIR
# Set /rw correctly: since /rw is on rootfs which is read-only, we
# cannot use a symlink. However, mount supports the bind option which
# essentially does the same.
mount -o bind $CONFDIR /rw
# If there are any files/directories in /userfs (config-bank-X
# directories excluding), move them to the config directory of the
# booted bank. This indicates a first boot from BLI.
for i in $(ls /userfs | grep -v "^config-bank-*" | grep -v "^common$"); do
mv /userfs/$i $CONFDIR
done
# If the config directory is still empty, copy the configuration
# from another bank to allow a 'correct' boot. This can happen when
# you upgrade an rbi with the bootloader.
# NOTE: there is no guarantee that this configuration will work, but
# it's better to have something.
if [ -z "$(ls $CONFDIR | grep -v "^version$" 2>/dev/null)" -a -x /usr/bin/copyconfig ]; then
/usr/bin/copyconfig "lastboot" $BOOTID
fi
# Set the 'lastboot' symlink to the current configuration
rm -f /userfs/config-bank-lastboot
ln -sf $CONFDIR /userfs/config-bank-lastboot
# Copy the version file from /etc to /userfs/config-bank-X
if [ -f /etc/version ]; then
cp /etc/version $CONFDIR
else
echo "Unknown" > $CONFDIR/version
fi
# Create a common userfs directory
[ ! -d /userfs/common ] && mkdir /userfs/common

}

case $1 in start) start ;; stop) ;; restart) ;; *) echo “Usage $0 [start|stop|restart]” exit 1 ;; esac


What's [JFFS2](https://en.wikipedia.org/wiki/JFFS2) filesystem?
> JFFS2 (Journaled Flash File System v2) is a file system designed for use on Flash devices such as those commonly found in embedded systems. Unlike some other file systems which may be stored on the Flash device and then copied into RAM during boot (i.e. ramdisk) JFFS2 actually resides on the Flash device and allows the user to read/write data to Flash. This is particularly useful in embedded devices that wish to save some persistent data between reboots. [[cit](http://processors.wiki.ti.com/index.php/AM335x_JFFS2_Support_Guide#)]
We finally found where the persistent informations are saved. Coming back to the binwalk analysis, I remember many signature related to JFFS2 filesystem. Let's review the evidences extracted:

root@kali:~/Projects/tg582n/_dump.bin.extracted# tree jff* jffs2-root └── fs_1 ├── common │ └── flash_image_fii ├── config-bank-999 │ ├── dl │ │ ├── persistent.cnf │ │ ├── phy.conf │ │ ├── seed.dat │ │ ├── stsZWEADQ8.CM0.upg │ │ ├── tls │ │ │ ├── cert0001.pem │ │ │ └── pkey0001.pem │ │ ├── user.ini │ │ └── xdsl.inf │ ├── etc │ │ ├── group │ │ ├── gshadow │ │ ├── passwd │ │ ├── resolv.conf │ │ ├── secrets.tdb │ │ ├── shadow │ │ ├── smb.conf │ │ └── smbpasswd │ └── version └── config-bank-lastboot -> /userfs/config-bank-999 jffs2-root-0 └── fs_1 ├── common │ └── flash_image_fii ├── config-bank-999 │ ├── dl │ │ ├── persistent.cnf │ │ ├── phy.conf │ │ ├── seed.dat │ │ ├── stsZWEADQ8.CM0.upg │ │ ├── tls │ │ │ ├── cert0001.pem │ │ │ └── pkey0001.pem │ │ ├── user.ini │ │ └── xdsl.inf │ ├── etc │ │ ├── group │ │ ├── gshadow │ │ ├── passwd │ │ ├── resolv.conf │ │ ├── secrets.tdb │ │ ├── shadow │ │ ├── smb.conf │ │ └── smbpasswd │ └── version └── config-bank-lastboot -> /userfs/config-bank-999 jffs2-root-1 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd ├── persistent.cnf ├── phy.conf ├── secrets.tdb ├── smb.conf ├── smbpasswd ├── stsZWEADQ8.CM0.upg ├── user.ini └── xdsl.inf jffs2-root-10 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd ├── persistent.cnf ├── smbpasswd └── user.ini jffs2-root-11 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd ├── persistent.cnf ├── smbpasswd └── user.ini jffs2-root-12 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd ├── persistent.cnf ├── smbpasswd └── user.ini jffs2-root-13 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd ├── persistent.cnf ├── smbpasswd └── user.ini jffs2-root-14 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd ├── persistent.cnf ├── smbpasswd └── user.ini jffs2-root-15 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd ├── persistent.cnf ├── smbpasswd └── user.ini jffs2-root-16 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd ├── persistent.cnf ├── smbpasswd └── user.ini jffs2-root-17 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd ├── persistent.cnf ├── smbpasswd └── user.ini jffs2-root-18 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd ├── persistent.cnf ├── smbpasswd └── user.ini jffs2-root-19 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd ├── persistent.cnf ├── smbpasswd └── user.ini jffs2-root-2 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd ├── persistent.cnf ├── secrets.tdb ├── smb.conf ├── smbpasswd ├── stsZWEADQ8.CM0.upg ├── user.ini └── xdsl.inf jffs2-root-20 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd ├── persistent.cnf ├── smbpasswd └── user.ini jffs2-root-21 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd ├── persistent.cnf ├── smbpasswd └── user.ini jffs2-root-22 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd ├── persistent.cnf ├── smbpasswd └── user.ini jffs2-root-23 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd ├── persistent.cnf ├── smbpasswd └── user.ini jffs2-root-24 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd └── smbpasswd jffs2-root-25 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd └── smbpasswd jffs2-root-26 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd └── smbpasswd jffs2-root-27 └── fs_1 ├── passwd └── smbpasswd jffs2-root-28 └── fs_1 ├── passwd └── smbpasswd jffs2-root-29 └── fs_1 └── smbpasswd jffs2-root-3 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd ├── persistent.cnf ├── secrets.tdb ├── smb.conf ├── smbpasswd ├── user.ini └── xdsl.inf jffs2-root-4 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd ├── persistent.cnf ├── secrets.tdb ├── smbpasswd ├── user.ini └── xdsl.inf jffs2-root-5 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd ├── persistent.cnf ├── smbpasswd ├── user.ini └── xdsl.inf jffs2-root-6 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd ├── persistent.cnf ├── smbpasswd ├── user.ini └── xdsl.inf jffs2-root-7 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd ├── persistent.cnf ├── smbpasswd ├── user.ini └── xdsl.inf jffs2-root-8 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd ├── persistent.cnf ├── smbpasswd └── user.ini jffs2-root-9 └── fs_1 ├── config-bank-lastboot -> /userfs/config-bank-999 ├── group ├── passwd ├── persistent.cnf ├── smbpasswd └── user.ini

41 directories, 210 files


Honestly I don't know why there are so much copies of same files but, definitely, we found what we were looking for: not only the `passwd` file but also certificates with private keys, user configurations, xdsl line configurations, etc.
Let's try to understand if there are any differences between files inside that directories, so we can narrow our analysis. With a basic bash scripting knowledge, we can use `md5sum` to find if files are the same. Turns out that almost every file are copies and the only variable is `user.ini`. Also, the `.upg` file appears to be the same of `smbpasswd`.

group b6645876780362adfefe6ae7aa2aa970 passwd ccfbeda0bfe6a969d9f3e95284e450be persistent.cnf 0169902625104a21be24f44df679d610 phy.conf c176b13932e5bf01930a066491877986 secrets.tdb cbe77f45cae8dad41cb9bef73ed69ed6 smb.conf 7c6ed2fab7571c3441d3af6740f9d067 smbpasswd d41d8cd98f00b204e9800998ecf8427e stsZWEADQ8.CM0.upg d41d8cd98f00b204e9800998ecf8427e user.ini 080b575f72aa410d0d2606ed9f152c18 user.ini 1b37b14685d303d192c80e5e8c3e68c7 user.ini 1d57ab52d6fa5d4d61cf6f520ac62b29 user.ini 2113deb10fd3cc6e5e5d5fc44489ee13 user.ini 2fbe85cc5305473ad68ae9b842134696 user.ini 3a4860416befea32f5a6952f75c1073e user.ini 4388cd21843a0e1dbc7ec8b9d6b0fe81 user.ini 59499065a1243c0fd0bc3aec77eb5052 user.ini 6281deec4ac9389b797afc4873b9a90a user.ini 6400c4bc913e682e32e055d262c058d4 user.ini 8165fea871781c7320bd6ef3b201c90f user.ini 8504dfd01106e4f2e2a21c6e7460964e user.ini 919573ff12d4eabf968a6dfd97a7d616 user.ini c4f70675bc732dd93fc8bb9c9219fb74 user.ini cab37a7859e4cb319aa1684f9fbee277 user.ini e9930518fb8db6670f14af642e177083 xdsl.inf 25daad3d9e60b45043a70c4ab7d3b1c6


Let's analyze them:
`group`: standard file, the same you can find on all *nix systems but with interesting groups.

SuperUser::101: TechnicalSupport::102: Administrator::103: WebsevUser::104: LAN_Admin::105: PowerUser::106: User::107: WAN_Admin::108:


`passwd`: the file we were looking for. This file will be slightly modified during boot because root access is somehow disabled but at least we found two users: `Administrator` and `tech` with relative hash.

root::0:0:Super User:/:/bin/sh nobody::1:1:nobody:/:/bin/sh mvfs::499:1::/var/mvfs:/bin/sh Administrator:ANpAYtow5vx0U:500:103:Linux User:(null):/bin/sh tech:RB6zAiLmCT4zM:501:102:Linux User:(null):/bin/sh


If you search on Google, turns out that the hash `ANpAYtow5vx0U`was generated by the command `mkpasswd` and [here](https://www.seancassidy.me/etc/passwords.txt) we can read that:
> If your password is on this list, it is not secure. It was generated by using the program '*mkpasswd'* and then not typing anything. It turns out that 'mkpasswd' doesn't make passwords, it makes password hashes. If you enter a blank password, it generates one of 4096 possible passwords.
So, Administrator user has a simple **blank** password, I didn't find anything similar with the hash of the tech user. For this user I started a simple crack session with `john`, and without any fancy cracking rig or powerful graphic video card, after an affordable cracking time (~ 2days) I managed to crack the password: it appears to be `55058391`.
![](/images/2019/01/image-22.png)
`secrets.tdb`: related to Samba services, it stores passwords in clear text. This file can be opened with the `tdbdump`:

{ key(23) = “SECRETS/SID/TECHNICOLOR” data(68) = “\01\04\00\00\00\00\00\05\00\00\00\15\89+\B5\E1jD\15P\1A\92\F03\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00” } { key(17) = “INFO/random_seed\00” data(4) = “y\04\00\00” }


`user.ini`: router clear text configuration file.
There are some other files but, for now, we have enough to start.
## Accessing the device...*in some way*
We found that the Administrator user has blank password. We can now login via console access. Tech user access is somehow disabled.

Username : Administrator Password :

 ______ Technicolor TG582n
___/_____/\
/ /\\ 8.C.M.0
_____/__ / \\
_/ /\_____/___ \ Copyright (c) 1999-2012, Technicolor
// / \ /\ \
_______//_______/ \ / _\/______
/ / \ \ / / / /\

/ / \ \ / / / / _ / / / _/ / / / / /
//// /___/ // \ \ \ \ ___________ \ \ \ \ \ / _\ \ / /\ \ \ \ _/ \ / / \ \ \ \ / _/ / \ \ _/ // \ \ / \ _____ \ /__/ \ / /\ \ // F.D.C. FW 14 // \ \ / \ \ // __/

{Administrator}=> contentsharing firewall printersharing
pwr service connection
cwmp dhcp dns
download dsd dyndns
eth atm config
debug env expr
grp hostmgr ids
igmp interface ip
ipqos label language
mbus memm mlp
mobile nat ppp
pptp ptrace script
sntp software statecheck
syslog system tls
{Administrator}=>


I spent a lot of time poking around in this weird restricted shell. I wasn't able to escape to our beloved Busybox that I know is running below. No matter what I tried, I always ended up in this jail I could not escape. It seems to manage everything from the console access.
To confirm this theory, I found this old post:
![](/images/2019/02/image.png)
And suddenly I remembered this two sneaky files laying in the `/nmon` directory.
![](/images/2019/02/image-2.png)
I'm quite sure this program is run at boot time and, basically, take the control of the entire router. This can now be confirmed in the boot log above:

linux application start … wait for linux_appl to initialize (1) wait for linux_appl to initialize (2) ************* ERROR RECORD ************* 000000:00:00.000000 Application NMON started after POWERON. ****************** END ***************** wait for linux_appl to initialize (3) appl_init: BUILD VERIFIED! wait for linux_appl to initialize (4) [SS EMUL] ERR: opening config file /active/ss.conf failed End of initialisation wait for linux_appl to initialize (5)


And this is the script that, at boot time, runs the `linux_appl.exe`

#/etc/init.d/linuxappl

#!/bin/sh

. /etc/init.d/mbusd_util

case $1 in start) TELLER=0 # linux application configuration /bin/echo “linux application start …” rm -f /var/run/linux_appl rm -f /var/run/init_finished mbusd_set_loadapp ../../nmon/linux_appl.exe /dev/nmon/nmontrace /dev/nmon/nmonerr /archive/ & while [ ! -f /var/run/linux_appl ] do TELLER=expr ${TELLER} + 1 echo “wait for linux_appl to initialize (${TELLER})” sleep 1; done ;; stop) killall -9 linux_appl ;; *)

esac


### Next steps
This ends up this phase of my journey. Honestly, I was (*am*) not prepared to impact in a so restricted and particular environment. My next steps will be to look the router from a network point of view, analyzing it while it's *up & running,* trying to find information within the services it runs and offers.
I hope you will find this post useful and if you have any hints or ideas to help me, please drop me a note.