256 - 512 bit encryption using 28 digit cipher key

[wlangfor@uoguelph.ca]

VST is still worthwhile but ultimately it gets less attention, and with attention comes license key crackers.

Not so sure that anyone will bother for a vst unless it's easy game which it isn't, realistically.

And thats where you are 100% totally wrong. VST cracks are a HUGE part of the music community and right now when every second person wants to be a producer and a dj making those "phat beats" yo! Almost every VST plugin is cracked, I have seen cracks from FlowStone developers (keeping it anonymous to protect their identity) recently, and if you give them something claiming to be uncrackable (free or not), those who have no knowledge in protection what so ever, will trust you and you give them false claims, and will probably be godsmacked when they see their new VST get cracked the next day employing the uncrackable method.

lol, I made a nice video to talk about this algorithm and explained that it's a good starting point. But I mean, I'm not using any big and nasty words like Godsmacked and such but I hope it's still entertaining.

Maybe it's not too late to join the circus right?



I'd trust it man.

[adamszabo]

The problem is still that all the substitutions and replacements you do, is still visible in the plugin. Resource hackers and decompilers and memory dumps will show that you replace the string "A" with something else. These strings are not hidden as you would think. A hacker will easily read all the replacements and could figure it out, it doesnt matter how many passes you do.

[wlangfor@uoguelph.ca]

The problem is still that all the substitutions and replacements you do, is still visible in the plugin. Resource hackers and decompilers and memory dumps will show that you replace the string "A" with something else. These strings are not hidden as you would think. A hacker will easily read all the replacements and could figure it out, it doesnt matter how many passes you do.

The thing is, the replacements are not physically coded, they're based on arrays. So, either way the array each pass will be 0-9 randomly. So, even in that case, it'd be a hard read.

Moreover, the new version I'm working truncates and replaces characters many times over. So that 1000 digits becomes 50. You see, so in other words it would tire the snooper out. I mean, there are only so many steps that you can keep up with until it becomes a human game. Because unique methods require that they are decrypted manually.

I might be able to get an older encryption technique which works with ruby, but it will be older. Maybe with these two techniques employed it will be enough.

[wlangfor@uoguelph.ca]

In regards to Adam's claim that VST are cracked more, perhaps this is true because of the price and compatibility with cheaper systems. I guess in nature it is a poor man's game.

But, I remembered, it's easy to forget the end goal for the project that I'd originally planned a specially made image to form the admin cypher.

So, right now we have some text in a string that is used as the cypher, but in the most advanced version to come it will rely on an image to be the code. I'll make one in photopea to show you really quick:



This is what an administrator cipher key would look like. They would merely add it to the flowstone code and it would be the key to all of their plugins, rather than there being a string supplying the cipher.

This way, an array is built and made connecting the dots. Furthermore, the name of the plugin will cause it to change in new ways as will the pluginid. As long as each key stays in an array it becomes very difficult to look at or render the data from a process. I remember talking to a guru years back, and he'd said to me that the worst and most annoying thing was complicated and especially nested arrays. I wonder if he didn't just really mean arrays, because after all, the nesting would only serve to provide a pattern, lol.

Sneaky gurus.

So, I'd looked into truncating, because that is an important step to make sure that the length of the string is not too long to begin with. Interestingly, this can be done with base64 for starters, it would be the most ideal locale because of the fact that the amount of characters it contains is limited. Logic would suggest that just the most compression of characters can occur there.

This should ensure that the url doesn't have to be too long. I'll be pleased with that. Furthermore, I wanted to add; the only way to unlock with the version I'd envisioned is with an image. To unlock the plugin it requires that the image be in the folder. Offline installs are done the same way, the image is downloaded, and its extensions is renamed to .key

The key would be tailored to the machine hard drive code or other computer info that I haven't worked out yet. Furthermore, the server will never connect to the vst, but instead create an image with gd, and the folder's name will be a special code that will be generated so that the user can re-download the key. This prevents hacking in other ways too, because there is never any response. And the only way to test for success is to conceivably check if the supposed image is in existence.

A long way to go but it is a fun project. But I'm sure withe the same base schematic and examples provided that someone could come up with something equally as cunning which is why I found the idea of the project amusing. I've been downloading tutorials to make wordpress plugins, it should be fun to make it all something more than local.

Until I have more.

[wlangfor@uoguelph.ca]

I realized what an image key would mean, something like an ilok.

It could be conceivably done, if someone could sense the serial of the usb stick. So that our flowstone flowlocker could automatically start a vst with the relevant license with a usb connected.

Anybody have thoughts on that? That'd be sick right? A product that does the same thing as ilok without the extra red tape? Just put the key file and register it to the specific usb stick and it serves as a secondary license. How cool would that be?

[k brown]

Or, you might spend a little of this time and effort helping your local hospital, church or gvmnt deal with what's going on in the world right now. I'm sure they could find a use for your considerable skills.

[wlangfor@uoguelph.ca]

Well, I guess in a way I am helping people self isolate

[wlangfor@uoguelph.ca]

Hi everyone, I hope health is with everyone.

I had some success with an algorithm designed to bring down the size of a binary, hex, and base64 encoded string so that it can be sent via url, given that modern php applications avoid post and globals. There's an annoying limitation to that.

So I feel it's best to put that version aside so as to be able to show how I'd made it efficient as it is. It's roughly 125% of the original in length and ready to be encoded with whichever encoding used, but I feel I could truly compress rather than just make do with 125%.

I'll post something once that's ready, and also I'll be sure to make sure things are as secure as they can be. I'll do some research into ruby and how to avoid snooping of its inner workings and I'll be sure to post some info regarding measures I've chosen for those who wish to avoid "great" loss.

After all, is there a product, whether or not vst that hasn't been pirated somehow? lol.

And as far as "flowlock" I'll try and have a working model ready.

EDIT: here's a good article, a bit old but the tech which resource hacking is always the same.
http://www.virtuouscode.com/2009/10/22/double-load-guards-in-ruby/

It's a tactic that might prove useful. It would require "requiring" ruby with a path and preventing it from being reloaded or loaded twice in the instance of resource hacking. As far as I know that is what we are looking for.

[wlangfor@uoguelph.ca]

ok, here's the failed schematic that doesn't compress for an example.

It's a good example however, of algorithms to reduce and how much reduction is possible. I reduced characters by about 23,000 with encoding.

example of robust encoding to reduce size - failed prototype.fsm

(3.92 KiB) Downloaded 1054 times

EDIT: so, tomorrow I'll have a new version which should bring 1000-2000 characters down to maybe 80, which is the goal. It's a hard algorithm to build but I'll get it done. I guess technically, though just for text the one I've already made is potentially the most powerful zip ever made.

it starts as being 49,000 characters and after my (failed) algorithm it becomes 249. Do the math; if I'm able to succeed with just a base64 string; we'll be in business and sending data to a server fairly large amounts is possible by url. This of course is not as convenient as it once was with post globals and insecure methods of get data being processed now taboo. But that's cool, assuming the only response from the php program is from an image, there's no way that snooping can occur, especially if there is a total lack (as there is) of form data.

You see? I'd thought it through, the real issue though will be saving the administrator cipher image with a local standalone exe and offline activation in regards to resource hacks. I'm not so sure if there will be a bug with the url I'd found about locking ruby to double instances; there may be, because technically the way in which flowstone processes ruby allows for classes being stored locally within the schema; so I'm unsure how effective that will be. But... ultimately, unique and too annoying to try is maybe the right word.

And flowlock? It'd make flowstone plugins the cutting edge, who would want ilok when you could just use any old usb stick.

Til then. It's frustrating the ruby doesn't have the secure peripherals it could, I know newer versions do. If anyone in the know knows where and how; is it possible that we can have some ruby includes made custom for flowstone users? Things like glib and zend and the other libs now mundane. It would be uber. Hashing and salts might be impossile, but USB serial detection through flowstone would be a gamechanger.

Robert

In regards to the making of an image cipher key, I may make only one copy and put it on My server, so that no-one can detect its weaknesses. I'd leave it automated and it would not have any DB connectivity. Fair?

[wlangfor@uoguelph.ca]

Hi all, I wanted to post My new ideas and progress. But I wanted to say that this project is CCBY, so if you attribute Me you can use this idea:

Imagine the internet without speed as a issue. Imagine if only 50mb = 1tb ?

How?

Here is something that gets close. I just found an online resource that finds patterns I'll use to redo these schematics:
https://www.online-utility.org/text/analyzer.jsp

base64 compression - 1.fsm

(256.64 KiB) Downloaded 1054 times

binary compressor v12 - 140 percent.fsm

(262.47 KiB) Downloaded 1042 times

but, imagine if I use this pattern finder first. You can also save that webpage as a single file or standalone html. Zounds.

I mean, if I were to succeed in binary, and to make binary 10% of original siz4e, it's the best compression in the world. And furthermore, if base64 encoded and I can make it 10% the size, you'll probably see the same technology in a few years running every browser, every download accelerator, every phone, every text, every bit of data you can find online because old modem speeds would still equal 240mb a second!

How crazy is that, lol.