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

Discussion in 'Serious Discussion' started by Yen, Apr 25, 2014.

  1. duh

    duh MDL Member

    Jan 20, 2009
    143
    15
    10
    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 :D

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

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

    thanks!
    -paul
     
  2. stayboogy

    stayboogy MDL Addicted

    May 1, 2011
    774
    140
    30
    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.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. stayboogy

    stayboogy MDL Addicted

    May 1, 2011
    774
    140
    30
    #23 stayboogy, May 15, 2014
    Last edited: May 15, 2014
    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...
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  4. Yen

    Yen Admin
    Staff Member

    May 6, 2007
    12,874
    13,628
    340
    #24 Yen, May 15, 2014
    Last edited: May 15, 2014
    (OP)
    No, you've got me wrong.:)

    You are right I totally agree with you on XDA there a lot of noobs talking BS so to say...:biggrin:

    With removing google I meant google itself....the company...google will ever release android source code (I do not talk about Gaps), they have intentions so they developed together with the NSA SELInux concept.
    Nobody can remove SELInux from Android 4.4!!!
    Even if one could totally modifiy the system, nobody can do it from scratch and has to USE google's code.
    You are always dependent on google and what they are doing.

    That's is what I wanted to point out with to get rid of google...(the thread is about SELinux)...
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  5. stayboogy

    stayboogy MDL Addicted

    May 1, 2011
    774
    140
    30

    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.)
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  6. duh

    duh MDL Member

    Jan 20, 2009
    143
    15
    10
    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. :D 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!" :D if you dont like this post ask mods to delete this post.
    no offense given and none taken.
     
  7. duh

    duh MDL Member

    Jan 20, 2009
    143
    15
    10
    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
     
  8. stayboogy

    stayboogy MDL Addicted

    May 1, 2011
    774
    140
    30
    #28 stayboogy, May 15, 2014
    Last edited: May 15, 2014
    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.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  9. duh

    duh MDL Member

    Jan 20, 2009
    143
    15
    10
    "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
     
  10. CODYQX4

    CODYQX4 MDL Developer

    Sep 4, 2009
    4,814
    45,774
    150
    #30 CODYQX4, May 15, 2014
    Last edited: Apr 12, 2019
    .
     
  11. duh

    duh MDL Member

    Jan 20, 2009
    143
    15
    10
    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
     
  12. stayboogy

    stayboogy MDL Addicted

    May 1, 2011
    774
    140
    30
    #32 stayboogy, May 15, 2014
    Last edited: May 15, 2014
    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
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  13. stayboogy

    stayboogy MDL Addicted

    May 1, 2011
    774
    140
    30
    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
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  14. CODYQX4

    CODYQX4 MDL Developer

    Sep 4, 2009
    4,814
    45,774
    150
    #34 CODYQX4, May 15, 2014
    Last edited: Apr 12, 2019
    .
     
  15. duh

    duh MDL Member

    Jan 20, 2009
    143
    15
    10
    "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. :D

    thanks!
    -paul
     
  16. Yen

    Yen Admin
    Staff Member

    May 6, 2007
    12,874
    13,628
    340
    I very enjoyed to read the new posts here, but what is missing...
    I have posted 'nobody can remove SELinux'. I actually don't like absolute statements, because no-thing is absolute.:)
    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?

    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.:)
    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...:biggrin:

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

    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.

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

    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.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  17. duh

    duh MDL Member

    Jan 20, 2009
    143
    15
    10
    " 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. :D 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! ;-) :D

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

    "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! :D;)
    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. :D

    "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. :D;)

    thanks!
    -paul
     
  18. Yen

    Yen Admin
    Staff Member

    May 6, 2007
    12,874
    13,628
    340
    #38 Yen, May 20, 2014
    Last edited: May 23, 2014
    (OP)
    Actually I have to say it is an illusion. Google / device manufacturers will enforce what they want regardless of what a minority will and can do.
    The ‘success’ is temporary, your success will be temporary.
    The success is a personal thing, the feeling is great to have a global player taken for a ride.

    I do not say it isn’t a good feeling to kick them by exploiting their stuff or using a flaw.
    I had been very involved in mimicking OEM activation of windows. It was a lot of fun.

    Anyway it changes nothing concerning the future of the devices, the imbalance of power will persist, the false idea of security and control will persist.

    There are different kinds of people.
    People who are not aware of the tech details and simply trust what Google / device manufacturers are offering. And that are by far the most.

    People who are aware and are using customized ROMS.
    People who research and try to break stuff.

    People who are not aware of something ‘bad’ are not affected..

    As soon as one can still run any custom rom it is no problem to me personally.
    It becomes a problem as soon as the boot chain stops if a fuse is triggered, or even one cannot flash a custom ROM at all.

    Yen: “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: “…you are wrong again. like i said before if you can alter the IBL binary and also if it checks…”


    How should I flash the tampered bootloader? In ‘download’ mode current ‘OS’ if an OS at all, controls the contents (new bootloader) to be flashed and already triggers the fuse.

    Without ‘external’ access to the boot partitions nobody can change a thing.
    And it will be never a solution for the masses….devices are changing quickly. They imply to the consumer you have to be cool and get the latest stuff, best every year a new smartphone.
    How should people be able to analyze one particular device and find a way to break stuff before the device is outdated?


    There is only one way to shatter their dreams (which is not as much fun as to break stuff :D), never to buy any device anymore where the OEM cooperates with US companies ......correct me if I am wrong.

    A Chinese phone is an alternative...why should one break stuff made by paranoids when I can get anything without that cr*p from the Chinese?!? On Chinese devices with MediaTek MTK CPUs I even can change the IMEI (and other IDs) anytime I want and I guess they don't care about NSA 'security' concepts.......:D

    Ever thought about to realize your projects on Chinese devices?
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  19. Yen

    Yen Admin
    Staff Member

    May 6, 2007
    12,874
    13,628
    340
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  20. R29k

    R29k MDL GLaDOS

    Feb 13, 2011
    5,119
    4,743
    180
    @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.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...