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

Search This thread
W

Wolf Pup

Guest
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!!!)

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

I'm sorry. I'm so sorry.
 

no.human.being

Senior Member
Oct 29, 2011
981
987
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. :D

The problem is that here in Germany (yeah, now you all know it, I'm German as well :D ) "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 :D ) 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). :D

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. :D

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.

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. :D

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. :D
 
Last edited:

no.human.being

Senior Member
Oct 29, 2011
981
987

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. :D

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.

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! :D ) 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 :D ). 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 :D ) 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:
  • Like
Reactions: MrTaco505

a.s.j

Senior Member
May 11, 2008
388
104
Ugh..u fry my brain with those long comments :D

That is what is called "the German perfection" :D

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
 

no.human.being

Senior Member
Oct 29, 2011
981
987
@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.

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.

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.
 

a.s.j

Senior Member
May 11, 2008
388
104
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 :D

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
 

theq86

Senior Member
Jan 6, 2009
951
729
37
Nuremberg
Nothing Phone 2
It is also possible, that even a vanilla kernel will not lead us the way.
I spent the last days comparing the firmware mtd driver with an untouched driver.
I have found no changes that would implement an extra security based on reading the secu_flag.

It is still possible, that HTC "obfuscated" or treated the radio area in a way that not even the mtd driver will be able to overcome. Because no reference to any secu flag is in the mtd drivers and they do not really differ from the vanilla mtd drivers I probably think the security lies not in the S-ON/S-OFF flag, but in the way the mtd driver works. It would take us forever to find out why exactly the mtd driver does not write the nand.

Remember, we got no error messages. And never when any radio or hboot is flashed, a Linux kernel is involved.

I think the low level OSes write the data in a special way, corrupting them afterwards.

Would it somehow be possible to mimic a write process of the low level OSes in the radio using the linux kernel? I really don't think the mtd driver is able to do our work.

---------- Post added at 03:01 PM ---------- Previous post was at 02:59 PM ----------

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

this is what we tried. we were on a minimal Android/Linux system. All the radio stuff has been executed long time ago at this stage. so we ARE not relying on the bootloader @this time.
 
Mar 9, 2012
8
3
mtd driver

I compared Android kernel 2.6.39.4 and Linux 2.6.39.4 mtd driver and also found no relevant difference. Just thinking whether it is not just a bug you are getting result code 0. This could be because of insufficient capabilities? Maybe trying kernel with capabilities disabled would help.

The
ret = (erase->state == MTD_ERASE_FAILED)?-EIO:0;
in the case MEMERASE in mtd_ioctl look very suspicious.

I could not find erase method implementation of struct erase_info so I cannot verify what other result codes are possible....

I am not a kernel developer, so I may be wrong. Just thinking about...
 
  • Like
Reactions: EJKasteel

a.s.j

Senior Member
May 11, 2008
388
104
But from what I understood, you still need the HTC Dev unlocked one to even boot the fastboot way to get there right? And this is what I am wondering about... :(

Sent from my HTC Vision using XDA
 

Lt.Win

Senior Member
Aug 20, 2011
3,159
673
Mumbai
Reading all this, I'm guessing HTC guts are geniuses of some sort. Also, I'm trying to find kernel developers over at other sections like aria, buzz, etc. They could help us. :D

Sent from my Wildfire S using xda premium
 

humzaahmed155

Senior Member
Dec 30, 2011
1,356
299
London
Reading all this, I'm guessing HTC guts are geniuses of some sort. Also, I'm trying to find kernel developers over at other sections like aria, buzz, etc. They could help us. :D

Sent from my Wildfire S using xda premium

I dont think the Buzz/Wildfire would help so much since the hardware is quite old on that phone, i dont know maybe the aria could help you guys.
 

no.human.being

Senior Member
Oct 29, 2011
981
987
It is also possible, that even a vanilla kernel will not lead us the way.
I spent the last days comparing the firmware mtd driver with an untouched driver.
I have found no changes that would implement an extra security based on reading the secu_flag.

It is still possible, that HTC "obfuscated" or treated the radio area in a way that not even the mtd driver will be able to overcome. Because no reference to any secu flag is in the mtd drivers and they do not really differ from the vanilla mtd drivers I probably think the security lies not in the S-ON/S-OFF flag, but in the way the mtd driver works. It would take us forever to find out why exactly the mtd driver does not write the nand.

It's not the secu_flag. Every single memory page that belongs to the "unmapped" (Radio) area is marked as "worn out" (being erased so often that another erase would "kill" it) and the mtd driver sees that marking and then refuses to erase the page in order to avoid physical damage to the memory. I'm sure that they did not really "wear the pages out", since HTC itself updates the Radio from time to time and sure they don't really make their memory bad, they just mark it as bad, so that the kernel no longer dares to erase it. The marking is done by setting bitflags in the "out of band area" of the pages ("out of band" doesn't mean that they're difficult to access, it just means that "normal" read/write calls are not affected by them so that the file system driver doesn't have to be aware of their presence). There are ioctl(...) calls for checking and modifying these flags for every single memory page. All we have to do is either ...

... make the mtd driver ignore these flags and erase the page nonetheless.
... make the mtd driver clear (reset) the flags before attempting to erase the page.

When we can do either of the two, we can write to the Radio area. The modification should not be "difficult" (perhaps we don't even have to modify the kernel-level mtd driver itself, but just the user space utilities), it's just that we have to dive into kernel development to understand what's going on beneath the hood.

Remember, we got no error messages. And never when any radio or hboot is flashed, a Linux kernel is involved.

Yes we got error messages trying to erase the unmapped area. The erase is skipping every single page since they are considered "bad". The "erase_image" utility told us that.

I think the low level OSes write the data in a special way, corrupting them afterwards.

They either write the data and then mark the page as bad or all the pages are marked bad by HTC during manufacturing and "their utilities" write to bad pages, allowing them to program the NAND nonetheless. Remember they can't do too much corruption since both Radio and HBOOT (both stemming from the protected area) are loaded from persistent (NAND) into volatile (RAM) memory by processor-level firmware and this firmware must be able to understand the data that's written to NAND, load it into RAM and schedule the execution of both, "Radio" and "HBOOT/Android" kernels, since the two are supposed to run "in parallel" on the processor, communicating with each other via shared memory. So this all can't be "too custom". At least the processor-level firmware must understand what both "operating systems" are doing and both must adhere to some sort of "common protocol" for the communication.

Also remember that dumping the HBOOT via the mtd layer works just fine, so the data ain't really "corrupted". The pages are just marked as "Do not erase me!" and that's what the mtd driver and user space utilities do. Not erasing them. Everything else works fine. :D

Would it somehow be possible to mimic a write process of the low level OSes in the radio using the linux kernel? I really don't think the mtd driver is able to do our work.

Yes it is. The mtd driver can both set and clear the flags (one of the two operations will almost certainly require a complete erasure of the page though) and it seems to be the only instance (apart from the user space mtdutils) that checks (and therefore "enforces") them.

Reading all this, I'm guessing HTC guts are geniuses of some sort. Also, I'm trying to find kernel developers over at other sections like aria, buzz, etc. They could help us. :D

The protection measure is in the Android kernel and is by Google, not by HTC. HTC just "makes use" of the protection by setting some flags that Android checks. Every Android phone has this protection in place. Even the Nexus phones have it. HTC hasn't got anything to do with this, they're just "licensees" of the technology.
 
Last edited:

no.human.being

Senior Member
Oct 29, 2011
981
987
Thanks for clearing up the reason. So maybe we need only to compile another custom version of mtdtools.

This is the source of flash_erase (what we're currently using for erasure). I'm currently not understanding all of it, but the loop at line 237 is doing the erasure.

You see that it performs lots of checks and breaks the cycle (moving to the next block with "continue;" without erasing the current at hand) or even aborts the complete erasure ("return;") when any of these checks "fail".

Code:
		int ret = mtd_is_bad(&mtd, fd, eb);
			if (ret > 0) {
				verbose(!quiet, "Skipping bad block at %08"PRIx64, offset);
				continue;
			} else if (ret < 0) {
				if (errno == EOPNOTSUPP) {
					noskipbad = 1;
					if (isNAND)
						return errmsg("%s: Bad block check not available", mtd_device);
				} else
					return sys_errmsg("%s: MTD get bad block failed", mtd_device);
			}

So when the mtd_is_bad(...) call returns something other than 0, then it aborts. If the return value is greater than zero, it just skips the current block, if it's lower than zero, it completely aborts the erasure.

Code:
		if (unlock) {
			if (mtd_unlock(&mtd, fd, eb) != 0) {
				sys_errmsg("%s: MTD unlock failure", mtd_device);
				continue;
			}
		}

When the mtd_unlock(...) call returns something other than zero, it skips the block as well.

Code:
		if (mtd_erase(mtd_desc, &mtd, fd, eb) != 0) {
			sys_errmsg("%s: MTD Erase failure", mtd_device);
			continue;
		}

Here it actually tries to erase. Now what I don't understand is, why is it trying to "unlock" the block first and only when the "unlock" succeeds it erases it? Wouldn't it be more logical to try to erase the block first (if it's not marked "locked" the erase will succeed) and when the erasure fails then unlock it and erase again after unlocking (then it will certainly succeed). The way it's written here probably will only erase blocks that were marked as "locked" before. I could imagine that the unlock call returns an error when the page is not locked and then the utility just moves on without erasing, wtf?! :D

However I'm not sure. This is all not very well documented you see? :D
 
W

Wolf Pup

Guest
If HTC was a person I'd punch them in the face!!!!
Let's sue 'em for theft.
 

heavy_metal_man

Senior Member
Nov 6, 2011
2,749
752
Gentlemen, about your legal concerns. Are we forgetting that revolutionary do what we aim to do, on somewhat a commercial scale.( even if we do not have to pay currently) they seem to be fine....

Sent from my HTC Wildfire using xda premium
 
  • Like
Reactions: MrTaco505
W

Wolf Pup

Guest
That's actually true!!
Has anyone ever had the thought that HTC/XTC-Clip is watching this thread, deliberately putting us down, or something.
 

Top Liked Posts