Related
In playing around with overclocking the Epic, I created this spreadsheet:
https://spreadsheets.google.com/ccc?key=0Ajd2hyK6pVbidDRhQ0VWOEVlN1VaMW9QSl9rcXExOHc&hl=en
I do not know if sharing the spreadsheet will allow you to temporarily edit the values to play with it or if you will need to make your own copy to play...
The formulas were gathered from S5PC110_EVT1_UM10.pdf which describes the SOC in our Epics.
It allows you to enter in the APLL m,p,s and the MPLL m,p,s and the Dividers on the second sheet and it will display the clock speeds that will be provided to the various components. On third sheet it will actually generate the code to be put into clock.c to test out the values.
One of the most interesting things that I noticed is that the combination of MPLL, MFCDiv, G3DDiv and G2DDiv are ONLY used when the CPU speed is changing to make sure that the A2M speed does not jump too much for the graphics components to continue working before the A2M DIV can be updated. A2M DIV is always kept at 200, depending on the speed, the graphics clock can drop to 166 or so when the CPU is changing speed (could lead to a stutter, I would think).
Something else that I noticed in there is the 2D graphics chip is mentioned as being capable of 250Mhz, while the other two graphics components are only 200Mhz.
Each of the Graphics components can independently choose their clock from one of four sources (currently it uses two A2M and MPLL), it can also use EPLL and VPLL, between those four clocks we may be able to find a group of combinations that will allow us to overclock parts of the graphics components individually and hopefully by small enough increments it does not fail (my first few attempts lead to needing to use odin to restore my epic).
One thing to note is APLL can generate 30MHz to 1GHz (so if I read this correctly we are using it above its capabilities to overclock), MPLL can generate 50Mhz-2Ghz, EPLL can generate 10Mhz - 600 Mhz, VPLL can generate 10Mhz - 600Mhz.
Just looking to generate some new discussion and innovation for our Epics... I am in no way an expert, just learning and sharing what I found out...
Geoff
1st!
10 char
What are you making here?
Sent from my Epic 4G using XDA Premium app
hi all,
I've updated DOSBOX's dynrec core to take advantage of the THUMB2 ARMv7 instructions that must be supported on Windows RT. Among other things, this includes being able to move immediates to registers without using a PC relative load, 32-bit instructions that allow access to all registers, etc. I also added a PLI instruction to preload a cacheblock into the instruction cache before it is executed, and PLD instructions to prefetch data for a minor speedup.
Testing on doom timedemo, I get 3721 realtics, which is a modest 5% speedup from the standard dynrec core. Probably not having directX is a significant bottleneck on video drawing, this can get fixed once I get a wrapper around directinput working. Hopefully these changes can also help out mamaich's x86 pe loader out a well.
-- old post below--
I managed to get dosbox compiled with mamaich's new updates (see below), so we now have dosbox with the dynamic recompiling core. I also included network support which seems to work.
The dynamic recompiling core does give better performance for newer apps. 3982 realtics vs 18088 realtics on doom timedemo, so about a 5x gain
The next step would be to get a better graphics core. There is an opengl wrapper for DX11 called gl2dx that I'm looking into.
I'm also looking at putting at optimizing dynrec for thumb2, for example, it seems that CBZ might be useful (except it only lets you branch forward!!!)
Hmm, I have to unfortunately note that DOS4GW doesn't seem to work in this build. I'm working on it!
In the mean time, enjoy commander keen 1 -6?...
no2chem said:
Hmm, I have to unfortunately note that DOS4GW doesn't seem to work in this build. I'm working on it!
In the mean time, enjoy commander keen 1 -6?...
Click to expand...
Click to collapse
So in the end, I think the dynamic recompiler has some issues.
I know that the VirtualAlloc function is correctly setting execute permissions on memory pages, but I don't know if FlushInstructionCache is actually flushing the instruction cache. It's also possible that the dynamic recompiler is emitting bad assembly, but inspecting the code... doesn't look like it!
no2chem said:
So in the end, I think the dynamic recompiler has some issues.
Click to expand...
Click to collapse
The same issue for me (but I'm using a bit obsolete DosBox sources, need to update). May be this is due to EABI changes (for example registers are not preserved), as DosBox dynamic core targets Linux.
Regarding DosBox. Look here - http://vogons.zetafleet.com/viewtopic.php?t=31787
This is the ARMv7 optimized dynamic core for DosBox by M-HT. It is not yet integrated into the official DosBox branch.
If you're concerned about FlushInstructionCache not being implemented correctly, let me know. As part of my work to port Chromium, I've learned how to do cache management in ARM a little closer to the metal (moving the relevant values to the coprocessor registers directly) and have both more control (for example, clearing the data cache lines as well) and more precise control over exactly what is done to the cache lines.
However, bear in mind that I haven't been able to properly test this yet, as too much of the Chromium core still doesn't want to compile for me... *sigh*.
GoodDayToDie said:
If you're concerned about FlushInstructionCache not being implemented correctly, let me know.
Click to expand...
Click to collapse
As far as I see - FlushInstructionCache works as expected (flushes icache). DosBox crashes due to some other reason, maybe due to the ARM-THUMB interworking problems (it is just a guess).
Good to know. It would be annoying if the official API were wrong...
I've found whu DosBox dynamic core crashes at random.
All existing dynamic cores use ARM code, even the thumb files are using the ARM prologue. Though our CPUs can run the ARM code, there is a bug (?) in RT that switches ARM code to be executed as a THUMB at random. For example you call an ARM procedure 100000 times, but at 100001 something happens and the code starts to execute as THUMB. Maybe a task switch occurs, or maybe some interrupt happens, and when OS returns to your code - it sets T bit in CPSR, so the code is interpreted as THUMB.
I was able to modify the prologue generator in risc_armv4le-thumb-iw.h so that it generates only THUMB code, and now everything started to work in my project. Attached. Code is ugly and unfinished and uses some dirty C hacks, I'll fix them later as it is deep night now. But you may look on the changes and implement similar things in a DosBox build.
mamaich said:
I've found whu DosBox dynamic core crashes at random.
All existing dynamic cores use ARM code, even the thumb files are using the ARM prologue. Though our CPUs can run the ARM code, there is a bug (?) in RT that switches ARM code to be executed as a THUMB at random. For example you call an ARM procedure 100000 times, but at 100001 something happens and the code starts to execute as THUMB. Maybe a task switch occurs, or maybe some interrupt happens, and when OS returns to your code - it sets T bit in CPSR, so the code is interpreted as THUMB.
I was able to modify the prologue generator in risc_armv4le-thumb-iw.h so that it generates only THUMB code, and now everything started to work in my project. Attached. Code is ugly and unfinished and uses some dirty C hacks, I'll fix them later as it is deep night now. But you may look on the changes and implement similar things in a DosBox build.
Click to expand...
Click to collapse
I'll take a look at getting that implemented in my build.
Edit: Haven't looked into it much, but DosBox crashes whenever I open any 32-bit stuff.
mamaich said:
I've found whu DosBox dynamic core crashes at random.
All existing dynamic cores use ARM code, even the thumb files are using the ARM prologue. Though our CPUs can run the ARM code, there is a bug (?) in RT that switches ARM code to be executed as a THUMB at random. For example you call an ARM procedure 100000 times, but at 100001 something happens and the code starts to execute as THUMB. Maybe a task switch occurs, or maybe some interrupt happens, and when OS returns to your code - it sets T bit in CPSR, so the code is interpreted as THUMB.
I was able to modify the prologue generator in risc_armv4le-thumb-iw.h so that it generates only THUMB code, and now everything started to work in my project. Attached. Code is ugly and unfinished and uses some dirty C hacks, I'll fix them later as it is deep night now. But you may look on the changes and implement similar things in a DosBox build.
Click to expand...
Click to collapse
thanks for figuring that out! its a bit odd though, don't you think - wouldn't normal ARM apps crash if this was the case? I'm sure most stuff is compiled with interworking, maybe ms interworking convention is different?
Anyway, I was thinking, doesn't homm3 use directx? Is your emulation layer also doing conversion of that code? It seems like it would be useful to have native wrappers for old versions of DX so they can take direct advantage of DX11 native. Alas, that's for another day.... Also, mfc would be nice too... (its there... MS just didn't provide the .lib, ordinals are [noname]'d out, and .pdb from debug server seems to be missing some exports....)
no2chem said:
hi all,
I managed to get dosbox compiled with mamaich's new updates (see below), so we now have dosbox with the dynamic recompiling core. I also included network support which seems to work.
The dynamic recompiling core does give better performance for newer apps.
The next step would be to get a better graphics core. There is an opengl wrapper for DX11 called gl2dx that I'm looking into.
I'm also looking at putting at optimizing dynrec for thumb2, for example, it seems that CBZ might be useful (except it only lets you branch forward!!!)
Click to expand...
Click to collapse
How big performance gains are you talking about?
bartekxyz said:
How big performance gains are you talking about?
Click to expand...
Click to collapse
Eh, 3982 realtics vs 18088 realtics on doom timedemo, so about a 5x gain
Nice! That should (eventually) allow quite a few legacy apps, if they're old enough and/or not to performance-sensitive (i.e. not realtime) to run acceptably.
no2chem said:
doesn't homm3 use directx? Is your emulation layer also doing conversion of that code?
Click to expand...
Click to collapse
No conversion, I just pass DX to the native OS libraries with some minimal wrappers. RT provides even DirectX 1.0 interfaces
The only problem is that RT prohibits non 32-bit color modes, though video driver supports them (at least 16 bit color is supported by tegra driver).
no2chem said:
I managed to get dosbox compiled with mamaich's new updates
Click to expand...
Click to collapse
I'm using ARM/Tumb dynamic code created by M-HT: http://vogons.zetafleet.com/viewtopic.php?t=31787
I've changed just one function.
I'm also looking at putting at optimizing dynrec for thumb2, for example, it seems that CBZ might be useful (except it only lets you branch forward!!!)
Click to expand...
Click to collapse
Please post your code changes somewhere, so that I could use them in my project too
don't you think - wouldn't normal ARM apps crash if this was the case? I'm sure most stuff is compiled with interworking, maybe ms interworking convention is different?
Click to expand...
Click to collapse
NTARM kernel is a THUM2-only kernel. There is no interworking it it. So it is possible that MS code intentionally sets the T bit to THUMB when returning from interrupt or a task-switch. Unfortunately this means that we can't use ARM code in our programs (I have not seen any ARM code in MS progs, only THUMB2). Anyway, THUMB2 code is very efficient now, its speed can be the same as of ARM code, and size is much smaller.
Generally, THUMB2 should outperform ARM, yes. Also, the state of Thumb vs. Arm is actually set in a kind of weird way: rather than manually setting a processor bit, it's controlled by the jump address. Since even THUMB2 instructions are always 16-bit (2-byte) aligned, the least significant bit of an instruction address is never 1. Therefore, that bit is used (on any jump-type instruction) as a flag to indicate whether the processor should use ARM or THUMB2 mode. In theory, this should mean that the OS doesn't care about the mode being used... but I've never written an interrupt handler for ARM (a couple other platforms, but not ARM) and there might be something weird going on with them.
GoodDayToDie said:
rather than manually setting a processor bit, it's controlled by the jump address
Click to expand...
Click to collapse
This is true for normal jumps. And that is why we have to set lowest bit to 1 manually on indirect branches inside autogenerated THUMB code. But for CPU itself the mode is kept in T bit in CPSR. And "something" sets it to 1 "sometimes". I have not done much testing, but I think that this should be an interrupt, as I've seen that bit changed in the middle of a generated ARM code.
Anyway the THUMB2 code is better then ARM for us - it is more compact, so more code may be kept in cache (both in CPU and DosBox dynamic recompilator's).
updated with a thumb2 dynrec.
Touch input for mouse
For anyone that wants to use their touchscreen for mouse input, navigate to their %AppData%\Local\DosBox folder and modify the dosbox-0.74.conf file so that "Autolock=true" is "Autolock=false"
It works pretty well with the touchscreen and an on-screen keyboard for gaming and such
[REVIEW] Phablet/Console Much i5 (5" Quad-Core)
Note
Due to the limitations of this forum, i cannot put the full version of the review. THIS IS NOT THE FULL REVIEW ARTICLE
For the complete version of this review visit my blog .
Package contents(Unboxing y full description of the package contents)
When the package is opened, we found the following elements that, i understand, are part of any standard shipment for this product.
Much i5 Device
Quick guide
Guarantee sheet
MicroUSB cable
USB Wall charger
3550 mAh Battery
Serial number sticker
About first impression
My first impression of the device was so good. I really feel that the device materials and quality is distinct that other devices i tested.
There is lots of details that make a difference, from the device design, or the software included, or the customization made on the system, etc.
The first time you boot the device, you get a screen to register an iMuch account. This is not required really, but you can do these steps to gain access for Much services (note: most in chinese). In my tests, i remove my Much account, and i can use the device without problems.
(First boot)
There is a icon called Much Helper, that really is a quick guide to use the device, that is so interesting and helpful (this come in english), and show you in short steps the main features of the device and how to use.
Is really nice get a device like this that manufacturer take care about heir users, and provide ways to get familiar and comfortable with the device like this (and in english, a common language).
Another thing that i get may attention is that this device come with no much bloatware, and the games listed are to download from the google playstore (instead of a separated store with software from a non clear origin)
Most of this games are free, or demo versions.(and i thanks for it, because the system come with no unecessary software pre-installed)
Product information
According with the manufacturer, or searching info on web pages, we can found many sources of information about the device and sometimes these information may be not consistent (may be different from one web page to other), and this may cause some confusion for anybody that wants to get info about this product.
On this section i will post the info i get from the manufacturer (or is not possible, the web page that i consider more reliable), listing only the relevant points for a tech analysis of the product, and omit these points that don´t get any relevant info about the device (as many time we found on many pages, things such video capabilities, mail capabilities, etc, that really are software based features that we can install on the device, and not a real feature of the device itself)
CPU(RAM): MTK6589 quad-core 1.2GHz Cortex A7
GPU: PowerVR Series 544
RAM: 1G RAM LPDDR2
Internal: 4GB ROM
Screen size: 5"
Screen resolution: 1280x720
Screen Type: IPS Panel, Multitouch 5 points
Operating System: Android4.2 (Much Launcher)
Storage: MicroSD(TF) support 64GB storage expand maximum
Sensor: Nine-axis sensing (gyroscope, electronic compass, and gravity sensing), and light-sensitive sensing, close up sensing
Camera: Main camera of 8 MPx, digital zoom, auto focus, microspur support, Flash LED. Front camera of 0.3 MPx;
Network Function: support WCDMA 850M/2100M GSM 850/900/1800/1900MHZ, HSUPA(high speed uplink):up to 11.5 Mbps,HSDPA+( high speed downlink):up to 42.2 Mbps
Wifi: 802.11b/g/n
bluetooth: V4.0LE +EDR
GPS: with AGPS support
Buttons: 4 action buttons, 2 Shoulder buttons, 2 special buttons (configurable), DPAD and 2 analog sticks.
Video Play: Hardware decoding, maximum resolution up to 1280x720P, H.264, MPEG4, MPEG2, VC-1, H.263
Audio System: D-class amplifier , AAC speaker (2x0.5w)
Power Supply: 3550mAh Lithium battery
Charge: dual interface charge, (Bottom) Micro USB charge interface 1A charge, (Top) Micro USB charge interface 500mA charge maximum.
TV-Out: Mini HDMI interface (support 1080P)
USB: MicroUSB OTG 2.0
Dual standard SIM card(WCDMA/GSM) + MicroSD(TF) card
size: 184.0x88.0x14.7mm
Antutu X Benchmark
Summary:
RAM Operation: 1089
RAM Speed: 502
CPU integer: 1819
CPU float-point: 1242
2D graphics: [720x1280] 646
3D graphics: [720x1280] 3294
Storage I/O: 832
Database I/O: 515
CPU frequency: 1209 MHz (x4)
Multitask: 2661
Dalvik: 780
Total: 13380
ClockWorkMod Recovery (Custom Recovery)
Android have a special mode called Recovery, that is used many times to recover the device if this have problems to run properly, but there exist an alternative Custom Recovery that add a lot of new functionality and tools, and one of the most popular is one called ClockWorkMod Recovery.
There is a full functional version of this recovery that run on this device.
One of the most important features of this custom recovery, is the NANDROID generation, a way to generate a full backup of the nand (where the operating system resides) to a directory, and can be used as a recovery point for the device in case of semi-brick, or simply if you want to get a clean firmware on it.
Take note that this backup (nandroid) is a image of the NAND, this means, there will be stored all your configs, users, passwords, accounts, etc. Is a good idea to get a clean firmware insatlled on the device, and install and configure all your base programs (file admins, cloud services, google account, etc) and then get a nandroid for your personal use. When you get back to this image/backup, you will get a clean and configured system, saving lot of time on basic configurations and installing basic software.
The installation of CWM on this device is easy. For this, i follow the next thread on XDA forum:
How to install CWM on most rooted mtk devices
This method is based on Rua1 tool (a russian guy that develop a specific MTK took), and i will try to explay step by step.
First, you need the drivers ADB installed on the system. If you don´t get yet, then download and install PDANet (for windows, there is the 4.12 installer).
Then install PDANet, and when the program ask for connecting the device (USB), connect your Much.
Program will install drivers (if ask to you, select "other manufacturer" for generic drivers)
When you get installed this program, then go and download "MTK Droid Root & Tools | MediaTek Android Smartphone" ver 2.4.8 (from this thread on XDA)
Run the program. If the antivirus or firewall warning about a unknown thread, ignore it.
The program will run adb and connect with your device. No matter if you set root for ADB and Apps in System Settings, the program will inform that the device is not fully rooted. (there is a yellow rectangle)
Press ROOT button.
When finished, the rectangle will be green
(I will do a copy paste from XDA thread, because is well explained what you must to do)
Click on the tab 'root,backup,recovery' and select 'to use boot from phone' then click on 'recovery and boot' and shortly after a dialogue box will appear asking if you want to 'make cwm recovery automatically' click yes
System start to generate the CWM version.
Is possible that the tool show a dialog with a warning "ATENTION! There is a probability to damage the boot block!". Select "Yes"
Android Games
Asphalt 8: Airborne
(Using Tincore to control the game)
Jet Set Radio
Bard´s Tale
Dead Trigger
N.o.v.a. 3
Using HDMI TV Out, External controller (PXN8633 Wireless controller with USB receiver) and Tincore to map the controller to screen.
Modern Combat 4: Zero Hour
Using HDMI TV Out, External controller (PXN8633), and Tincore for mapping.
Ravensword
Grand Theft Auto Vice CityUsing External Controller and Tincore for mapping.
DraStic (Nintendo DS)
Zelda Phantom Hourglass
PPSSPP (Playstation Portable PSP)
Lego Indiana Jones 2
Mame4Droid Reloaded (Arcades)
Garou: Mark of Wolves
Marvel vs Capcom
Retroarch
Arcade (MAME) - Ultimate Mortal Kombat 3
PSX - Tekken 3
N64Oid (Nintendo 64)
Bad Fur Day
(Gameplay)
About Battery
Some words i must to say about this point. This device is the first handheld gaming console that i forgive to take care constantly about battery level. In fact, using as a normal smartphone and as a gaming console, is a heavy use for me, more than my normal smartphone (i like to use a Motorola Razr), and my phone, only as phone, battery is not longer than Much device.
I don´t know how many hours it can be working, but i´m sure is enough for most of users that want a good duration.
Check the following screenshots:
These 3 screenshots was taken when i get in home, in night (well, really when i remember to take these screenshots)
The most important of these screenshots, are that the device was working as normal usage, with WIFI enabled, one SIM card enabled, and most time (when i´m in train or bus) with Bluetooth enabled (for bluetooth audio), with all normal options for a smartphone standard enabled (GPS, Vibration, etc), and most important, playing normally, and the battery, well, you can see the images. For this reason i can mention that i forgot to check constantly the battery level, to calculating how many time i can play, or anything.
And of course, the battery is replaceable, then if you really need more battery duration, simply buy another battery pack, and carry with you to replace when you go out of power.
Final words
Apologize for the mistakes i did writing in english. As many of you know, this is not my natural language, but i did my best to try to bring to you a readable and understandable article that, sincerely, i hope is useful.
And remember this is not a full article review. It is only a Summary.
Zalu2!
Deen0X
re-install MUCH I5
Hello,
I have one Much I5. This device was bricked somehow and I need to re-install it. I made all the instruction on your blog but after pressing Vol- android screen suddenly disappear and I can only see ireadygo screen and I could not do anything else. Could you help me to re-install this device may be from pc ?
Thank you & best regards,
(please note: I would like to post this to the developer forum, but since I just registered, I'm not allowed to do so. furthermore, I'm not allowed to post direct links (see below))
I would like to announce a new library for GPU-based processing on mobile systems – ogles_gpgpu.
As many of you know, it is often beneficial in terms of performance and energy efficiency to execute certain processing tasks on the GPU instead of the CPU. This is especially the case for image processing tasks. ogles_gpgpu enables fast and portable, GPU-powered processing by using OpenGL ES 2.0 shaders.
Since transferring data to and from the GPU is often a bottleneck for GPU processing, platform-specific fast texture access is also implemented. The library is written in well documented, clear C++ code. An interface for Android systems via JNI is provided. Example applications show how to use this library. All code is LGPL licensed.
There are several scenarios on how to use this library: You can for example pass image data (or arbitrary byte data) to ogles_gpgpu, which creates an OpenGL texture from it. You can then process it on the GPU by applying a series of filters (OpenGL shaders) on it. This kind of rendering happens off-screen. Afterwards, you can lock the result data and obtain a pointer to it. You can then copy this data for future processing or directly analyze or modify it. Another possible scenario is to directly pass an OpenGL texture ID as input for ogles_gpgpu. This is for example beneficial if you can obtain camera frames as OpenGL texture from the camera API of your target platform (both Android and iOS allow this and example projects or provided for this). Now ogles_gpgpu can directly run the filters on this camera frame texture. This can happen off-screen or optionally on-screen, which means that the result image is also displayed to a render surface. After processing on the GPU side, you can access the result data again as described in the first scenario. By this, you can do further CPU-based processing of the result data. This is for example necessary, if certain algorithms can not (efficiently) be implemented as OpenGL shaders.
At current development stage, there are not so many image processing filters implemented, yet, but this is about to change in the future. The most important thing is that a portable architecture for GPU-based processing is available, which allows fast texture access by using platform-specific optimizations.
You can check out the project on github: github.com/internaut/ogles_gpgpu
More information can be found on my personal website: mkonrad.net/projects/ogles_gpgpu.html
Thank you.
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