Talk:Brick

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)

There is a very large list here that could be used to as a reference MWoolweaver (talk) 06:37, 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/uses 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 be base64 encrypted, etc, so these checks would not be foolproof. --Awesomebing1 (talk) 03:08, 23 February 2015 (UTC)

Yeah, there's no foolproof technical method, and giving people a technical method may even give them a false sense of security. This is a case where a social method can be more effective than a technical method. The first time somebody reports that they installed a package that actually bricked their device (not just an ordinary bootloop that can be solved by going into no-Substrate mode or doing a DFU restore), there will be a ton of news and investigation of that report in the social system that jailbreakers use - blogs, forums, Twitter, and so on. I believe that staying in touch with that social system, and learning how to better estimate whether a tweak/developer/repository is trustworthy, can be a more effective defense against bad packages. Britta (talk) 03:40, 23 February 2015 (UTC)