Welcome to XDA

Search to go directly to your device's forum

Register an account

Unlock full posting privileges

Ask a question

No registration required
Post Reply

[DEV][THE S-OFF CAMPAIGN] We need electrical engineers & experts in JTAG, OpenOCD!

OP *se-nsei.

8th March 2012, 09:31 PM   |  #1701  
eoghan2t7's Avatar
Recognized Contributor
Flag Belfast
Thanks Meter: 2,156
 
4,190 posts
Join Date:Joined: Jan 2011
Donate to Me
More
Quote:
Originally Posted by BeciMester

Is it still illegal if you do the modification only for yourself on your own phone and do not distribute the modified code? Also: do you legally have to restore everything to stock if you sell the phone or give it away?

(I'm on my phone...)

its not illegal to modify your phone as it your property for example when apple took George Francis Hotz aka geohot to court about him breaking the iphone bootloaders etc the courts dropped the case because its not illegal to do
The Following User Says Thank You to eoghan2t7 For This Useful Post: [ View ]
8th March 2012, 09:42 PM   |  #1702  
theq86's Avatar
Senior Member
Flag Nuremberg
Thanks Meter: 736
 
918 posts
Join Date:Joined: Jan 2009
Donate to Me
More
Quote:
Originally Posted by BeciMester

Is it still illegal if you do the modification only for yourself on your own phone and do not distribute the modified code? Also: do you legally have to restore everything to stock if you sell the phone or give it away?

(I'm on my phone...)

Well, as long as you sell it for private purpose it doesn't matter.

However, nhb is right. Even if the exploit does not contain hboot code, we can not just patch hboot and distribute it.
distribute the exploit, however is leading us into a shadow corner of right.

The approach of getting uboot to work may not infringe copyright, but it would surely need some bricked wildfires before being usable.

---------- Post added at 09:42 PM ---------- Previous post was at 09:39 PM ----------

Quote:
Originally Posted by eoghan2t7

its not illegal to modify your phone as it your property for example when apple took George Francis Hotz aka geohot to court about him breaking the iphone bootloaders etc the courts dropped the case because its not illegal to do

At least in my country, anything cracking the SIMLOCK IS illegal
The Following User Says Thank You to theq86 For This Useful Post: [ View ]
8th March 2012, 10:39 PM   |  #1703  
Wolf Pup's Avatar
Senior Member
Flag I live in the TARDIS
Thanks Meter: 290
 
3,731 posts
Join Date:Joined: Jan 2011
More
Quote:
Originally Posted by no.human.being

But there's a different thing that makes me concerned and it's the fact that we're patching the HBOOT and this software is protected by copyright. I'm not sure whether creating a software that patches it is already considered "creating a derived work" (which we would NOT be allowed to do) or if that "derived work" is only created "on the phone" and therefore by the person running the patch (after all the patch itself doesn't contain HBOOT code at all).

Yeah, we could use UBOOT. Stupid idea, but if we can recreate software from our own code, that performs the same stuff another software does, maybe we can write our own HBOOT, pre-patched. (Please don't kill me!!!)

Quote:
Originally Posted by theq86


At least in my country, anything cracking the SIMLOCK IS illegal

I'm sorry. I'm so sorry.
The Following 2 Users Say Thank You to Wolf Pup For This Useful Post: [ View ]
9th March 2012, 12:29 AM   |  #1704  
Senior Member
Thanks Meter: 1,075
 
984 posts
Join Date:Joined: Oct 2011
Quote:
Originally Posted by theq86

At least in my country, anything cracking the SIMLOCK IS illegal

Well it "is illegal". There has only been exactly one case so far, where someone got sentenced to something around 20 - 30 months on probation and that one cracked several hundreds of phones on a commercial basis, charging money from his customers for each unlock. The sentence was for copyright infringement (because the handset firmware was modified), not fraud against the provider (because he enabled his customers to use the "subsidized" handsets on another carrier's network afterwards) and the court that decided the case was only a district court, so they probably weren't very competent concerning intellectual property stuff.

The problem is that here in Germany (yeah, now you all know it, I'm German as well ) "circumventing a technical protection measure that's supposed to prevent you from accessing data or assisting someone in doing so" (I'm very loosely translating the law here, so don't take this for an official translation ) is already considered fraud. Sure this law was passed to cover the typical "hacking" scenario, where you break into a foreign system circumventing firewalls and then look at, say, internal data of another corporation. That is why it's colloquially referred to as "the hacker paragraph", but you see that the formulation is so inexact and vague, that it effectively covers our case as well. "Protection" doesn't neccessarily mean that it must be "hard to overcome", it's almost certainly enough as soon as it prevents you from "accidentally" overcoming it. It must make you realize that the data you're accessing is supposed to be protected. So from that point of view, the "unmapped memory" is probably much more than enough to be considered "protection", even though it only takes a stupid kernel parameter to break it (and a bit of a lenghty calculation if you're doing it for the first time).

Our case is a bit special though, since we (the ones that are "circumventing the protection measure") are also the rightful owners of the system we "break into" and it would be a bit of a "perverted law" if you weren't allowed to look at data residing on your own system, just because it is somehow "protected". So the "looking at it" is definitely ok. And even breaking the security on your own handset is definitely going to be ok. If it weren't ok, that would also mean that, say, when you forget the login for your computer and then break the hash in order to be able to log into your system again, you'd already be breaking the law since there is a "technical protection measure" in place that requires "thoughtful action" to "circumvent". Certainly, even in Germany, you're obviously never going to end up in courtroom for "breaking into your forgotten user account" on your own system/network.

However, the problem is that, by developing an exploit, we're essentially providing a solution here that other people may use as well and, from the legal point of view, this might turn us into some kind of a "service provider". Basically, one could argue that we're providing some kind of "service for others to unlock their handsets", even though we're not charging for it and suddenly it's no longer our property we're breaking into. This is where it starts to become problematic.

Quote:
Originally Posted by BeciMester

Is it still illegal if you do the modification only for yourself on your own phone and do not distribute the modified code? Also: do you legally have to restore everything to stock if you sell the phone or give it away?

I don't think you have to revert to stock, as long as you explicitely mention that the firmware is altered. And of course you're not supposed to do it for commercial purposes. So "selling your S-OFF handset" would be ok, as long as you mention that it's S-OFF and you didn't use the S-OFF to, say, install malware on it that spies upon the subsequent owner.

Turning the handsets of your friends S-OFF would also be ok. On the other hand, "buying 100 handsets, unlocking, then selling them" would most likely get you in trouble.
Last edited by no.human.being; 9th March 2012 at 12:31 AM.
The Following 3 Users Say Thank You to no.human.being For This Useful Post: [ View ]
9th March 2012, 12:35 AM   |  #1705  
Wolf Pup's Avatar
Senior Member
Flag I live in the TARDIS
Thanks Meter: 290
 
3,731 posts
Join Date:Joined: Jan 2011
More
I hate the law!

Sent from a Time Lord, via his TARDIS.
9th March 2012, 12:49 AM   |  #1706  
Senior Member
Thanks Meter: 1,075
 
984 posts
Join Date:Joined: Oct 2011
Quote:
Originally Posted by Bad-Wolf

I hate the law!

Yeah, sometimes it's stupid, but I tend to respect it.

Btw, I think that the S-ON lock by itself is actually copyright infringement committed by HTC. The GPL forbids the licensee (and in this sense HTC is "licensing" Android from Google and Google is "licensing" Linux from the GNU project) to "put restrictions in place that prevent others from redistributing and/or modifying the software" covered by GPL and that GPL and non-GPL software may not be "distributed as a coherent system". This basically means that HTC must license HBOOT as GPL. They basically have no choice. Either they GPL it (then we'd be allowed to modify or) or they cease to distribute it with Android. What they're currently doing is totally against copyright law. But this is a war the Free Software Foundation has to fight (as it's their copyright that is infringed), not us. However, I'm sure they'd get a great amount of "compensation fees" and manufacturers would have to stop locking their bootloaders if the FSF did file a lawsuit.

The S-ON is definitely infringing the GPL, no doubts about that.

In addition, the Radio firmware is basically Iguana (operating system, OzPLB license, similar to BSD license) on top of Pistachio (kernel, BSD license). So if someone was really committed, he could probably build the Radio firmware from the sources of the two. Then we could be sure that it's really free.

Quote:
Originally Posted by Bad-Wolf

Yeah, we could use UBOOT. Stupid idea, but if we can recreate software from our own code, that performs the same stuff another software does, maybe we can write our own HBOOT, pre-patched. (Please don't kill me!!!)

Yeah, the problem is that we must not base it on HBOOT. So basically we'd create an "HBOOT compatible bootloader" from scratch. Of course that's perfectly legal. It really ain't that much code either. HBOOT is an extremely primitive program. The code that was supposed to do the analysis and patching was in fact more complex than HBOOT itself. (This is no joke! ) And much of the stuff is "security related" (checking signatures and such), which we could completely omit of course as we want to encourage modification of the firmware, not prevent it.

However, UBOOT is very proven software that is trusted upon in the embedded world (and of course it's legal ). The problem is that it's designed to load Linux kernels and as we already know Linux and Android are very similar ("genetically" similar in fact), but they're not completely identical. Most of the difference is in the headers. Android kernels have a different header that the bootloader has to evaluate in order to set up the processor so that it's in a state in which the kernel expects it to be. This means that we either have to modify UBOOT to enable it to read Android kernel headers (I'm not familiar with the UBOOT source, but it's probably a substantial amount of work, as UBOOT is much more "generic" than HBOOT is so it probably has a much more extensive codebase ) or modify Android to work with Linux kernel headers (this seems to be a lot more likely to be possible to accomplish, most likely modifying the "mkbootimg" utility would be sufficient).

Note that this is an entirely different project than what we originally planned to accomplish. Basically, we know how to S-OFF now, we just can't provide a utility (for two reasons: first, we have no kernel that allows us to write to the HBOOT area, second, we are not allowed to distribute such a utility). Do you think it's ok if we "S-OFF manually"? I mean we "know" which instructions we have to patch, we can map the memory, we can dump. When we have a good kernel we can erase and write back. For me it's definitely enough once we get the kernel. I don't need a "one click solution", I just want to "get it done somehow" and as long as you're all doing it manually and on your own personal handsets, I don't see a lot of legal concerns.
Last edited by no.human.being; 9th March 2012 at 01:59 AM.
The Following 2 Users Say Thank You to no.human.being For This Useful Post: [ View ]
9th March 2012, 02:27 AM   |  #1707  
MrTaco505's Avatar
Senior Member
Flag Dallas
Thanks Meter: 103
 
409 posts
Join Date:Joined: Jan 2012
More
Ugh..u fry my brain with those long comments
9th March 2012, 08:46 AM   |  #1708  
a.s.j's Avatar
Senior Member
Thanks Meter: 46
 
352 posts
Join Date:Joined: May 2008
Donate to Me
More
Quote:
Originally Posted by MrTaco505

Ugh..u fry my brain with those long comments

That is what is called "the German perfection"

Indeed I agree with all NBH said (even not being German). I asume, that without precise analysis of whole the "problem" we can not go on, but we still try again and again. I am into it also, and I must say, that I doubt, that anyone would sue us for breaking HBOOT while they break the GPL license too

@NBH: Do you think, that you would be able to create HBOOT like program, that would do it for us without using the original one?

And also, if the NAND write protection is within the kernel... how come that on the other devices (like my DZ) it was enough just to get temp root an dd the image to NAND with using psneuter utility? Would that be possible, that this one and possibly some part of gFree is overcoming this security? Or is it just so, that the kernel in WFS is different, than the one in DZ? I'd guess the kernel is being fairly the same and differs only in driver modules, or ma I wrong?

Sent from my HTC Vision using XDA
9th March 2012, 02:29 PM   |  #1709  
Senior Member
Thanks Meter: 1,075
 
984 posts
Join Date:Joined: Oct 2011
Quote:
Originally Posted by a.s.j

@NBH: Do you think, that you would be able to create HBOOT like program, that would do it for us without using the original one?

Certainly not. Too much knowledge about the controller's internals required. Porting UBOOT will be hard enough.

Quote:
Originally Posted by a.s.j

And also, if the NAND write protection is within the kernel... how come that on the other devices (like my DZ) it was enough just to get temp root an dd the image to NAND with using psneuter utility?

The important thing with the Desire Z (Vision) is that it uses an MSM7230 processor and a NAND chip from SanDisk of part number SDIN5C2-4G, which has an integrated controller (so called "eMMC-module"), that is much more complex than the memory controller that resides on the MSM7227 processor on the WFS. The DZ's memory controller is doing wear-levelling and bad block management on its own and, on the kernel side, is controlled by the "mmcblk" driver, not the "mtd" driver. We assume that the restriction that prevents us from erasing the Radio partition on the WFS resides in the "mtd" driver. On the DZ, it's not the "mtd" driver that is used for storage, but the "mmcblk" driver, since that's the protocol that this memory controller is speaking.

I don't know what psneuter does, never heard of it. Always thought that GFree was doing the entire S-OFF.

Quote:
Originally Posted by a.s.j

Would that be possible, that this one and possibly some part of gFree is overcoming this security? Or is it just so, that the kernel in WFS is different, than the one in DZ? I'd guess the kernel is being fairly the same and differs only in driver modules, or ma I wrong?

GFree is open-source, so we already know what it's doing. First it runs this strange "needle and haystack"-algorithm. I think that this "maps" the partition 7 (Radio partition?) while the system is already running (we "map" it during boot using kernel parameters, that's why we don't need an exploit for mapping). Then it dumps partition 7, patches a bit (secu_flag gets patched at address 0x00000a00, it's the least significant bit, CID and SIM-lock are also patched at some other addresses) and writes it all back. No need to erase the memory on the DZ before writing it back, since the memory controller supports in-place overwriting, doing the "read-modify-erase-write"-cycle by itself so that it's transparent to the kernel.

We can't do what GFree did, since we couldn't find the secu_flag in the WFS NAND. It's either strongly obfuscated or in some "special storage" outside the "normal" NAND area.
9th March 2012, 02:50 PM   |  #1710  
a.s.j's Avatar
Senior Member
Thanks Meter: 46
 
352 posts
Join Date:Joined: May 2008
Donate to Me
More
Well, that what I was affraid of. Well then, I am not able to help much, I can only throw some ideas, cause I do not own WFS. I am following this thread because my girlfriend has one and she is getting mad from suffering low internal memory space

Anyway, if I can help somehow, I am willing to do so even though I have not much spare time (to busy working )

I just thought, that it may be possible to map unmapped memory on running device and not be relaying on the bootloader... Would that be possible or impossible too?

Sent from my HTC Vision using XDA

Post Reply Subscribe to Thread

Tags
bootloader, campaign, dev, exploit, hboot, htc, kernel, radio, s-off, secu-flag, wildfire s
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes