PureBasic Forums - English

When compiling some Window applications, i can notice some PB related strings in the exe! It would be nice if this can be changed, btw not everybody must see in what language the program has been coded ^^ thanks

here are some examples, you may find inside your exe.

pb_toolbar_id
pb_toolbar_callback
PB_MDIGadget
PB_WindowID
PB_ID

va!n wrote:not everybody must see in what language the program has been coded

and think "it's only Basic" ?

Why do you come up with this topic over and over again?
These strings are in there because they are needed, its as simple as that. What is so hard to understand there ?

If you have such a big problem with that, you can always use an exe packer/crypter to hide them.

k ^^
last time i posted it, because there was the name "purebasic" in the exe, but some time ago... i can still live with it - it was just an idea and i dont want bother about the PB strings in exe futuremore

Well. That the strings we use shows up in the exe's simply shows how brilliant and simple the compiler handles things. Purebasic exe's can be cracked much easier than f.ex exe's compiled with visual basic, because the code you write actually does what you write without much bloat

Thats why programs done with purebasic are rather easy to understand using a disassembler, and this is good.


IF you like to hide strings and other stuff from your exe, you will need to do it yourself programatically, or use some sort of external tool. Period.!

> Purebasic exe's can be cracked much easier than f.ex exe's compiled with
> visual basic [...]

Actually, I once read that Visual Basic exes are simple to crack because it's
such a popular language that all the crackers know what the code blocks look
like, and what they do.

PB wrote:
Actually, I once read that Visual Basic exes are simple to crack because it's
such a popular language that all the crackers know what the code blocks look
like, and what they do.

Ok seen from "someone who have the two exes, a disassembler and no experience in cracking either vb or pb, only assembler knowlegde"'s point of view then

@thefool: I know what you mean. Visual Basic apps are so common that
all the crackers can tell what command a block of code relates to, so it's very
bad in that respect. Some anti-cracking sites therefore suggest VB users NOT
use VB commands for rego routines and to use API or encrypted commands
instead, to avoid this very situation.

Yeah. With purebasic, we are so lucky to choose between all of them, and even make our own encrypted routines wich get decrypted at runtime

I must of mis read, can someone explain this to me?

It sounded like va!n meant the constants themselves #pb_windowID, is showing up in the exe, not string representations, since string representation shows up in all language's exes unless they are encrypted.

TheFool's response sounded like he was talking about actual strings you place in the EXE. And that they are required (???)

as for PureBasic being in the exe. One out think that any compiler wouldnt need to self-advertise in it's customer's products <---- I think I mis-read that, since TheFool stated they are needed? (???)

On a side note, I worked on a program that stripped out advertising out of vbin files, only to find the files no longer work, heheh. If the same can be done with PB created exe/dlls w/o running the risk of the program no longer working ... that would be heaven sent ...

Shannara wrote:I must of mis read, can someone explain this to me?

It sounded like va!n meant the constants themselves #pb_windowID, is showing up in the exe, not string representations, since string representation shows up in all language's exes unless they are encrypted.

TheFool's response sounded like he was talking about actual strings you place in the EXE. And that they are required (???)

as for PureBasic being in the exe. One out think that any compiler wouldnt need to self-advertise in it's customer's products <---- I think I mis-read that, since TheFool stated they are needed? (???)

On a side note, I worked on a program that stripped out advertising out of vbin files, only to find the files no longer work, heheh. If the same can be done with PB created exe/dlls w/o running the risk of the program no longer working ... that would be heaven sent ...

Freak said they were needed
I AM wondering why the actual constant names show up, but well.

About getting the advertising out of pb programs, its easy. Compress or encrypt the exe
You could do some code to actually encrypt the code portions that uses these constants (self modifying).

About VBins, i guess it has some kind of checksum check, wich you can remove using a disassembler.
Eg overwrite the advertising with 00 or nops (90h), and then skip the crc check. Or rewrite the crc. Or hope that pb one day get a packer that can do all this

Why the CONSTANT names show up, i dont know. but i trust Fred.

Well, it's just not constants name, but 'id' which are used with Get/SetProp() api. It can't be avoided so just relax .

*slaps head* DUH to me! heh. I was curious about that big self-modification craze a few months ago.

I trust Fred as well. And I 2nd that, would be nice to have a packer by default that does all of that Thanks for bringing that up, TheFool.

i don't know about others but for me it's like a medal of honor to show others what is possible with pb! so i think you must be proud of those pb strings!;-)

Well, Im only worried about the criminal side of peeps By looking for certain strings in a exe, you can tell about the compiler, and one possible way of attack. Let's take for instance, our favorite (sic) compiler, .NET. Someone can open the bugger and look for strings that references the MSIL, which you can see right away.

Run it through a de"compiler", to grab the MSIL, run that through one of several tools available on the net to convert it to the language of your choice. C# or VB.net. And voila, you have the source code an can play around. obstructors (sp?) are a joke in this case. Welcome to the world of .NET.

Im not saying PB is that way. But, by finding those strings, a person can find a method of attack. What? a PureBasic compiler? Chances are, the same person is using some PB libraries for some of their data files. Lets search those ... Ah, by opening up any vbin files in notepad, you get a (c) reel media productions. Now, the attacker can download purebasic off of the usenets, and torrents. Grab the free vbin library, and easily construct a program that will render the vbin files useless by either stripping out certain things, or even using the built in vbin_delete() w/ no password required.

What's the last thing he needs to do? Distribute this "malware" to all of the people using the software .... Social Engineering is the way to go here

But anyways, those are my thoughts