http://www.canyoucrackit.co.uk/
Not Evo related, but still fun. It's stage 1 of a challenge, that is said to be a GCHQ Recruitment Test.
I don't know why this is under the HTC Supersonic but here is the hex data, so you don't have to manually type it in yourself:
Code:
eb 04 af c2 bf a3 81 ec 00 01 00 00 31 c9 88 0c
0c fe c1 75 f9 31 c0 ba ef be ad de 02 04 0c 00
d0 c1 ca 08 8a 1c 0c 8a 3c 04 88 1c 04 88 3c 0c
fe c1 75 e8 e9 5c 00 00 00 89 e3 81 c3 04 00 00
00 5c 58 3d 41 41 41 41 75 43 58 3d 42 42 42 42
75 3b 5a 89 d1 89 e6 89 df 29 cf f3 a4 89 de 89
d1 89 df 29 cf 31 c0 31 db 31 d2 fe c0 02 1c 06
8a 14 06 8a 34 1e 88 34 06 88 14 1e 00 f2 30 f6
8a 1c 16 8a 17 30 da 88 17 47 49 75 de 31 db 89
d8 fe c0 cd 80 90 90 e8 9d ff ff ff 41 41 41 41
(I'll edit this post if you find any transcription errors)
Suspicious sequences are:
00 01 and 00 00 at offset 0x08
deadbeef at 0x18
5c 58 3d 41 41 41 41 75 43 58 3d 42 42 42 42 75 3b 5a ("\X=AAAAuCX=BBBBu;Z") at 0x41
47 49 75 at 0x89
41 41 41 41 ("AAAA") at 0x9c
ff ff ff at 0x99
00 00 00 at offset 0x36 and again at 0x3e
The first few bytes look like x86 assembly code. Trying http:/ stackoverflow.com/questions/1737095/how-do-i-disassemble-raw-x86-code (sorry, can't actually make that a link due to forum rules)
I think it's not 16-bit real mode code, so here's a static analysis of the code treated as ia32 linux code - because of the int $0x80 at the end.
Code:
objdump -D -b binary -mi386 (raw bytes here)
start:
0: eb 04 jmp 0x6
might_be_data1:
2: af scas %es:(%edi),%eax
3: c2 bf a3 ret $0xa3bf
init:
6: 81 ec 00 01 00 00 sub $0x100,%esp
c: 31 c9 xor %ecx,%ecx
search_for_zero_byte:
e: 88 0c 0c mov %cl,(%esp,%ecx,1)
11: fe c1 inc %cl
13: 75 f9 jne 0xe
15: 31 c0 xor %eax,%eax
17: ba ef be ad de mov $0xdeadbeef,%edx
checksum_loop:
1c: 02 04 0c add (%esp,%ecx,1),%al
1f: 00 d0 add %dl,%al
21: c1 ca 08 ror $0x8,%edx ; first time through, %edx = $0xdeadbe
24: 8a 1c 0c mov (%esp,%ecx,1),%bl
27: 8a 3c 04 mov (%esp,%eax,1),%bh
2a: 88 1c 04 mov %bl,(%esp,%eax,1) ; swap byte values
2d: 88 3c 0c mov %bh,(%esp,%ecx,1) ; swap byte values
30: fe c1 inc %cl ; run the loop until %cl wraps to 0
32: 75 e8 jne 0x1c
34: e9 5c 00 00 00 jmp 0x95
sub_39:
39: 89 e3 mov %esp,%ebx
3b: 81 c3 04 00 00 00 add $0x4,%ebx
41: 5c pop %esp
42: 58 pop %eax
43: 3d 41 41 41 41 cmp $0x41414141,%eax
48: 75 43 jne 0x8d
4a: 58 pop %eax
4b: 3d 42 42 42 42 cmp $0x42424242,%eax
50: 75 3b jne 0x8d
52: 5a pop %edx
53: 89 d1 mov %edx,%ecx
55: 89 e6 mov %esp,%esi
57: 89 df mov %ebx,%edi
59: 29 cf sub %ecx,%edi
5b: f3 a4 rep movsb %ds:(%esi),%es:(%edi)
5d: 89 de mov %ebx,%esi
5f: 89 d1 mov %edx,%ecx
61: 89 df mov %ebx,%edi
63: 29 cf sub %ecx,%edi
65: 31 c0 xor %eax,%eax
67: 31 db xor %ebx,%ebx
69: 31 d2 xor %edx,%edx
6b: fe c0 inc %al
6d: 02 1c 06 add (%esi,%eax,1),%bl
70: 8a 14 06 mov (%esi,%eax,1),%dl
73: 8a 34 1e mov (%esi,%ebx,1),%dh
76: 88 34 06 mov %dh,(%esi,%eax,1)
79: 88 14 1e mov %dl,(%esi,%ebx,1)
7c: 00 f2 add %dh,%dl
7e: 30 f6 xor %dh,%dh
80: 8a 1c 16 mov (%esi,%edx,1),%bl
83: 8a 17 mov (%edi),%dl
85: 30 da xor %bl,%dl
87: 88 17 mov %dl,(%edi)
89: 47 inc %edi
8a: 49 dec %ecx
8b: 75 de jne 0x6b
8d: 31 db xor %ebx,%ebx
8f: 89 d8 mov %ebx,%eax
91: fe c0 inc %al
93: cd 80 int $0x80
95: 90 nop
96: 90 nop
97: e8 9d ff ff ff call 0x39
9c: 41 inc %ecx
9d: 41 inc %ecx
9e: 41 inc %ecx
9f: 41 inc %ecx
X=AAAAuCX=BBBBu;
Before i found this page, i wrote a little tool to convert hex into a readable string in pascal..
s:=#$E3+#$81+#$C3+#$04+#$00+#$00+#$00+'\X=AAAAuCX=BBBBu;Z'+#$89+#$D1+#$89+#$E6+#$89+#$DF+')'+#$CF+#$F3+#$A4+#$89+#$DE+#$89+#$D1+#$89+#$DF+')'+#$CF+'1'+#$C0+'1'+#$DB+'1'+#$D2+#$FE+#$C0+#$02+#$1C+#$06+#$8A+#$14+#$06+#$8A+'4'+#$1E+#$88+'4'+#$06+#$99+#$14+#$1E+#$00+#$F2+'0'+#$F6+#$8A+#$1C+#$16+#$8A+#$17+'0'+#$DA+#$88+#$17+'GIu'+#$DE+'1'+#$DB+#$89+#$D8+#$FE+#$C0+#$CD+#$80+#$90+#$90+#$EB+#$9D+#$FF+#$FF+#$FF+'AAAA';
and manually typed in every hex value.. before finding this site.
anyway (annoyed wasting that 20 minutes now)
\X=AAAAuCX=BBBBu;Z
That looks like a cookie?
let's suppose they are opcodes, this does not look like 0x86 have you tried a 16bit disassembler mode?
Question, is this disassemble code? or is this a captured packet? or a packet made to look like either but instead is just random crap generated by a program with a unique identifier that can be decoded...
some clue would be nice...
---------- Post added at 08:15 PM ---------- Previous post was at 08:05 PM ----------
oh and could someone move this thread? it's got nothing to do with htc lol
Here you go :-
www.canyoucrackit.co.uk/soyoudidit.asp
Sent from my GT-S5570 using xda premium
lol, that's just cheating, forget brute force, bruteforce the http request strings to find page you get sent to if you get the answer ...
shakes head, they spent all that time and they never even bothered to stop to consider producing a link on the fly after getting the answer right then deleting the computer generated webpage (tmp file)...
they need help after all! no wonder they're in need of hackers christ....
Anyway thanks for that link, but the answer would be nice, i guess we'll found out soon enough
Cheers!
So i got it.
Passphrase: Pr0t3ct!on#[email protected]*12.2011+
solution to part #1 of canyoucrackit
part2.h will be published along with solutions to the subsequent levels after 12 December 2011
#include <stdio.h>
#include <stdint.h>
#include <malloc.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include <time.h>
#include <sys/types.h>
#include <sys/mman.h>
#include <sys/utsname.h>
#include "part2.h" // see information above
static char part1[] = {
0xeb, 0x04, 0xaf, 0xc2, 0xbf, 0xa3, 0x81, 0xec, 0x00, 0x01, 0x00, 0x00, 0x31, 0xc9, 0x88, 0x0c,
0x0c, 0xfe, 0xc1, 0x75, 0xf9, 0x31, 0xc0, 0xba, 0xef, 0xbe, 0xad, 0xde, 0x02, 0x04, 0x0c, 0x00,
0xd0, 0xc1, 0xca, 0x08, 0x8a, 0x1c, 0x0c, 0x8a, 0x3c, 0x04, 0x88, 0x1c, 0x04, 0x88, 0x3c, 0x0c,
0xfe, 0xc1, 0x75, 0xe8, 0xe9, 0x5c, 0x00, 0x00, 0x00, 0x89, 0xe3, 0x81, 0xc3, 0x04, 0x00, 0x00,
0x00, 0x5c, 0x58, 0x3d, 0x41, 0x41, 0x41, 0x41, 0x75, 0x43, 0x58, 0x3d, 0x42, 0x42, 0x42, 0x42,
0x75, 0x3b, 0x5a, 0x89, 0xd1, 0x89, 0xe6, 0x89, 0xdf, 0x29, 0xcf, 0xf3, 0xa4, 0x89, 0xde, 0x89,
0xd1, 0x89, 0xdf, 0x29, 0xcf, 0x31, 0xc0, 0x31, 0xdb, 0x31, 0xd2, 0xfe, 0xc0, 0x02, 0x1c, 0x06,
0x8a, 0x14, 0x06, 0x8a, 0x34, 0x1e, 0x88, 0x34, 0x06, 0x88, 0x14, 0x1e, 0x00, 0xf2, 0x30, 0xf6,
0x8a, 0x1c, 0x16, 0x8a, 0x17, 0x30, 0xda, 0x88, 0x17, 0x47, 0x49, 0x75, 0xde, 0x31, 0xdb, 0x89,
0xd8, 0xfe, 0xc0, 0xcd, 0x80, 0x90, 0x90, 0xe8, 0x9d, 0xff, 0xff, 0xff, 0x41, 0x41, 0x41, 0x41,
};
// code to dump the decrypted memory:
static const char dump_mem[] = {
0xba, 0x31, 0x00, 0x00, 0x00, // mov edx, 0x40
0x8d, 0x4f, 0xce, // lea ecx, [edi-0x32]
0x31, 0xdb, // xor ebx, ebx
0x43, // inc ebx (stdout)
0x31, 0xc0, // xor eax, eax
0xb0, 0x04, // add al, 0x4 - sys_write
0xcd, 0x80, // int 0x80
0x31, 0xdb, // xor ebx,ebx
0x43, // inc ebx
0x31, 0xd2, // xor edx,edx
0x42, // inc edx
0x68, 0x0a, 0x00,0x00, 0x00, // push 0xa
0x8d, 0x0c, 0x24, // lea ecx,[esp]
0xb8, 0x04, 0x00,0x00, 0x00, // mov eax, 0x4
0xcd, 0x80, // int 0x80 - sys_write
0x31, 0xdb, // xor ebx,ebx
0x31, 0xc0, // xor eax,eax
0x40, // inc eax
0xcd, 0x80, // int 0x80 - sys_exit
};
uint32_t patch_mem(char *ptr, size_t size)
{
uint32_t i;
for (i = 0; i < size; i++) {
if (*(uint16_t *)&ptr == 0x80cd) {
*(uint16_t *)&ptr = 0x45eb;
return 0;
}
}
return 1;
}
uint32_t check_arch(void)
{
struct utsname kernel_info;
uname(&kernel_info);
return strcmp(kernel_info.machine, "i686") ? 1 : 0;
}
int main(int argc, char **argv)
{
void *mem;
if (check_arch()) {
printf("[-] this program must run on a 32-bit architecture\n");
return 1;
}
printf("[*] allocating page aligned memory\n");
mem = memalign(4096, 4096);
if (!mem) {
printf("[-] error: %s\n", strerror(errno));
return 1;
}
memset(mem, 0, 4096);
printf("[*] setting page permissions\n");
if (mprotect(mem, 4096, PROT_READ | PROT_WRITE | PROT_EXEC)) {
printf("[-] error: %s\n", strerror(errno));
return 1;
}
printf("[*] copying payload\n");
memcpy(mem, part1, sizeof(part1));
memcpy(mem + sizeof(part1), part2, sizeof(part2));
memcpy(mem + sizeof(part1) + sizeof(part2), dump_mem, sizeof(dump_mem));
printf("[*] adding dump_mem payload\n");
if (patch_mem(mem, sizeof(part1))) {
printf("[-] failed to patch memory\n");
return 0;
}
printf("[*] executing payload..\n\n");
((int(*)(void))mem)();
return 0;
}
CHEERS
Craig Capel said:
lol, that's just cheating, forget brute force, bruteforce the http request strings to find page you get sent to if you get the answer ...
shakes head, they spent all that time and they never even bothered to stop to consider producing a link on the fly after getting the answer right then deleting the computer generated webpage (tmp file)...
they need help after all! no wonder they're in need of hackers christ....
Anyway thanks for that link, but the answer would be nice, i guess we'll found out soon enough
Cheers!
Click to expand...
Click to collapse
Pr0t3ct!on#[email protected]*12.2011+
that's the answer
But easy way to do it.... just use ip scaner...and put the adress below... then you see many updates in adress...2 hours of reading...but i found it
Sorry for my bad English ...
CHEERS
thx. Interesting way to learn how this works without visiting strange sites...
(although it does not seem to fit this forums purpose)
Related
OK, I know that global subclassing of windows is formally not supported. However, I have a few ideas of how to do it. First, I was wondering if anyone knows whether or not the internal window structure is similar to the internal structure used on Windows NT.
Also, I was wondering if anyone knows how to locate the internal window table. I figure that it's contained somewhere in GWES as it contains the USER functions. I've been researching CreateWindowEx, but I haven't been able to land on anything specific.
Thanks!
Here is info that I've digged in last 10 minutes. It can be incorrect.
chmckay said:
First, I was wondering if anyone knows whether or not the internal window structure is similar to the internal structure used on Windows NT.
Click to expand...
Click to collapse
It is completely different.
As far as I've seen from coredll decompilation the HWND is internally translated to internal CWindow class by an internal "static CWindow* CWindow::coredllPwndFromHwnd(HWND__*)" function defined in twinuser.obj file in thunks.lib in PlatformBuilder. I've dumped it from a COREDLL.PDB file from old PlatformBuilder 4.0beta. Here is it, cleaned from unnecessary function prototypes:
Code:
struct CWindow
{
struct CWindow* m_pcwndNext;
struct CWindow* m_pcwndParent;
struct CWindow* m_pcwndChild;
unsigned m_sig;
struct CWindow* m_pcwndOwner;
struct CWindow* m_pcwndOwned;
struct CWindow* m_pcwndNextOwned;
struct CWindow* m_pcwndRestore;
struct tagRECT m_rc;
struct tagRECT m_rcClient;
void* m_pgdiwnd;
void* m_pgdiwndClient;
void* m_pgdiwndClientUpdate;
struct tagRECT m_rcRestore;
struct _GENTBL* m_ptblProperties;
unsigned m_dwState;
struct ScrollBarInfoInternal* m_psbii;
DWORD* m_pszName;
struct MsgQueue* m_pmsgq;
DWORD m_himc;
unsigned m_grfStyle;
unsigned m_grfExStyle;
struct CWindowClass* m_pwc;
long m_lID;
long m_lUserData;
void* m_hprcCreator;
void* m_hthdCreator;
void* m_hprcWndProc;
int (*m_pfnWndProc)(HWND__*, DWORD, DWORD, int);
struct HRGN__* m_hrgnWindowRgn;
struct HRGN__* m_hrgnVisible;
struct HRGN__* m_hrgnUpdate;
struct HRGN__* m_hrgnClientVisible;
struct HRGN__* m_hrgnClientUpdate;
struct HMENU__* m_hmenu;
void* m_hprcDestroyer;
struct CWindow::__unnamed::__unnamed m;
unsigned m_grfBitFields;
DWORD m_rgdwExtraBytes[0];
};
The structure may have been changed in the current version of OS.
The code of coredllPwndFromHwnd() function taken from iMate 1.72 ROM:
Code:
.text:01F6E65C sub_1F6E65C ; COD
.text:01F6E65C ; sub
.text:01F6E65C 10 40 2D E9 STMFD SP!, {R4,LR}
.text:01F6E660 FE 24 C0 E3 BIC R2, R0, #0xFE000000
.text:01F6E664 2C 00 9F E5 LDR R0, =unk_1FC65AC ; this is a "g_dwGwesBase" variable
.text:01F6E668 00 10 90 E5 LDR R1, [R0]
.text:01F6E66C 01 40 82 E0 ADD R4, R2, R1
.text:01F6E670 1C 10 9F E5 LDR R1, =0x574E4457 ; Magic value? It is in m_sig member.
.text:01F6E674 0C 00 94 E5 LDR R0, [R4,#0xC]
.text:01F6E678 01 00 50 E1 CMP R0, R1
.text:01F6E67C 57 0E A0 13 MOVNE R0, #0x570
.text:01F6E680 08 00 80 13 ORRNE R0, R0, #8
.text:01F6E684 00 40 A0 13 MOVNE R4, #0
.text:01F6E688 72 0C 00 1B BLNE SetLastError
.text:01F6E68C 04 00 A0 E1 MOV R0, R4
.text:01F6E690 10 80 BD E8 LDMFD SP!, {R4,PC}
I can upload somewhere the complete dump of all structures from coredll, gwes, nk. But they are taken form old PlatformBuilder, because latest version has this data removed from PDB files.
I don't know the address that containf the head of this linked list, but probably it starts from the desktop window. So you can get CWindow of desktop and enumerate windows with m_pcwndNext/m_pcwndChild members.
The other problem is that we cannot determine the g_dwGwesBase value that is added to HWND to determine CWindow pointer.
One idea. You can try "GetWindowLong" to get data from CWindow structure. But its predefined offsets look very strange.
Mamaich,
Thank you VERY much. That was just the information I needed! I've managed to locate the class information and successfully subclass a window globally on the emulator (my cradle is at home, so I can't test this on my device).
Here's what I've learned that you might be interested in:
the g_dwGwesBase variable is actually a pointer to the virtual memory location of gwes.exe. Also, the 0xfe000000 value is specific to the processor. In this case, the value is (hwnd & ~0xfe000000), while on the x86/emulator platform, it is (hwnd & 0x1fffffff). I don't have access to the MIPS or SH3 libraries (as I don't have a full copy of Platform Builder).
Anyway, this is what the coredllPwndFromHwnd() function amounts to:
DWORD *wnd = (hwnd & ~0xfe000000) + g_dwGwesBase;
if( wnd[3] == 0x574e4457 )
return wnd;
else {
SetLastError(0x578);
return NULL;
}
The 0x574e4457 is not processor specific (as it appears in the x86 libs). Also, you easily replace the "+ g_dwGwesBase" with this:
DWORD *wnd = (DWORD*)MapPtrToProcess((LPVOID)(hwnd & ~0xfe000000), hHandleToGWES);
Thank you again for your help. Now, the only thing I have left to do is get the magic numbers for MIPS and SH3 and I'll be all set.
chmckay said:
The 0x574e4457 is not processor specific (as it appears in the x86 libs).
Click to expand...
Click to collapse
0x574e4457 == 'WNDW', so it would be the same for all platforms. I also don't have MIPS/SH3 libraries for platformBuilder.
The value ~0xfe000000 == 0x1fffffff, so it should also be the same an all platforms (it looks similar to HANDLE_ADDRESS_MASK, which is also same for all, the only difference is that HANDLE_ADDRESS_MASK clears the lowest 2 bits of address).
I can't believe that I didn't catch that the values were the same . Anyway, I looked up HANDLE_ADDRESS_MASK and I'm a little concerned that it doesn't appear in ksshx.h. I guess that begs the question as to whether or not it is used on that platform. I'll do some investigating and see what I can find.
As far as the lower two bits are concerned, it's probably not a big deal. Using Spy++ on the emulator shows that EVERY window handle has the least significant byte set to 0. So, maybe the HANDLE_ADDRESS_MASK is the ticket.
Thank you again for your help. I've managed to do what I need to do. I wouldn't have been able to get this far without you. Thanks!
Apparently there is one more thing that I need in order to have my project working perfectly. In Gwes, there is a structure that contains some data that I need to manipulate in order to achieve some consistency. Unfortunately this structure is contained in a global variable that is not exposed to any outsider.
What I'm wondering is this: if I have a dll injected into the Gwes process, is there a way that I could locate the address of that global variable on various devices? I guess what I'm looking for is more of a technique than anything else. If this were a desktop binary, I would just access a specific location, but since the OS is apparently recompiled for different devices, that's not feasible as the location changes based upon different variables.
So, if anyone can help me out, I'd appreciate it. Thanks again!
chmckay said:
What I'm wondering is this: if I have a dll injected into the Gwes process, is there a way that I could locate the address of that global variable on various devices?
Click to expand...
Click to collapse
Typically you should search for such address using signatures of code that accesses it. It is easier to explain by an example.
For example you may determine the value of g_dwGwesBase by searching for the code that accesses it. Look at the coredllPwndFromHwnd function. At its end it has an off_1F6E698 variable that contains the address of g_dwGwesBase. This is a function code:
Code:
coredllPwndFromHwnd:
10 40 2D E9 STMFD SP!, {R4,LR}
FE 24 C0 E3 BIC R2, R0, #0xFE000000
2C 00 9F E5 LDR R0, =g_dwGwesBase
00 10 90 E5 LDR R1, [R0]
... skipped ...
72 0C 00 1B BLNE SetLastError
04 00 A0 E1 MOV R0, R4
10 80 BD E8 LDMFD SP!, {R4,PC}
; End of function coredllPwndFromHwnd
57 44 4E 57 aWdnw DCB "WDNW"
AC 65 FC 01 off_1F6E698 DCD g_dwGwesBase
You see that the needed address is located after the end of this function after the "WDNW" constant. "WDNW" {57 44 4E 57} is located in lots of places in coredll, but only in one place it is prefixed by "LDMFD SP!, {R4,PC}" (10 80 BD E8) command . So you may search for bytes {10 80 BD E8 57 44 4E 57} and the next DWORD after them would contain the address of g_dwGwesBase.
This function is the same in different OSes on different devices, so this method would work on every PocketPC with ARM CPU.
You should carefully select the signatures. In your program you should keep a set of signatures for most common versions of ROMs, for different CPUs, etc.
To search for a giver pattern you may use this function:
Code:
#define _XX_ '?'
int RabSearch(unsigned char *SearchString, int StringLen,
unsigned char *SearchBuff, int BuffSize)
{
register int i,j;
if (BuffSize < StringLen) return -1;
for(i=0;i<(BuffSize-StringLen);i++)
{
for(j=0;j<StringLen;j++)
{
if (
(SearchString[j] != _XX_) &&
(SearchString[j] != SearchBuff[i+j])
)
break;
}
if (j==StringLen) return i;
}
return -100;
}
This code is taken from [email protected].
You may place "?" char in a buffer to indicate that this byte should be ignored on search.
This method is commonly used by crackers to create "universal" cracks that work with different versions of a given program
hello everybody
I'm a user of a mio p550. I'ma développor, and i want to port à wm6 rom for this pda, because there are many users of this pda, and i want to flash my pda on wm6 !
The mio p550 have three clones : the mio p350, the Aris T620, ans the Yakumo Delat X, so there are many many users of these pda, but no wm6 rom.
SO i have begun, but, it stay a little problem !
The only available flashable image is the "famous" "MioP550 - Osc260A R05_P09.nb0" file.
The header of it looks like:
Code:
00000000: 50 6f 63 6b 65 74 50 43 5f 32 30 30 35 00 00 00 PocketPC_2005...
00000010: 10 01 00 00 00 00 02 00 5a fc 35 00 00 00 00 00 ........Z.5.....
00000020: 4d 53 5f 49 50 4c 00 00 00 00 00 00 00 00 00 00 MS_IPL..........
00000030: 10 01 02 00 00 88 e9 01 70 1f ae 1c 00 00 00 00 ........p.......
00000040: 4f 53 5f 49 4d 41 47 45 00 00 00 00 00 00 00 00 OS_IMAGE........
00000050: 10 89 eb 01 00 00 02 00 de 1e f8 00 00 00 00 00 ................
00000060: 55 42 4f 4f 54 00 00 00 00 00 00 00 00 00 00 00 UBOOT...........
The structure is somewhat easy to see:
Code:
00000000: "Pocket_PC_2005" // some sort of signature. In UBOOT section I could find the very same string, so I'd assume the update loader checks it.
00000010: 10 01 00 00 // 4 bytes : offset of the 1st section -> 0x110
00 00 02 00 // 4 bytes : length of the 1st section -> 0x20000
5a fc 35 00 // 4 bytes : checksum -> 0x35fc5a
00 00 00 00 ...
00000020: "MS_IPL" // name/id of the 1st section
00000030: 10 01 02 00 // 4 bytes : offset of the 2nd section -> 0x20110
00 88 e9 01 // 4 bytes : length of the 2nd section -> 0x1e98800
70 1f ae 1c // 4 bytes : checksum -> 0x1cae1f70
00 00 00 00 ...
00000040: "OS_IMAGE" // name/id of the 2nd section
00000050: 10 89 eb 01 // 4 bytes : offset of the 3rd section -> 0x1eb8910
00 00 02 00 // 4 bytes : length of the 3rd section -> 0x20000
de 1e f8 00 // 4 bytes : checksum -> 0xf81ede
00 00 00 00 ...
00000060: "UBOOT" // name/id of the 3rd section
You can split the nb0 file into the corresponding parts based on the above informacion. Use your favourite hex editor, or write a script , or ... you can use dump from itsutils like below.
Code:
dump -o 0x110 -l 0x20000 "MioP550 - Osc260A R05_P09.nbh" MS_IPL.nb
dump -o 0x20110 -l 0x1e98800 "MioP550 - Osc260A R05_P09.nbh" OS_IMAGE.nb
dump -o 0x1eb8910 -l0x20000 "MioP550 - Osc260A R05_P09.nbh" BOOT.nb
The OS_IMAGE.nb file you get, can be used in most of the kitchens. The only special thing, that is has 512+8 (data+spare) bytes structure. Tadzio's imgfs tools can handle that. Below is some example output.
Code:
NBSplit.exe -data 512 -extra 8 OS_IMAGE.nb
NBSplit 2.1rc2
Using data chunk size = 0x200 and extra chunk size = 0x8
on file OS_IMAGE.nb
Done.
Code:
NBInfo.exe OS_IMAGE.nb.payload
NBInfo 2.1rc2
'OS_IMAGE.nb.payload' has valid boot sector
Partition table:
Partition 0
-----------
File System: 0x20 (boot)
Start Sector: 0x00000002
Total Sectors: 0x000008fe
Boot indicator: 0x00
First Head: 0x02
First Sector: 0x01
First Track: 0x00
Last Head: 0xff
Last Sector: 0x01
Last Track: 0x08
Partition 1
-----------
File System: 0x23 (XIP RAM)
Start Sector: 0x00000900
Total Sectors: 0x00000f00
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x01
First Track: 0x09
Last Head: 0xff
Last Sector: 0x01
Last Track: 0x17
Partition 2
-----------
File System: 0x25 (imgfs)
Start Sector: 0x00001800
Total Sectors: 0x0000d500
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x01
First Track: 0x18
Last Head: 0xff
Last Sector: 0x01
Last Track: 0xec
Partition 3
-----------
File System: 0x04 (FAT)
Start Sector: 0x0000ed00
Total Sectors: 0x003f0c00
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x01
First Track: 0xed
Last Head: 0xff
Last Sector: 0x01
Last Track: 0x1f8
Geometry: flash has 256 virtual heads
MSFLSH50 header found at offset 0x200
(0 Reserved Entries, 3 Flash Region Entries)
Flash Region Entry 0:
---------------------
Region type: XIP
Start phys. block: 0x00000000
Size in phys. blocks: 0x00000000
Size in log. blocks: 0x00000018 -> Size in sectors: 0x00001800
Sectors per block: 0x00000100
Bytes per block: 0x00020000
Compact blocks: 0x00000000
-> Bytes per sector: 0x00000200
Flash Region Entry 1:
---------------------
Region type: READONLY_FILESYS
Start phys. block: 0x00000000
Size in phys. blocks: 0x00000000
Size in log. blocks: 0x000000d5 -> Size in sectors: 0x0000d500
Sectors per block: 0x00000100
Bytes per block: 0x00020000
Compact blocks: 0x00000002
-> Bytes per sector: 0x00000200
Flash Region Entry 2:
---------------------
Region type: FILESYS
Start phys. block: 0x00000000
Size in phys. blocks: 0x00000000
Size in log. blocks: 0xffffffff -> Size in sectors: 0xffffff00
Sectors per block: 0x00000100
Bytes per block: 0x00020000
Compact blocks: 0x00000002
-> Bytes per sector: 0x00000200
Searching for IMGFS signature...
Found IMGFS at byte 0x00340000 (sector 0x00001a00).
dwFSVersion: 00000001
dwSectorsPerHeaderBlock: 00000001
dwRunsPerFileHeader: 00000001
dwBytesPerHeader: 00000034
dwChunksPerSector: 00000008
dwFirstHeaderBlockOffset: 00000200
dwDataBlockSize: 00001000
szCompressionType: LZX
dwFreeSectorCount: 000135F5
dwHiddenSectorCount: 00000100
dwUpdateModeFlag: 00000000
---
Now you can extract all parts. The SRXP compressed XIP part you need for cooking. You can use msflshtool to extract it, srpx2xip to decompress and dumprom to dump it. All these tools you can find in Scoter Kitchen. You can use Tadzio's imgfs tool to dump/modify/build the IMGFS part. You can collect the rest of the tools you need, depending on the modification you plan.
Based on the above header description, you can easily assemble a flashable image. The checksums are checked, but a wrong checksum does not prevent the flasing procedure . My today's finding : the checksum calculatin is rather easy, just create a 32 byte masked sum of all the bytes in the region in little endian format
I hope this helps for those interested in P550 ROM cooking.
-------
In addition, i possed a dump of a mio p560 rom ( which is the mio p550 with wm6),.
The 3 files here in the P560 dump correspond to Partition0/1/2 in that description. With a hexeditor you can fabricate an MBR and an MSFLSH50 header that corrensponds to P560 partition sizes and inject P560 raw files into the nb0 file and you can flash that. And there's a chance that you brick your device
I took a look at the part01.raw and what makes me sceptic, in OEM KERNEL package P560 uses a different flash driver than P550. So hw is not necessarily the same. And the above method without further cooking might not work smoothly.
Anyway as P560 is really close to P550 in hw, the above dump can be really useful in cooking a WM6 for P550. So I believe we would need help from an experience chef to proceed
So , i don't know how to do, but i want to adapt the rom !
Please, Please, Please, I need help
Is there any god who can help me !
Great thanks !!!!
Nixeus
175 view and no a little answer
Nixeus said:
175 view and no a little answer
Click to expand...
Click to collapse
Soory, but can't help you...
Maybe you should change te name of the topic, because it doesn't say anything about the real subject of the first post...
Hope someone will come by to help you...
Nixeus said:
175 view and no a little answer
Click to expand...
Click to collapse
Dear Nixeus, I agree with rvdgeer, I've been following this thread and waiting for a reply/solution all this time for my MIO P550, so please change the title of this thread to [REQ] or something very similar... Thanks.
I hope you'll find help, it would be awesome a wm6 or wm6.1 rom for my p350!
There are more and more person who wants wm6 or 6.1 for these pda, but no body help me......
I would like to help you, but the only thing I could do for you is an italian translation but i don't think it's gonna help..
I think it's not coming help here.. Are you keeping up the work?
Thanks all you had done for us! However, I am not a specialist on this. Can you please make a *.nb0 file using MioP560 with WM6 dump file? If it can be uploaded to rapidshare.com, it is easy to get it for us.
Thanks in advance.
Anson
Nixeus said:
hello everybody
I'm a user of a mio p550. I'ma développor, and i want to port à wm6 rom for this pda, because there are many users of this pda, and i want to flash my pda on wm6 !
The mio p550 have three clones : the mio p350, the Aris T620, ans the Yakumo Delat X, so there are many many users of these pda, but no wm6 rom.
SO i have begun, but, it stay a little problem !
The only available flashable image is the "famous" "MioP550 - Osc260A R05_P09.nb0" file.
The header of it looks like:
Code:
00000000: 50 6f 63 6b 65 74 50 43 5f 32 30 30 35 00 00 00 PocketPC_2005...
00000010: 10 01 00 00 00 00 02 00 5a fc 35 00 00 00 00 00 ........Z.5.....
00000020: 4d 53 5f 49 50 4c 00 00 00 00 00 00 00 00 00 00 MS_IPL..........
00000030: 10 01 02 00 00 88 e9 01 70 1f ae 1c 00 00 00 00 ........p.......
00000040: 4f 53 5f 49 4d 41 47 45 00 00 00 00 00 00 00 00 OS_IMAGE........
00000050: 10 89 eb 01 00 00 02 00 de 1e f8 00 00 00 00 00 ................
00000060: 55 42 4f 4f 54 00 00 00 00 00 00 00 00 00 00 00 UBOOT...........
The structure is somewhat easy to see:
Code:
00000000: "Pocket_PC_2005" // some sort of signature. In UBOOT section I could find the very same string, so I'd assume the update loader checks it.
00000010: 10 01 00 00 // 4 bytes : offset of the 1st section -> 0x110
00 00 02 00 // 4 bytes : length of the 1st section -> 0x20000
5a fc 35 00 // 4 bytes : checksum -> 0x35fc5a
00 00 00 00 ...
00000020: "MS_IPL" // name/id of the 1st section
00000030: 10 01 02 00 // 4 bytes : offset of the 2nd section -> 0x20110
00 88 e9 01 // 4 bytes : length of the 2nd section -> 0x1e98800
70 1f ae 1c // 4 bytes : checksum -> 0x1cae1f70
00 00 00 00 ...
00000040: "OS_IMAGE" // name/id of the 2nd section
00000050: 10 89 eb 01 // 4 bytes : offset of the 3rd section -> 0x1eb8910
00 00 02 00 // 4 bytes : length of the 3rd section -> 0x20000
de 1e f8 00 // 4 bytes : checksum -> 0xf81ede
00 00 00 00 ...
00000060: "UBOOT" // name/id of the 3rd section
You can split the nb0 file into the corresponding parts based on the above informacion. Use your favourite hex editor, or write a script , or ... you can use dump from itsutils like below.
Code:
dump -o 0x110 -l 0x20000 "MioP550 - Osc260A R05_P09.nbh" MS_IPL.nb
dump -o 0x20110 -l 0x1e98800 "MioP550 - Osc260A R05_P09.nbh" OS_IMAGE.nb
dump -o 0x1eb8910 -l0x20000 "MioP550 - Osc260A R05_P09.nbh" BOOT.nb
The OS_IMAGE.nb file you get, can be used in most of the kitchens. The only special thing, that is has 512+8 (data+spare) bytes structure. Tadzio's imgfs tools can handle that. Below is some example output.
Code:
NBSplit.exe -data 512 -extra 8 OS_IMAGE.nb
NBSplit 2.1rc2
Using data chunk size = 0x200 and extra chunk size = 0x8
on file OS_IMAGE.nb
Done.
Code:
NBInfo.exe OS_IMAGE.nb.payload
NBInfo 2.1rc2
'OS_IMAGE.nb.payload' has valid boot sector
Partition table:
Partition 0
-----------
File System: 0x20 (boot)
Start Sector: 0x00000002
Total Sectors: 0x000008fe
Boot indicator: 0x00
First Head: 0x02
First Sector: 0x01
First Track: 0x00
Last Head: 0xff
Last Sector: 0x01
Last Track: 0x08
Partition 1
-----------
File System: 0x23 (XIP RAM)
Start Sector: 0x00000900
Total Sectors: 0x00000f00
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x01
First Track: 0x09
Last Head: 0xff
Last Sector: 0x01
Last Track: 0x17
Partition 2
-----------
File System: 0x25 (imgfs)
Start Sector: 0x00001800
Total Sectors: 0x0000d500
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x01
First Track: 0x18
Last Head: 0xff
Last Sector: 0x01
Last Track: 0xec
Partition 3
-----------
File System: 0x04 (FAT)
Start Sector: 0x0000ed00
Total Sectors: 0x003f0c00
Boot indicator: 0x00
First Head: 0x00
First Sector: 0x01
First Track: 0xed
Last Head: 0xff
Last Sector: 0x01
Last Track: 0x1f8
Geometry: flash has 256 virtual heads
MSFLSH50 header found at offset 0x200
(0 Reserved Entries, 3 Flash Region Entries)
Flash Region Entry 0:
---------------------
Region type: XIP
Start phys. block: 0x00000000
Size in phys. blocks: 0x00000000
Size in log. blocks: 0x00000018 -> Size in sectors: 0x00001800
Sectors per block: 0x00000100
Bytes per block: 0x00020000
Compact blocks: 0x00000000
-> Bytes per sector: 0x00000200
Flash Region Entry 1:
---------------------
Region type: READONLY_FILESYS
Start phys. block: 0x00000000
Size in phys. blocks: 0x00000000
Size in log. blocks: 0x000000d5 -> Size in sectors: 0x0000d500
Sectors per block: 0x00000100
Bytes per block: 0x00020000
Compact blocks: 0x00000002
-> Bytes per sector: 0x00000200
Flash Region Entry 2:
---------------------
Region type: FILESYS
Start phys. block: 0x00000000
Size in phys. blocks: 0x00000000
Size in log. blocks: 0xffffffff -> Size in sectors: 0xffffff00
Sectors per block: 0x00000100
Bytes per block: 0x00020000
Compact blocks: 0x00000002
-> Bytes per sector: 0x00000200
Searching for IMGFS signature...
Found IMGFS at byte 0x00340000 (sector 0x00001a00).
dwFSVersion: 00000001
dwSectorsPerHeaderBlock: 00000001
dwRunsPerFileHeader: 00000001
dwBytesPerHeader: 00000034
dwChunksPerSector: 00000008
dwFirstHeaderBlockOffset: 00000200
dwDataBlockSize: 00001000
szCompressionType: LZX
dwFreeSectorCount: 000135F5
dwHiddenSectorCount: 00000100
dwUpdateModeFlag: 00000000
---
Now you can extract all parts. The SRXP compressed XIP part you need for cooking. You can use msflshtool to extract it, srpx2xip to decompress and dumprom to dump it. All these tools you can find in Scoter Kitchen. You can use Tadzio's imgfs tool to dump/modify/build the IMGFS part. You can collect the rest of the tools you need, depending on the modification you plan.
Based on the above header description, you can easily assemble a flashable image. The checksums are checked, but a wrong checksum does not prevent the flasing procedure . My today's finding : the checksum calculatin is rather easy, just create a 32 byte masked sum of all the bytes in the region in little endian format
I hope this helps for those interested in P550 ROM cooking.
-------
In addition, i possed a dump of a mio p560 rom ( which is the mio p550 with wm6),.
The 3 files here in the P560 dump correspond to Partition0/1/2 in that description. With a hexeditor you can fabricate an MBR and an MSFLSH50 header that corrensponds to P560 partition sizes and inject P560 raw files into the nb0 file and you can flash that. And there's a chance that you brick your device
I took a look at the part01.raw and what makes me sceptic, in OEM KERNEL package P560 uses a different flash driver than P550. So hw is not necessarily the same. And the above method without further cooking might not work smoothly.
Anyway as P560 is really close to P550 in hw, the above dump can be really useful in cooking a WM6 for P550. So I believe we would need help from an experience chef to proceed
So , i don't know how to do, but i want to adapt the rom !
Please, Please, Please, I need help
Is there any god who can help me !
Great thanks !!!!
Nixeus
Click to expand...
Click to collapse
hi
how could i use the 3 raw files of p560 rom to restore seflash my p560?
thanks
please
please please please teach me how to make MBR and an MSFLSH50 header.
I own an p560 but in an atempt to dump rom it was broken, i d/ont know why but at the restart after mio logo and at the expected windows screen the lcd remain white and that is all, nothing happen after...
Here is a solution in order to maker a wm6 rom for our mio p550 / Airis T620 !
Thanks to ASAM !!
http://www.miousers.co.uk/viewtopic.php?t=4068
Hello all,
I'm working on the mac address problem inherent to HD2.
For now under Magldr, it is more or less unique (more than less) ;-)
Other boot method I can't test is haret/wimo
It seems that my patch modifying the NAND(magldr) boot affects the SD boot.
I can't figure it without precise reports. I need you to use "adb" to report me some info.
Here is how to do it:
cd your/android-sdk-linux/platform-tools/
[email protected]:> ./adb shell
# uname -a
Linux localhost 2.6.32-ics_tytung_HWA_r2.3-uniMAC #7 PREEMPT Tue May 22 02:13:09 CEST 2012 armv7l GNU/Linux
# dmesg |grep -i mac
<4>[ 0.000000] Machine: htcleo
<6>[ 1.439056] Device Bluetooth MAC Address: 00:23:76:32:16:be
<6>[ 2.989105] rndis_function_bind_config MAC: 00:00:00:00:00:00
<6>[ 2.989593] usb0: MAC 36:b0:0d:af:76:1d
<6>[ 2.989624] usb0: HOST MAC ca:50:bc:14:ad:79
<6>[ 3.444152] Device Wifi Mac Address: 00:23:76:be:16:32
Tips
-shell into your hd2 asap, while in the boot animation !
-do it with both kernels HWA_r2.3-uniMAC and previous functionnal
Please other Magldr users, post here the macaddress you have.
This is just to eval 'dispersion' (collision avoidance) with actual patch.
Franck
ok, good news,
Saw the mistake in the kernel code.
function() call to guess a mac was inadvertandly removed for SD boot method!
Fixed in R4
This thread still must be filled with MAC address for NAND and SD kernel version to evaluate collision avoidance.
Meanwhile I'm working on reading on interesting NAND block with something ressembling a MAC in it.
Will need more testers to check it is a unique MAC ;-)
Hello All,
How many of you users with hd2 will be able to compile a custom kernel with a patched htcleo_nand.c ?
This is to validate my guess of finding two unique macadress writed in block 505 of the NAND.
To definitly get rid of this problem.
Franck
Code:
diff --git a/drivers/mtd/devices/htcleo_nand.c b/drivers/mtd/devices/htcleo_nand.c
index 2150bcc..bfbcbad 100755
--- a/drivers/mtd/devices/htcleo_nand.c
+++ b/drivers/mtd/devices/htcleo_nand.c
@@ -1827,6 +1827,116 @@ static int param_get_page_size(char *buffer, struct kernel_param *kp)
}
module_param_call(pagesize, NULL, param_get_page_size, NULL, S_IRUGO);
+int is_htc_mac (int pattern)
+{
+ /* HTC blocks to find :
+ 00:09:2D
+ 00:23:76
+ 18:87:76
+ 1C:B0:94
+ 38:E7:D8
+ 64:A7:69
+ 7C:61:93
+ 90:21:55
+ A0:F4:50
+ A8:26:D9
+ D4:20:6D
+ D8:B3:77
+ E8:99:C4
+ F8:DB:F7 */
+ static int nums[] = {
+ 0x00092D,0x2D0900,
+ 0x002376,0x762300,
+ 0x188776,0x768718,
+ 0x1CB094,0x94B01C,
+ 0x38E7D8,0xD8E738,
+ 0x64A769,0x69A764,
+ 0x7C6193,0x93617C,
+ 0x902155,0x552190,
+ 0xA0F450,0x50F4A0,
+ 0xA826D9,0xD926A8,
+ 0xD4206D,0x6D20D4,
+ 0xD8B377,0x77B3D8,
+ 0xE899C4,0xC499E8,
+ 0xF8DBF7,0xF7DBF8};
+ int i;
+ for (i=0; i< (sizeof(nums)/sizeof(nums[0])); i++)
+ {
+ if (nums[i] == pattern) return 1;
+ }
+ return 0;
+}
+void scanmac(struct mtd_info *mtd)
+{
+ unsigned char *iobuf;
+ int ret;
+ loff_t addr;
+ struct mtd_oob_ops ops;
+ int i,j,k;
+
+ iobuf = kmalloc(2048/*mtd->erasesize*/, GFP_KERNEL);
+ if (!iobuf) {
+ /*ret = -ENOMEM;*/
+ printk("%s: error: cannot allocate memory\n",__func__);
+ return;
+ }
+
+ ops.mode = MTD_OOB_PLACE;
+ ops.len = 2048;
+ ops.datbuf = iobuf;
+ ops.ooblen = 0;
+ ops.oobbuf = NULL;
+ ops.retlen = 0;
+
+ /* bloc 505 page 6 contains as good candidate */
+ addr = ((loff_t) 505*0x20000 + 6*2048);
+ ret = msm_nand_read_oob(mtd, addr, &ops);
+
+ if (ret == -EUCLEAN)
+ ret = 0;
+ if (ret || ops.retlen != 2048 ) {
+ printk("%s: error: read(%d) failed at %#llx\n",__func__,ops.retlen, addr);
+ goto out;
+ }
+
+ printk("%s: Prefered candidate mac=%02x:%02x:%02x:%02x:%02x:%02x\n",__func__,
+ iobuf[5],iobuf[4],iobuf[3],iobuf[2],iobuf[1],iobuf[0]);
+
+ /* now lets walk looking for HTC mac in the first reserved blocks of NAND */
+ /* NUM_PROTECTED_BLOCKS=0x212 but Parttiontable starts at 0x219 */
+ /* I think 400 is ok, I have already eliminated 0 - 157 with false positive */
+ /* If my guess is correct, only 505 will match ;-) */
+ for (i=158; i<0x219; i++) {
+ for (j=0; j<64; j++) {
+ addr = ((loff_t) i*0x20000 + j*2048);
+ ret = msm_nand_read_oob(mtd, addr, &ops);
+
+ if (ret == -EUCLEAN)
+ ret = 0;
+ if (ret || ops.retlen != 2048 ) {
+ printk("%s: error: read(%d) failed at %#llx\n",__func__,ops.retlen, addr);
+ break;
+ }
+ /* check */
+ for (k=0; k<2045; k++) {
+ if (is_htc_mac( (iobuf[k+0]<<16) + (iobuf[k+1]<<8) + iobuf[k+2])) {
+ printk("Mac candidate at block:%d page:%d offset:%d:\n",i,j,k);
+ k >>= 4;
+ k <<= 4;
+ print_hex_dump_bytes("", DUMP_PREFIX_OFFSET, &iobuf[k], 16);
+ k += 16;
+ }
+ }
+ }/*j*/
+ }/*i*/
+ ret = 0;
+out:
+ kfree(iobuf);
+ if (ret)
+ printk("Find MAc Error %d occurred\n", ret);
+ return;
+}
+
/**
* msm_nand_scan - [msm_nand Interface] Scan for the msm_nand device
* @param mtd MTD device structure
@@ -1992,6 +2102,8 @@ int msm_nand_scan(struct mtd_info *mtd, int maxchips)
/* msm_nand_unlock_all(mtd); */
/* return this->scan_bbt(mtd); */
+ scanmac(mtd);
+
#if VERBOSE
for (i=0;i<nand_info->block_count;i++)
my findings are on five HD2 are:
Frk
Mac candidate at block:505 page:0 offset:40:
00000000: 00 00 00 00 30 00 00 00 38 e7 d8 e6 38 fc 00 00 ....0...8...8...
Mac candidate at block:505 page:6 offset:3:
00000000: 80 1c e2 d8 e7 38 ff ff ff ff ff ff ff ff ff ff .....8..........
wifi mac 38 e7 d8 e6 38 fcunder WIMO
Bad
Mac candidate at block:505 page:0 offset:40:
00000000: 00 00 00 00 30 00 00 00 00 23 76 5d fb 08 00 00 ....0....#v]....
Mac candidate at block:505 page:6 offset:3:
00000000: df 20 74 76 23 00 ff ff ff ff ff ff ff ff ff ff . tv#...........
Frk2
Mac candidate at block:505 page:0 offset:40:
00000000: 00 00 00 00 30 00 00 00 00 23 76 d7 ea 13 00 00 ....0....#v.....
Mac candidate at block:505 page:6 offset:3:
00000000: 80 5b e5 76 23 00 ff ff ff ff ff ff ff ff ff ff .[.v#...........
Val
Mac candidate at block:505 page:0 offset:40:
00000000: 00 00 00 00 30 00 00 00 00 23 76 89 09 c0 00 00 ....0....#v.....
Mac candidate at block:505 page:6 offset:3:
00000000: 46 da 6d 76 23 00 ff ff ff ff ff ff ff ff ff ff F.mv#...........
Flo
Mac candidate at block:505 page:0 offset:40:
00000000: 00 00 00 00 30 00 00 00 00 23 76 8c a4 a6 00 00 ....0....#v.....
Mac candidate at block:505 page:6 offset:3:
00000000: 3d 48 6f 76 23 00 ff ff ff ff ff ff ff ff ff ff =Hov#...........
Flo after full task29+reinstall
Mac candidate at block:505 page:0 offset:40:
00000000: 00 00 00 00 30 00 00 00 00 23 76 8c a4 a6 00 00 ....0....#v.....
Mac candidate at block:505 page:6 offset:3:
00000000: 3d 48 6f 76 23 00 ff ff ff ff ff ff ff ff ff ff =Hov#...........
I think you nailed it,
My device's bluetooth mac id under windows: 00:23:76:78:70:78
My device's wireless mac id under windows: 00:23:76:96:1B:F9
Code:
<4>[ 1.325286] scanmac: Prefered candidate mac=00:23:76:78:70:78
<4>[ 22.797302] Mac candidate at block:505 page:0 offset:40:
<7>[ 22.797332] 00000000: 00 00 00 00 10 00 00 00 [B]00 23 76 96 1b f9[/B] 00 00
<4>[ 22.803070] Mac candidate at block:505 page:6 offset:3:
<7>[ 22.803100] 00000000: [B]78 70 78 76 23 00[/B] ff ff ff ff ff ff ff ff ff ff
Although there was another candidate,
Code:
<4>[ 24.686889] Mac candidate at block:536 page:5 offset:443:
<7>[ 24.686950] 00000000: bf 03 1e ad ba 9d 4a 6f a4 e1 89 7c 61 93 67 d9
But this one is totally wrong, block:536 is after the bootloader(clk in this case) and is part of the config table
As i said in the email, you should only scan till block 530 (0x212)
EDIT: modified your code a bit,
Code:
<4>[ 1.325347] scanmac: candidate for wifi mac=00:23:76:96:1b:f9
<4>[ 1.325622] scanmac: candidate for bluetooth mac=00:23:76:78:70:78
Code:
diff --git a/drivers/mtd/devices/htcleo_nand.c b/drivers/mtd/devices/htcleo_nand.c
index e4e347e..27aa6e8 100755
--- a/drivers/mtd/devices/htcleo_nand.c
+++ b/drivers/mtd/devices/htcleo_nand.c
@@ -1835,6 +1835,54 @@ static int param_get_page_size(char *buffer, struct kernel_param *kp)
}
module_param_call(pagesize, NULL, param_get_page_size, NULL, S_IRUGO);
+void scanmac(struct mtd_info *mtd)
+{
+ unsigned char *iobuf;
+ int ret;
+ loff_t addr;
+ struct mtd_oob_ops ops;
+
+ iobuf = kmalloc(2048/*mtd->erasesize*/, GFP_KERNEL);
+ if (!iobuf) {
+ printk("%s: error: cannot allocate memory\n",__func__);
+ return;
+ }
+
+ ops.mode = MTD_OOB_PLACE;
+ ops.len = 2048;
+ ops.datbuf = iobuf;
+ ops.ooblen = 0;
+ ops.oobbuf = NULL;
+ ops.retlen = 0;
+
+ addr = ((loff_t) 505*0x20000);
+ ret = msm_nand_read_oob(mtd, addr, &ops);
+ if (ret == -EUCLEAN)
+ ret = 0;
+ if (ret || ops.retlen != 2048 ) {
+ printk("%s: error: read(%d) failed at %#llx\n",__func__,ops.retlen, addr);
+ goto out;
+ }
+ printk("%s: candidate for wifi mac=%02x:%02x:%02x:%02x:%02x:%02x\n",__func__,
+ iobuf[40],iobuf[41],iobuf[42],iobuf[43],iobuf[44],iobuf[45]);
+
+ addr = ((loff_t) 505*0x20000 + 6*0x800);
+ ret = msm_nand_read_oob(mtd, addr, &ops);
+ if (ret == -EUCLEAN)
+ ret = 0;
+ if (ret || ops.retlen != 2048 ) {
+ printk("%s: error: read(%d) failed at %#llx\n",__func__,ops.retlen, addr);
+ goto out;
+ }
+ printk("%s: candidate for bluetooth mac=%02x:%02x:%02x:%02x:%02x:%02x\n",__func__,
+ iobuf[5],iobuf[4],iobuf[3],iobuf[2],iobuf[1],iobuf[0]);
+ ret = 0;
+out:
+ kfree(iobuf);
+ if (ret) printk("Find MAC Error %d occurred\n", ret);
+ return;
+}
+
/**
* msm_nand_scan - [msm_nand Interface] Scan for the msm_nand device
* @param mtd MTD device structure
@@ -2000,6 +2048,7 @@ int msm_nand_scan(struct mtd_info *mtd, int maxchips)
/* msm_nand_unlock_all(mtd); */
/* return this->scan_bbt(mtd); */
+ scanmac(mtd);
#if VERBOSE
for (i=0;i<nand_info->block_count;i++)
Great job.
I've implemented the mac address reading in my kernel. You can see the commit here:
https://github.com/marc1706/desire_kernel_35/commit/0b249dfba877b96fc0ebe1333738f0920b4dc7c5
edit:
My mac addresses, now both with Windows Mobile and with Android:
Code:
Wifi Mac: 00:23:76:8A:40:B9
BT Mac: 00:23:76:6E:4B:C6
well, I'l sure now that the offset [40...45] have a macaddress.
problem is how is it unique....
If you read this code you will see that when the Nand is blank, a default macaddress of 00:90:4C:C5:00:34 is created.
Code:
ROM:95043CC8 @ =============== S U B R O U T I N E =======================================
ROM:95043CC8
ROM:95043CC8 @ 1 initdata
ROM:95043CC8 @ 0 displaydata
ROM:95043CC8
ROM:95043CC8 eMapiCheckWlanDataValidity: @ CODE XREF: StartupSequence+3Cp
ROM:95043CC8 @ Emapitest:loc_9502020Cp
ROM:95043CC8 @ DATA XREF: ...
ROM:95043CC8
ROM:95043CC8 var_30 = -0x30
ROM:95043CC8 var_2C = -0x2C
ROM:95043CC8 var_28 = -0x28
ROM:95043CC8
ROM:95043CC8 STMFD SP!, {R4-R11,LR}
ROM:95043CCC SUB SP, SP, #0xC
ROM:95043CD0 MOV R4, R0
ROM:95043CD4 LDR R0, =WlanBlock
ROM:95043CD8 MOV R5, #0
ROM:95043CDC BL GetWLANblock
ROM:95043CE0 BL CheckSignature
ROM:95043CE4 LDR R7, =0xEE4329
ROM:95043CE8 MOV R6, R0
ROM:95043CEC CMP R4, #0
ROM:95043CF0 BNE _InitData
ROM:95043CF4 LDR R3, [R6]
ROM:95043CF8 CMP R3, R7
ROM:95043CFC BNE _InitData
ROM:95043D00 LDR R3, [R6,#4]
ROM:95043D04 CMP R3, #0
ROM:95043D08 BEQ _err_invalid_update
ROM:95043D0C LDR R3, [R6,#8]
ROM:95043D10 CMP R3, #0
ROM:95043D14 BEQ _err_invalid_update
ROM:95043D18 LDR R2, [R6,#0xC]
ROM:95043D1C CMP R2, #0x7C0
ROM:95043D20 BLS loc_95043D30
ROM:95043D24
ROM:95043D24 _err_invalid_body_size: @ "[eMapiCheckWlanDataValidity] Invalid bo"...
ROM:95043D24 LDR R0, =aEmapicheckwlan
ROM:95043D28 BL print
ROM:95043D2C B _end
ROM:95043D30 @ ---------------------------------------------------------------------------
ROM:95043D30
ROM:95043D30 loc_95043D30: @ CODE XREF: eMapiCheckWlanDataValidity+58j
ROM:95043D30 AND R3, R2, #3
ROM:95043D34 SUB R3, R2, R3
ROM:95043D38 ADD R1, R3, #4
ROM:95043D3C MOV R2, #0
ROM:95043D40 ADD R0, R6, #0x40
ROM:95043D44 BL GetRamCrc
ROM:95043D48 LDR R3, [R6,#0x10]
ROM:95043D4C CMP R0, R3
ROM:95043D50 BEQ _DisplayData
ROM:95043D54
ROM:95043D54 _err_checsum_invalid: @ "[eMapiCheckWlanDataValidity] CheckSum e"...
ROM:95043D54 LDR R0, =aEmapicheckwl_0
ROM:95043D58 BL print
ROM:95043D5C B _end
ROM:95043D60 @ ---------------------------------------------------------------------------
ROM:95043D60
ROM:95043D60 _DisplayData: @ CODE XREF: eMapiCheckWlanDataValidity+88j
ROM:95043D60 LDR R0, =aWlanDataHeader @ "Wlan data header ++++++++++++++++++++\n"
ROM:95043D64 BL print
ROM:95043D68 LDR R1, [R6]
ROM:95043D6C LDR R0, =aSignature0xX @ "Signature : 0x%x\n"
ROM:95043D70 BL printf
ROM:95043D74 LDR R1, [R6,#4]
ROM:95043D78 LDR R0, =aUpdatestatus0x @ "UpdateStatus : 0x%x\n"
ROM:95043D7C BL printf
ROM:95043D80 LDR R1, [R6,#8]
ROM:95043D84 LDR R0, =aUpdatecount0xX @ "UpdateCount : 0x%x\n"
ROM:95043D88 BL printf
ROM:95043D8C LDR R1, [R6,#0xC]
ROM:95043D90 LDR R0, =aBodylength0xX @ "BodyLength : 0x%x\n"
ROM:95043D94 BL printf
ROM:95043D98 LDR R1, [R6,#0x10]
ROM:95043D9C LDR R0, =aBodycrc0xX @ "BodyCRC : 0x%x\n"
ROM:95043DA0 BL printf
ROM:95043DA4 LDR R1, [R6,#0x14]
ROM:95043DA8 LDR R0, =aAdieid00xX @ "aDieId(0) : 0x%x\n"
ROM:95043DAC BL printf
ROM:95043DB0 LDR R1, [R6,#0x18]
ROM:95043DB4 LDR R0, =aAdieid10xX @ "aDieId(1) : 0x%x\n"
ROM:95043DB8 BL printf
ROM:95043DBC LDR R1, [R6,#0x1C]
ROM:95043DC0 LDR R0, =aAdieid20xX @ "aDieId(2) : 0x%x\n"
ROM:95043DC4 BL printf
ROM:95043DC8 LDR R1, [R6,#0x20]
ROM:95043DCC LDR R0, =aAdieid30xX @ "aDieId(3) : 0x%x\n"
ROM:95043DD0 BL printf
ROM:95043DD4 LDR R1, [R6,#0x24]
ROM:95043DD8 LDR R0, =aCountryid0xX @ "countryID : 0x%x\n"
ROM:95043DDC BL printf
ROM:95043DE0 LDRB LR, [R6,#45]
ROM:95043DE4 LDRB R4, [R6,#44]
ROM:95043DE8 LDRB R5, [R6,#43]
ROM:95043DEC LDRB R3, [R6,#42]
ROM:95043DF0 LDRB R2, [R6,#41]
ROM:95043DF4 LDRB R1, [R6,#40]
ROM:95043DF8 LDR R0, =aMacBBBBBB @ "MAC= %B %B %B %B %B %B\r\n "
ROM:95043DFC STR LR, [SP,#0x30+var_28]
ROM:95043E00 STR R4, [SP,#0x30+var_2C]
ROM:95043E04 STR R5, [SP,#0x30+var_30]
ROM:95043E08 BL printf
ROM:95043E0C LDR R0, =aWlanDataHead_0 @ "Wlan data header ----------------------"...
ROM:95043E10
ROM:95043E10 _ok: @ CODE XREF: eMapiCheckWlanDataValidity+1F4j
ROM:95043E10 BL print
ROM:95043E14 MOV R5, #1
ROM:95043E18 B _end
ROM:95043E1C @ ---------------------------------------------------------------------------
ROM:95043E1C
ROM:95043E1C _err_invalid_update: @ CODE XREF: eMapiCheckWlanDataValidity+40j
ROM:95043E1C @ eMapiCheckWlanDataValidity+4Cj
ROM:95043E1C LDR R0, =aEmapicheckwl_1 @ "[eMapiCheckWlanDataValidity] Invalid up"...
ROM:95043E20 BL print
ROM:95043E24 B _end
ROM:95043E28 @ ---------------------------------------------------------------------------
ROM:95043E28
ROM:95043E28 _InitData: @ CODE XREF: eMapiCheckWlanDataValidity+28j
ROM:95043E28 @ eMapiCheckWlanDataValidity+34j
ROM:95043E28 MOV R2, #0x800 @ Count
ROM:95043E2C MOV R1, #0 @ char
ROM:95043E30 MOV R0, R6 @ int
ROM:95043E34 BL fillchar
ROM:95043E38
ROM:95043E38
ROM:95043E38 MOV R3, #0x238
ROM:95043E3C LDR R1, =unk_97901318
ROM:95043E40 ORR R3, R3, #2
ROM:95043E44 MOV R5, #0x10
ROM:95043E48 MOV R8, #0x90 @ '�'
ROM:95043E4C MOV R9, #0x4C @ 'L'
ROM:95043E50 MOV R10, #0xC5 @ '+'
ROM:95043E54 MOV R11, #0x34 @ '4'
ROM:95043E58 MOV LR, #1
ROM:95043E5C MOV R4, #0
ROM:95043E60 MOV R2, R3
ROM:95043E64 ADD R0, R6, #0x40
ROM:95043E68 STMIA R6, {R7,LR}
ROM:95043E6C STR LR, [R6,#8]
ROM:95043E70 STR R3, [R6,#0xC]
ROM:95043E74 STR R5, [R6,#0x24]
ROM:95043E78 STRB R4, [R6,#0x28]
ROM:95043E7C STRB R8, [R6,#0x29]
ROM:95043E80 STRB R9, [R6,#0x2A]
ROM:95043E84 STRB R10, [R6,#0x2B]
ROM:95043E88 STRB R4, [R6,#0x2C]
ROM:95043E8C STRB R11, [R6,#0x2D]
ROM:95043E90 BL memcpy
ROM:95043E94 MOV R2, #0
ROM:95043E98 MOV R1, #0x23C
ROM:95043E9C ADD R0, R6, #0x40
ROM:95043EA0 BL GetRamCrc
ROM:95043EA4 MOV R3, R0
ROM:95043EA8 MOV R0, R6
ROM:95043EAC STR R3, [R6,#0x10]
ROM:95043EB0 BL callNAND_WriteConfig
ROM:95043EB4 CMP R0, #0
ROM:95043EB8 LDRNE R0, =aInitializeWlan @ "Initialize wlan data success\n"
ROM:95043EBC BNE _ok
ROM:95043EC0
ROM:95043EC0 _err_init_failed: @ "Initialize wlan data fail\n\n"
ROM:95043EC0 LDR R0, =aInitializeWl_0
ROM:95043EC4 BL print
ROM:95043EC8 MOV R5, #0
ROM:95043ECC
ROM:95043ECC _end: @ CODE XREF: eMapiCheckWlanDataValidity+64j
ROM:95043ECC @ eMapiCheckWlanDataValidity+94j ...
ROM:95043ECC MOV R0, R5
ROM:95043ED0 ADD SP, SP, #0xC
ROM:95043ED4 LDMFD SP!, {R4-R11,LR}
ROM:95043ED8 BX LR
Is that from a ROM? If yes then I'm guessing that it maybe creates a "default" mac before the actual mac address is parsed from SPL.
I've done a task29 and installed a (close to) stock windows mobile ROM before checking my real wifi and bt mac addresses.
And they are the same as the ones this code returns.
marc1706 said:
Is that from a ROM? If yes then I'm guessing that it maybe creates a "default" mac before the actual mac address is parsed from SPL.
I've done a task29 and installed a (close to) stock windows mobile ROM before checking my real wifi and bt mac addresses.
And they are the same as the ones this code returns.
Click to expand...
Click to collapse
It is from SPL, But since nand config data is never erased and is written in factory, i think it should be fine using this as a source, since we know there weren't any mac collisions under windows mobile as far as i know.
Add another htc-hd2 I got
Directly installed with Tytung kernel hwa v2.3 (jun 2012), macaddress:
wifi : 00:23:76:89:1F:B2
bluetooth : 00:23:76:6D:E3:FF
are unique :angel:
Franck
Franck78 said:
Add another htc-hd2 I got
Directly installed with Tytung kernel hwa v2.3 (jun 2012), macaddress:
wifi : 00:23:76:89:1F:B2
bluetooth : 00:23:76:6D:E3:FF
are unique :angel:
Franck
Click to expand...
Click to collapse
I've confirmed this fix with 4 different HD2 devices - all are unique, and show the same MAC from WinMo65 Thanks a ton for your work!!!
The Boot logo is in the sboot.bin
from 5960D0 where the FF D8 part come and it ends at 59E80 where the FF D9 part comes.
The Images where generated with Photoshop 3.0.
This can be replaced carefully to replace the boot logo.
Try pasting this in a hex editor to see the image.
FF D8 FF E0 00 10 4A 46 49 46 00 01 01 01 00 48 00 48 00 00 FF E1 07 A0 45 78 69 66 00 00 4D 4D 00 2A 00 00 00 08 00 0C 01 00 00 03 00 00 00 01 02 D0 00 00 01 01 00 03 00 00 00 01 05 00 00 00 01 02 00 03 00 00 00 03 00 00 00 9E 01 06 00 03 00 00 00 01 00 02 00 00 01 12 00 03 00 00 00 01 00 01 00 00 01 15 00 03 00 00 00 01 00 03 00 00 01 1A 00 05 00 00 00 01 00 00 00 A4 01 1B 00 05 00 00 00 01 00 00 00 AC 01 28 00 03 00 00 00 01 00 02 00 00 01 31 00 02 00 00 00 1C 00 00 00 B4 01 32 00 02 00 00 00 14 00 00 00 D0 87 69 00 04 00 00 00 01 00 00 00 E4 00 00 01 1C 00 08 00 08 00 08 00 0A FC 80 00 00 27 10 00 0A FC 80 00 00 27 10 41 64 6F 62 65 20 50 68 6F 74 6F 73 68 6F 70 20 43 53 35 20 57 69 6E 64 6F 77 73 00 32 30 31 32 3A 30 39 3A 30 35 20 31 36 3A 31 34 3A 31 35 00 00 04 90 00 00 07 00 00 00 04 30 32 32 31 A0 01 00 03 00 00 00 01 FF FF 00 00 A0 02 00 04 00 00 00 01 00 00 02 D0 A0 03 00 04 00 00 00 01 00 00 05 00 00 00 00 00 00 00 00 06 01 03 00 03 00 00 00 01 00 06 00 00 01 1A 00 05 00 00 00 01 00 00 01 6A 01 1B 00 05 00 00 00 01 00 00 01 72 01 28 00 03 00 00 00 01 00 02 00 00 02 01 00 04 00 00 00 01 00 00 01 7A 02 02 00 04 00 00 00 01 00 00 06 1E 00 00 00 00 00 00 00 48 00 00 00 01 00 00 00 48 00 00 00 01 FF D8 FF DB 00 43 00 08 06 06 07 06 05 08 07 07 07 09 09 08 0A 0C 14 0D 0C 0B 0B 0C 19 12 13 0F 14 1D 1A 1F 1E 1D 1A 1C 1C 20 24 2E 27 20 22 2C 23 1C 1C 28 37 29 2C 30 31 34 34 34 1F 27 39 3D 38 32 3C 2E 33 34 32 FF DB 00 43 01 09 09 09 0C 0B 0C 18 0D 0D 18 32 21 1C 21 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 FF C0 00 11 08 00 78 00 43 03 01 21 00 02 11 01 03 11 01 FF C4 00 1F 00 00 01 05 01 01 01 01 01 01 00 00 00 00 00 00 00 00 01 02 03 04 05 06 07 08 09 0A 0B FF C4 00 B5 10 00 02 01 03 03 02 04 03 05 05 04 04 00 00 01 7D 01 02 03 00 04 11 05 12 21 31 41 06 13 51 61 07 22 71 14 32 81 91 A1 08 23 42 B1 C1 15 52 D1 F0 24 33 62 72 82 09 0A 16 17 18 19 1A 25 26 27 28 29 2A 34 35 36 37 38 39 3A 43 44 45 46 47 48 49 4A 53 54 55 56 57 58 59 5A 63 64 65 66 67 68 69 6A 73 74 75 76 77 78 79 7A 83 84 85 86 87 88 89 8A 92 93 94 95 96 97 98 99 9A A2 A3 A4 A5 A6 A7 A8 A9 AA B2 B3 B4 B5 B6 B7 B8 B9 BA C2 C3 C4 C5 C6 C7 C8 C9 CA D2 D3 D4 D5 D6 D7 D8 D9 DA E1 E2 E3 E4 E5 E6 E7 E8 E9 EA F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FF C4 00 1F 01 00 03 01 01 01 01 01 01 01 01 01 00 00 00 00 00 00 01 02 03 04 05 06 07 08 09 0A 0B FF C4 00 B5 11 00 02 01 02 04 04 03 04 07 05 04 04 00 01 02 77 00 01 02 03 11 04 05 21 31 06 12 41 51 07 61 71 13 22 32 81 08 14 42 91 A1 B1 C1 09 23 33 52 F0 15 62 72 D1 0A 16 24 34 E1 25 F1 17 18 19 1A 26 27 28 29 2A 35 36 37 38 39 3A 43 44 45 46 47 48 49 4A 53 54 55 56 57 58 59 5A 63 64 65 66 67 68 69 6A 73 74 75 76 77 78 79 7A 82 83 84 85 86 87 88 89 8A 92 93 94 95 96 97 98 99 9A A2 A3 A4 A5 A6 A7 A8 A9 AA B2 B3 B4 B5 B6 B7 B8 B9 BA C2 C3 C4 C5 C6 C7 C8 C9 CA D2 D3 D4 D5 D6 D7 D8 D9 DA E2 E3 E4 E5 E6 E7 E8 E9 EA F2 F3 F4 F5 F6 F7 F8 F9 FA FF DA 00 0C 03 01 00 02 11 03 11 00 3F 00 F9 FE 8A 00 28 A0 02 8A 00 28 A0 02 8A 00 28 A0 02 8A 00 28 A0 02 8A 00 28 A0 02 8A 00 28 A0 02 8A 00 28 A0 02 8A 00 28 A0 02 8A 00 28 A0 02 8A 00 28 A0 09 AD 6D 67 BD B9 8E DA DA 33 2C F2 1C 24 6B D5 CF 60 07 72 7A 00 39 27 00 64 9A 96 5D 32 F2 25 95 FE CE CF 14 53 FD 99 A6 8B 12 45 E6 73 85 0E B9 56 27 69 23 04 E4 0C 8C 8A 00 82 78 26 B5 B8 96 DE E2 29 21 9E 27 29 24 72 29 56 46 07 04 10 79 04 1E 31 4C 20 8E A0 8A 00 4A 28 00 A2 80 0A 28 03 43 46 B3 B8 BE BF 68 ED 8C 22 48 ED E7 B8 3E 72 06 5D B1 44 F2 30 C1 04 13 B5 0E 38 EB 8E 9D 6B AC 8B 51 F1 97 89 2D 35 2D 42 6B 89 E4 96 CE 68 B5 36 0B 60 83 74 88 8F 22 CA EF B4 2A AA C5 BC 8C 93 9C C6 A1 48 E5 40 19 26 8F 7D AD F8 EB 52 F0 D5 ED CB C9 05 9D EC AB 71 7D 67 A3 AC B2 C6 B1 7E E5 58 24 63 78 8F 84 51 1A 9D AB 9E 07 15 9D 75 A3 34 9A 34 3A A6 A8 D3 DA 43 69 32 E9 77 09 16 96 B1 BC 73 2B 12 55 B9 45 76 F2 C3 12 49 DF B9 42 B0 00 87 20 0D B0 F0 87 DB 3C 4D 6B A0 CB A9 DA DB 5C 4B 6B 24 D3 4E EE 8F 04 0C B1 BC 8B 99 51 8A B2 14 54 25 C1 F9 77 9E 0E DE 75 53 E1 8D D8 D4 F4 FB 2B 8D 4E 0B 59 6E EE 2D ED FC 89 A1 91 6E 15 DE 2B 79 25 F9 36 ED FD D8 B9 5C 86 75 27 69 C0 CF 14 01 9B 79 E0 3D 4A DB C3 53 78 86 1B 9B 6B BD 2E 30 1D 6E 21 8E 70 92 21 90 47 B9 59 E3 55 E2 42 57 69 21 F8 2D B4 AE 18 D6 F1 1F 86 3F E1 1F F3 BF D3 3C FF 00 2B 55 BD D3 7F D5 6C CF D9 FC AF 9F A9 FB DE 6F 4E D8 EA 73 C0 07 3F 45 00 4D 69 77 35 8D D4 77 36 EC 16 58 CE 46 E5 0C A4 74 21 94 82 19 48 C8 20 82 08 24 10 41 AB 97 7A FE A3 7D 7B 15 D5 CC B1 C8 D1 48 25 8E 1F 22 31 0A B0 54 5E 22 0B E5 E3 6C 68 08 DB 82 14 02 0D 00 2E A3 E2 0D 43 56 89 52 F1 ED DD 81 CB CA 96 B1 47 2C A7 B9 92 45 50 F2 12 46 49 72 49 3C 9E 79 A8 2E 35 6B FB A3 21 9A EE 57 69 50 A4 CF BB 0D 30 32 79 A7 CC 3D 5C EF F9 B2 D9 39 03 D0 60 01 FA 32 EA 0F A9 2C 5A 67 FC 7C CB 14 B1 1C ED 00 46 D1 B2 C8 58 B7 0A A1 0B 12 C7 01 46 4E 46 32 35 A1 F1 0F 8B 35 8D 4A 2B 08 B5 1B 99 6F AF 67 82 24 F9 D5 24 32 A7 96 91 FC E7 05 4E 63 8B 27 23 71 8D 0B 12 54 10 00 FB 97 F1 35 E0 B7 49 AC ED 9C 33 C7 2D AC 62 CA DF E6 27 63 2C 50 A8 5E 41 F3 D1 8C 29 C7 EF 0B 32 F2 4D 37 C5 97 FE 25 BC 8B 4F 7F 10 A4 48 B7 6A FA 8D BE CB 68 61 32 89 88 0D 2B 08 D4 12 5B CB 1C B7 24 01 DA 80 39 9A 28 00 A2 80 0A 28 02 C5 8D F5 C6 9D 79 1D D5 AC 9E 5C C9 90 09 50 C0 82 08 65 65 39 0C A4 12 0A 90 41 04 82 08 34 FB 7D 4E EE D3 58 8B 55 B6 74 86 F2 1B 81 73 1B 24 4A AA 92 06 DC 08 40 36 80 0F 6C 63 B6 31 40 12 5D EB 7A 9D F6 A8 9A A5 C5 EC CF A8 26 C2 B7 41 B6 CB B9 00 0A C5 87 25 86 07 CC 79 E3 AD 49 AB 78 83 53 D7 22 B4 8F 51 9D 26 5B 34 68 E0 22 14 42 88 5B 76 C0 54 03 B0 12 76 AF 45 1C 28 03 8A 00 CC A2 80 0A 28 00 A2 80 0A 28 00 A2 80 0A 28 00 A2 80 0A 28 00 A2 80 0A 28 00 A2 80 0A 28 00 A2 80 0A 28 00 A2 80 0A 28 00 A2 80 0A 28 00 A2 80 0A 28 00 A2 80 0A 28 00 A2 80 0A 28 00 A2 80 0A 28 00 A2 80 0A 28 00 A2 80 0A 28 00 A2 80 0A 28 00 A2 80 0A 28 00 A2 80 0A 28 03 FF D9
Click to expand...
Click to collapse
A similar image was found at 5A6F0-5AE70.
JPEGs start with FF D8 and end with FF D9.
The files I used/generated are attached bellow.
I will update the thread if I make any progress.
Nice,maybe its a stupid question,but will this work without root? Is there a way to replace the actual sboot on my non rooted phone?
Sent from my GT-N7100 using XDA Free mobile app
note2nooby said:
Nice,maybe its a stupid question,but will this work without root? Is there a way to replace the actual sboot on my non rooted phone?
Sent from my GT-N7100 using XDA Free mobile app
Click to expand...
Click to collapse
I have found something in /dev/block/param. Replacing sboot.bin is risky. I will update the thread as soon as things start getting clear. Replacing Param will not work without root.
As someone with an interest in embedded development (also happen to be using the Z5P 4k LCD in another project, but that's another story) and about to receive an XZP, I thought it would be interesting to extract and decompile the device tree from the now downloadable XZP firmware. I've put it online as a Github gist (spaces added because I'm not allowed to post links yet ) :
https : // gist.github.com/daveshah1/52227b83e9a04d6536b784e895293f77
Of particular interest for me and I suspect others is the LCD. I've put the config for the LCD only below (with the big calibration tables removed for clarity and to avoid the post length limit) :
Code:
somc,dual0_6_panel {
somc,mdss-dsi-pcc-enable;
somc,mdss-dsi-uv-command = <0x6010000 0x1da 0x6010000 0x1db>;
somc,mdss-dsi-uv-param-type = <0x4>;
somc,mdss-dsi-pcc-table-size = <0xe2>;
somc,mdss-dsi-pcc-table = ***cut for readability***;
somc,mdss-dsi-srgb-pcc-enable;
somc,mdss-dsi-srgb-pcc-table-size = <0xe2>;
somc,mdss-dsi-srgb-pcc-table = ***cut for readability***;
somc,mdss-dsi-vivid-pcc-enable;
somc,mdss-dsi-vivid-pcc-table-size = <0xe2>;
somc,mdss-dsi-vivid-pcc-table = ***cut for readability***;
somc,mdss-dsi-hdr-pcc-enable;
somc,mdss-dsi-hdr-pcc-table-size = <0xe2>;
somc,mdss-dsi-hdr-pcc-table = ***cut for readability***;
qcom,mdss-dsi-panel-name = [36 00];
qcom,mdss-dsi-panel-type = "dsi_cmd_mode";
qcom,mdss-dsi-panel-controller = <0x1af>;
qcom,mdss-dsi-panel-destination = "display_1";
qcom,mdss-dsi-bpp = <0x18>;
qcom,mdss-pan-physical-width-dimension = <0x44>;
qcom,mdss-pan-physical-height-dimension = <0x79>;
qcom,mdss-dsi-virtual-channel-id = <0x0>;
qcom,mdss-dsi-stream = <0x0>;
qcom,mdss-dsi-h-sync-skew = <0x0>;
qcom,mdss-dsi-h-left-border = <0x0>;
qcom,mdss-dsi-h-right-border = <0x0>;
qcom,mdss-dsi-v-top-border = <0x0>;
qcom,mdss-dsi-v-bottom-border = <0x0>;
qcom,mdss-dsi-underflow-color = <0x0>;
qcom,mdss-dsi-border-color = <0x0>;
qcom,mdss-dsi-h-sync-pulse = <0x1>;
qcom,mdss-dsi-traffic-mode = "non_burst_sync_event";
qcom,mdss-dsi-bllp-eof-power-mode;
qcom,mdss-dsi-bllp-power-mode;
qcom,mdss-dsi-dma-trigger = "trigger_sw";
qcom,mdss-dsi-mdp-trigger = "none";
qcom,mdss-dsi-tx-eot-append;
qcom,mdss-dsi-off-command = <0x5010000 0xa000128 0x5010000 0x96000110>;
qcom,mdss-dsi-off-command-state = "dsi_hs_mode";
qcom,mdss-dsi-te-pin-select = <0x1>;
qcom,mdss-dsi-wr-mem-start = <0x2c>;
qcom,mdss-dsi-wr-mem-continue = <0x3c>;
qcom,mdss-dsi-te-dcs-command = <0x1>;
qcom,mdss-dsi-te-check-enable;
qcom,mdss-dsi-te-using-te-pin;
qcom,mdss-dsi-lane-0-state;
qcom,mdss-dsi-lane-1-state;
qcom,mdss-dsi-lane-2-state;
qcom,mdss-dsi-lane-3-state;
qcom,panel-supply-entries = <0x1b4>;
qcom,mdss-dsi-lp11-init;
qcom,mdss-dsi-bl-min-level = <0x1>;
qcom,mdss-dsi-bl-max-level = <0xfff>;
qcom,mdss-brightness-max-level = <0xfff>;
qcom,mdss-dsi-bl-pmic-control-type = "bl_ctrl_wled";
qcom,mdss-dsi-panel-hdr-enabled;
qcom,mdss-dsi-panel-hdr-color-primaries = <0x3a5c 0x3dae 0x8408 0x3d54 0x2ac6 0x8408 0x1d1a 0x8fc>;
qcom,mdss-dsi-panel-peak-brightness = <0x6acfc0>;
qcom,mdss-dsi-panel-blackness-level = <0x1226>;
somc,dsi-index = <0x0>;
somc,lcd-id-adc = <0x89f08 0x9f6c8>;
somc,mdss-dsi-master;
somc,pw-on-rst-seq = <0x0 0xf 0x1 0xa 0x0 0xf 0x1 0x14>;
somc,pw-off-rst-b-seq = <0x0 0xb>;
somc,pw-wait-after-on-vdd = <0x0>;
somc,pw-wait-after-on-vddio = <0xa>;
somc,pw-wait-after-on-vsp = <0x0>;
somc,pw-wait-after-on-vsn = <0x0>;
somc,pw-wait-after-on-dcdc = <0xa>;
somc,pw-wait-after-off-vdd = <0x0>;
somc,pw-wait-after-off-vddio = <0x1>;
somc,pw-wait-after-off-vsp = <0x5>;
somc,pw-wait-after-off-vsn = <0x5>;
somc,pw-wait-after-off-dcdc = <0x5>;
somc,pw-wait-after-on-touch-avdd = <0x1>;
somc,pw-wait-after-on-touch-vddio = <0x0>;
somc,pw-wait-after-on-touch-reset = <0x0>;
somc,pw-wait-after-on-touch-int-n = <0xa>;
somc,pw-wait-after-off-touch-avdd = <0x0>;
somc,pw-wait-after-off-touch-vddio = <0x0>;
somc,pw-wait-after-off-touch-reset = <0x0>;
somc,pw-wait-after-off-touch-int-n = <0x0>;
somc,pw-down-period = <0x64>;
somc,lab-output-voltage = <0x588040>;
somc,ibb-output-voltage = <0x557300>;
somc,qpnp-lab-limit-maximum-current = <0xc8>;
somc,qpnp-ibb-limit-maximum-current = <0x320>;
somc,qpnp-lab-max-precharge-time = <0x1f4>;
somc,qpnp-lab-soft-start = <0x320>;
somc,qpnp-ibb-discharge-resistor = <0x12c>;
somc,qpnp-lab-pull-down-enable;
somc,qpnp-lab-full-pull-down;
somc,qpnp-ibb-pull-down-enable;
somc,qpnp-ibb-full-pull-down;
somc,ewu-wait-after-touch-reset = <0x28>;
somc,lk-on-skip;
qcom,esd-check-enabled;
qcom,mdss-dsi-panel-status-command = <0x6010001 0x500010a>;
qcom,mdss-dsi-panel-status-command-state = "dsi_lp_mode";
qcom,mdss-dsi-panel-status-check-mode = "reg_read";
qcom,mdss-dsi-panel-status-read-length = <0x1>;
qcom,mdss-dsi-panel-max-error-count = <0x3>;
qcom,mdss-dsi-panel-status-value = <0x9c>;
somc,change-fps-enable;
somc,change-fps-panel-type = "uhd_4k_type";
somc,change-fps-panel-mode = "susres_mode";
somc,change-fps-command = <0x39010000 0x6f0 0x55aa5208 0x390100 0x10 0xbd00ac0c 0xc000159 0x909010e 0xc0c00b4>;
somc,driver-ic-vdisp = <0x780>;
somc,driver-ic-rclk = <0x2625a00>;
somc,driver-ic-total-porch = <0xc>;
somc,change-fps-rtn-adj;
somc,change-fps-rtn-pos = <0x1 0x6>;
qcom,dynamic-mode-switch-enabled;
qcom,dynamic-mode-switch-type = "dynamic-resolution-switch-immediate";
qcom,dcs-cmd-by-left;
qcom,mdss-dsi-display-timings {
1080p {
qcom,mdss-dsi-timing-default;
qcom,mdss-dsi-panel-width = <0x21c>;
qcom,mdss-dsi-panel-height = <0x780>;
qcom,mdss-dsi-h-back-porch = <0x12c>;
qcom,mdss-dsi-h-pulse-width = <0x28>;
qcom,mdss-dsi-h-front-porch = <0x190>;
qcom,mdss-dsi-v-back-porch = <0xa>;
qcom,mdss-dsi-v-pulse-width = <0x2>;
qcom,mdss-dsi-v-front-porch = <0xc>;
qcom,mdss-dsi-panel-framerate = <0x3c>;
qcom,mdss-dsi-panel-timings = <0x1b0606 0xb110507 0x5030400>;
qcom,mdss-dsi-t-clk-post = <0x7>;
qcom,mdss-dsi-t-clk-pre = <0x29>;
qcom,mdss-dsi-on-command = [39 01 00 00 00 00 06 f0 55 aa 52 08 00 15 01 00 00 00 00 02 c9 01 15 01 00 00 00 00 02 90 00 15 01 00 00 00 00 02 58 01 39 01 00 00 00 00 06 f0 55 aa 52 08 07 15 01 00 00 00 00 02 ef 01 39 01 00 00 00 00 06 f0 55 aa 52 08 00 15 01 00 00 00 00 02 b4 01 39 01 00 00 00 00 10 bd 00 ac 0c 0c 00 01 56 09 09 01 01 0c 0c 00 d9 15 01 00 00 00 00 02 35 00 39 01 00 00 00 00 03 44 00 00 39 01 00 00 00 00 06 f0 55 aa 52 08 01 39 01 00 00 00 00 03 d4 88 88 39 01 00 00 00 00 05 ff aa 55 a5 80 15 01 00 00 00 00 02 6f 01 15 01 00 00 00 00 02 f3 10 39 01 00 00 00 00 05 ff aa 55 a5 00];
qcom,mdss-dsi-post-panel-on-command = <0x5010000 0x129 0x5010000 0x43000111>;
qcom,mdss-dsi-on-command-state = "dsi_lp_mode";
qcom,mdss-dsi-timing-switch-command = [39 00 00 00 00 00 06 f0 55 aa 52 08 00 15 00 00 00 00 00 02 c9 01 15 00 00 00 00 00 02 90 00 15 00 00 00 00 00 02 58 01 15 00 00 00 00 00 02 03 00 39 00 00 00 00 00 06 f0 55 aa 52 08 04 15 01 00 00 00 00 02 c0 03];
qcom,mdss-dsi-timing-switch-command-state = "dsi_lp_mode";
qcom,mdss-tear-check-sync-init-val = <0xf00>;
qcom,mdss-tear-check-start-pos = <0xf00>;
qcom,mdss-tear-check-rd-ptr-trigger-intr = <0xf01>;
qcom,config-select = <0x1b5>;
qcom,mdss-dsi-panel-clockrate = <0x3595a6c0>;
};
4k {
qcom,mdss-dsi-panel-width = <0x438>;
qcom,mdss-dsi-panel-height = <0xf00>;
qcom,mdss-dsi-h-back-porch = <0x68>;
qcom,mdss-dsi-h-pulse-width = <0x28>;
qcom,mdss-dsi-h-front-porch = <0x8c>;
qcom,mdss-dsi-v-back-porch = <0xa>;
qcom,mdss-dsi-v-pulse-width = <0x2>;
qcom,mdss-dsi-v-front-porch = <0xc>;
qcom,mdss-dsi-panel-framerate = <0x3c>;
qcom,mdss-dsi-panel-timings = <0x1b0606 0xb110507 0x5030400>;
qcom,mdss-dsi-t-clk-post = <0x7>;
qcom,mdss-dsi-t-clk-pre = <0x29>;
qcom,mdss-dsi-on-command = <0x15010000 0x290 0x3150100 0x2 0x3013901 0x0 0x6f055aa 0x52080415 0x1000000 0x2c003 0x39010000 0x6f0 0x55aa5208 0x7150100 0x2 0xef013901 0x0 0x6f055aa 0x52080015 0x1000000 0x2b401 0x15010000 0x235 0x390100 0x3 0x44000039 0x1000000 0x6f055 0xaa520801 0x39010000 0x3d4 0x88883901 0x0 0x5ffaa55 0xa5801501 0x0 0x26f0115 0x1000000 0x2f310 0x39010000 0x5ff 0xaa55a500>;
qcom,mdss-dsi-post-panel-on-command = <0x5010000 0x129 0x5010000 0x43000111>;
qcom,mdss-dsi-on-command-state = "dsi_lp_mode";
qcom,mdss-dsi-timing-switch-command = [39 00 00 00 00 00 06 f0 55 aa 52 08 00 15 00 00 00 00 00 02 c9 01 15 00 00 00 00 00 02 90 03 15 00 00 00 00 00 02 58 00 15 00 00 00 00 00 02 03 01 39 00 00 00 00 00 06 f0 55 aa 52 08 04 15 01 00 00 00 00 02 c0 03];
qcom,mdss-dsi-timing-switch-command-state = "dsi_lp_mode";
qcom,compression-mode = "dsc";
qcom,config-select = <0x1b6>;
qcom,mdss-tear-check-sync-init-val = <0xf00>;
qcom,mdss-tear-check-start-pos = <0xf00>;
qcom,mdss-tear-check-rd-ptr-trigger-intr = <0xf01>;
qcom,mdss-dsi-panel-clockrate = <0x3595a6c0>;
};
};
};
config0 {
qcom,split-mode = "dualctl-split";
linux,phandle = <0x1b5>;
phandle = <0x1b5>;
};
config1 {
qcom,mdss-dsc-encoders = <0x1>;
qcom,mdss-dsc-slice-height = <0x20>;
qcom,mdss-dsc-slice-width = <0x438>;
qcom,mdss-dsc-slice-per-pkt = <0x1>;
qcom,mdss-dsc-bit-per-component = <0x8>;
qcom,mdss-dsc-bit-per-pixel = <0x8>;
qcom,mdss-dsc-block-prediction-enable;
linux,phandle = <0x1b6>;
phandle = <0x1b6>;
};
A few things to note, although may only be of interest to geeks like me...
- Despite all of the marketing info, as far as I can tell it's still running 8bpc/24bpp, not any kind of 10 bit colour. I think HDR is more a case of a brighter backlight and software filtering rather than anything else.
- Based on the panel setup commands I suspect it uses the same driver chip (NT35950) as the Z5P panel
- Both the Z5P and this panel use compression to fit 4k video in the bandwidth available (not used in 1080p mode). The former uses Qualcomm's proprietary FBC, the latter uses the newer VESA DSC. I think this may lead to slightly better quality in 4k mode, although the difference would probably never be visible.
The device tree only gives limited information about the camera, most of the camera configuration is done in a shared library (libcammw.so) which I'm also investigating. It would certainly be nice if you could tweak it to trade off framerate/resolution/record time like a pro HS camera.
In general is this all bad news?
I wouldn't necessarily say so - the lack of true 10 bit colour is a bit disappointing but I'm not sure how much difference it really makes.