Defeating authuld protection on CI+ devices

[cyberdemon79]

Hi,

my tool is for now read-only on purpose.
Writing the hashes would be easy to implement, but I don't know
if a simple (fopen, fseek, fwrite, fclose) to /dev/bml0/3 would break
something and I would feel very bad I a TV got bricked because of my tool.
If someone has experience in modifying his hashes, could you tell me
what would be the best approach to do so ?
I think a save way is to (programatically) dump /dev/bml0/3, modify it
and reflash it (with bmlrestore). It should work, but I haven't dared to try it
So if someone could tell me if writing via fwrite (directly to /dev/bml0/3) works
I can implement it).
Then the tool could check the hashes and ask if it should correct wrong hashes.

The structure of /dev/bml0/3 is as follows (don't know if posting a dump is ok):
4096 filler bytes (I think they are all 00 or ff, don't have the TV in reach).
after that 6 hashes are stored where a hash consists of the 16-byte hash itself and a 4 byte length (of the partition or file).
The length actually specifies over how many bytes the hash is calculated.
smartsmurf used this in calculating the hash over the first 4 bytes only, stored this hash and modified the size to 4
so he can change everything after those first 4 bytes (which is a header).
The hashes are in this order: kernel, uboot, fnw, authuld, root, boot

So in a nutshell, the bml0/3 structure is:

Code: Select all

[4096 bytes]
[16 bytes kernel hash][4 bytes kernel length]
[16 bytes uboot hash][4 bytes uboot length]
[16 bytes fnw hash][4 bytes fnw length]
[16 bytes authuld hash][4 bytes authuld length]
[16 bytes root hash][4 bytes root length]
[16 bytes boot hash][4 bytes boot length]

The hashes for mtd_exe and mtd_app are stored in the macpartition file (my tool shows where to find them).
The structure of the macpartition file ist very simple:

Code: Select all

[16 byte mtd_exe hash][4 byte mtd_exe length][16 byte mtd_app hash][4 byte mtd_app length]

I hope this helps.
I don't know the order in which the hashes are checked
but mtd_exe and mtd_app should be later then the rest of them
(don't mess with the other hashes if you don't really know what you are doing).
Be very very careful when modifying the hashes you
can brick your system which every single one of them !!!
(That is why I haven't implemented the auto-update function).

cu
Cyberdemon

[juusso]

It is how i imagine process of manual flashing CI+ TV:
1. Patch firmware (or use original one)
2. Copy required images to restore for example to T-CHLCIPDEUC/image dir (TDM enabled kernel, fnw, uboot)
3. Calculate required hashes and write it to uboot_env.bin (dumped before or downloaded)
4. Place new uboot_env.bin to /image dir next to all other images
5. Run FFB (or flash images by hand)

Do i miss here something? I have sense - yes...

[mirsev]

Hello,

Where can I find the mkey value? I'm trying to calculate hashes for Samsung BD-C6900 blu-ray player but it seems that mkey and hashes are stored in a place different from those in TVs. The partition tbml3 (or /dev/bml0/3) is empty: it contains only 0xff. However, I have found the length of the file /bin/authuld (which is 36308 or 0x8DD4) in two other partitions: tbml6 and tbml8 which are copies of rootfs. This file length is at the offset 0x003ff010 (at the end_of_partition - 0x1000 + 0x10). Just 16 bytes before this there is something which looks like a hash:

tbml6:

Code: Select all

*
003ff000  7f e9 9d dc f4 c6 c6 7f  68 37 4d bc 60 87 9f 64  |........h7M.`..d|
003ff010  d4 8d 00 00 ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
003ff020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00400000

tbml8:

Code: Select all

*
003ff000  94 11 37 49 2e dd 0c 83  b4 89 c6 65 d6 33 52 95  |..7I.......e.3R.|
003ff010  d4 8d 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
003ff020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
003ff200  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00400000

However, please note that hashes are different and none of them matches with those calculated by calchash. So, it seems that mkey is different.

I suppose that mkey must be somewhere in memory since it is used by security system to calculate hashes, right? If so, then it might be that mkey for BD-C6900 is also somewhere near this place. May be I could find it if I knew where to look for...

By the way, I have found these strings in /mtd_exe/exeDSP:

Code: Select all

fsrrestore /dev/bml0/5 /mnt/nfs/Image
fsrrestore /dev/bml0/7 /mnt/nfs/Image
fsrrestore /dev/bml0/6 /mnt/nfs/rootfs.img
fsrrestore /dev/bml0/8 /mnt/nfs/rootfs.img
fsrbootwriter /dev/bml0/c /mnt/nfs/onboot.bin
fsrrestore /dev/bml0/20 /mnt/nfs/boot_image.raw
fsrrestore /dev/bml0/22 /mnt/nfs/BootSound
fsrrestore /dev/bml0/9 /mnt/nfs/cmac.bin
fsrrestore /dev/bml0/10 /mnt/nfs/cmac.bin
fsrrestore /dev/bml0/11 /mnt/nfs/key.bin

Seems like commands to flash firmware. Let's look at key and cmac:
cmac at /dev/bml0/9:

Code: Select all

00000000  cb 82 e0 47 6e ec fe 10  b7 41 5c 09 9c 34 a5 3f  |...Gn....A\..4.?|
00000010  00 50 5e 02 ef b1 16 82  2f fe 71 35 71 b9 88 f4  |.P^...../.q5q...|
00000020  bd 71 fb 14 00 c0 25 02  66 d5 0c 94 a6 2c b5 1c  |.q....%.f....,..|
00000030  f5 14 82 e7 7c 74 e2 67  48 5e 2f 00 1b 8f 9a a5  |....|t.gH^/.....|
00000040  84 6d 4d 86 24 48 2c 18  3c b9 c1 47 14 f0 3f 00  |.mM.$H,.<..G..?.|
00000050  7b ca 4c f5 f2 59 47 5a  da c2 c5 79 65 d7 d6 f1  |{.L..YGZ...ye...|
00000060  76 e2 01 00 ff ff ff ff  ff ff ff ff ff ff ff ff  |v...............|
00000070  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00040000

cmac at /dev/bml0/10:

Code: Select all

00000000  25 a3 d1 35 99 93 2d a3  d2 55 a7 49 f1 fe 75 81  |%..5..-..U.I..u.|
00000010  00 60 72 02 2c 23 83 1d  82 14 07 d1 80 60 78 90  |.`r.,#.......`x.|
00000020  c0 7d 4d 22 00 c0 40 02  60 a8 d9 99 f3 b6 da 20  |.}M"..@.`...... |
00000030  c5 8a 3e b2 05 6d 43 d6  48 5e 2f 00 b0 da c7 4b  |..>..mC.H^/....K|
00000040  78 a6 81 41 49 18 7c f4  d6 60 f1 f5 14 f0 3f 00  |x..AI.|..`....?.|
00000050  7b ca 4c f5 f2 59 47 5a  da c2 c5 79 65 d7 d6 f1  |{.L..YGZ...ye...|
00000060  76 e2 01 00 00 00 00 00  00 00 00 00 00 00 00 00  |v...............|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00040000

key at /dev/bml0/11:

Code: Select all

00000000  f0 f0 fe fa 86 d4 46 c9  47 76 56 00 a4 a8 30 98  |......F.GvV...0.|
00000010  e6 ee 7a e2 ff ff ff ff  ff ff ff ff ff ff ff ff  |..z.............|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00040000

Again, cmac data are different. Strange? Also, I tried to use data from /dev/bml0/11 as mkey, but it does not work...

Any idea?

[juusso]

I want to add support of CI+ devices to FFB, but don`t have any other idea than collect full set of firmwares together with bml0/3 partition where hashes are stored. But this way is a bit dirty and i don`t know if it`s enough to flash bml0/2-bml0/7 and stl0/8-9(or stl0/10-11) to get TV working (where does macpartition file exist on TV?)

Latest CI+ firmwares disallow users to rollback because of disabled shell access over console and rolling back to another restricted firmware if such exists.

Partition hashes, monitored by authuld are listed here
(starting offset 0x00001000)

We even have tool, which calculates hashes on TV and compares it to existing on bml0/3 partition.

The mtd_exe and mtd_appdata hashes stored on macpartition file. How to write correct hashes to that file?

I know it takes a while before hashes are calculated on TV (longer than Authuld reboots TV), so more time is needed to calculate and write required data to TV.

Sure, hashes could be calculated manually on PC and edited with help of any HEX editor. But i`m thinking not every user who decides roll back CI+ TV could do that easily and don1t brick TV. In other hand i want to add it to FFB, where hashes could be calculated and written automatically.

I see few ways to do that:

1. Firmware files are extracted to TV`s rwarea and calchash calculates required hashes and CREATES image of bml0/3 with correct hashes on it. After that all images were flashed to TV.

Problem: how to create that bml0/3 image? i haven`t seen any solution for B series. Just some Denny`s and mirsev`s tools for C series.

2. The same as first, but required hashes are to flash directly (inject? edit?) to it`s required place right after firmware flashing procedure is done.

3. Some kind python script is needed to calculate hashes on PC. But if we`re not going to change other partitions, just only appdata and exe.img, then how do we calculate other required hashes out of TV?


This problem still remains open and none finalizes this job. Any ideas?

[juusso]

After some tests on CI+ device and conversation to smart people i can say i got answers to my questions (with some notices for future).

Sadly cyberdaemon did not continued his work on defeating authuld on B series. Let me concentrate info of this thread (everything related to B series only)

According research here, some tests with calchash tool on different devices, i can make some conclusions:
Examples are from LE40B550A5P

To flash preFEB firmware manually (or automatically) to the CI+ device is needed:

1. Precalculated hash and written to right strMacPartition (from authuld debug log):

   Code: Select all

   strMacPartition1 = (/dev/bml0/14)
   strMacPartition2 = (/dev/bml0/15)
   strMackeyPartition = (/dev/bml0/16)

   Some explanation:
   depending of what firmware is used (PartitionSwitch_0_0 or PartitionSwitch_1_0 is selected),
   the strMacPartitions are checked by Authuld and hashes calculated.
   Those hashes are to compare to hashes on firmware partitions:
   • stl0/8 and stl0/9 (strMacPartition1 = /dev/stl0/14)
   • stl0/10 and stl0/11 (strMacPartition2 = /dev/stl0/15).
   If hashes don`t match, TV reboots.
   If everything fine, TV boots up, authuld is finished its job.

   Code: Select all

    authuld 1
   ====================================================
   
                Authuld Version : 1.6 : DEV
   
   ====================================================
   [INFO]  /dtv/.secure_booting file created for execution of this program
   [INFO]  sem_key = 1929773086
   [INFO]  Attempting to create new semaphore set with 1 members
   [INFO]  Semaphore set already exists!
   [INFO]  Warning...!!! There is no data.
   [INFO]   flash type : 128 MB
   [INFO]  strMacPartition1 = (/dev/bml0/14)
   [INFO]  strMacPartition2 = (/dev/bml0/15)
   [INFO]  strMackeyPartition = (/dev/bml0/16)
   [INFO]  authuld : normal boot
   [INFO]  mkey is not dev!
   [INFO]  waiting 15 sec for executing other jobs
   [INFO]  -----------------------
   [INFO]  ---- CI integrity checking for file /dev/bml0/6...
   [INFO]   --- input size = 3387392
   [INFO]  with Cmac (SE)
   [INFO]  Hash checking is Verified
   [INFO]  -----------------------
   [INFO]  ---- CI integrity checking for file /dev/bml0/7...
   [INFO]   --- input size = 786432
   [INFO]  with Cmac (SE)
   [INFO]  Hash checking is Verified
   [INFO]  mounted exeDsp = /dev/stl0/10
   [INFO]  mounted appData = /dev/stl0/11
   [INFO]  -----------------------
   [INFO]  ---- CI integrity checking for file /dev/stl0/10...
   [INFO]   --- input size = 13746176
   [INFO]  with Cmac (SE)
   [INFO]  Hash checking is Verified
   [INFO]  -----------------------
   [INFO]  ---- CI integrity checking for file /dev/stl0/11...
   [INFO]   --- input size = 16580608
   [INFO]  with Cmac (SE)
   [INFO]  Hash checking is Verified
   [INFO]  success=23, nonce=-1
   [INFO]  /dtv/.secure_booting is deleted

2. Changing only firmware (exe.img and appdata.img) does not require any change of hashes, stored on bml0/3
3. If u-boot/fnw/kernel/rootfs/boot is needed to flash, hashes required to be (p)re-calculated and flashed to bml0/3.
4. Hash structure on MacPartition is exact as mentioned:

   Code: Select all

   [16 byte mtd_exe hash][4 byte mtd_exe length][16 byte mtd_app hash][4 byte mtd_app length]

5. The flash size and MacPartition number for different TV`s ( is detected by cyberdaemon`s calchash.
   128Mb (T-CHL5CIPDEUC)

   Code: Select all

      flashtype=128;
      strcpy(macpartition[0], "/dev/bml0/14");
      strcpy(macpartition[1], "/dev/bml0/15"); 

   1Gb (T-CHLCIPDEUC)

   Code: Select all

         flashtype=1000;
         strcpy(macpartition[0], "/dev/bml0/18");
         strcpy(macpartition[1], "/dev/bml0/19"); 

   2Gb (T-CHUCIPDEUC)

   Code: Select all

         flashtype=2000;
         strcpy(macpartition[0], "/dev/bml0/16");
         strcpy(macpartition[1], "/dev/bml0/17"); 

I only doubt for what stl0/16 is used? What else is checked here?
If compare two bml0/16 (from different versions of the same firmware), they differ:

Code: Select all

# hexdump -C /dev/bml0/16
00000000  27 07 79 19 bd ed 6c 1e  21 1e 51 8c 75 f2 3d 4b  |'.y...l.!.Q.u.=K|
00000010  72 e4 a9 66 27 07 79 19  ff ff ff ff ff ff ff ff  |r..f'.y.........|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00020000
#

and the second firmware:

Code: Select all

# hexdump -C /dev/bml0/16
00000000  27 07 79 19 bd ed 6c 1e 21 1e 51 8c 75 f2 3d 4b  |'.y..'...\4+Z|8.|
00000010  72 e4 s9 66 27 07 79 19  ff ff ff ff ff ff ff ff  |.j*.'.y.........|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00020000
#

Anyone knows what is used third strMacPartition for?

[arris69]

....
Anyone knows what is used third strMacPartition for?

what partition is ~400 MB big on this models?

arris

[juusso]

About bml0/16 partition (on B550 or 128Mb device)

Our old user Langerhans remembered me about research of petergrey. He found, that script, called emergency.sh is executed right from ExLink TD debug menu if correct password is entered:

Code: Select all

TDM>TD>9115

emergency.sh

#!/bin/sh
echo Hello world!

Code 9115 is valid only on CI+ devices and not for CI.

Here is the tool, which shows that password (and not only) for device .
To get password, place extracted patcher binary to USB and execute in telnet:

Code: Select all

/dtv/usb/sda/patcher /dev/mem /dtv/usb/sda/patch.ini patch2 patch

Here are more args (look at the patch.ini):

[ patch1 ]
Description = kernel patch for enabling keyboard input
[ patch2 ]
Description = prints out magic number for emergency.sh
[ patch3 ]
Description = enable all reading of all memory 1/2
[ patch4 ]
Description = enable all reading of all memory 2/2

and so on...

According that info (only one source...) the strMackeyPartition is needed to calculate password for executing emergency.sh. The structure of that partition:

Code: Select all

[4 bytes magic][16 bytes seek][4bytes magic]

This could be seen on bml0/16 examples of different firmwares. 4 bytes at the beginnig and 4 bytes after seek code are same...
p.s. i just noticed the codes are same. Sorry, i confused my self and lost example of the other firmware...

So the strMackeyPartition is not needed for firmware flashing, but we could flash it with known password to call emergency.sh.

[juusso]

While studying dumps of B650T2P (T-CHLCIPDEUC-2006.0), i noticed one block with data on 18th bml partition, which isn't described anywhere.

This macPartition is in use with 1nd (PartitionSwith_0_0) firmware and it's currently inactive (alternative).
At the end we have [16 bytes] hash? + [4 bytes] file length. (rootfs?)
Is it possible, that some data is being calculated and written to another strMacPartition during/after firmware upgrade?

/dev/bml0/18:

Code: Select all

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00000000   CC 33 98 3C 70 EE 40 D6  03 57 AE 9F 17 6E 6C F6
00000010   00 10 3C 03 F3 E0 8E 2D  69 9A C2 76 CE 07 08 71
00000020   3A 9A 0B 2D 00 D0 C9 01  00 00 00 00 00 00 00 00
00000030   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
*                
00000240   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
00000250   00 00 00 00 00 00 00 00  59 D7 D6 22 43 D2 7B 35 
00000260   3B AA 32 69 67 0E 9C 50  00 10 33 00 FF FF FF FF   
*
0100000 

In the same time active partition (hashes stored on bml19) does not have any hex data at the end:

/dev/bml0/19:

Code: Select all

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00000000   D9 60 B5 82 B2 AD 80 EB  32 03 C6 BC 23 73 5B CA
00000010   00 F0 40 03 07 7C B3 32  41 EC CD B1 DD F0 40 FD
00000020   F4 21 82 9D 00 D0 CA 01  00 00 00 00 00 00 00 00
00000030   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
*
00000240   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
00000250   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
00000260   00 00 00 00 00 00 00 00  00 00 00 00 FF FF FF FF
*
0100000 

Here is bml0/3 block with hashes:

Code: Select all

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00001000   26 7A 0E F7 6F F0 E4 9F  79 1B C5 74 54 10 2E D9
00001010   E0 3C 2F 00 72 AB F2 09  A8 EA D4 BC E5 4B 24 A8
00001020   7B 1D F6 BB DC 21 04 00  62 41 92 96 D0 4C 2F B1
00001030   17 00 81 0F B5 78 47 CA  B4 BA 02 00 3D 8A 03 F3
00001040   1C F0 B8 15 30 A1 4B F7  42 D8 4D FA B8 95 00 00
00001050   C0 D5 C5 4B BF 04 E5 28  EF 3B C8 4A 5B 75 AA 07
00001060   00 10 33 00 B0 5A B0 71  00 32 84 11 E2 F7 FE 45 
00001070   A4 83 FE 5E 00 E0 0D 00  79 F0 81 7F 56 65 61 93 
00001080   00 10 31 00 81 6A A0 6C  0A 06 A3 94 23 F4 06 2E
00001090   B8 F0 68 3E 00 B0 0D 00  92 4C 61 38 A1 1A F0 0B
000010A0   61 ED FA E0 CB 5B 01 FC  00 90 4A 03 93 81 18 AE
000010B0   94 9C D6 BE CD 6F 02 22  00 4C 4C 02 00 90 C5 01
000010C0   92 4C 61 38 A1 1A F0 0B  61 ED FA E0 CB 5B 01 FC
000010D0   00 90 4A 03 93 81 18 AE  94 9C D6 BE CD 6F 02 22

To have full view, here are some data (hashes, file length) of all ro partitions of this firmware:

bml0/1

Code: Select all

0005858C = 361864

./chkhash -k 7CED26D8CA2FA0F80BC637E2FF07EC46 -h 361864 bml0_1
Hash: 97 06 17 36 f6 07 4e e4 38 02 ad 08 2e d8 4a 2e, length = 361864

bml0/2

Code: Select all

000421DC = 270812

./chkhash -k 7CED26D8CA2FA0F80BC637E2FF07EC46 -h 270812 u-boot.bin
Hash: 72 ab f2 09 a8 ea d4 bc e5 4b 24 a8 7b 1d f6 bb, length = 270812

bml0/3

Code: Select all

00020000 = 131072

./chkhash -k 7CED26D8CA2FA0F80BC637E2FF07EC46 -h 131072 bml3.bin
Hash: f1 5f b7 da 15 e0 91 a2 8c 59 cc 33 c6 04 f5 6b, length = 131072

bml0/4

Code: Select all

0002BAB4 = 178868

./chkhash -k 7CED26D8CA2FA0F80BC637E2FF07EC46 -h 178868 fnw.bin
Hash: 62 41 92 96 d0 4c 2f b1 17 00 81 0f b5 78 47 ca, length = 178868

bml0/5

Code: Select all

002F3CE0 = 3095776

./chkhash -k 7CED26D8CA2FA0F80BC637E2FF07EC46 -h 3095776 Image
Hash: 26 7a 0e f7 6f f0 e4 9f 79 1b c5 74 54 10 2e d9, length = 3095776

bml0/6

Code: Select all

00331000 = 3346432

./chkhash -k 7CED26D8CA2FA0F80BC637E2FF07EC46 -h 3346432 rootfs.img
Hash: c0 d5 c5 4b bf 04 e5 28 ef 3b c8 4a 5b 75 aa 07, length = 3346432

bml0/7

Code: Select all

000DE000 = 909312

./chkhash -k 7CED26D8CA2FA0F80BC637E2FF07EC46 -h 909312 boot.img
Hash: b0 5a b0 71 00 32 84 11 e2 f7 fe 45 a4 83 fe 5e, length = 909312

Firmware partitions (T-CHLCIPDEUC 2003.0) currently inactive (PartitionSwitch_0_0)

Code: Select all

bml0/8
033C1000 = 54267904

./chkhash -k 7CED26D8CA2FA0F80BC637E2FF07EC46 -h 54267904 exe.img
Hash: cc 33 98 3c 70 ee 40 d6 03 57 ae 9f 17 6e 6c f6, length = 54267904

bml0/9

Code: Select all

01C9D000 = 30003200

./chkhash -k 7CED26D8CA2FA0F80BC637E2FF07EC46 -h 30003200 appdata.img
Hash: f3 e0 8e 2d 69 9a c2 76 ce 07 08 71 3a 9a 0b 2d, length = 30003200

T-CHLCIPDEUC 2006.0, currently active (PartitionSwitch_1_0)
bml0/10 (exe.img)

Code: Select all

0340F000 = 54587392

./chkhash -k 7CED26D8CA2FA0F80BC637E2FF07EC46 -h 54587392 exe.img
Hash: d9 60 b5 82 b2 ad 80 eb 32 03 c6 bc 23 73 5b ca, length = 54587392

bml0/11

Code: Select all

01CAD000 = 30068736

./chkhash -k 7CED26D8CA2FA0F80BC637E2FF07EC46 -h 30068736 appdata.img
Hash: 07 7c b3 32 41 ec cd b1 dd f0 40 fd f4 21 82 9d, length = 30068736

Calculations were done with Denny`s tool for C series (recompiled for B series). Any hints about 16 bytes on bml0/18 are welcome ...

p.s. switching between firmwares does not affect to strMacPartition1 and2, as well as to strMackeyPartition, so they remain unchanged.

[mirsev]

What is the difference between chkhash tool for C and B series? Do you run it on PC or inside TV?

To search for files whose hashes are present in bml0/3 you may try to run chkhash with -L option.

[juusso]

Hi, mirsev,
i recompiled chkhash (firstly made for C series) for my NAS (arm5 cpu), so i run those calculations from dumps. I don`t have B series CI+ device, but on my TV (CI) the chkhash works too. But my problem, i have nothing to calculate on TV

Need more dumps from different models to compare...

BTW, I couldn't run chkhash with -L properly, it does not gave any output. Neither error nor result