This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
apemanzilla's profile picture

Custom ROM via crafting

Started by apemanzilla, 04 March 2014 - 05:29 PM
apemanzilla #1
Posted 04 March 2014 - 06:29 PM
I have a fairly simple suggestion here. I would like to have an alternative crafting recipe for computers where a floppy disk (the disk must have a bios.lua file on it) replaces the standard redstone. The produced computer would be identical to other computers, except instead of having the standard files, it would have the files from the disk instead.

For example, here is a disk's layout:
/bios.lua
/rom/myprogram
/rom/myfolder/myprogram
/myfolder/anotherprogram

This would result in a computer running the given bios.lua, a read-only "rom" folder with the files and folders contained in it, and a NON read-only folder "myfolder" with a file "anotherprogram" in it. The bios file would still be intangible and invisible as far as the OS can see.

Another example:

/myprogram

The user would not be able to craft the computer with this disk as it is missing a bios.lua file.

Final example:

/bios.lua
/myprogram
/rom/
/mysecondprogram

This would result in a computer running the given bios.lua, with an empty rom folder and two non read-only files "myprogram" and"mysecondprogram."

This would open a new path for advanced OS's and virus-proof systems, but at the disadvantage of being single-use - you can't fix bugs in the code without creating a new computer.
Edited on 27 February 2015 - 01:21 PM
sci4me #2
Posted 06 March 2014 - 03:10 AM
yeah, i really HATE that the rom is in the cc zip. cant you at least have a bootloader that can do multiboot?
Sebra #3
Posted 06 April 2014 - 11:41 AM
I like this suggestion. It will allow players to modify things, they cannot now.
It's possible to add recipe like Comp+Disk=Comp_reprogrammed, but really it is an option only.
s0r00t #4
Posted 17 April 2014 - 12:11 AM
+1
Love that suggestion, as it would add support for custom bootloader system, and the ability to make better OSes.
Snocker15 #5
Posted 23 April 2014 - 04:49 PM
Great idea! I would love to see this implemented to the game.
Saldor010 #6
Posted 23 April 2014 - 05:42 PM
Yeah, considering your the one making the computer, you should be the one to decide how it runs ;)/>
TheOddByte #7
Posted 23 April 2014 - 08:22 PM
I support this suggestion, it would be very useful! :D/>
wilcomega #8
Posted 26 April 2014 - 12:40 PM
this is amazing, just go on a server set these programs up and sell them as game consoles. great idea. more things you can do with this:
  • Operating system
  • Anti-virus
Full support as i have like 3 diffrent posts where you can edit the rom but it always got turned down, i really hope this one makes it through as its not as complicated and still really really good

SUPPORT
Edited on 18 August 2014 - 08:42 PM
LDShadowLord #9
Posted 28 April 2014 - 02:25 AM
+1. I agree, it is a good idea :)/>
Sebra #10
Posted 01 May 2014 - 11:41 AM
It's possible to add recipe like Comp+Disk=Comp_reprogrammed, but really it is an option only.
Please, Dan200, if you add this, do not leave old data in Computer, use new Id.
Reason is security leak.
apemanzilla #11
Posted 16 May 2014 - 05:06 PM
Have I mentioned this would also make it possible to prevent people booting the computer from a disk? :3
Zudo #12
Posted 16 May 2014 - 06:04 PM
Support. This would be really useful.
apemanzilla #13
Posted 16 May 2014 - 08:32 PM
Added a counter at the top of the thread so we know how many people want this :3
It's possible to add recipe like Comp+Disk=Comp_reprogrammed, but really it is an option only.
Please, Dan200, if you add this, do not leave old data in Computer, use new Id.
Reason is security leak.
Why not just wipe the computer before changing the ROM?
Sebra #14
Posted 17 May 2014 - 07:01 AM
Added a counter at the top of the thread so we know how many people want this :3
It's possible to add recipe like Comp+Disk=Comp_reprogrammed, but really it is an option only.
Please, Dan200, if you add this, do not leave old data in Computer, use new Id.
Reason is security leak.
Why not just wipe the computer before changing the ROM?
1. Some security could check unique id. New Comp is reprogrammed, so not trusted.
2. Files form old Comp should not be deleted from world save. They should be recoverable after accidents.
3. If old Comp was reprogrammed before, old ROM files are also stored in world save and recoverable.

Btw counters (and even polls) are only to warm your heart. :)/>
apemanzilla #15
Posted 19 May 2014 - 04:54 PM
Added a counter at the top of the thread so we know how many people want this :3
It's possible to add recipe like Comp+Disk=Comp_reprogrammed, but really it is an option only.
Please, Dan200, if you add this, do not leave old data in Computer, use new Id.
Reason is security leak.
Why not just wipe the computer before changing the ROM?
1. Some security could check unique id. New Comp is reprogrammed, so not trusted.
2. Files form old Comp should not be deleted from world save. They should be recoverable after accidents.
3. If old Comp was reprogrammed before, old ROM files are also stored in world save and recoverable.

Btw counters (and even polls) are only to warm your heart. :)/>

1. Huh? Anyone can spoof computer IDs with ease anyways, you should always try to use a better form of security if there's any thing valuable you're protecting.
2. All files on the computer would be replaced with ones on the disk anyways.
3. See above.
Edited on 19 May 2014 - 02:54 PM
GreenByteSoftware #16
Posted 21 May 2014 - 04:37 AM
Completely agreed with that! Creating OSes on top of OS is terrible!
Konlab #17
Posted 25 May 2014 - 05:04 PM
Really good idea!
skwerlman #18
Posted 26 May 2014 - 11:03 AM
+1 Fully support

Being able to replace a computer's BIOS would be extremely useful.

Plus, you could add fs encryption to the BIOS, so you never need to implement it again.

Question: Will the custom BIOS use up space on the computer's drive, or will it be limited to a specific size (as in real life)?

Also, will it be possible to give the BIOS (and only the BIOS) write privileges to edit itself (like a BIOS flasher)?
Edited on 26 May 2014 - 09:08 AM
cptdeath58 #19
Posted 28 May 2014 - 05:45 PM
If you could edit a computer's ROM in ComputerCraft, You could also increase security in many ways, but you could also allow even more security leaks.
That being said, You could reroute a disk drives boot to use the computer's boot instead to help increase security on doors because the disk doesnt come
first then, so they would be putting a useless disk in trying to hack into it, but if the person does gets his hands on the computer, he can destroy it completely
making it unusable.
However again, you can get a password system onto your computer before accessing it to prevent this so…
1+ Support here
KingofGamesYami #20
Posted 29 May 2014 - 03:59 AM
+1 support, amazing idea. Especially the preventing of disk-booting.

Would this also override control+s and control+r ?
Saldor010 #21
Posted 29 May 2014 - 04:18 AM
+1 support, amazing idea. Especially the preventing of disk-booting.

Would this also override control+s and control+r ?

I don't think it should. In my opinion, pushing control+s/r, is pushing the power button of the computer. I don't think any program should be able to disable that.
KingofGamesYami #22
Posted 29 May 2014 - 01:54 PM
Yes, but we are crafting our computer differently…
skwerlman #23
Posted 29 May 2014 - 01:56 PM
Maybe add an option to disable it, but not by default.
Saldor010 #24
Posted 29 May 2014 - 06:25 PM
Yes, but we are crafting our computer differently…

No we aren't. All we're doing is editing the ROM, not changing the actual hardware.
KingofGamesYami #25
Posted 29 May 2014 - 08:13 PM
Yes, but we are crafting our computer differently…

No we aren't. All we're doing is editing the ROM, not changing the actual hardware.
Well, as I don't see a button in either recipe… Could be separate suggestion "recipe to remove power button" :)/>
Xfel #26
Posted 31 May 2014 - 08:41 AM
CTRL-S and CTRL-R are handled by the mod itself, these two never get close to lua code. so, even by rom editing, this part of computer behaviour can't be changed.
Edited on 31 May 2014 - 06:43 AM
negamartin #27
Posted 05 June 2014 - 04:28 AM
I support :)/>
Awesome suggestion. Hope dan adds this…
+1
Geforce Fan #28
Posted 06 June 2014 - 05:00 AM
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.
BytePointer #29
Posted 19 June 2014 - 07:00 AM
Maybe you could craft a microchip, be able to put a custom ROM on it, then put it in a new special kind of computer! Maybe called 'Custom Computer'? ;P

CTRL-S and CTRL-R are handled by the mod itself, these two never get close to lua code. so, even by rom editing, this part of computer behaviour can't be changed.
Yes, these interrupts are mentioned in bios.lua
Lyqyd #30
Posted 19 June 2014 - 03:25 PM
No, Xfel is right. Ctrl-R and Ctrl-S are handled on the Java side and there's nothing the Lua side can do about them.
Sebra #31
Posted 19 June 2014 - 03:28 PM
Maybe you could craft a microchip, be able to put a custom ROM on it, then put it in a new special kind of computer! Maybe called 'Custom Computer'? ;P
Too complicated. Computer has no chip inside now, only redstone dust ;P
ElvishJerricco #32
Posted 20 June 2014 - 07:40 AM
This general suggestion has been asked for since the dawn of time. I've always supported it. And this thread seems to prove that almost everyone wants it. If there's a most requested feature for CC, this is it.
sEi #33
Posted 20 June 2014 - 11:26 AM
+1

Would be a nice feature.

/sEi
Konlab #34
Posted 20 June 2014 - 11:40 AM
But if you craft an edited ROM, there MUST be leaved some main APIs,
I guess for example Redstone API isn't written in Lua.
Sebra #35
Posted 20 June 2014 - 02:38 PM
Only LUA side can be changed of course. Java side can be supposed "hardware".
Konlab #36
Posted 20 June 2014 - 03:10 PM
But how to call that 'java side'?
apemanzilla #37
Posted 20 June 2014 - 05:47 PM
But how to call that 'java side'?
Same as now.
Mr. Bateman #38
Posted 25 June 2014 - 01:05 PM
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.
Sebra #39
Posted 25 June 2014 - 10:18 PM
I would like to see this taken one step further, such as maybe fs.flashROM()….
Either way, a method that gives trusted software access to flash the ROM when they really need it would be great.
No. I would not support separating software on "trusted" and "not trusted". ROM / RAM separation is good enough.
If you would be able to change ROM in any way, you would be able to add any quantity of levels of "trust" yourself.
skwerlman #40
Posted 27 June 2014 - 02:01 AM
I would like to see this taken one step further, such as maybe fs.flashROM()….
Either way, a method that gives trusted software access to flash the ROM when they really need it would be great.
No. I would not support separating software on "trusted" and "not trusted". ROM / RAM separation is good enough.
If you would be able to change ROM in any way, you would be able to add any quantity of levels of "trust" yourself.
Assuming you had the trust to start. Although implementing trusted software would be pretty hard unless all trusted code were encrypted on disk, since you could just take what made them 'trusted' and move it into some less-than-trustworthy code.
I think only the ROM should be allowed write access to itself, leaving it up to the ROM decide whether or not to allow flashing.
Simply giving the ROM write privileges to itself allows it to implement a trusted/untrusted scheme, so I don't think there needs to be one by default.
Sebra #41
Posted 27 June 2014 - 08: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?
Geforce Fan #42
Posted 29 June 2014 - 09: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 on 29 June 2014 - 07:15 PM
Sebra #43
Posted 29 June 2014 - 09:48 PM
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).
cptdeath58 #44
Posted 19 July 2014 - 01:44 AM
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.
Link149 #45
Posted 19 July 2014 - 02:32 AM
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.
Sebra #46
Posted 19 July 2014 - 05:13 AM
Everything can be cracked, when given enough time.
Try to crack calculator.
Or watch.
Or digital thermometer…
logsys #47
Posted 19 July 2014 - 10:48 PM
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
sci4me #48
Posted 20 July 2014 - 05:44 AM
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/>

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.
flaghacker #49
Posted 22 July 2014 - 09:31 PM
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.
Tatjam #50
Posted 24 July 2014 - 04: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 on 24 July 2014 - 02:54 PM
Rectar2 #51
Posted 07 August 2014 - 02:23 AM
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 on 07 August 2014 - 12:24 AM
theoriginalbit #52
Posted 07 August 2014 - 02:26 AM
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.
acepilot1122 #53
Posted 08 August 2014 - 06: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)
Rectar2 #54
Posted 13 August 2014 - 06:29 AM
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.
theoriginalbit #55
Posted 13 August 2014 - 07:08 AM
bios.lua is Lua-side, not Java-side
Rectar2 #56
Posted 13 August 2014 - 09: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.
immibis #57
Posted 25 August 2014 - 07:20 AM
If it was a crafting recipe, it would obviously already be entirely Java-side.
classyjakey #58
Posted 25 August 2014 - 04:36 PM
+1 This will make it easier to dualboot.
sci4me #59
Posted 28 August 2014 - 09: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!!
Pizza Fox #60
Posted 28 August 2014 - 11: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.
wilcomega #61
Posted 04 September 2014 - 10:31 PM
+5
Cranium #62
Posted 30 September 2014 - 11:50 PM
For the main reason I outlined here, I highly doubt this will ever be implemented. The potential for causing irreparable damage to someone's system is way too high.
Sebra #63
Posted 02 October 2014 - 06:50 AM
The main reason this suggestion is better, than "You can create your own custom ROM with resource packs" is ability to create individual ROM for each computer. Second reason is default computer's behavior for those who would not change it. Third reason is ability to change ROM inside game, not outside.
ardera #64
Posted 02 November 2014 - 11:20 AM
There are some things that would be exploitable if bios.lua wasn't there, the string metatable could be overridden (the string metatable is static per lua machine, so every computer has the same string metatable) Calling functions on strings uses the __index of the string metatable. Virusses could spread very easy.

I think if it's gonna get implemented, there will be a raw bios.lua with basic protection and stuff.
Sebra #65
Posted 02 November 2014 - 01:49 PM
I hope there would be a way to protect it on java side. If not, minor hidden lua stub can be made to protect just this.
Any other exploitable thing except string metatable?
ardera #66
Posted 02 November 2014 - 04:38 PM
There is a very easy way to protect this :)/>
Just let the ComputerCraft Lua Machine Initializer set the __metatable tag of the string metatable to some random string, and it's protected.

I'm not that sure, but I think it's possible to mess with the shutdown/reboot function then, but this can be protected too.
Edited on 02 November 2014 - 03:39 PM
3dsboy08 #67
Posted 08 November 2014 - 03:27 AM
Now we have just found out about a program named "carbon", which allows custom ROM's :D/>
Luca_S #68
Posted 11 November 2014 - 05:50 PM
This would be really nice :D/> on servers you could prevent others to use /diks/startup files, because its very bad if you need a disk drive, but want a public PC. Hope this will be implemented.
cdel #69
Posted 13 November 2014 - 08:53 AM
Now we have just found out about a program named "carbon", which allows custom ROM's :D/>

As the creator of that program, I am considering adding the ability to choose the location of the new rom. Therefore its completely possible to have a rom on something such as a disk. :D/>
Agent Silence #70
Posted 13 November 2014 - 04:45 PM
It is a good idea but it is too big a handful for dan200 to carry on his own.

You have to add new recipes, clone all the computer class files(advanced and normal), modify the way the rom works entirely on both clones, and then find a way to lock the rom again.

And it is an especially tedious task because of not only the massive amounts of programming, but also he has to handle his everyday life.
theoriginalbit #71
Posted 13 November 2014 - 11:28 PM
-snip-
Lol. It wouldn't actually be that difficult. It's just not that good of an idea.
Agent Silence #72
Posted 14 November 2014 - 05:27 AM
-snip-
Lol. It wouldn't actually be that difficult. It's just not that good of an idea.

If you could make the computer startup run before the disk startup
the entire need for another rom is removed
Luca_S #73
Posted 18 November 2014 - 06:46 AM
I know, that this would give the abality to hack computers, but it would also give the ability to disable the booting from disks. So on servers you could do public PCs with disk drives.
wilcomega #74
Posted 09 June 2015 - 11:57 AM
Bump, still a great idea and i think it should be implemented, it will not be able to fully brickwall a pc because you can always overwrite the ROM of a pc, but this way people can finnaly make secure operating systems and core computer functionallity instead of building on this super vunreable default operating system
MindenCucc #75
Posted 09 June 2015 - 02:49 PM
Yeah, this is a good idea. This may be possible using peripherals. I'll look at the API as soon the electricity comes back.

Edit: nope, it's impossible :(/>
Edited on 09 June 2015 - 02:28 PM
Creator #76
Posted 09 June 2015 - 03:56 PM
An alternative is to just overwrite the top level coroutine. Should work fine.
apemanzilla #77
Posted 10 June 2015 - 09:17 PM
An alternative is to just overwrite the top level coroutine. Should work fine.

…what?

We're talking about making our own ROM, that CAN'T be bypassed by disk booting.
cptdeath58 #78
Posted 23 June 2015 - 06:21 AM
For the main reason I outlined here, I highly doubt this will ever be implemented. The potential for causing irreparable damage to someone's system is way too high.
I see you're reasoning so why not also make it or another block hold the hard disk so if it does become irreparable, you can simply have multiple of those and insert your backup, change your password on the computer and go on.
flaghacker #79
Posted 23 June 2015 - 06:25 AM
For the main reason I outlined here, I highly doubt this will ever be implemented. The potential for causing irreparable damage to someone's system is way too high.
I see you're reasoning so why not also make it or another block hold the hard disk so if it does become irreparable, you can simply have multiple of those and insert your backup, change your password on the computer and go on.

What kind of super-important stuff do you guys keep on your conputers? And can't you afford 7 iron to make a new one?

And what? You can only set the ROM when crafting, not afterwards. How could you use this to insert malware?
cptdeath58 #80
Posted 23 June 2015 - 05:23 PM
For the main reason I outlined here, I highly doubt this will ever be implemented. The potential for causing irreparable damage to someone's system is way too high.
I see you're reasoning so why not also make it or another block hold the hard disk so if it does become irreparable, you can simply have multiple of those and insert your backup, change your password on the computer and go on.

What kind of super-important stuff do you guys keep on your conputers? And can't you afford 7 iron to make a new one?

And what? You can only set the ROM when crafting, not afterwards. How could you use this to insert malware?
True, but you never know… someone can end up entering your computer somehow and scrapping it,
Creeper9207 #81
Posted 15 July 2015 - 05:46 AM
this is a really good idea, you should also be able to modify default apis
CherryPie #82
Posted 18 July 2015 - 08:42 PM
This would be amazing on servers to make the computers "anti-hackable" by disabling the auto boot from disk. +1!
flaghacker #83
Posted 18 July 2015 - 09:24 PM
This would be amazing on servers to make the computers "anti-hackable" by disabling the auto boot from disk. +1!

You can do that already (server-wide) with resource packs/by editing the computercraft jar file. If you want you can even make an os.setBootFromDisk (boolean) function.
CherryPie #84
Posted 19 July 2015 - 05:46 AM
This would be amazing on servers to make the computers "anti-hackable" by disabling the auto boot from disk. +1!

You can do that already (server-wide) with resource packs/by editing the computercraft jar file. If you want you can even make an os.setBootFromDisk (boolean) function.

I thought that the suggestion was to elliminate this, lol. Also if you do it for every computer some might get mad and it would be hard to contact and concince the owner of the server that he/she should do it.
Edited on 19 July 2015 - 03:47 AM
Luca_S #85
Posted 31 December 2015 - 03:35 PM
+1 I know that this topic is a bit old, but I really like it, so I have to say something here. I really like this idea, beacuse
  • Prevention of disk autobot,per computer
  • Something like UEFI/EFI/BIOS Menu
  • On servers, maybe not everyone wants ROM modification, but the people who want them can do them on there own