Skip navigation.
Home

More advanced unpacking - Part I

Unbelievable but true. After 4 months of getting owned by other things making my life mad, i finally managed to release a new unpacking tutorial. This one goes far more into depth as the beginners tutorial i have released last year. It aims to show some generic tricks and tools, that can be used on many other protectors. Enjoy!

Find the files here

Frank Boldewin

Continues to be one of the best and most advanced posters on offensive computing.

I highly encourage giving his posts a read.

V.

ps I think Frank needs some more competition!

I agree about giving Frank

I agree about giving Frank more competition.

I felt disappointed with dannyquist´s Saffron. The release was buggy and I didn´t hear the tool has been fixed or improved since I reported the problem.

btw... Does anyone have a copy of BinBLAST? I´ve tried to find it but I was unable. It´s like it never was released. Even Scott didn´t find a copy to send me it. Incredible but true!

I know he promised to make a new release early in march but I´ld like to test the pre-alpha release.

My apologies for not

My apologies for not updating, it's on my list of things to do but not a high priority. The tool works pretty well for code analysis, but not necessarily reproducing the original binary.

If I remember fine in the

If I remember fine in the test I did with an UPX packed file part of the executable was not being dumped and the code was not unpacked.

Different problem?

Is this different than what we talked about? From what I saw based on the problems you reported the code was unpacking but the executable size was not correct. This sounds like something new.

I can not remember if it was

I can not remember if it was other test.

Make a new release, this time including the binary, and I will make new tests.

Let me see if I can clarify some things

We said we wouldn't release the kernel mode version of saffron which works very well. We also said we WOULD release the dynamic instrumentation version which works much less well. And so we did.

We said the DI version only unpacks a few packers, and only to the point of being able to gain some useful malware analysis.

Never once did we ever advertise that you would get a copy of the original, pre-packed binary with matching file size, md5sum or anything of the sort.

We have no need of or interest in doing that, which seems to only be useful for pirating software, not malware analysis.

Our main interest was in helping developers and analysts automate their malware work more and so we presented and discussed algorithms, techniques and methods that we have found useful in unpacking malware. We presented some proof of concept demo tools to show our results with the limited test set we had. We never tried to say saffron DI was a commercial product or open source project that people should expect to download, install and run.

Saffron requires a high end user or developer who understands the kernel, memory management, process dumping, intel architecture, etc. in order to get running. (its a POC to demonstrate concepts developers can use in their own tools.)

As far as BinBlast, I'll have to ask Scott his plans for it, but it was a similar idea. He released a paper and a concept on using Biology algorithms on binary disassembly. Anyone who chooses to can implement this idea.

These are academic papers and experimental code for research, not ready to download, install and run tools.

So I hope that clarifies things. I encourage everyone to use the concepts we publish and try to develop tools and techniques of their own. We want to support to community and will continue to give this forum to people who want to discuss and debate these ideas.

V.

I wonder if all the above is

I wonder if all the above is really true or are just excuses due the impossibility of producing something that may work as expected.

Please, respect my doubts and excuse my scepticism but I come from a group that has been characterized for facts and not just words so I´m used to be like Saint Thomas.

well

If you had seen our talk, read our paper or listened to our responses it should be obvious that its true.

I also think maybe your expectations are off base with what we said it would do.

I respect your doubts because unpacking is hard. If it was easy everyone would be releasing tools to do it. We are simply releasing academic ideas and findings.

What would be more productive would be if you read the paper and looked at the algorithms and techniques and commented scientifically on flaws or benefits of the concept.

What we released in a nutshell (correct me if I'm wrong Danny) is a technique for overloading the page fault handler in order to find likely OEP candidates which may aid in developing autounpacking tools. We wrote some POC code to show how you can start to implement the idea.

If you have a better method then by all means publish it, we are dying to see it.

V.

I guess I will have to wait

I guess I will have to wait to the day (if it comes) you decide to walk from theory to practice land.

Were you even at the DEFCON

Were you even at the DEFCON presentation? If you were, did you have a fucking clue what they were talking about? Or are you just talking out of your ass?

Oh wait, this is one of those self-answering questions.

I compiled what they

I compiled what they released and I found it was buggy, did you?

Oh, wait! this is other of those self-answering questions.

Yup i let my flashplayer

Yup i let my flashplayer loose on it and it was some nice trickery Frank gave there..

wonder if he didt think it would be as funny if he included peid wich actually found "tElock 0.9 - 1.0 (private) -> tE!" thats the first thing i thought anyways apparently there will be a #2 :)

hope it wont take as long as 4 months for the second

@_pusher_ : sorry, i haven't

@_pusher_ : sorry, i haven't tested the unpackme on peid as i thought, 3 peinfo tools are enough to demonstrate that it is possible to fool them. slightly changes on the unpackme and even peid would fail. promise me. ;)

the main idea of this tut was not to show how a special protector is being unpacked. the aim was to demonstrate some generic tricks and tools, which might also be useful in other unpacking sessions.

for the next part i currently plan, next to introducing other nice tools, some more scripting and other automation tricks. this time with a real life malware, using a proprietary packer.

donno when this will be finished, as my life currently is determined by dozens of other things, but it will be finished before i leave the country for a longer time in summer (without any computers). ;)