Skip to main content
Reverse Engineering

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

5
  • Your decompilation is an attempt to transform the ELF header of a MIPS binary into 32-bit 80x86 assembly. Unfortunately, the result doesn't make sense. I've uploaded my IDA disassembly to Mega. You might try if you can load the .idb into the trial version of IDA, or you can check the (editable) asm or (more readable) html file. Even if you don't know Mips assembler, function names and printed strings tell you a lot about what the binary does. Commented Jan 21, 2015 at 17:13
  • I took a look at the code, I still don't understand it (except for the function names). As you said probably there is a private key that I need to crack / discover. Can you suggest me any way? As I said my only goal is to compile a custom firmware, and I still don't know if the else of if [ -x /usr/sbin/sig_verify ]; then is really valid (line 156 to 164 of update.sh) Commented Jan 21, 2015 at 19:23
  • Seems to me like there was an old way to validate the file, and a new way. The old way is the else part, and it assumes the checksum is at bytes 240-255 of the file. The generator sets them to 0, generates the MD5sum of the file, then stores the MD5sum into those bytes. The validator extracts them, sets them to 0, computes the MD5sum, and checks if they match. But all this is only done if sig_verify doesn't exists, or isn't executable. Commented Jan 21, 2015 at 21:33
  • If sig_verify exists and is executable, then it's used instead of the "old" way. This will execute the sig_verify binary, which does something similar, but it will also use asymmetric encryption on the checksum. To replicate this, you'd need the private key, but you only have the public one from the disassembly. Getting that private key is about as feasible as getting the secret from an ssh or a https server - there's no real way to do this. Commented Jan 21, 2015 at 21:37
  • I understood the code, but I didn't understand why is there the alternative since the firmware is packed and the file couldn't disappear. Even if the file isn't available the firmware should be verified and return a positive value, but it isn't. I mean, with the adaptation code I made if I pass the firmware it returns a verification check error ( "Error: wrong validation token ($token, $hash)") There should be a way of flashing a custom firmware without actually JTAG the router no? Is there any method instead of "trying to crack" the private key? Commented Jan 21, 2015 at 22:44