GR8cloud virtual volume image partitioning

Page 2/3
1 | | 3

By Wolverine_nl

Paladin (938)

Wolverine_nl's picture

21-09-2018, 11:25

Good question Wink

By Eugeny_Brychkov

Paladin (1016)

Eugeny_Brychkov's picture

21-09-2018, 22:16

sdsnatcher73 wrote:

What software is used on the server, and is it Windows or Linux?

I wrote code on Visual C#, thus I think it will only compile for Windows.

sdsnatcher73 wrote:

Could we run this software on our own hardware (PC or even NAS)?

It uses its own protocol, very simple but at the same time having some fool-proof measures and authentication.

sdsnatcher73 wrote:

Then it would be possible to create volumes of different sizes,

Current firmware in GR8NET supports any size of the volume (within 32-bit sector addressing); 100 MB I mentioned before is limitation of the server space.

sdsnatcher73 wrote:

and maybe even have multiple volumes on different ports?

Here we must assess the feasibility of it. GR8NET already has sd-card, and having multiple volumes will cause increased traffic and, as network connection is somehow slower than sd-card, slower operation of disk subsystem. The point of GR8cloud was a storage of the data, a kind of backup for your information available anywhere through your GR8NET. Probably we can go further - as you suggest - having multiple cloud volumes, and it will require some firmware redesign.

Regarding sharing code and protocol for the server operation: I did not decide if I must publish it (e.g. through GR8NET manual). The reason is if it is known, people may gain access to other people's GR8cloud volume if targets did not change password from default. So far I had only one or two requests to change password, thus I suspect others use their GR8cloud with default password, or do not use GR8cloud at all.

By Grauw

Enlighted (7407)

Grauw's picture

21-09-2018, 23:13

Eugeny_Brychkov wrote:

Regarding sharing code and protocol for the server operation: I did not decide if I must publish it (e.g. through GR8NET manual). The reason is if it is known, people may gain access to other people's GR8cloud volume if targets did not change password from default.

Not the best of reasoning… if only because I could sniff the traffic and probably figure out the protocol faster than I could by reading source code :).

By sdsnatcher73

Master (193)

sdsnatcher73's picture

22-09-2018, 06:16

Eugeny_Brychkov wrote:
sdsnatcher73 wrote:

What software is used on the server, and is it Windows or Linux?

I wrote code on Visual C#, thus I think it will only compile for Windows.

Well, Microsoft has .Net Core now, which runs on Linux, so it might be possible.

Eugeny_Brychkov wrote:
sdsnatcher73 wrote:

Could we run this software on our own hardware (PC or even NAS)?

It uses its own protocol, very simple but at the same time having some fool-proof measures and authentication.

Yes I got that much from the videos, but if we have access to the software (even if only in executable format) the GR8NET would be able to talk to any instance of the software.

Eugeny_Brychkov wrote:
sdsnatcher73 wrote:

Then it would be possible to create volumes of different sizes,

Current firmware in GR8NET supports any size of the volume (within 32-bit sector addressing); 100 MB I mentioned before is limitation of the server space.

Yes that was my impression as well, but it would be great if we could run a 4GB volume on our own hardware. And what I was hoping to achieve is to be able to mount the volume on PC as well, so you could inject files into the volume on PC and have them available on your MSX next boot (MSX should of course be off when accessing the volume on PC).

Eugeny_Brychkov wrote:
sdsnatcher73 wrote:

and maybe even have multiple volumes on different ports?

Here we must assess the feasibility of it. GR8NET already has sd-card, and having multiple volumes will cause increased traffic and, as network connection is somehow slower than sd-card, slower operation of disk subsystem. The point of GR8cloud was a storage of the data, a kind of backup for your information available anywhere through your GR8NET. Probably we can go further - as you suggest - having multiple cloud volumes, and it will require some firmware redesign.

Regarding sharing code and protocol for the server operation: I did not decide if I must publish it (e.g. through GR8NET manual). The reason is if it is known, people may gain access to other people's GR8cloud volume if targets did not change password from default. So far I had only one or two requests to change password, thus I suspect others use their GR8cloud with default password, or do not use GR8cloud at all.

The main thought was not to have multiple volumes active on the MSX, but on the server. So one for gaming on :684 and another for coding on :685. Then you’d just change the port in GR8NET config and you reboot from different volume. This should already be possible as you are also serving multiple users from 1 server (not sure if they are all on different ports or how you identify user to volume as I don’t have a GR8NET yet)

By Eugeny_Brychkov

Paladin (1016)

Eugeny_Brychkov's picture

24-09-2018, 09:27

Grauw wrote:
Eugeny_Brychkov wrote:

...

The reason is if it is known, people may gain access to other people's GR8cloud volume if targets did not change password from default.

Not the best of reasoning… if only because I could sniff the traffic and probably figure out the protocol faster than I could by reading source code :).

There's only one risk: access properties to the GR8cloud volume is defined at the software level (nothing in hardware making two GR8NET adapters different), and if the malefactor will change property of the adapter (one command is needed), and will know and change the password to the volume (and almost all volumes are currently protected by the default password which is easy to find) - the malefator will have his adapter looking as another adapter and gain access to that adapter's volume.

So the key here is the password, but even it can be cracked sniffing for traffic if the whole conversation between server and client is observed, and exact purpose of fields is known. I must somehow balance performance and security, and at this point do not think it is appropriate to implement SSL or any other kind of security level.

I accept that any traffic or code can be cracked if there's an aim to do it, and "obscurity" serves as one of the "minor" layer to make things complicated for stranger crackers.

I am happy to publish code and protocol, but in gain of giving people running their clouds I personally risk the following:

  1. Other clouds will be out of my control and even influence. Problems with those images, related to quality of GR8NET or unrelated, will cause bad user experience and blaming me for something I even will not know about (I wonder if there're GR8NET users having problems with the device and its software, and instead of asking they just put the device aside and do not use it);
  2. I will get a ton of suggestions how to make things better. I will very welcome them, but while people used to give great advice and suggestions, they usually hesitate to implement them. I will have to choose what to do, and it will be not possible to please everyone;
  3. Last, minor, but not least. I will get public feedback that I am dumb in IT security. I actually am, with some knowledge, assumptions and beliefs that our MSX brothers and sisters are in good faith not misusing their GR8NETs and all designs related to it.

I must admit that publishing is expected to give a way to improve the security, and even maybe performance, the only question is who will be assessing feasibility of improvements and investing the time in improvement implementations, and then support them.

sdsnatcher73 wrote:

The main thought was not to have multiple volumes active on the MSX, but on the server. So one for gaming on :684 and another for coding on :685.

It is easy to implement at GR8NET side: host and password are being changed with single command. I even not sure if reboot is needed as host change will raise "disk change" flag.

sdsnatcher73 wrote:

Yes that was my impression as well, but it would be great if we could run a 4GB volume on our own hardware.

Be carefult with that. When Nextor initializes, it scans (reads) whole FAT, and some other areas, and as bigger disk image is, more time this Nextor "startup" will take. Even with 16MB FAT12 volume on current GR8cloud server startup takes about 10 seconds. GR8NET can not control or influence it as read requests are made by Nextor kernel for single sectors (the least performance achieved possible).

By Eugeny_Brychkov

Paladin (1016)

Eugeny_Brychkov's picture

26-09-2018, 11:05

Update: right now, while I am considering pros and cons of opening the protocol, we can do the following ways:

  1. I can compile the server code for target platforms (but it will require me to perform installations and learn how to port and compile for targer platform);
  2. I can share source code with interested people on simple NDA.

By Manuel

Ascended (14667)

Manuel's picture

26-09-2018, 11:53

But why NDA? Why not just put it in the open? As Grauw said, it's probably very easy to reverse engineer with a sniffer anyway...

By sdsnatcher73

Master (193)

sdsnatcher73's picture

27-09-2018, 06:35

Apart from the discussion about opening the sources, a thought on how to make it more secure. From what I am reading, and please Eugeny correct me if I am wrong, the issue is there is no encryption at all due to speed considerations. Which is understandable. What if you would use encryption only during the authentication part and then fall back to unencrypted for the data transfers.

By Eugeny_Brychkov

Paladin (1016)

Eugeny_Brychkov's picture

27-09-2018, 07:17

sdsnatcher73 wrote:

What if you would use encryption only during the authentication part and then fall back to unencrypted for the data transfers.

Correct, I actually do this way. Control information (password and other key fields) are coded, and checked by the server (and GR8NET at its end), but data is not modified. Injecting same request/response data for another transfer will not work, the header will need to be re-coded.

By Eugeny_Brychkov

Paladin (1016)

Eugeny_Brychkov's picture

08-10-2018, 09:03

I decided to go the following route: now you have gr8cloudserver application designed in .NET Core and runnable on Windows as well as Linux. Please see new version of uploaded manual (closer to its end, use ^F to search through it).

Karloch has build Docker container image, his post is here.

Page 2/3
1 | | 3
My MSX profile