Database Info

Possible backdoor loader?

Using Anycut, select Activity, and in there choose "Device info". This tells you all the build related info, and on the bottom there is a way to check for new builds depending on your "build type". Maybe if using the wifi IP settings forced it through a proxy, where we would sniff the request. Possibly see if there are builds (beta?) we could load, or redirect it to a custom build?

worldestroyer said:
Using Anycut, select Activity, and in there choose "Device info". This tells you all the build related info, and on the bottom there is a way to check for new builds depending on your "build type". Maybe if using the wifi IP settings forced it through a proxy, where we would sniff the request. Possibly see if there are builds (beta?) we could load, or redirect it to a custom build?
Click to expand...
Click to collapse
Great find

We should start a list... I will even keep all the data in a spread sheet if everyone can give me all the info
Build Description
Build ID
Build Date
Build Type
Build User
Build Host
Linux Kernal version
Baseband Version
RIL Impl version
Android ID

G1 back door updater
I have a G1 without the update... I also have adb shell access to it and succesfully ran bash and busybox on it. I know where all the partitions are in the filesystem (mtdblock1-5) and where the kernel resides (boot is mtdblock2).
When the upgrade comes out, I will sniff the packets and let you guys know (and possibly even put the upgrade file up for download somewhere).
Build Description
kila-user 1.0 TC4-RC19 109652
ota-rel-keys, release-keys
Build ID
TC4-RC19
Build Date
Sat Sep 13 00:11:34 PDT 2008
Build Type
user
Build User
android-build
Linux Kernel version
2.6.25-01828-g18ac882
[email protected] #1
Thu Sep 11 23:18:27 PDT 2008
Baseband Version
62.33.20.08H_1.22.12.28
RIL Impl version
HTC-RIL 1.0 (Aug 19 2008, 21"32:33)

damien667 said:
I have a G1 without the update... I also have adb shell access to it and succesfully ran bash and busybox on it. I know where all the partitions are in the filesystem (mtdblock1-5) and where the kernel resides (boot is mtdblock2).
When the upgrade comes out, I will sniff the packets and let you guys know (and possibly even put the upgrade file up for download somewhere).
Build Description
kila-user 1.0 TC4-RC19 109652
ota-rel-keys, release-keys
Build ID
TC4-RC19
Build Date
Sat Sep 13 00:11:34 PDT 2008
Build Type
user
Build User
android-build
Linux Kernel version
2.6.25-01828-g18ac882
[email protected] #1
Thu Sep 11 23:18:27 PDT 2008
Baseband Version
62.33.20.08H_1.22.12.28
RIL Impl version
HTC-RIL 1.0 (Aug 19 2008, 21"32:33)
Click to expand...
Click to collapse
The upgrade will download at various times... it will ask you to update after it has downloaded.
BTW I added two fields I forgot. Build Host (I am wondering if this is different for some and that is how they get updates) and Android ID (also wondering if this has to do with updates.)
Here is my info
Build Description
kila-user 1.0 TC4-RC19 109652
ota-rel-keys, release-keys
Build ID
TC4-RC19
Build Date
Sat Sep 13 00:11:34 PDT 2008
Build Type
user
Build User
android-build
Build Host
undroid13.corp.google.com
Linux Kernel version
2.6.25-01828-g18ac882
[email protected] #1
Thu Sep 11 23:18:27 PDT 2008
Baseband Version
62.33.20.08H_1.22.12.28
RIL Impl version
HTC-RIL 1.0 (Aug 19 2008, 21"32:33)
Android ID
200145da5528c72d

Important information vs useless information
What is useless information is the serial numbers or which machine built your ROM image.
What IS NOT useless, and VERY important, is the ip address and/or domain name where the update file is downloaded from as well as the location of said file on said server, as well as the file name itself.
With that information, we could technically cook our own updates to the firmware if we figure out how to build one, simulate the updating server on a local network, and spoof the phone into thinking it's receiving a legit update when it's actually putting a cooked update onto itself... no need for root access to update the phone!
I read that you will receive a text message with a "download now" button to proceed with the update... if this is true, I can capture the entire traffic sequence of said update and we can emulate it on a local network.
I've tried some preliminary tests using the AnyCut app to open the page to force a "check for updates" and see what server it connects to but could not sniff packets from my wired LAN to my wireless LAN... I will try to sniff the packets straight on my linux router next time and see if I can tell who the phone talks to to check for updates.
If anyone wants to help, that would be excellent.

damien667 said:
What is useless information is the serial numbers or which machine built your ROM image.
What IS NOT useless, and VERY important, is the ip address and/or domain name where the update file is downloaded from as well as the location of said file on said server, as well as the file name itself.
With that information, we could technically cook our own updates to the firmware if we figure out how to build one, simulate the updating server on a local network, and spoof the phone into thinking it's receiving a legit update when it's actually putting a cooked update onto itself... no need for root access to update the phone!
I read that you will receive a text message with a "download now" button to proceed with the update... if this is true, I can capture the entire traffic sequence of said update and we can emulate it on a local network.
I've tried some preliminary tests using the AnyCut app to open the page to force a "check for updates" and see what server it connects to but could not sniff packets from my wired LAN to my wireless LAN... I will try to sniff the packets straight on my linux router next time and see if I can tell who the phone talks to to check for updates.
If anyone wants to help, that would be excellent.
Click to expand...
Click to collapse
HTC is already telling people how to cook your own rom. I want to know how they go about deciding who gets the updates and when... are the build hosts all the same? or do they differ? is our ID sequential? does it mean something? At this point I don't think there is any useless info... we don't know enough about the entire process.
I will see what I can sniff in wireshark but I am not sure. I would really like to get my hands on a prerelease version and find out it's info.

HTC takes the Android SDK with kernel and rootfs, compiles it with the ARM toolchain, adds the proprietary t-mobile stuff, and makes an image to flash onto the phone. All of this information AND sourcecode is available from Google's GIT repository in the android SDK sourcecode. You can find it all here:
http://git.source.android.com/?p=platform/vendor/htc/dream.git;a=tree;h=refs/heads/master;hb=master
Since this phone goes through t-mobile, they are the ones who decide the updating process and order. According to their forums it's random.
http://forums.t-mobile.com/tmbl/board/message?board.id=87&thread.id=8855&view=by_date_ascending&page=1
The point is to get a back door into the root shell account so we can run whatever code we want on the phone as the root user... this will give us the ability to put a home-cooked android compilation on the phone if we so pleased.
Another way to do this is to figure out how the bootloader works on the phone and somehow tell it to boot up from a kernel in the sd card instead of the one in the ROM.

... I read that google was responsible for deploying the updates and that is why it is random. I think it is because they use your android ID not your IMEI or any other number. And I bet all our android ID's have similarities.
BTW... I ran the debug client and the FOTA is cancelled by the server. It then crashes. So I am guessing what we are doing isn't working. There must be something else.

I have my G1 connected over wifi to my network. Using Cain to arp poison and wireshark to sniff.
Sorry to say, but I saw this one coming...the "call home" is encrypted via TLS/SSL.
Mine was contacting Google at 74.125.19.102. I captured the ssl cert. You can get a copy of it here: http://rapidshare.com/files/158237323/74.125.19.102.crt.html
More info to come

I figured it would call google.... but google sends an abort to my device. I know what classes it uses to call home... maybe we can figure it out in there.

Caught something interesting. Apparently when it calls home, its gives google quite a bit of information. I have censored some of it, such as IMEI, serial number, etc
Code:
POST /checkin HTTP/1.1
Content-type: org/x-json
Content-Length: 271
Host: android.clients.google.com
Connection: Keep-Alive
User-Agent: Android-Checkin/1.0
{"imei":"***************","checkin":{"build":{"bootloader":"0.95.0000","serialno":"************","carrier":"tmobile","radio":"62.33.20.08H_1.22.12.28","revision":"128","id":"tmobile/kila/dream/trout:1.0/TC4-RC19/109652:user/ota-rel-keys,release-keys","product":"trout"}}}HTTP/1.1 200 OK
Date: Tue, 28 Oct 2008 05:01:58 GMT
X-Content-Type-Options: nosniff
Expires: Tue, 28 Oct 2008 05:01:58 GMT
Cache-Control: private, max-age=0
Content-Length: 102
Content-Type: text/html
Server: GFE/1.3
{"stats_ok":true,"time_msec":1225170118172,"intent":[{"action":"android.server.checkin.FOTA_CANCEL"}]}

I dont think this feature is going to help us. It just looks like a way for the phone to call home. Now if somebody can get a full capture of the update when its transferred, then we might have something useable.

I don't think we even need to sniff it... I just think we need to dump it from the device. My device has a file in its firmware folder... hmmm

neoobs said:
I don't think we even need to sniff it... I just think we need to dump it from the device. My device has a file in its firmware folder... hmmm
Click to expand...
Click to collapse
How did you find that out?

used ADB to browse my files

The checkin mentions keepalive, might this just be a keepalive for push services?
I don't like how it's sending all of the phone's info w/ just ssl. You could conceivably swipe someones IMEI and serial no. and send a keepalive, I wonder what you would start getting if you did that...
I would prefer a session key hashed w/ time w/ a public key from Google. That would do, right?
Whatever... This kind of bothers me.

I have the certs from my phone that I pulled. Wonder if that will help.

The data I got was not encrypted! There was some other information that was encrypted that I havent tried to crack.
Unless wireshark decrypted the data on the fly (which I dont think it did), the data I retrieved was NOT encrypted.

damien667 said:
HTC takes the Android SDK with kernel and rootfs, compiles it with the ARM toolchain, adds the proprietary t-mobile stuff, and makes an image to flash onto the phone. All of this information AND sourcecode is available from Google's GIT repository in the android SDK sourcecode. You can find it all here:
http://git.source.android.com/?p=platform/vendor/htc/dream.git;a=tree;h=refs/heads/master;hb=master
Since this phone goes through t-mobile, they are the ones who decide the updating process and order. According to their forums it's random.
http://forums.t-mobile.com/tmbl/board/message?board.id=87&thread.id=8855&view=by_date_ascending&page=1
The point is to get a back door into the root shell account so we can run whatever code we want on the phone as the root user... this will give us the ability to put a home-cooked android compilation on the phone if we so pleased.
Another way to do this is to figure out how the bootloader works on the phone and somehow tell it to boot up from a kernel in the sd card instead of the one in the ROM.
Click to expand...
Click to collapse
I am no linux guru......but why not write a backdoor into the kernel if we have the source?? I dont think i know C , nor linux system programing enough to do this...but it seems relatively easy.
or we could always wait for an exploit for the 2.6.25 kernel and then compile it for the android.
I would personally love to be able to use the nice andriod ui, but have the ability to pop a root shell and run all of the linux code i have come to love.

Donut 1.6 Official system images for ADP1 now available!

Hi,
Some people on the forum probably noticed it already before me, but tweets from Cyanogen and JBQ brought it to my attention that the official Android 1.6 system images for the ADP1 are now available for download from HTC:
http://developer.htc.com/adp.html
I haven't installed them yet because my unofficial Cyanogen build is probably better than those in a number of ways ;-) But I did download them.
Also, these are probably required to build a real & working Donut 1.6 build from the AOSP tree.
Cheers everyone, and enjoy!
--Tim

Just wondering couple things:
1. Does it have Google Apps?
2. Do you loose root if you install this?
3. Does it mess-up recovery image?
So did anyone try it yet?

Hi Karolis,
I haven't checked the contents of the images but I expect them to have the Google apps. The 1.5 images from the same site contained them, as far as I know.
Whether or not it messes up the recovery image depends on the method of installation you choose, but you can always put back the recovery image of your choice on your ADP1.
I don't know about losing root access or not. I've heard people claim that it depends on your recovery image used. It will not include the SuperUser application but you can install that manually.
Cheers,
--Tim

HTC is an authorized Google distributer I guess:
# Use of the Google Software by You
1. You agree to use the Google Software only for purposes that are permitted by (a) this License Agreement and (b) any applicable law, regulation or generally accepted practices or guidelines in the relevant jurisdictions (including any laws regarding the export of data or software to and from the United States or other relevant countries).
Click to expand...
Click to collapse
I'm going to flash just the system image and see how it goes...

Didn't wipe, going from CM 4.1.11.1 to 1.6 - boot looped.
Finally got back to recovery (Cyanogen Recovery gone!) and wiped cache + user data, and at least got it to boot. Phew!
Better get Cyanogen's recovery back pronto, so I can restore my nandroid backup.
/Mats

dude.... dont use the OTA, use fastboot and fastboot flash boot and system and reboot -w. The reason it requires a wipe is because of the differences in frameworks, apps, dependencies, ramdisks, etc.
I was waiting for this, this is going to be my default now. I don't like all the stuff Cyanogen does to builds, I preffer the official ADP builds 1000's times more.
---edit----
I flashed it right away and now I'm confused. It's 1.6 alright, but the build is different from previous ADP builds, no dev tools or spare parts or anything else. This is almost exactly what you'd probably get from a stock 1.6 build, weird...

BTW, you don't lose root with this, ADP builds are meant to be rooted, you know?

can someone confirm if you lose cyanogen's recovery image?

···
这个还不错··希望走点出update包····but··我最期待cm 4.2···

Agh someone plz post a 32a version

Gosh, what a mess. After finally getting CM recovery back in, I went for a nandroid restore, but instead made a nandroid backup, overwriting my precious backup of my phone as it was before embarking on this 1.6 adventure. Well, after reinstalling CM 4.1.11.1 (hush - I had a backup on my SD card!) at least I got all my apps back.
Why must I dive into stuff like this when I'm in a rush and really don't have the time for it?
/Mats

I don't understand. Why such interest in this build when it specifically states this is for ADP (Android Development Phones) ONLY!
If you do not OWN an ADP1, then please, this thread has NOTHING for you of interest.

marty22877 said:
can someone confirm if you lose cyanogen's recovery image?
Click to expand...
Click to collapse
You wont loose it if your flash the new system and boot partitions via fastboot. Any of the Apps 2 SD stuff won't work though.

elzee said:
I don't understand. Why such interest in this build when it specifically states this is for ADP (Android Development Phones) ONLY!
If you do not OWN an ADP1, then please, this thread has NOTHING for you of interest.
Click to expand...
Click to collapse
????
Aaaanyway... I noticed this build doesn't let you su (wrong uid for the su binary), but that can be fixed easily, just pull su and Superuser.apk from another build, boot your phone into recovery, and push su to /system/bin and Superuser.apk to /system/app, then chmod 4755 /system/bin/su and reboot.
---edit--
you might also want to rm /system/xbin/su, but I don't know if it's really necessary or not. Gonna try it.

ok, removing xbin/su did nothing apparently, so it's safe. Keep in mind though that the stock boot.img is doesn't allow you to adb remount, but you can still adb shell, then su, and then remount manually (mount -o rw,remount /system). We just need to change ro.secure in it and we're good to go.

Using fastboot to only flash boot and system worked perfectly fine for me.
Very nice and clean.
Apps2sd can still be had if you want to, just do it the manual way (creating symlinks).
Pushing the xda versions of Launcher and Messaging makes the phone very, very nice - and the only things that I feel I'm missing is the userinit.sh and compcache really....I never really noticed/cared too much about the BFS.
Pretty nice build to be honest....

elzee said:
I don't understand. Why such interest in this build when it specifically states this is for ADP (Android Development Phones) ONLY!
If you do not OWN an ADP1, then please, this thread has NOTHING for you of interest.
Click to expand...
Click to collapse
Because the G1 and ADP1 are both identical Dream handsets? And people want an official donut, rather than 1.5 with many donut features hacked in?

just wondering, will this work with rooted Dream Phones???

bootloader
i'm getting error message updating from 1.5 adp crc1:
Bootloader Version...: 1.33.2005
Baseband Version.....: 2.22.19.26I
Serial Number........: HT847GZ00498
--------------------------------------------
checking product... OKAY
checking serialno... OKAY
checking version-bootloader... FAILED
Device version-bootloader is '1.33.2005'.
Update requires '1.33.2004' or '1.33.0004' or '0.95.3000' or '0.95.0000'.
Click to expand...
Click to collapse
i have a adp phone.
tried to roll back to stock 1.5 img or ota, same issue, is someone had this issue?

@ anyone who tried this. Which build number is this? Is it newer than 1.6_r1 (DRC79) or should I keep building the experiemental tree?

[Q] LG-AS730 -- Instructions to root

This is our first Android device: LG-AS730 – Optimus Select (for carrier Revol)
-
SCR Version: AS73010b_Revol
Software version: AS73011A
Andriod version: 4.0.4
Kernel version: 3.0.8
OUR GOAL:
Root the phone for security reasons in addition to getting rid of all the bloat and/or unwanted apps. We don’t like syncing, or the sharing and storing of our data (cloud). We do however respect open source. That said, we have never rooted, see above, “our first android device”. What is in place, if anything to accomplish our goal –without loosing functionality and/or bricking our device?
-
Our XDA search term “LG-AS730”, and “AS-730” yields no results at this point in time.

Root AS730 / Development
This method will work for the AS730.
http://forum.xda-developers.com/showthread.php?t=1886460
Be aware our phone has a locked bootloader + CRC Check, which means if you remove certain system apps, you will be greeted with a "Security Error" message on system start, resulting in a shiny new brick.
I already bricked mine, and luckily I still has a couple days left on my 15 day warranty with Revol to get a replacement ( I said it was an update gone wrong )
(After which, I found the .cab file on the LG server to hopefully restore (Haven't verified yet))
I'm currently looking into ways to remove the CRC check.
I'll be making a post soon with an attached .cab / other information on our device.
It just sucks our device has almost no documentation or development.
If anyone would like to help with development or anything, PM me.

veris said:
This method will work for the AS730.
http://forum.xda-developers.com/showthread.php?t=1886460
Be aware our phone has a locked bootloader + CRC Check, which means if you remove certain system apps, you will be greeted with a "Security Error" message on system start, resulting in a shiny new brick.
I already bricked mine, and luckily I still has a couple days left on my 15 day warranty with Revol to get a replacement ( I said it was an update gone wrong )
(After which, I found the .cab file on the LG server to hopefully restore (Haven't verified yet))
I'm currently looking into ways to remove the CRC check.
I'll be making a post soon with an attached .cab / other information on our device.
It just sucks our device has almost no documentation or development.
If anyone would like to help with development or anything, PM me.
Click to expand...
Click to collapse
Glad to see that my excuse works in other places xD. I do have a rooted System.img, just no way to flash it to the phone. (At least, I believe I still have the rooted system.img file). With our model, LG Mobile Phone Support Tool doesn't decompress a system.img.ext4 while flashing which is what caused my brick. I tried splicing back together a BIN file and literally ****ed the partitions.

??
AS_730 said:
This is our first Android device: LG-AS730 – Optimus Select (for carrier Revol)
-
SCR Version: AS73010b_Revol
Software version: AS73011A
Andriod version: 4.0.4
Kernel version: 3.0.8
OUR GOAL:
Root the phone for security reasons in addition to getting rid of all the bloat and/or unwanted apps. We don’t like syncing, or the sharing and storing of our data (cloud). We do however respect open source. That said, we have never rooted, see above, “our first android device”. What is in place, if anything to accomplish our goal –without loosing functionality and/or bricking our device?
-
Our XDA search term “LG-AS730”, and “AS-730” yields no results at this point in time.
Click to expand...
Click to collapse
Do u have the original rom

[ROM][Development] NEC Terrain custom ROM

Hello!
This is a development thread for those who is ready to contribute to the creation of a custom ROM for NEC Terrain.
The prior steps, which are bootloader unlock, rooting and even repartitioning have found their solutions and can be found in:
http://forum.xda-developers.com/showthread.php?t=2515602 for the discussion
https://github.com/x29a/nec_terrain_root for an apk which opens for you an ability to have the system area of the phone writeable
https://github.com/alex-kas/nec_terrain for the last ideas on how recovery and boot images should look like and the repartitioning
So, all questions regarding all the above should be asked in that thread as they are off-topic here.
For more general questions regarding the present rom, programs to disable, features and current bugs/oddities, please, see
http://forum.xda-developers.com/general/help/q-nec-terrain-discussion-t3162070
Thanks for understanding the thread aim and welcome to development!

Found this CWM recovery creator online. Apparently you can just upload the recovery img that comes with a phone and it will generate/build a recovery based on that. Worth a try?
EDIT: Here's the link. Apparently it is necessary for some phones to upload additional files to get the recovery to work properly. I'll look into it when I start to build this thing
https://builder.clockworkmod.com/
Sent from my LG-D415 using XDA Forums

alright......so ADW launcher is very very unstable with this ROM. Basically spontaneous reboot every 30min or so.
I need 5 panels, and the stock launcher can add them, but it always make the second panel default, which is very annoying.
So which launcher do you guys prefer?

Have I found?
Unfortunately this builder does not spit output ...
I got a strong impression the Terrain is reduced CasioCommando with qwerty. @MrMEEE, I suggest to investigate this direction. The later phone is reported to have both: custom roms and custom kernel. xda has developments on this.
This guess is NOT because NEC is Casio, this is because I found that both phones use for some unknown device the so called ktrc_driver.ko kernel module and the only device apart from Terrain which I could spot by google is CasioCommando. Then, of course, accounting that NEC is Casio I make this conclusion.
Also the boot of Terrain contains commands and even kernel modules references that do not exist. I have a gut feeling that devs were in rush and just were porting some system from another phone.
EDIT: I found a binary custom recovery for commando and so far it is the ONLY recovery which comes to some graphical image! I learned that graphics is device-dependent and presence of some colored points suggests that the graphics driver is correct. One just need to adjust the resolution ... This supports my theory that commando may be the prototype for the kernel.
Will try also to look into all of that.

alex-kas said:
Unfortunately this builder does not spit output ...
I got a strong impression the Terrain is reduced CasioCommando with qwerty. @MrMEEE, I suggest to investigate this direction. The later phone is reported to have both: custom roms and custom kernel. xda has developments on this.
This guess is NOT because NEC is Casio, this is because I found that both phones use for some unknown device the so called ktrc_driver.ko kernel module and the only device apart from Terrain which I could spot by google is CasioCommando. Then, of course, accounting that NEC is Casio I make this conclusion.
Also the boot of Terrain contains commands and even kernel modules references that do not exist. I have a gut feeling that devs were in rush and just were porting some system from another phone.
EDIT: I found a binary custom recovery for commando and so far it is the ONLY recovery which comes to some graphical image! I learned that graphics is device-dependent and presence of some colored points suggests that the graphics driver is correct. One just need to adjust the resolution ... This supports my theory that commando may be the prototype for the kernel.
Will try also to look into all of that.
Click to expand...
Click to collapse
Probably explains why we have an HDMI selector in the build.prop, huh...
But wow, that's an astounding discovery! Never would have guessed NEC = Casio. I believe there are 2 Casio Commandos, I assume you are referencing the newer one?
Sent from my LG-D415 using XDA

alex-kas said:
Unfortunately this builder does not spit output ...
I got a strong impression the Terrain is reduced CasioCommando with qwerty. @MrMEEE, I suggest to investigate this direction. The later phone is reported to have both: custom roms and custom kernel. xda has developments on this.
This guess is NOT because NEC is Casio, this is because I found that both phones use for some unknown device the so called ktrc_driver.ko kernel module and the only device apart from Terrain which I could spot by google is CasioCommando. Then, of course, accounting that NEC is Casio I make this conclusion.
Also the boot of Terrain contains commands and even kernel modules references that do not exist. I have a gut feeling that devs were in rush and just were porting some system from another phone.
EDIT: I found a binary custom recovery for commando and so far it is the ONLY recovery which comes to some graphical image! I learned that graphics is device-dependent and presence of some colored points suggests that the graphics driver is correct. One just need to adjust the resolution ... This supports my theory that commando may be the prototype for the kernel.
Will try also to look into all of that.
Click to expand...
Click to collapse
If you are correct, then the kernel source is available here:
http://www.casiogzone.com/us/download/index.html
I'll look into it..

GPL or not GPL?
Citation from http://wiki.cyanogenmod.org/w/Doc:_porting_intro:
"The manufacturer or vender of any device using Android will minimally need to make the source code available for all GPL components upon request, including (and especially) the kernel. You definitely want to request a copy of the kernel source and keep it handy."
Can anyone clarify the tedious question in the subject? I mean, does running android implies gpl on kernel? Can anyone (NEC, ATT, Qualcom) hide the source and what the conditions should be then? Can they have proprietary blobs in the kernel?
Weird

alex-kas said:
Citation from http://wiki.cyanogenmod.org/w/Doc:_porting_intro:
"The manufacturer or vender of any device using Android will minimally need to make the source code available for all GPL components upon request, including (and especially) the kernel. You definitely want to request a copy of the kernel source and keep it handy."
Can anyone clarify the tedious question in the subject? I mean, does running android implies gpl on kernel? Can anyone (NEC, ATT, Qualcom) hide the source and what the conditions should be then? Can they have proprietary blobs in the kernel?
Weird
Click to expand...
Click to collapse
Android runs on a standard Linux kernel which is GPL covered. Android is really just a Java VM inside of a Linux kernel I believe. So yes, Android kernel IS Linux kernel so therefore it would be GPL covered (thanks for the explanation @Nardholio )
They understand GPL. Anything based on the Linux Kernel must have the source released, so AFAIK there is no "proprietary" in a Linux Kernel... however that is just my understanding and if I am wrong someone please correct me. If they put "proprietary" code in the kernel and try to use that as an excuse to not release it, I say "Too bad, that's not an excuse, since you understood GPL when you built the kernel but are refusing to follow it. Guess what, now you have to release the kernel AND your "proprietary" software! LOL!!!"
Sent from my LG-D415 using XDA

I posted this in the wrong thread. Long story short I found someone interested in helping enforce the GPL for the Terrain but I don't own one. I need someone who owns a Terrain (preferably directly bought from AT&T or NEC) and who has already requested kernel source and either received no response or a refusal (I used the feedback form on NEC's website and got a polite refusal a few days later but I don't own one)

Nardholio said:
I posted this in the wrong thread. Long story short I found someone interested in helping enforce the GPL for the Terrain but I don't own one. I need someone who owns a Terrain (preferably directly bought from AT&T or NEC) and who has already requested kernel source and either received no response or a refusal (I used the feedback form on NEC's website and got a polite refusal a few days later but I don't own one)
Click to expand...
Click to collapse
I own a Terrain, and have gotten a refusal from NEC support...
What do you have in mind???
---------- Post added at 12:21 PM ---------- Previous post was at 12:19 PM ----------
Dear Mr. Martin Juhl,
Thank you for contacting NEC.
This is in regards to your email about the kernel of the NEC Terrain phone. You may check the kernel version and build number of the device on the phone itself. We do not have the source code of the device nor release them.
Please feel free to email us at [email protected] or call our toll free Customer Service number (1-800-637-5917) if you have any additional questions.
Your reference number for this inquiry is: 150727-000011
Thank you again for taking the time to write.
Sincerely,
NEC Customer Support

MrMEEE said:
I own a Terrain, and have gotten a refusal from NEC support...
What do you have in mind???
---------- Post added at 12:21 PM ---------- Previous post was at 12:19 PM ----------
Dear Mr. Martin Juhl,
Thank you for contacting NEC.
This is in regards to your email about the kernel of the NEC Terrain phone. You may check the kernel version and build number of the device on the phone itself. We do not have the source code of the device nor release them.
Please feel free to email us at [email protected] or call our toll free Customer Service number (1-800-637-5917) if you have any additional questions.
Your reference number for this inquiry is: 150727-000011
Thank you again for taking the time to write.
Sincerely,
NEC Customer Support
Click to expand...
Click to collapse
Sweet. PM me your email address and I will hand off my communication with the SF Conservancy to you. Just saying you can go to kernel.org and download the Linux kernel is NOT a sufficient response. They need to provide full source to boot the device (including board files, device drivers, any in kernel firmware, and build scripts)

YOU WILL NOT BELIEVE!
http://nec-mobilecom.co.jp/gpl/w/list/NEC_TERRAIN.html
I pressed NEC to deliver it. Have no time to check right away the integrity. Also, I have some problem downloading from CAF (I'm in a place where git is blocked). Maybe will ask someone to help (re-download to an http store).

alex-kas said:
YOU WILL NOT BELIEVE!
http://nec-mobilecom.co.jp/gpl/w/list/NEC_TERRAIN.html
I pressed NEC to deliver it. Have no time to check right away the integrity. Also, I have some problem downloading from CAF (I'm in a place where git is blocked). Maybe will ask someone to help (re-download to an http store).
Click to expand...
Click to collapse
Well sh*t... Never thought this would happen in a bazillion years.
Yet if you read their terms and conditions, it states you aren't allowed to reversed engineer their software to a "human readable form". Is this nullified by GPL, or can we be in trouble for using their kernel source for a ROM?
EDIT: Just downloaded myself a copy of the kernel.
Sent from my SAMSUNG-SGH-I747 using XDA Free mobile app

I do not care. I asked, nec gave the source publicly. no reverse engineering. Now we all gpl. My point.
Sent on the go

I don't think they would care as long as you are not reselling it...... you aren't, right?
Sent from my SGH-I547C using XDA Free mobile app

Darn, I was gonna set up a booth in front of my house and be one of those loud, obnoxious salesmen

hey mister.... I'mer gonna take two them kernel if ye can cut me a deal....
jasonmerc said:
Darn, I was gonna set up a booth in front of my house and be one of those loud, obnoxious salesmen
"GEEEETTT'CHA KERNEL SOURCE HEEEEEEAAA! TERRAIN KERNEL SOURCE, ONLY FIIIIIVE DOLLAHS! MAKE YOURSELF A ROM! CUSTOM RECOVERY! FIIIIIIVE DOLLAHS!"
Click to expand...
Click to collapse

First experiments
Results for the moment are like this:
1. The kernel does compile with the modified files with no compilation issues at all.
2. The kernel is smaller then the stock one.
3. The recovery.img produced by full caf build does boot but halts at the android image with the red triangle. Or perhaps does not halt but I did not come with a key combination to proceed.
PROS: graphics works
4. The kernel being stuffed into original boot image does boot, shows boot animation WITHOUT boot sound and then not surprisingly goes to a bootloop flashing the home screen
CONS: seems that sound is not here yet
5. The bootloop was broken using
adb reboot recovery
which means that adb does function
6. I did not try to flash the whole image to check whether bootloops are due to somewhat above the kernel (aka this kernel doesn't work with the stock soft).
Overall, we have a messy kernel source which however at least boots to init, communicates with adb and has graphics.
I'm free for a team project: who is in?
Technically, to make this particular caf manifest I had to install a virtual ubuntu 10.04 x64. My native machine failed to compile. I have gcc 4.9. Even the downgrade to 4.4.7 did not do the job. And for some reason I failed to compile gcc 4.4.3 for my machine. ubuntu 10.04 has gcc 4.4.3. But there you need to install some stuff and update the present there python (it is just 6.5 there but still some update exists still inside 6.5 and it fixes somewhat causing a peculiar error during the build). Also, be aware: you cannot compile on a virtualbox share: mmap does not work for security reasons. You must arrange ALL inside the virtual machine. After the build it is about 53GiB. So, the vm-drive should be at least 60 giga.

alex-kas said:
Results for the moment are like this:
1. The kernel does compile with the modified files with no compilation issues at all.
2. The kernel is smaller then the stock one.
3. The recovery.img produced by full caf build does boot but halts at the android image with the red triangle. Or perhaps does not halt but I did not come with a key combination to proceed.
PROS: graphics works
4. The kernel being stuffed into original boot image does boot, shows boot animation WITHOUT boot sound and then not surprisingly goes to a bootloop flashing the home screen
CONS: seems that sound is not here yet
5. The bootloop was broken using
adb reboot recovery
which means that adb does function
6. I did not try to flash the whole image to check whether bootloops are due to somewhat above the kernel (aka this kernel doesn't work with the stock soft).
Overall, we have a messy kernel source which however at least boots to init, communicates with adb and has graphics.
I'm free for a team project: who is in?
Technically, to make this particular caf manifest I had to install a virtual ubuntu 10.04 x64. My native machine failed to compile. I have gcc 4.9. Even the downgrade to 4.4.7 did not do the job. And for some reason I failed to compile gcc 4.4.3 for my machine. ubuntu 10.04 has gcc 4.4.3. But there you need to install some stuff and update the present there python (it is just 6.5 there but still some update exists still inside 6.5 and it fixes somewhat causing a peculiar error during the build). Also, be aware: you cannot compile on a virtualbox share: mmap does not work for security reasons. You must arrange ALL inside the virtual machine. After the build it is about 53GiB. So, the vm-drive should be at least 60 giga.
Click to expand...
Click to collapse
I haven't code in years, but I want to help out. I am ok with scripting and also able to load stuff to my terrain for testing. Let me know.

Progress Inquiry
Happy New Year!
Just wondering if any progress has been made for this particular device. I understand we all have lives and things get in the way, or interests wither away, its just an inquiry. I'd love to see an update to this device, even up to kitkat if that was possible. Any suggestions on how to recruit developers whom may be interested in the challenge of custom rom development for this device?

General (OPEN DEV) BruteRoot - A collection of Root Tactics (Possibly Force Bootloader unlock on NA Samsung S22?)

Devices & Linux Versions I or other Testers have Successfully Gained Root on:
(Likely All) MTK CPU Based Android devices UP TO 11 (Maybe 12? I haven't tested) (I.e LG, Sony, Select Samsung devices)
Android Devices with LINUX KERNEL VERSIONS - 5.8 - 4.14 - Maybe More? (Needs Testing)
-THIS GUIDE IS NOT BEGINNER FRIENDLY - BASIC UNDERSTANDING OF PYTHON, UNIX/LINUX ETC WILL BE REQUIRED!-​
If you have been holding off updating your device, well here's some good news, your device may still be vulnerable to a method to gain root access (and subsequently, possibly the ability to edit Build.prop and therefore allow the ability for OEM unlocking on USA based devices.) <- correct me if I'm wrong, but this should be possible, and once done, should persist across updates, correct?
As of the time of writing this, there is not currently a simplified APK method, but, still this process is relatively straight forward.
Alot of the methods used HAVE been patched from what I understand, but there have got to be plenty of devices out there still which are not updated. This project aims to compile all current, former and future Root methods into an APK that will do all the leg-work. If its able to find a working method, the GUI will pop a root shell for the end user. This SHOULD work, regardless of the setting of the "OEM UNLOCK" option in the dev options. A bypass, essentially.
Regardless, The project linked below uses a myriad of known exploits & vulnerabilities and looks to find one that will work.
Methods used are:
Nearly all of GTFOBins
Writeable docker.sock
CVE-2022-0847 (Dirty pipe)
CVE-2021-4034 (pwnkit)
CVE-2021-3560
It'll exploit most sudo privileges listed in GTFOBins to pop a root shell, as well as exploiting issues like a writable docker.sock, or the recent dirty pipe (CVE-2022-0847). More methods to root will be added over time too.
There is also an alternative (Dirty Pipe) injection method the uses @topjohnwu 's Magisk , this should be implemented into the apk. See this Github repo, Here.
I would imagine this could be implented in a way to target devices that have stopped being supported for updates, aswell, that do not have TWRP, such as the SM-T307U.
One big note - I am betting there are still ALOT of devices that are in inventory at retailers that remain on the vulnerable OS. So keeping that in mind, I'd say this is worth building.
What needs to be done:
TESTING!
Build APK - HELP NEEDED WITH THIS!
Deploy
Main Goals:
Get bootloader unlock ability for devices normally not unlockable (I.e North American Samsung Galaxy S22, Etc)
Above can be achieved by getting temp root via methods detailed here or otherwise, then editing build.prop, altering the below settings (The settings may be worded differently or simply not present at all, depending on device and Firmware version):
sys.oem_unlocking_allowed to 1
ro.oem_unlock_supported to 1 (most devices are set to 1 by default.)
ro.boot.flash.locked to 0
ro.secure to 0
ro.debuggable to 1
I think there may be one or two more that pretaint to Flash.locked. I.e flash.locked.other--or something very close.
Locally, gain temp root (System preferred, but any root will do.) on as many device types as possible.
Give device control back to end user.
Stay up-to-date on new exploits for root access & update apk accordingly.
STAY ETHICAL!!!! This is, in the end, a research project. Meaning all work preformed in the context of this project could result in a damaged or bricked device. By participating in this project you acknoledge these risks and accept them, and agree to not hold me, XDA, or anyone else responsible if you do some dumb ****. - k0mraid3
Github Project link: HERE for my fork & HERE for the original project.
My fork will incorporate the original project, as well as other found root access methods, such as the magisk injection method mentioned above - my repo is mainly used as a hub for the APK's dev - i don't have enough time to work on it at the moment but all are welcome to help.
July 15th 2022 (UPDATE) (SAMSUNG DEVICES ONLY): A new Escalation method has been found via the Galaxy app store (Versions BEFORE Galaxy Store 4.5.41.8). No details known yet, but it is said to be very easy. See CVE-2022-33708 (July132022). Unknown if downgrading the app to 4.5.0.0 will enable the method again or not.
Cred: liamg
One method to run Traitor on device - Thanks @DevinDking for sharing this.
Steps to get script on phone.
//
#!/bin/sh
set -e
dir=/data/local/tmp
adb=${adb:-"adb"}
$adb push traitor ${dir} //This puts file on phone make sure to run the terminal where its located
$adb shell chmod 755 ${dir}/traitor"
//
Now to run script start a new terminal
//
adb shell
#!/bin/sh
set -e
dir=/data/local/tmp
adb=${adb:-"adb"}
${dir}/traitor //script opens
//
But I assume this wouldn't work right, and isn't right.
Idk trying my best here xD
Click to expand...
Click to collapse
Tools & References:
Linux (and Android, FTMP) Privilege Escalation Techniques
Dirty Pipe - Magisk Injection
Traitor - Main Repo
GTFOBins
CVE Database (Public Database for exploits, vulnerabilities, etc.)
Windows Subsystem For Linux (Great for Dev)
ADB App Control - Cred @Cyber.Cat
Leaked Samsung Source Code ***Mod Edit: Link Removed***
Crontab Root Template script (File Attached - you still must edit crontab with "crontab -e" and point it to this file, see comments for guide, I will add one to post later)
Android Image Kitchen Used to create custom image's etc.
MTK Client
MTK Meta Utility (Source-???)
Will add more as time goes on and more found.
Interesting Attack vectors -
GFX Componets of a system.
Issues with Linux itself (i.e Dirty Pipe)
Privilage escalation via any means (I.e GTFOBins)
unprotected system process - Hijack them if possible (i.e RILService Mode, and a wide range of other OEM apps left on devices after ship)
7/24/22 - Samsung, LG & Other OEM's obfuscating (Intentionally Hiding) Fastboot and ADB Bootloader interfaces on PC
So over the last week or so i dived head first into USB Dev - ill save you the time and sum it up.
Vendors and OEM's are actively obfuscating the USB connection between your smartphone and the PC to keep you from Rooting. As far as im aware, there is no Universal way to fix this as each OEM screws with the USB drivers differently. THIS needs to be a point of focus for the rooting community. However, i have found a few tools for Dev if you wish to screw with this. (I'll upload them tonight)
7/24/22 - MTK (MediaTek) based Exploits
I Will try to compile a few methods for FORCING Bootloader Unlock on MTK based Devices as well as a way for manipulating said devices. I will attach two tools to this thread, these tools are EXTREMELY POWERFUL and can completely **** up your device. When i say REALLY F*CK UP your device, I mean to the point you cant even access recovery, Download OR bootloader mode. I'm Talking a blank DEAD device. So use with caution.
With that said, lets talk about the tools. You will need a basic understanding of Python to make use of MTK Client
First up, we have MTK Meta Utility (Currently Version 44) (Download Below)
Next we have MTK Client (Github Link)
So what can you do? Well, you can crash the Preloader to Brom with MTK Meta Utility while at the same time using MTK Client to send any payload you like to the device via Fastboot.
I know, vague right now, but ill add detail over the coming days.
I will continue to update the below list as new methods are discovered.
If you find Guides, tutorials or new exploits, please link them in the comments so I can include them in future development!
Telegram Channel: Here.
Information on Vulnerabilities, exploits & methods - CVE-2022-0847 (Jfrog) - The Story Of "Dirty Pipe" - XDA - Dirty Pipe - PWNKIT (CVE--2021-4034) - CVE-2021-3560 - Docker Breakout / Privilege Escalation - CVE-2022-33708 (July132022) - CVE-2022-33701 (July122022) - CVE-2022-22268 (Unlock Knox Guard with DEX) (JAN2022) - MTK Client -
Dev Team & credit to -
@topjohnwu - LiamG - @wr3cckl3ss1 - bkerler -
UPDATED - 7/29/22

There is also a new vulnerability exploit by Zhenpeng Lin that allows for privilege escalation on Pixel 6 and and Galaxy S22 devices running 5.10 kernel.

Don't update... destroyer of worlds

I feel like I'm missing something because wouldn't their normally be a million responses of hype, hope and nay-saying going on here? Has this been shot down already?

olivehue512 said:
I feel like I'm missing something because wouldn't their normally be a million responses of hype, hope and nay-saying going on here? Has this been shot down already?
Click to expand...
Click to collapse
Lol, everybody already updated the patch

blackhawk said:
Lol, everybody already updated the patch
Click to expand...
Click to collapse
This is just sad panda. I'm gonna skip next update anyways unless it comes with an actual other phone that is BL unlocked. I feel like everyone wants this so bad it can't be that far out before it happens.
Does the Magisk injection method work after July patch? I was reading through the work they did to get it done. Props to those guys.

sierratango88 said:
There is also a new vulnerability exploit by Zhenpeng Lin that allows for privilege escalation on Pixel 6 and and Galaxy S22 devices running 5.10 kernel.
Click to expand...
Click to collapse
Has it got a fancy number yet?! Eager to try this!!!! Maybe it can be put in with the others.

olivehue512 said:
I feel like I'm missing something because wouldn't their normally be a million responses of hype, hope and nay-saying going on here? Has this been shot down already?
Click to expand...
Click to collapse
Well, because they are known and accepted vulnerabilities and exploits. A very few have even been marked as "WONTFIX" such as the TTY method.

olivehue512 said:
This is just sad panda. I'm gonna skip next update anyways unless it comes with an actual other phone that is BL unlocked. I feel like everyone wants this so bad it can't be that far out before it happens.
Does the Magisk injection method work after July patch? I was reading through the work they did to get it done. Props to those guys.
Click to expand...
Click to collapse
Honestly, it's worth a shot but I doubt it.
One of the goals behind building the APK compilation of all these different tactics is to enable the end user to "give it a shot" easily on different devices, without having to know how to run all of this manually. Basically imagine an apk that just tries all the above methods and if ones successful the gui will pop a root shell open. From there, the possibilities are endless. Edit Build.prop, SELinux, Verity, Etc.

FYI even you applied the July update, seems like the Kernel version is still from June 21st, is still 5.10xxxx so we could still benefit from this exploit. Very interested in how we can get root here in the US.

K0mraid3 said:
Has it got a fancy number yet?! Eager to try this!!!! Maybe it can be put in with the others.
Click to expand...
Click to collapse
There hasn't been a CVE assigned to it yet that I am aware of.

xgerryx said:
FYI even you applied the July update, seems like the Kernel version is still from June 21st, is still 5.10xxxx so we could still benefit from this exploit. Very interested in how we can get root here in the US.
Click to expand...
Click to collapse
Go to the Github linked and try the different methods, see if you can pop a root and nano build.prop to allow OEM unlocking?

sierratango88 said:
There hasn't been a CVE assigned to it yet that I am aware of.
Click to expand...
Click to collapse
GREAT news for us! LEts get this temp root! lol

Looks like another new one! CVE-2022-33708

Another Samsung Exclusive - CVE-2022-33701

So, ive just spent my entire friday and friday night MANUALLY testing all the GTFOBins & reproducing some of the newer CVE's on Samsung Galaxy S7 Edge (Android 9) -Galaxy tab A 8.4, (Android 11), Galaxy S21 & S22 (Android 12) --- A little bit of progress made. Again, ill need someone with better working knowledge on APKs & Java to really move forward. All i can say so far, is this all must be awk for sammie, because cronie is looking promising
"crontab -e"

interesting find. not "New" but still new-ish enough some may be able to use. CVE-2022-22268 (Unlock Knox Guard with DEX)

New to this all but not rooting. Anyone recommend a way tutorial on how to try these methods on Win 11?

I don't have a deep understanding of Linux, I have tried, debian and unbuntu. I get traitor to run but it's detecting the Linux kernel and not my phones. How can I get the program to search for vulnerability on my phone not my Linux. I would love a more in depth guide and I'd love to give feedback on methods.

DevinDking said:
I don't have a deep understanding of Linux, I have tried, debian and unbuntu. I get traitor to run but it's detecting the Linux kernel and not my phones. How can I get the program to search for vulnerability on my phone not my Linux. I would love a more in depth guide and I'd love to give feedback on methods.
Click to expand...
Click to collapse
i had the same issue but cant remember how i worked that out. let me see if i can find out what i did on win11