Posted 7 January 2015 - 13:28
Hi.
Tested some images. Each image, that is able to record, contains the pau in /usr/bin/ and it's init script in init.d!
pau itself is closed source, so no chance to find the sources.
Using pau from another image doesn't work (look post up).
By the way, original image doesn't contain a pau.
Best regards
Mike
Posted 7 January 2015 - 13:58
open("/dev/bcm_au", O_RDWR) = -1 ENOENT (No such file or directory)
It looks for /dev/bcm_au ...
Posted 7 January 2015 - 14:15
~# ls /dev
bcm_au
but copied pau from oe-alliance or from another image is not executeable on my solo se
due to ELF error.
What I'm doing wrong?
Posted 7 January 2015 - 14:15
chmod +x ?
Posted 7 January 2015 - 14:25
of course chmod +x
readelf --symbols pau:
readelf: Error: Unable to read in 0x550 bytes of section headers
So is's definitely the binary
Posted 7 January 2015 - 14:32
Maybe binary corrupted? You can download from github directly https://github.com/o...au/pau?raw=true
md5sum pau f3c9619098980c1772415e6d8e823b61 pau
Posted 7 January 2015 - 14:37
~# ./pau
: not found 1: ELF0
./pau: line 2: syntax error: unexpected word (expecting ")")
size of that pau differs from size of the openvix pau
Posted 7 January 2015 - 14:57
hmmm strange behavior:
If I copy a binary from my solo via filezilla to my debian system and the back to my solo teh binary isn't executeable anymore, even if I do a chmod +x.
Posted 7 January 2015 - 17:08
Maybe you do ascii transfer? It worked here.
Posted 7 January 2015 - 17:52
@malakudi: you're the big boss!
I'm using debian sid and during last compilation of filezilla ftp switched to auto (I didn't realize that).
After switching to binary all works as excepted.
But it's time for a little bit reverse engeneering.
In the meantime I've different versions auf the pau binary.
All of them uses
librt.so.1
libstdc++.so.6
libm.so.6libgcc_s.so.1
libc.so.6
One of them contains 550 unreadable bytes (I don't know to handle that).
The pau from the post up instead contains crypto calls:
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000001 0 SECTION GLOBAL DEFAULT ABS _DYNAMIC_LINKING
2: 00000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses
3: 00000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main@GLIBC_2.0 (2)
4: 00408730 4 OBJECT GLOBAL DEFAULT 17 _IO_stdin_used
5: 0041b3b0 0 OBJECT GLOBAL DEFAULT 24 __RLD_MAP
6: 00402070 3100 FUNC GLOBAL DEFAULT 14 aes_setkey_enc
7: 00400998 0 FUNC GLOBAL DEFAULT 12 _init
8: 0040808c 1092 FUNC GLOBAL DEFAULT 14 B64Encode
9: 00407548 740 FUNC GLOBAL DEFAULT 14 md5_append
10: 004086d0 0 FUNC GLOBAL DEFAULT UND rand@GLIBC_2.0 (2)
11: 004086c0 0 FUNC GLOBAL DEFAULT UND puts@GLIBC_2.0 (2)
12: 00407abc 1408 FUNC GLOBAL DEFAULT 14 B64Decode
13: 00405558 276 FUNC GLOBAL DEFAULT 14 AesDecrypt
14: 0040152c 480 FUNC GLOBAL DEFAULT 14 Hex2Byte
15: 004079e0 220 FUNC GLOBAL DEFAULT 14 B64DecodeLength
16: 00401394 204 FUNC GLOBAL DEFAULT 14 RandomByte
17: 004086b0 0 FUNC GLOBAL DEFAULT UND time@GLIBC_2.0 (2)
18: 004086a0 0 FUNC GLOBAL DEFAULT UND clock_gettime@GLIBC_2.2 (3)
19: 00401a50 780 FUNC GLOBAL DEFAULT 14 B64Decrypt
20: 00408690 0 FUNC GLOBAL DEFAULT UND printf@GLIBC_2.0 (2)
21: 00401460 204 FUNC GLOBAL DEFAULT 14 Byte2Hex
22: 0040515c 744 FUNC GLOBAL DEFAULT 14 AesCtxInit
23: 00408680 0 FUNC GLOBAL DEFAULT UND strlen@GLIBC_2.0 (2)
24: 00408670 0 FUNC GLOBAL DEFAULT UND memcpy@GLIBC_2.0 (2)
25: 00401d5c 784 FUNC GLOBAL DEFAULT 14 B64Encrypt
26: 00408660 0 FUNC GLOBAL DEFAULT UND ioctl@GLIBC_2.0 (2)
27: 00408650 0 FUNC GLOBAL DEFAULT UND free@GLIBC_2.0 (2)
28: 00408640 0 FUNC GLOBAL DEFAULT UND perror@GLIBC_2.0 (2)
29: 004033c8 3780 FUNC GLOBAL DEFAULT 14 AesEncBlk
30: 00405444 276 FUNC GLOBAL DEFAULT 14 AesEncrypt
31: 00408630 0 FUNC GLOBAL DEFAULT UND memset@GLIBC_2.0 (2)
32: 0040803c 80 FUNC GLOBAL DEFAULT 14 B64EncodeLength
33: 00408620 0 FUNC GLOBAL DEFAULT UND putchar@GLIBC_2.0 (2)
34: 00408610 0 FUNC GLOBAL DEFAULT UND calloc@GLIBC_2.0 (2)
35: 00402c8c 1852 FUNC GLOBAL DEFAULT 14 AesGenKeySched
36: 00000000 0 FUNC WEAK DEFAULT UND __gmon_start__
37: 00401280 276 FUNC GLOBAL DEFAULT 14 GenRandomBytes
38: 00408600 0 FUNC GLOBAL DEFAULT UND open@GLIBC_2.0 (2)
39: 004085f0 0 FUNC GLOBAL DEFAULT UND srand@GLIBC_2.0 (2)
40: 004085e0 0 FUNC GLOBAL DEFAULT UND sprintf@GLIBC_2.0 (2)
41: 0040428c 3792 FUNC GLOBAL DEFAULT 14 AesDecBlk
42: 00000000 0 FUNC GLOBAL DEFAULT UND __gxx_personality_v0@CXXABI_1.3 (4)
and there are lots of .symtab and .dynsym entries.
Again you're wellcome for the "transfer option"....
Best regards
Mike
Posted 7 January 2015 - 22:14
I think it is a little silly to disable this option in the drivers and then release a utility that enables it. If they go to court for tax fraud, I bet no judge will believe them that the utility pau is not from them. So they better stop this nonsense.
As an EU citizen I also find it quite disturbing for a big company to try avoid taxes.
Posted 8 January 2015 - 09:37
I agree, but I'm not shure about pau. There are to much different versions. As far as I analyzed that tool it's the only ambition to provide a key for the soc.
I didn't analyze the other vu duo images (yet) if they contain a pau, too.
By the way, the info about the oe-alliance git was well. I did a git clone, because there are many usable "things" in there.
Bye
Mike
Posted 8 January 2015 - 12:39
By the way, the info about the oe-alliance git was well. I did a git clone, because there are many usable "things" in there.
Yes,; it's a pity PLi & OE-A don't have a bit of cooperation. Would be of mutual benefit.
Posted 8 January 2015 - 13:18
So why isn't it there? We don't block any cooperation.
Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)
Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.
Many answers to your question can be found in our new and improved wiki.
Posted 8 January 2015 - 15:18
LOL.....
Posted 8 January 2015 - 15:30
???
You seem to have a lot of fun by yourself. Care to share?
Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)
Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.
Many answers to your question can be found in our new and improved wiki.
Posted 8 January 2015 - 15:33
You know the story very well yourself.
Posted 8 January 2015 - 15:39
No.
We are open to cooperate with anyone. And we accept code from anyone. The only thing we require is that our standards are adhered to.
If you are suggesting otherwise, you are wrong.
Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)
Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.
Many answers to your question can be found in our new and improved wiki.
Posted 8 January 2015 - 16:05
You know I'm not suggesting anything.
And 'accepting code' isn't the same as cooperating. But that's the end of me going off-topic: you know the full story very well indeed.
Posted 8 January 2015 - 16:25
Why do you always cut discussions off when it doesn't suit you? And go on and on as like a broken record when it does?
You know very well why we don't let OE-A dictate how we operate, exactly because of a difference in opinion about standards.
So again, where are we a blocking factor in cooperating with anyone else?
Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)
Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.
Many answers to your question can be found in our new and improved wiki.
0 members, 8 guests, 0 anonymous users
