[DeadLine]

Hello,

DeadLine's File Binder is an easy to use file binder that you can use to bind 2 files into one executable file.

Screenshot:
[img]http://i363.photobucket.com/albums/oo73/Allibobo/fb1.png[/img]

Screenshot:
[img]http://i363.photobucket.com/albums/oo73/Allibobo/fb2.png[/img]

Download:
http://www.mediafire.com/?ghkhzk55fipo4ih

VirusTotal:
https://www.virustotal.com/file/88898ead...334512165/

Please leave a comment to keep this thread alive !

DeadLine

[skyline7349]

thanks man taking look at it now. i really want to know how to theme a program.

[triplex-x]

nice share bro and thanks for sharing the sources. awesome binder and the GUI

[Vuln]

Why do you put like literally everything in a try/catch statement? o.0

PHP Code


<?php 
try
    {
    if (chbMessagebox.Checked == true)
    {
    grbMessagebox.Enabled = true;
    }
    else
    {
    grbMessagebox.Enabled = false;
    }
    }
    catch
    {
    } 


^ for example, what error could possibly be catched?
chbMessagebox.Checked == true could be shortened to chbMessagebox.Checked btw.

Also keep in mind that the output file still has the assembly info of the stub, which probably causes a detection or two :p

Anyways, it's working fine, good job. Nice website of yours too.

[DeadLine]

Why do you put like literally everything in a try/catch statement? o.0

PHP Code


<?php 
try
    {
    if (chbMessagebox.Checked == true)
    {
    grbMessagebox.Enabled = true;
    }
    else
    {
    grbMessagebox.Enabled = false;
    }
    }
    catch
    {
    } 


^ for example, what error could possibly be catched?
chbMessagebox.Checked == true could be shortened to chbMessagebox.Checked btw.

Also keep in mind that the output file still has the assembly info of the stub, which probably causes a detection or two :p

Anyways, it's working fine, good job. Nice website of yours too.

Hello,

I use try/catch because you never know when an error may appear. The codes might be good, but there can always be a problem when an advanced user starts editing the functions with an editing program and causes an error. Also, it is good practice :)

And thank you !

Kind regards,

DeadLine

[+Bourbon]

Hello,

I use try/catch because you never know when an error may appear. The codes might be good, but there can always be a problem when an advanced user starts editing the functions with an editing program and causes an error. Also, it is good practice :)

And thank you !

Kind regards,

DeadLine

You're using them wrong. You shouldn't use try catch blocks to mask errors. You should trap errors and perform statements accordingly. What's strange is that you have proper error trapping and then surround the statement in a try catch clause regardless. It's not a good programming practice it's very poor. There's a slight performance draw back with testing for an exception but the real performance draw back would be using try catch blocks instead of error trapping. Not really relevant to you though.

Sometimes using a try catch block is essential as there are no means for error trapping. For example, when you're using a Stream Reader:

Code

.    StreamReader Reader;
     Reader = new StreamReader("InvalidPath");
     Reader.ReadToEnd();

As far as i know there's no way to determine if the file isn't being used by another process or whatever condition that may cause an exception. So most appropriate thing to do would be handle an IOException thrown by the StreamReader class constructor.

An example of where a try catch block is redundant can be found in seconds using your project.

[DeadLine]

You're using them wrong. You shouldn't use try catch blocks to mask errors. You should trap errors and perform statements accordingly. What's strange is that you have proper error trapping and then surround the statement in a try catch clause regardless. It's not a good programming practice it's very poor. There's a slight performance draw back with testing for an exception but the real performance draw back would be using try catch blocks instead of error trapping. Not really relevant to you though.

Sometimes using a try catch block is essential as there are no means for error trapping. For example, when you're using a Stream Reader:

Code

.    StreamReader Reader;
  Reader = new StreamReader("InvalidPath");
  Reader.ReadToEnd();

As far as i know there's no way to determine if the file isn't being used by another process or whatever condition that may cause an exception. So most appropriate thing to do would be handle an IOException thrown by the StreamReader class constructor.

An example of where a try catch block is redundant can be found in seconds using your project.

I already knew this, but thanks anyway.

[+Bourbon]

I already knew this, but thanks anyway.

That explains why you use try catch blocks incorrectly.

[dreamer66]

There is nothing wrong with using try/catch blocks where it's unlikely to get any errors. Try/catch only affects performance when they fire so the performance loss is non existent if they don't.

[DeadLine]

There is nothing wrong with using try/catch blocks where it's unlikely to get any errors. Try/catch only affects performance when they fire so the performance loss is non existent if they don't.

Finally someone who understands. Thank you sir !

[+Bourbon]

There is nothing wrong with using try/catch blocks where it's unlikely to get any errors. Try/catch only affects performance when they fire so the performance loss is non existent if they don't.

Finally someone who understands. Thank you sir !

I did a benchmark and it is in fact slower. But as mentioned before it's minuscule. Really bad conventions however.

[DeadLine]

I did a benchmark and it is in fact slower. But as mentioned before it's minuscule. Really bad conventions however.

That is true, but once again, what if someone with a decompiler decided to edit your application and delete a checkbox and recompile it. It would cause an error when he binds files.

So in fact, I don't mind the application being 0,001 miliseconds slower than normal.

I know that this is a bad example but it is really all about being 100% sure that no error messages will pop up.

[dreamer66]

I did a benchmark and it is in fact slower. But as mentioned before it's minuscule. Really bad conventions however.

How did you do the benchmark exactly ?

Code

Stopwatch sw = new Stopwatch();
    sw.Start();

    if (checkBox1.Checked == true)
    textBox1.Enabled = false;

    Console.WriteLine(sw.Elapsed);
    sw.Stop();
    textBox1.Enabled = true;

    try
    {
    if (checkBox1.Checked == true)
    textBox1.Enabled = false;

    Console.WriteLine(sw.Elapsed);
    sw.Stop();
    }

    catch { }

The results are almost identical
00:00:00.0001939
00:00:00.0002231

Needless to add, we are talking about values that are less than a millisecond.

[+Bourbon]

How did you do the benchmark exactly ?

Code

Stopwatch sw = new Stopwatch();
    sw.Start();

    if (checkBox1.Checked == true)
    textBox1.Enabled = false;

    Console.WriteLine(sw.Elapsed);
    sw.Stop();
    textBox1.Enabled = true;

    try
    {
    if (checkBox1.Checked == true)
    textBox1.Enabled = false;

    Console.WriteLine(sw.Elapsed);
    sw.Stop();
    }

    catch { }

The results are almost identical
00:00:00.0001939
00:00:00.0002231

Needless to add, we are talking about values that are less than a millisecond.

Yes, minuscule.. Like I said. What you said was:

performance loss is non existent

So I was right.

That is true, but once again, what if someone with a decompiler decided to edit your application and delete a checkbox and recompile it. It would cause an error when he binds files.

That's hilarious.

[Vuln]

That is true, but once again, what if someone with a decompiler decided to edit your application and delete a checkbox and recompile it. It would cause an error when he binds files.

So in fact, I don't mind the application being 0,001 miliseconds slower than normal.

I know that this is a bad example but it is really all about being 100% sure that no error messages will pop up.

Why in earth would someone decompile a binder to remove a checkbox? I know what you mean but that was probably the worst example ever... It's like... when a program saves a log every 0.5 seconds because a thunderstrike might disable the electricity one day :p

Anyways, no -visible- performance loss isn't a reason to do it, right? I mean, it takes longer to code, it's a bit harder to read, it's harder to see when a 'good' try/catch statement is used etc.

But enough about try/catch :p What did you do to bypass TR/Dropper.Gen? I can't get rid of it in my own binder yet the source is nearly the same.