Related
I currently have been trying to implement an application that supports advanced SMS features like compression (as spelled out in specification "Compression algorithm for text messaging services (Release 8)", 3GPP TS 23.042 V8.0.0). A quick search of the forum did not result in anything that supports this, so forgive me if this is a repeat.
Does anybody have an implementation of this specification that actually works? I would very much like to see the source code if so, but an application that I could compress an SMS using that protocol would be nice as well just to compare to what I am generating.
The problem is I have the GSM 7bit huffman tree, and it works fine for me, but it does not produce results that match the test vectors included with the specification above.
Any help would be greatly appreciated!
I did find an implementation that CLAIMS to be compliant, but I have to work through de-compilation of it... JAVA Class files... Also working up a driver for it to test out it's compression. If I can successfully de-compile the class files, and the driver works, then I might be done (short of converting it to C/C++). I'll post later on the success /failure of it.
Oh, it's called "Attention" and the JAR files are available at:
http://code.google.com/p/attention/
Got the SVN source tree for it (was added recently) and this is truly not ready for prime time. It is RIDDLED with errors and absolute paths' to files that don't exist as anything other than resources... I have tried going through and fixing most of them that has to do with the compression, but my hopes are not high. Plus, it's in JAVA...
Anyhow, I am still looking for a GOOD implementation of this. Any suggestions would be greatly appreciated.
Hello.
In this topic we talk about the Lenovo ICS versions and the home-brown self-made Ice Cream Sandwich I'm trying to build.
Currently I'm trying to port Ice Cream Sandwich (Android 4.0.4) to A1 IdeaPad by Lenovo.
Currently working:
* Touchscreen Input
* SGX530 Hardware Graphic Acceleration
* Orientation
* 3D Acceleration
* Brightness (using lights.omap3.so from Lenovo)
Not working:
* Audio
* ...
UPDATE 05.08.2012:
SGX530 Integration succeeded into Android AOSP ICS 4.0.4!
One should have to know that you have to use a DIFFERENT SGX DDK for ICS than for Gingerbread but that's not documented... [email protected] for ICS, 1.7.X for GB. Installed the proper components, ES=5.X and then we are rolling. I'm now trying to use some of the ICS libraries from the Lenovo ICS, but those have horrible dependencies. Thou I can most likely take the camera.omap3.so, I still want to be able to build those libraries from source, where available, so I gotta have to collect some stuff together. If this progresses nicely, I might be able to make a CM9 port here aswell, but for now, I need to get the rest of the functionallity working (WiFi driver [dhd_oob.ko] registers, but doesn't appear on the ICS yet, same for bluetooth. Sound is not working yet (E/AudioFlinger( 4034): createTrack_l() Bad parameter: sampleRate 44100 m 44100 format 1 m 1, channelMask 0x0000000 m 0x00000001 for output 0x3 with format 67520, e.a. channelMask is not doing what it should do), ...)
Again, I'm sorry that I don't have much spare time right now, so the progress is rather slow.
Status:
Right now Ice Cream Sandwich is booting, I had to patch SystemUI.apk to force hardware acceleration off. I tried to set debug.egl.hw=0 in the prop-file, but it didn't change anything, so I had to modify the source to hard-set it to accept no hardware acceleration.
I'm trying to get input to work, but it seems that the mg-capacity / Morgan Touch Capacity Display doesn't give proper values to InputReader. Since the libinput.so got massivly changed after switching from GingerBread to Ice Cream Sandwich, it doesn't seem to give proper values to the InputReader anymore. I patched/modified my libinput.so to display raw events and log them to logcat, but I gotta take a look if I have to write myself a wrapper for that.
UPDATE 31.03.2012:
- I was able to fix the missing BTN_TOUCH in the kernel sources. Now we have a working touchscreen.
- Added ro.sf.hwrotation 270, so the input is correct
UPDATE 25.07.2012:
- Sorry for the lack of updates, I currently don't have much spare time to work on this, sadly.
- What I found out is, that I was able to implement SGX530 libraries to Ice Cream Sandwich, but the driver wouldn't really activate my screen. To be honest, when i loaded the SGX drivers, my screen or speakers (not sure which) started to give this really high pitched noise. I'm not sure where it came from, but I'm sure I ****ed something up with the SGX drivers. We can't simply take the Gingerbread SGX Drivers to Ice Cream Sandwich, sadly. And we can't simply use the SGX Module from the version Lenovo provided, since they depend on a certain kernel module.
E.a. If you use a GingerBread Kernel with the Input Fix (like the one I compiled), you can boot Ice Cream Sandwich fine and stuff, but you can not use the SGX530 modules from the Lenovo ICS. (As this one flashes a new kernel version, and modifies the MBR and does other witch-craftery)
My ultimate goal would be, to use the Gingerbread Kernel from Lenovo with the additional screen input fixes for ICS and add the SGX/PowerVR 530 to that, so we would have hardware acceleration (for now). I want to avoid the 3.x kernel from Lenovo as much as possible as it seems to have various terrible problems in the regular use (disconnecting Wifi, standby problems, power supply problems, etc.)
We can't simply make an omap-kernel from the 3.x tree aswell, as we are missing lots of the arch/arm/mach-omap2/board-evt* and the important arch/arm/mach-omap2/board-evt1a.c which initializes our board for the boot process. And even if we could use a 3.x tree and implement powerVR into it, we would have to port ALL the changes Lenovo made to the sources (some MMC adaptions, power supply adaptions, modification to the rfkill, etc.) to the new kernel by which, most likely, lenovo will release either another pad or ICS for A1 (as it would take a HUGE amount of time).
So the goals are:
- Wait for Lenovo to stabilize the kernel of ICS and use their ROM.
OR:
- Use GB-Kernel from Lenovo Source Ball, try to implement PowerVR/SGX530 drivers and user-land applications to the ICS
- Slowly adapting other OMAP devices and libraries (brightness, vibration, sound, ...)
Chat:
#ideapad-a1 @ irc.freenode.net
(it's gmarkall's channel, but I hang out there.)
This is great. I look forward to seeing what you come up with.
My guess is that the Kernel is missing most of the drivers you need. I have been able to sort out this hardware so far:
CPU: TI OMAP3622 ARM® Cortex™-A8 processor
Video: PowerVR SGX530
Wireless: Broadcom BCM4329
Bluetooth: Broadcom BCM4329
Audio: TI TLV320AIC3110 (tlv320aic3111)
GPS: Broadcom BCM4751
I2C Ambient Light Sensor: Capella CM3217 (I2C) input5
Power Management: TI twl4030 (I2C)
Soft keypad?: TI twl4030 (I2C) input1
Capacitive Touch: TI twl4030 (I2C) input2
Power Button: TI twl4030 (I2C) input3
Back Camera: s5k5ca (3mp camera)
Front Camera: omap34xxcam Aptina MT9V115
Accelerometer (G sensor): Analog Devices ADXL345 (I2C) input4
Gyroscope: None
eCompass: None
Hopefully this helps when choosing kernel options.
---------- Post added at 08:58 AM ---------- Previous post was at 08:55 AM ----------
...additionally, the Nook Color is nearly the same hardware from what I can tell and they seem to be getting pretty far on ICS.
If someone can post a dmesg listing from a nook color, I can compare it to an A1 to try to document the hardware differences.
that's cool, I'm looking forward to your good news
It would be awesome to get ICS running on the a1!
nice work!
OK, some news:
It seems I'm pretty much f*cked until we get the sources for the kernel. The GB Kernel doesn't send the proper events for InputReader/EventHub.
I investigated the input within the system using the "getevent" tool (getevent -l).
The device itself seems to be able to report PRESSURE from what I've seen, just plain doesn't want to do it. (using 'dumpsys window')
It currently doesn't send a PRESSURE event which we need for activating the touchscreen. (Instead it gets sent by the redicoulus light sensor...)
One attempt would be to hack away and modify the InputReader to send a ABS_MT_PRESSURE event on every ABS_MT_X modification, or just wait for the sources.
On related note: I also tried to compile CM9 in an attempt to see if it may fix the input issuses or use a different input system, but it's just the same result as using vanilla ICS
spiegeleixxl said:
OK, some news:
It seems I'm pretty much f*cked until we get the sources for the kernel. The GB Kernel doesn't send the proper events for InputReader/EventHub.
I investigated the input within the system using the "getevent" tool (getevent -l).
The device itself seems to be able to report PRESSURE from what I've seen, just plain doesn't want to do it. (using 'dumpsys window')
It currently doesn't send a PRESSURE event which we need for activating the touchscreen. (Instead it gets sent by the redicoulus light sensor...)
One attempt would be to hack away and modify the InputReader to send a ABS_MT_PRESSURE event on every ABS_MT_X modification, or just wait for the sources.
On related note: I also tried to compile CM9 in an attempt to see if it may fix the input issuses or use a different input system, but it's just the same result as using vanilla ICS
Click to expand...
Click to collapse
Access to source would definitely make this a lot easier! Thankfully, the admin over at the Lenovo forum has promised to release the A1 source within the next week (just Google search "Lenovo Ideapad A1 source code", should be first or second link).
Thanks for spearheading this project. Would be great to see ICS on the A1!!
If you don't mind me asking, how exactly did you force hardware acceleration off inside of the SystemUI.apk? I'm currently working on doing something similar to this for the skyrocket, but I keep running into systeumui force closes.
One possible change would be changing the AndroidManifest.xml, i suppose:
frameworks/base/packages/SystemUI/AndroidManifest.xml: android:hardwareAccelerated="true"
Allthou I changed it somewhere in source, I can look it up for you later, try changing that XML option.
Great, can't wait for the A1 source being published - alas I would be glad if I would have any experience with linux/modding to help getting ICS to work on the A1 Kudos to spiegeleixxl for spearheading the development here!
Source Code released
finally Lenovo did it...
Thanks to Mark from Lenovo !
download.lenovo.com/lenovo/content/sm/A1-Kernel-Source.tgz
Unfortunately the source seems incomplete -> http://forum.xda-developers.com/showthread.php?t=1439451&page=23
drsnuggles79 said:
Unfortunately the source seems incomplete -> http://forum.xda-developers.com/showthread.php?t=1439451&page=23
Click to expand...
Click to collapse
Luckily enough the mg-i2c-driver is in there. It looks like it's failing to report some ABS_MT messages that are required for libinput/EventHub/InputReader to work. If gmarkall and me get the kernel compiled and working we can get rolling on porting ICS.
The graphics driver for ICS are also available via TI SGX SDK which is freely available.
So we're going into a good direction!
Great news. Is there anything that us noobs can do to help?!
tonyyeb said:
Great news. Is there anything that us noobs can do to help?!
Click to expand...
Click to collapse
spend money
otti17 said:
spend money
Click to expand...
Click to collapse
If by that you mean buy an A1, I'm already ahead of you!
waiting for your first build ..
how glad to see someone porting ICS to my cute A1 !
I've been searching someone trying to port ics since i bought A1 ...
wanna see a first build of ics to taste on my pad...
so much appreciate your works here .. guys....
Tint Ag Khaing said:
how glad to see someone porting ICS to my cute A1 !
I've been searching someone trying to port ics since i bought A1 ...
wanna see a first build of ics to taste on my pad...
so much appreciate your works here .. guys....
Click to expand...
Click to collapse
It's not like i can't give you a BUILD, you'll even SEE something, but you won't be able to DO something cause it doesn't register the press event.
What is the likelihood of getting to a beta stage with this?
AFAIK there are some touchscreen drivers-related issues.
[email protected]_a1
Even though JB is more or less feature-complete on Defy(+) there are still a few nits which will be hard to squash without having access to features which are only available in later kernels (eg. the ION memory allocator). Given that this board is frequented by people who (theoretically at least) should be able to give a hand in porting the required drivers/features to get a 3.X kernel up and running on Defy(+) I started making an overview of those missing bits. It should only take a relatively small group of willing volunteers, each responsible for a driver or feature, to get those bits ported.
From a quick glance at the configuration options used with the currently used 2nd-boot kernel I come to the following list of drivers/features which will need to be ported to 3.X. Some of these might already be available under different names in the kernel. Others might have been ported but are simply not part of the kernel tree I used to make this comparison (Quarx2k/jordan-kernel; branch 3.0.8-defy_display). Yet others might not be needed in the newer kernel because their functions are taken over by other drivers/features.
This is not a complete list of features needed to get a kernel running on the Defy(+) (see mapphone_defconfig in branch 2.6.32 for what is needed).
In the following list I marked potential replacements in bold type, usually followed by a question mark (?) to indicate I'm not sure they are fully compatible replacements for the 2.6.X drivers/features. The drivers/features are listed in 2.6.X menuconfig order using Kconfig names and symbols.
Drivers needed for Jordan w/kernel 3.x
Top level
Support for open firmware device tree (ARM port)
ARM_OF -> USE_OF ?
Support for device tree in /proc
PROC_DEVICETREE
DSP Bridge driver
MPU_BRIDGE
System Type
Motorola Android Platform Phone
MACH_MAPPHONE -> MACH_OMAP_MAPPHONE ? complete?
Motorola Android Platform phone 2nd-boot kernel modifications
MAPPHONE_2NDBOOT
Export DIE ID code under /proc/socinfo
OMAP3_EXPORT_DIE_ID
Device Drivers/Misc devices
AKM8973 Magnetometer
SENSORS_AKM8973_AKMD
KXTF9 Accelerometer
SENSORS_KXTF9
Bluetooth power control driver for TI wl127x
WL127X_RFKILL
Motorola OMAP Device Type Driver
OMAP_DEV_TYPE_DRV
Motorola Modem PM Driver
MODEM_PM_DRIVER
Motorola netmux driver
NETMUX_DRIVER
Motorola netmux link driver
NETMUX_LINKDRIVER
Motorola Camera Driver
CAMERA_MISC
Device Drivers/Multimedia support/Video capture adapters
HP OMAP3 Imaging/3A driver
VIDEO_OMAP3_HP3A
Video out driver
VIDEO_OMAP_VIDEOOUT -> VIDEO_OMAP2_VOUT ?
Device Drivers/Sound card support/Open Sound System (DEPRECATED)
Audio driver for OMAP3430 with CPCAP
SOUND_CPCAP_OMAP -> SND_OMAP_SOC ( = ALSA)
Device Drivers/USB support
CPCAP USB Transceiver Driver
CPCAP_USB
Device Drivers/USB support/USB Gadget Support
USB Gadget Drivers (MOTO Android Gadget)
USB_MOT_ANDROID
Device Drivers/Real Time Clock
CPCAP RTC
RTC_DRV_CPCAP
So... anyone here who is willing and able to take on one of these drivers/features? Within a reasonable time frame (weeks, not months)? Anyone who knows of existing ports for these missing bits?
Why wait for Quarx or any of the other already overworked developers to do all the work? Just join hands, sing Kumbayah and get porting - but post here which driver/feature you want to work on to avoid needless duplication of effort.
I'll wait a few days for others to take the fun projects, then I'll start on those which are left.
it's a great idea，but it seems so difficult for us to complete such a huge program.
one-piggy said:
it's a great idea，but it seems so difficult for us to complete such a huge program.
Click to expand...
Click to collapse
It is not as big as you make it out to be. The drivers already exist, they just need to be ported. The differences between 2.6.32 and 3.0.X (the first target) are not that big, so the changes needed should be limited. The number of drivers which need to be ported is also rather limited, especially given the potential number of volunteers. The difficulty level for porting these drivers is generally not that high, there are plenty of examples to be found for similar hardware which has already been ported.
The list contains 17 items. Several of them need to be checked for compatibility only (USE_OF, MACH_OMAP_MAPPHONE, VIDEO_OMAP2_VOUT, SND_OMAP_SOC, USB_MOT_ANDROID). This leaves 12 items. The CPCAP-related drivers might already be available (need to check later Motorola code). The procfs-related stuff should be easy to implement (PROC_DEVICETREE, OMAP3_EXPORT_DIE_ID) and might already be available under different names.
For OMAP-specific stuff (CONFIG_MPU_BRIDGE etc) there is linux-omap, more specifically several mailing lists frequented by people who have experience with porting to the linux-omap tree.
Porting the sensor drivers (SENSORS_AKM8973_AKMD, SENSORS_KXTF9) should be straightforward. The camera/video-related drivers might be more complicated as they'll need to be adapted to use ION. Then again, maybe they have already been ported? If not, there should be plenty of examples for similar hardware to base a port on.
I'm not saying porting these drivers/features will be effortless. Nor does it have to be. Porting ICS and later JB to Defy(+) wasn't effortless either yet still someone did it. By dividing the tasks needed to port these drivers/features the amount of effort needed will be limited. As said, I assume that there are several people frequenting this (part of this) site who should be capable of partaking in this effort.
YetAnotherForumUser said:
The differences between 2.6.32 and 3.0.X (the first target) are not that big
Click to expand...
Click to collapse
I second that. There's a huge misconception that 3.0.x a major change. But it wasn't. They just bumped up the version number.
Sent from my MB526 using xda premium
simmilar drivers in this repository
https://github.com/redyk/omap3630-3.0.8
Lg Optimus Black(sniper) 3.0.8 sources..
I found smmilar drivers but i don't know these drivers same them
quarx is already very far with the kernel. The actual problem is that he has no idea how to get display working.
If anyone can help with this that would be great.
junesoung said:
https://github.com/redyk/omap3630-3.0.8
Lg Optimus Black(sniper) 3.0.8 sources..
I found smmilar drivers but i don't know these drivers same them
Click to expand...
Click to collapse
LG Optimus Black 'sniper' kernel, 3.0.57:
https://github.com/TheMeier/lge-kernel-sniper-linux-stable
Has source for the following drivers, probably more - I just cloned the repository.
AKM8973 Magnetometer
KXTF9 Accelerometer
WL127X_RFKILL
m11kkaa said:
quarx is already very far with the kernel. The actual problem is that he has no idea how to get display working.
If anyone can help with this that would be great.
Click to expand...
Click to collapse
don't see a problem if someone wants to make a separate attempt. i think community effort has better chance in getting latest kernel up and running.
YetAnotherForumUser said:
LG Optimus Black 'sniper' kernel, 3.0.57:
https://github.com/TheMeier/lge-kernel-sniper-linux-stable
Has source for the following drivers, probably more - I just cloned the repository.
AKM8973 Magnetometer
KXTF9 Accelerometer
WL127X_RFKILL
Click to expand...
Click to collapse
Sounds good
GalaxySL use same cpu(omap3630)
It has 3.0 kernel too
You can find more drivers
Sent from my MB525 using xda app-developers app
Which is the base you intend to use as a starting point, test / compile against?
https://github.com/Quarx2k/jordan-kernel/tree/3.0.8-defy_display
This one?
May be this would help http://forum.xda-developers.com/showthread.php?p=33801839
http://forum.xda-developers.com/showthread.php?p=33710566
Sent from my MB526 using xda app-developers app
Comparison between Defy and LG Optimus Black kernel configuration
m11kkaa said:
quarx is already very far with the kernel. The actual problem is that he has no idea how to get display working.
If anyone can help with this that would be great.
Click to expand...
Click to collapse
The display subsystem in the LG Optimus Black seems to resemble that in the Defy(+), so for that purpose those sources can be useful.
For comparison purposes I attached a side-by-side diff of the default Defy(+) kernel .config and that for the LG Optimus Black.
domokos said:
Which is the base you intend to use as a starting point, test / compile against?
https://github.com/Quarx2k/jordan-kernel/tree/3.0.8-defy_display
This one?
Click to expand...
Click to collapse
That is the base I used to find missing drivers/features. For porting purposes it does not matter that much which base is used, as long as it is as close to baseline as possible. The linux-omap tree would be a good starting point as that is a) synchronized with baseline and b) where work on OMAP-related stuff takes place. As the purpose of the port is to get Android to run, the most recent Android-specific branch would be a good target. Of course there is much to say for taking the path of least resistance so if one of those other trees around here (Quarx 3.0.8-defy_display, LG, Samsung, a mashup of all three, etc) can get us where we want to be in less time that would be an option as well.
http://forum.xda-developers.com/showthread.php?t=1546102
maybe this will be helpfull?!
YetAnotherForumUser said:
Even though JB is more or less feature-complete on Defy(+) there are still a few nits which will be hard to squash without having access to features which are only available in later kernels (eg. the ION memory allocator). Given that this board is frequented by people who (theoretically at least) should be able to give a hand in porting the required drivers/features to get a 3.X kernel up and running on Defy(+) I started making an overview of those missing bits. It should only take a relatively small group of willing volunteers, each responsible for a driver or feature, to get those bits ported.
From a quick glance at the configuration options used with the currently used 2nd-boot kernel I come to the following list of drivers/features which will need to be ported to 3.X. Some of these might already be available under different names in the kernel. Others might have been ported but are simply not part of the kernel tree I used to make this comparison (Quarx2k/jordan-kernel; branch 3.0.8-defy_display). Yet others might not be needed in the newer kernel because their functions are taken over by other drivers/features.
This is not a complete list of features needed to get a kernel running on the Defy(+) (see mapphone_defconfig in branch 2.6.32 for what is needed).
In the following list I marked potential replacements in bold type, usually followed by a question mark (?) to indicate I'm not sure they are fully compatible replacements for the 2.6.X drivers/features. The drivers/features are listed in 2.6.X menuconfig order using Kconfig names and symbols.
Drivers needed for Jordan w/kernel 3.x
Top level
Support for open firmware device tree (ARM port)
ARM_OF -> USE_OF ?
Support for device tree in /proc
PROC_DEVICETREE
DSP Bridge driver
MPU_BRIDGE
System Type
Motorola Android Platform Phone
MACH_MAPPHONE -> MACH_OMAP_MAPPHONE ? complete?
Motorola Android Platform phone 2nd-boot kernel modifications
MAPPHONE_2NDBOOT
Export DIE ID code under /proc/socinfo
OMAP3_EXPORT_DIE_ID
Device Drivers/Misc devices
AKM8973 Magnetometer
SENSORS_AKM8973_AKMD
KXTF9 Accelerometer
SENSORS_KXTF9
Bluetooth power control driver for TI wl127x
WL127X_RFKILL
Motorola OMAP Device Type Driver
OMAP_DEV_TYPE_DRV
Motorola Modem PM Driver
MODEM_PM_DRIVER
Motorola netmux driver
NETMUX_DRIVER
Motorola netmux link driver
NETMUX_LINKDRIVER
Motorola Camera Driver
CAMERA_MISC
Device Drivers/Multimedia support/Video capture adapters
HP OMAP3 Imaging/3A driver
VIDEO_OMAP3_HP3A
Video out driver
VIDEO_OMAP_VIDEOOUT -> VIDEO_OMAP2_VOUT ?
Device Drivers/Sound card support/Open Sound System (DEPRECATED)
Audio driver for OMAP3430 with CPCAP
SOUND_CPCAP_OMAP -> SND_OMAP_SOC ( = ALSA)
Device Drivers/USB support
CPCAP USB Transceiver Driver
CPCAP_USB
Device Drivers/USB support/USB Gadget Support
USB Gadget Drivers (MOTO Android Gadget)
USB_MOT_ANDROID
Device Drivers/Real Time Clock
CPCAP RTC
RTC_DRV_CPCAP
So... anyone here who is willing and able to take on one of these drivers/features? Within a reasonable time frame (weeks, not months)? Anyone who knows of existing ports for these missing bits?
Why wait for Quarx or any of the other already overworked developers to do all the work? Just join hands, sing Kumbayah and get porting - but post here which driver/feature you want to work on to avoid needless duplication of effort.
I'll wait a few days for others to take the fun projects, then I'll start on those which are left.
Click to expand...
Click to collapse
Maybe this link can be useful: http://blackscratches.blogspot.ro/2012/04/how-to-build-android-kernel-308-for-ti.html it seems very explicit about porting kernel 3.0.8 on omap 3630 including drivers
Fight4Music said:
http://forum.xda-developers.com/showthread.php?t=1546102
maybe this will be helpfull?!
Click to expand...
Click to collapse
It might. For more stuff like that have a look at the Linux OMAP Kernel Project where you'll find more about the various OMAP-related development efforts. The above link points to one of the many branches of this tree:
http://git.omapzoom.org/?p=kernel/omap.git;a=summary
In the p-android-omap-3.4 branch there is a camera driver for the "Aptina MT9P031 Camera". The Defy+ (and Defy/Bayer) contain a camera based on the MT9P012. It stands to reason that there is a family relationship between all these mt9xyyy sensor drivers.
Working 3.0 kernel for Samsung Galaxy SL
The Samsung Galaxy SL shares quite a bit of hardware with the Defy(+). There now is a working (if not feature-complete) 3.0 kernel for this device.
https://github.com/dhiru1602/android_kernel_samsung_latona
Attached to this message is a side-by-side diff between the Defy default config and that for the latona (S G SL) as well as a side-by-side diff between the Optimus Black default config and that for the latona.
http://forum.xda-developers.com/showthread.php?t=1546102
Sent from my MB525 using xda app-developers app
junesoung said:
http://forum.xda-developers.com/showthread.php?t=1546102
Sent from my MB525 using xda app-developers app
Click to expand...
Click to collapse
See #14...
YetAnotherForumUser said:
See #14...
Click to expand...
Click to collapse
Oh, sorry;
Sent from my MB525 using xda app-developers app
ABANDONED
Hi! Does anyone here use Linux desktop distributions in chroot environment on Android device?
I am developing wayland protocol server for Android devices. If anyone is interested in checking my project, latest version of apk is always available here:
ftp://ftp.drivehq.com/mogryph/sparkle/
Currently I am only focused on running Xwayland as client. Also apk supports audio output.
Simplest instruction:
1. Android 6 or newer required, busybox required, root required
2. Prepare linux distribution in directory, image or on partition. Make sure you have Xwayland installed in it. Make sure you specify which DE to run (or at least xterm) in ~/.xinitrc
3. Install and start sparkle.apk
4. Press "edit user.sh", uncomment (remove #) line starting with start_generic_container. Change rest of this line to match your device:
first arg - image or partition where distribution is installed. If distribution is installed in directory and mouting is not needed, leave this arg unchanged.
second arg - mount point or directory with distribution. If you use mounting (first arg), this arg can be left unchanged.
third arg - name of the user which will be used to start Xwayland and DE. Its better to specify non-root. Also this is the user who must have .xinitrc in his home dir (see step 2).
5. Save user.sh and click "Start".
6. Any problems and crashes will be reflected in the log.
If you want audio output:
1. Compile and install driver from pcm_sparkle.tar.gz in your distribtion
2. cp 1.asoundrc ~/.asoundrc
If you have blinking problem, change upload_mode from 1 to 2 in settings. If you have bad performance, setting no_damage to true may help, but in most cases no_damage=false is better. Fastest upload mode is 0 (if it works).
If you don't trust me and don't want to give sparkle root permissions (I perfectly understand this) you don't have to. Also you can do without busybox.
But in this case, you need to understand and do a lot of things. Check sparkle's user.sh to get idea about what needs to be done. Basically:
1. You need to make /data/data/com.sion.sparkle/files accessible from inside chroot container. You can use bind bound.
2. Make sure you have tmpfs mounted over /tmp in container.
3. You may need to change selinux context on /tmp to match sparkle's context or disable SELinux.
4. You need to create new directory in /tmp, symlink sparkle's wayland socket from /data/data/com.sion.sparkle/files/wayland-0 to this dir. And export XDG_RUNTIME_DIR to point to this dir. Dir must be (ch)owned by user who will be running Xwayland and DE.
5. After all this, you can try to start Xwayland and your DE.
new version
New version
rgho.st/8Fbz64Rxj
Added x86 and x86_64 support. Actually it is rewritten almost from scratch but x86 support is the only thing others can notice...
Hello! This project is interesting. I tried you app and it works on my Xiaomi Redmi Note 4X(chromium and glmark from chrooted environment works very well)! Can you publish source code on Github, because it really interesting project?
Also I'm interested, please post it on github!
Did you put this up on github or move this thread? Looks very interesting.
1
Argh, sorry, I decided to abandon this project. You are free to delete thread. Also no copyleft-licensed components were used so I don't have to bother releasing sources.
Hentacler said:
Argh, sorry, I decided to abandon this project. You are free to delete thread. Also no copyleft-licensed components were used so I don't have to bother releasing sources.
Click to expand...
Click to collapse
Check your PM please!
1
Hello again.
For last two weeks I was rewriting it from scratch (yes. again... yes, third time).
Probably need another week to make it stable.
Currently I am not sure it runs on any device except my own 5-year old phone (LineageOS 14).
I will maintain last version here:
ftp://ftp.drivehq.com/mogryph/sparkle/
There is no English documentation, but you can see script "user.sh" to get idea about how to start xwayland. In most cases it should be enough to edit few lines in that script to make it work on another device. If you execute this script on your device with "install" argument, it is supposed to place itself into sparkle's directory and sparkle is supposed to run it ("start" function) automatically. Sparkle doesn't request root unless script does.
Here is video of sparkle working:
https://www.youtube.com/watch?v=tOSFYxCF7Q8
But it seems that KDE + video recording was too much for my old phone
Still, if you going to see video, don't close it until 2:00 where I turned of composition which caused lags.
Also on device everything looks much smoother than on video, even after 2:00.
When I watch fullscreen (1280x720) video on my device, sparkle + xwayland together add just 5% of CPU load (20% load of single core).
Thats it I guess... I tried to to discuss sparkle on 4pda.ru (russian forums), but got very bad reception. "xsdl is perfect, dont reinvent the wheel" they say. So I started to hate humanity and I decided to make sparkle personal project. Also this is last time I am solving reCAPTCHA to leave post on XDA.
Still alive
We are still alive. I've changed first post to reflect actual state. Now sparkle supports audio, auto-mouting containers and is lot more stable.
Yet there are still many things I want to improve in sparkle's core before adding new functions.
Also there are few demo videos on ftp.
Amazing!
Working great on my redmi 6 pro. Stock miui 9.9.3 rom. With linuxdeploy and sparkle from your ftp. No lag on visual and sound. My Linux distribution is alpinelinux arm64 arch.
Since first time I see your posting on 4pda. I'm interested in it. And finally it's on xda.
Thanks dev.
---------- Post added at 02:52 AM ---------- Previous post was at 02:44 AM ----------
For anyone interested in the topic. Please follow the instructions in documentation from ftp. And Translate it to eng from rus.
This sounds amazing! Just curious, is it related to https://github.com/twaik/sparkle ?
I now have it working very well on my Samsung Tab S3 using Xwayland and a tiling window manager. Firefox runs amazingly well!
Is it meant to be used only with Xwayland or will it also work with native Wayland applications?
BTW, I think if you open sourced this project and promoted it a bit, it could become quite popular. It's basically the first way to run X11 GUI applications on Android devices at full speed. If you set up a donation link, you could also get compensated for your time and effort. I'll personally contribute $20 if it's open sourced, and I'm sure others will chip in as well.
robsmith11 said:
This sounds amazing! Just curious, is it related to https://github.com/twaik/sparkle ?
Click to expand...
Click to collapse
Thanks for feedback. Nice to hear that someone managed to start this thing
Twaik's repository is clone of my very very old version of sparkle. I made that version years ago when I was just starting to learn linux and C++. Sparkle was rewritten from scratch two or three times since that version. And (I believe) current version is much better.
Regarding making it open source... Few months ago I had to find real job. Can't spend much time on personal projects any more. But I have my own strange programming style and my own vision of what sparkle should be. Not sure I want others to paint on my picture. It's probably all because of Twaik! I hate how he used old open source version of sparkle. He did terrible things to it, outraging all my beliefs Sorry!
P.S.: Yesterday I've uploaded another apk to my ftp. The file is called "sparkle-testing.apk". This version is much newer and has many fixes. But I've also changed to many things since tested version including some fundamental changes. No guarantee it will run at all on other devices. Interest is mega low and I get no test reports at all.
Hi Hentacler, I've just found your project - it looks really promising. Unfortunately, the only link currently working on this thread is to github. Is this project still live?
I have a samsung galaxy note 10+, and am using it as a laptop replacement. In addition to the android apps using Samsung Dex (Samsung's desktop solution), I have several linux distributions installed inside a chroot using userLand - so far, its working great. I'd be keen to give you project a try if it's still live, and am happy to help out with testing from my device.
Re open source - while I like your project, I'm not super interested in investing time into something that's not open sourced - I appreciate your concerns about wanting to maintain the direction, but having transparent development is pretty important to me. Is Twaik's fork of your project a better place to go?
Cheers.
tillum said:
Hi Hentacler, I've just found your project - it looks really promising. Unfortunately, the only link currently working on this thread is to github. Is this project still live?
I have a samsung galaxy note 10+, and am using it as a laptop replacement. In addition to the android apps using Samsung Dex (Samsung's desktop solution), I have several linux distributions installed inside a chroot using userLand - so far, its working great. I'd be keen to give you project a try if it's still live, and am happy to help out with testing from my device.
Re open source - while I like your project, I'm not super interested in investing time into something that's not open sourced - I appreciate your concerns about wanting to maintain the direction, but having transparent development is pretty important to me. Is Twaik's fork of your project a better place to go?
Cheers.
Click to expand...
Click to collapse
ftp://ftp.drivehq.com/mogryph/sparkle/
Link to FTP should work and there you can get two versions:
sparkle.apk - old version, but confirmed to work by 3-4 people.
sparkle-testing.apk - latest version, but only briefly tested by me.
I don't ask anyone to invest anything... Sparkle doesn't request root access or any other dangerous permissions (unless you enable automatic container mounting and starting) so it's safe to try for anyone who wants.
Btw, somewhere between these two versions I've replaced BASH container initialization script with LUA version. That was probably a bad idea. LUA script is harder to start directly as root and hacks I used may not work (currently may even cause application freeze if root access is denied). Going to revert to BASH probably. But this only touches people who want sparkle to mount container and launch everything automatically on single button press.
p.s.: Why I need to solve captcha every time I post something?
Thanks for the new release! I've updated and everything seems to be working without any changes on my Samsung Tab S3 with chroot and Arch Arm Linux.
Your changes also solved the flickering for me! The old version would flicker the screen whenever my keyboard's trackpoint activated, but it's not flickering at all any more. Performance seems to be about the same.
I think this could be quite popular, but not many people know about it. Perhaps a post on Hacker News or Reddit would raise awareness.
I understand your position on open source and maintaining control. One idea if you haven't already considered it is releasing the code with a restrictive license that forbids any forks. But either way, I'm enjoying being to properly use X11 on my tablet.
BTW, have you tried any native Wayland compositors? I don't really understand the Wayland ecosystem that well. I gave Sway a brief try, but it didn't seem to work. I've only been using XWayland.
@Hentacler Thanks for your reply! Very keen to get this working, but having a few issues. I'm unsure how to configure the user.lua file - I'm using your latest apk.
I have a non-rooted device, and am running archlinux under termux. Works fine with xsdl. I have installed xorg-server-wayland for X11. I'd appreciate any advice you have.
@robsmith11 Are you able to share how you got this working on Arch? Thanks!!!!
tillum said:
@Hentacler Thanks for your reply! Very keen to get this working, but having a few issues. I'm unsure how to configure the user.lua file - I'm using your latest apk.
I have a non-rooted device, and am running archlinux under termux. Works fine with xsdl. I have installed xorg-server-wayland for X11. I'd appreciate any advice you have.
@robsmith11 Are you able to share how you got this working on Arch? Thanks!!!!
Click to expand...
Click to collapse
I am not sure it is possible to use sparkle without root...
Sparkle makes it's directory accessible for everyone (chmod 777). Before Android 8 or 9 this was enough and xwayland from termux was able to connect to sparkle. Here is how people used to start it:
export XDG_RUNTIME_DIR=/data/data/com.sion.sparkle/files
Xwayland
But newer versions of Android brought more restrictions and termux can no longer connect to sparkle. These new restrictions are implemented using SELinux if you know what it is. Applications now have different security contexts.
But that is not all. Newest versions of android brought even more terrible meaningless restrictions effectively "killing" applications like termux and many others.
In short, from now one applications are not allowed to execute code (binary) that comes from "untrusted" sources. Termux used to download a lot of such code from it's own repositories. And now it can't. We can't even unpack binaries from assets.
So I can only help with rooted devices.
P.S. Please forgive me, but I am leaving this website. Making people solve recaptcha every time they want to post something is unacceptable level of contempt.
My mail: [email protected]
Thanks for that, will have a play. I could always just root my device. Weird about recaptcha, not having this issue. Currently through termux I have access to the whole sdcard, and am able to download packages (and distros) in it - will have a play and see what else is possible.
@tillum
I basically just followed the instructions on the first post for using Sparkle without busybox. I didn't need to modify the Lua scripts.
I'm guessing SELinux may be a problem without root. I'll try setting it up without root when I have a chance later.
This is a general service announcement. There is vulnerability in the Mali GPU drivers that allows for root access discovered by security researcher Man Yue Mo (CVE-2022-38181). The vulnerability goes way back and affects almost any device with a Mali GPU. That covers most of the FireHD tablets from the last 5 years, most of the FireTV televisions, and the 1st, 2nd and 3rd gen Cubes (and FireTV pendant).
Man Yue Mo posted a POC for the Pixel 6, that was adapted to work on the 2nd and 3rd gen FireTV Cubes. It takes a non-trivial number of changes to get it to work on other devices, and I don't have any FireHD tablets to work through it on. It appears that the cat's out of the bag on this exploit now, because the 2nd gen Cube just got an update that patches the POC. So I'm assuming a patch is coming (possibly even present) to other Fire devices as well, otherwise I would have kept it quiet for longer to try to work through some other devices.
Rortiz2 said:
This is really interesting and exciting. I wonder if this vulnerability affects any other Fire HD devices as well (obviously those using Mali GPUs). If you don't mind me asking, what are your plans regarding the PoC's source code? (nevermind, I think I found the original POC here). Could you give some hints regarding to what needs to be changed in order to port the exploit to other devices? I'd love to test it and learn more about this CVE.
Click to expand...
Click to collapse
I will try to post the source for the two Cube versions within the next day.
The Pixel 6 POC has to be modified for 32bit userspace, and there may need to be modifications to some of the struct's depending on which version of the Mali driver your device is using.
Kallsyms offsets need to be changed for any firmware you want to cover
Pool_size should be verified on your device
I'd also double check the path for define Mali, I've seen a couple devices that don't use the default path.
Lastly disabling selinux may need to be modified depending on the kernel version.
I'd start out with a device that you already have root on so that you can get any values needed, and use it as a potential template.
Edit: added 2nd and 3rd gen source code
Pro-me3us said:
I will try to post the source for the two Cube versions within the next day.
The Pixel 6 POC has to be modified for 32bit userspace, and there may need to be modifications to some of the struct's depending on which version of the Mali driver your device is using.
Kallsyms offsets need to be changed for any firmware you want to cover
Pool_size should be verified on your device
I'd also double check the path for define Mali, I've seen a couple devices that don't use the default path.
Lastly disabling selinux may need to be modified depending on the kernel version.
I'd start out with a device that you already have root on so that you can get any values needed, and use it as a potential template.
Edit: added 2nd and 3rd gen source code
Click to expand...
Click to collapse
Thank you for your the brief explanation regarding the changes that need to be made. We are currently attempting to exploit the Fire HD8 2020 (onyx), but have encountered an issue. We were able to extract the kallsyms table using this script, which seemed to work correctly. However, we have discovered that some of the kallsyms appear to be missing, specifically:
sel_read_handle_unknown: ffffff80083b08b0
selinux_enforcing: Doesn't seem to exist.
init_creds: Doesn't seem to exist.
commit_creds: ffffff80080dc530
add_init: Doesn't seem to exist.
add_commit: Doesn't seem to exist.
We have also observed that the tablet crashes after increasing FLUSH_SIZE (which seems to be normal as per the comments in the source code of the PoC), probably indicating that this device is indeed vulnerable to the CVE. Do you have any suggestions on how we can proceed with regards to the missing kallsyms?
Rortiz2 said:
Do you have any suggestions on how we can proceed with regards to the missing kallsyms?
Click to expand...
Click to collapse
I don't know if it's a good idea to go through methods publicly since it will help instruct Amazon on how to make future probing and intrusions harder for other exploits. I'll pm you
Rortiz2 said:
Thank you for your the brief explanation regarding the changes that need to be made. We are currently attempting to exploit the Fire HD8 2020 (onyx), but have encountered an issue. We were able to extract the kallsyms table using this script, which seemed to work correctly. However, we have discovered that some of the kallsyms appear to be missing, specifically:
sel_read_handle_unknown: ffffff80083b08b0
selinux_enforcing: Doesn't seem to exist.
init_creds: Doesn't seem to exist.
commit_creds: ffffff80080dc530
add_init: Doesn't seem to exist.
add_commit: Doesn't seem to exist.
We have also observed that the tablet crashes after increasing FLUSH_SIZE (which seems to be normal as per the comments in the source code of the PoC), probably indicating that this device is indeed vulnerable to the CVE. Do you have any suggestions on how we can proceed with regards to the missing kallsyms?
Click to expand...
Click to collapse
FYI, if you want to test anything on other devices i have almost everything 10 gen and below, including the hd8 (10). Totally dont care if i brick them, they arent used regularly... Including a unlocked and locked fire 7 (2019)
Graphics adapter
ARM Mali-T720 MP
I'll gladly run any testing on my devices as well. Fire 7 (2019) and HD 10+ (2021) both running firmware version 7.3.2.1.
I have an already-rooted Karnak (8th gen HD 8) that I can reflash to any OS needed - do let me know if it can be of any service to the cause.
Pro-me3us said:
I don't know if it's a good idea to go through methods publicly since it will help instruct Amazon on how to make future probing and intrusions harder for other exploits. I'll pm you
Click to expand...
Click to collapse
I am also facing trouble to find kallsyms - add_init add_commit values. can you help me to find that
mind _spacer said:
I am also facing trouble to find kallsyms - add_init add_commit values. can you help me to find that
Click to expand...
Click to collapse
The values you're referring to are not kernel symbols, but rather shellcode(s). You'll need to adjust the ADD_* values to align them with your specific kallsyms. The following example shows the correct values for the Amazon Fire HD8 2020 (onyx):
Code:
#define AVC_DENY_7314_1443 0x3252F4 // avc_denied.isra.6
#define SEL_READ_HANDLE_UNKNOWN_7314_1443 0x3308B0
#define PREPARE_KERNEL_CRED_7314_1443 0x5C8E8
#define COMMIT_CREDS_7314_1443 0x5C530
#define ADD_PREPARE_KERNEL_CRED_7314_1443 0x9123a108 // add x8, x8, #0x8E8 <-- prepare_kernel_cred
#define ADD_COMMIT_7314_1443 0x9114c108 // add x8, x8, #0x530 <-- commit_creds
As you can see, these values are ARM assembly opcodes encoded as 32-bit constants. In this case, they represent the add operation on the x8 register. To create these constants, you can use online converters or the ARM instruction set encoding.
For instance, add x8, x8, #0x8E8 is encoded into the 32-bit value 0x9123a108 using the following breakdown:
91000000 - Base value for ADD (immediate) instruction with 64-bit registers (this will be different for non-ARM64 archs).
00001000 - Destination and first operand register (x8 in binary).
00111010 - Immediate value to be added, rotated right by 12 bits (0x8E8 rotated - prepare_kernel_cred).
00000001 - Shift amount for immediate value (1*12, since immediate value is specified in multiples of 12).
I actually implemented a function to dynamically craft the values, but I never tried it so far. In case anyone is interested, this is how it looked like:
Code:
#define ADD_OPCODE_ARM64 0x91000000 // ARM64
#define ADD_OPCODE_ARM32 0xE0000000 // ARM32
uint32_t add_off_to_reg(uint32_t offset, uint8_t reg) {
uint32_t add_value = ADD_OPCODE_ARM64;
add_value |= reg; // Rd
add_value |= reg << 5; // Rn
add_value |= (offset & 0xFFF) << 10; // imm12
LOG("add x%d, x%d, %#x: 0x%08X\n", reg, reg, offset, add_value);
return add_value;
}
I hope this helps you!
Rortiz2 said:
The values you're referring to are not kernel symbols, but rather shellcode(s). You'll need to adjust the ADD_* values to align them with your specific kallsyms. The following example shows the correct values for the Amazon Fire HD8 2020 (onyx):
Code:
#define AVC_DENY_7314_1443 0x3252F4 // avc_denied.isra.6
#define SEL_READ_HANDLE_UNKNOWN_7314_1443 0x3308B0
#define PREPARE_KERNEL_CRED_7314_1443 0x5C8E8
#define COMMIT_CREDS_7314_1443 0x5C530
#define ADD_PREPARE_KERNEL_CRED_7314_1443 0x9123a108 // add x8, x8, #0x8E8 <-- prepare_kernel_cred
#define ADD_COMMIT_7314_1443 0x9114c108 // add x8, x8, #0x530 <-- commit_creds
As you can see, these values are ARM assembly opcodes encoded as 32-bit constants. In this case, they represent the add operation on the x8 register. To create these constants, you can use online converters or the ARM instruction set encoding.
For instance, add x8, x8, #0x8E8 is encoded into the 32-bit value 0x9123a108 using the following breakdown:
91000000 - Base value for ADD (immediate) instruction with 64-bit registers (this will be different for non-ARM64 archs).
00001000 - Destination and first operand register (x8 in binary).
00111010 - Immediate value to be added, rotated right by 12 bits (0x8E8 rotated - prepare_kernel_cred).
00000001 - Shift amount for immediate value (1*12, since immediate value is specified in multiples of 12).
I actually implemented a function to dynamically craft the values, but I never tried it so far. In case anyone is interested, this is how it looked like:
Code:
#define ADD_OPCODE_ARM64 0x91000000 // ARM64
#define ADD_OPCODE_ARM32 0xE0000000 // ARM32
uint32_t add_off_to_reg(uint32_t offset, uint8_t reg) {
uint32_t add_value = ADD_OPCODE_ARM64;
add_value |= reg; // Rd
add_value |= reg << 5; // Rn
add_value |= (offset & 0xFFF) << 10; // imm12
LOG("add x%d, x%d, %#x: 0x%08X\n", reg, reg, offset, add_value);
return add_value;
}
I hope this helps you!
Click to expand...
Click to collapse
Thank you for the brief reply, definitely it helped a lot.
Pro-me3us said:
I will try to post the source for the two Cube versions within the next day.
The Pixel 6 POC has to be modified for 32bit userspace, and there may need to be modifications to some of the struct's depending on which version of the Mali driver your device is using.
Kallsyms offsets need to be changed for any firmware you want to cover
Pool_size should be verified on your device
I'd also double check the path for define Mali, I've seen a couple devices that don't use the default path.
Lastly disabling selinux may need to be modified depending on the kernel version.
I'd start out with a device that you already have root on so that you can get any values needed, and use it as a potential template.
Edit: added 2nd and 3rd gen source code
Click to expand...
Click to collapse
Is this POC works on android devices (such as samsung) having mali driver , if its works can you tell me the modifications need to done on struct's and disable selinux depending on kernel version(which u mentioned) and what are the changes do we need to do?
mind _spacer said:
Is this POC works on android devices (such as samsung) having mali driver , if its works can you tell me the modifications need to done on struct's and disable selinux depending on kernel version(which u mentioned) and what are the changes do we need to do?
Click to expand...
Click to collapse
Knowing nothing about your device, it's hard to know what changes are required to get the POC to run. What is the device kernel version and Mali driver type and version? Is it using a 32bit or 64bit version of Android? Do you have a copy of the firmware that your device is currently using (most importantly boot.img)? Do you have the source code for the kernel? Is the source code for the same version of the firmware that your device is currently running?
There are a few ways to do things depending on what resources you have available to you.
Following....with my 2021 Fire HD 10 running 7.3.2.1
Pro-me3us said:
Knowing nothing about your device, it's hard to know what changes are required to get the POC to run. What is the device kernel version and Mali driver type and version? Is it using a 32bit or 64bit version of Android? Do you have a copy of the firmware that your device is currently using (most importantly boot.img)? Do you have the source code for the kernel? Is the source code for the same version of the firmware that your device is currently running?
There are a few ways to do things depending on what resources you have available to you.
Click to expand...
Click to collapse
This is the spec of my device:
Samsung M30s (M307FXXU4CVD1)
Android 11, 64-bit version
Kernel - 4.14.113
Security patch level - 1 Mar 2022
Mali - G72 MP3, version - r26 p0
I have the source code and firmware image of this device. And I have found the device specific offsets (from elf of kernel) and @Rortiz2 helped me to find some of it, kernel base address (by reading header of boot.img) and path defined for mali is correct.
I tried to run the original POC but device reboots at the after it prints "Cleanup flush region" part.
then, I tried ur poc which ends by "Release_mem_pool" and reboot.
Hope you could help me.
mind _spacer said:
G72 MP3, version - r26 p0
I have the source code and firmware image of this device. And I have found the device specific offsets (from elf of kernel) and @Rortiz2 helped me to find some of it, kernel base address (by reading header of boot.img) and path defined for mali is correct.
I tried to run the original POC but device reboots at the after it prints "Cleanup flush region" part.
then, I tried ur poc which ends by "Release_mem_pool" and reboot.
Click to expand...
Click to collapse
I'm assuming that Mali driver type is Valhall? or Bifrost? Midgard?
Valhall r26p0 might be recent enough that you don't need to make any struct changes to for older driver compatibility.
Since your device is using 64bit Android, I'd stick to the original Pixel6 POC. A lot of the changes in my two POCs was 64bit to 32bit conversations. The 32bit POC may work on your device, but I don't know if there are any incompatibilities. Better to avoid any potential 32bit complications.
What are the 6 kernel addresses that you plugged in to the Pixel6 POC for your device?
Pro-me3us said:
I'm assuming that Mali driver type is Valhall? or Bifrost? Midgard?
Valhall r26p0 might be recent enough that you don't need to make any struct changes to for older driver compatibility.
Since your device is using 64bit Android, I'd stick to the original Pixel6 POC. A lot of the changes in my two POCs was 64bit to 32bit conversations. The 32bit POC may work on your device, but I don't know if there are any incompatibilities. Better to avoid any potential 32bit complications.
What are the 6 kernel addresses that you plugged in to the Pixel6 POC for your device?
Click to expand...
Click to collapse
I'm trying to work with your gazelle POC as a base for amazon mustang (midgard r26p0), but I have some questions; what is alloc.in.flags (1 << 22) in spray()? It doesn't seem to match any base_mem_alloc_flags I could find for either the cube or the mustang.
I'm also getting -EPERM on the alias_sprayed_regions() mmap(), presumably because of MAP_SHARED. When ORed with MAP_ANON the mmap64 call succeeds, however find_pgd() then fails because the pages are all zeroed. Can you advise?
@Pro-me3us
A temp root would be great - at least, to make backups easier. is this new exploit realistic to get working on hd tablets? Do you have a tablet like that to try ?
relalis said:
I'm trying to work with your gazelle POC as a base for amazon mustang (midgard r26p0), but I have some questions; what is alloc.in.flags (1 << 22) in spray()? It doesn't seem to match any base_mem_alloc_flags I could find for either the cube or the mustang.
I'm also getting -EPERM on the alias_sprayed_regions() mmap(), presumably because of MAP_SHARED. When ORed with MAP_ANON the mmap64 call succeeds, however find_pgd() then fails because the pages are all zeroed. Can you advise?
Click to expand...
Click to collapse
I have never taken a look at Midgard.
Midgard r26p0 - July, 2018 (mustang)
Bifrost r25p0 - June, 2020 (gazelle)
Bifrost r16p0 - December, 2018 (raven)
Based on the timing, I would use the raven POC as your base, because the driver is likely more similar. This is related to the issue you were asking about. Bifrost r16p0 doesn't support the memory pool group which is that flag. Support for that was added somewhere between Bifrost r16p0 and r25p0, and Midgard r26p0 may not support it either. Check out the changes made in Raven, I basically just removed it.
bibikalka said:
@Pro-me3us
A temp root would be great - at least, to make backups easier. is this new exploit realistic to get working on hd tablets? Do you have a tablet like that to try ?
Click to expand...
Click to collapse
There are two parts to the POC, the GPU driver exploit, and disabling selinux to open a root shell. The GPU exploit portion should be mostly compatible between devices. If your device is using 64bit userspace, use the original Pixel6 POC which shouldn't have any driver incompatibilities back to about Bifrost r25p0 (2020). The Pixel6 uses Valhall, i'm not sure what driver version was available in 2020. If you have a device with 32bit userspace like most Amazon devices, then either the raven or gazelle POC should work for the GPU exploit portion. Midgard may have other unknown differences that need to be addressed
Disabling selinux / rootshell fixup portion is the part that needs to be modified to get the POC working with any individual tablet, because this portion has kernel specific instructions. This part of the POC probably isn't going to be as simple as swapping a couple kallsyms addresses. I think @Rortiz2 was working on getting the selinux / rootshell fixup working a few of the tablets. Using that as a base for the other MediaTek tablets might be more useful than my POCs, assuming they are more similar.
The new POC uses a race condition and the GPU portion is a bit more complicated, and may need more device specific tuning. The selinux / rootshell portion is mostly the same as the older exploit. The new user_buf exploit exploit mostlyonly has the advantage of working on Bifrost r38p0 which is the driver Amazon updated the Cubes to, to patch the shrinker exploit.
@mind _spacer sorry, I didn't notice your device kernel version before. The pixel6 POC handles the rootshell portion by disabling AVC_deny, for kernels older than 5.0 it may be easier to substitute selinux_enforcing, at least that's what was done for raven. I struggled a bit to get the rootshell portion working on both raven and gazelle. @rortiz was able to adapt it to one of the FireTablets in just a couple days, so he probably has a much better understanding and might be able to offer insights.
Pro-me3us said:
There are two parts to the POC, the GPU driver exploit, and disabling selinux to open a root shell. The GPU exploit portion should be mostly compatible between devices. If your device is using 64bit userspace, use the original Pixel6 POC which shouldn't have any driver incompatibilities back to about Bifrost r25p0 (2020). The Pixel6 uses Valhall, i'm not sure what driver version was available in 2020. If you have a device with 32bit userspace like most Amazon devices, then either the raven or gazelle POC should work for the GPU exploit portion. Midgard may have other unknown differences that need to be addressed
Disabling selinux / rootshell fixup portion is the part that needs to be modified to get the POC working with any individual tablet, because this portion has kernel specific instructions. This part of the POC probably isn't going to be as simple as swapping a couple kallsyms addresses. I think @Rortiz2 was working on getting the selinux / rootshell fixup working a few of the tablets. Using that as a base for the other MediaTek tablets might be more useful than my POCs, assuming they are more similar.
Click to expand...
Click to collapse
A bulk of Fire HDs was 32 bit user space indeed, armv8l was the kernel on many (HD10 2019 that i have). HD10 2021 became aarch64.
I thought @diplomatic had a fairly generic code to disable selinux fairly for all devices within his MTK exploit? Or was that a lot more different than here? Too bad a lot of old crew seems to have scattered, so much less capability around here these days (looking at @k4y0z here ).
What's the best way to find out the version of MALI driver that the device is using?
bibikalka said:
What's the best way to find out the version of MALI driver that the device is using?
Click to expand...
Click to collapse
KBASE_IOCTL_VERSION_CHECK will return param.major and param.minor API versions, as to the driver type (midgard/bifrost/valhal) you'll have to look at Amazon's source code release for the individual devices, or perhaps find the relevant page on postmarketos wiki