-
Dec 9th, 2021, 01:47 PM
#1
Transmit Executables
I discovered a way to get around the problem of web bowsers (eg. Google Chrome) and mail servers (eg. Gmail) blocking executable files without any notification or bypass method. The servers do not identify potential malware based upon the file extension, but rather on the file format itself. So the logical solution is to change the format.
This program has the added advantage of encrypting the file using the outdated RC4 encryption technique. Speed and ease of use are among RC4's major benefits. But RC4 can be hacked, especially if you use the same key repeatedly. Also, RC4 isn't ideal if you have small bits of data to send.
To combat these issues, the key is different with each file and is shuffled. To identify and separate the original and encrypted files, the encrypted file has an extra ".edf" (Encrypted Data File) extension added to the file name.
The RC4 code that I found was for VBA and included an extra loop routine to advance the byte table. I really don't know if that makes the results more secure or not, but for now I have commented it out.
J.A. Coutts
Code:
Option Explicit
Dim AllBytes(255) As Byte
Private ByteBuffer() As Byte
Private eBuffer() As Byte
Private Declare Function WideCharToMultiByte Lib "kernel32" (ByVal CodePage As Long, ByVal dwFlags As Long, ByVal lpWideCharStr As Long, ByVal cchWideChar As Long, ByVal lpMultiByteStr As Long, ByVal cbMultiByte As Long, ByVal lpDefaultChar As Long, ByVal lpUsedDefaultChar As Long) As Long
Private Declare Function MultiByteToWideChar Lib "kernel32" (ByVal CodePage As Long, ByVal dwFlags As Long, ByVal lpMultiByteStr As Long, ByVal cchMultiByte As Long, ByVal lpWideCharStr As Long, ByVal cchWideChar As Long) As Long
Private Sub cmdDecrypt_Click()
Dim FileName As String
With Dialog1
.DialogTitle = "Select a File"
.InitDir = App.Path '"C:\"
.Filter = "All Files|*.*"
.ShowOpen
FileName = .FileName
End With
Me.Caption = FileName
If Len(FileName) = 0 Then
MsgBox "Nothing Selected!", vbExclamation
Exit Sub
End If
GetFile (FileName)
'DebugPrintByte FileName, ByteBuffer
If Right$(FileName, 4) = ".edf" Then
FileName = Left$(FileName, Len(FileName) - 4)
Else
MsgBox "Improper file name!", vbExclamation
Exit Sub
End If
eBuffer = RunRC4(ByteBuffer, FileName)
'DebugPrintByte "RC4 Decrypted", eBuffer
Erase ByteBuffer
PutFile (FileName)
End Sub
Private Sub cmdEncrypt_Click()
Dim FileName As String
With Dialog1
.DialogTitle = "Select a File"
.InitDir = App.Path '"C:\"
.Filter = "All Files|*.*"
.ShowOpen
FileName = .FileName
End With
Me.Caption = FileName
If Len(FileName) = 0 Then
MsgBox "Nothing Selected!", vbExclamation
Exit Sub
End If
GetFile (FileName)
'DebugPrintByte FileName, ByteBuffer
eBuffer = RunRC4(ByteBuffer, FileName)
'DebugPrintByte "RC4 Encrypted", eBuffer
Erase ByteBuffer
FileName = FileName & ".edf"
PutFile (FileName)
End Sub
Private Sub Form_Load()
Dim lPtr As Long
For lPtr = 0 To 255
AllBytes(lPtr) = lPtr
Next
End Sub
Private Function RunRC4(bText() As Byte, sKey As String) As Byte()
Dim S() As Byte
Dim NewKey As String
Dim bKey() As Byte
Dim kLen As Long
Dim bTmp As Byte
Dim I As Long
Dim J As Long
Dim lPtr As Long
Dim sLen As Long
Dim bResult() As Byte
S = AllBytes
NewKey = Mid$(sKey, InStrRev(sKey, "\") + 1)
bKey = StrToUtf8(Shuffle(NewKey, False))
kLen = GetbSize(bKey)
For I = 0 To 255
J = (J + S(I) + bKey(I Mod kLen)) Mod 256
bTmp = S(I)
S(I) = S(J)
S(J) = bTmp
Next I
I = 0
J = 0
'DebugPrintByte "Initial", S
'For lPtr = 0 To 3071
' I = (I + 1) Mod 256
' J = (J + S(I)) Mod 256
' bTmp = S(I)
' S(I) = S(J)
' S(J) = bTmp
'Next lPtr
'DebugPrintByte "Cycled", S
sLen = GetbSize(bText)
ReDim bResult(sLen - 1)
For lPtr = 0 To sLen - 1
I = (I + 1) Mod 256
J = (J + S(I)) Mod 256
bTmp = S(I)
S(I) = S(J)
S(J) = bTmp
bResult(lPtr) = S((CLng(S(I)) + S(J)) Mod 256) Xor bText(lPtr)
Next lPtr
RunRC4 = bResult
End Function
Private Function StrToUtf8(strInput As String) As Byte()
Const CP_UTF8 = 65001
Dim nBytes As Long
Dim abBuffer() As Byte
If Len(strInput) < 1 Then Exit Function
' Get length in bytes *including* terminating null
nBytes = WideCharToMultiByte(CP_UTF8, 0&, ByVal StrPtr(strInput), -1, 0&, 0&, 0&, 0&)
' We don't want the terminating null in our byte array, so ask for `nBytes-1` bytes
ReDim abBuffer(nBytes - 2) ' NB ReDim with one less byte than you need
nBytes = WideCharToMultiByte(CP_UTF8, 0&, ByVal StrPtr(strInput), -1, ByVal VarPtr(abBuffer(0)), nBytes - 1, 0&, 0&)
StrToUtf8 = abBuffer
End Function
Public Function Shuffle(sInput As String, flgRev As Boolean, Optional bHex As Byte) As String
Dim bTmp As Byte
Dim bInput() As Byte
Dim iLen As Integer
Dim bKey As Byte
Dim I%, N%
Dim iStart As Integer
Dim iEnd As Integer
Dim iStep As Integer
bInput = StrToUtf8(sInput)
If bHex Then
bKey = bHex
Else
For N% = 0 To UBound(bInput) Step 1
bKey = bKey Xor bInput(N%) + CByte(N%)
Next N%
If bKey = 0 Then bKey = 255
End If
iLen = GetbSize(bInput)
If flgRev Then
iStart = iLen - 1
iEnd = 0
iStep = -1
Else
iStart = 0
iEnd = iLen - 1
iStep = 1
End If
For I% = iStart To iEnd Step iStep
N% = ((bKey Mod (I% + 1)) + I%) Mod iLen
bTmp = bInput(I%)
bInput(I%) = bInput(N%)
bInput(N%) = bTmp
Next I%
Shuffle = Utf8ToStr(bInput)
End Function
Private Function Utf8ToStr(abUtf8Array() As Byte) As String
Const CP_UTF8 = 65001
Dim nBytes As Long
Dim nChars As Long
Dim strOut As String
' Catch uninitialized input array
nBytes = GetbSize(abUtf8Array)
If nBytes <= 0 Then Exit Function
' Get number of characters in output string
nChars = MultiByteToWideChar(CP_UTF8, 0&, VarPtr(abUtf8Array(0)), nBytes, 0&, 0&)
' Dimension output buffer to receive string
strOut = String(nChars, 0)
nChars = MultiByteToWideChar(CP_UTF8, 0&, VarPtr(abUtf8Array(0)), nBytes, StrPtr(strOut), nChars)
Utf8ToStr = Replace(strOut, Chr$(0), "") 'Remove Null terminating characters
End Function
Private Sub DebugPrintByte(sDescr As String, bArray() As Byte)
Dim lPtr As Long
On Error GoTo Done
Debug.Print sDescr & ":"
For lPtr = 0 To UBound(bArray)
Debug.Print Right$("0" & Hex$(bArray(lPtr)), 2) & " ";
If (lPtr + 1) Mod 16 = 0 Then Debug.Print
Next lPtr
Done:
Debug.Print
End Sub
Private Sub GetFile(FileName As String)
Dim iFile As Integer
iFile = FreeFile()
Open FileName For Binary Shared As iFile
ReDim ByteBuffer(LOF(iFile) - 1)
Get #iFile, , ByteBuffer
Close #iFile
End Sub
Private Sub PutFile(NewFile As String)
Dim iFile As Integer
On Error GoTo PutErr
iFile = FreeFile()
Open NewFile For Binary Shared As iFile
Put #iFile, , eBuffer
Close #iFile
Exit Sub
PutErr:
MsgBox "Error: " & CStr(Err)
End Sub
Private Function GetbSize(bArray() As Byte) As Long
On Error GoTo GetSizeErr
GetbSize = UBound(bArray) + 1
Exit Function
GetSizeErr:
GetbSize = 0
End Function
-
Dec 9th, 2021, 06:41 PM
#2
Re: Transmit Executables
But, how do you get this program to your client for decoding?
We could just do a Base64 on the whole thing and paste it in an email, if we could get a Base64 decoder to our client.
Chicken and egg problem.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
-
Dec 10th, 2021, 09:08 AM
#3
Re: Transmit Executables
We usually handle this, in "two steps":
1) Zip the Binaries - and upload such an AppUpgrade_MostRecent.zip to our own Webserver first.
2) Send a (much smaller) Email with just that "Zip-Link" to the customer, informing that a new version is available via https-download.
Olaf
-
Dec 10th, 2021, 09:34 AM
#4
Re: Transmit Executables
Originally Posted by Schmidt
We usually handle this, in "two steps":
1) Zip the Binaries - and upload such an AppUpgrade_MostRecent.zip to our own Webserver first.
2) Send a (much smaller) Email with just that "Zip-Link" to the customer, informing that a new version is available via https-download.
That's actually precisely how I did it for years. It would often take the I.T. department to do the ZIP download, as typical user virus scanners (and/or other filter software) would still scan (and block) that ZIP file upon download because it contained an executable.
But, more recently, my clients have gotten all paranoid about my website getting hacked (which it never has) with some virus getting on things. So, more recently, my primary client (an international hospital chain) has setup a BOX account and given me access to it. IDK what all that BOX account does, but it definitely does a thorough scan of anything you plunk down into it. But it does let my executables through after typically a good 15 second scan.
I know that wouldn't work for everyone. I'm just reporting my experiences.
I certainly don't do any encoding/decoding of my executables though. I'm well trusted, but my clients still get nervous about executables (and I don't really blame them). Going through an encoding/decoding scheme might actually make them more nervous than they already are. I think working through their I.T. departments and/or using something like BOX gives them a level of security they need and deserve.
Just my opinion though.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
-
Dec 10th, 2021, 10:25 AM
#5
Addicted Member
Re: Transmit Executables
G'Day JAC
Thanks for sharing this
Originally Posted by couttsj
I discovered a way to get around the problem of web bowsers (eg. Google Chrome) and mail servers (eg. Gmail) blocking executable files without any notification or bypass method. The servers do not identify potential malware based upon the file extension, but rather on the file format itself. So the logical solution is to change the format.
We have been creating .sas files, I can tell you from 2 decades of doing something similar, so a timed tested approach that this works as designed.
Plus you can provide a PreImageLoader that detokenizes / decrypts / etc. which is another style of 'copy protection' that means virus never get the chance to infect as you can load directly into memory and jmp to IPL address.
It would be gr8 if we could come up with a standard for this type of stuff and then we could create our own 'Image Store' for desktop apps. I know I have 100s, a lot forks of apps. I found often by accident.
For me the hardest part is getting the idea for apps. and the UI as I'm colour ignorant.
-
Dec 10th, 2021, 11:26 AM
#6
Re: Transmit Executables
Originally Posted by Elroy
But, how do you get this program to your client for decoding?
We could just do a Base64 on the whole thing and paste it in an email, if we could get a Base64 decoder to our client.
Chicken and egg problem.
Base64 is available from the command line:
--------------------------------------------------------
certutil -encode setup.exe tmp.b64 && findstr /v /c:- tmp.b64 > data.b64
certutil -decode data.b64 setup.exe
--------------------------------------------------------
I have used this in the past, but this program is faster and more convenient.
J.A. Coutts
-
Dec 10th, 2021, 11:29 AM
#7
Re: Transmit Executables
Originally Posted by Schmidt
We usually handle this, in "two steps":
1) Zip the Binaries - and upload such an AppUpgrade_MostRecent.zip to our own Webserver first.
2) Send a (much smaller) Email with just that "Zip-Link" to the customer, informing that a new version is available via https-download.
Olaf
Zip format worked for a long time, but recently Google Chrome started dropping these as well.
J.A. Coutts
-
Dec 10th, 2021, 11:35 AM
#8
Re: Transmit Executables
Originally Posted by jg.sa
G'Day JAC
Thanks for sharing this
We have been creating .sas files, I can tell you from 2 decades of doing something similar, so a timed tested approach that this works as designed.
Plus you can provide a PreImageLoader that detokenizes / decrypts / etc. which is another style of 'copy protection' that means virus never get the chance to infect as you can load directly into memory and jmp to IPL address.
It would be gr8 if we could come up with a standard for this type of stuff and then we could create our own 'Image Store' for desktop apps. I know I have 100s, a lot forks of apps. I found often by accident.
For me the hardest part is getting the idea for apps. and the UI as I'm colour ignorant.
That's the idea behind this. I intend to add it to PicServer once I have confirmed that the encryption is adequate.
J.A. Coutts
-
Dec 10th, 2021, 11:42 AM
#9
Re: Transmit Executables
Originally Posted by Elroy
I certainly don't do any encoding/decoding of my executables though. I'm well trusted, but my clients still get nervous about executables (and I don't really blame them). Going through an encoding/decoding scheme might actually make them more nervous than they already are. I think working through their I.T. departments and/or using something like BOX gives them a level of security they need and deserve.
Just my opinion though.
If your clients trust you, why can't you supply a hash of the executable, which they can verify on the receiving end.
J.A. Coutts
-
Dec 10th, 2021, 05:59 PM
#10
Addicted Member
Re: Transmit Executables
G'Day JAC
Originally Posted by couttsj
encryption is adequate
Won't this always be a WIP ?
I remember now that 1 of the down streams is the possibility is to grab a .sas or .edf over the WAN, if your apps. don't have a setup .exe and use .ini ( this is due to legacy ) for persistence not registry / .mdb ( DB ) etc. then you can have what I called wApps ( WAN Apps ) so icons on your desktop in the Preloader are configured, but not installed in the traditional sense
When I was doing this originally the WAN was way to slow, now an image is so small compared to the movies / vids. we are all DLing ( Streaming )
You might want to think about opening up the scope now even if you don't want to use this design for years.
BTW - I never install in any M$ folders always under SAS\Apps\ so viruses cannot easily get a full list of the PCs apps., and obviously per loader checks this folder for icons of wApps
Last edited by jg.sa; Dec 10th, 2021 at 06:27 PM.
-
Dec 10th, 2021, 07:02 PM
#11
Re: Transmit Executables
Originally Posted by Elroy
It would often take the I.T. department to do the ZIP download,
as typical user virus scanners (and/or other filter software) would still scan (and block) that ZIP
Since Windows-defender became a decent tool (starting already in the Win8.1 era),
I'm not seeing that kind of thing (false positive alarms) that often anymore.
Most of our customers run Win10 - and even the Admins in the Offices in the meantime know,
that installing "Avast" or some other of the "cheaper" Virus-Scanners cannot compete with Win-defender anymore.
So they leave the machines running the (preinstalled) Win-defender these days
Originally Posted by Elroy
But, more recently, my clients have gotten all paranoid about my website getting hacked ...
So, more recently, my primary client (an international hospital chain) has setup a BOX account
Hmm, BOX is "web/cloud-stuff", provided by "just another vendor" - so your customers apparently trust them more,
than they trust you (or your "due diligence", e.g. checking zips for Viruses on VirusTotal before uploading)?
That's a crazy thing to do, because - in the end - they *have* to trust you far more,
because it is *your* executables which will run in their Network (able to do a huge amount of harm, if it was otherwise).
So, since they (have to) trust you "fully and implicitely" anyways, all they have to do
(after downloading from "anywhere"), is whether the "Files they are about to put onto their LAN-Disks",
are exactly the same Files you put into the Zip...
And it was already mentioned, that e.g. a FileHash for your Zip
(ideally transferred to your customers on a different channel),
can help with "trusting your Binaries" just fine, since it gives the customer a *guarantee*,
that they look at the same Zip you've "build" locally on your Dev-machine (when they compare Hashes).
As for "site-hacking"... small Websites (from small vendors) usually have an advantage,
because they usually "fly under the radar" (from a Hackers point of view).
When you hear about "Site-Hacks" in the news, it's almost always about "the big vendors"
(which are more "juicy targets" to them).
... does not mean, that you should neglect securing your own website of course ...
@couttsj
You say, that Google/Chrome is not downloading Zip-Files with Executables anymore...
Hmm, put that to the test just now (I know, that Firefox works just fine with "Zips that hold Exes" already)...:
So, on an up-to-date Win10, with an up-to-date Win-defender, with a fresh installed Google/Chrome -
I had absolutely no problem, downloading such Zips from vbRichClient.com (tested in both, http and https-mode) -
and it also downloaded these Zips just fine from our company-website...
So I cannot really see what problem you're trying to fix here.
Olaf
-
Dec 10th, 2021, 09:22 PM
#12
Re: Transmit Executables
I use Proton mail occassionally. Which is a very secure email provider. Not that that is relevant to what I am about to suggest (but a nervous client would get a warm feeling if they googled Proton).
Could one set up a proton account, and share it with a single client. ('Share' meaning you set it up, and the user can log in to it.) Send an email to that account, with the zipped exe attached. Let the client know that there is something in the Proton acount, and they can log in, and download the zip.
Not sure if that avoids/solves all the issues raised in this thread, but I thought I would throw in the suggestion.
Rob
-
Dec 10th, 2021, 09:33 PM
#13
Addicted Member
Re: Transmit Executables
G'Day Rob
Originally Posted by Bobbles
but a nervous client would get a warm feeling if they googled
I know exactly what you mean we use #NoSpamAccepted so we tell clients that we use #NSA for email so that gives them a Warm & Fuzzy as well
But, when we tell them it is only avail. to .gov.au or gov.nz that is not so good !!!
-
Dec 10th, 2021, 09:37 PM
#14
Hyperactive Member
Re: Transmit Executables
Originally Posted by Schmidt
So, on an up-to-date Win10, with an up-to-date Win-defender, with a fresh installed Google/Chrome -
I had absolutely no problem, downloading such Zips from vbRichClient.com (tested in both, http and https-mode) -
and it also downloaded these Zips just fine from our company-website...
Well, I have Win10 and now I can't download from vbRichClient with Opera (chrome based). Have no problems with firefox.
-
Dec 11th, 2021, 02:36 AM
#15
Re: Transmit Executables
Originally Posted by Schmidt
@couttsj
You say, that Google/Chrome is not downloading Zip-Files with Executables anymore...
Hmm, put that to the test just now (I know, that Firefox works just fine with "Zips that hold Exes" already)...:
So, on an up-to-date Win10, with an up-to-date Win-defender, with a fresh installed Google/Chrome -
I had absolutely no problem, downloading such Zips from vbRichClient.com (tested in both, http and https-mode) -
and it also downloaded these Zips just fine from our company-website...
So I cannot really see what problem you're trying to fix here.
Olaf
This all started when I attempted to send an associate a copy of PicServer to test. I first of all zipped it and emailed it to him. Unfortunately he used Gmail, and it was silently dropped. It was not in spam and there was no record of it ever having been received. So then I put it onto our server and sent him the link. When he used Google Chrome, it informed him that the file was dangerous and could not be downloaded. I instructed him to use FireFox, and everything went fine. The fact that the server was not a secure server (HTTP only) may have something to do with that. For subsequent fixes, I used the Base64 trick.
J.A. Coutts
Last edited by couttsj; Dec 11th, 2021 at 02:44 AM.
-
Dec 11th, 2021, 04:41 AM
#16
Addicted Member
Re: Transmit Executables
G'Day Olaf
I have experienced the same issue as JAC - No Delivery , No Errors , No Idea W* T* F* is going on
Originally Posted by Schmidt
That's a crazy thing to do, because - in the end - they *have* to trust you far more,
because it is *your* executables which will run in their Network (able to do a huge amount of harm, if it was otherwise).
B U T
If that image has been infected, is it still *your* exe ???
These issues evaporate if the image cannot be infected with JACs design !!!
With our SAS design, the image never exists .local
No hacker is able to 'covid' a file that is not persistent
-
Dec 11th, 2021, 04:59 AM
#17
Re: Transmit Executables
Originally Posted by Schmidt
So, since they (have to) trust you "fully and implicitely" anyways, all they have to do
(after downloading from "anywhere"), is whether the "Files they are about to put onto their LAN-Disks",
are exactly the same Files you put into the Zip...
And it was already mentioned, that e.g. a FileHash for your Zip
(ideally transferred to your customers on a different channel),
can help with "trusting your Binaries" just fine, since it gives the customer a *guarantee*,
that they look at the same Zip you've "build" locally on your Dev-machine (when they compare Hashes).
This is exactly the problem proverbial code-signing certificates try to solve without side-channels for the hashes.
Nevertheless we always produce checksums.md5 file for our nightly builds which is used by the boot-strapper at client-side to consistency check locally downloaded build for corruption (and re-download if so).
Code:
906A807D0E348B33E2BDE9718B9ED703 *Dreem.exe
31AD9F2198027B2BCD1885F24DEF315C *Dreem.chm
2FC3F4E79C05B69B60EE8385586E422B *Dreem.pdb
A6405C7B94B12EA19F895D0603EE24B9 *DreemAcc15.ocx
0CACD94A1FD325E34E1B5786E6606457 *DreemAcc15.pdb
0F8AE169051780ACE37861BFD4FAB718 *DreemCm15.ocx
63B9E11276E33395731B0A500DDA378B *DreemCm15.pdb
...
38E31CBA59B0E4586A73E5C5DC174A97 *External\UcsFP20.dll
D48C6042D66A6C3F559D3F6F3AAF6871 *External\UcsStackWalk.dll
1B32A483B9A754908B75015EB514C4DF *External\UniCCtl.ocx
This is a standard chechsums file format used in linux-land which can be produced/consumed by HashCheck shell extension too.
cheers,
</wqw>
-
Dec 11th, 2021, 06:44 AM
#18
Re: Transmit Executables
I just checked and I can download from the web zip files that contain exes inside using Chrome.
I Just checked from one of my websites now and it downloaded.
(are you able to download from there?)
I don't remember that I did any special configuration in Chrome (I usually use FireFox).
Anyway, how are the independent developers supposed to work, do they need all to put their programs in Microsoft Store (and any single update)?
-
Dec 11th, 2021, 07:08 AM
#19
Addicted Member
Re: Transmit Executables
G'Day Eduardo
Originally Posted by Eduardo-
Anyway, how are the independent developers supposed to work
Does M$ concern themselves with Ind. Dev. anymore ???
Originally Posted by Eduardo-
do they need all to put their programs in Microsoft Store (and any single update)?
I have no idea, but I thought that is what you are supposed to do
This why I never use setup.exe's only configure routines inside the .sas files if required on image IPL
It would be gr8 if we could use Edge Servers and have our own what I call 'Image Store'
A bit like Napster for desktop apps, but only apps written in VI and not using .NET bloatware
Just my 2c worth
-
Dec 11th, 2021, 07:31 AM
#20
Re: Transmit Executables
Originally Posted by jg.sa
G'Day Eduardo
Good day,
Originally Posted by jg.sa
Does M$ concern themselves with Ind. Dev. anymore ???
I don't think so.
I think that big companies want everybody to work for them. A world full of slaves. But that would be a talk for the Chit-Chat forum.
Originally Posted by jg.sa
This why I never use setup.exe's only configure routines inside the .sas files if required on image IPL
That could work in case of inside company distribution, or with already trained people, but not with new potential clients that find your program through the web.
They find your web site, see that your program is available, and then? (call you so you go to their homes to install the program?)
Originally Posted by jg.sa
It would be gr8 if we could use Edge Servers and have our own what I call 'Image Store'
A bit like Napster for desktop apps, but only apps written in VI and not using .NET bloatware
Just my 2c worth
Also, it seems something for internal use of companies, not for normal users.
-
Dec 11th, 2021, 10:05 AM
#21
Re: Transmit Executables
Originally Posted by Carlos Rocha
Well, I have Win10 and now I can't download from vbRichClient with Opera (chrome based). Have no problems with firefox.
I think that's a different problem, having its cause in how I've defined the "<a href=" attributes of the download-links -
which were given as fully qualified URL - leading with "http://".
And that's what Chrome (or chromium) complains about recently, when you navigated to the site via https://...
I've fixed this now, by leaving protocol and domain out of the Download-URLs,
meaning reduction to e.g.: href="/downloads/RcBase-bla.zip" will then automatically "do the right thing",
no matter if you navigated to the website via http:// or https://.
HTH
Olaf
-
Dec 11th, 2021, 10:18 AM
#22
Re: Transmit Executables
Originally Posted by jg.sa
If that image has been infected, is it still *your* exe ???
I've already addressed that in my first post (when you read the section about Hashes).
No "special designs" are needed for that -
just one of the "considered secure" Hash-Algos (as e.g. SHA256) would be enough.
In addition you might want to read wqwetos reply as well...
Olaf
-
Dec 11th, 2021, 09:51 PM
#23
Addicted Member
Re: Transmit Executables
G'Day Eduardo
Originally Posted by Eduardo-
I 100% agree, in Australia you are forced to Volunteer if you want to get financial support when u are unemployed.
Originally Posted by Eduardo-
I was told when I work for Gov. Dept. Centrelink who pays the benefits that Gov. does not want you to have your own business, Bills ( Billionaires ) who pay $$$s to Political Parties in Oz., but we are not allow to know who or how much, need more and more slaves because they have lots of expenses, I'm guessing paying political parties heaps of c$$h is right up there in the expenses list
So around and around we go, a few getting richer and richer while the slaves are struggling to pay their own bills. When I analysed this system I have come to this conclusion, in the richest country in the world we are paying people who are not living in Australia billions of dollars in welfare, because they tell our Politicians that they are going to employ Ozzies in the future.
Originally Posted by Eduardo-
That could work in case of inside company distribution, or with already trained people, but not with new potential clients that find your program through the web.
They find your web site, see that your program is available, and then? (call you so you go to their homes to install the program?)
Also, it seems something for internal use of companies, not for normal users.
It works for site DL as well, but must be .exe not .sas and they need to fill in a configuration form on initial load, which is part of the .exe and these details are stored in .ini's and emailed ( ET Phone Home )
We then ask for more details after 10 image activations, because we are thinking they are wanting to take advantage of 'all' the facilities and are past eval. period.
Last edited by jg.sa; Dec 12th, 2021 at 07:28 AM.
-
Dec 12th, 2021, 07:53 AM
#24
Re: Transmit Executables
Originally Posted by jg.sa
I 100% agree, in Australia you are forced to Volunteer if you want to get financial support when u are unemployed.
This topis is OT here, but I just want to point that I think that it is right to ask for a service (work) when the people are receiving help from the state.
In Argentina it is the contrary and now we have generations of people that never worked.
Of course the economy goes nowhere with those ideas.
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
|