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
Related
The Kernel Source Saga
aka
How Samsung Is Continuing to Violate the GPL
As you are all aware, there are still no custom kernels or any functioning custom recoveries for this fine (despite its flaws) device - the Samsung Galaxy Indulge (specifically, the SCH-R910). We'd love to be able to say that's not the case, but it is - and will continue to be, for as long as the issues outlined below continue. Samsung has left us not just in the lurch, but completely screwed - whether it is simple incompetence, disregard for the prepaid device community, interference by MetroPCS, or flat-out malice, the outcome is the same.
The Symptoms
The problem here is not that Samsung has not published some sort of source package. They have done at least that - enough to keep most observers happy. However, this package was broken from the start. The first package that Samsung published for the R910 included a badly-broken netfilter, which stumped our kernel experts for a good while before the decision was made to simply substitute the three pieces of netfilter from another device.
Doing this allowed our kernel developers (and myself) to compile a kernel, linked with a clean initramfs extracted from the stock kernel. In a properly-released source package, this should be enough - but it wasn't. These kernel attempts would appear to boot, but about 10-15s after completion of the boot animation, would die completely. The LTE and CDMA baseband versions, in About Phone, would display as Unknown, if one could get there quickly enough.
Three of the top Epic kernel developers, myself, and a long-time Android veteran analyzed kmsg logs (see below) and other factors, and determined that it was impossible to generate what is in the stock binary blob from the source package published by Samsung.
Warning: technical details! The following IRC log summarizes the issue:
[10:29] <@k0nane> The kernel now builds successfully - no more errors in netfilter, out of the box - but with the stock initramfs, it will exhibit the same behavior as previous builds. After boot, it will shut down within 10-15s. If there is time to get to About Phone, it will show the baseband versions as CDMA: unknown and LTE: unknown.
[10:30] <@k0nane> The modules that are built, which is not the complete set as in the stock initramfs, are /significantly/ larger than the stock copies and cannot be put in a kernel build as even with LZMA compression it will be far too large to fit in bml8.
[10:31] <@k0nane> So as before, if the solution is to use the (again, incomplete) newly-compiled modules, it's no solution at all. Thus there is still no way to build a kernel identical to the stock build.
[see logs below]
[10:36] <@k0nane> Expert analysis caught one of the anomalies:
[10:36] <@k0nane> <@Decad3nce> DRockstar: <4>[ 6.042947] [MULTIPDP][poll_thread] dpram_open failed!!
[10:36] <@k0nane> <@Decad3nce> probe never goes through
[10:36] <@k0nane> <@Decad3nce> and you fails
[10:36] <@k0nane> <@Decad3nce> :x
[10:36] <@k0nane> <@Decad3nce> what should happen (from start)
[10:36] <@k0nane> <@Decad3nce> <4>[ 6.275749] [MULTIPDP] dpram_open successd !!!!
[10:36] <@k0nane> <@Decad3nce> <3>[ 6.275770] [IDPRAM] <dpram_tty_ioctl:1718> IOCTL cmd = 0x5405
[10:36] <@k0nane> <@Decad3nce> <3>[ 6.280198] [IDPRAM] <dpram_tty_ioctl:1718> IOCTL cmd = 0x540
[10:36] <@k0nane> <@Decad3nce> which triggers phone active
[10:36] <@k0nane> <@Decad3nce> <3>[ 6.757528] [IDPRAM] <phone_active_irq_handler:2195> PHONE_ACTIVE level: LOW , phone_sync: 0
[10:36] <@k0nane> <@Decad3nce> then you have your power on, etc
[10:36] <@k0nane> <@Decad3nce> 3>[ 9.870551] [IDPRAM] dpram_phone_power_on() ...
[10:36] <@k0nane> <@Decad3nce> <3>[ 10.450069] [IDPRAM] <phone_active_irq_handler:2195> PHONE_ACTIVE level: LOW , phone_sync: 0
[10:36] <@k0nane> <@Decad3nce> <3>[ 10.457065] [IDPRAM] <phone_active_irq_handler:2195> PHONE_ACTIVE level: HIGH, phone_sync: 0
[10:36] <@k0nane> <@Decad3nce> also, not sure what this is
[10:36] <@k0nane> <@Decad3nce> <4>[ 6.042931] [MULTIPDP]filp_open() failed~!: -6
[10:36] <@k0nane> <@Decad3nce> doesn't occur in your goodlog
[10:36] <@k0nane> <@DRockstar> hmm, what could prevent the probe?
[10:36] <@k0nane> <@Decad3nce> the dpram_open failing
[10:37] <@k0nane> And to summarize that, "so from boot, goes through kernel init, then device init, then when it gets to the radio interface layer.. it dies a horrible death because of no access to dpram0"
[10:37] <@k0nane> The details should be unimportant, however, if what's provided is identical to/can produce stock (which, as we see, it cannot).
[10:39] <@k0nane> http://k0nane.info/size.png <== a comparison of stock (left) vs. compiled (right) module sizes
Click to expand...
Click to collapse
Logs: Bad Boot #1 Bad Boot #2 Clean Boot
Source and initramfs as of these logs: Github
What Has Samsung Done?
I have been in contact with SamsungJohn (John Imah), Samsung's official developer representative on Twitter. On first notification of the issue, no action had been taken, and it took an RT campaign to catch Mr. Imah's eye. Approximately one week later, Mr. Imah joined me in IRC, and took note of the information above. Shortly after that, Samsung released a new source package on opensource.samsung.com. That was great - except that the only difference was an end to the out-of-the-box compile errors. Everything else about this source package was identical. The results were the same.
Within the next business day, Mr. Imah requested that I send the information to his corporate email address, as he had an "HQ team" there with him. Unfortunately, that was June 22. Mr. Imah has not responded to tweets or DMs since then, and we have been given absolutely no indication that any work has been done on this issue. The source package has not been updated again.
I have given Samsung ample notification and time to work with myself and my fellow developers to resolve this issue without a public expose. They have failed to so much as maintain the appearance of progress, let alone make any. It was, is, time for the saga to end. Samsung is hereby on notice. They, by failing to provide the source necessary to generate what is included in the stock kernel binary, are violating the General Public License.
http://www.gnu.org/copyleft/gpl.html said:
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
- a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
- b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
- c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.
- d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.
- e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.
Click to expand...
Click to collapse
How Can You Help?
Tweet, email, and otherwise contact every public-facing Samsung representative.
Tell your friends. Have them do the same.
Send a copy of this report to [email protected] - the source in question is the Linux kernel, which is owned by the Free Software Foundation.
Just spread the word - until Samsung feels the heat from this (feel free to contact their legal department!) we will not see results. Development for the Indulge will continue to be held back. Only the users will suffer.
--
Follow me on Twitter @k0nane/@publik0.
x-posted from AndroidForums.
for anyone that thinks this isnt worthwhile, imagine if your device had no source.. where would your kernels be? imagine if this became the trend, to give out crap source
shabbypenguin said:
for anyone that thinks this isnt worthwhile, imagine if your device had no source.. where would your kernels be? imagine if this became the trend, to give out crap source
Click to expand...
Click to collapse
And on top of that, I have every reason to believe - though IANAL - their behavior is illegal.
RT the thread.
I blew this up over on samsungs facebook page.. someone got pissed and deleted my post..
http://www.facebook.com/SamsungMobileUSA
I started to 'comment' on a bunch of their stuff w/ a link to this thread..
I might get my account suspended BWAHAHAHAHA..
bastards
Let's call out @samsungjohn on twitter!
Sent from my Epic™ 4G using XDA Premium app
This is the vary reason i will NEVER BUY any thing sumsuck ever makes, EVER AGAIN!
I have a suspicion that what's going on here is actually just a (possibly long-standing) bug. However, the situation is a bit strange all around.
To be specific, I suspect it's a race condition that happens to be triggered by your kernel build, but not Samsung's. This could easily be due to nothing more than using a different compiler, i.e., one that produces more efficient code.
I notice that in "Bad Boot #1" and "Bad Boot #2", the "[MULTIPDP][poll_thread] dpram_open failed!!" message is preceeded by "[MULTIPDP]filp_open() failed~!: -6". Looking at multipdp.c, dpram_open is failing to open "/dev/dpram1" and returning ENXIO ("No such device or address"), indicating that /dev/dpram1 doesn't exist yet.
Now, there's only two references to "/dev/dpram1" in the entire stock kernel image. The first is the line in multipdp.c that it's failing on. The second is in initramfs's /sbin/init. Here, Android's init actually contains a simplified implementation of udev to handle kernel uevents. That is, it's responsible for dynamically creating device nodes as kernel drivers are loaded, one of which is /dev/dpram1.
What I think is happening is this:
init.rc insmods dpram.ko
dpram.ko registers the dpram tty devices, issuing an add uevent message for device 252:2.
... (some time elapses) ...
init processes the uevent message, creates /dev/dpram1.
Meanwhile:
init.rc insmods multipdp.ko
multipdp.ko creates the poll_thread kernel thread.
poll_tread calls dpram_open.
dpram_open attempts to open /dev/dpram1, which might not exist yet.
Probably what's happening is that Samsung's kernel "takes long enough" to get to the "insmod multipdp.ko" part of init.rc that init has time to process the dpram.ko uevents and create /dev/dpram1, so that by the time dpram_open is called, the device node exists. However, your kernel is "fast enough" that init.rc gets to "insmod multipdp.ko", creates the new kernel thread and executes it, before init has caught up on device node creation. Thus, /dev/dpram1 doesn't exist and everything goes to ****.
Now here is where it gets bizarre. If we compare against the Epic's EC05 init.rc, there's an interesting stanza prior to module initialization that's missing here:
Code:
#samsung dpram modules
mknod 0666 /dev/dpram0 c 255 1
mknod 0666 /dev/dpram1 c 255 2
mknod 0666 /dev/dpramerr c 255 0
mknod 0666 /dev/ttyCDMA0 c 240 1
Presumably this is supposed to create the missing device nodes before insmoding both dpram.ko and multipdp.ko, eliminating the race condition. However, mknod is a command not supported by init, there's no mknod program in the initramfs, and those are the wrong device numbers. Perhaps it's an acknowledgment that the race condition exists on both devices, even though nothing is actually done on the Epic to avoid it? It's just, ... strange.
Unfortunately I can't think of a great solution. One option would be to modify multipdp.c to add a sleep loop around "filp_open(DPRAM_DEVNAME, ...)" to wait for the device to be created. However, that would mean using your own compile of multipdp.ko instead of the one Samsung provides, which could open a different can of worms.
A second option is to move "insmod /lib/modules/multipdp.ko" until after mounting /system, hoping that init would've caught up by then. This can even be insured by running a script that checks for the device node and sleeps if it doesn't exist yet. Something like:
Code:
#!/system/bin/sh
for i in 1 2 3 4 5; do
ls /dev/dpram1 && break
sleep 1
done
and call it from init.rc, after mounting /system, with:
Code:
exec /system/etc/wait_for_dpram1.sh
Anyways, even if this particular issue turns out not to be the culprit, I wouldn't be too quick to conclude that Samsung must've released bad/wrong/old source code. In general, building code with a different compiler, or even a different compiler version, can shake out unfortunate bugs like this. I really hate to ruin any good-will between Samsung and the community by making inflammatory acusations when, frankly, they're probably just as puzzled as we are over this.
Best of luck!
mkasick said:
I have a suspicion that what's going on here is actually just a (possibly long-standing) bug. However, the situation is a bit strange all around.
To be specific, I suspect it's a race condition that happens to be triggered by your kernel build, but not Samsung's. This could easily be due to nothing more than using a different compiler, i.e., one that produces more efficient code.
I notice that in "Bad Boot #1" and "Bad Boot #2", the "[MULTIPDP][poll_thread] dpram_open failed!!" message is preceeded by "[MULTIPDP]filp_open() failed~!: -6". Looking at multipdp.c, dpram_open is failing to open "/dev/dpram1" and returning ENXIO ("No such device or address"), indicating that /dev/dpram1 doesn't exist yet.
Now, there's only two references to "/dev/dpram1" in the entire stock kernel image. The first is the line in multipdp.c that it's failing on. The second is in initramfs's /sbin/init. Here, Android's init actually contains a simplified implementation of udev to handle kernel uevents. That is, it's responsible for dynamically creating device nodes as kernel drivers are loaded, one of which is /dev/dpram1.
What I think is happening is this:
init.rc insmods dpram.ko
dpram.ko registers the dpram tty devices, issuing an add uevent message for device 252:2.
... (some time elapses) ...
init processes the uevent message, creates /dev/dpram1.
Meanwhile:
init.rc insmods multipdp.ko
multipdp.ko creates the poll_thread kernel thread.
poll_tread calls dpram_open.
dpram_open attempts to open /dev/dpram1, which might not exist yet.
Probably what's happening is that Samsung's kernel "takes long enough" to get to the "insmod multipdp.ko" part of init.rc that init has time to process the dpram.ko uevents and create /dev/dpram1, so that by the time dpram_open is called, the device node exists. However, your kernel is "fast enough" that init.rc gets to "insmod multipdp.ko", creates the new kernel thread and executes it, before init has caught up on device node creation. Thus, /dev/dpram1 doesn't exist and everything goes to ****.
Now here is where it gets bizarre. If we compare against the Epic's EC05 init.rc, there's an interesting stanza prior to module initialization that's missing here:
Code:
#samsung dpram modules
mknod 0666 /dev/dpram0 c 255 1
mknod 0666 /dev/dpram1 c 255 2
mknod 0666 /dev/dpramerr c 255 0
mknod 0666 /dev/ttyCDMA0 c 240 1
Presumably this is supposed to create the missing device nodes before insmoding both dpram.ko and multipdp.ko, eliminating the race condition. However, mknod is a command not supported by init, there's no mknod program in the initramfs, and those are the wrong device numbers. Perhaps it's an acknowledgment that the race condition exists on both devices, even though nothing is actually done on the Epic to avoid it? It's just, ... strange.
Unfortunately I can't think of a great solution. One option would be to modify multipdp.c to add a sleep loop around "filp_open(DPRAM_DEVNAME, ...)" to wait for the device to be created. However, that would mean using your own compile of multipdp.ko instead of the one Samsung provides, which could open a different can of worms.
A second option is to move "insmod /lib/modules/multipdp.ko" until after mounting /system, hoping that init would've caught up by then. This can even be insured by running a script that checks for the device node and sleeps if it doesn't exist yet. Something like:
Code:
#!/system/bin/sh
for i in 1 2 3 4 5; do
ls /dev/dpram1 && break
sleep 1
done
and call it from init.rc, after mounting /system, with:
Code:
exec /system/etc/wait_for_dpram1.sh
Anyways, even if this particular issue turns out not to be the culprit, I wouldn't be too quick to conclude that Samsung must've released bad/wrong/old source code. In general, building code with a different compiler, or even a different compiler version, can shake out unfortunate bugs like this. I really hate to ruin any good-will between Samsung and the community by making inflammatory acusations when, frankly, they're probably just as puzzled as we are over this.
Best of luck!
Click to expand...
Click to collapse
.....and why are you not a recognized developer? You deserve it more than me.
mkasick, thanks for the reply, we will look into this. EDIT: Keep in mind that we are using the same toolchain as Samsung, specifically CodeSourcery 2009q3.
mkasick said:
I have a suspicion that what's going on here is actually just a (possibly long-standing) bug. However, the situation is a bit strange all around.
To be specific, I suspect it's a race condition that happens to be triggered by your kernel build, but not Samsung's. This could easily be due to nothing more than using a different compiler, i.e., one that produces more efficient code.
I notice that in "Bad Boot #1" and "Bad Boot #2", the "[MULTIPDP][poll_thread] dpram_open failed!!" message is preceeded by "[MULTIPDP]filp_open() failed~!: -6". Looking at multipdp.c, dpram_open is failing to open "/dev/dpram1" and returning ENXIO ("No such device or address"), indicating that /dev/dpram1 doesn't exist yet.
Now, there's only two references to "/dev/dpram1" in the entire stock kernel image. The first is the line in multipdp.c that it's failing on. The second is in initramfs's /sbin/init. Here, Android's init actually contains a simplified implementation of udev to handle kernel uevents. That is, it's responsible for dynamically creating device nodes as kernel drivers are loaded, one of which is /dev/dpram1.
What I think is happening is this:
init.rc insmods dpram.ko
dpram.ko registers the dpram tty devices, issuing an add uevent message for device 252:2.
... (some time elapses) ...
init processes the uevent message, creates /dev/dpram1.
Meanwhile:
init.rc insmods multipdp.ko
multipdp.ko creates the poll_thread kernel thread.
poll_tread calls dpram_open.
dpram_open attempts to open /dev/dpram1, which might not exist yet.
Probably what's happening is that Samsung's kernel "takes long enough" to get to the "insmod multipdp.ko" part of init.rc that init has time to process the dpram.ko uevents and create /dev/dpram1, so that by the time dpram_open is called, the device node exists. However, your kernel is "fast enough" that init.rc gets to "insmod multipdp.ko", creates the new kernel thread and executes it, before init has caught up on device node creation. Thus, /dev/dpram1 doesn't exist and everything goes to ****.
Now here is where it gets bizarre. If we compare against the Epic's EC05 init.rc, there's an interesting stanza prior to module initialization that's missing here:
Code:
#samsung dpram modules
mknod 0666 /dev/dpram0 c 255 1
mknod 0666 /dev/dpram1 c 255 2
mknod 0666 /dev/dpramerr c 255 0
mknod 0666 /dev/ttyCDMA0 c 240 1
Presumably this is supposed to create the missing device nodes before insmoding both dpram.ko and multipdp.ko, eliminating the race condition. However, mknod is a command not supported by init, there's no mknod program in the initramfs, and those are the wrong device numbers. Perhaps it's an acknowledgment that the race condition exists on both devices, even though nothing is actually done on the Epic to avoid it? It's just, ... strange.
Unfortunately I can't think of a great solution. One option would be to modify multipdp.c to add a sleep loop around "filp_open(DPRAM_DEVNAME, ...)" to wait for the device to be created. However, that would mean using your own compile of multipdp.ko instead of the one Samsung provides, which could open a different can of worms.
A second option is to move "insmod /lib/modules/multipdp.ko" until after mounting /system, hoping that init would've caught up by then. This can even be insured by running a script that checks for the device node and sleeps if it doesn't exist yet. Something like:
Code:
#!/system/bin/sh
for i in 1 2 3 4 5; do
ls /dev/dpram1 && break
sleep 1
done
and call it from init.rc, after mounting /system, with:
Code:
exec /system/etc/wait_for_dpram1.sh
Anyways, even if this particular issue turns out not to be the culprit, I wouldn't be too quick to conclude that Samsung must've released bad/wrong/old source code. In general, building code with a different compiler, or even a different compiler version, can shake out unfortunate bugs like this. I really hate to ruin any good-will between Samsung and the community by making inflammatory acusations when, frankly, they're probably just as puzzled as we are over this.
Best of luck!
Click to expand...
Click to collapse
You weed out toolchain, source, and what you have left is a defconfig that probably has more debugging active than the one that's shipped with the source.
No other way to explain size differential.
EDIT: Also, holy awesome on that analysis.
mkasick said:
One option would be to modify multipdp.c to add a sleep loop around "filp_open(DPRAM_DEVNAME, ...)" to wait for the device to be created.
Click to expand...
Click to collapse
Attached is a patch that should implement this. I've also attached a build of the kernel with it applied--given that we might be looking at funny race condition issues, it's probably worth seeing if the build environment has as much of an effect here.
Mind you, I don't have an Indulge and was unable to test. No idea if this actually works, but hopefully it's progress.
Now, if it does work, it's worth running a dmesg and looking for a "/dev/dpram1 does not exist yet, sleeping." just prior to "dpram_open successd !!!!". If that message isn't there, then it wasn't strictly the patch that contributed to a successful kernel, rather it's probably an artifact of the build.
Full disclosure:
The kernel sources are from SCH-R910_OpenSource.zip posted the Samsung open source page. The initramfs was extracted from this Odin repackage of the stock kernel, linked to from androidforums, although in retrospect I probably should've pulled it from k0nane's GitHub. It was compiled with CodeSourcery G++ Lite 2010q1-188 (EABI) on a Debian sid machine last updated sometime two weeks ago.
In additon to the aforementioned patch (indulge_multipdp_wait_for_dpram1.diff), I used another patch (indulge_no_ifdef_linux.diff) to get rid of the single "#ifdef linux" that trips up the eabi compiler and shouldn't be necessary with the gnueabi one. Otherwise, the only other source changes I made were to the CROSS_COMPILE variable in Kernel/Makefile and CONFIG_INITRAMFS_SOURCE in Kernel/arch/arm/configs/forte_01_defconfig to set the appropiate paths for those two.
I build the kernel once with the original initramfs, copied the newly-built modules/samsung/multipdp/multipdp.ko over the existing one in the initramfs, and rebuilt the kernel to link in the updated initramfs. That should be it.
k0nane said:
Keep in mind that we are using the same toolchain as Samsung, specifically CodeSourcery 2009q3.
Click to expand...
Click to collapse
Yes you're right.
I know that for the Epic's DI18 Samsung used what looked to be an in-house build of GCC 4.3.1 for the stock kernel even though they were recommending CodeSourcery in the source README. Apparently they switched to 2009q3-67 for Froyo and I never noticed.
Decad3nce said:
You weed out toolchain, source, and what you have left is a defconfig that probably has more debugging active than the one that's shipped with the source.
No other way to explain size differential.
Click to expand...
Click to collapse
The defconfig on my Github is identical to that of the package on opensource.samsung.com with the exception of LZMA compression being enabled and a path to the initramfs files being set.
mkasick said:
Attached is a patch that should implement this. I've also attached a build of the kernel with it applied--given that we might be looking at funny race condition issues, it's probably worth seeing if the build environment has as much of an effect here.
Click to expand...
Click to collapse
I'll pass this on to an Indulge user, or test it myself if I find a working microUSB cable first. Thanks. EDIT: No such luck! Died within 15s like most kernel builds do. Unfortunate. I can have the user acquire a log, but I am 95% certain no new info will be presented.
k0nane said:
Died within 15s like most kernel builds do.
Click to expand...
Click to collapse
Crud.
k0nane said:
I can have the user acquire a log, but I am 95% certain no new info will be presented.
Click to expand...
Click to collapse
I'd be curious if it contains any more statements about dpram_open, suggesting whether or not that patch had any effect. Or the built multipdp.ko even works.
Either way, if the device is automatically rebooting after 15 seconds, it's either hitting a kernel panic or something funny is going on with the watchdog. If we could get console output with a UART jig that would likely be helpful.
Can (stock) recovery be booted with a source-compiled kernel and survive for some length of time?
mkasick said:
I'd be curious if it contains any more statements about dpram_open, suggesting whether or not that patch had any effect. Or the built multipdp.ko even works.
Click to expand...
Click to collapse
I will acquire a log ASAP. A new copy of that kernel with adbd flipped to root on boot would be useful, as it's difficult to capture a full kmsg without it - I can generate it via your patch, or if you wish to substitute in the initramfs from my github, that's an option as well.
mkasick said:
Either way, if the device is automatically rebooting after 15 seconds, it's either hitting a kernel panic or something funny is going on with the watchdog. If we could get console output with a UART jig that would likely be helpful.
Click to expand...
Click to collapse
And unfortunately, building one is a bit beyond my skill level. I'd be willing to buy one. The jig should work for the Indulge, given it is essentially a Galaxy S device. I agree that it's most likely panicking - it would be helpful if there were some kind of output to the display as there is with Epic kernel panics.
mkasick said:
Can (stock) recovery be booted with a source-compiled kernel and survive for some length of time?
Click to expand...
Click to collapse
That has not yet been tested. There's a /system/bin/recovery and a recovery partition; as with the Epic and other devices, the partition should be triggered by the button combination on boot. I'll have a user flash a built kernel to bml9.
k0nane said:
or if you wish to substitute in the initramfs from my github, that's an option as well.
Click to expand...
Click to collapse
Attached is a build with your github initramfs.
k0nane said:
And unfortunately, building one is a bit beyond my skill level. I'd be willing to buy one. The jig should work for the Indulge, given it is essentially a Galaxy S device.
Click to expand...
Click to collapse
I have to read through that thread again, but I believe the simple version of the JIG is a 3.3v USB-to-serial converter along with a single resistor to activate the UART. I have some FT232 converters lying around, but they're 5v.
I'll order some parts and see if I can build one for myself in a week or so, as it would be useful for Epic debugging. If it works, we can work something out to get one sent your way.
k0nane said:
That has not yet been tested. There's a /system/bin/recovery and a recovery partition; as with the Epic and other devices, the partition should be triggered by the button combination on boot.
Click to expand...
Click to collapse
I'm thinking ~15 seconds is a somewhat strange time to die during boot. If recovery (with adb) runs stable, then the kernel works in a minimal environment. Perhaps some narrowing down of the boot sequence can be done from there?
Sorry to derail this but I'm cross posting here..
I sent an inquiry to the EFF to see if this is an issue that they can help with. Below is the response I received:
Rebecca said:
Rebecca S. Reagan [email protected] to me
show details 6:27 PM (12 hours ago)
Hi there!
Thank you for contacting the Electronic Frontier Foundation (EFF).
Unfortunately, we do not have the capacity necessary to take on open source issues like this one. The Electronic Frontier Foundation (EFF) is a small, grassroots legal advocacy non-profit focused on defending civil liberties and constitutional rights online with very limited resources. As such, we have a very important but narrowly focused mission and are not equipped to address all of the potential issues that escape our limited scope.
Regards,
Rebecca
Click to expand...
Click to collapse
I took a second look, found, and fixed another problem. Attached are more builds.
I compiled an unpatched kernel using 2009q3-67, decompressed it, and ran "strings" against both it and the stock kernel. I diffed the strings output to look for anything missing that I could grep for in the source tree. I found some things in "Kernel/arch/arm/mach-s5pv210/mach-aries.c" in the stock kernel that were missing from my build.
First were missing definitions for "dpram-device", "onedram", and "modemctl". The second were strings corresponding to the modemctl_cfg_gpio function, which is responsible for setting the "PHONE_ON", "CP_RST", and "PDA_ACTIVE" gpios. For these items to be included requires that CONFIG_SAMSUNG_PHONE_TTY and CONFIG_SAMSUNG_PHONE_SVNET be set in the kernel config file. Which they are (as "=m") in forte_01_defconfig.
Here's the problem: when build_kernel.sh runs "make defconfig", the both config options are missing in the resulting .config file. It turns out that as part of the reorganization that Samsung did to package the source release, they moved the onedram drivers from the Kernel source directory to the external module one, and dropped the Kconfig files that define these options. Without them, the build infrastructure assumes that all (useful) references those config options are removed from the all source files and purges them from the configuration. Except they're still needed by mach-aries.c, and without them, a key part to the kernel radio interface goes missing.
This definitely contributes to why the radio can't be brought up on boot. This may also cause the reboot after 15 seconds, although I'm not certain.
Anyways, I fixed this problem by adding stub entires for CONFIG_SAMSUNG_PHONE_TTY and CONFIG_SAMSUNG_PHONE_SVNET to Kernel/arch/arm/Kconfig, which allows those options to be preserved by "make defconfig". I've also verified that all the other purged config options aren't used in this source tree.
Attached is a patch containing the modified Kconfig, just apply and clean build as normal. I've also attached two kernel builds for testing, one with the stock initramfs and the other with k0nane's.
Some more notes:
While comparing strings, I noticed that Samsung appears to do some amount of source clean-up and reorganization in preparation of open source packages. For example, there's a bunch of files stored in a "forte" subdirectory for whatever driver that are moved up to the parent, e.g., "Kernel/arch/arm/mach-s5pv210/forte/mach-aries.c" is moved to "Kernel/arch/arm/mach-s5pv210/mach-aries.c". This alone shouldn't be a problem, but if it was done improperly, i.e., not all forte-specific changes were pushed to the parent, some functionality or device-specific bug fixes could be lost.
With regard to my earlier concern about there being a race condition, I'm uncertain at this point if it's actually a problem. It's possible that the missing device definitions are picked up from sysfs by init, and the relevant device nodes created that way. I haven't verified that this is the case, but given that the Epic should be vulnerable to the same condition, but we never observe it, perhaps it's not really an issue. Also, the reason why modules compiled from the source package are much larger than the ones shipped with the initramfs is that they're unstripped. Compiling with the "INSTALL_MOD_STRIP" environment variable defined results in them being stripped upon "make modules_install".
Hope that helps.
mkasick, you are a god. You've done the work that Samsung completely neglected to do - whether deliberately or not.
I suppose this thread can be closed, now. The changes have been pushed to my Github.
Thanks everyone for your input, and mkasick for fixing an obscure problem on a device you don't own!
Even though JB is more or less feature-complete on Defy(+) there are still a few nits which will be hard to squash without having access to features which are only available in later kernels (eg. the ION memory allocator). Given that this board is frequented by people who (theoretically at least) should be able to give a hand in porting the required drivers/features to get a 3.X kernel up and running on Defy(+) I started making an overview of those missing bits. It should only take a relatively small group of willing volunteers, each responsible for a driver or feature, to get those bits ported.
From a quick glance at the configuration options used with the currently used 2nd-boot kernel I come to the following list of drivers/features which will need to be ported to 3.X. Some of these might already be available under different names in the kernel. Others might have been ported but are simply not part of the kernel tree I used to make this comparison (Quarx2k/jordan-kernel; branch 3.0.8-defy_display). Yet others might not be needed in the newer kernel because their functions are taken over by other drivers/features.
This is not a complete list of features needed to get a kernel running on the Defy(+) (see mapphone_defconfig in branch 2.6.32 for what is needed).
In the following list I marked potential replacements in bold type, usually followed by a question mark (?) to indicate I'm not sure they are fully compatible replacements for the 2.6.X drivers/features. The drivers/features are listed in 2.6.X menuconfig order using Kconfig names and symbols.
Drivers needed for Jordan w/kernel 3.x
Top level
Support for open firmware device tree (ARM port)
ARM_OF -> USE_OF ?
Support for device tree in /proc
PROC_DEVICETREE
DSP Bridge driver
MPU_BRIDGE
System Type
Motorola Android Platform Phone
MACH_MAPPHONE -> MACH_OMAP_MAPPHONE ? complete?
Motorola Android Platform phone 2nd-boot kernel modifications
MAPPHONE_2NDBOOT
Export DIE ID code under /proc/socinfo
OMAP3_EXPORT_DIE_ID
Device Drivers/Misc devices
AKM8973 Magnetometer
SENSORS_AKM8973_AKMD
KXTF9 Accelerometer
SENSORS_KXTF9
Bluetooth power control driver for TI wl127x
WL127X_RFKILL
Motorola OMAP Device Type Driver
OMAP_DEV_TYPE_DRV
Motorola Modem PM Driver
MODEM_PM_DRIVER
Motorola netmux driver
NETMUX_DRIVER
Motorola netmux link driver
NETMUX_LINKDRIVER
Motorola Camera Driver
CAMERA_MISC
Device Drivers/Multimedia support/Video capture adapters
HP OMAP3 Imaging/3A driver
VIDEO_OMAP3_HP3A
Video out driver
VIDEO_OMAP_VIDEOOUT -> VIDEO_OMAP2_VOUT ?
Device Drivers/Sound card support/Open Sound System (DEPRECATED)
Audio driver for OMAP3430 with CPCAP
SOUND_CPCAP_OMAP -> SND_OMAP_SOC ( = ALSA)
Device Drivers/USB support
CPCAP USB Transceiver Driver
CPCAP_USB
Device Drivers/USB support/USB Gadget Support
USB Gadget Drivers (MOTO Android Gadget)
USB_MOT_ANDROID
Device Drivers/Real Time Clock
CPCAP RTC
RTC_DRV_CPCAP
So... anyone here who is willing and able to take on one of these drivers/features? Within a reasonable time frame (weeks, not months)? Anyone who knows of existing ports for these missing bits?
Why wait for Quarx or any of the other already overworked developers to do all the work? Just join hands, sing Kumbayah and get porting - but post here which driver/feature you want to work on to avoid needless duplication of effort.
I'll wait a few days for others to take the fun projects, then I'll start on those which are left.
it's a great idea，but it seems so difficult for us to complete such a huge program.
one-piggy said:
it's a great idea，but it seems so difficult for us to complete such a huge program.
Click to expand...
Click to collapse
It is not as big as you make it out to be. The drivers already exist, they just need to be ported. The differences between 2.6.32 and 3.0.X (the first target) are not that big, so the changes needed should be limited. The number of drivers which need to be ported is also rather limited, especially given the potential number of volunteers. The difficulty level for porting these drivers is generally not that high, there are plenty of examples to be found for similar hardware which has already been ported.
The list contains 17 items. Several of them need to be checked for compatibility only (USE_OF, MACH_OMAP_MAPPHONE, VIDEO_OMAP2_VOUT, SND_OMAP_SOC, USB_MOT_ANDROID). This leaves 12 items. The CPCAP-related drivers might already be available (need to check later Motorola code). The procfs-related stuff should be easy to implement (PROC_DEVICETREE, OMAP3_EXPORT_DIE_ID) and might already be available under different names.
For OMAP-specific stuff (CONFIG_MPU_BRIDGE etc) there is linux-omap, more specifically several mailing lists frequented by people who have experience with porting to the linux-omap tree.
Porting the sensor drivers (SENSORS_AKM8973_AKMD, SENSORS_KXTF9) should be straightforward. The camera/video-related drivers might be more complicated as they'll need to be adapted to use ION. Then again, maybe they have already been ported? If not, there should be plenty of examples for similar hardware to base a port on.
I'm not saying porting these drivers/features will be effortless. Nor does it have to be. Porting ICS and later JB to Defy(+) wasn't effortless either yet still someone did it. By dividing the tasks needed to port these drivers/features the amount of effort needed will be limited. As said, I assume that there are several people frequenting this (part of this) site who should be capable of partaking in this effort.
YetAnotherForumUser said:
The differences between 2.6.32 and 3.0.X (the first target) are not that big
Click to expand...
Click to collapse
I second that. There's a huge misconception that 3.0.x a major change. But it wasn't. They just bumped up the version number.
Sent from my MB526 using xda premium
simmilar drivers in this repository
https://github.com/redyk/omap3630-3.0.8
Lg Optimus Black(sniper) 3.0.8 sources..
I found smmilar drivers but i don't know these drivers same them
quarx is already very far with the kernel. The actual problem is that he has no idea how to get display working.
If anyone can help with this that would be great.
junesoung said:
https://github.com/redyk/omap3630-3.0.8
Lg Optimus Black(sniper) 3.0.8 sources..
I found smmilar drivers but i don't know these drivers same them
Click to expand...
Click to collapse
LG Optimus Black 'sniper' kernel, 3.0.57:
https://github.com/TheMeier/lge-kernel-sniper-linux-stable
Has source for the following drivers, probably more - I just cloned the repository.
AKM8973 Magnetometer
KXTF9 Accelerometer
WL127X_RFKILL
m11kkaa said:
quarx is already very far with the kernel. The actual problem is that he has no idea how to get display working.
If anyone can help with this that would be great.
Click to expand...
Click to collapse
don't see a problem if someone wants to make a separate attempt. i think community effort has better chance in getting latest kernel up and running.
YetAnotherForumUser said:
LG Optimus Black 'sniper' kernel, 3.0.57:
https://github.com/TheMeier/lge-kernel-sniper-linux-stable
Has source for the following drivers, probably more - I just cloned the repository.
AKM8973 Magnetometer
KXTF9 Accelerometer
WL127X_RFKILL
Click to expand...
Click to collapse
Sounds good
GalaxySL use same cpu(omap3630)
It has 3.0 kernel too
You can find more drivers
Sent from my MB525 using xda app-developers app
Which is the base you intend to use as a starting point, test / compile against?
https://github.com/Quarx2k/jordan-kernel/tree/3.0.8-defy_display
This one?
May be this would help http://forum.xda-developers.com/showthread.php?p=33801839
http://forum.xda-developers.com/showthread.php?p=33710566
Sent from my MB526 using xda app-developers app
Comparison between Defy and LG Optimus Black kernel configuration
m11kkaa said:
quarx is already very far with the kernel. The actual problem is that he has no idea how to get display working.
If anyone can help with this that would be great.
Click to expand...
Click to collapse
The display subsystem in the LG Optimus Black seems to resemble that in the Defy(+), so for that purpose those sources can be useful.
For comparison purposes I attached a side-by-side diff of the default Defy(+) kernel .config and that for the LG Optimus Black.
domokos said:
Which is the base you intend to use as a starting point, test / compile against?
https://github.com/Quarx2k/jordan-kernel/tree/3.0.8-defy_display
This one?
Click to expand...
Click to collapse
That is the base I used to find missing drivers/features. For porting purposes it does not matter that much which base is used, as long as it is as close to baseline as possible. The linux-omap tree would be a good starting point as that is a) synchronized with baseline and b) where work on OMAP-related stuff takes place. As the purpose of the port is to get Android to run, the most recent Android-specific branch would be a good target. Of course there is much to say for taking the path of least resistance so if one of those other trees around here (Quarx 3.0.8-defy_display, LG, Samsung, a mashup of all three, etc) can get us where we want to be in less time that would be an option as well.
http://forum.xda-developers.com/showthread.php?t=1546102
maybe this will be helpfull?!
YetAnotherForumUser said:
Even though JB is more or less feature-complete on Defy(+) there are still a few nits which will be hard to squash without having access to features which are only available in later kernels (eg. the ION memory allocator). Given that this board is frequented by people who (theoretically at least) should be able to give a hand in porting the required drivers/features to get a 3.X kernel up and running on Defy(+) I started making an overview of those missing bits. It should only take a relatively small group of willing volunteers, each responsible for a driver or feature, to get those bits ported.
From a quick glance at the configuration options used with the currently used 2nd-boot kernel I come to the following list of drivers/features which will need to be ported to 3.X. Some of these might already be available under different names in the kernel. Others might have been ported but are simply not part of the kernel tree I used to make this comparison (Quarx2k/jordan-kernel; branch 3.0.8-defy_display). Yet others might not be needed in the newer kernel because their functions are taken over by other drivers/features.
This is not a complete list of features needed to get a kernel running on the Defy(+) (see mapphone_defconfig in branch 2.6.32 for what is needed).
In the following list I marked potential replacements in bold type, usually followed by a question mark (?) to indicate I'm not sure they are fully compatible replacements for the 2.6.X drivers/features. The drivers/features are listed in 2.6.X menuconfig order using Kconfig names and symbols.
Drivers needed for Jordan w/kernel 3.x
Top level
Support for open firmware device tree (ARM port)
ARM_OF -> USE_OF ?
Support for device tree in /proc
PROC_DEVICETREE
DSP Bridge driver
MPU_BRIDGE
System Type
Motorola Android Platform Phone
MACH_MAPPHONE -> MACH_OMAP_MAPPHONE ? complete?
Motorola Android Platform phone 2nd-boot kernel modifications
MAPPHONE_2NDBOOT
Export DIE ID code under /proc/socinfo
OMAP3_EXPORT_DIE_ID
Device Drivers/Misc devices
AKM8973 Magnetometer
SENSORS_AKM8973_AKMD
KXTF9 Accelerometer
SENSORS_KXTF9
Bluetooth power control driver for TI wl127x
WL127X_RFKILL
Motorola OMAP Device Type Driver
OMAP_DEV_TYPE_DRV
Motorola Modem PM Driver
MODEM_PM_DRIVER
Motorola netmux driver
NETMUX_DRIVER
Motorola netmux link driver
NETMUX_LINKDRIVER
Motorola Camera Driver
CAMERA_MISC
Device Drivers/Multimedia support/Video capture adapters
HP OMAP3 Imaging/3A driver
VIDEO_OMAP3_HP3A
Video out driver
VIDEO_OMAP_VIDEOOUT -> VIDEO_OMAP2_VOUT ?
Device Drivers/Sound card support/Open Sound System (DEPRECATED)
Audio driver for OMAP3430 with CPCAP
SOUND_CPCAP_OMAP -> SND_OMAP_SOC ( = ALSA)
Device Drivers/USB support
CPCAP USB Transceiver Driver
CPCAP_USB
Device Drivers/USB support/USB Gadget Support
USB Gadget Drivers (MOTO Android Gadget)
USB_MOT_ANDROID
Device Drivers/Real Time Clock
CPCAP RTC
RTC_DRV_CPCAP
So... anyone here who is willing and able to take on one of these drivers/features? Within a reasonable time frame (weeks, not months)? Anyone who knows of existing ports for these missing bits?
Why wait for Quarx or any of the other already overworked developers to do all the work? Just join hands, sing Kumbayah and get porting - but post here which driver/feature you want to work on to avoid needless duplication of effort.
I'll wait a few days for others to take the fun projects, then I'll start on those which are left.
Click to expand...
Click to collapse
Maybe this link can be useful: http://blackscratches.blogspot.ro/2012/04/how-to-build-android-kernel-308-for-ti.html it seems very explicit about porting kernel 3.0.8 on omap 3630 including drivers
Fight4Music said:
http://forum.xda-developers.com/showthread.php?t=1546102
maybe this will be helpfull?!
Click to expand...
Click to collapse
It might. For more stuff like that have a look at the Linux OMAP Kernel Project where you'll find more about the various OMAP-related development efforts. The above link points to one of the many branches of this tree:
http://git.omapzoom.org/?p=kernel/omap.git;a=summary
In the p-android-omap-3.4 branch there is a camera driver for the "Aptina MT9P031 Camera". The Defy+ (and Defy/Bayer) contain a camera based on the MT9P012. It stands to reason that there is a family relationship between all these mt9xyyy sensor drivers.
Working 3.0 kernel for Samsung Galaxy SL
The Samsung Galaxy SL shares quite a bit of hardware with the Defy(+). There now is a working (if not feature-complete) 3.0 kernel for this device.
https://github.com/dhiru1602/android_kernel_samsung_latona
Attached to this message is a side-by-side diff between the Defy default config and that for the latona (S G SL) as well as a side-by-side diff between the Optimus Black default config and that for the latona.
http://forum.xda-developers.com/showthread.php?t=1546102
Sent from my MB525 using xda app-developers app
junesoung said:
http://forum.xda-developers.com/showthread.php?t=1546102
Sent from my MB525 using xda app-developers app
Click to expand...
Click to collapse
See #14...
YetAnotherForumUser said:
See #14...
Click to expand...
Click to collapse
Oh, sorry;
Sent from my MB525 using xda app-developers app
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.
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
Latest Version 0.5.1 (beta)
What is CobaltDebugger? An ARM Processor Simulator/Emulator/Debugger. At its current state, it reads Android bootloader files, and runs them in a simulator, giving you control over which instructions execute and when. For optimal experience, use this in conjunction with IDA Pro.
Hint: Try setting the PC Register to an interesting address found in IDA.
https://youtu.be/cwvz8Cj70Ac <- newer but still old
https://youtu.be/L5NDob2rCmI <- even older
Unzip contents
Run CobaltDebugger.exe
Load up your aboot.mbn or sbl1.mbn
If you want to display referenced strings, open your binary in IDA, go to View > Subviews > Strings, then copy and paste the contents of the strings window into a new text file, then load that text file into CobaltDebugger.
Memory file will grow to 4GB
Click "Load Binary"
Then click "Step Into" or "Run"
You can
- Set breakpoints by address: use >, and < to define break-ranges
- Alter register values, condition flags, psr modes, instruction sets (ARM and Thumb)
Memory edits are not yet implemented but will most likely come as time permits
Page Up, Page Down, Up, and Down keys can be used to navigate the memory viewer - or you can type an address and click "Go" to go there - There's a bug in here somewhere - I'll get to it
The output from the bottom right window is saved as output.xxxxxx.txt, although the file may not get flushed until you click "Unload" or close the application.
All ARM and Thumb instructions were implemented in C# by hand by me. There may be bugs here and there as this is a work in progress and beta. Not all instructions have been implemented so you may encounter a message that states such and such instruction not implemented. If you see that, let me know which instruction and I will implement it as time permits, or you can wait until the next release. I plan on continuing this project until all instructions are implemented.
Originally built with the binaries from the AT&T Samsung Galaxy Note 3 (NC2) in mind, but focus switched to the Verizon Samsung Galaxy S4 (NK1), then back to Note 3 (OC1). This should work with other similar binaries as well.
I'm hoping this will help us discover new ways to unlock bootloaders. But at the very least it's fun to watch the files run.
Change Log 0.5.1
Added image verification steps thanks to Tal Aloni
Bug fixes
More instructions implemented
Slight redesign
Change Log 0.5
Bug fixes, UI improvements, a few more instructions implemented
Now the "Next" instruction is actually the Next instruction as opposed to the most recently executed instruction, so you can see the instruction highlighted BEFORE it executes.
Change Log 0.4.1
Fixed some bugs
Implemented some more instructions
AT&T Note 3 NC2 aboot runs to completion again, although you may find some instructions I've missed if you start jumping around editing the PC value.
Change Log 0.4
Complete refactor
Verizon S4 NK1 aboot runs to completion, although you may find some instructions I've missed if you start jumping around editing the PC value.
Broke some things with the Note 3 aboot instructions
Change Log v0.3:
set default breakpoint for Verizon S4 aboot - Either it's actually *supposed* to start executing code at 0x880C7000 after an MCR and BX instruction, or I may have mis-coded something, but it seems odd, so a breakpoint is set to 0x88E0E4BC until I can figure that one out.
Output to file - C:\temp\output.HHmmss.asm - Now you can review the log after the program has run.
Subscribed. This is going to be epic.
Taking the trash out then going to have some fun hopefully with this.
Next feature to add is the ability to load and run elf files like tz and sdi
v0.2
I Implemented the SP Minus Immediate instruction, which should resolve the NotImplemented exception reported by @dmt010 . I also implemented a bunch more instructions needed by the S4 aboot, although I'm still not done. I went ahead and uploaded an update anyway. This one doesn't blow up like the first version, but rather displays the missing instruction if it encounters one. To skip to a specific address and start executing code, you can modify the PC register and click Apply Edits, then step or run. Sometimes you have to do it twice for it to take, for some reason. If you want to play around with this with your own abootmbn or sbl1.mbn, feel free to post any Not Implemented messages here so I can add them, just make sure no one else has already posted it. Make sure you copy and paste the whole line including the instruction mnemonic and "Pattern" which will help me to identify the desired encoding.
Instruction [Thumb16,LDRB] not implemented. Pattern: [01111iiiiinnnttt]. Address: [0x88E1C470]
Cheers
I just uploaded v0.3. Now it runs the Verizon S4 aboot file without exception until it gets to a section where keeps incorrectly executing ANDEQ R0, R0, #0x3. I know that's not what it is supposed to do, and that it is a result of BX R14, when R14 is holding 0x880C7000, but 0x880C7000 has only zeros because the s4 aboot is running out of context, isolated. Maybe there is supposed to be code at 0x880C7000, ready and waiting to run. Or maybe there was a calculation error in my code and R14 should not have held the value 0x880C7000. I don't know. I will relook at the preceeding steps and make sure the calculations are correct. Might add a unit test or two. I may need to spend more time looking at the line before the branch (MCR p15, 0, R0,c1,c0, 0) MCR was one of the first instructions I implemented months ago. I may need to re-look at that logic and make sure I did it right...
Cobaltikus said:
I just uploaded v0.3. Now it runs the Verizon S4 aboot file without exception until it gets to a section where keeps incorrectly executing ANDEQ R0, R0, #0x3. I know that's not what it is supposed to do, and that it is a result of BX R14, when R14 is holding 0x880C7000, but 0x880C7000 has only zeros because the s4 aboot is running out of context, isolated. Maybe there is supposed to be code at 0x880C7000, ready and waiting to run. Or maybe there was a calculation error in my code and R14 should not have held the value 0x880C7000. I don't know. I will relook at the preceeding steps and make sure the calculations are correct. Might add a unit test or two. I may need to spend more time looking at the line before the branch (MCR p15, 0, R0,c1,c0, 0) MCR was one of the first instructions I implemented months ago. I may need to re-look at that logic and make sure I did it right...
Click to expand...
Click to collapse
What did I say? Glad I snagged the first post, I knew this project would take off.
It is possible that at some point I will consider sharing my source code to the public. But first I need to look into different licensing steps I should take to make sure that if I do release it, it will remain open source and not be stolen and licensed by someone else, forcing me to take my code down, or something else that could be bad for me. I want to make sure that if I do it, I do it right. Another issue for me is that I like to copy and paste the psuedocode from ARM directly into my code, commented, so I have it for reference. I'm fairly certain I would have to take that out before releasing, so I'm not infringing on ARM's copyright policies. But it would be nice to collaborate. Possibly. Maybe.
Cobaltikus said:
... (MCR p15, 0, R0,c1,c0, 0) MCR was one of the first instructions I implemented months ago. I may need to re-look at that logic and make sure I did it right...
Click to expand...
Click to collapse
Yep. I need to re-implement MCR. I wasn't doing all that needed to be done.
v0.4
v0.4 runs Verizon S4 NK1 aboot to completion, and you can view and modify the active Instruction Set (ARM vs Thumb).
v0.5
v0.5
I got a bit side tracked. Thanks to Tal Aloni, Cobalt Debugger now shows and validates the certificate chain and image signature, which started me down the rabbit hole of potentially cracking RSA. When I come back up for air I'll post my latest changes.
ive been trying to crack that thing for months now! haha join in the telegram again for info and we can collaborate live. from what i understand we're dealing with an RSA-SHA1 sig with PKCS#11 padding
Sorry to be somewhat off-topic, but RSA is a method of encryption. So Samsung/Verizon used this to encrypt the bootloader. So if we can crack it, we have access to the bootloader and can Loki it/ another exploit?
Oh yeah, I subbed. I'm teaching myself python and Java(was already on my to do list) to try and offer limited help.
XxD34THxX said:
Sorry to be somewhat off-topic, but RSA is a method of encryption. So Samsung/Verizon used this to encrypt the bootloader. So if we can crack it, we have access to the bootloader and can Loki it/ another exploit?
Oh yeah, I subbed. I'm teaching myself python and Java(was already on my to do list) to try and offer limited help.
Click to expand...
Click to collapse
can you do much with python on android?
What exactly does this thing do ? I"m a bit confused This is some kind of simulator so that you can see how it impacts memory during execution ? But then again, if it can't access hardware then what's the use ? What does it offer over IDA pro ? I'm confused
Not now. Still on the basics of python. I have python and ide on my pc waiting if you need me to test something.
kcarden said:
ive been trying to crack that thing for months now! haha join in the telegram again for info and we can collaborate live. from what i understand we're dealing with an RSA-SHA1 sig with PKCS#11 padding
Click to expand...
Click to collapse
Ah right, getting now what the use of this is As long as stuff is not done in hardware, which it most likely wont be anyway (cause kernel is not up lol) then this could function as a simulator to debug the bootloader. Makes sense
XxD34THxX said:
Sorry to be somewhat off-topic, but RSA is a method of encryption. So Samsung/Verizon used this to encrypt the bootloader. So if we can crack it, we have access to the bootloader and can Loki it/ another exploit?
Oh yeah, I subbed. I'm teaching myself python and Java(was already on my to do list) to try and offer limited help.
Click to expand...
Click to collapse
i've been looking a lot at recovery.img and the recovery partition. and what happens is the image is encrypted and then signed to be accepted by other software sig checks