Related
The most recent ROM update released by Dopod has changed the format of NBF files. Here is the information I've found. Maybe someone would create a new xda3nbftool from the code I provide? I don't have time for this. Probably the same format soon would be used in other operator's updates.
New NBF files header is normally 0xAB bytes in length and looks like "K7qAW73q39..skipped..t7=". It is a base64 encoded string with a modified alphabet. The string length may change in the newer version, so you need to search for "=" to find the end of a header.
Here is a sample code that decodes it:
Code:
/*
* $Id: base64.c,v 1.1.1.1 2001/10/04 00:16:06 andrewr Exp $
* modified by mamaich for HTC firmware
*/
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
static void base64_init(void);
static int base64_initialized = 0;
#define BASE64_VALUE_SZ 256
#define BASE64_RESULT_SZ 8192
int base64_value[BASE64_VALUE_SZ];
/*
* This is the original base64 decode table:
*
const char* base64_code = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
*/
/*
* BaUpgradeUt uses a modified alphabet:
*/
const char* base64_code = "yz98765432UVWXYZabcdKLMNOPQRSTopqrstuvwxefghijklmnABCDEFGHIJ10+/";
static void
base64_init(void)
{
int i;
for (i = 0; i < BASE64_VALUE_SZ; i++)
base64_value[i] = -1;
for (i = 0; i < 64; i++)
base64_value[(int) base64_code[i]] = i;
base64_value['='] = 0;
base64_initialized = 1;
}
char *
base64_decode(const char *p)
{
static char result[BASE64_RESULT_SZ];
int j;
int c;
long val;
if (!p)
return NULL;
if (!base64_initialized)
base64_init();
val = c = 0;
for (j = 0; *p && j + 4 < BASE64_RESULT_SZ; p++) {
unsigned int k = ((unsigned char) *p) % BASE64_VALUE_SZ;
if (base64_value[k] < 0)
continue;
val <<= 6;
val += base64_value[k];
if (++c < 4)
continue;
/* One quantum of four encoding characters/24 bit */
result[j++] = val >> 16; /* High 8 bits */
result[j++] = (val >> 8) & 0xff; /* Mid 8 bits */
result[j++] = val & 0xff; /* Low 8 bits */
val = c = 0;
}
result[j] = 0;
return result;
}
/* adopted from http://ftp.sunet.se/pub2/gnu/vm/base64-encode.c with adjustments */
const char *
base64_encode(const char *decoded_str)
{
static char result[BASE64_RESULT_SZ];
int bits = 0;
int char_count = 0;
int out_cnt = 0;
int c;
if (!decoded_str)
return decoded_str;
if (!base64_initialized)
base64_init();
while ((c = (unsigned char) *decoded_str++) && out_cnt < sizeof(result) - 5) {
bits += c;
char_count++;
if (char_count == 3) {
result[out_cnt++] = base64_code[bits >> 18];
result[out_cnt++] = base64_code[(bits >> 12) & 0x3f];
result[out_cnt++] = base64_code[(bits >> 6) & 0x3f];
result[out_cnt++] = base64_code[bits & 0x3f];
bits = 0;
char_count = 0;
} else {
bits <<= 8;
}
}
if (char_count != 0) {
bits <<= 16 - (8 * char_count);
result[out_cnt++] = base64_code[bits >> 18];
result[out_cnt++] = base64_code[(bits >> 12) & 0x3f];
if (char_count == 1) {
result[out_cnt++] = '=';
result[out_cnt++] = '=';
} else {
result[out_cnt++] = base64_code[(bits >> 6) & 0x3f];
result[out_cnt++] = '=';
}
}
result[out_cnt] = '\0'; /* terminate */
return result;
}
int main()
{
char *In="K7qAW73q39yq39yq39yq37bZK707Xtyn39yq39yq39zNLCKq39yq387kWtakW8Oq39yq39yq39z9R4LvaMHxPMmq39yq39yqW9yq39yq39zrW8ymW8ymW8amW8ym39yq39yq39yq39yq39yq39yq39yq39yq39yqW5KEY8qAWt7=";
puts(base64_decode(In));
}
Re: Encryption algo in ba_dpodcht_12406_110_10600 + radio RO
The encryption of the ROM image has also changed. It is still a modification of XOR algorythm. The remaining part of the file starting from 0xAB offset may be decrypted with this procedure:
Code:
bool XorBuffer(BYTE *buf, int len, DWORD &dwVal)
{
DWORD *p= (DWORD*)buf;
if (len&3)
printf("WARNING: buffer not multiple of 4\n");
len >>= 2;
while (len--)
{
*p++ ^= dwVal;
dwVal^=p[-1];
}
return true;
}
The modification is minimal - the XOR constant is XORed itself with a decrypted byte. The other code of xda3nbftool does not need to be modified except for skipping the 0xAB bytes from the start of a file.
The starting values of dwVal for the chinese update:
Extended ROM: 0x9d94b405
Main ROM: 0xE688221
Radio: 0x1F1F5006
Maybe later I'll make a program that would automatically calculate these constants for a given ROM image.
Re: Encryption algo in ba_dpodcht_12406_110_10600 + radio RO
To protect radio ROM from reverse engeneering HTC used a simple substitution cipher. I've managed to calculate a part of a table for ascii characters and numbers. Someone with a better cryptographic skills is needed to find the remaining part of the table. Here is a sample code that partially decrypts the radio ROM image. All embedded strings become readable, but the code still cannot be decompiled.
Edited: I've calculated the whole table. See posts below.
Code:
#include <stdio.h>
int Arr[256];
void main(int argc, char *argv[])
{
FILE *SrcFile;
unsigned long Count[256], MaxCount=0;
int I, Ch, PrevCh=0, Divider, Value;
for(int i=0; i<256; i++)
Arr[i]=i;
Arr[0xFF]=0xFF;
... deleted ...
Arr[0x2D]=0x7e;
if (argc != 2)
{
printf("\nSyntax: DECR <file>");
return;
}
if ((SrcFile=fopen(argv[1],"rb")) == NULL)
{
printf("\nCannot open %s",argv[1]);
return;
}
FILE *O=fopen("radio","wb");
for (I=0; I < sizeof(Count)/sizeof(Count[0]); I++)
Count[I]=0;
while ((Ch=fgetc(SrcFile)) != EOF)
fputc(Arr[Ch],O);
fclose(SrcFile);
fclose(O);
}
The code looks ugly, but it works.
Looking at Magician ROM?
Hi mamaich,
Thanks for your continuous good work!
Are you looking at Magician ROM as well? While it uses USB for ActiveSync, it may mean the closest and most official port that Himalaya can have.
Re: Looking at Magician ROM?
I've found a simple method to generate the complete table.
Here is it:
Code:
int Arr[256]={
0x34, 0x4F, 0x9E, 0x59, 0x47, 0xC1, 0xAC, 0x96, 0xF5, 0x99, 0xF4, 0x24, 0x58, 0xFD, 0x2C, 0x7B,
0x3F, 0x25, 0x26, 0x00, 0x61, 0x21, 0x30, 0x54, 0x1D, 0x2D, 0xDF, 0x05, 0xBD, 0x29, 0x2A, 0x82,
0x14, 0x6E, 0x31, 0x68, 0x10, 0x5C, 0x63, 0x13, 0x1C, 0xDE, 0x39, 0x1F, 0x18, 0x7E, 0x66, 0xD0,
0xB3, 0x1B, 0xED, 0x20, 0x27, 0x3B, 0x8D, 0x0B, 0xB6, 0x64, 0xC2, 0x28, 0x2F, 0x9D, 0x78, 0x0E,
0xAF, 0x52, 0xD4, 0xD6, 0x70, 0x6C, 0x53, 0x73, 0x7C, 0x5A, 0xD1, 0x7F, 0x6D, 0x69, 0x5D, 0x12,
0x43, 0xCB, 0x2E, 0xBC, 0x04, 0xB8, 0x86, 0x44, 0x4B, 0x3E, 0xD5, 0xB9, 0x01, 0x4D, 0xA8, 0x4C,
0xE4, 0xAB, 0x7A, 0x35, 0xA3, 0xEC, 0x3D, 0x72, 0x11, 0x5E, 0x8F, 0xC0, 0x56, 0x19, 0xC8, 0x87,
0x0F, 0x45, 0x46, 0xC3, 0x55, 0xCC, 0x6B, 0xB7, 0x0A, 0x62, 0x71, 0x36, 0xA0, 0x49, 0x4A, 0xB2,
0xC4, 0x92, 0xD9, 0x77, 0xE1, 0x07, 0x38, 0x17, 0x74, 0x9A, 0xBA, 0xBF, 0x67, 0x02, 0x1A, 0xE2,
0x83, 0xA5, 0xA6, 0xD7, 0x6F, 0xA1, 0x33, 0x84, 0x8B, 0xAD, 0x85, 0xD2, 0x6A, 0xA9, 0xAA, 0x8C,
0x94, 0x0C, 0xAE, 0x50, 0x90, 0x95, 0xB4, 0x93, 0x9C, 0x09, 0x5B, 0x9F, 0x98, 0xCD, 0xB1, 0xE6,
0xF2, 0x57, 0x4E, 0x23, 0xCE, 0xFA, 0x2B, 0x97, 0xA2, 0x48, 0x8E, 0xCF, 0x40, 0x89, 0x3A, 0x91,
0x5F, 0x9B, 0x03, 0xF7, 0xF0, 0xBB, 0xEE, 0xF3, 0xFC, 0xDB, 0x06, 0x65, 0xE9, 0xBE, 0xF8, 0xFB,
0x16, 0xE5, 0x88, 0xC7, 0x51, 0x1E, 0x79, 0x80, 0xE3, 0x15, 0x7D, 0x32, 0xA4, 0xEB, 0xEA, 0x75,
0x42, 0xB0, 0xF1, 0x76, 0x22, 0xF6, 0x08, 0xD3, 0xDC, 0xB5, 0xF9, 0x41, 0x81, 0xFE, 0x0D, 0xDA,
0xD8, 0xC5, 0xC6, 0xE0, 0xE7, 0x3C, 0x37, 0x60, 0xDD, 0x8A, 0xA7, 0xE8, 0xEF, 0xC9, 0xCA, 0xFF
};
I've removed useless table from my previous post.
Here is the decrypted BlueAngel 1.06 radio ROM.
henrylim I don't have Magician so I cannot make any tools for it.
One note. Do not ask me for the compiled versions of these tools, nor ask for writing the unlocker for BlueAngel. I'll ignore such posts.
After the download, Wht do i need to do?
weasley said:
After the download, Wht do i need to do?
Click to expand...
Click to collapse
Dumb question. Why have you downloaded a file if you don't know how to use it?
I just bought a xda iis and wish to upgrade the rom to chinese but i got a radion sum error when i start the upgrade. so could you kindly advise me what to do?
weasley said:
I just bought a xda iis and wish to upgrade the rom to chinese but i got a radion sum error when i start the upgrade. so could you kindly advise me what to do?
Click to expand...
Click to collapse
you should ask in "BlueAngel upgrading" forum. There may be 2 reasons for this:
1. Archive is broken. You should redownload the update. And make sure that you are not installing the Himalaya ROM on BlueAngel.
2. Something is wrong with your PC. Try the upgrade on different PC.
Or you may keep the old radio and upgrade everything else.
hi mamaich,
is there any tool like an updated version of xda3nbftool so that we can change the operator and country code for the new roms. pls help how modify the new roms using the new encryption method.
thanks
jeet
jeet said:
hi mamaich,
is there any tool like an updated version of xda3nbftool so that we can change the operator and country code for the new roms. pls help how modify the new roms using the new encryption method.
thanks
jeet
Click to expand...
Click to collapse
This would be great indeed.... If someone could make the time for this a lot of people would be most happy.
Hi mamaich,
you ARE genius... )))) perfect...
buzz
Ok, i dont quite get it, how do I decrypt.............naaaaaa just kidding :lol:
Damm, keep up the good work.
Whish i had more time to study this
Great post, and great work!
Thanks!
I am actually using a perl script, written by itsme...the array is the same.
My question: Is the process reversible?
If I would take a radio_.nbf (or better yet, a dump), decrypt it to nba using xda3nbftool, then decode it, edit it...and encode it again by reversing the script, would I get a valid encoded nba back?
Thanks again,
HapyGoat
You can reencrypt the file back. Of cause you'll need to reverse the table to do this. I did it and it worked. But be careful, you can kill the radio part of your device.
Thanks mamaich for experimenting! That is great news...
Did you use a radio dump or started with an original nbf file?
I've worked with original NBF
Has anyone been able to compile an easy-to-use executable? I don't have access to a C compiler, and I tried reprogramming it in PureBasic, but it still comes out totally garbled. I'm assuming the 256-byte decryption table is specific for that one encrypted ROM file.
Please help, I'm trying to compare Anansky's BigStorage hack on the Magicians and provide support to other language ROM files and future updates.
Thanks!
I've managed to compile a program based on mamaich's previous posts to read in the header of an encrypted ROM file to spit out the XOR key and the unencrypted header, but I don't understand the decryption of the actual ROM portion with the modified XOR. My programming skills are intermediate and this was actually my first attempt at C++ programming (well, the second half anyway).
I compiled the code using Bloodshed.net's Dev-C++ program (very nice and simple).
Can anyone help out with the rest to decrypt (and of course, re-encrypt) the latest ROMs, and to possibly inject the code into a new xda3nbftool?
Code:
/*
* $Id: base64.c,v 1.1.1.1 2001/10/04 00:16:06 andrewr Exp $
* modified by mamaich for HTC firmware
*/
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
static void base64_init(void);
static int base64_initialized = 0;
#define BASE64_VALUE_SZ 256
#define BASE64_RESULT_SZ 8192
int base64_value[BASE64_VALUE_SZ];
/*
* This is the original base64 decode table:
*
const char* base64_code = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
*/
/*
* BaUpgradeUt uses a modified alphabet:
*/
const char* base64_code = "yz98765432UVWXYZabcdKLMNOPQRSTopqrstuvwxefghijklmnABCDEFGHIJ10+/";
static void
base64_init(void)
{
int i;
for (i = 0; i < BASE64_VALUE_SZ; i++)
base64_value[i] = -1;
for (i = 0; i < 64; i++)
base64_value[(int) base64_code[i]] = i;
base64_value['='] = 0;
base64_initialized = 1;
}
char *
base64_decode(const char *p)
{
static char result[BASE64_RESULT_SZ];
int j;
int c;
long val;
if (!p)
return NULL;
if (!base64_initialized)
base64_init();
val = c = 0;
for (j = 0; *p && j + 4 < BASE64_RESULT_SZ; p++) {
unsigned int k = ((unsigned char) *p) % BASE64_VALUE_SZ;
if (base64_value[k] < 0)
continue;
val <<= 6;
val += base64_value[k];
if (++c < 4)
continue;
/* One quantum of four encoding characters/24 bit */
result[j++] = val >> 16; /* High 8 bits */
result[j++] = (val >> 8) & 0xff; /* Mid 8 bits */
result[j++] = val & 0xff; /* Low 8 bits */
val = c = 0;
}
result[j] = 0;
return result;
}
/* adopted from http://ftp.sunet.se/pub2/gnu/vm/base64-encode.c with adjustments */
const char *
base64_encode(const char *decoded_str)
{
static char result[BASE64_RESULT_SZ];
int bits = 0;
int char_count = 0;
int out_cnt = 0;
int c;
if (!decoded_str)
return decoded_str;
if (!base64_initialized)
base64_init();
while ((c = (unsigned char) *decoded_str++) && out_cnt < sizeof(result) - 5) {
bits += c;
char_count++;
if (char_count == 3) {
result[out_cnt++] = base64_code[bits >> 18];
result[out_cnt++] = base64_code[(bits >> 12) & 0x3f];
result[out_cnt++] = base64_code[(bits >> 6) & 0x3f];
result[out_cnt++] = base64_code[bits & 0x3f];
bits = 0;
char_count = 0;
} else {
bits <<= 8;
}
}
if (char_count != 0) {
bits <<= 16 - (8 * char_count);
result[out_cnt++] = base64_code[bits >> 18];
result[out_cnt++] = base64_code[(bits >> 12) & 0x3f];
if (char_count == 1) {
result[out_cnt++] = '=';
result[out_cnt++] = '=';
} else {
result[out_cnt++] = base64_code[(bits >> 6) & 0x3f];
result[out_cnt++] = '=';
}
}
result[out_cnt] = '\0'; /* terminate */
return result;
}
int main(int argc, char *argv[])
{
char In[0xFF],Ch;
FILE *SrcFile;
int i;
if (argc != 2)
{
printf("\nSyntax: HEADER <newROMfile>");
return 1;
}
if ((SrcFile=fopen(argv[1],"rb")) == NULL)
{
printf("\nCannot open %s",argv[1]);
return 1;
}
Ch=fgetc(SrcFile);
i=0;
while (Ch != 0x3D)
{
In[i]=(char)Ch;
Ch=fgetc(SrcFile);
i++;
}
In[i]=(char)Ch;
printf("\nHeader of %s:\n",argv[1]);
puts(base64_decode(In));
}
Output:
Code:
C:\>result.exe radio_.nbf
Header of radio_.nbf:
PM10C CDL__001 WWE 1.11.00 Magician 0
0 0 3bd9e0b4
Manich
I know you have had contact with the auther of the new tool, what I am not aware of is if you were able to help him work out the checksum of modifed type II rom.
This seems to be the problem he has when saving a type II rom.
this is source for a nodule that makes adbd runs as root instead of user 'shell'...
built and used on atrix, but much less useful than originally hoped..
The better alternative might be to destroy or modify adbd's ANDROID_PROPERTY_WORKSPACE env vbl...
(This post is in 'atrix 4g general' because noob users can't post to dev threads. mods please move as appropriate..)
Code:
/*
*/
#include <linux/module.h>
#include <linux/string.h>
#include <linux/sched.h>
int __init init_adbdroot(void)
{
struct task_struct *p;
struct cred *cr;
for_each_process(p) {
if ( strcmp(p->comm, "adbd") == 0 ) {
printk(KERN_INFO "adbdroot: Found %s %d\n", p->comm, p->pid);
cr = (struct cred *)p->real_cred;
cr->uid = cr->euid = cr->suid = cr->fsuid = 0;
cr = (struct cred *)p->cred;
cr->uid = cr->euid = cr->suid = cr->fsuid = 0;
return -EOWNERDEAD;
}
}
printk(KERN_INFO "adbdroot: Could not find adbd\n");
return -1;
}
MODULE_LICENSE("GPL");
module_init(init_adbdroot)
Was searching for Qualcomm drivers to throw at my Lumia. Same cpu and looks like it was written for PC Suite Mode. Actually there's Nokia stuff all over in the folder I downloaded. Found here http://searchcode.com/codesearch/view/42236209.
Code:
/* nokia.c -- Nokia Composite Gadget Driver
*
* Copyright (C) 2008-2010 Nokia Corporation
* Contact: Felipe Balbi <[email protected]>
*
* This gadget driver borrows from serial.c which is:
*
* Copyright (C) 2003 Al Borchers ([email protected])
* Copyright (C) 2008 by David Brownell
* Copyright (C) 2008 by Nokia Corporation
*
* This software is distributed under the terms of the GNU General
* Public License ("GPL") as published by the Free Software Foundation,
* version 2 of that License.
*/
#include <linux/kernel.h>
#include <linux/utsname.h>
#include <linux/device.h>
#include "u_serial.h"
#include "u_ether.h"
#include "u_phonet.h"
#include "gadget_chips.h"
/* Defines */
#define NOKIA_VERSION_NUM 0x0211
#define NOKIA_LONG_NAME "N900 (PC-Suite Mode)"
/*-------------------------------------------------------------------------*/
/*
* Kbuild is not very cooperative with respect to linking separately
* compiled library objects into one module. So for now we won't use
* separate compilation ... ensuring init/exit sections work to shrink
* the runtime footprint, and giving us at least some parts of what
* a "gcc --combine ... part1.c part2.c part3.c ... " build would.
*/
#include "composite.c"
#include "usbstring.c"
#include "config.c"
#include "epautoconf.c"
#include "u_serial.c"
#include "f_acm.c"
#include "f_ecm.c"
#include "f_obex.c"
#include "f_serial.c"
#include "f_phonet.c"
#include "u_ether.c"
/*-------------------------------------------------------------------------*/
#define NOKIA_VENDOR_ID 0x0421 /* Nokia */
#define NOKIA_PRODUCT_ID 0x01c8 /* Nokia Gadget */
/* string IDs are assigned dynamically */
#define STRING_MANUFACTURER_IDX 0
#define STRING_PRODUCT_IDX 1
#define STRING_DESCRIPTION_IDX 2
static char manufacturer_nokia[] = "Nokia";
static const char product_nokia[] = NOKIA_LONG_NAME;
static const char description_nokia[] = "PC-Suite Configuration";
static struct usb_string strings_dev[] = {
[STRING_MANUFACTURER_IDX].s = manufacturer_nokia,
[STRING_PRODUCT_IDX].s = NOKIA_LONG_NAME,
[STRING_DESCRIPTION_IDX].s = description_nokia,
{ } /* end of list */
};
static struct usb_gadget_strings stringtab_dev = {
.language = 0x0409, /* en-us */
.strings = strings_dev,
};
static struct usb_gadget_strings *dev_strings[] = {
&stringtab_dev,
NULL,
};
static struct usb_device_descriptor device_desc = {
.bLength = USB_DT_DEVICE_SIZE,
.bDescriptorType = USB_DT_DEVICE,
.bcdUSB = __constant_cpu_to_le16(0x0200),
.bDeviceClass = USB_CLASS_COMM,
.idVendor = __constant_cpu_to_le16(NOKIA_VENDOR_ID),
.idProduct = __constant_cpu_to_le16(NOKIA_PRODUCT_ID),
/* .iManufacturer = DYNAMIC */
/* .iProduct = DYNAMIC */
.bNumConfigurations = 1,
};
/*-------------------------------------------------------------------------*/
/* Module */
MODULE_DESCRIPTION("Nokia composite gadget driver for N900");
MODULE_AUTHOR("Felipe Balbi");
MODULE_LICENSE("GPL");
Wow. Looks interesting. Will look through it tommorow.
Don't really know whether it's useful, as I'm not a developer, but this smells like possibility of ANDROID (lol) for Lumia.
Well, N900...
"Nokia composite gadget driver for N900"
ice8lue said:
Well, N900...
"Nokia composite gadget driver for N900"
Click to expand...
Click to collapse
Yes N900 driver in the kernel for a Sony Experia running Android on the same chip used in most Lumias if I am not mistaken. In the right hands maybe useful, maybe not, but thought it interesting....
Hmmm maybe a little closer to a way to flashing unsigned firmware updates?
I hope I've brought something useful here.
I figured out how to load mDNIe color profiles from sdcard.
So this I found out so far:
1. you have to be rooted;
2. profiles MUST be placed in /sdcard/mdnie folder;
3. profile is a text file and can be edited with any text editor;
4. file name is irrelevant ;
5. you have to edit two titles inside profile file to correspond to profile, you're going to override, eg. you're using AMOLED cinema mode. It's internal name is DYNAMIC_UI, so titles inside profile should be DYNAMIC_UI_1 for longer array and DYNAMIC_UI_2 for shorter one.
The whole list of model with corresponding internal names:
AMOLED cinema mode - DYNAMIC_UI;
AMOLED photo - STANDARD_UI;
Basic - NATURAL_UI;
6. first lines (bytes) of arrays are special marks (0xEC and 0xEB) and should not be touched;
7. to enable profile you have to write into /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning:
echo 1 > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning
echo "profile file name without path and spaces" > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning
8. PROFILE WILL RESET AFTER SCREEN OFF/ON CYCLE. For now I'm using Tasker to refresh it on screen on event. Maybe later we'll figure out some more elegant way;
UPDATE:
Written a small app for PC to tune colors through ADB. Useful for displaying some fullscreen test picture on device and drag sliders on PC to see effect (if any).
Profile structure description is in 2nd post.
That's it by now. There are comments from kernel source, but not too much descriptive (attached here).
I'd extracted and formated properly some major profiles. Attaching them here. Now we need to play allot with them to find out what each byte is doing exactly.
All profiles attached here have matching line numbers. I suggest to keep this pattern, so it will allow us to refer particular byte by line number while discussing here.
Profile bytes with description:
Description will be updated as figured out.
Code:
1 : BYPASS_2
2 : {
3 : 0xEB,
4 : 0x01, /* mdnie_en */
5 : 0x00, /* data_width mask 00 0000 */
6 : 0x00, /* ascr_roi 1 ascr 00 1 0 */ (only odd values 1-155, affects lines 132-155)
7 : 0x02, /* algo_roi 1 algo lce_roi 1 lce 00 1 0 00 1 0 */
8 : 0x00, /* roi_ctrl 00 */
9 : 0x00, /* roi0_x_start 12 */
10 : 0x00,
11 : 0x00, /* roi0_x_end */
12 : 0x00,
13 : 0x00, /* roi0_y_start */
14 : 0x00,
15 : 0x00, /* roi0_y_end */
16 : 0x00,
17 : 0x00, /* roi1_x_strat */
18 : 0x00,
19 : 0x00, /* roi1_x_end */
20 : 0x00,
21 : 0x00, /* roi1_y_start */
22 : 0x00,
23 : 0x00, /* roi1_y_end */
24 : 0x00,
25 : };
26 : BYPASS_1
27 : {
28 : 0xEC,
29 : 0x18, /* lce_on 0 lce_gain 0 0 00 0000 */
30 : 0x24, /* lce_color_gain 00 0000 */
31 : 0x10, /* lce_scene_change_on scene_trans 0 0000 */
32 : 0x14, /* lce_min_diff */
33 : 0xb3, /* lce_illum_gain */
34 : 0x01, /* lce_ref_offset 9 */
35 : 0x0e,
36 : 0x01, /* lce_ref_gain 9 */
37 : 0x00,
38 : 0x66, /* lce_block_size h v 0000 0000 */
39 : 0xfa, /* lce_bright_th */
40 : 0x2d, /* lce_bin_size_ratio */
41 : 0x03, /* lce_dark_th 000 */
42 : 0x96, /* lce_min_ref_offset */
43 : 0x00, /* nr sharp cs gamma 0000 */ (unsharpen mask radius (0-15))
44 : 0xff, /* nr_mask_th */ (unsharpen mask threshold)
45 : 0x00, /* sharpen_weight 10 */ (unsharpen mask strength (0-199))
46 : 0x00,
47 : 0x07, /* sharpen_maxplus 11 */
48 : 0xff,
49 : 0x07, /* sharpen_maxminus 11 */
50 : 0xff,
51 : 0x01, /* cs_gain 10 */
52 : 0x00,
53 : 0x00, /* curve_1_b */
54 : 0x20, /* curve_1_a */
55 : 0x00, /* curve_2_b */
56 : 0x20, /* curve_2_a */
57 : 0x00, /* curve_3_b */
58 : 0x20, /* curve_3_a */
59 : 0x00, /* curve_4_b */
60 : 0x20, /* curve_4_a */
61 : 0x00, /* curve_5_b */
62 : 0x20, /* curve_5_a */
63 : 0x00, /* curve_6_b */
64 : 0x20, /* curve_6_a */
65 : 0x00, /* curve_7_b */
66 : 0x20, /* curve_7_a */
67 : 0x00, /* curve_8_b */
68 : 0x20, /* curve_8_a */
69 : 0x00, /* curve_9_b */
70 : 0x20, /* curve_9_a */
71 : 0x00, /* curve10_b */
72 : 0x20, /* curve10_a */
73 : 0x00, /* curve11_b */
74 : 0x20, /* curve11_a */
75 : 0x00, /* curve12_b */
76 : 0x20, /* curve12_a */
77 : 0x00, /* curve13_b */
78 : 0x20, /* curve13_a */
79 : 0x00, /* curve14_b */
80 : 0x20, /* curve14_a */
81 : 0x00, /* curve15_b */
82 : 0x20, /* curve15_a */
83 : 0x00, /* curve16_b */
84 : 0x20, /* curve16_a */
85 : 0x00, /* curve17_b */
86 : 0x20, /* curve17_a */
87 : 0x00, /* curve18_b */
88 : 0x20, /* curve18_a */
89 : 0x00, /* curve19_b */
90 : 0x20, /* curve19_a */
91 : 0x00, /* curve20_b */
92 : 0x20, /* curve20_a */
93 : 0x00, /* curve21_b */
94 : 0x20, /* curve21_a */
95 : 0x00, /* curve22_b */
96 : 0x20, /* curve22_a */
97 : 0x00, /* curve23_b */
98 : 0x20, /* curve23_a */
99 : 0x00, /* curve24_b */
100 : 0xff, /* curve24_a */
101 : 0x20, /* ascr_skin_on strength 0 00000 */
102 : 0x67, /* ascr_skin_cb */
103 : 0xa9, /* ascr_skin_cr */
104 : 0x0c, /* ascr_dist_up */
105 : 0x0c, /* ascr_dist_down */
106 : 0x0c, /* ascr_dist_right */
107 : 0x0c, /* ascr_dist_left */
108 : 0x00, /* ascr_div_up 20 */
109 : 0xaa,
110 : 0xab,
111 : 0x00, /* ascr_div_down */
112 : 0xaa,
113 : 0xab,
114 : 0x00, /* ascr_div_right */
115 : 0xaa,
116 : 0xab,
117 : 0x00, /* ascr_div_left */
118 : 0xaa,
119 : 0xab,
120 : 0xff, /* ascr_skin_Rr */
121 : 0x00, /* ascr_skin_Rg */
122 : 0x00, /* ascr_skin_Rb */
123 : 0xff, /* ascr_skin_Yr */
124 : 0xff, /* ascr_skin_Yg */
125 : 0x00, /* ascr_skin_Yb */
126 : 0xff, /* ascr_skin_Mr */
127 : 0x00, /* ascr_skin_Mg */
128 : 0xff, /* ascr_skin_Mb */
129 : 0xff, /* ascr_skin_Wr */
130 : 0xff, /* ascr_skin_Wg */
131 : 0xff, /* ascr_skin_Wb */
132 : 0x00, /* ascr_Cr */ red in cyan
133 : 0xff, /* ascr_Rr */ red in red
134 : 0xff, /* ascr_Cg */ green in cyan
135 : 0x00, /* ascr_Rg */ green in red
136 : 0xff, /* ascr_Cb */ blue in cyan
137 : 0x00, /* ascr_Rb */ blue in red
138 : 0xff, /* ascr_Mr */ red in magenta
139 : 0x00, /* ascr_Gr */ red in green
140 : 0x00, /* ascr_Mg */ green in magenta
141 : 0xff, /* ascr_Gg */ green in green
142 : 0xff, /* ascr_Mb */ blue in magenta
143 : 0x00, /* ascr_Gb */ blue in green
144 : 0xff, /* ascr_Yr */ red in yellow
145 : 0x00, /* ascr_Br */ red in blue
146 : 0xff, /* ascr_Yg */ green in yellow
147 : 0x00, /* ascr_Bg */ green in blue
148 : 0x00, /* ascr_Yb */ blue in yellow
149 : 0xff, /* ascr_Bb */ blue in blue
150 : 0xff, /* ascr_Wr */ red in white
151 : 0x00, /* ascr_Kr */ red in black
152 : 0xff, /* ascr_Wg */ green in white
153 : 0x00, /* ascr_Kg */ green in black
154 : 0xff, /* ascr_Wb */ blue in white
155 : 0x00, /* ascr_Kb */ blue in black
156 : };
Hey, this looks useful.
Do you mind if I incorporate a variation of this into my SkyHigh kernel. Just an idea ATM to make it Synapse compatible and switchable etc. I'm sure it's doable
Won't be able to try for a few weeks though, still away and have some other kernel commitments on my return
Sent from my SM-N9005 using XDA Premium 4 mobile app
UpInTheAir said:
Hey, this looks useful.
Do you mind if I incorporate a variation of this into my SkyHigh kernel. Just an idea ATM to make it Synapse compatible and switchable etc. I'm sure it's doable
Won't be able to try for a few weeks though, still away and have some other kernel commitments on my return
Sent from my SM-N9005 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Actually, there is nothing here to do with kernel, stock kernel is already capable of loading profiles.
On the other hand, to load profile I do use Tasker so as for reloading on every screen on, 'cause it gets reset every time.
And I do understand that not every user can handle this with such creepy app like Tasker.
So implementing some easy way to handle choosing/loading/reloading plofiles sounds really useful.
The method and app I introduced here are only a comfortable way to investigate a profile structure and build a fine tuned, personolized profile for a particular display and taste. Further usage of that profile yet needs to be developed.
heyjoe66 said:
Actually, there is nothing here to do with kernel, stock kernel is already capable of loading profiles.
On the other hand, to load profile I do use Tasker so as for reloading on every screen on, 'cause it gets reset every time.
And I do understand that not every user can handle this with such creepy app like Tasker.
So implementing some easy way to handle choosing/loading/reloading plofiles sounds really useful.
The method and app I introduced here are only a comfortable way to investigate a profile structure and build a fine tuned, personolized profile for a particular display and taste. Further usage of that profile yet needs to be developed.
Click to expand...
Click to collapse
Yes, I understand that. I wish to add the control into Synapse, no need for scripts or other apps, that's all
I do have control for similar with my Note 3 kernel. I just might try implement some of it, stock or not.
Sent from my SM-N9005 using XDA Premium 4 mobile app
Ok, let me be the first who admits it, I have no glue how to calibrate the screen with your tools. Could you post a step by step guide or even Youtube video? That would be awesome.
Hi,
There is an application on the PlayStore : ColorTRUE
A workmate has the Colormonki Display calibration tool.
I will ask him share it to see how it works and if I can make a "real life" calibrated color screen.
Orphee said:
Hi,
There is an application on the PlayStore : ColorTRUE
A workmate has the Colormonki Display calibration tool.
I will ask him share it to see how it works and if I can make a "real life" calibrated color screen.
Click to expand...
Click to collapse
Hi,
(from app description)
Look for other ColorTRUE Aware Apps
Unlike your laptop or desktop operating system, Android mobile apps do not have system wide color management capabilities. Therefore, each app must apply color profiles individually. For this reason, X-Rite has created the ColorTRUE Aware Partner Program. We are currently collaborating with other app developers to allow them to seamlessly access your ColorTRUE profile so any app can display colors accurately and consistently. ColorTRUE Aware apps will be color managed once you create a profile with ColorTRUE. Just look for the ColorTRUE Aware logo for compatibility.
Click to expand...
Click to collapse
Looks like it doesn't use mdnie.
heyjoe66 said:
Hi,
(from app description)
Looks like it doesn't use mdnie.
Click to expand...
Click to collapse
You are right, I tried the display calibration tool, it only works in X-rite app.
I don't know if it can help, but I extracted ICC profile from data application.
mDNIe is quite obscure for me...
Edit : There is a tool to open ICC profiles here : http://www.color.org/profileinspector.xalter
Orphee said:
You are right, I tried the display calibration tool, it only works in X-rite app.
I don't know if it can help, but I extracted ICC profile from data application.
mDNIe is quite obscure for me...
Edit : There is a tool to open ICC profiles here : http://www.color.org/profileinspector.xalter
Click to expand...
Click to collapse
Not sure if I know what to do with this. I can see some values in the Profile Explorer you provided, but I have no idea, what threy mean.
I tried to read a bit about ICC, like here and here, but seriously, that's too much new info for me right now.
The most terrible thing about color here that bothers me is that color reproduction is heavily depend on screen brightness. With low brightness level grayscale goes totally green. I think I'll try to implement some callback for brightness changes in mdnie in kernel and apply some color correction there. Have no idea, how I'm gonna do that, but I'll try.
Do you want me to do a titanium backup of X-rite ColorTrue to leave you try it (with it own gallery)
Orphee said:
Do you want me to do a titanium backup of X-rite ColorTrue to leave you try it (with it own gallery)
Click to expand...
Click to collapse
Well, thanks indeed, but what I'm saying is that I have no idea how to correlate values from ICC with mdnie values. I don't know what values in ICC profile mean, some kind of coordinates of base RGB colors on some colorspace. I don't know how to translate them into values like red-in-black, red-in-green, red-in-white.
That's what problem is.
If you know anything about ICC profile structure, if can somehow describe all that values to me, maybe then we could figure out something to do with all that.
heyjoe66 said:
8. PROFILE WILL RESET AFTER SCREEN OFF/ON CYCLE. For now I'm using Tasker to refresh it on screen on event. Maybe later we'll figure out some more elegant way;
Click to expand...
Click to collapse
You can use a init.d script for profile reloading when screen is reactivated:
Code:
#!/system/bin/sh
(while [ 1 ]
do
AWAKE=`cat /sys/power/wait_for_fb_wake`
if [ $AWAKE = "awake" ]; then
echo 1 > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning;
echo "profile file name without path and spaces" > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning;
fi
SLEEPING=`cat /sys/power/wait_for_fb_sleep`
if [ $SLEEPING = "sleeping" ]; then
sleep 1
fi
done &)
It's nothing else than a modified screenstate scaling script, i use that on my S2 and it works very good.
regards,
lombartz
lombartz said:
You can use a init.d script for profile reloading when screen is reactivated:
Code:
#!/system/bin/sh
(while [ 1 ]
do
AWAKE=`cat /sys/power/wait_for_fb_wake`
if [ $AWAKE = "awake" ]; then
echo 1 > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning;
echo "profile file name without path and spaces" > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning;
fi
SLEEPING=`cat /sys/power/wait_for_fb_sleep`
if [ $SLEEPING = "sleeping" ]; then
sleep 1
fi
done &)
It's nothing else than a modified screenstate scaling script, i use that on my S2 and it works very good.
regards,
lombartz
Click to expand...
Click to collapse
Nice. That looks really useful. Sadly, these wait_for_fb_* attributes are missing on our device, or maybe moved to some place else. Need to look for them.
Regarding the problem you're referring to, it's actually a bug in samsung's code. They are trying to read profile from /sdcard when sdcard is not ready yet. I've fixed it in my own kernel build by moving the mdnie folder to /data. So now profile is updated as it meant to.
Can this be used to raise the gamma levels on the sm-t805 lollipop screen?
I have been playing around with this today but cant seem to get it to affect the color.
I have loaded up ABD, and loaded the DYNAMIC_UI profile into your little app but none of the sliders seem to affect anything on screen.
This is on a T800 running Cyanogenmod
Wow, I have a x-rite i1 display pro and it's working with color True application, can I load a profile at startup?
Astania said:
Wow, I have a x-rite i1 display pro and it's working with color True application, can I load a profile at startup?
Click to expand...
Click to collapse
Nope, thats not what this is for. I have the same piece of hardware but it only creates a profile that other apps can use if they support the x-rite sdk, such apps are nonexistent on Android except the x-rite app itself, and that app only works for displaying photos.
The mDNIe profiles are going to bare zero relation to the x-rite profiles so you cant use the x-rite profiles system wide even if you had the means.
I dont think there is enough dev backing on this to make it happen, but the ultimate goal would be to create a tool which is able to adjust the various settings of these profiles so it can be used in conjunction with a colorometer to create a color accurate profile that can be loaded up system wide.
Well, ICC profiles are universal standard, not only used by X-rite. X-rite is only making devices to measure color differences between the display and the standard.
So if you have another standard colour profile for display like mDNIe , you somehow must know what is a difference between a display you are profiling and standard, so you need a device to measure it.
Maybe there's a tool that can convert ICC to mDNIe profile?
It would be great to have possibility to turn on the display profiling at startup, especially that it can display wide range of AdobeRGB palette. ColorTrue app makes an ICC when you connect a profiler via USB and difference after and before profiling is huge. But profiles work only in the application, so it's not good.
Astania said:
Well, ICC profiles are universal standard, not only used by X-rite. X-rite is only making devices to measure color differences between the display and the standard.
So if you have another standard colour profile for display like mDNIe , you somehow must know what is a difference between a display you are profiling and standard, so you need a device to measure it.
Maybe there's a tool that can convert ICC to mDNIe profile?
It would be great to have possibility to turn on the display profiling at startup, especially that it can display wide range of AdobeRGB palette. ColorTrue app makes an ICC when you connect a profiler via USB and difference after and before profiling is huge. But profiles work only in the application, so it's not good.
Click to expand...
Click to collapse
Yup, I completely agree with what you are saying.
The screen on the Galaxy Tab S is really great, a very capable screen. But it's hampered by being locked to the few profiles Samsung provides.
Unfortunately mDNIe is a Samsung-only affair, and the tool posted earlier is full of sliders that seem to do nothing to the colour of the screen.
The profiles created by the X-Rite app are just a correction on top of a correction, this is fine and all as the chances of us getting low-level calibration seem non-existent, but there are no apps out whatsoever that actually use the X-Rite sdk (other than the x-rite app).
Without an advanced developer on board who knows all of this stuff inside out, I dont think we are going to get anywhere with conversion of mDNIe to ICC or anything like this.
The X-Rite app is great for photos, if there was any support for the X-Rite SDK in a video app this would be a good enough solution for me even if it is a correction on top of a correction, as colour accuracy in the OS is not important.
I have a Java Native Interface project that works. It is the helloJNI prototype. Now I want to use it to call the functions in the header file of a Device Driver. This DD is already in my image, and I see it in /dev folder. What I want to know if how do I call the device driver functions? Here is what I have in my JNI folder:
Code:
#include "com_example_sansari_usedevicedriver_MainActivity.h"
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
/*
* Class: com_example_sansari_usedevicedriver_MainActivity
* Method: useqseecom
* Signature: ()Ljava/lang/String;
*/
JNIEXPORT jstring JNICALL Java_com_example_sansari_usedevicedriver_MainActivity_UseQUALCOM
(JNIEnv *env, jobject obj)
{
(*env)->NewStringUTF(env,"Hi From UseDeviceDriver");
}
Below is the executable I created to interface with the device driver from the user space. It works. I am trying to see how do I add the code below to the JNI handle I have above. Where does the main function of my executable below fit in the above file?
[/CODE]
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
int main(int argc, char **argv)
{
/* Our file descriptor */
int fd;
int rc = 0;
char *rd_buf[16];
printf("<1>%s: entered\n", argv[0]);
/* Open the device */
fd = open("/dev/hello1", O_RDWR);
if ( fd == -1 ) {
perror("<1>open failed");
rc = fd;
exit(-1);
}
printf("<1>%s: open: successful\n", argv[0]);
/* Issue a read */
rc = read(fd, rd_buf, 0);
if ( rc == -1 ) {
perror("<1>read failed");
close(fd);
exit(-1);
}
printf("<1>%s: read: returning %d bytes!\n", argv[0], rc);
close(fd);
return 0;
}
[/CODE]