FORUMS
Remove All Ads from XDA

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

936 posts
Thanks Meter: 499
 
By *se-nsei., Senior Member on 3rd December 2011, 11:19 PM
Post Reply Email Thread
14th February 2012, 12:45 PM |#911  
heavy_metal_man's Avatar
Recognized Contributor
Thanks Meter: 773
 
Donate to Me
More
Quote:
Originally Posted by *se-nsei.

You can't even spell newbie mate, get out of this thread.

lol +1 totally wrong place to be.
 
 
14th February 2012, 02:55 PM |#912  
MrTaco505's Avatar
Senior Member
Flag Dallas
Thanks Meter: 105
 
More
I am itching so badly for an s-off, just can't wait

Sent from my Desire HD using xda premium
14th February 2012, 04:13 PM |#913  
Account currently disabled
Thanks Meter: 559
 
More
one day wildfire s will be cracked by s-off.
The Following User Says Thank You to m1ndh4x8r For This Useful Post: [ View ] Gift m1ndh4x8r Ad-Free
14th February 2012, 04:55 PM |#914  
Senior Member
Thanks Meter: 1,075
 
More
So just in case anyone's wondering what I'm doing: I'm currently trying out different cross compilers to build the kernel. Up to this point, I made use of the CodeSourcery ARM toolchain for everything. Now I'm trying out Google's compiler suite for ARM to build Linux 3.2.5 and run it on the handset. If that doesn't work either, I'll go back to the CodeSourcery toolchain and try an older kernel, probably 2.6.35 as this is what was forked and became the Android kernel for Gingerbread. Let's see if I can get any of those kernel builds to boot. If none of the builds boot, we probably got the configuration wrong.

Remember the idea was to boot a "vanilla" Linux kernel on the handset to get rid of any restrictions that might have been put into Google's "custom" kernels. Why are we doing this? Well, a "vanilla" Linux kernel should definitely permit us to read/write from/to the entire NAND so no more "protected" or "unmapped" areas. It will also make running our tool as root trivial, so no more exploits or privilege escalation before patching the phone S-OFF.

I'm gonna document/update the progress here:

Linux 3.2.5 - CodeSoucery toolchain - BUILD SUCCESSFUL - BOOT FAILS
Linux 3.2.5 - Google toolchain - BUILD SUCCESSFUL - BOOT FAILS
Linux 2.6.35 - CodeSourcery toolchain - BUILD FAILS (This is due to an error in the kernel sources!)

Linux 2.6.35 is faulty. It fails on ...
Code:
drivers/video/console/vgacon.c:508:18: error: 'PCIMEM_BASE' undeclared (first use in this function)
Unlike the other build errors, this seems to be a true error in the kernel sources, so there's no "workaround" or "patch" to it. Only fix that's suggested seems to be "use a more recent kernel". So "vanilla" (kernel.org) 2.6.35 seems to be plain unbuildable for ARM. What now?

Just for documentation purposes. I configured it much the same way that I did with the 3.2.5 kernel (so look a few pages back for details), commented out lines 67 and 68 if "drivers/scsi/osd/osd_initiator.c", then built using the following command line.

Code:
make ARCH=arm CROSS_COMPILE="arm-none-linux-gnueabi-" -j`grep 'processor' /proc/cpuinfo | wc -l`
It fails on a bug in "drivers/video/console/vgacon.c". This seems to be a bigger error in the kernel sources, so there's no quick fix for it. Suggested solution is to use a more recent kernel version.
The Following 7 Users Say Thank You to no.human.being For This Useful Post: [ View ] Gift no.human.being Ad-Free
Wolf Pup
15th February 2012, 06:18 PM |#915  
Guest
Thanks Meter: 0
 
More
Thumbs up
Quote:
Originally Posted by *se-nsei.

You can't even spell newbie mate, get out of this thread.

Hilarious! Considering you're English, the Get out of here! but really makes me image what you are thinking!

---------- Post added at 07:18 PM ---------- Previous post was at 06:52 PM ----------

Quote:
Originally Posted by no.human.being

I think he wasn't against quoting in the OP, but in the post here in the thread that directly followed mine and which quoted everything (*se-nsei has since edited his post and the quote is now removed).



Well, I'm using POSIX compliant systems (e. g. Linux) on all of my machines, so I'm quite familiar with the system itself. I've worked as a software developer and am currently studying computer science, so of course I've got quite some programming language skills as well. This includes system level programming (assembly language, etc.) which comes in handy when reverse engineering stuff.

During my last semester, I've pushed hard to get a slot in an interdisciplinary research project here at university. This is where I met some electrical engineers and so-called "technical computer scientists". This is a different direction of study than regular "comuter science", which is what I'm studying.

While regular "computer science" is more about large-scale systems (PCs and clusters, I've quite specialized in the latter section because I'm also very much into IT security and penetration testing which was another subject where I strongly specialized during my studies and obviously you can use clusters for breaking security systems, especially cryptographic systems where you can make use of raw computational power to factor large integers for breaking RSA encryption for example), "technical computer science" is more in the embedded world so it's about programming microcontrollers, FPGAs and the like. Think of it as "the bridge between regular computer science and electrical engineering". This cooperation with our "technical computer science" branch got me some very limited (!!) embedded skills as well and now I tried to combine the two to break the security on HTC devices.



Well basically you could try to get familiar with the file system, memory system etc. of Linux, which is probably far better documented than that of Android. Remember the Android kernel is based on Linux so all the low-level stuff will be extremely similar and most of the permissions stuff (both use POSIX permissions) is also. The biggest difference is that Linux is a true multi-user system, so multiple users can login to the machine (e. g. via remote shell) and interact with the system and the OS does its best to separate the users from each other so that one can't get in the way of another, be it by accident or intentionally.

Now Android makes use of the multi-user facility of Linux as well, but of course there's little sense in having the user-account facilities exposed to the end users as, contrary to a server, which is what Linux was originally designed for, a smartphone will usually only be used by one person. So on Android each process is its own user. So whenever you start a process on Android, a new user account is temporarily created transparently for that application in the background and as soon as the process dies, that user account silently disappears again. That's basically all. Android is in fact much harder to hack than Linux is (and Linux is quite hardened as well due to its server heritage) because it is targeted for embedded use so it is far less complex than a full-blown Linux system for desktop or server use and lower complexity means less weak points where you could break the system. Additionally, Android is designed to be secured "against the will of its user" (which is exactly what we're trying to break here, we want to install custom firmware or change the partitioning but we're not allowed to) while Linux is not.

The source code of kernels and most tools for both systems is open so feel free to grab whatever you want. Keep in mind that in most cases you don't need to take a look at the source but only at a specification and only in special cases (where you want to break/modify something and need to know exactly how it's implemented) you actually need to skim through the source. The source code is really extensive so there's no point in trying to know it all.

If you want to compile native code for Android (which is all we're interested in here as you can't really write exploits in an interpreted language like Java, you want to get as close "to the metal" as possible), check the CodeSourcery "arm-none-linux-gnueabi" toolchain. If you want to write code that runs directly on the processor (like an operating system kernel) without any operating system beneath, check the CodeSourcery "arm-none-eabi" toolchain. Both toolchains are not free/open-source software, but you can get a license for non-commercial use without paying any license fees. There is also an ARM version of the gcc toolchain (which is "free as in free speech, not as in free beer" GPLed software by the legendary GNU project) but it is much more complicated and I've never managed to set it up correctly to build for our target.

In addition to the toolchain, you should grab the official Android SDK for pushing files onto the device's file system, getting a remote shell on the device and stuff like that. You'll need to enable USB debugging on the device for this to work. If you can do the development on a Linux machine, you're usually much better off, as Linux has fantastic development tools supplied. Most stuff can be done on Windows as well, but there may be additional tweaks required.

When you want to understand how memory protection works, take a look at this Wikipedia article. It's not very detailled, there's really a bit more to it, but it gives you an idea of the general concept.

Well this is generally what it's all about. If you have any more concrete questions on how to get started, just post here and we'll all be here to help. Thank you very much for your efforts in joining us.



Very true! There's a very basic rule in IT security and it is "boot access is root access", which means as long as you're able to physically interact with the system, you can efficiently break every security system (apart from special cases like full disk encryption when you don't have the encryption key). There's really nothing you can do to prevent this, so all attempts to prevent it are actually just raising the "investment bar" higher. If you prevent write access to the ROM, people can grab a JTAG interface and still flash it. The only thing IT security can (and should) really secure against is remote access and "accidental" data manipulation by a local user or data manipulation by "unskilled" local adversaries. No chance (and also no reason) to really secure a system against a skilled local adversary with the right equipment.

Thanks! I already knew about multi-user and USB Debugging and Android SDK, although you explained it much better! You coming to XDA has been a miracle, right from the beginning! I have Windows, but I hope to install Ubuntu. When I have some free time, I might start a secret project, that should help the Android community. I have also built a ROM, but it hasn't been released yet, I have flashed it though. If you want it, don't hesitate to ask.

Now, please explain this:

Why do I have the strange urge to eat Pringles?
15th February 2012, 06:39 PM |#916  
Senior Member
Thanks Meter: 1,075
 
More
Oh please don't quote it all. People are visiting this site via their mobiles and even on a desktop PC it's not worth scrolling over dozens of LoQ (Lines of Quote .. the new software metric ).

Quote:
Originally Posted by Bad-Wolf

I have also built a ROM, but it hasn't been released yet, I have flashed it though. If you want it, don't hesitate to ask.

Thanks for the offer, however, I'm quite confident with CM7.2.
The Following 2 Users Say Thank You to no.human.being For This Useful Post: [ View ] Gift no.human.being Ad-Free
15th February 2012, 08:21 PM |#917  
humzaahmed155's Avatar
Senior Member
Flag London
Thanks Meter: 283
 
More
Im planning on installing Linux Mint or Ubuntu, but i only have 20-30GB Free of my 320GB Internal hard drive, so i was wondering if a virtual machine will do the job, like have a dynamically-expanding disk and if it can communicate with the device like it can using a physical PC.

Im a Flash-a-holic but writing code and developing ROM(s) is a toughie for me
15th February 2012, 08:42 PM |#918  
Senior Member
Thanks Meter: 1,075
 
More
As long as you can map the physical USB device through, you should be fine. Most virtualization tools can do it, but it often turns out to be quite a hassle.
The Following User Says Thank You to no.human.being For This Useful Post: [ View ] Gift no.human.being Ad-Free
15th February 2012, 08:49 PM |#919  
*se-nsei.'s Avatar
OP Senior Member
Flag London
Thanks Meter: 499
 
More
Quote:
Originally Posted by no.human.being

As long as you can map the physical USB device through, you should be fine. Most virtualization tools can do it, but it often turns out to be quite a hassle.

This is S-OFF business must be such a tough job. Btw, @n.h.b - I've decided to study computer science in higher education. You and a lot of others have inspired me to take on my interests. Haha, just a little OT.
15th February 2012, 09:31 PM |#920  
humzaahmed155's Avatar
Senior Member
Flag London
Thanks Meter: 283
 
More
Quote:
Originally Posted by no.human.being

As long as you can map the physical USB device through, you should be fine. Most virtualization tools can do it, but it often turns out to be quite a hassle.

Great! As i entered setup VMWare Workstation said "High Android Phone" Is mounted, i also decided to install linux mint because it consumes less Space.
16th February 2012, 05:34 AM |#921  
Member
Thanks Meter: 6
 
More
I come late to the party, but why not ask Alquez for his conf, and compile files for the 2.x Linux kernel? If he got it to compile and run why not just use his work as basis, then run your little C program to do the job, and we are good?
Post Reply Subscribe to Thread

Tags
bootloader, campaign, dev, exploit, hboot, htc, kernel, radio, s-off, secu-flag, wildfire s

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes