Here's a lesson you should learn
before writing your own security tool.
So, long time ago, before I get
into, that deep into publishing malware analysis reports,
even before I get deep into malware analysis itself,
or into analyzing big malwares,
and before my stuxnet report,
I wrote a tool called Pokas x86 Emulator.
This tool was really a good tool
to unpack in malware,
through creating a virtualized environment.
All the environment from Windows, processor,
everything was emulated and it runs the malware
inside the simulated environment
and then it lets the malware unpack itself,
and then it becomes unpacked,
it dumps it, and that's it.
So, this tool give me a really big success.
I have spoken in cairo security camp.
While speaking in the conference,
I got one of the audience actually working
in a company, he came to the stage
and he offered me a job inside his company.
I got lots of success out of it.
Lots of buzz, lots of people talking about it.
It has been shared multiple times
and it got me into working in each search when I started.
So, that's one, this was a really successful project
that I have created.
I decided to take it to another level.
I created another bigger application
called, the Security Research and Development Framework.
That was really, really big project.
It included the emulator as part of it,
it included a debugger,
an API hooking tool, process injection,
it included all types of instrumental tools
to do a malware analysis.
Any tool you would think about malware analysis.
Even included PCAP analysis,
included Android analysis, included so many tools inside.
This framework was created
to help people who want to write their own security tools,
especially malware analysis tools or forensics,
to use the tools inside this framework
to build their own tools.
Guess what, with the success of the emulator,
now the whole emulator is included
as just a small part of a bigger, bigger project called,
The Security Research and Development Framework,
that is out there.
This project has failed miserably.
Nobody has used it.
Nobody cared about it.
I got to a speaking engagement,
however, nobody really cared about the project.
Nobody really decided to download it
and use it by himself.
If was really, really unsuccessful project.
I spent two years writing this project
and it ended up just as another application on the top.
And if you search for malware,
or malware analysis, or even incident handling,
you are seeing it help so many projects
that look so amazing.
Lots of code, that nobody's using.
But what is the problem?
Why these tools are not successful
and how you can avoid that.
So, basically, if you want to write your own security tool,
you should think about marketing first.
What is the problem that you are trying to solve,
what's exactly the problem?
Is the audience want to unpack the malware?
If that's what you are targeting for
and you know that so many people are session online
for a solution for this problem.
Then you write a tool for exactly that problem,
and solve exactly that problem.
If this problem is not very common,
like people wants to develop their own security tools,
then you don't need to write a solution for it.
Maybe that will make your project not very successful.
Second thing, if you are writing a tool,
here's the difference between marketers
and engineers.
Engineers think that more features means more success
for the project,
but the reality is the opposite.
Marketers tell you that
more features, create more distraction
from the main feature of this application.
It means more information you want to submit
to the audience.
And, the most important, you can make the audience
take too information at the same time,
or believe in two things at the same time.
If you make them believe that they have a problem,
and marketing the malware, and that's a solution.
Or believe that they want to write a debugger
and that's, that the debugger is included,
but you can't offer them both at the same time.
If you are making an article,
you can't just list features.
Nobody cares about all the list of features.
They care about one main problem
and one main solution.
More features as well, means it's much harder
for them to use the tool.
Because the more features,
means it's more complicated, it's more structured,
and when this structures there'll be more steps.
It's like a big country,
there's more bureaucracy, lots of work and some.
So, the best option is to have the least amount
of features as possible, inside this tool.
Just solve the main issue.
This is the first thing to think about.
Other things, you can include more features
when they are requested and they are really a supplement
for the main solution.
Don't create a tool that's solves multiple solutions
at the same time.
The third thing, focus on the marketing first.
Marketing is everything.
You're writing in the tool,
share your story in writing this tool,
share the steps that you're following,
share the idea with the people.
You're idea will not be stolen.
Even if it's stolen,
the ideas are worth a dime a dozen,
but all the money is in implementation.
All the success is in the execution, in the implementation.
There's no, there's lots of ideas out there.
And keeping your idea, somebody has thought
about it before, and that happens all the time.
But, when implement the ideas, are very few people.
So share your story, and share how it goes,
and as well, focus on the documentation,
on the examples, on the tutorials,
focus on presenting, focus on getting this
across to the audience,
and that will help you more define the project
as you go along.
If you do the waterfall style,
which create the whole tool
after you finish it, now present it,
you'll discover that it may not suit the audience.
It may work, it may not.
And it will be, it's kind of a combo.
Let's see if this will work,
you put it out there like how I did
with Security Research and Development Framework,
but doesn't succeed so much.
So, focus so much on your marketing
and for your marketing with the development time.
Even before your idea goes,
even before you start writing the code.
Maybe you start presenting this idea to people,
or actually, possibly your audience.
Not your family and friends who don't know
what's the malware analysis is about.
Focus on your audience and trying to reach them,
trying to connect to them,
and building relationships,
and ask them and get their feedback.
That's it for today, and see you in the next video, bye-bye.