Home Upgrade Search Memberlist Extras Hacker Tools Award Goals Help Wiki Contact

.NET 

Folder Encryption / Source released!

Greetings all!

I've been working up a new application and figured I would release it here for all of you that might find it usefull! If you do use this program please leave some feadback, I'd like to hear what you think, and it will encourage me to keep developing this project! And just to clarify, I did get the idea from this post: https://hackforums.net/showthread.php?tid=4888596, but I'm to lazy to convert the code, so I just made my own version with my twist on it :)

The general Idea of the program is this: You chose a folder, and the folder is encrypted and all the data is stuffed into a "Files.Encrypted" in the same directory as the program. Then after you've done that, create a decryption stub, this stub is only compatable with that "Files.Encrypted" file, they both have the same salt packed inside, and will only work with eachother. Then when you want to unpack the files, run the unpack stub, enter the password it was created with, and it will place the files like they were in the folder, inside a folder located in the same directory as the application called "Decompressed".

Some key features are:
- Always uses 256-bit AES
- As secure as possible (uses standardized algorithms)
- "Polymorphic" / unique output (CBC cipher mode with random IV)
- Minimal RAM overhead. (Writes as it reads)
- No critical information is stored inside the stub

Photos:
Spoiler (Click to View)

https://github.com/Icemantheditor/FolderEncryption
I have replaced the DL link to the repository on my github, if you don't want to waste time compiling it, there is a pre-compiled binary inside of bin/Debug/FolderEncryption.exe
Very good job!

but quick suggestion You SHOULD let the user pick a password or randomly generate it
(Jul 5, 2015 08:56 PM)VmX5 Wrote:  Very good job!

but quick suggestion You SHOULD let the user pick a password or randomly generate it

It is randomly picked, the problem is the password has to be 32 characters long, I guess I could just add say x's to get a short password up to length, and chop long passwords to length behind the scenes to simplify it for the end user.
I have a few suggestions for you.
1) Compression. Like gzip
2) Store the data inside the decrypter. (makes it easier to move around / share)
3) when you start the decrypter have it prompt for the password, that way you cant reverse engineer it to get the password
(Jul 5, 2015 10:03 PM)Hoody Wrote:  I have a few suggestions for you.
1) Compression. Like gzip
2) Store the data inside the decrypter. (makes it easier to move around / share)
3) when you start the decrypter have it prompt for the password, that way you cant reverse engineer it to get the password

I've tried Gzip and it didn't help, it actually increased size. I was thinking about that, however people might want to have them separate. And it is like that, the password isn't stored in the stub.
(Jul 5, 2015 10:15 PM)taktaktak Wrote:  I've tried Gzip and it didn't help, it actually increased size. I was thinking about that, however people might want to have them separate. And it is like that, the password isn't stored in the stub.

hmm, ok then :P

well, for gzip. You have to zip the data before you encrypt it, else it will inflate.
(Jul 5, 2015 10:21 PM)Hoody Wrote:  hmm, ok then :P

well, for gzip. You have to zip the data before you encrypt it, else it will inflate.

Idk about that, how would I zip a string? Because if you're talking about ziping the file, some can get very very large, to large to read in one string because it would exhaust all memory and throw an exception, so it would have to happen as I write it. And I've tried 3 different methods of gzip ing strings and they all inflated the file size.
(Jul 5, 2015 10:26 PM)taktaktak Wrote:  Idk about that, how would I zip a string? Because if you're talking about ziping the file, some can get very very large, to large to read in one string because it would exhaust all memory and throw an exception, so it would have to happen as I write it. And I've tried 3 different methods of gzip ing strings and they all inflated the file size.

Oh god i cant even remember the last time i used gzip. But from what i recall, you can use a stream and just feed it 10kb or so at a time. So read to the buffer, pass to the stream, dispose the buffer, repeat.

Also, after coding in C for a while. I cringe at the word "string". lol use a byte array :) haha or char* if ya know what i mean ;)
(Jul 5, 2015 10:33 PM)Hoody Wrote:  Oh god i cant even remember the last time i used gzip. But from what i recall, you can use a stream and just feed it 10kb or so at a time. So read to the buffer, pass to the stream, dispose the buffer, repeat.

Also, after coding in C for a while. I cringe at the word "string". lol use a byte array :) haha or char* if ya know what i mean ;)

Hmm sounds interesting, and simple enough, I'll have to give it a shot. And sadly I have a little experience in c++ so kinda :P
(Jul 5, 2015 09:57 PM)taktaktak Wrote:  It is randomly picked, the problem is the password has to be 32 characters long, I guess I could just add say x's to get a short password up to length, and chop long passwords to length behind the scenes to simplify it for the end user.

The password does not need to be 32 characters.
either use PasswordDeriveBytes or hash it to 32 bit.
Lotta blood to let, peace to make, give a fuk about a check
(Jul 5, 2015 10:39 PM)BahNahNah Wrote:  The password does not need to be 32 characters.
either use PasswordDeriveBytes or hash it to 32 bit.

Actually you just reminded me that I switched encryption methods, I totally forgot to update that, thanks I suppose.
(Jul 5, 2015 10:39 PM)BahNahNah Wrote:  The password does not need to be 32 characters.
either use PasswordDeriveBytes or hash it to 32 bit.

But. Bannawwa (hard W)

you sure you mean 32 bit? thats.. 4 bytes... like 0x12345678
tbh im talking out of my ass. but for real. i doubt they have a 32bit password
(Jul 5, 2015 10:45 PM)Hoody Wrote:  But. Bannawwa (hard W)

you sure you mean 32 bit? thats.. 4 bytes... like 0x12345678
tbh im talking out of my ass. but for real. i doubt they have a 32bit password

I dont remember. I know that one of the key sizes for Rijndael is the same as an MD5 hash (128 bits i think).
Lotta blood to let, peace to make, give a fuk about a check
(Jul 5, 2015 10:47 PM)BahNahNah Wrote:  I dont remember. I know that one of the key sizes for Rijndael is the same as an MD5 hash (128 bits i think).

well.. i think hes using aes256? im too lazy to check the OP. but if so. lets do some math :)

bit / 8 = byte

now you see bannawwa.

Code
___32_
8|256
  24
   16
   16
    0

256 / 8 = 32

so OP here needs to use 32 characters.
(Jul 5, 2015 10:55 PM)Hoody Wrote:  well.. i think hes using aes256? im too lazy to check the OP. but if so. lets do some math :)

bit / 8 = byte

now you see bannawwa.

Code
___32_
8|256
  24
   16
   16
    0

256 / 8 = 32

so OP here needs to use 32 characters.

(Surprise that's what I said)


(Jul 5, 2015 10:55 PM)Hoody Wrote:  well.. i think hes using aes256? im too lazy to check the OP. but if so. lets do some math :)

bit / 8 = byte

now you see bannawwa.

Code
___32_
8|256
  24
   16
   16
    0

256 / 8 = 32

so OP here needs to use 32 characters.

I tried adding in your gzip and it was just giving me trouble, if people want to compress the data then ill just let them do it with a third party program.


Possibly Related Threads...
Thread / Author Replies Views Last Post
[.NET] by Weakky.Mar 29, 2017 03:21 PM 137 4,958 Mar 29, 2017 03:21 PM
Last Post: Mustys
[C#] by FileBossJan 2, 2016 08:28 AM 2 174 Jan 2, 2016 08:28 AM
Last Post: He B TeMy
[Shell] by JOWOct 3, 2015 10:33 PM 2 169 Oct 3, 2015 10:33 PM
Last Post: BackTrack161