[ANY] Add ASLR, DEP protection to VB6 apps or any, Terminal Server aware flags

Hi,

it's a console application to patch executable.

Using:

1) open with notepad your app.vbp (main project file of your program) and append to the end:

Code:

---

[VBCompiler]
LinkSwitches="/FIXED:NO"

---

2) compile your program.
3) unpack and compile TSAware_c.vbp from archive below.
4) from command line (or .bat file) execute:

Code:

---

TSAwarePatch.exe "path\to\your\program.exe"

---

What does he do:
- Instruct compiler to generate a relocation section (required by ASLR)
Adds:
- ASLR (IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE)
- DEP (IMAGE_DLLCHARACTERISTICS_NX_COMPAT)
- TSAWARE (IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE)
flags to DllCharacteristics field of Optional Image header
- correct PE checksum.

Detail description:
By default, all VB6 apps has no ASLR / DEP protection. What is it, you can read somewhere else. You can check your app e.g. using Process Hacker.
I'll stop a little bit about TSAWARE:

When you run your app in Windows Server with installed Terminal services some API have unusual behaviour. You can read more in this MSDN article.
If you sure your app meets all requirements stated in above article, to ensure your app will not be virtualized in that way, you must add TS awareness.
And, just a little experiment:
- install terminal sevices (or, here is full instruction in Russian)
- run in console:

Code:

---

change user /execute

---

- reboot
- execute GetWindowsDirectory() API, SHGetFolderPath() or SHGetKnownFolderPath() and you will get C:\Users\Username\WINDOWS instead of C:\WINDOWS until set flag or use something like GetSystemWindowsDirectory() API.

Also, to add TS awareness you can add flag to linker, in .vbp:

Code:

---

[VBCompiler]
LinkSwitches="/TSAWARE"

---

Download attachment: in this post.

Good luck,
Stanislav.

Just for curiosity.
Does the VB6 linker support the flags for ALSR+DEP (/DYNAMICBASE /NXCOMPAT) ?
Just like with /TSAWARE
I think not because those flags were introduced later?
I heard that it's possible to replace the link.exe by a newer version so more flags are supported and maybe the binaries are more trimmer, any experience here?
Again, no need necessary actually. Just out of curiosity.

Code:

---

C:\Program Files\Microsoft Visual Studio\VB98>link /?
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

usage: LINK [options] [files] [@commandfile]

  options:

      /ALIGN:#
      /BASE:{address|@filename,key}
      /COMMENT:comment
      /DEBUG
      /DEBUGTYPE:{CV|COFF}
      /DEF:filename
      /DEFAULTLIB:library
      /DELAY:{NOBIND|UNLOAD}
      /DELAYLOAD:dll
      /DLL
      /DRIVER[:{UPONLY|WDM}]
      /ENTRY:symbol
      /EXETYPE:DYNAMIC
      /EXPORT:symbol
      /FIXED[:NO]
      /FORCE[:{MULTIPLE|UNRESOLVED}]
      /GPSIZE:#
      /HEAP:reserve[,commit]
      /IMPLIB:filename
      /INCLUDE:symbol
      /INCREMENTAL:{YES|NO}
      /LARGEADDRESSAWARE[:NO]
      /LIBPATH:dir
      /LINK50COMPAT
      /MACHINE:{ALPHA|ARM|IX86|MIPS|MIPS16|MIPSR41XX|PPC|SH3|SH4}
      /MAP[:filename]
      /MAPINFO:{EXPORTS|FIXUPS|LINES}
      /MERGE:from=to
      /NODEFAULTLIB[:library]
      /NOENTRY
      /NOLOGO
      /OPT:{ICF[,iterations]|NOICF|NOREF|NOWIN98|REF|WIN98}
      /ORDER:@filename
      /OUT:filename
      /PDB:{filename|NONE}
      /PDBTYPE:{CON[SOLIDATE]|SEPT[YPES]}
      /PROFILE
      /RELEASE
      /SECTION:name,[E][R][W][S][D][K][L][P][X]
      /STACK:reserve[,commit]
      /STUB:filename
      /SUBSYSTEM:{NATIVE|WINDOWS|CONSOLE|WINDOWSCE|POSIX}[,#[.##]]
      /SWAPRUN:{CD|NET}
      /TSAWARE[:NO]
      /VERBOSE[:LIB]
      /VERSION:#[.#]
      /VXD
      /WARN[:warninglevel]
      /WINDOWSCE:{CONVERT|EMULATION}
      /WS:AGGRESSIVE

---

Hi, Krool. Interesting question. I never tried these keys.
One time I replaced linker with newer version and I had some problems.
---
Ok, Just did it again: I copied whole folder:
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.14.26428\bin\Hostx86\x86"
to
"C:\Program Files (x86)\Microsoft Visual Studio\VB98"

+ added /TSAWARE /DYNAMICBASE /NXCOMPAT, I receive such err/warnings:

(google translate):

Quote:

---

LINK: warning LNK4010: Invalid version number of the subsystem 4.0; The default subsystem version is adopted
LINK: warning LNK4044: unrecognized parameter "/ TSAWARE / DYNAMICBASE / NXCOMPAT"; ignored
LINK: fatal error LNK1207: incompatible PDB format in "H: \ _ AVZ \ Our developments \ Example \ Example.pdb"; delete and rebuild

---

But, after I manually delete Example.pdb and re-build the project, linking is successfully completed.
And regardless of warning about uncompatible switches, exe has required flags: 0x8140, mean all 3 options from this topic.

--
BTW. Size of Example.exe:
linker 6.0 - exe (6,21 MB), pdb (2,93 MB)
linker 14.14 - exe (6,56 MB), pdb (3,16 MB)

~ 300 KB higher.
I thought that in 10 years they had to optimize it :)))))))))

Here is a explanation about ALSR and DEP and why it should be included on newer apps: https://blogs.msdn.microsoft.com/vcb...-and-nxcompat/

So in fact your tool TSAwarePatch is very handy to just "patch" any existing app with the new flags. Not to bother about linker switches.

And anyhow. I do not feel comfortable to replace the link.exe just to support /DYNAMICBASE /NXCOMPAT linker options.

So, great tool. :thumb:

When you enable ASLR you also should add the relocation information to the image (/FIXED:NO).

Quote:

---

Originally Posted by The trick

When you enable ASLR you also should add the relocation information to the image (/FIXED:NO).

---

Good point. If it's done by the linker for /DYNAMICBASE, it implies (defaults to) /FIXED:NO

However, when you "patch" later on the flag for ALSR by the TSAwarePatch /FIXED:NO is not set. So it's necessary to compile with /FIXED:NO. If it would be done by linker it's not necessary. But this way it is.

The trick, good to see you.
I had some precautions, but on this topic (post #17) we tested that both samples (VS2008) was identical, only flags is different.
However, I read and I agree that it should include /FIXED:NO. BTW, no crashes for my apps all this time without that switch.

Quote:

---

The trick, good to see you.

---

And you :)

Quote:

---

BTW, no crashes for my apps all this time without that switch.

---

Just it has no sense without the relocations (ASLR). It'll work as if you don't set that flag.

I think it'd good to add that info (about /FIXED:NO) to the first post.

Sure, I'll add.

See: https://jeffpar.github.io/kbarchive/kb/235/Q235956/

Quote:

---

Microsoft Visual C++ 6.0 introduces two new linker optimization options --
/OPT:WIN98, which is set by default, and /OPT:NOWIN98. The default sets the file
alignment at 4K instead of the previous 512 bytes. This results in a larger
module size, but one which loads faster on Windows 98 with reduced file
swapping. A release build of an AppWizard-generated MDI application is
approximately 14K larger than when the /OPT:NOWIN98 option is used, and a
ReleaseMinSize build of a standard ATL DLL with no objects added is
approximately 17K larger.

---

This may account for some of the size difference.

During my experiments I saw no difference in sizes using this switch or not (for both, linker v6.0 and v.14.14).

lol, exe compiled with linker v.14.14 doesn't want to work on XP: "Not a valid Win32 application" :)
Interesting, why?
I see no difference between 2 Dependency Walker logs.
API log: link to image is attached.
Additional linker switches is not used this time.

Check MajorOperatingSystemVersion field of IMAGE_OPTIONAL_HEADER

Hi, The Trick! Thanks, I got it.

I had to change "MajorSubsystemVersion" field from 6 to 4.
MajorOperatingSystemVersion - doesn't matter (it was also 6 in my case). Dunno, what does it affect on.

I think that means it won't run on down level operating systems (it just shows an error message), and it may affect the behavior of some APIs. I can't rememberwhich but I think one of the APIs affected, has to do with returning non-client area sizes of a window.

DEXWERX, only when using a new Link.exe from current VS.

I added patch for MajorSubsystemVersion / MajorOperatingSystemVersion fields
and re-wrote a code a little bit to beautify it and made more detailed console output.
Just if somebody (like me) would like to experiment and use new linker. So the final exe is now support Win 2k/XP.

I can't attach to 1-st post.
So, here it is:

Quote:

---

Originally Posted by Krool

DEXWERX, only when using a new Link.exe from current VS.

---

ah good to know. :thumb:

I was interested in the ASLR and DEP.
After running on a small vb6 test program
>TSAwarePatch.exe myvbtest.exe

My virus scanner was triggered.
Running the patched myvbtest.exe through https://www.virustotal.com reveals a number of antivirus detects a Trojan behavior.

AV emails to report a false positive