The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
Difference between revisions of "Talk:Brick"
(linking draft of human algorithm) |
Awesomebing1 (talk | contribs) (Reply) |
||
Line 10: | Line 10: | ||
:::We could instead write something like a "human readable algorithm" for helping people determine trust/reliability on their own. I started a draft of this on the /r/jailbreak wiki (since TheiPhoneWiki doesn't really do user guides): [http://www.reddit.com/r/jailbreak/wiki/howtoresearch "How to research a tweak"] [[User:Britta|Britta]] ([[User talk:Britta|talk]]) 01:48, 23 February 2015 (UTC) |
:::We could instead write something like a "human readable algorithm" for helping people determine trust/reliability on their own. I started a draft of this on the /r/jailbreak wiki (since TheiPhoneWiki doesn't really do user guides): [http://www.reddit.com/r/jailbreak/wiki/howtoresearch "How to research a tweak"] [[User:Britta|Britta]] ([[User talk:Britta|talk]]) 01:48, 23 February 2015 (UTC) |
||
+ | ::I was thinking that we could add some functionality to dpkg that checks if the package modifies the nvram binary. Of course, they may create a LaunchAgent or something that runs something that modifies it too, so then we would have to add a grep search for the word nvram. But, then again, it could we base64 encrypted, etc, so these checks would not be foolproof. --[[User:Awesomebing1|Awesomebing1]] ([[User talk:Awesomebing1|talk]]) 03:08, 23 February 2015 (UTC) |
Revision as of 03:08, 23 February 2015
Difficulty of bricking an iOS device
- "(unless very specifically designed to do so by a malicious person, which has not been seen "in the wild")" --- Wasn't this seen here recently with the nvram hack that was discovered here?? Given it hasn't been used in an actual tweak or a package yet... MWoolweaver (talk) 16:28, 19 February 2015 (UTC)
- What I meant by this sentence is that nobody has deployed this method maliciously/intentionally in a package on any repository that I've heard of - they have all so far been clearly marked as dangerous "proof of concept" packages/instructions, not meant to trick you. In other words, it's not "in the wild" as a malicious tweak that people might randomly run into right now. I'd welcome revising this sentence with alternate phrasing that makes this more clear. Britta (talk) 05:07, 20 February 2015 (UTC)
Maybe we could advise people to delete/rename nvram binary (e.g. mv /usr/sbin/nvram /usr/sbin/nvram.disabled) so that potentially malicious tweaks can't use it (it's easy to bypass by supplying another copy of nvram with the tweak though).--Danzatt (talk) 08:19, 21 February 2015 (UTC)
- Yeah, that doesn't really protect people, so it's not super useful to recommmend. In general I believe this page is mostly helpful as a technical reference for people curious about how bricking works instead of as a user guide for avoiding it. :) The user advice would mostly be "avoid installing stuff from repositories and developers you don't trust", with maybe some explanation for how to determine which repositories and developers to trust. Britta (talk) 23:12, 21 February 2015 (UTC)
- Maybe a "trusted sources" page should be created somewhere, including repos that are from trusted developers that have released a certain number of tweaks on the official repos, this creates a place where users can be sure that the repo that they're adding is secure. --Haifisch (talk) 01:38, 23 February 2015 (UTC)
- We could instead write something like a "human readable algorithm" for helping people determine trust/reliability on their own. I started a draft of this on the /r/jailbreak wiki (since TheiPhoneWiki doesn't really do user guides): "How to research a tweak" Britta (talk) 01:48, 23 February 2015 (UTC)
- I was thinking that we could add some functionality to dpkg that checks if the package modifies the nvram binary. Of course, they may create a LaunchAgent or something that runs something that modifies it too, so then we would have to add a grep search for the word nvram. But, then again, it could we base64 encrypted, etc, so these checks would not be foolproof. --Awesomebing1 (talk) 03:08, 23 February 2015 (UTC)