-
Apr 29th, 2021, 01:38 AM
#1
Thread Starter
New Member
-
Apr 29th, 2021, 02:15 AM
#2
Re: Is vb6 really native ?
Hi graysuit, welcome to forum.
Interesting topic. Could you post larger screenshots? I can't read the text right now. I believe this forum might be automatically resizing the images but I am not sure.
Peter
-
Apr 29th, 2021, 02:54 AM
#3
Re: Is vb6 really native ?
Originally Posted by graysuit
Whereas native c exe/dll can't be decompiled.
Nor an android c native libs *.so can be.
No, it's the same in C/C++
When you compile something like printf("%s\n", "IT IS CLEAR VISIBLE"); you can find the string literal with hex editor in the compiled executable just the same.
Why would anyone want to obfuscate the literals in the final executable? I can think of only one reason. . . two max.
cheers,
</wqw>
-
Apr 29th, 2021, 03:08 AM
#4
Thread Starter
New Member
-
Apr 29th, 2021, 03:36 AM
#5
Re: Is vb6 really native ?
Originally Posted by graysuit
Hi Peter, Thanks for welcoming !
Looks like site automatically shrink images to save disk.
Here are screenshots links, please view:
https://i.ibb.co/6YP3QQp/1.png
https://i.ibb.co/hgfVXP3/2.png
Hola wqweto ! thanks,
Actually Not just strings, it embed event name as well like "Form_Load", which I don't see in c executable.
Regards for all helps
“Form_Load” literal is probably used by error handling. Bet you would find “main” in C/C++ binary or any function with some kind of error handling which uses __FUNCTION__ built-in constant. Whatever Strings are used will get embedded in the final executable in plain text.
-
Apr 29th, 2021, 03:42 AM
#6
Re: Is vb6 really native ?
From the sidelines: you'll only get a "native" executable, if you actually activate "native" compiling in Project Options
IIRC, the Default is P-Code
But i admit: I have no idea if that makes a difference in a HexViewer
Last edited by Zvoni; Tomorrow at 31:69 PM.
----------------------------------------------------------------------------------------
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------------------
People call me crazy because i'm jumping out of perfectly fine airplanes.
---------------------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad
-
Apr 29th, 2021, 05:28 AM
#7
Re: Is vb6 really native ?
Form_Load is visible because he removed the 'Private' declaration.
Normal Form_Load are not visible:
Code:
Private Sub Form_Load()
instead of
that equals to:
Code:
Public Sub Form_Load()
-
Apr 29th, 2021, 05:52 AM
#8
Re: Is vb6 really native ?
That is not executable code. Those are string literals. Try viewing other executables, you will see plain text and some other stuff are just embedded in the same file as the executable code.
-
Apr 29th, 2021, 06:05 AM
#9
Re: Is vb6 really native ?
Originally Posted by Zvoni
IIRC, the Default is P-Code
It defaults to Native with Optimize for Fast Code option and no Advanced Optimizations.
cheers,
</wqw>
-
Apr 29th, 2021, 06:36 AM
#10
Re: Is vb6 really native ?
Last edited by Zvoni; Tomorrow at 31:69 PM.
----------------------------------------------------------------------------------------
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------------------
People call me crazy because i'm jumping out of perfectly fine airplanes.
---------------------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad
-
Apr 29th, 2021, 08:37 AM
#11
Re: Is vb6 really native ?
if its not native or p-code what is it?
I dont think microsoft would lie to us and have some kind of bytecode instead.
-
Apr 29th, 2021, 08:41 AM
#12
Re: Is vb6 really native ?
Originally Posted by baka
if its not native or p-code what is it?
I dont think microsoft would lie to us and have some kind of bytecode instead.
You want to put money on that statement?
Last edited by Zvoni; Tomorrow at 31:69 PM.
----------------------------------------------------------------------------------------
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------------------
People call me crazy because i'm jumping out of perfectly fine airplanes.
---------------------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad
-
Apr 29th, 2021, 09:25 AM
#13
Re: Is vb6 really native ?
I wonder if this entire thread is about the lay interpretation of the word "code." Most people have no programming background and probably have no clue.
Many see "code" and think it is the same as "cipher" (which they probably mean, but duh). From there they think "secret" and get their panties in a bunch when they find plain text string literals and symbol names in object code.
I shudder to imagine the safety nightmares similarly perpetrated playing at house wiring, plumbing, auto repairs, etc.
-
Apr 29th, 2021, 10:59 AM
#14
Thread Starter
New Member
-
Apr 29th, 2021, 11:15 AM
#15
Re: Is vb6 really native ?
Not necessarily. What would you expect to see? After all, every file is just going to be some string of bytes. In theory, that string of bytes could turn out to be a recognizable string, though that is vanishingly unlikely. Still, every file will be a string of bytes. Any strings in the program are also just a series of bytes, and there is no good reason for them not to be in the order they are found in the string, so if you look at that series of bytes in the source code, you'll see the string. If you notice, some of the other bytes in the file look like letters. That's just because that byte value represents that letter. It isn't meaningful, just coincidence. The bytes in the string also happen to represent the letters in the string, and since they remain in the sequence of the string, the letters appear in the sequence of the string, and thus you see the string. It's not exactly coincidence, since the sequence of bytes is holding the string literal, so it would make sense that you would see the bytes lining up correctly to form the string. It's still your mind that is interpreting it as a string, though. As far as the program that built your display is concerned, it's just a sequence of independent bytes, and those bytes happen to be displayable as the character you see. The fact that they form a string is up to your brain, not the bytes.
So, what is happening with the Form_Load? Essentially, it's the same thing. It's a sequence of bytes, each byte represents by the character, and your brain recognizes the sequence of characters to be the string. So, why are THOSE bytes in that sequence? As you would expect, there would have to be SOME sequence used, because there would have to be something (even if just a four byte pointer) representing the function address. Why was THAT sequence used? The reasoning is probably somewhat lost to time. I would think that it would have been pretty convenient to know about external functions in lots of places, and using recognizable names, while not the absolutely most compact means to represent them, would have a powerful advantage. It's probably something as simple as that: The name is there because the function is public, and it was thought to be advantageous to be able to get that name out in a recognizable format.
My usual boring signature: Nothing
-
Apr 29th, 2021, 11:35 AM
#16
Thread Starter
New Member
Re: Is vb6 really native ?
Nice, it would be great memory to meet developers that joined here before my birth date.
Well, everything got cleared.
Now at last, is it will be hard to reverse or decompile vb6 executable same like an C executable is hard to ?
-
Apr 29th, 2021, 12:16 PM
#17
Re: Is vb6 really native ?
u will never be able to fully decompile an exe to vb6 since a lot is lost when compiling. the decompiler will need to "add" an id to things that are just memory allocations without a title, while in the source could you could have a function name that is obvious for that purpose. it will be hard to understand. the same with variables names could be no-name.
as you already know from private function names where the name is lost.
this product is a decompiler and u can read yourself https://www.vb-decompiler.org/products.htm
usually "hackers" are using live-memory debugger when they hack something, they dont need decompilers.
-
Apr 29th, 2021, 12:20 PM
#18
Re: Is vb6 really native ?
It is possible to decompile anything usable to a sufficient extent. If you are concerned that somebody will steal your magic code, then you have to first decide just how magic your code really is. If it is sufficiently valuable, then yes, somebody will be able to decompile it enough to steal it. If it is mostly only valuable to you, then you could post the source code on a bulletin board and nobody would be interested in it, let alone steal it. The truth lies somewhere along that continuum, you just have to decide where it lies, for you.
My usual boring signature: Nothing
-
Apr 29th, 2021, 12:30 PM
#19
Thread Starter
New Member
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|