It almost felt like the memes were for obfuscation, because they certainly had that effect on me. I'd say if this was a presentation, it would be neither informative nor professional.
A well-placed meme for humour can be good, I agree.
Could you describe the whole reversing process in a bit more detail? Binary goes in, understanding comes out, you can't explain that (well I hope someone can).
* Guy sees service running on 32764 and thinks that's quite odd
* Gets very frustrated at useless forum posts from people with no clue
* Downloads a copy of the firmware from the (horrible) modem-help.co.uk
This is where it gets interesting:
Binwalk
------
First off, a program called Binwalk is used. This is a combo of a really cool python script, the libmagic database (if you've used the file utility in 'nix you've used it) and some C to deal with some compression types.
When binwalk works, it's pure brilliance. As you can see in the screenshot on slide 12, binwalk is able to detect strings and filesystems inside the firmware.
References to Texas Instruments and Telogy Networks would be a good starting point if you wanted to google for datasheets or some more background information
I haven't ever seen a reference to Igor Pavlov in a firmware binary before but his name popping up is a good indication that you might be hitting 7zip or LZMA compressed data - http://en.wikipedia.org/wiki/Igor_Pavlov_%28programmer%29
The filesystem
-----
Squashfs is commonly used (and horribly broken) by manufacturers of modems and routers.
Luckily the author is able to extract the filesystem out by looking at the offsets printed out by binwalk - this doesn't always work!
Slide 13 is pretty typical when reversing modem firmware - someone thought they were being smart and broke the squashfs format. It looks like no one else will be able to replicate this as the source code for the modified format has been taken down (?)
It's possible the author is using the name of the folder in the last screenshot of slide 13 as a hint of what to do next, slide 14 and 15 are magic to me.
I think the author has changed the LZMA sourcecode to look for LZMA compressed data with a gzip header but this seems really strange to me
Slide 15 just shows the unsquashfs tool with what seems like sensible output (if you'd done something wrong at this point you might see huge numbers of inodes or a silly number of files and you'd have to go back to the compression and keep looking)
Now the author has a filesystem to look through - I would have used strings and grep instead of just grep at this point. He's grepping for the name of the service he found in the forum posts, I think.
I have no knowledge of MIPS assembly so I'm unable to help you there - IDA provides some flow diagrams like you can see in slide 19. I'm not sure if the author annotated the fucntion names or if IDA was able to find them.
He identifies a buffer overflow and writes a small script to exploit it in slide 20 (I'd love some extra explanation of this if anyone can give it)
When the script is run it seems to dump the current configuration of the modem, but then it crashes or resets (slide 21)
The comments on slide 23 suggest that the code has jumped to the "restore_default" function - sorry, I don't understand this part. References to nvram would suggest it's going something to the config though, which would explain slide 21.
Slide 26 shows an (hopefully LAN-side only) exploit that's able to enable the HTTP management interface of the modem and reset the password at the same time.
Final edit: I'm sorry for the formatting of this post. I'd love to collaborate with someone on a blog post about this exploit. I'm really just getting started with firmware reversing (and most of the time I don't get past the binwalk stage). My contact details are in my profile.
He doesn't actually exploit the heap overflow. He just sends messages as a normal backdoor user would, theres no authentication.
(He also greps for the string the server sent upon connection, but it's nowhere to be found. He then just greps for bind and filters for binary files only, to find all binaries that call bind (remember dynamic linking in the end comes down to strings..))
I walk through a similar process here [1], using binwalk to extract the source-code from a firmware image, then running the insecure router software in a QEMU VM. Although the purpose in the linked instructions is to repair a different Netgear exploit from October 2013 by modifying the insecure binary executable (see [2] for information on the technique).
It sounds like binwalk is a member of a family of programs referred to as file rippers. These used to be easy to find, but the "rip" keyword has been taken over by CD and DVD ripping software. They were commonly used to extract embedded files from demo scene demos, including .mod/.s3m/.xm/.it music and .flc videos.
Another good one to look at is QuickBMS - allows you to define a "script" and then feed it to the ripper. I guess it saves you time writing boilerplate code when trying to get at new/unknown file formats. The Xentax Game Research forum loves it - http://aluigi.altervista.org/quickbms.htm (blocked as Hacking/Internet by the corporate proxy here, so it's good)
Thank you for explaining my slides ;)
They were designed to be read by people who understand reverse engineering.
There is some errors in your comments, I didn't exploit anything, I just highlighted a vulnerability in the backdoor :D
People, if you are confused by memes, don't do RE :D
And for those who say I could have just written a simple text, well, text is not that simple to write especially when you're not a native english speaker :) and I had a lot of fun doing my draws
I don't think I get the whole thing either, but my impression is:
- Download image for modem firmware.
- Extract the filesystem from the image by hacking up an open source tool. This represents all the files on-disk on the modem.
- Search the file system for references to the suspicious port. Locate binary that listens on said port.
- Disassemble binary, figure out the protocol/format of messages it's expecting to hear on suspicious port.
- Brute force the effect of sending messages by sending messages to said port with the header it's expecting, and different permutations of payloads? (I'm not sure about this part, I might be making shit up)
- Using this brute forcing figure out what payloads do what and map out what this backdoor listener can do.
What is the tool being shown on slide 18? It looks like it breaks the assembly into basic blocks and shows a control flow graph based on that. Very cool tool, is it open-source?
Well, it is like a game that you can play with your eyes closed. Imagine that you close your eyes and then somebody gives you a large toy made out of LEGOs. And you figure out what this toy is, with your eyes closed! That's what he did.
I actually appreciate the humor, but I'm in the same boat where there's a good portion I'm just not wrapping my head around clearly. I'd love if someone made an annotated version with technical descriptions.
