@arraybolt3 @eickmeyer @cdp1337 @vkc
Rather than just start disassembling, try to reproduce the blobs that are documented, then see what's different. Then start doing the same with the handful of ones without docs.
Top-level
@arraybolt3 @eickmeyer @cdp1337 @vkc 5 comments
@FritzAdalis @eickmeyer @cdp1337 @vkc That's more or less what I had planned. Reverse engineering tools were what I hoped to use for investigating how things changed from the original source code, if they changed. @arraybolt3 @FritzAdalis @eickmeyer @cdp1337 @vkc Look for strings contained in the blob first—sometimes you can learn a lot that way. @arraybolt3 @FritzAdalis @eickmeyer @cdp1337 @vkc I don't have time to do this myself, but I'd run all of the binary blobs I might want to compare through ssdeep. That way I would get a quick first feel for which are similar/alike, and which are different, and to what extend. https://ssdeep-project.github.io/ssdeep/index.html Doing something like `vimdiff <(xxd binary1) <(xxd binary2) also helps me for quick checks. https://cutter.re/ is a free gui for reversing. @arraybolt3 @FritzAdalis @eickmeyer @cdp1337 @vkc diffoscope is an excellent tool for analysing differences in binaries. It will dive down i into any format it knows (including ELF) to extract meaningful diffs. |
@FritzAdalis @arraybolt3 @cdp1337 @vkc
That's actually an excellent idea.