The dream of a free Linux / Android is over, what do you think about SE Linux?

the only option in these kind of scenario is to use a jtag. but the real s**tty problem is
some OEM even hide the jtag pads and esply emu0 and emu1 ports using which you
can really enable/disable functions/options.

in TI omap34xx and omap44xx we got the GP and HS chipset. in gp there is no e-fuse
but there is a e-fuse in HS chipset and to make matter worse we got ARM's TZ. the TZ
is a major issue. the NDA documentation on generic (yes generic documentation is
also under NDA) states that the TZ can literally lock up everything.

i been trying to break the HW-NAT and enable the AES accleration in n900 but as of
now no luck. it too doesnt have jtag pads, or i dont know the jtag pads. blackberry
playbook is not even in the scope.

so the point is "PROFIT & SPY" via FUD and not openness. there is no openness
and will ne none as long as there is NSA and other 3 lettered agencies.

your only friend here is jtag and if you dont have one, you are pretty much a lame duck
you can scream and shout as much as you can but you are locked. baseband is
another issue.

http://droid-developers.org/wiki/Main_Page will help you understand that in much more
detail. here the info is in real in-depth compared to xda-developers. its more or less
focussed on TI's omap.

so the bottomline is you need to indeed defeat the bootrom be it TI's omap or some
other arm cpu and then you can have what you want. the only issue here is? to do that?

you need jtag access and its not easy to jtag these devices. because they are either
hidden deep inside the layers of pcb and secondly they can be turned off by the pad
config utilities.

thus access to these pads are not at all easy. but if you do get access somehow? then
there is no NSA's SELinux or WTF feature can stop you from having your right "freedom"

bootrom is not bootloader. bootrom is the initial bootloader or IBL and it chainloads
the 2nd stage bootloader.

more info about your dream can be found here
http://www.ok-labs.com/products/okl4-microvisor
http://en.wikipedia.org/wiki/L4_microkernel_family
debugging is a disaster

hence if you could understand all these... you are the real master of your device.

so keep the hope keep the faith. there might be one annoyed user who will pick the
pitchfork up and will start to lead this rebel march. its a matter of time and frustration
till things gets done.

and for these things TI's omap3xxx and omap4xxx are a good head start. but dont
expect overnight success. these is very extensive work... good luck once again.

"Live Free Else DIE"

thanks!
-paul

 

I think everyone is forgetting the fact that Google makes Android source code completely open to everyone;

this means that one can easily modify the source code any way they want to, which means they can remove or add features at whim provided they know what they are doing.

Secondly, all kernel sources are made public due to the GPL;

this means that one can easily modify the kernel any way they want to, which means they can remove or add any feature they want provided they know what they are doing.


Absolutely everything in the source code for the AOSP and Linux Kernels can be modified, and I do mean everything. And I know first hand because I build with the source on a daily basis...


If you are worried about the SELinux additions then git the source and modify it to make it build both the OS and the kernel without SELinux support. If this hasn't been done already, then it will in time. There are millions upon millions of people who are and have modified both sources, even to the point that OEMs have started taking up user additions and modifications and adding it to their own production builds.

The beauty of open source is that if you don't like it, then you can change it. And removing SELinux crap is not impossible by any means.

 

I completely respect you Yen and your work here,

but,

I'm sorry, this is absolutely untrue...

the basic apps that underpin the os are needed, but they have nothing to do with google other than the fact that the code was produced by them. if you don't believe me, decompile each app and look at the source code...

all other google tracking crap can be removed if root is possible for the device in question.

if you remove google play and google gsf services the device will still work just fine, the user just won't be able to use the google play store.

aside from this, the entire android dev community is full of people who DON'T KNOW JACK DIDDLY SQUAT and that spread useless and wrong information all the time. just because some random person on some random forum has said google can't be removed from an android device does not make it true...

 

sorry i misunderstood what you meant

i agree that everyone is subject to them because of the source code, but the fact remains that since it's open source it can be modified to the point that it only resembles the original source from google.

but google does release the source. https://android.googlesource.com/?format=HTML

and the fact remains that the majority of the kitkat source has already been released to the public through their git


and

when it comes to building from source, there are several files in the build directory that control the way the source is compiled, and all that is required to change how the system builds, what it builds, and what is required to build without error is to edit these files, which is very easy to do. to say SELinux can't be removed is wrong. the correct thing to say is that it hasn't been done yet.

(I'm not saying I can do it; just saying it's completely possible and will happen. It's only a matter of time.)

 

okay this means its time to open the deck of all 52 cards and 2 extra cards.
See the OEM/ODM has a purpose, "TO SELL!" and for that they can adopt any
lines (viz. like how you portray) "*& DON'T KNOW JACK DIDDLY SQUAT &*"

as a matter of fact we give no rat ass about the xda developers either.
you are partially true. its more of a hype and "hey i am cool! dont you
think so? uh! no, okay screw you then if you dont think we are cool."

most of the xda developers i have come across are like self proclaimed
cool. ayeeeeee? aye aye!

they just assume based on assumption. here is why. every vendor sticks
to their VLSI design and the developers there are literally clueless and
if you try to prove your point, you are labelled as an "ASS".

ARM's design and fabrication concepts are free for any one and everyone
provided they sign up and also dont give it away for free. after all
most important concepts given to people are for free and all they need
to do is sign an NDA.

now the OEM/ODM makes further modification and they add on their own
stuffs. which must comply with the terms and conditions of arm holdings
but they are not obliged to distribute it for free or they have the right
to ask the user to maintain confidentiality and strictness according to
the NDA terms.

now having said that i will come to the points you raised about google
and openness and et al.

android is highly and fully dependent on the kernel and the kernel is
the linux kernel albeit with a few modification here and there and
the ODM/OEM is not obliged to give it to end users or mmmmm "developers".

So? if you must have freedom then you need to pay the price and the
pricetag is pretty heavy.

here is why.

here is a site which deals with revese engineering of the hardware.
http://siliconpr0n.org/wiki/doku.php?id=start
these guys are really good in doing the reverse engineering. and as a
matter of fact these guys were even able to get the fabrication
reversed for RSA Secure ID.

http://siliconpr0n.org/wiki/doku.php?id=process_tech

and those who love popcorn and wish to know more here is a pdf explaining
the process of reverse engineering the DIE.

http://siliconpr0n.org/uv/epoxy_to_schematic.pdf
and some more info here
http://security.cs.rpi.edu/courses/hwre-spring2014/Lecture11_SRAM.pdf

yes you read it right. RSA's Secure ID reverse engineering. And its lead
by andrew zonenberg. and last time i spoke with azonenberg he told he is
"this close" in cracking open the device.

no i am not going off topic. i am relating the topic as how OEM/ODM
can lock up the FOSS kernel with whatever just they feel like introducing
along with hardware modification.

Why am i saying it. Because i been working my ass off and head off trying
to find a way to break into the CPU and extract the confidential data
stored inside the EEPROM stored inside the CPU.

yes an eeprom aka e-fuse which is inside the CPU, here its omap3400 in
nokia n900 and omap4300 blackberry playbook.

and can the security be defeated? oh yes of course pretty much doable
without all the SNR (more noise than proper signal). these devices are
FIPS-140 compliant which requires the OEM/ODM to provide extra security
as per the law/mandate.

But are they completely attack proof? by all means?

No. these devices have the arm's TZ and thats assisted by a strong tz api
and also HW natting. Which means attack via software is pretty much useless
and also a big and ultimate waste of time.

So is the future doomed? the TZ NDA document says its not fully attack
proof. given the academic passion and determination it might get broken,
but that process is not easy.

So whats the closest approach? well, EM is the free lunch restraunt.

Any electronic device emit EM, thats the basic principle and any EM has
a unique and distinct fingerprint. If we can isolate the finger print
we can extact a hell lot of extremely excellent data.

Now coming back to e-fuse and tz and cpu, this is a brief, or rather
floating info, for in-depth info read the documents.

The CPU has the cores, and inside the cores the dies exist. So the die is
permanent and what does it do? Simple no brainer answer "It just computes
instructions."

If thats so? what makes this chip secure and hard to tamper using software.

Aah, here comes TZ and TZ API. the TZ is dependent on e-fuse. a small eeprom
which hold a cryptographic signature which validates the integrity of the
various stage bootloader.

So now the SELinux got the aid of ARM's TZ and TZ API and cpu assisted
encryption. s**t! we are screwed. And i am not aware of any software method
of exploiting this scenario. If you do know please feel free to send me a P.M.

Now you might ask me "you just mentioned about EM (electro magnetic) stuffs"
WTH that has to do here.

aah glad you did ask me that question.

The CPU being an electronic device will emit some EM when some current is
passed. That is, when powered on there will be some change in the EM
surrounding the CPU and other electronic circuits isnt it?

if you argree with me and if you havent already slept on then these is
where your interest might get an adrenaline shot.

This the oldest known drawback in encryption/cryptography. and its known as
the "achilles heel" of encryption.

And they are differential power analysis and side channel attack.

where you literally play with the EM and power spectrum used by the ICs.

When the cpu is doing some computation it changes its states. i.e. 1+1 will
have a different EM state, and i++ will have a different state of EM and
encryption will have another different state.

So if we know the encryption pattern being used there then we can create a
map (rainbow tables) of the signals which might match with the corresponding
encryption keys.

Thus if its AES it will have different s-blocks and RSA will have different
but if we can create a rainbow table of the states and we also know the
e-fuse eeprom size. then work is way reduced now.

but this theory of attack is still in papers. and here is why its so tough.

when the cpu changes states changes it will show change/up-down in voltage
and there are other components also there like other IC and components
which might also change their states. Thus, the power measurement is will
show absurd reading and no way close to the actual cryptanalysis.

But thank goodness, i did mention the EM, and which is unique and if we
could introduce some rectifier circuits which will filter out the Noise
from other devices and also a selenoid (coil used to measure the EM) just
over the CPU we can then see how the CPU during init validated the
cryptographic signatures and hands over the boot process to IBL and SBL.

Or in short you just defeated the encryption.
Okay thats bad news. then nothing is secure. Not exactly. Military and high
security devices have something called as Anti-DPA, its near or inside the
cpu thus it cancells the EM even before it hits the surface of the CPU IC.

so to sum everything. Neither google nor SELinux or any blah blah device
is really secure unless it has Anti-DPA already implemented. And that will
shoot the cost of the same phone to no less than 15-20K US$. ;-)

And samsung/apple/blackberry/nokia/et al can afford to sell joe/jane users
dumb ass smart phones for 15-20K. absolute LULZIE!

thus it boils down to this question now, okay you get the keys via EM, will
it unlock the device and make it fully open and free?

the question is dodgy because, we are still far from complete. even if you
get the keys, then you need to find the loop hole in the bootrom and then
only you have completely circumvented the security provided by
" "
fill in between the quotes your favourite tycoon OEM/ODM provider company.

more info about what to do with the keys after you extract them is here
http://droid-developers.org/wiki/Vulnerability_hunting
and the cryptography is here
http://droid-developers.org/wiki/Cryptography

so thats breaking the attack in a nutshell in pen and paper.

but the big question "shut up ass, stop boring us! when can you crack it!"
it isnt as easy as it looks like. first you need a circuit and rectifier
something like this

https://media.blackhat.com/ad-12/O'Flynn/bh-ad-12-for-cheapskates-o'flynn-WP.pdf
https://media.blackhat.com/eu-13/briefings/OFlynn/bh-eu-13-for-cheapstakes-oflynn-slides.pdf

and loads of time and a massive passion to waste your youth. and
funds to be wasted on these circuits.

and then softwares like mathlab and mathematica and or gnu octave to
do all the rainbow tables and other various mathematical operations
and combine all these and process it (waste your life and youth and time)
eventually you will be able to free of your frustration. and enjoy the
promised Free and Open Source Android (my ASS).

you can pretty much break any security provided you think different and have
loads of time to waste, thats about it. and SELinux is no different so is the TZ and
e-fuse and RSA secure ID and et al anything and everything.

this is how it can be done. And there are a few more papers on cryptanalysis.
i will point to those papers. later as of now read the cryptanalysis by nsa
on military cryptanalysis. :-D

http://www.nsa.gov/public_info/_files/military_cryptanalysis/mil_crypt_IV.pdf

hope i bored you to the core of your large intestine. if you dont like it.
return back to the enjoyable la la disney land. and enjoy what you like to do
ultimately.

sorry for wasting your time. padron me and my stupidity and ignorance.

thanks!
-paul

p.s. i have just enjoyed my rights.
"Be stupid, be lazy and be crazy!" if you dont like this post ask mods to delete this post.
no offense given and none taken.

 

why cant i remove SELinux? I havent tried it yet. But i am sure i can pretty much compile
android kernel or an arm linux kernel w/o opting SELinux.

How about i remove the SELinux and related source files and rebase the kernel source
and then compile. will it work. it has to but i am not sure. since i havent yet worked on it
as of now. but i will give it a shot soon.

heard of http://www.replicant.us/ ?

time to go to freenode again and ask chaps there whats it like there.... so i cant verify
yen's comment nor can i veryify what i mentioned.

thanks!
-paul

 

you obviously are not familiar with the GPL... if a manufacturer doesn't release their kernel source then they are in violation of the GPL--however most OEMs do release the source... that's the beauty of linux and its kernel.


i'm sorry but the rest of what you've posted doesn't read well / make much sense...

we are not talking about hardware at all, and everything you posted has nothing to do with this discussion that I can see (although I respect the fact I could have misunderstood you).

we are talking about SELinux, which is a kernel security module addition, nothing more. it controls security on the software level, nothing more.

we are not talking about unlocking bootloaders or modifying them, which is what prevents new kernels from being flashed. we are strictly talking SELinux which has nothing to do with bootloaders or eeprom at all.

All that is being done by making SE enabled by default is making exploiting devices harder because apps can only access the permissions they need to perform their basic functions, therefore making the creation of exploit apps even tougher because their functions are denied by the kernel module. The truth is that SELinux has been in the linux kernel since 2.6 in 2003. Although it is now further evolved, it is not "new."

The reason SELinux is enabled by default now is because Google and OEMs are getting tired of end users deleting software that is bundled with their devices due to contracts they have with certain retailers and service providers. In order to always be in compliance of these contracts they have to keep the end user from modifying the device by any means necessary.

These new security measures are to keep end users from gaining root access and deleting bundled software, which includes Google apps (and other proprietary apps) that send information to Google servers. That is all.

 

"you obviously are not familiar with the GPL... if a manufacturer doesn't release their kernel source then they are in violation of the GPL--however most OEMs do release the source... that's the beauty of linux and its kernel."

http://source.android.com/source/licenses.html

LGPL requires allowance of customer modification and reverse engineering for debugging those modifications. Most device makers do not want to have to be bound by these terms. So to minimize the burden on these companies, we minimize usage of LGPL software in userspace.

this is the android licence. have you read the licence actually by yourself?

or you wish to argue and amuse me.

and then the GPL licence is here and so is the LGPL and also apache licence

http://www.apache.org/licenses/LICENSE-2.0

7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.

the BOLD "*fine print*" word is "NON-INFRINGEMENT".... did you really read
the licence?

which also means its upto the vendor to deny/grant you the complete source
code. period.

http://www.gnu.org/licenses/gpl-2.0.html

b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

so if you design your own libraries? then you may/may not distribute. But if
its based on the existing base then you MUST. my limited understanding tells
me this much only.

care to help me understand, what i am failing to understand?

i am not a lawyer and i am not educated enough to make an educated guess
that you really have "READ" and "understood".

now lgpl

https://www.gnu.org/licenses/lgpl.html

The “Minimal Corresponding Source” for a Combined Work means the Corresponding Source for the Combined Work, excluding any source code for portions of the Combined Work that, considered in isolation, are based on the Application, and not on the Linked Version.

this again according to me means they need not give it to us the complete
source and libraries necessary to you (general public) at all. and once
again if you think my weak english is unable to make me understand the
licence terms please feel free to do so.

and then again back to
http://source.android.com/source/licenses.html

For a corporation (or other entity) that has assigned employees to work on the Android Open Source Project, a Corporate Contributor License Grant is available. This version of the grant allows a corporation to authorize contributions submitted by its designated employees and to grant copyright and patent licenses. Note that a Corporate Contributor License Grant does not remove the need for any developer to sign their own Individual Contributor License Grant as an individual. The individual grant is needed to cover any of their contributions that are not owned by the corporation signing the Corporate Contributor License Grant.

i will assume that it means the same. well, we are not obliged to give you
everything. we will share what we like, we dont care. simple. period.

and now how is ARM's TZ is related to SELinux?

mmmmmm would you care to waste 283 KB of your download data bandwidth?

https://www.kernel.org/doc/ols/2007/ols2007v2-pages-79-86.pdf

pg 1 on the right hand side you will see something called as HAS or
hardware assisted security. and if i understand correctly has loads of s**t
to do with the ARM's TZ (trustzone).

and if you have the ARM's TZ NDA paper and the API you will see that
"OH YES IT DOES MATTER! A LOT."

HAS (hardware assisted security) has nothing to do with TZ and SELinux?
really thats news. and besides this is 2007 paper, hosted in kernel.org
since dec 2010.

if you read that paragraph which mentions HAS you will understand what it
says. i will again assume you have read and not heard from someone else
and i will assume that assumption that you have read.

its not your fault its the generic TLDR thingie....

"i'm sorry but the rest of what you've posted doesn't read well / make much sense...

we are not talking about hardware at all, and everything you posted has nothing to do with this discussion that I can see (although I respect the fact I could have misunderstood you). "

no sweat chill... ;-) here is a beer for you... and i explained how the
SELinux can be defeated straight up and also bootrom and bootloader
and everything. Its just a touch on info. there are papers which explains this
process in great in-depth and detail and beyond the scope of my explaination.

"we are talking about SELinux, which is a kernel security module addition, nothing more. it controls security on the software level, nothing more.

we are not talking about unlocking bootloaders or modifying them, which is what prevents new kernels from being flashed. we are strictly talking SELinux which has nothing to do with bootloaders or eeprom at all. "

i dont use selinux and i have stripped off the SELinux process completely
and i use grsec which is much better and doesnt have the three lettered
agencies like NSA/FBI/CIA etc etc et al.

"All that is being done by making SE enabled by default is making exploiting devices harder because apps can only access the permissions they need to perform their basic functions, therefore making the creation of exploit apps even tougher because their functions are denied by the kernel module. The truth is that SELinux has been in the linux kernel since 2.6 in 2003. Although it is now further evolved, it is not "new." "

yes please tell me in detail about it. I been fighting my lungs out with the
meego in nokia n950. Where the SELinux had a different name but same s**tty
objective.

"The reason SELinux is enabled by default now is because Google and OEMs are getting tired of end users deleting software that is bundled with their devices due to contracts they have with certain retailers and service providers. In order to always be in compliance of these contracts they have to keep the end user from modifying the device by any means necessary."

i must again hate to disagree. Its because users uses all kind of tweaked methods
to tweak the devices and their operational functionality. viz. Wifi, where a user
can enable channels more than 11 all the way to channel 14 in b/g zone which is
not legal in the US of the A. again we got FBI/CIA/NSA/DOE blah blah 3 lettered
agencies.

this been the major reason why some wifi routers are trip locked to regions
and even using openwrt we can open those wifi channels. Bluetooth is another.
and if you know about gnu radio. then you will know how the old baseband
firmware can be modified and then made to sniff and use it as a shadow BTS.

google up for more info.

"These new security measures are to keep end users from gaining root access and deleting bundled software, which includes Google apps (and other proprietary apps) that send information to Google servers. That is all."

partially right and also wrong because FCC doesnt want you go screwing around
thats number one and second because big brother likes to spy on you and lastly
big brother doesnt like you enjoy "freedom and privacy"

prism is awesome. how many people like prism? its wonderful isnt it? it splits
the white light into 7 colors. i love prism and its awesome.

what you dont know prism? no no i am speaking of that physics experiment of
splitting light using a prism and nothing else.

"you obviously are not familiar with the GPL... if a manufacturer doesn't release their kernel source then they are in violation of the GPL--however most OEMs do release the source... that's the beauty of linux and its kernel."

yes please help me understand the licence can you please. then i will stop
ruining my life by trying to port the ADSL driver to broadcom BCM63xx chipsets.
netgear is such an ass organization that they did a code drop with some
broadcom's IP source code. or conexant with their adsl driver for the conexant
adsl chipset and netgear again an ass organizations.

and i been like an idiot trying to port u-boot with the latest version so
the TP-Link TD-W8970 can boot freely and openwrt can be easily be ported with
out much nagging and serial console.

192.168.1.1 and upgrade firmware and yay, bye bye tp-link firmware & screw you
hello openwrt.

well that was fun. ;-)

i would really appreciate if you can baby walk me the GPL x.y.z and BSD a.b.c
and Apache l.m.n and tom-dick-harry 1abc.2xyz.infinityblah blah licence version.

english is not my mother tongue. So i guess i have difficulty understanding and
if thats so then i also do have difficulty in communicating.

thanks!
-paul

p.s. no hard feelings. no offence given none taken.
and once again TLDR because 80 chars/line

 

.

 

true. only reason i dont like apple products because they are way overpriced and
completely unjustified price.

but nonetheless CODYQX4 your post did lighten up the post. thanking you(r) post
without pressing the thank button. ;-)

FOSS and its licence and RMS's (at times/sometimes) wierd logic forces me
to blink and also along with that the licences from ODM/OEM.

and if i did offend anyone with my harsh words i offer my humble apologies.

and AFAIK apple releases the kernel code under APSL. which is nice. but many
things are well hidden still inside apple's strong hold bunker.

licence also stops us from doing a clean room reverse engineering.

thanks!
-paul

 

No hard feelings here either, just healthy discussion


I'm not going to post any more than this with regards to your discussions, duh...

i'm familiar with HAS, but you can't just string information together to try to make some point, which from what I see has not been made.

again, we are not talking hardware... we are talking selinux, which as of yet has not been implemented in the Android system to work in tandem with HAS. HAS is what verifies and in many cases prevents new kernels from being flashed and executed, and prevents things like bootloaders from being tampered with, with regards to Android.

as of now, SELinux is only used to prevent system level attacks and modifications in Android, nothing more. It prevents apps and users from gaining elevated privileges to perform malicious actions to the system and absolutely nothing more. If you would read any current info, even regarding Android 4.4, you will see that it doesn't do anything else at all, period, with regards to Android systems.

the paper you linked to clearly outlines this flaw in its current development and only provides an idea of how to make it work in tandem with HAS by virtualizing the execution of code in particular domains. nothing more. and all that nonsense you are posting about ARM's TZ has nothing to do with SELinux itself. You're stringing semi-related information together to make some point only you understand and that is not true with regards to SELinux's use in Android systems.

sorry, but do some more reading on SELinux. It's not dependent on HAS or anything to do with ARM's trusted zone, which are not and have not been a part of this discussion...

maybe you should read something about how SELinux is actually being used on Android systems from Google...

https://source.android.com/devices/tech/security/se-linux.html

 

i do agree with you here, even though I hate Apple and its practices.

Apple from quite some time has been against end-user modification of any kind and this is why they basically remove every possibility of customization from all their operating systems.

i guess since the user can't customize the system, they don't bundle crap with their devices so that the user feels they are manipulating the system by installing what they want idk

 

.

 

"I'm not going to post any more than this..."

your choice, and i dont rule you, not here to dictate either.

"i'm familiar with HAS, but you can't just string information together to try to make some point, which from what I see has not been made."

its pretty much clear then that you havent understood what
i am trying to say. i never said you are wrong. and then
with respect to SELinux. i dont use it and i disable it
when i roll my own kernel.

so obviously i cant speak neither in favor of SELiux nor
against SELinux. if i dont know something i have no right
to defend or attack that concept/notion.

"again, we are not talking hardware... we are talking selinux, which as of yet has not been implemented in the Android system to work in tandem with HAS. HAS is what verifies and in many cases prevents new kernels from being flashed and executed, and prevents things like bootloaders from being tampered with, with regards to Android."

if i recall correctly the TZ has a major role here. because
TZ cannot be altered easily. which even you are agreeing or may be not.
i am not able to understand your point clearly.

and i am not going against you. and IMO kernel flashing
almost has nothing to do here. and bootloaders?

which stage bootloader are you speaking of here? stage 1
or stage 2 loader. because both are distinct in their
function and also operation.

stage 1, inits the basic hardware and crypto functions and
hardware firewall. i am not sure if you know what i am
really speaking here.... i will assume you know what i am
speaking of here.

and HAS not yet implemented? really?
http://omappedia.org/wiki/Bootloader_Project
and more info on security and cryptanalysis here
http://droid-developers.org/wiki/Trust_Zone
http://droid-developers.org/wiki/L3_firewall
http://droid-developers.org/wiki/EFuse
http://droid-developers.org/wiki/Content for complete info
and bootloader tampering. awwwwwww dear...

http://droid-developers.org/wiki/Application_Processor_Boot_ROM
http://droid-developers.org/wiki/Baseband_Processor_Boot_ROM
so its not the bootrom of the application which has been tampered and
reverse engineered but also the baseband.

hello dude. you really need to update the info you are using in order
to defend your justification(s).

and oh yes by the way, i am trying to tamper and reverse engineer the n900
bootloader and when i am done with that i will try to tamper the baseband
n900's custom gsm radio IC.

"as of now, SELinux is only used to prevent system level attacks and modifications in Android, nothing more. It prevents apps and users from gaining elevated privileges to perform malicious actions to the system and absolutely nothing more. If you would read any current info, even regarding Android 4.4, you will see that it doesn't do anything else at all, period, with regards to Android systems. "

i am not denying that fact. and i am well aware of the functionality of SELinux
so thanks once again for the brush up. and regarding SELinux? my knowledge
which is ultra little cant cope up with it. SELinux i have never used and i
will never use it. Grsecurity works well with arm and its a long time
since grsec been ported to arm arch and i rather use grsec than selinux.

so i will give you the benefit of doubt, wrt to selinux. why because i
honestly dont know nor do i use SELinux, so i cant speak about it. i will assume
you know it better and much more indept than me. and i have no issue in
accepting info about something which i really dont know anything about.

so whatever you say here i will take for granted is correct and you have
expressed here to the best of your ability.

"the paper you linked to clearly outlines this flaw in its current development and only provides an idea of how to make it work in tandem with HAS by virtualizing the execution of code in particular domains. nothing more. and all that nonsense you are posting about ARM's TZ has nothing to do with SELinux itself. You're stringing semi-related information together to make some point only you understand and that is not true with regards to SELinux's use in Android systems. "

thats real news. i give up on this notion. what i understand and i need to
explain in a few lines will be :

SELinux has nothing to do with the bootloader, be it initial or later stage
tampering. thats number one. second point, if i can figure out the jtag pin out
with the emu0 and emu1 pins/pads then i can debug the SELinux.

have done a little, very little debugging with MIPS, mipsel and mipseb so
i can use the same logic to do the same with arm (armel/armeb/armhf/arm64).

if you have used a JTAG then you will know what i am talking about. if
no then forget it. its my fault.

given the fact that if you got a JTAG then you can very well do anything
under the stars and sun and anything and everything almost (except reverse
the e-fuse process, because once a specific voltage is passed e-fuse is no
longer editable).

so i dont know if you know about JTAG or have used JTAG, if you did? you would
not refend your idea so blindly.

"sorry, but do some more reading on SELinux. It's not dependent on HAS or anything to do with ARM's trusted zone, which are not and have not been a part of this discussion...

maybe you should read something about how SELinux is actually being used on Android systems..."

i dont use SELinux and i dont care about SELinux. and if i ever come across
any arm arch which has this s**tty feature? i will hunt for the jtag pin outs,
i will modify or tamper (your worded/coined phrase) the first stage bootloader
and second stage bootloader and read the PKI keys, and padd the bootloader and
then roll my own kernel with all patches possible and then a wipe clean the
device and install the OS of my choice. and forget about warranty, its void
anyway.

*PROVIDED I BUY ANY s**tTY ARM PHONE WITH SELINUX INSTALLED/ENABLED*

"https://source.android.com/devices/tech/security/se-linux.html"

See above. i dont care about SELinux. and i will readily tamper the bootroms
and do the rest as needed.

because all i know is one thing, where there is JTAG there is always a way
(to defeat all these mechanism, thanks but no thanks SELinux)

besides this is an arguement, and you have the right to defend your notion
and likewise i have the right to object provided i have enough evidence and knowledge
to disprove you.

thanks!
-paul

 

" I have posted 'nobody can remove SELinux'. I actually don't like absolute statements, because no-thing is absolute."

very well said. like a politician. playing it safe. but sticking to topic, folks at replicant android are working on it.

"Sure for proof of concept I guess it is possible.. so the correct answer would be sure it can be removed sooner or later with a lot of efforts.... but that is not the point.

The point is that nobody of the 'ordinary' users can!
It seems we here have more than average knowledge concerning the Android system. BUT WE are a minority!!! I mean how many percent of devices are rooted at all, for instance?"

thats why we are helping those 'ordinary' users with these projects. where we take the time and effort
to dismantle the dream of these OEM/ODM to completely control the end user's device.

BUT THOSE minority users, need our help so that they can help themselves.

That doesn't makes us above ordinary or special or super human. we are ordinary too.

And rooting its a matter of taste. Do users wish to root the device?

"And it seems one must to be 'over average skilled' to get rid of their stuff..so to say to realize personal freedom!!! That is the point.
We can discuss on this level and have fun."

thats the reason we started replicant android. please pay a visit at our project.

indeed we are slow compared to bleeding edge android distro, but this process of
reverse engineering takes a lot of time.

"I am familiar with decompiling apps / smali / baksmali, styling, initramfs / kernel / recovery, framework, systemUI, services.jar and so on...but I cannot program..I have added CWM to stock kernel's initramfs at my SGS1, that's all...and of course applied CWM update zips and easy scripts...
I have made my own 'theme'. BUt that is all I cannot do more and have not the time to do more..."

hehehe, amazing, you went to do all that. no s**t skerlock! ;-)

why because these devices we are targetting not just for one OS like android,

we are trying to make it open to as many OS as possible. i am working on porting
debian to these devices.

"Anyway I opened the thread SELInux and Samsung KNOX has been mentioned as well. Even IF one would be able to remove SELInux from the kernel there is still the bootchain itself..here again the link: http://blog.azimuthsecurity.com/2013/05/exploiting-samsung-galaxy-s4-secure-boot.html

In summary, each stage of the boot process cryptographically verifies the integrity of the subsequent stage, with the trust root originating in QFuse values...."

thats why i posted the info on cryptanalysis and modification of the bootrom.

there are 2 stages of booting in ARM.

ROM-CODE (rtos) kinda thingie -> IBL or initial bootloader -> SBL or second stage bootloader -> Kernel

ROM-CODE exploitation is impossible w/o physically attacking the chip.

yes we are speaking of treating the cpu with concentrated sulphuric acid and nitric acid
(siliconpr0n) and then use the wire joints to read the data and reverse engineer it even get
the vlsi/vhdl design.

i guess the qfuse is the same as TI's e-fuse. there are 2 types of chipsets of the same cpu
chip. one is development one and other is production one. and in TI's term first one is called
GP or general purpose and second is HS or high security. the only different is a HS got
e-fuse.

so if you can modify the IBL and padd the crypto hashes and signatures, then it will just
check and match the signature from rom-code and then verify the IBL and pass on the
instruction to SBL and the SBL will then boot the kernel. no magic simple logic.

"It can become far worse....the boot process can just stop to go on at future devices if the kernel signature does not match anymore....parts which are verified at different boot stages can be open source or not..they just don't run when not officially signed.
AT my particular case, should one be able to remove SELinux, it surely would trigger the e-fuse..and that is just the beginning."

you are wrong again. like i said before if you can alter the IBL binary and also if it checks
and verifies with the rom-code and then hands the next stage to SBL.

so if you can modify the IBL or IL then SBL or SL will boot without any issue and the
kernel will be loaded with any salsa dancing. hence kernel signature has no maor role.

and e-fuse is a small eeprom present inside the cpu and that gets blown off inside the
factory itself. right after the first stage assembly. it passes a specific voltage and the
connectivity path is broken.

more info here
http://forum.xda-developers.com/showpost.php?p=30934500&postcount=7

thus your e-fuse get broken in the factory assembly line right at the first stage and
there is no reversing process, if you screw up then you need to either discard the
board or take the pain of redoing assembly again.

"On Exynos Samsung’s own it is possible to make a full dump of any partitions and to re-apply the sboot.bin and param.bin to restore KNOX flag since it is found on eMMC, but not on QUALCOMM’s Snapdragons..."

really? hehehe, once again, no s**t sherlock!
http://www.psdevwiki.com/ps3/KLMAG2GE4A-A001 if you can rip the eMMC out?
then using this reader you can squeeze all the information out. i know it because
i am doing this on my blackberry playbook.

so i am planning to fabricate the pcb again and then solder the parts again and
time to playyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy with my playbook.

everything is torn apart or ripped apart cpu with ram on top of cpu, emmc, all filters
and circuits and graphics IC and other various IC and tonnes of caps and ress.

"So in summary it does not matter what we can do. It does not matter if one can remove SELinux. The majority cannot.

The majority of users are ‘addicted’ to their devices and use anything that google provides.
Whilst time goes by, they are enforcing their security stuff, they only allow to run their signed stuff, and that completely destroys the idea of open source. In other words google is just another imperialistic bloodsucker who wants only money and control. "

i will not say a character against you on this. i whole heartedly agree with you and being
in the industry this long makes me know the bloodsuckedupness even more realistic.

and it cannot destroy us, US = FOSS, we are united (with a little difference in opinion)
we are there and we will ruin their dream of imperialistic complete command and control.

we are here to help the ordinary user, like you and me. yes we are ordinary too just like
everyone else. we are here, all we need is a little time. but we will shatter their dreams.

why? because we just love to rape their wet dreams.

thanks!
-paul

 

@Yen I think before we all start pulling on tin foil hats, we should first look at why Google wants more security. I think Google is trying to pick up from where Blackberry fell down when Android pulled the rug from under their feet. Blackberry is still used a lot by corporate and government users who still go with the idea that Blackberry is more secure than Android, which it is ! If you have ever been involved in business you would know that sitting on your backside is akin to suicide. It's all about mind share, which should lead to market share.