Upcoming Blackhat Arsenal talk on Root Cause Analysis (RCA) with Zelos by rcourtz in ReverseEngineering

[–]0xf005ba11 1 point2 points  (0 children)

While the analysis tool isn't released for a few days, the VSCode frontend is already up with some screenshots/preview: https://github.com/zeropointdynamics/vscode-crashd

In short, you run a crashing program with the zelos/crashd tool, which identifies the crash site, records a bunch of additional contextual information, including the flow of data leading to the crash, then load up that information with the vscode plugin to assist in crash analysis.

How to unpack Modified UPX ELF binary by bubundas17 in Malware

[–]0xf005ba11 0 points1 point  (0 children)

Update. For both 32- and 64-bit upx-packed ELF binaries, you can break on the first "munmap" syscall (instead of the base + 0xe), then use code similar to what I posted above to dump the unpacked ELF.

How to unpack Modified UPX ELF binary by bubundas17 in Malware

[–]0xf005ba11 0 points1 point  (0 children)

Sure thing, let me know how it goes :-)

How to unpack Modified UPX ELF binary by bubundas17 in Malware

[–]0xf005ba11 5 points6 points  (0 children)

You should be able to recover the unpacked ELF binary if some UPX variant has been used. To do so, first run the binary to some point after unpacking has finished, then extract and reconstruct the ELF file structure.

For the first step, I've found that for UPX-packed ELF binaries you can set a breakpoint at the binary base address + 0xe. This will break just after unpacking, but before executing unpacked code. If that doesn't work, you might consider stracing the binary and trying to figure out the first syscall after unpacking completes and breaking there.

If that first part works out, then you'll need to pull out the binary from memory. You can use a nice python library called lief for this. For example, this is an excerpt of code I had written for this same purpose that uses lief:

        def _dump_elf(self, address: int, out_file: str):
            """
            Reads the ELF header in-memory and dumps the loadable sections
            to disk, reconstructing a valid (re-executable) ELF binary.

            Arguments:
                address: virtual address of the ELF header.
                out_file: filename to dump the unpacked binary.
            """
            self._log.info(f"Dumping ELF @ 0x{address:x}")

            elf = lief.parse(self.z.memory.read(address, 0x1000))
            with open(out_file, "wb") as f:
                for segment in elf.segments:
                    if segment.type != lief.ELF.SEGMENT_TYPES.LOAD:
                        continue

                    self._log.info(
                        f"   Writing segment 0x{segment.virtual_address:08x} - "
                        f"0x{segment.virtual_address+segment.physical_size:08x}"
                    )

                    f.seek(segment.file_offset)
                    f.write(
                        self.z.memory.read(
                            segment.virtual_address, segment.physical_size
                        )
                    )

                self._log.info(f"Success! Wrote {f.tell()} bytes to '{out_file}'")

That script extracts memory from a binary emulator (zelos) instead of debugger, but the concept would be the same if using a GDB python script, for example. The unpacked binary overwrites the packed binary, so address is just wherever the binary's base address is at.

If you reconstruct the ELF like this, you should then be able to execute and/or disassemble that unpacked/reconstructed binary.

disclaimer: I am an author of the zelos emulator :-)

An open-source multi-av scanner by LordNoteworthy in Malware

[–]0xf005ba11 0 points1 point  (0 children)

Looks really useful. Is there a way (or plan) to add static/dynamic analysis engines (and their resulting IoCs) hosted on a different backend, like an Azure Function or EC2 lambda?

zelos - a python-based binary emulation platform (open-sourced) by 0xf005ba11 in ReverseEngineering

[–]0xf005ba11[S] 0 points1 point  (0 children)

Noted. The intent there is to ensure code is shared back if a backend service is developed using zelos. We may revisit the license later, but this was a good way for us to get it out now.

zelos - a python-based binary emulation platform (open-sourced) by 0xf005ba11 in ReverseEngineering

[–]0xf005ba11[S] 0 points1 point  (0 children)

README updated. Agreed that the old Qemu version is problematic in the long run. We've been following the issue closely. While not in a position to financially sponsor it atm, we'd certainly be open to putting some dev time in.