Increase .exe file size

[Pricehacker 0]

Hello!

I want to make a script that changes the filesize of program files while still having them run as usual.

I tried FileWrite() but then the program wouldnt be recognized as a runnable program, could you guys help me to the right path?

[Jos 2,163]

Why would you want to do this?

[FrancescoDiMuro 403]

@Jos

He wants to conquer the World with a mastodontic .exe file.

P.S.: I was sarcastic.

Edited August 28, 2018 by FrancescoDiMuro

[careca 277]

Is this considered as a mod working on a thread, or can i answer?

[JLogan3o13 1,620]

Yes, it is considered as a Mod working in a thread. Please wait.

[Pricehacker 0]

Not sure what "Mod working in a thread" means but the reason i want to make exe files bigger is becouse i want to store information at a "secret place" eighter by reading from the exe file afterwards, or by looking at the file size and using that as a source of information to store a short string lika a password.

Also thanks for trying to help guys!

[Melba23 3,396]

Pricehacker,

Quote

Not sure what "Mod working in a thread" means

Then read this announcement.

M23

[Melba23 3,396]

Pricehacker,

One way to do what you want is to use Alternate data streams (ADS) - I believe that there are some examples on the forum on how to use AutoIt to with them. But as this method has been used for malware in the past and is not necessarily transferrable between machines, I would counsel against its use as it is likely to be more trouble that it is worth.

M23

[JLogan3o13 1,620]

I would agree with Melba, any AV product worth its salt is going to do a checksum of executables against any binary-appending of data. Most of the time if you do this it goes into the package.nw and is easily detectable. Even if it doesn't go there, it is going to change the hashsum, which will be detected.

And if you have to go to those lengths to get around AV detection, you're really beginning to stumble into the gray area between legitimacy and malware.

[iamtheky 927]

if you are just shooting for security by obscurity, seems it would be easier to reshack a dependency or bury it in the metadata.  You still have to write a script that tells everyone where it is in order to use that string, so where you put it matters very little to a determined attacker, imho.

[careca 277]

Huh.. green light to answer?

[rudi 31]

• Use a FileInstall() with some file meeting your size needs
• define a huge string variable in your script, filled with  RANDOM characters.

And  that with "Mod Team working on a thread", I'm not sure, if I get this 100%...

 

I assume, that this means, don't help, while the moderator's team is discussing, if a question is apropriate or prohibited. As Melba and Logan were putting valuable answers to the orignal question, I assume, we are past this "is-it-legitim-discussion"

 

Regards, Rudi.

[Somerset 3,038]

This topic is borderline negative behavior, that almost always leans towards suspicious activities.

They are trying to conceal a malicious file for ill intent.

File hidden from either a program, or person.

File storage in a compression state.

Data storage is another possibility, but that too is suspicious.

[iamtheky 927]

or storing a product key, or a hardcoded password.....   Also, any target a payload of this manner would work on could get rekt without all the legwork.  Now if he said the D word or any of the keywords about putting it back together, then its piledriver time.

 

I do love your cynicism though, im jealous, it seems healthy and well cared for.  I have started leaning more towards:

Don't attribute to malice, that which can be attributed to coding some shit in the jankiest way possible because i had a bad idea that ended up working. 

[rudi 31]

If you want to *CHECK* a password, a user has to put in on program startup, don't store the password itself, but it's hash code:

 

#Region Password Check
$PWD = ""
$PW_hash = "0x83CA415F8BA7FCE3163736F7BB472DA7F307B832"
Do
    $PWD = InputBox("Password Check", "enter your password", "", "*")
Until $PWD <> ""
_Crypt_Startup()
$Hash_Input = _Crypt_HashData($PWD, $CALG_SHA1)
If $Hash_Input <> $PW_hash Then
    MsgBox(64, "Wrong Password", "Please type your password again, the SHA1 Hash calculated doesn't match!", 10)
    Exit
EndIf
_Crypt_Shutdown()
#EndRegion

That way the user cannot retrieve your password from the compiled EXE, but *YOU* can verify, he/she knows it.

 

Regards, Rudi.

[Pricehacker 0]

Not exactly what i was looking for but that doesnt matter as encrypting the password is probably much safer anyways.

Thanks to all of you for your help!