# New application security features in Clarion - Clarion

**URL:** <https://clarionhub.com/t/new-application-security-features-in-clarion-clarion/3518>\
**Category:** clarionsharp.com/blog/\
**Tags:** security\
**Created:** [September 3, 2020, 1:09am UTC](https://clarionhub.com/t/new-application-security-features-in-clarion-clarion/3518 "2020-09-03T01:09:41Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![brahn](https://clarionhub.com/user_avatar/clarionhub.com/brahn/32/756_2.png) [@brahn](https://clarionhub.com/u/brahn)\
**Post date:** [September 3, 2020, 1:09am UTC](https://clarionhub.com/t/new-application-security-features-in-clarion-clarion/3518/1 "2020-09-03T01:09:41Z")

</div>

> **[New application security features in Clarion | Clarion](https://clarionsharp.com/blog/new-application-security-features-in-clarion/)**

---

<div class="post-metadata">

**Author:** ![CarlBarnes](https://clarionhub.com/user_avatar/clarionhub.com/carlbarnes/32/1859_2.png) [@CarlBarnes](https://clarionhub.com/u/CarlBarnes)\
**Post date:** [September 3, 2020, 2:50pm UTC](https://clarionhub.com/t/new-application-security-features-in-clarion-clarion/3518/2 "2020-09-03T14:50:16Z")

</div>

These are good changes for SV to make. I’ll probably stick with classic rebasing because it will be faster and use less memory.

For those that do not take the time to set DLL base addresses ASLR is an improvement over Loader rebasing. Both classic Image\_Base and new Dynamic\_Base can coexist. Only if the EXE has ASLR=On does the Process have ASLR for those DLLs with ASLR=On.

Note that EXEs get random rebased also, unless they have FIXED in the EXP. In that case the EXE with ASLR=On is loaded as usual at 40’0000h but the DLLs with ASLR get randomized. You can find mentions of this on the web for the MinGW compiler that defaults to FIXED for EXEs.

Some good description here:

> **[If relocated DLLs cannot share pages, then doesn't ASLR cause all pages to be...](https://devblogs.microsoft.com/oldnewthing/20160413-00/?p=93301)**
>
> ASLR is careful to keep sharing alive.

> **[How important is it nowadays to ensure that all my DLLs have non-conflicting...](https://devblogs.microsoft.com/oldnewthing/20170120-00/?p=95225)**
>
> Not so much, since ASLR changes it anyway.

---

<div class="post-metadata">

**Author:** ![Paul\_Attryde](https://clarionhub.com/user_avatar/clarionhub.com/paul_attryde/32/1334_2.png) [@Paul\_Attryde](https://clarionhub.com/u/Paul_Attryde)\
**Post date:** [September 4, 2020, 9:59pm UTC](https://clarionhub.com/t/new-application-security-features-in-clarion-clarion/3518/3 "2020-09-04T21:59:38Z")

</div>

I’m curious, as far as I know (and I haven’t looked at this in years), isn’t this just implemented as flags in the PE header? If I’m right then in theory any CW app can support ASLR and DEP, you just have to know which bits to twiddle.

---

<div class="post-metadata">

**Author:** ![CarlBarnes](https://clarionhub.com/user_avatar/clarionhub.com/carlbarnes/32/1859_2.png) [@CarlBarnes](https://clarionhub.com/u/CarlBarnes)\
**Post date:** [September 5, 2020, 6:15pm UTC](https://clarionhub.com/t/new-application-security-features-in-clarion-clarion/3518/4 "2020-09-05T18:15:32Z")

</div>

Yes PE Optional Header flags in Dll Characteristics. Maybe they made some code changes for DEP.

If you have VS you have EditBin and can set them now. LibMaker has all the code needed to read a PE file header and could write. To do this to the RTL DLLs you would have to unsign them or the digital signature checksum would be bad. There are 2+ on the web. I have one written I’ll post on Github soon. Its a function in ImageHlp.DLL.

> **[IMAGE\_OPTIONAL\_HEADER32 (winnt.h) - Win32 apps](https://learn.microsoft.com/en-gb/windows/win32/api/winnt/ns-winnt-image_optional_header32?redirectedfrom=MSDN)**
>
> Represents the optional header format. (32 bit)

IMAGE\_DLLCHARACTERISTICS\_DYNAMIC\_BASE  
IMAGE\_DLLCHARACTERISTICS\_NX\_COMPAT for DEP