xp2KeyCrypt 1.4.1 Final - August 12, 2013

A collection of especially useful xplorer² topics and ideas. New users may find it helpful to look here before searching the other forums for information. >>>>>> Please post new material in the relevant forum. (New stuff posted here will be removed.) Thanks. -fg-

Moderators: fgagnon, nikos

Enternal
Member
Member
Posts: 54
Joined: 2013 Aug 03, 05:28

Re: xp2KeyCrypt 1.3 Final (Unicode) - August 5, 2013

Post by Enternal » 2013 Aug 08, 18:23

Kilmatead wrote:But considering that EndCleanup() is nothing more than a removal of the 7za.exe, it looks rather like the Wipe() is executed regardless of a successful integrity check or not. I haven't intentionally created a fail-state to check it yet (in case PB is sneakier than I thought), but it doesn't look right.
Oh! I forgot the END statement. Looks like my sleepiness got to me :lol: The END statement is going to be inside the EndCleanup() so it's going to be like the original END statement but also remove 7za.exe become actually ending.
Kilmatead wrote:Also, just after that (when setup is complete), you conveniently re-launch the program to save the user the trouble of clicking the shortcut again, except you forgot to pass any initially given arguments. Ain't minutia fun?
*sigh I did not even think about this lol. Got to add this now too heh.
Kilmatead wrote:I have no doubt that many anti-virus toys will just love the idea of your binary unpacking another binary just to execute it - usually that sort of thing is reserved for static resources or DLL's. There's nothing wrong with doing it, and it is "cleaner" - but there may be pitfalls. :shrug: On that same theme, if you're still playing with UPX compression, you'll note that that's one of the main causes of AutoIt/AHK scripts being flagged as evil-doers...
You hit exactly what I was most worried about when I woke up this morning. If I don't use APX, the file size for xp2KeyCrypt is like 700 KB. Kind of big. On the other hand, if I keep them separate like I did before, the UPX version of 7za does not trip any sort of virus flags (virustotal.com) and my own executable only trip 4 for being a packer. But if I combined them... it might be troublesome. However the results from virustotal are kind of positive but not sure yet haha. The heuristic might make it different.
EDIT: I'm doing it this way now. UPX the 7za.exe executable and leave my program alone.
https://www.virustotal.com/en/file/a1e1 ... 375985143/
https://www.virustotal.com/en/file/0e57 ... 375985253/
So yeah, I might not go for it then. Going to have think more about it. On the other hand, X2.DAT being a 7-zip file is even less apparent with this method. Unless they pay attention now lol. Of course in terms of security, that means nothing.

Anyway I updated the binaries but it does not need testing I think. It's pretty much just that END statement being added so it's rather minor. I work on the other stuff later today when I get hope again haha.
EDIT: Ok. Now when you finish the first time encryption, it should now send the command-line arguments as well.
EDIT2: Link removed. The new executable and source is now in the first post.
Kilmatead wrote:Regrettably x2's "scripting" is indeed a limited affair, forcing us to be more inventive than your average litter of kittens. Having an open and practical API is one of those things that never seemed to dawn on Nikos, and x2 suffers for it - but such is life. Considering that file managers are niche-products anyway, the actual percentage of users who would delve to such a level is virtually non-existent - so it's kind of a chicken-vs-egg argument. He did not exactly imagine 10 years ago when x2 was initially pushing kicking and screaming into this life that weirdo's like myself would be messing with its entrails. :shrug:

xyplorer's quite impressive for a manager written in basic, but it can never seem to get away from the "shiny" impression of too many niche-requests being granted for the sake of customer relations, and not enough attention brought to the depth of the shell itself. The same applies to x2 in reverse - a little more thought put into fluffy GUI nonsense (because people like their fluffy) wouldn't hurt. But that's just my opinion - at the end of the day all file managers essentially do the same thing and the users are just quibbling about the paint-job. Besides, we're not here to play comparison games, enough of that goes on elsewhere. (Although I will point out that your own xyKeyCrypt seems to have suffered a lukewarm reception so far on that forum - no discussions of assembly, no humor, no suggestions... where's the fun? You'll need to work harder to wake them up, the grumpy bunch. :wink:)
Hahaha I feel down on XYplorer's forum for XYKeyCrypt. No feedback whatsoever :(. They don't seem to be interested in encryption in general though so two of my scripts (I wrote the other one in XY's language) that had to do with encryption did not get much reception. My other scripts get a lot of more response and help. *sigh Oh well, I'm going to force it out of them and be blunt about it "hey I need feedback!" :twisted:.

Actually Don's rather hard about implementing features lol. We have to spend a lot of time and prove to him that the feature is productive and is easy to use with customers that are now power users. If we can't convince him, we don't get the feature lol. It took us years before he finally agreed that basic zip support is useful. But yeah, I think it's extremely amazing how stable and good the program is yet it's written in Visual Basic. He fully prove that it's the programmer is the one that can work the magic with any language. On the other hand, the compiler is still an issue and therefore haven't figure out a good way to implement multi-threading and x64 version so that will continue to be the wall. It's expected though, all file managers have their own issues. Directory Opus is really really good but portability is a pain. And... it's huge. Very huge. But it's good! But it's huge. xplorer2 and XYPlorer are the lightweight ones and are the fun ones to take with you everywhere you go. Got stuck on a deserted island? Don't worry, you have xplorer2 and XYplorer ready to help you... and XYplorer can make coffee in the morning too if you need that.
Last edited by Enternal on 2013 Aug 12, 20:17, edited 1 time in total.

Enternal
Member
Member
Posts: 54
Joined: 2013 Aug 03, 05:28

Re: xp2KeyCrypt 1.4 Final - August 12, 2013

Post by Enternal » 2013 Aug 12, 20:16

Ok. I'm now finished with this. Thank you for everything and have fun with it! Bye bye!

Kilmatead
Platinum Member
Platinum Member
Posts: 4569
Joined: 2008 Sep 30, 06:52
Location: Dublin

Re: xp2KeyCrypt 1.4 Final - August 12, 2013

Post by Kilmatead » 2013 Aug 12, 21:58

Michael Corleone wrote:Just when I thought I was out... they pull me back in.
Bugger - I didn't read the last source accurately enough - if I had, I would have discouraged you from this:
Enternal wrote:* Remove OSBit check and used a simpler more efficient check. It simply runs xplorer2_64.exe if found and otherwise, will just use xplorer2_UC.exe
There is a very good reason this is an extremely bad idea - as the x2 binary comes in two formats it is recommended that the portable-user carries both files as part of his setup - when on an x86 client system, he runs the x86 version, and x64 for x64, to accommodate programme shell extension compatibility, path-addressing, etc.

(As an x86 user you would not realise the many pitfalls which can arise from something which initially appears superficially simple. As an aside, this is one of the reasons it's almost unbelievable that your man has not moved heaven and earth to generate his own x64 version of xyplorer - compiler limitations or not - a file manager is not about any bland claims of "speed" or nonsense of memory-mapping (there is far more to x64 than memory); it is fundamentally important on the shell-level that the x64 integrity be respected and there simply is no excuse for not ensuring that. Any claim otherwise is misinformation: while an x86 process will indeed "run" just fine, it can't read the shell at all, and will also suffer the SYSWOW64 redirections on the path-resolution level which a power-user would find simply laughable. Reference this as an example where a user finds it difficult to understand even the explanation as to why he doesn't understand what he's actually looking at.)

Your previous method (of checking the OS bit-type) was perfectly acceptable as it would run the expected version appropriately. As it is now, if the user switches to an x86 system (and has both binaries as he should) it will always try to execute the x64 version and (if x86 OS) fail miserably. To circumvent this, the user would need to have two different runtime folders (and all that entails) with two different launch shortcuts, and he himself be aware of what the OS is beforehand (when most clients can't accurately tell you their own wive's true hair-colour, you can't trust what they might guess regarding OS bit-types).

As I said, this is my fault for not looking closer at the code from the 08-Aug-13 - I did not notice that you had commented out the bit-factoring function, otherwise I would have copped it sooner. Apologies.

I strongly suggest you restore the previous handler.

Enternal
Member
Member
Posts: 54
Joined: 2013 Aug 03, 05:28

Re: xp2KeyCrypt 1.4 Final - August 12, 2013

Post by Enternal » 2013 Aug 13, 00:47

Kilmatead wrote:
Michael Corleone wrote:Just when I thought I was out... they pull me back in.
Bugger - I didn't read the last source accurately enough - if I had, I would have discouraged you from this:

There is a very good reason this is an extremely bad idea - as the x2 binary comes in two formats it is recommended that the portable-user carries both files as part of his setup - when on an x86 client system, he runs the x86 version, and x64 for x64, to accommodate programme shell extension compatibility, path-addressing, etc.

(As an x86 user you would not realise the many pitfalls which can arise from something which initially appears superficially simple. As an aside, this is one of the reasons it's almost unbelievable that your man has not moved heaven and earth to generate his own x64 version of xyplorer - compiler limitations or not - a file manager is not about any bland claims of "speed" or nonsense of memory-mapping (there is far more to x64 than memory); it is fundamentally important on the shell-level that the x64 integrity be respected and there simply is no excuse for not ensuring that. Any claim otherwise is misinformation: while an x86 process will indeed "run" just fine, it can't read the shell at all, and will also suffer the SYSWOW64 redirections on the path-resolution level which a power-user would find simply laughable. Reference this as an example where a user finds it difficult to understand even the explanation as to why he doesn't understand what he's actually looking at.)

Your previous method (of checking the OS bit-type) was perfectly acceptable as it would run the expected version appropriately. As it is now, if the user switches to an x86 system (and has both binaries as he should) it will always try to execute the x64 version and (if x86 OS) fail miserably. To circumvent this, the user would need to have two different runtime folders (and all that entails) with two different launch shortcuts, and he himself be aware of what the OS is beforehand (when most clients can't accurately tell you their own wive's true hair-colour, you can't trust what they might guess regarding OS bit-types).
Ah I never thought about that. Sorry I have my fault in the matter as well. Anyway the OSBits method is now back in. I hope everything works out now. Anyway thank you for pointing that out. Also, I always love how you have so many quotes at your disposal that makes a lot of sense!

Post Reply