drivers/video/console/vgacon.c:508:18: error: 'PCIMEM_BASE' undeclared (first use in this function)
make ARCH=arm CROSS_COMPILE="arm-none-linux-gnueabi-" -j`grep 'processor' /proc/cpuinfo | wc -l`
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.
|bootloader, campaign, dev, exploit, hboot, htc, kernel, radio, s-off, secu-flag, wildfire s|
|Thread Tools||Search this Thread|