Jump to content




Custom ROM via crafting


84 replies to this topic

#41 Sebra

  • Members
  • 726 posts

Posted 27 June 2014 - 07:51 AM

1. Change ROM(by crafting) in order to protect "_flash_" directory and use it for autorun some changeable code.
2. Use trusted procedure, you wrote in ROM, to change "_flash_" content.
3. Do you need more?

#42 Geforce Fan

  • Members
  • 846 posts
  • LocationMissouri, United States, America, Earth, Solar System, Milky Way, Universe 42B, Life Street, Multiverse, 4th Dimension

Posted 29 June 2014 - 08:11 PM

yeah, I don't see a reason you couldn't implement rom editing and trust yourself. You're being given complete access to the computer.
One of the reasons I think this is such a good idea is because, currently, computercraft is very limited as to what it can do--the user is at the ROM's mercy. Letting the user make their own ROM would be a revolutionary thing for CC. It would remove most of the limitations that occur due to the way CC is. This is also the reason, I think, it's not been implemented. I feel that the last thing dan200 wants to do is to give the user complete and total freedom. Maybe I'm wrong; but if I'm right this is unlikely to be implemented. Either way I still support it as I've said earlier.

Edited by Geforce Fan, 29 June 2014 - 08:15 PM.


#43 Sebra

  • Members
  • 726 posts

Posted 29 June 2014 - 08:48 PM

View PostGeforce Fan, on 29 June 2014 - 08:11 PM, said:

It would remove most of the limitations that occur due to the way CC is. This is also the reason, I think, it's not been implemented. I feel that the last thing dan200 wants to do is to give the user complete and total freedom.
User never would have complete freedom. Java part of CC would be always precompilled.
I think Dan200 want CC to be fool proof as much as it possible. But that is why this suggestion is so good: No user commands can break bios. Only implicit crafting only in player's hands would change rom. And you have the same way to return all to default state (craft with empty disk).

#44 cptdeath58

  • Members
  • 139 posts
  • LocationError 404: Could not find.

Posted 19 July 2014 - 12:44 AM

View PostSebra, on 29 June 2014 - 08:48 PM, said:

View PostGeforce Fan, on 29 June 2014 - 08:11 PM, said:

It would remove most of the limitations that occur due to the way CC is. This is also the reason, I think, it's not been implemented. I feel that the last thing dan200 wants to do is to give the user complete and total freedom.
User never would have complete freedom. Java part of CC would be always precompilled.
I think Dan200 want CC to be fool proof as much as it possible. But that is why this suggestion is so good: No user commands can break bios. Only implicit crafting only in player's hands would change rom. And you have the same way to return all to default state (craft with empty disk).
This may be true, but it allows for more possible security solutions as well. Allowing a user to be able to replace CraftOS entirely with another OS with an impossible to crack password system is what we need. It would keep the intruders at bay and allow more options rather than someone just simply putting in a startup disk to bypass your password system.

#45 Link149

  • Members
  • 46 posts
  • LocationQuebec, Canada

Posted 19 July 2014 - 01:32 AM

View Postcptdeath58, on 19 July 2014 - 12:44 AM, said:

View PostSebra, on 29 June 2014 - 08:48 PM, said:

View PostGeforce Fan, on 29 June 2014 - 08:11 PM, said:

It would remove most of the limitations that occur due to the way CC is. This is also the reason, I think, it's not been implemented. I feel that the last thing dan200 wants to do is to give the user complete and total freedom.
User never would have complete freedom. Java part of CC would be always precompilled.
I think Dan200 want CC to be fool proof as much as it possible. But that is why this suggestion is so good: No user commands can break bios. Only implicit crafting only in player's hands would change rom. And you have the same way to return all to default state (craft with empty disk).
This may be true, but it allows for more possible security solutions as well. Allowing a user to be able to replace CraftOS entirely with another OS with an impossible to crack password system is what we need. It would keep the intruders at bay and allow more options rather than someone just simply putting in a startup disk to bypass your password system.

Everything can be cracked, when given enough time.

#46 Sebra

  • Members
  • 726 posts

Posted 19 July 2014 - 04:13 AM

View PostLink149, on 19 July 2014 - 01:32 AM, said:

Everything can be cracked, when given enough time.
Try to crack calculator.
Or watch.
Or digital thermometer...

#47 logsys

  • Members
  • 171 posts

Posted 19 July 2014 - 09:48 PM

View PostSebra, on 19 July 2014 - 04:13 AM, said:

View PostLink149, on 19 July 2014 - 01:32 AM, said:

Everything can be cracked, when given enough time.
Try to crack calculator.
Or watch.
Or digital thermometer...
All of that can be cracked if they use a kind of software that enables user interaction.. For example, TInspire are crackable(calculators).

About the ROM being a limit, I don't think that's true. A computer has its space limited, and the ROM doesn't... If you top level override, you could gain access like if there was nothing in the ROM, you would build your ROM yourself. It's not easily made, but with sandboxes and the top level override, you would pass the original ROM with the cost of the space in the computer.. That would be easily changed if you had a disk drive with a disk acting as a ROM or if you merged internal storage with the disk.

Oh god.. I wrote soo much. I hope someone does great use from it

#48 sci4me

  • Members
  • 225 posts
  • LocationEarth

Posted 20 July 2014 - 04:44 AM

View Postlogsys, on 19 July 2014 - 09:48 PM, said:

View PostSebra, on 19 July 2014 - 04:13 AM, said:

View PostLink149, on 19 July 2014 - 01:32 AM, said:

Everything can be cracked, when given enough time.
Try to crack calculator.
Or watch.
Or digital thermometer...
All of that can be cracked if they use a kind of software that enables user interaction.. For example, TInspire are crackable(calculators).

About the ROM being a limit, I don't think that's true. A computer has its space limited, and the ROM doesn't... If you top level override, you could gain access like if there was nothing in the ROM, you would build your ROM yourself. It's not easily made, but with sandboxes and the top level override, you would pass the original ROM with the cost of the space in the computer.. That would be easily changed if you had a disk drive with a disk acting as a ROM or if you merged internal storage with the disk.

Oh god.. I wrote soo much. I hope someone does great use from it

Few things: 1. this idea is the best idea ever and should be at the top of the list of the CC features to be implemented. 2. you CAN get above CraftOS with a little bit of lua "magic" (its really simple actually). 3. you are wrong.

Not to be a jerk, but i'm guessing your not a programmer? Java?
Trust me, you will not be able to "crack" anything from within CC even with a custom ROM. I promise, with standard CC, you wont get out of the CC sandbox or anything like that.
However, because I am intrigued, I will take a minute and look into this further. It is an interesting topic (also relates to my OS development). But I can guarantee I wont be able to figure out anything...

there are things that cannot be cracked. Now, a watch or calculator could be... potentially. But it would require hardware hacking.

In CC though, even in the BIOS, we are VERY limited. There isn't really a whole lot that can be done in the BIOS... except for the string metatable thing but.. thats pretty much it.

If you ask me, CC and trusted code = joke. CraftOS actually... my OS may be a different story, but that's still being worked on.

Wow, I wrote a lot too........... :P

View PostGeforce Fan, on 06 June 2014 - 04:00 AM, said:

1 word: yes.
To be honest, this is a very sense-making suggestion. Like he said, you make the computer, shouldn't you be able to control how it runs?
Another thing is that this could be used to protect your program so that they cannot be modified or deleted.

This can be done EXCEPT... startup disks ruin it.
I have this is my OS, a very secure system... but startup disks make it a joke.

#49 flaghacker

  • Members
  • 655 posts

Posted 22 July 2014 - 08:31 PM

Quote

This can be done EXCEPT... startup disks ruin it.
I have this is my OS, a very secure system... but startup disks make it a joke.
That's the point, the startup thing is in the bios, you would be able the remove that.

#50 Tatjam

  • Members
  • 16 posts
  • LocationSpain

Posted 24 July 2014 - 03:53 PM

Good idea, i will like to not have them locked, so, raid servers can have real virus attacks ;)

With real i mean IN GAME attacks :P

Edited by Tatjam, 24 July 2014 - 03:54 PM.


#51 Rectar2

  • Members
  • 43 posts
  • LocationThe Universe

Posted 07 August 2014 - 01:23 AM

View PostROFLCopter64bit, on 25 June 2014 - 12:05 PM, said:

I would like to see this taken one step further, such as maybe fs.flashROM().
It would make programs like this easier to implement, as giving a bootloader direct access to the raw startup and autorun script and change it as need be (Maybe even bios.lua, but it's a last resort :) ) would make life much easier than relying that the user renamed /startup on their disk to /grubstartup.

The arguments would be a one-time password that the computer gives the user only once, which changes everytime you flash the ROM.
Or maybe, you can only flash it once (or a preset value) like in the OP.
If the user forgets this password, (if it's not one-time only) the user can flash back to default ROM (but other people might use this to exploit holes).

Either way, a method that gives trusted software access to flash the ROM when they really need it would be great.
I think this could be a good idea, but on the Java side of CC, the screen should clear, and you should be given an on-screen choice asking if you want this to happen. That'd keep it secure, and so the user couldn't be easily attacked by viruses, rather than the password system. If someone then forgets the password, they're screwed.

Edited by Rectar2, 07 August 2014 - 01:24 AM.


#52 theoriginalbit

    Semi-Professional ComputerCrafter

  • Moderators
  • 7,332 posts
  • LocationAustralia

Posted 07 August 2014 - 01:26 AM

View PostRectar2, on 07 August 2014 - 01:23 AM, said:

I think this could be a good idea, but on the Java side of CC, the screen should clear, and you should be given an on-screen choice asking if you want this to happen. That'd keep it secure, and so the user couldn't be easily attacked by viruses, rather than the password system. If someone then forgets the password, they're screwed.
I virus could click, but it can't enter a correct password.

#53 acepilot1122

  • Members
  • 34 posts

Posted 08 August 2014 - 05:26 PM

maybe rather than a custom crafting recipe for a computer rom, there should be some kind of bios config file that lets you turn on/off different features like booting from disk or ctrl + t... maybe from that it would let you write things into bios, but this cannot be done from disk, or can only be done by the computers owner (the person who crafted it)

#54 Rectar2

  • Members
  • 43 posts
  • LocationThe Universe

Posted 13 August 2014 - 05:29 AM

View Posttheoriginalbit, on 07 August 2014 - 01:26 AM, said:

I virus could click, but it can't enter a correct password.
Since it'd be on the Java side, it could specifically wait for a mouse click, directly from the user.

#55 theoriginalbit

    Semi-Professional ComputerCrafter

  • Moderators
  • 7,332 posts
  • LocationAustralia

Posted 13 August 2014 - 06:08 AM

bios.lua is Lua-side, not Java-side

#56 Rectar2

  • Members
  • 43 posts
  • LocationThe Universe

Posted 13 August 2014 - 08:57 PM

What I meant was, flashing could be entirely Java side, not handled by Lua in any way. So the bios wouldn't be programming the flashing, it would be a built-in feature to the mod itself.

#57 immibis

    Lua God

  • Members
  • 1,033 posts
  • LocationWellington, New Zealand

Posted 25 August 2014 - 06:20 AM

If it was a crafting recipe, it would obviously already be entirely Java-side.

#58 classyjakey

  • Members
  • 3 posts

Posted 25 August 2014 - 03:36 PM

+1 This will make it easier to dualboot.

#59 sci4me

  • Members
  • 225 posts
  • LocationEarth

Posted 28 August 2014 - 08:03 PM

Again, +1000. There isn't a reasonably reason NOT to add this. Make it a config option if you must.

Either way, I may just brew up my own custom ROM for the cc.jar that makes this possible for myself...
We'll see. Obviously it wouldn't really the the same thing but.. meh.

ADD THIS!! Seriously!!

#60 Pizza Fox

  • Members
  • 6 posts
  • Locationwhere am i

Posted 28 August 2014 - 10:16 PM

What would be easier in-game but harder out-of-game would be if in the config file you could make a certain program be the rom assuming it is correctly formatted. Sort of how if a startup file exists the computer runs that, but with a modified rom, with some features still implemented like control-t and the filesystem.





2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users