File binder

[Skitty]

For some reason, when I want to extract the data from the impregnated executable, the resulting file is smaller than the original file that was used.

I can't run the file after extracting it from the file holding the data... although the impregnated file still works nicely..

How can I fix this?

I'm guessing that the data being retrieved is to big at on point so it isn't stored to the variable or something.

expandcollapse popup

$1 = FileOpenDialog("Select victim",@DesktopDir,"All (*.*)" )
_TAKEOWN($1)
If Not FileMove($1,@DesktopDir & "\Data",1) Then
    MsgBox(0,">:(","Error moving file...")
EndIf
$2 = FileOpenDialog("Select data to append",@DesktopDir,"All (*.*)" )
$OP1 = StringSplit($2,"\")
$OP2 = UBound($OP1) - 1
$F2O = FileOpen(@DesktopDir & "\Data",1)
$OP = FileOpen($2)
$RD = FileRead($OP)
FileWrite($F2O,@CRLF & ";#START-" & @CRLF)
FileWrite($F2O,$RD)
FileWrite($F2O,@CRLF & ";#END-" & @CRLF & $OP1[$OP2])
FileClose($F2O)
FileClose($2)
;MsgBox(0,"Done","Optionally, you can check to see if the data was successfully written." & @CRLF & "Else, just press ok.")
FileMove(@DesktopDir & "\Data",$1,1)

MsgBox(0,":)","Done." & @CRLF & "Now lets get that data back!")

$File = FileOpen(FileOpenDialog("Select file to extract data from...",@DesktopDir,"All (*.*)"))

$Status = 0
While 1
    $line = FileReadLine($file)
If @error = -1 Then
    ExitLoop
Else
If $line = ";#START-" Then
    $Status = 1
EndIf
If $Status = 1 Then
    If $line = ";#START-" Then ContinueLoop
    If $line = ";#END-" Then
        $Name = FileReadLine($file)
        $Sp = StringSplit($Name,".")
        $Ub = UBound($Sp) - 1
        FileMove(@ScriptDir & "\Data",@ScriptDir & "\" & $Sp[1] & " - Copy." & $Sp[$Ub])
        Exit
    EndIf
    _CREATE($line)
EndIf
EndIf
Wend

Func _CREATE($Data)
    $F = FileOpen(@ScriptDir & "\Data",1)
    FileWrite($F,$Data & @CRLF)
    FileClose($F)
EndFunc

Func _TAKEOWN($File)
    If StringInStr($File, " ") Then
        $I1 = 0
        while 1
            If $I1 >= 3 Then ExitLoop
            RunWait('TAKEOWN /F "' & $File & '"',"",@SW_HIDE)
            Sleep(2000)
            run('icacls "' & $File & '" /grant *S-1-1-0:(D,WDAC)',"",@SW_HIDE)
            $I1 += 1
        WEnd
    Else
        $I2 = 0
        While 1
            If $I2 >= 3 Then ExitLoop
            RunWait('TAKEOWN /F ' & $File,"",@SW_HIDE)
            Sleep(2000)
            run('icacls ' & $File & ' /grant *S-1-1-0:(D,WDAC)',"",@SW_HIDE)
            $I2 += 1
        WEnd
    EndIf
    FileSetAttrib($File,"-RASHNOT")
EndFunc

Be careful when using it, recommend you have common sense 2011 running while you're using this..

Edited February 25, 2011 by System238

[Skitty]

So I've finally asked a question that can't be answered?

No, I doubt it...

Some one got any advice?

How do I store ridiculously large amounts of binary data to a variable?

[PsaltyDS]

The script, functions, and your description look malicious. Why pick a "victim"? Why include icacls to delete group EVERYONE perms to the file? Why post something unsafe and then have to warn people about running it?

Not with a ten foot pole...

[lionfaggot]

its people like you who ruin autoit and get it detected by runtime scans for people like me, seriously, fuck off. because of people like you all my fanbase say my programs are malware.

[SmOke_N]

What the heck is an "impregnated" file?

[Skitty]

What the heck is an "impregnated" file?

It means I'm hiding data in a file, and to the others, thanks for thinking that I am even remotely capable of creating maleware that would cause Autoit to be detected by an antivirus.

I felt smart there for a second.

Edit: To be more informative, my mission is to create an executable that stores Files in itself. and then retrieve them when you want to.

And what I wanted to do was have my executable store another executable in itself and summon it whenever you choose.

I sorta have this working except that the summoned binary data is useless.

Edited February 26, 2011 by System238

[SmOke_N]

Because you're trying to treat binary data like text data ( both reading and writing ).

( Well, from at least your example, you don't open anything in binary mode )

Edit:

A few things pop to mind from your above comment.

FileInstall()

Zip

Rar

7z

The above options could prove to be more viable for something like that .... no?

Edited February 26, 2011 by SmOke_N

[Skitty]

Because you're trying to treat binary data like text data ( both reading and writing ).

( Well, from at least your example, you don't open anything in binary mode )

Edit:

A few things pop to mind from your above comment.

FileInstall()

Zip

Rar

7z

The above options could prove to be more viable for something like that .... no?

Yeah it probably would, but what I'm trying to do is create a variation of FileInstall(), except that this would enable my executable to install files into itself after it's been compiled.

This way, I can have a single executable that would store executables like Procexp.exe, which is the only file I've been testing this on.

Using Trancxx's Run Binary script, It's possible to create such an executable that would sort of edit itself and run binary data from the executable in question after creating a temporary file of the binary data.

This isn't a high priority subject at all, it's just a little something that I thought would be interesting to try, and it's almost working except that I haven't been opening anything in binary read mode as you said, which may be why some binary file's result in being a few bytes smaller than the original..

I'll try this and post my results when I'm done, and if it works, I'll post the code here I guess.

Edit: I tried and failed.

It didn't work, reading and writing with 17 as an option in fileopen().

Edited February 27, 2011 by System238

[SmOke_N]

Your idea really seems silly to me.

Why would one need 30 exe's that could be extracted in memory and ran without being extracted onto the physical disk ( only reason I can see you doing this )?

The weight of the files are still within the initial exe, in fact, with all the extra data you'd need, it'd be larger.

Not saying it's impossible, but you'd have to set start and end pointers, and know how to handle the binary in memory.

If you had issues reading/writing binary data, I'd imagine this being a big feat for you.

I doubt you'll get much help seriously with it, this type of feature/information, no matter your intent, is not something that should be floating around for any ole' script kiddie to get a hold of.

Edited February 27, 2011 by SmOke_N

[Skitty]

Your idea really seems silly to me.

Why would one need 30 exe's that could be extracted in memory and ran without being extracted onto the physical disk ( only reason I can see you doing this )?

The weight of the files are still within the initial exe, in fact, with all the extra data you'd need, it'd be larger.

Not saying it's impossible, but you'd have to set start and end pointers, and know how to handle the binary in memory.

If you had issues reading/writing binary data, I'd imagine this being a big feat for you.

I doubt you'll get much help seriously with it, this type of feature/information, no matter your intent, is not something that should be floating around for any ole' script kiddie to get a hold of.

Yeah, I guess it is pretty silly after all..

*moving on to something else...*