Related
Current android versions:
CM7.2
Kernel Status:
- Kernel v3.10
- LCD
- Keyboard
- SDHC MMC
- Max1587a
- Asic3 Buttons
- Automatic screen rotation
- Touchscreen
- Bluetooth (audio and mouse tested and working)
- Usb host (supports everything USB 1.1 compliant)
- Backlight
- Adb and Usb mass storage
- M24C08 Eeprom
- Keyboard and button backlights
- RTC8564
- Led's - Red, Green, Blue
- Vibrate
- AC Charging
- USB Charging
- WIFI
- Support for EXT4 filesystems
- Modem
- Phone Support
- Audio Support - no input from mics, routing related.
- Data -3g or GPRS
- Power Management - Standby works which is a low power state, Deep sleep and suspend to mem is not working
- DOC flash chips are supported by kernel for both g3 and g4 devices
Not Working/To-do list::
- Camera's - need to add V4L driver to android and dual cam support for camera app and kernel driver.
- add video/audio decoders/encoders
- add modem sound routing to kernel or android (AT commands )
Link to files: (Link)
Link to Kernel source: (Link)
WOW i'll try it. Thanks
Thanks notime!
Not a Universal owner, but glad to see Android made it's way to this device.
Is there any software that can assist to create the 3 partitions?
is anyone working on getting the touchscreen going? if it had touchscreen working i'd jump on this in a hot second.
Now this is so cool, that somebody is actually developing android 4 our beloved Uni :-D:-D:-D
Hi
For me it's not working.
I wrote it here
Here is my LOG
EDIT: It's working. I had the phone off.
Android version
Hi,
first of all - great work!
Second - this will probably be a seen as a stupid question but why are you trying this with such an old version of Android? Are the new versions requiring so much more memory or something?
Anyhow, good luck with further work and thanks for restoring my hopes of Uni resurrection
asdafer said:
Hi,
first of all - great work!
Second - this will probably be a seen as a stupid question but why are you trying this with such an old version of Android? Are the new versions requiring so much more memory or something?
Anyhow, good luck with further work and thanks for restoring my hopes of Uni resurrection
Click to expand...
Click to collapse
That is a good question..., it was the only one i had on hand at the time. But the kernel i'm using is based off 2.6.32.9 the current android 2.1 eclair is based off 2.6.29 so theoretically that and the newer android version froyo should work. If i find or build a 2.1 rootfs that works i will post it.
id say any android functioning on the uni is a giant step in the right direction. we don't need to get picky lmfao
Hi Notimer,
is there any software which can allow me to partition my SD card?
yes. knoppix and fdisk.
Touchscreen
Does anybody know what this ts_calibrate output means or familar with it?
xres = 480, yres = 640
Took 1 samples...
Top left : X = 65492 Y = 678
Took 1 samples...
Top right : X = 65494 Y = 678
Took 1 samples...
Bot right : X = 65492 Y = 678
Took 2 samples...
Bot left : X = 65493 Y = 678
Took 2 samples...
Center : X = 65493 Y = 678
256.000000 0.002021 0.125000
256.000000 0.002694 0.250000
Calibration constants: 16777216 132 8192 16777216 176 16384 65536
If you don't feel like dealing with a full linux distro or the command line when partitioning, try the G-partd Live CD. It's a great, Partition Magic style GUI for the Linux command line partition tools.
http://gparted.sourceforge.net/livecd.php
it'd be better if we just had a 128mb dd image methinks. simpler and faster lmfao
Updates
I posted a new kernel and updated the working functions list on the first post. I know it might not be the updates some were wanting but....it's a update i thought was worth posting...but still no touch screen.
Has anyone tried or built any other android rootfs or images to test with this kernel or know how to?
Does anyone know of a device running Linux that has a phone chip similar to the one in the universal?
Can you compile a kernel image that mounts loopback image files instead of actual ext2 partitions for those that don't feel like partitioning their SD cards? I think it would encourage many more testers.
im confused here, titchy linux runs just fine on the universal. why is it we dont harvest drivers from that?
The project is abandoned.
As I no longer own a Windows RT device and I'm not willing to use Windows RT anymore, unless Microsoft would make it more open (at least to run your own desktop apps) - I've decided to stop working on this project.
As usual I'm publishing complete sources of this tool. Feel free to use them in your own projects or to continue developing this one - only leave my copyrights somewhere.
Don't ask me how to build the sources or to explain anything in them. Figure that out yourself.
The project is abandoned. Sorry.
I'm presenting a tool that allows running a set of x86 Windows applications on Windows RT (ARM) tablets. Its goal is to support all apps except for those that:
- require much CPU power,
- use complex features that were cut out from WinRT like D3D9 extensions or OpenGL,
- require drivers or specific services,
- make heavy use of COM interfaces,
- use undocumented windows internals,
- apps that use .NET framework,
- x86 Metro apps,
- 16 or 64 bit Windows programs,
- buggy apps that require special workarounds.
The tool is currently on a beta stage, so don't expect much from it. It is far from being complete, but at least it runs something.
Current version: 0.061
Just a minor update. The project is not dead, I just had no time to continue the development.
Attached the fixed ntdll.nt.dll that works under Windows RT 8.1 (Microsoft removed some NTDLL exports, so I had to add more stubs). This fix is not needed on RT 8.0.
To install it: extract the attached 0.061-ntdll.nt.dll.zip to c:\x86node\windows\SystemNT\ overwriting the existing file.
Autostarting x86 programs does not work on RT 8.1 ("can't install CreateProcessInternal hook"). I'll look on this later.
Don't ask on jailbreaking the 8.1 beta in this thread - there is a good progress on it, more info would be on release (in october or when WZOR would leak the RTM).
Current version: 0.06
Seems that archive is too big to be attached, so I've uploaded it to google drive and here
Installation: extract the archive on your unlocked Windows RT device, run the MSI file and follow the instructions.
Note: Uninstall the previous version before installing a new one.
List of compatible apps is in this post: http://forum.xda-developers.com/showthread.php?p=40924456
Trademarks
Windows is a registered trademark of Microsoft Corporation. ReactOS is a registered trademark or a trademark of ReactOS Foundation. All other trademarks are the property of their respective owners.
Disclaimer
This software is provided "as is". Use it on your own risk. I make no warranties as to performance, merchantability, fitness for a particular purpose, or any other warranties whether expressed or implied. No oral or electronic communication with me shall create a warranty of any kind. Under no circumstances should I be liable for direct, indirect, special, incidental, or consequential damages resulting from the use, misuse, or inability to use this software, even if I has been advised of the possibility of such damages.
I'm trying my best to make the software working, but I can't guarantee that it is free from defects.
All beta versions of this tool would be freeware. You may freely use it for your own, embed it into your tool, but you can't use it commercially without my confirmation. You can disassemble, analyze or modify this tool for yourself - later I'll provide SDK and document its internals. The only thing that is prohibited is changing embedded copyright notices. I reserve the right of making the project commercial, but this does not mean that this would ever happen.
This software contains unmodified binaries from the ReactOS project: a registry editor, cmd.exe, ole32.dll to name the few. Those binaries are left unmodified and are covered by LGPL license. Future versions may contain redistributable binaries provided by Microsoft and/or other companies.
Some more information may be found in my blog. If you want to support development - use the link or press the button on the left side of the post.
Changes:
15 may 2013: DInput and DInput8 changes for Fallout2 keyboard compatibility.
12 may 2013: A minor update. Fallout 2 now works, tested on Russian version from 1C.
01 may 2013: Added the ability to automatically launch x86 applications. Added the shell32 interfaces - so that installers now work (at least NSIS and InstallShield installers are known to be working).
05 apr 2013: Fixed a few bugs.
04 apr 2013: Uploaded a new build after a long delay. Now emulator supports 256-color modes. But due to a limitation on an updated Nvidia driver - 640x480 and 800x600 display modes are no longer supported on Windows RT. You'll see the black lines to the right and bottom of the screen if the program tries to set such mode.
25 feb 2013: The tool now outputs its version to log. Now one x86 program may launch another - so some of the installers and, for example, 7Z GUI frontend can now run under emulation. Added ~80 DLLs. Some of them are stubs (like D3D9.DLL), others are mostly untested. I have not done all that I've planned for this build, publishing it just as an update to show that the work is going on. Do not expect it to run much more than the previous build.
13 feb 2013: more informative errors from launcher. Emulator now supports program paths with spaces. EXE files with relocations are now processed correctly. Some bugfixes in kernel32 and advapi32.
11 feb 2013: fixed a typo in winmm.dll emulation, now pinball has sound. Also updated the launcher.
10 feb 2013: now the program reached the beta stage.
Known problems
No D3D and most of COM interfaces. Lots of programs would crash, don't run or have different issues.
Notes:
The program keeps its settings in the HKCU\Software\x86node\Settings registry key. Supported REG_SZ (string) values are:
DosboxCore: "dynamic", "simple" or "normal". Dynamic is the default as it is the fastest, but the most buggy core.
LogFile: path to the log file. If not present - log file is %temp%\win86emu.log
Supported REG_DWORD values:
LogLevel: 0=no log (default), 4=max logging
added 13 feb 2013: now default log level is 2: warnings+errors, so you don't need to edit registry
There are several compatibility hacks that may be useful. Compatibility settings are stored in HKCU\Software\x86node\Compatibility\[filename.exe] key. "filename.exe" - a name of the emulated EXE file without path. All values are DWORD:
SetProcessAffinityMask = bitmask. Specify which CPUs to use for running a program, read SetProcessAffinityMask description in MSDN. 0 or unset == run on all cores.
NoRaiseException = 1. RaiseException would just return. Now exceptions are emulated correctly, so this hack is no longer needed.
UseDirectRegistry = 1. Do not redirect emulated registry keys to HKCU\Software\x86node. Be careful when using it.
MaxProcessorFeaturePresent = max processor feature number that is "supported". See the IsProcessorFeaturePresent function in MSDN. All requests for the value above specified would return 0. Default: 0 (IsProcessorFeaturePresent always returns 0).
SimulateAdminRights = 1. Lie to installers that call OpenSCManager function to determine that it is running as administrator, allowing these programs to run without elevation. Redirect the "common start menu" and similar folders to the per-user folders.
You can fake the OS version to a running program. Default XP SP3:
OSVersionLo=dword:00000001
OSVersionHi=dword:00000005
OSVersionBuild=dword:00000a28
OSServicepackLo=dword:00000000
OSServicepackHi=dword:00000003
Some information on the project internals may appear in my blog: http://mamaich-eng.blogspot.ru, but this thread on XDA would be the main discussion place.
I may be missing something...but this won't run for me. The exe just tells me it can't be run like normal exe does. I am jailbroken and can run arm compiled exe.
That is very impressive, mamaich.
lucas.scott said:
I may be missing something...but this won't run for me. The exe just tells me it can't be run like normal exe does. I am jailbroken and can run arm compiled exe.
Click to expand...
Click to collapse
Reread the directions ?
I don't have an ARM tablet to test this on, but this type of development is what will get me onto an ARM tablet for the next go-round. I love my S7S, but I really hated paying the price.
dan-htc-touch said:
Reread the directions ?
Click to expand...
Click to collapse
ugh...embarassed.
Great work mamaich. Thank you!
Notepad from Windows 95 seems to run too.
wow,this is an awesome project!
Amazing! Thank you!!!!!!!
Would you mind giving a technical explanation?
mamaich said:
I'm presenting a prototype of a tool that allows running Windows programs compiled for a desktop PC (x86) on an unlocked Windows RT (arm) tablet. The tool emulates x86 instructions and passes Windows API calls to WinRT kernel with necessary modifications.
This build is an early alpha version. It can run only very simple apps that use rather small subset of Win32 API that I've already implemented. Archive contains clock.exe from NT4 distribution as an example of such app. As I'll continue work on the project - the list of supported applications would grow up.
This tool would support only 32-bit windows native applications. It would not allow running drivers or .NET apps that were written for old .NET versions nor Win16 or DOS apps. And current version supports emulation only of EXE files that contain relocations section (this would be fixed later).
Instructions:
1. Unlock your device with this tool: http://forum.xda-developers.com/showthread.php?t=2092158
2. Unzip the archive to any directory
3. Run _start_clock.cmd
This would execute the clock.exe from NT4 in the emulation mode.
This post would be updated as I'll make more progress.
Note: This is an early alpha version, and do not expect that it would run anything except the provided file. Do not ask me what programs would be supported and when the next builds would appear - I don't know, as I work on this project only on spare time. I would not publish the complete sources of the tool, but it would be extensible by users, and some plugins (at least bochs/dosbox emulation engines and some of the API wrappers) would be opensource.
"Yact" in the file names stands for "yet another code translator", it was the original name of the project.
Edited 13.01.2012:
- added a few ARM WinAPI workarounds, added calc.exe as a second example (run _start_calc.cmd).
Click to expand...
Click to collapse
heh, is this a port of the app you showed off back in the CE days? -awesome getting that ported over
This is great, really opens up a lot more things and means that we don't need to recompile everything either.
heh, is this a port of the app you showed off back in the CE days? -awesome getting that ported over
Click to expand...
Click to collapse
Not exactly a port, it is a clean remake based on the old ideas.
clrokr said:
Would you mind giving a technical explanation?
Click to expand...
Click to collapse
The idea is very simple:
- a PE file loader (load files, process relocs, run TLS callbacks in an emulation mode). Support import loops (DLL A imports B while B imports A), ordinals, etc.
- a set of wrapper x86 DLLs (kernel32_stub.dll and so on) that "look like" the corresponding Win API functions for an emulated program:
Code:
#define DEFINE_FUNC1(name) \
static const ModuleDef str_##name={DLL_NAME,#name}; \
EXTERN_C DW STUB_EXPORT stub_##name(DW p1) \
{ \
DW *p=&p1; \
__asm { mov eax,p } \
__asm { jmp f1 } \
__asm { mov eax,offset str_##name } \
f1: __asm { in eax,0xe5 } \
__asm { mov p,eax } \
return (DW)p; \
}
.....
#define DEFINE_FUNC3(name) \
static const ModuleDef str_##name={DLL_NAME,#name}; \
EXTERN_C DW STUB_EXPORT stub_##name(DW p1,DW p2,DW p3) \
{ \
DW *p=&p1; \
__asm { mov eax,p } \
__asm { jmp f1 } \
__asm { mov eax,offset str_##name } \
f1: __asm { in eax,0xe5 } \
__asm { mov p,eax } \
return (DW)p; \
}
....
DEFINE_FUNC1(AddAtomA)
DEFINE_FUNC1(AddAtomW)
DEFINE_FUNC7(CreateFileA) -- number in macro == number of parameters to a __stdcall WinAPI function.
Compiler automatically generates "ret N*4" at the end of such function.
I've decided to use such c+asm approach instead of making a tiny assebler stub,
as I can easily implement some of such functions in C directly in a stub DLL plus it
simplifies debugging. And the functions have a usual C prologue/epilogue, so that
the emulated program may even patch them in runtime, for example for hooks.
...
- a 32-bit x86 emulation engine (currently 2 engines: from bochs and from dosbox, planning on adding my own) that intercepts the command "in eax,0xe5", determines which API is needed by a program and passes it to a handler.
- native (arm) API handler DLLs (kernel32_yact.dll and so on). They are mostly autogenerated too:
Code:
#define DEFINE_FUNC1(name) \
EXTERN_C DW STUB_IMPORT name(DW); \ -- this behaves like a function prototype to compiler
EXTERN_C DW STUB_EXPORT yact_##name(DW *R) \ -- R - pointer to the x86 stack
{ \
DW r=name(p1); \ // call the func passing it paramers from the emulated stack, p1==R[0], p2==R[1] and so on
LEAVE(1); \ // empty macro, as the stack is unwinded in x86 stub DLL now
return r; \
}
...
#define DEFINE_FUNC3(name) \
EXTERN_C DW STUB_IMPORT name(DW,DW,DW); \
EXTERN_C DW STUB_EXPORT yact_##name(DW *R) \
{ \
DW r=name(p1,p2,p3); \
LEAVE(3); \
return r; \
}
...
DEFINE_FUNC1(AddAtomA)
DEFINE_FUNC1(AddAtomW)
DEFINE_FUNC7(CreateFileA) // as you see - implementation part is identical to an x86 stub, so I can use the same stub-generator tool
Some of the functions require complex emulation due to their absence in ARM or due to the callbacks to x86 code:
Code:
static DWORD WINAPI ThreadProc(
LPVOID lpParameter // [0] == orig func, [1] == orig param
)
{
__EXCEPTION_REGISTRATION_RECORD R;
DWORD *Parm=(DWORD*)lpParameter;
DWORD *TEB=(DWORD*)PeLdrGetCurrentTeb();
R.Next=(__EXCEPTION_REGISTRATION_RECORD*)-1;
R.Handler=(void*)CbReturnToHost();
TEB[0]=(DWORD)&R; // in case of unhandled exception - just return
PeLdrNotifyNewThread(NULL,DLL_THREAD_ATTACH);
DWORD Ret=EmuExecute(Parm[0],1,Parm[1]); // 1 == number of parameters to the emulated function
delete Parm;
return Ret;
}
EXTERN_C DW STUB_EXPORT yact_CreateThread(DW *R)
{
DWORD* Parm=new DWORD[2];
Parm[0]=p3; // TODO: no out-of-memory checking for now
Parm[1]=p4;
DWORD StackSize=p2;
if(StackSize)
StackSize+=1024*1024; // I reserve some space for my own needs (debugging)
else
StackSize=2*1024*1024; // TODO: I don't support autogrow stacks, so reserve 2 Mb
DWORD t=(DWORD)CreateThread((LPSECURITY_ATTRIBUTES)p1,StackSize,ThreadProc,Parm,p5,(LPDWORD)p6);
LEAVE(6);
return t;
}
Some of the COM interfaces are already implemented, for example DirectDraw and DirectSound, though not heavily debugged. On a desktop emulator build I can already run "Heroes of might and magic 3" and old WinRAR, but there are several RT-specific OS limitations I need to bypass before making them run on ARM. Current work in progress is: overcoming the RT limitations, manually implementing the API functions that callback to a program code (like CreateThread, RegisterClassA and so on), adding stubs for other system DLLs/COM objects.
Manually thrown SEH exceptions are fully supported, but access violation, int3 and similar OS-generated exceptions would cause program to crash. Some of the TEB fields (TLS and the fields required by the Borland compilers) are implemented too.
I don't make pointer translation in an emulated code nor make parameter checks passed to API. As a side-effect - the emulated program may trash the emulator in memory, but this greatly increases speed.
Most of the x86 EXE files don't contain relocations section and need to be loaded on the specific addresses (typically 0x400000). This is not a problem on a desktop, as I can rebase my emulator's EXE to any address I need, and free the corresponding RAM addrs for emulated program, but on ARM - this is a main problem. So currently only EXEs with relocs are supported for emulation, but there are ways to overcome this problem. And some EXEs produced by old Borland compilers contain "broken" relocs, this is a small problem too.
HI mamaich, sorry for disturbing you, may i know how do you compile visual studio project for arm ?, i already change windowsarmdesktop to true. But i can't find arm options in build settings. Any suggestion ?
rheza02 said:
HI mamaich, sorry for disturbing you, may i know how do you compile visual studio project for arm ?, i already change windowsarmdesktop to true. But i can't find arm options in build settings. Any suggestion ?
Click to expand...
Click to collapse
This is completely unrelated to the topic and has been covered in at least 3 threads, multiple times in each, in the past couple days. Use the search function.
netham45 said:
This is completely unrelated to the topic and has been covered in at least 3 threads, multiple times in each, in the past couple days. Use the search function.
Click to expand...
Click to collapse
Yes, and I've answered it here: http://forum.xda-developers.com/showpost.php?p=36644799&postcount=131
Wow, this is awesome work! While recompiling (for native speed, lower memory footprint, launch time, lower battery usage, script transparency, etc.) is still obviously preferred, this finally offers a way to run closed-source or otherwise un-recompilable legacy apps. Well done; I'll be watching this closely.
A thought for making it easier to run the apps (including the aforementioned script transparency): Windows (at least on x86 and x64, and I'm pretty sure on ARM too) supports specifying executable names that, when they would be executed, are instead passed as a parameter to another executable. This is usually used for testing or debugging purposes (for example, always load a given app under a debugger or have Application Verifier hook into it at launch) but it can be used for other purposes too. One, which would be fantastic here, is to always run a program through a compatibility layer... I've never before seen it used for a full instruction set translation compatibility layer, but why not?
Create the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<IMAGE FILE NAME>
i.e. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\starcraft.exe
Then create a REG_SZ (String) value under that key called "Debugger" and set the value to the full path of the program you want to host the executable.
i.e. C:\Program Files\x86_peldr\peldr.exe
Source: http://support.microsoft.com/kb/824344
I can't promise that this will work for executable images that wouldn't be loadable normally, but it's probably worth a shot. Another, slightly less seamless option: change the extension of the executables (for example, starcraft.ex86) and register your app as the handler for that file type.
GoodDayToDie said:
Wow, this is awesome work! While recompiling (for native speed, lower memory footprint, launch time, lower battery usage, script transparency, etc.) is still obviously preferred, this finally offers a way to run closed-source or otherwise un-recompilable legacy apps. Well done; I'll be watching this closely.
A thought for making it easier to run the apps (including the aforementioned script transparency): Windows (at least on x86 and x64, and I'm pretty sure on ARM too) supports specifying executable names that, when they would be executed, are instead passed as a parameter to another executable. This is usually used for testing or debugging purposes (for example, always load a given app under a debugger or have Application Verifier hook into it at launch) but it can be used for other purposes too. One, which would be fantastic here, is to always run a program through a compatibility layer... I've never before seen it used for a full instruction set translation compatibility layer, but why not?
Create the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<IMAGE FILE NAME>
i.e. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\starcraft.exe
Then create a REG_SZ (String) value under that key called "Debugger" and set the value to the full path of the program you want to host the executable.
i.e. C:\Program Files\x86_peldr\peldr.exe
Source: http://support.microsoft.com/kb/824344
I can't promise that this will work for executable images that wouldn't be loadable normally, but it's probably worth a shot. Another, slightly less seamless option: change the extension of the executables (for example, starcraft.ex86) and register your app as the handler for that file type.
Click to expand...
Click to collapse
What I was thinking of for doing that was hooking the 'This doesn't run on this PC' error that explorer gives and making it call this instead of the error.
Nice... but that doesn't cover things like launching a program from the command line (script or manually), or one program launching another, or launching Windows services (although I'm not sure you'd want to emulate those anyhow... the battery hit would suck), or so on. Still an interesting goal.
One other thought for the "it'd-be-awesome" list (not even really a wish-list): support doing this for DLLs loaded into other processes (i.e. somehow get between LoadLibrary and the x86 binary, and interpose your translator). Why, you ask? Plugins. Browser plugins, media codecs (which are DLLs, whatever their extension), Control Panel files, COM objects in general, etc.
TheXSample - SXELROM v2.0 for JXD S7300B
This is a summary of the original article (in Spanish) is in my blog .
For updates on this article, I suggest visiting one of the links above.
_____________________________________________________________________
UPDATES
04/02/2013: Patch_Xsample_2.1.rar
Mirror Mega
Change log:
Tincore KeyMapper
AutoProfiles. By enabling this option, the KeyMapper automatically load profiles, depending on the application that is running in the foreground.
AXIS Investment Selection
Dialogos selection list of options
Elimination of unnecessary controls
UI Enhancements (simpler interface)
Better integration Holo
Scalable Icons
Component Selection pressing physical controls
Renaming profiles
Exporting profiles *
Importing profiles *
* With these options opens the possibility to share applications among users profiles.
Driver Tincore
Acceleration of the driver
Investment AXES
Accelerometer support *
Fixed some bugs
Support for specific calibration D-PAD **
Added hot-key [VOL-] & [L2] to reset current profile ***
* Now you can assign horizontal or vertical tilt to one of the axes of the sticks. With this option, you can play many N64 or PSX titles (preferably on emulators that support analog), and the inclination to use the console to control the action in games. Example: Mario Kart 64 may play a "Wiimote Style" or Forsaken, can be controlled by tilting the tablet.
The D-PAD ** console, as already explained is analog, but which behaves as digital.
There is a problem with the D-PAD and their center (neutral position) is shifted to the right, so the analog calibration can influence the response of the D-PAD, for example, that in some games and emulators respond correctly to one side, usually to the left.
To avoid this, in games / emulators that specifically use a d-pad instead of analog, recalibrate the driver is suggested to use the D-pad as the main entrance. To do this, simply open the tool and select "Calibrate" in the Stick 0, and use the D-PAD to calibrate the device.
Note: The calibration is stored in the profile of the game, so it will not affect other profiles created with KeyMapper.
*** This combo is useful if you experiment problems or get stucked with your current keymapper layout. You can use in any time to reset profile to <RESET TO DEFAULT> values.
Requirements
Having installed the rom-SXELROM TheXSample v2.0 before installing this patch.
Instructions
Unzip the zip in the root of the microSD
Start the console with [Vol +] and [POWER] and select "Apply upadte from EXT".
Select the patch you want to apply:
- Patch1200
- Patch1320
- Patch1500
App is installed in the data, that is, as user application, and eliminates the above.
_____________________________________________________________________
List of changes
Here is a short list of changes included in this version of firmware.
Later in this article, there is a section with extended information about these changes.
Firmware
New kernel changes allowing more CPU settings and more conservative values ??(donation version includes SetCPU)
This includes new governors set for the console hardware
Minor changes in memory management.
NTFS writing enabled.
Speed ??1.2GHz default rom
All changes to the stock rom v1.7, as the inclusion of the new Full Screen option
Tincore Driver
Support for multi-directional swipes.
All controls can be swipe-type (Support up to 20 swipes configured simultaneously)
Establishment of standard joystick driver for the device. It works and is recognized by the system as analog joystick 4 axes and 16 buttons
Improvements and optimizations in the driver code, to get even less lag.
New algorithm for pointer modes sensitivities
Support for remapping keys
http://www.youtube.com/watch?v=MlJxrGBvews
(Dead Trigger mode driver with Joystick)
http://www.youtube.com/watch?v=xRRowLsgyGw
(Temple Run using the full interface with console controls)
Tincore KeyMapper
Changes and improvements in the user interface of the tool
Improved display rotation tool wing pair.
Self adjusting menus always leave visible objects / widgets on screen
Defining swipes using drag & drop, to start and end points
Simplification in the definition of areas for pointer modes
Highlighting groups of objects / widgets
Calibration Sticks in two modes: Auto and Manual
Basic implementation for remapping controls for mode "Key"
http://www.youtube.com/watch?v=hj-ZNQWQoQw
(Modern Combat 4 Touch mode, with Swipes activated to switch weapons)
http://www.youtube.com/watch?v=uvM8mgOl0aU
(Nova 3 Touch mode, with Swipes activated to switch weapons. You can see that there are no breaks in the 360 ??º turns, and changing weapon swipe too fast)
Download Links
TheXSample - SXELROM v2.0
Rom - Google Docs Mirror (GDrive)
Patch speeds and Swap
Patch - Mega Mirror
Patch - Mediafire Mirror
Thanks
Many people involved directly and indirectly in the development of this Rom: Christian Troy, fun_, Lomax, fuser-invent, Tincore, Namco69, Yoshi41, Skelton, Deen0X and who stay to name.
Special mention of Durruti, inspiration especially for TheXSample and Tincore
I hope this rom will please and utility of those who wish to try.
=============================== Older Versions ===============================
TheXSample - SXELROM v1.0 para JXD S7300B
Usage of this article
Usage of this article is alowed by copy or link reference to anyone with the only condition of keeping original author and a reference to the original source of this review. The mentioned reference is the following:
Source and Updates of the info from this article.
Original (in Spanish) is in my blog.
For updates I suggest to visit any of the mentioned links.
About this article
This article is a summarized version and only contains the most relevant features..
To read the full article check the previous link
Features
http://www.youtube.com/watch?v=Zz_YYYRiCz4
(SXELROM beta, showing some features)
Only features present
at the time of the writing of this review are listed.
(Separate external and internal mount points)
Based on Skelrom v1.0 for JXDS7300B, private 1.4stock firmware sources and JXD 1.5. Includes all Skelrom and last official firmware fixes.
Clean code. Official sources only. No alien code.
New mount points. Now internal and external mount points are at the same level in the filesystem and not one inside the other. Swap is easier.
Deep sleep improvements. WiFi disable when sleep saves a lot of battery.
New Kernel features by Skelton andTincore (check Kernel chapter)
New specific governors tailored to device hardware. Specially new "ondemand" scores more than 10000 Antutu points with console processor running at 1.3GHz (No cpu stress needed)
New "ondemand" governor allows cooler execution.
50Hz to 60Hz screen fix, The same that we suggested JXD to incorporate in his 1.5 firmware (Check screen refresh note)
New Tincore input kernel driver. It provides lower input lag and lots of extra configuration options to support new sticks and buttons operation modes.
"Tincore Keymapper", UI Mapping tool to configure specific input kernel driver options (check Tincore Keymapper chapter)
About new Kernel
This firmware's kernel has been created using JXD 1.4 sources. Those sources, whith some small chanes, have been released as JXD 1.5 firmware.
(new governors added)
More important kernel feautres:
Chanes in CPU and voltage to improve temperature and stability.
Support CIFS/NFS for seamless net shares filesystem mount.
I/O schedulers and NAND optimizations. Improve read/write operations and memory access.
Mali driver optimizations to speed up 2D and increase graphical memory cache buffer.
(Antutu Benchmark result with new firmware improvements, governor “ondemand” and 1.32GHz. Reaching 10000 points which is a bit better than 1.5GHz with performance governor)
About new input kernel driver: Tincore Driver
Tincore provided a new kernel driver to improve latency and support many missing features in original drivers.
(Keymapper, with new features like pointer mode)
Driver improves response times because it is more optimal and faster than the original. This reduces input lag
New driver enables key events for all sticks when mapping tool is disabled, This allows to use right stick as a key pressing digital stick. Because of this it can be used by emulators and games that can be controlled with keyboard.
http://www.youtube.com/watch?v=BPntj4ojtq4
(Showing some of the new features of the Tincore's Driver)
Keymapper tool features
(Keymapper using original JXD driver)
The new mapping tool supports both JXD driver and, naturally, the new Tincore driver.
The tool supports multiple stick modes (split/combined/pointer...) and allows to define where is the screen pressed when a button or stick is operated.
The tool supports profile save and restore and portrait mode.
Because of its backwards compatibility the tool by itself is a good replacement for the JXD mapping tool. Ley profile support is already a great addition.
Download links
TheXSample - SXELROM v1.0
Rom - Mirror Mega
Patches
The patch includes a file folder with different kernels at different speeds (1200, 1320 or 1500 MHz) as well as the possibility of exchanging the SWAP and the external memory and return to conventional partition system JXD. Within each folder is how to install and that is what.
Patch - Mirror Mega
For more updates check original article.
How to install:
Download the file and extract the contents of "TheXSample-SXelrom v1.0 for JXD s7300B.rar" to your sdcard root
With the deviced tunerd off, insert the microsd with the files, press and keep pressed the button [VOL+] and, without releasing, turn on your device with [POWER] button
Keep [VOL+] pressed until you see an android image with a progress bar. The firmware will be installed automatically and at the end of the process the device will reboot.
Your device is updated!
Thanks to:
This firmware has been possible thanks to the work of several persons. All valuable contributions have been in the form of coding, suggestions, testing...
Thanks go to Tincore, Skelton, Christian Troy, fun_, fuser-invent, LomaX, Namco69, Yoshi41, Deen0X and more.
Also thanks to web shops Willgoo y Zococity that provided testing devices that allowed tetst and feedback for the team.
(Because I have more than one console, I was able to perform a series of tests in parallel to obtain useful information that was used in the development of some of the features of the firmware)
I also want to give special thanks to the couples (wives, etc) several of whom have been working on this project, that it takes patience and an understanding that we do this because we love, and we want to share it with more people.
I hope this project is the starting point for more projects of the same type, which are extremely rich in both technical knowledge in general, but especially on a personal level, because in my case I meet interesting people, who always is rewarding and I hope to keep in touch. ^_^
Zalu2!
Deen0X / TheXSample
Update, check the first post...
Update, check the first post...
Although a newbie to Kernel hacking I have built a custom Android build for a FriendlyArm Nano PC T3 Plus and it's very reliable. I've modified the kernel to add additional serial ports etc so I know a little bit of my way around it but this is the first time with adding a new driver.
The issue I have is in not seeing the events from the touchscreen within the driver. I've used the source from this git repository, which seems to be pretty similar to others of the same type.
https://git.sphere.ly/varun.chitre1...e1/drivers/input/touchscreen/doubletap2wake.c
Now, I do have something working in regards to the fact that during boot I see the following in the console debug output so I know the code compiled and is being initialised.
[ 3.220000] input: dt2w_pwrkey as /devices/virtual/input/input3
[ 3.224000] [doubletap2wake]: doubletap2wake_init done
I can also see touch events from cat /sys/input/event1 when the display is off so I know that they are not disabled when the screen is off. I've enabled the debug output from the doubletap2wake code but nothing appears in the debug output so I suspect that I am missing some hook or have an incorrect driver registration somewhere.
Any clues what I might be missing? I have trawled as many github repositories trying to find what I am missing but every one is pretty much the same.
I managed to get the touch detection to work and it was the fact that I had not registered the correct driver in this function. Might be handy for anyone else working on this.
static int input_dev_filter(struct input_dev *dev) {
if (strstr(dev->name, "touch") ||
strstr(dev->name, "himax_ts")) {
return 0;
} else {
return 1;
}
}
It still doesn't work but I know why. I now need to find the code that is called when the display suspends and resumes and input the code to enable the doubletap2wake driver, so I now need to trawl through all of the video drivers to find the right one.
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