Hi,
I wan't to add a new key in /res/keys to be able to sign update.zip files that will be verified OK by the recovery.
It seems the utility dumpkeys.jar is done for this, but I don't currently have the environement to compile Android and cannot manage to compile the DumpPublicKey.java file alone.
Would any ROM makers post me the dumpkeys.jar (it's in system/core/libmincrypt/tools ) ?
Or any other utilities that can put the public key in good format...
Or any other way to achieve this (I don't wan't to change the boot loader except if there is no other solutions).
Thanks.
/res/keys in stock rom's initramfs and custom roms'
want to know how /res/keys is used in zImage and flashing
Thanks
http://forum.xda-developers.com/showthread.php?t=788251
sorry to post here as I don't have right to post there.
seem res/keys is required for custom zImage but how to replace or create. Guess it can't just copy from stock rom
found something related which may help
http://forum.xda-developers.com/showthread.php?t=581216
http://forum.xda-developers.com/showthread.php?t=471586&highlight=sign
found it!! the code which check /res/keys
<android source>/bootable/recovery/install.c
Code:
#include "install.h"
#include "mincrypt/rsa.h"
#include "minui/minui.h"
#include "minzip/SysUtil.h"
#include "minzip/Zip.h"
#include "mtdutils/mounts.h"
#include "mtdutils/mtdutils.h"
#include "roots.h"
#include "verifier.h"
#define ASSUMED_UPDATE_BINARY_NAME "META-INF/com/google/android/update-binary"
#define PUBLIC_KEYS_FILE "/res/keys"
As many know, Jelly Bean wifi does not support enterprise wifi.
A fix was posted on the google forum that will hopefully work with the TF300t http://code.google.com/p/android/issues/detail?id=34212#c165
external/wpa_supplicant_8:
diff --git a/src/crypto/tls_openssl.c b/src/crypto/tls_openssl.c
index aaa920b..be94e8a 100644
--- a/src/crypto/tls_openssl.c
+++ b/src/crypto/tls_openssl.c
@@ -929,6 +929,11 @@ struct tls_connection * tls_connection_init(void *ssl_ctx)
#ifdef SSL_OP_NO_COMPRESSION
options |= SSL_OP_NO_COMPRESSION;
#endif /* SSL_OP_NO_COMPRESSION */
+#ifdef ANDROID
+ options |= SSL_OP_NO_TLSv1_1;
+ options |= SSL_OP_NO_TLSv1_2;
+ options |= SSL_OP_NO_TICKET;
+#endif /* ANDROID */
SSL_set_options(conn->ssl, options);
conn->ssl_in = BIO_new(BIO_s_mem());
(note similar patch in wpa_supplicant_6 if your build configuration uses that)
those shouldn't disable WiFi, just limit what TLS versions are used by wpa_supplicant to talk to the server. it should still use TLSv1.0 and SSLv3.0.
My understanding is that you have to apply the patch to the source code and recompile the file. I have no clue how to do this despite a few searches with explanations beyond my abilities. Could someone give me a newb guide on how to do this or uploaded a patched file to fix this common issue?
Many, many thanks!
Is it possible to apply the patch and recompile it in Windows 7? From my searches it seems that you need linux (Ubuntu?) or Mac. If so, can you point me in the right direction?
Thanks!
Please compile, if possible, your embedded recovery kernels without the sensorhub defconfig options.
CONFIG_SENSORS_SSP=y
CONFIG_SENSORS_SYSFS=y
CONFIG_SENSORS_SSP_ACCELEROMETER_POSITION=7
CONFIG_SENSORS_SSP_GYROSCOPE_POSITION=7
CONFIG_SENSORS_SSP_MAGNETOMETER_POSITION=7
CONFIG_SENSORS_SSP_LSM330=y
CONFIG_SENSORS_SSP_CM36651=y
CONFIG_SENSORS_SSP_AK8963C=y
CONFIG_SENSORS_SSP_BMP182=y
CONFIG_SENSORS_SSP_AT32UC3L0128=y
CONFIG_SENSORS_SSP_SENSORHUB=y
The kernel flashes over the sensorhub firmware on every single entry of recovery, and rebooting into the normal kernel, if the embedded kernel firmware mismatches the live hardware firmware. I consider this dangerous because firstly I don't know what happens if a firmware flash fails on boot, and secondly, the whole procedure is done over the I2C bus and takes about 22 seconds, increasing the boot time (and recovery entry) dramatically. The firmware changes relatively often and we have like 4 different versions out there in the wild at this moment and they will surely increase.
Off-topic: The sensorhub is a new dedicated micro-controller chip found on the Note 2 which handles all device sensors, instead of them being handled by the main CPU itself. The point of the thing is to offload that work from the CPU to vastly improve battery life.
Thank you a lot for the feedback and input about this issue
When compiling recoveries, we get the binary (recovery file) and the kernel. Sorry if I seem noob here, but I do not compile kernels, I am only used to cwm source. And in the recovery binary sources, there is no sensors flashed, it is the kernel that is repacked with it.
Now, if I take a recovery.img as it is outputted when compiled from cm10 sources, that is packed with a cm10 kernel, the recovery will boot without a delay.
However, that will break exfat support since we cannot insmod the external modules
So, the only choice is to repack the recovery ramdisk with a stock Samsung kernel, and that's what I do in my recoveries. However, this seems to induce the boot delay for people using custom kernels built around some sources (redpill, Perseus)
These recoveries repacked with a Samsung kernel will run fine along stock kernels and Note2core custom kernel (also a 4.1.2 source).
One of the potential causes is this part of code I believe (have no Note 2 to debug it)
drivers/sensor/ak8963.c
Code:
if (retry_count < 5) {
retry_count++;
pr_warn("############################################");
pr_warn("%s, retry_count=%d\n", __func__, retry_count);
pr_warn("############################################");
goto retry;
} else {
There is a check routine repeated 5 times, and on each repeat count a goto loop. The retry loop restarts much above in the code
retry:
Code:
#ifdef FACTORY_TESTstatic int ak8963c_selftest(struct akm8963_data *ak_data, int *sf){
.
.
.
retry:
/* read device info */
i2c_smbus_read_i2c_block_data(ak_data->this_client,
AK8963_REG_WIA, 2, buf);
pr_info("%s: device id = 0x%x, info = 0x%x\n",
__func__, buf[0], buf[1]);
/* set ATSC self test bit to 1 */
i2c_smbus_write_byte_data(ak_data->this_client,
AK8963_REG_ASTC, 0x40);
/* start self test */
i2c_smbus_write_byte_data(ak_data->this_client,
AK8963_REG_CNTL1,
AK8963_CNTL1_SELF_TEST);
/* wait for data ready */
while (1) {
msleep(20);
if (i2c_smbus_read_byte_data(ak_data->this_client,
AK8963_REG_ST1) == 1) {
break;
}
}
i2c_smbus_read_i2c_block_data(ak_data->this_client,
AK8963_REG_HXL, sizeof(buf), buf);
/* set ATSC self test bit to 0 */
i2c_smbus_write_byte_data(ak_data->this_client,
AK8963_REG_ASTC, 0x00);
x = buf[0] | (buf[1] << 8);
y = buf[2] | (buf[3] << 8);
z = buf[4] | (buf[5] << 8);
/* Hadj = (H*(Asa+128))/256 */
x = (x*(ak_data->asa[0] + 128)) >> 8;
y = (y*(ak_data->asa[1] + 128)) >> 8;
z = (z*(ak_data->asa[2] + 128)) >> 8;
pr_info("%s: self test x = %d, y = %d, z = %d\n",
__func__, x, y, z);
if ((x >= -200) && (x <= 200))
pr_info("%s: x passed self test, expect -200<=x<=200\n",
__func__);
else
pr_info("%s: x failed self test, expect -200<=x<=200\n",
__func__);
if ((y >= -200) && (y <= 200))
pr_info("%s: y passed self test, expect -200<=y<=200\n",
__func__);
else
pr_info("%s: y failed self test, expect -200<=y<=200\n",
__func__);
if ((z >= -3200) && (z <= -800))
pr_info("%s: z passed self test, expect -3200<=z<=-800\n",
__func__);
else
pr_info("%s: z failed self test, expect -3200<=z<=-800\n",
__func__);
sf[0] = x;
sf[1] = y;
sf[2] = z;
if (((x >= -200) && (x <= 200)) &&
((y >= -200) && (y <= 200)) &&
((z >= -3200) && (z <= -800))) {
pr_info("%s, Selftest is successful.\n", __func__);
return 1;
} else {
if (retry_count < 5) {
retry_count++;
pr_warn("############################################");
pr_warn("%s, retry_count=%d\n", __func__, retry_count);
pr_warn("############################################");
goto retry;
}
These are many retries using a non efficient goto loop.
Basically, here's the current possibilities I see:
- if we repack the recovery with your kernel or redpill, people will get delay issues on stock ROMs/Kernels
- if we use cm10 kernel: no delays but we loose exfat support
- if we use note2core kernel we'll probably loose exfat support
- if I recompile kernel from samsung sources without the sensors, it seems it will also break exfat
So, at the end I do not see a good choice that will satisfy every one. Either I wait for Samsung to release their sources so that you fix the kernel or I repack with 2 kernels: Samsung stock and redpill, so people can chose
Hope I am not getting it all wrong, but that's how I understand it
All that code is totally irrelevant and has nothing to do with the issue. I also don't understand what you want to say about that loop? Goto is inefficient? Nonsense.
The firmware flash and logic happens in /drivers/sensorhub/ssp_firmware.c and its just a few lines of code. The whole flash process is logged in kmsg at boot so you can just retrieve that and see for yourself.
And you're missing the point, as long as you embed ANY kernel with the sensorhub drivers, they will flash it. There are stock kernels out there with versions 91100, 92600, 92800, 102600 (just from the top of my head, might differ). If you use any recovery kernel whose version mismatches the boot.img kernel firmware, you will get the issue.
And to be honest, I don't understand what the fuss is about fixing it, TWRP includes now a kernel with exFat and removed sensor drivers. You just have to do the same.
Phil3759 said:
Either I wait for Samsung to release their sources so that you fix the kernel
Click to expand...
Click to collapse
There is nothing to fix from the live kernel side, I hope you understand that...
AndreiLux said:
All that code is totally irrelevant and has nothing to do with the issue. I also don't understand what you want to say about that loop? Goto is inefficient? Nonsense.
The firmware flash and logic happens in /drivers/sensorhub/ssp_firmware.c and its just a few lines of code. The whole flash process is logged in kmsg at boot so you can just retrieve that and see for yourself.
And you're missing the point, as long as you embed ANY kernel with the sensorhub drivers, they will flash it. There are stock kernels out there with versions 91100, 92600, 92800, 102600 (just from the top of my head, might differ). If you use any recovery kernel whose version mismatches the boot.img kernel firmware, you will get the issue.
And to be honest, I don't understand what the fuss is about fixing it, TWRP includes now a kernel with exFat and removed sensor drivers. You just have to do the same.
There is nothing to fix from the live kernel side, I hope you understand that...
Click to expand...
Click to collapse
AndreiLux said:
Sorry but you're a bit out of bound here with accusing kernel developers and doing such claims about the source of the issue while you seem pretty ignorant about the technical aspects of the problem.
As I said and explained in the thread you linked, the problem lies with the recovery and not the boot kernel. You're the one who will have to adapt your embedded kernel that you include here.
Click to expand...
Click to collapse
You also seem a bit ignorant about recoveries
TWRP doesn't included any custom kernel with exfat support. It comes with cm9 kernel and maybe now cm10.1 since they moved sources to 4.2 recently. Their source is just the android/bootable/recovery part built around cyanogenmod source. CM kernel, as I said in my answer, doesn't flash the sensors that's why there is no delay. That's the only reason why twrp won't have the delay. I can also include cm10 kernel and no more delays, but say good bye to exfat.
TWRP includes native exfat support where as CM and AOKP choose to not include it in their source (thus cwm) because it is not legal (MS patent). Only thing cwm devs can do:
- import twrp source for exfat support and break the MS patent
- use Samsung genuine kernel to get exfat support
So, not an easy decision / move as you suggest
Phil3759 said:
TWRP doesn't included any custom kernel with exfat support. It comes with cm9 kernel and maybe now cm10.1 since they moved sources to 4.2 recently. Their source is just the android/bootable/recovery part built around cyanogenmod source. CM kernel, as I said in my answer, doesn't flash the sensors that's why there is no delay. That's the only reason why twrp won't have the delay. I can also include cm10 kernel and no more delays, but say good bye to exfat.
TWRP includes native exfat support where as CM and AOKP choose to not include it in their source (thus cwm) because it is not legal (MS patent). Only thing cwm devs can do:
- import twrp source for exfat support and break the MS patent
- use Samsung genuine kernel to get exfat support
So, not an easy decision / move as you suggest
Click to expand...
Click to collapse
Sorry but almost everything you said its wrong.
TWRP includes a modified CM kernel with added exFat and since I've made Bigbiff aware, also removes the sensorhub drivers.
CM kernel, as I said in my answer, doesn't flash the sensors that's why there is no delay.
Click to expand...
Click to collapse
The CM kernel is based on the Samsung sources and has the flash logic intact, because it's obviously needed in the OS to even have functioning sensors. It's not flashing in your case because you have matching firmwares, and that's all.
Sorry but I suggest you inform yourself here a bit more, I've explained it pretty clearly yet you seem to be ranting about things which are just not correct.
delete
I am trying to build some kernel modules for a Tronsmart MK808ii but Tronsmart have not provided the config (No proc/config.gz) after some messing about I have managed to get some kernel modules to load (I have the Init and Exit pointers in the right place). My first aim is to allow the device to read usb cdroms and iso files for which I need to load isofs.ko cdrom.ko and sr_mod.ko
Actually things go pretty well except there appears to be a misalignment between struct gendisk in the module and kernel. when the genhd driver dereferences gendisk->part0 i get an oops. Looking at the code the only definable length object before part0 seems to be disk_name
In order to be more precise about what's happening and to determine the relative alignment of structures between my kernel and the supplied one I need to be able to disassemble the original kernel which I've extracted from the eeprom - ony problem is that neither file nor objdump know what to do with this image, so I'm presupposing it has some sort of header on it so the bootloader can find the image. The Image starts with KRNL$
Does anyone have an idea of how vmlinux image can be extracted from this rom image?
int major; /* major number of driver */
int first_minor;
int minors; /* maximum number of minors, =1 for
* disks that can't be partitioned. */
char disk_name[DISK_NAME_LEN]; /* name of major driver */
char *(*devnode)(struct gendisk *gd, mode_t *mode);
unsigned int events; /* supported events */
unsigned int async_events; /* async events, subset of all */
/* Array of pointers to partitions indexed by partno.
* Protected with matching bdev lock but stat and other
* non-critical accesses use RCU. Always access through
* helpers.
*/
struct disk_part_tbl __rcu *part_tbl;
struct hd_struct part0;
I get a lot of question that my custom kernel breaks support their own AOSP-based ROMs.
So I'm here to how to fix that from your side.
The culprit is CyanogenMod's /init.environ.rc.
CM has been messing around that in recent months.
Changing BOOTCLASSPATH does not break cross-compatibility between different AOSP forks, as long as they don't remove stuffs and just adds stuff.
The problem is SYSTEMSERVERCLASSPATH. If any new stuffs are added, Android RunTime will just abort itself and refuse to boot.
And recently, CyanogenMod added Cyanogen Platform API.
That additionally adds /system/framework/org.cyanogenmod.platform.jar to the /init.environ.rc's SYSTEMSERVERCLASSPATH.
That breaks other AOSP-forks that doesn't use Cyanogen Platform API.
So those ROM developers have 3 options.
They can..
1. Just go and use Cyanogen Platform API. Undoubtedly, this would be super hard if your ROM is not already based on CyanogenMod.
2. Ask custom kernel developers to release a separate version just for your ROM. Very unlikely.
3. Solution below.
Most elegant solution I ended up so far is patch your Android RunTime(android_art) to just bypass extra SYSTEMSERVERCLASSPATH.
Just go to art/runtime/native/dalvik_system_DexFile.cc.
Around line 380..
Code:
diff --git a/runtime/native/dalvik_system_DexFile.cc b/runtime/native/dalvik_system_DexFile.cc
index 3298b46..50aa44c 100644
--- a/runtime/native/dalvik_system_DexFile.cc
+++ b/runtime/native/dalvik_system_DexFile.cc
@@ -382,14 +382,6 @@ static jbyte IsDexOptNeededInternal(JNIEnv* env, const char* filename,
// Logging of reason for returning kDexoptNeeded or kPatchoatNeeded.
const bool kReasonLogging = true;
- if ((filename == nullptr) || !OS::FileExists(filename)) {
- LOG(ERROR) << "DexFile_isDexOptNeeded file '" << filename << "' does not exist";
- ScopedLocalRef<jclass> fnfe(env, env->FindClass("java/io/FileNotFoundException"));
- const char* message = (filename == nullptr) ? "<empty file name>" : filename;
- env->ThrowNew(fnfe.get(), message);
- return kUpToDate;
- }
-
// Always treat elements of the bootclasspath as up-to-date. The
// fact that code is running at all means that this should be true.
Runtime* runtime = Runtime::Current();
Remove those 7 lines and your ROM will be now compatible with custom kernels targeting CyanogenMod.
(Git style patch is added for 'git am' command. I'd appreciate it if you maintain Git repository, apply that Git patch for authorship.)
The only problem so far would be that this will break compatibility with Xposed, which replaces Android RunTime thus reverting this modification.