WEBVTT 00:04.000 --> 00:07.260 Okay, I'm from China. 00:07.260 --> 00:10.460 The title of my presentation is Hacking Windows C. 00:10.460 --> 00:16.260 It's about the security problems of PDAs and mobiles. 00:17.620 --> 00:22.100 My presentation is constructed with eight parts. 00:22.100 --> 00:40.700 First of all, I'll make a brief introduction of Windows C, because ARM processors is the most useful processor in PDAs and mobiles, so I'll introduce the ARM processor's architecture. 00:41.540 --> 00:46.820 You know, understanding memory management is very important for Buffalo Flow. 00:46.820 --> 00:53.020 The second, I'll introduce memory management with graphics. 00:53.500 --> 01:01.060 Compared with other Windows systems, Windows C chooses processes in a different way. 01:01.500 --> 01:08.900 Then I'll introduce the features of processes and threads of Windows C. 01:09.700 --> 01:16.200 The Windows C API search technology is funny. 01:16.240 --> 01:24.780 I'll introduce how to write shellcode using this method. 01:24.860 --> 01:33.220 And I will also introduce the implementation of system code and use it to write shellcode. 01:33.220 --> 01:38.340 After this, I'll demonstrate a simple Buffalo Flow. 01:38.580 --> 01:44.260 Well, I think this technology will be improved in the future. 01:44.900 --> 01:50.220 Then I'll talk something about decoding shellcode. 01:50.220 --> 01:59.620 The decoding shellcode will make the real shellcode more universal, but ARM processor's cache architecture makes it funny. 02:00.240 --> 02:03.200 At last, I'll conclude my presentation. 02:03.960 --> 02:07.420 Okay, let's move on to the next part, the first part. 02:08.400 --> 02:15.440 Windows C is a very popular embedded operating system for PDAs and mobiles. 02:15.440 --> 02:19.100 The name is developed by Microsoft. 02:20.860 --> 02:31.280 Because of the familiar APIs, Windows developers can easily develop applications for Windows C. 02:31.280 --> 02:37.200 Maybe this is a very important reason that makes Windows C popular. 02:37.480 --> 02:49.140 Windows C file is the latest version, but Windows C.net is the most useful version, and my presentation is based on this version. 02:51.060 --> 03:06.060 Maybe for marketing reasons, there is Windows mobile software for pocket PC and a smartphone in Microsoft's website and MSDN, but they are all based on the core of Windows C. 03:06.060 --> 03:13.440 By default, Windows C is in little Indian mode and it supports several processes. 03:15.160 --> 03:22.620 Almost all of the embedded devices will use ARM CPU. 03:23.080 --> 03:32.540 ARM processor is a typical RISC processor, which implements a load store architecture. 03:32.540 --> 03:36.720 Only load and store instructions can access memory. 03:36.720 --> 03:44.340 Data operating instructions operate on RISC contents only. 03:44.980 --> 03:50.560 There are six major versions of ARM architecture. 03:50.720 --> 04:12.180 The demonstrated device has a Samsung S3 C2410 processor, which has an ARM 9 core and the architecture version is an ARM V4T. 04:12.180 --> 04:23.100 More and more PDAs are using Intel X scale processor, which architecture version is V5TE. 04:24.680 --> 04:33.940 ARM processors support seven processor modes, depending on the architecture version. 04:34.540 --> 04:43.420 These modes are user, FIQ, IRQ, supervisor, undefined, abort and system. 04:43.420 --> 04:49.520 The system mode requires ARM architecture V4 and above. 04:49.520 --> 04:55.280 All modes except the user mode are referred to privileged mode. 04:55.840 --> 05:09.700 Applications usually are running user mode, but on the pocket PC, all applications appear to be running in kernel mode. 05:09.960 --> 05:14.000 I'll talk about it later. 05:15.840 --> 05:22.340 Windows ARM processor has 39 registers. 05:22.340 --> 05:28.160 These registers are arranged in partially overlapping banks. 05:28.760 --> 05:33.860 There's different registers for each processor mode. 05:34.820 --> 05:49.520 The bank registers give rapid context switching for dealing with processor exception and privileged operations. 05:50.320 --> 06:10.840 In ARM architecture V3 and above, there are 30 general purpose registers, the program counter register, the current program status register and the file saved program status register. 06:12.080 --> 06:21.000 15 general purpose registers are visible at any one time, depending on the processor mode. 06:21.520 --> 06:30.700 By convention, R13 is used as a stack point in ARM assembly language. 06:30.700 --> 06:37.420 The C and the C++ compilers always use R13 as a stack point. 06:39.300 --> 06:53.600 In user mode and system mode, R14 is used as a link register, which stores the return address while a subroutine call is made. 06:54.460 --> 07:01.440 The program counter register is accessed as R15. 07:01.700 --> 07:08.640 It can access directly by data processing instructions. 07:09.200 --> 07:19.440 This feature is different from other processors and it is useful for code location while writing show code. 07:23.060 --> 07:29.780 You know, understanding memory management is very important for buffer overflow. 07:30.320 --> 07:40.160 But Windows C, but compared to other Windows systems, Windows C chooses memory management in a different way. 07:40.160 --> 07:44.100 Windows C uses ROM and RAM. 07:44.100 --> 07:52.740 The ROM in the Windows C system is just like a small read on a hard disk. 07:52.740 --> 08:02.020 It stores the entire operating system as well as the applications that are bundled in the system. 08:02.300 --> 08:11.140 The data, um, the data can maintain inside the ROM without power or battery. 08:11.580 --> 08:17.100 The RAM in a Windows C system is divided into two areas. 08:17.100 --> 08:20.760 The program memory and object store. 08:20.760 --> 08:27.980 The object store can be considered something like a permanent virtual RAM disk. 08:28.060 --> 08:33.400 It's unlike a RAM disk in the PC. 08:34.880 --> 08:42.260 It can maintain the files in it, uh, even if the system turned off. 08:42.260 --> 08:52.400 That, that is the reason that, this is the reason that Windows C devices typically have a main battery and a backup battery. 08:52.480 --> 09:01.160 They provide the power to my, to the RAM to maintain the files stored in it. 09:01.500 --> 09:10.940 Even when the user hit the reset button, the Windows C kernel starts up looking for previously created object store. 09:11.360 --> 09:18.200 Um, the system will use that store if it finds one. 09:20.900 --> 09:29.000 Another area of Windows C RAM is program memory. 09:29.000 --> 09:32.900 Program memory is just like the RAM in the PC. 09:33.100 --> 09:41.460 Uh, it stores the heaps and the stacks that, uh, the application, for applications that are running. 09:41.780 --> 09:51.440 Um, the, the dividing of the, between the object store and the program memory is adjustable. 09:51.440 --> 09:58.960 The user can move the dividing line, uh, by the system control panel applet. 09:59.940 --> 10:08.900 Windows C is a, um, 32-bit operating system, so it supports 4GB virtual address space. 10:09.260 --> 10:12.120 Let's look at this graph. 10:12.120 --> 10:17.120 This is the, um, 4GB virtual address space layout. 10:26.030 --> 10:35.110 The upper 2GB is, uh, used for, used by, is a kernel space used by a system for its own data. 10:35.110 --> 10:38.230 And the lower 2GB is a user space. 10:38.630 --> 10:52.150 From this address, uh, to below this address, the memories are used to, um, um, uh, larger memory, larger memory allocation. 10:52.150 --> 10:57.890 Such a, uh, it's used by the, uh, such as memory mapped files. 10:58.050 --> 11:01.730 Um, um, object store is loaded here. 11:01.730 --> 11:11.170 And from zero to below, this, uh, uh, this memory is, uh, divided into 33 slots. 11:11.690 --> 11:14.610 Each of which is a 32MB. 11:17.980 --> 11:24.220 The slot 1 is, uh, uh, XIP, uh, executed in place. 11:24.220 --> 11:28.920 This is a new feature, uh, of the Windows C.net. 11:29.120 --> 11:38.660 Uh, it expanded the application's virtual address space from 32MB to 64MB. 11:42.460 --> 11:52.800 Well, this graph is, uh, is the slot 0 virtual address space layout. 11:52.800 --> 11:55.280 Slot 0 is very important. 11:55.280 --> 12:01.180 It's, uh, used by the current active process. 12:01.980 --> 12:07.360 The first 64KB is, uh, reserved by the OS. 12:07.360 --> 12:14.380 And the following is the process's code, code and data. 12:16.680 --> 12:21.000 Um, stacks and heaps are arranged here. 12:21.980 --> 12:26.260 DLL files are loaded into the top, uh, top address. 12:31.350 --> 12:34.350 Well, let's move on to the next part. 12:34.810 --> 12:43.310 Um, uh, compared with other, uh, system, Windows C.net chooses processes in a different way. 12:43.330 --> 12:48.890 Windows C.net limits, uh, 32 processes being run at any one time. 12:48.990 --> 12:54.770 Uh, when the system starts, at least four processes are created. 12:54.850 --> 13:00.530 Um, let's look at the previous, uh, graph. 13:02.490 --> 13:07.310 NKEXE, uh, which provides the kernel service. 13:07.310 --> 13:12.150 It's always loaded into the slot 97. 13:12.690 --> 13:20.590 Um, filesystem.exe, which provides the filesystem service. 13:20.590 --> 13:23.570 It's always in slot 2. 13:23.730 --> 13:34.010 Device.exe, which, uh, which, uh, load and maintains the device drivers for system. 13:34.010 --> 13:36.630 It's in slot 3 normally. 13:36.630 --> 13:43.470 And, uh, GWES.exe, which provides GUI support. 13:44.070 --> 13:50.150 The other processes are also created such as explorer. 13:53.010 --> 14:01.950 Um, the, uh, other Windows system. 14:02.210 --> 14:09.630 Each process, at least, has a primary thread, uh, associated it, uh, up on start. 14:09.670 --> 14:12.890 Uh, if it never, never created one. 14:13.650 --> 14:21.890 One process, uh, can create any number of threads only limited by the available memory. 14:22.270 --> 14:29.970 Um, each thread belongs to a particular, uh, process and shares the same memory. 14:29.970 --> 14:41.070 But the, uh, set prog permissions API, uh, can give the, um, current thread access any, any process. 14:42.030 --> 14:48.450 Each thread has an ID, a private stack, and a set of registers. 14:48.450 --> 14:58.450 When the process is, uh, loaded, uh, the system will assign the next, uh, available slot to it. 14:58.450 --> 15:06.430 And DL files loaded into the top address of the, um, uh, uh, uh, address space. 15:06.430 --> 15:10.830 And then followed by the stack and the default process heap. 15:10.830 --> 15:13.830 After this, then execute it. 15:14.750 --> 15:25.650 Uh, when the, uh, when the process is, the thread is scheduled, the system will copy, uh, copy from its slot to slot zero. 15:25.650 --> 15:32.690 It's not a real copy operation, it's just mapped into the slot zero. 15:33.190 --> 15:41.610 Uh, this is mapped back to the original slot allocated to the process if the process becomes inactive. 15:50.730 --> 15:55.310 Process, uh, allocated stack for each thread. 15:55.350 --> 16:04.290 The default size is, uh, 64 KB, uh, depending on the link parameter when the, uh, program is compiled. 16:04.290 --> 16:08.730 This, uh, this size can, can, can be modified. 16:09.070 --> 16:14.690 The top two KB is used to guard against the stack overflow. 16:14.690 --> 16:21.010 We can't destroy this memory, otherwise the device will freeze. 16:21.890 --> 16:25.270 And the remainder, uh, available for use. 16:25.270 --> 16:31.510 Um, variables declared inside the function are allocated in the stack. 16:32.010 --> 16:37.510 Um, thread stack memory is reclaimed when it terminates. 16:39.770 --> 16:42.830 Well, let's move on to the next part. 16:42.830 --> 16:50.250 Um, before, before exploit, we must have, uh, share code to run on the Windows CE. 16:50.250 --> 16:56.810 Um, Windows CE implements, uh, V32 compatibility. 16:56.850 --> 17:09.930 The core DLL provides the entry points for, uh, for the, for almost all the APIs that implement, uh, that in the core DLL. 17:10.110 --> 17:29.680 Um, um, um, we must, uh, search the, uh, necessary API addresses, um, and then you use this, uh, uh, API address, APIs to implement our share code. 17:29.680 --> 17:56.060 The traditional method to implement, uh, uh, share code, uh, in the, uh, other Windows system is to, uh, locate the kernel 32 or NTDL, uh, via PB structure and then search, uh, search necessary APIs via, uh, P head structure. 17:56.380 --> 18:02.740 Well, is there any structure like, um, PB on the Windows CE? 18:02.740 --> 18:05.020 The answer is yes. 18:05.020 --> 18:12.480 That's, um, the kernel, the, uh, K data structure will satisfy those. 18:13.500 --> 18:17.780 The defined in NK arm.h. 18:20.360 --> 18:36.620 Uh, K data structure is, uh, is a very important kernel, uh, kernel structure can be accessed from user mode by fixed, uh, address, uh, K user, uh, P user K data. 18:36.680 --> 18:46.940 Um, the value over, uh, the value over P user K data is defined in the, uh, K functs. 18:46.940 --> 18:49.280 It's in the normal SDK. 18:49.580 --> 19:09.880 Um, uh, the value, uh, the P user K data is, uh, FFFC800 in ARM processors and, uh, file 8, uh, file 8, uh, file 8, uh, file 8, uh, file 8, uh, file 8, uh, file 8, 800 on the, uh, other CPUs. 19:14.740 --> 19:21.120 Well, let's look at the last member of, uh, K data structure. 19:21.120 --> 19:28.840 Um, it's offset 300 from the start of K data structure. 19:32.240 --> 19:36.200 Um... There is, uh, 19:41.120 --> 19:56.440 the, uh, the, uh, the, um, AIN4 is a DWORD array and there is a point to the module list index 9. 19:56.440 --> 20:09.340 So offset 3 to 4 from the FFFC800 is the point to the module list. 20:09.800 --> 20:13.840 Well, let's look at the module structure. 20:13.840 --> 20:18.120 The first member is defined in kernel header file. 20:26.840 --> 20:31.360 The second member is P mode. 20:31.360 --> 20:37.400 It's a point to the next module of the module chain. 20:39.100 --> 20:45.040 The third member is LPSZ mode name. 20:45.420 --> 20:51.300 It's a module name string. 20:51.300 --> 21:01.460 So we can locate the core DLL by comparing the unicode string of its name. 21:04.110 --> 21:08.450 Well, we also notice the E32 member. 21:09.290 --> 21:11.910 Let's look at this. 21:12.810 --> 21:17.590 E32 member is the E32 structure. 21:17.590 --> 21:18.810 It's defined in kernel header file . 21:18.810 --> 21:22.030 The third member is P HDR. 21:23.330 --> 21:28.450 Well, let's look into the E32 structure. 21:28.450 --> 21:36.090 The E32 V base will tell us the virtual base address of the module. 21:36.110 --> 21:42.590 So we can locate the virtual base address of the core DLL. 21:42.890 --> 21:49.130 We also notice the last member is E32 unit. 21:50.170 --> 21:55.110 It's an info structure and the info structure has two members. 21:55.110 --> 22:01.950 The first is the virtual relative address and the second is the size. 22:03.150 --> 22:10.230 And the little extra is defined in the P HDR. 22:10.450 --> 22:12.710 The start of P HDR. 22:13.730 --> 22:18.570 Six members used by NK. 22:18.570 --> 22:23.170 And the first is the export table position. 22:23.370 --> 22:42.530 So from now on, we got the virtual base address of the core DLL and its export table relative address of the export table position. 22:45.090 --> 23:10.510 And I wrote a small... I wrote a small program to list all the virtual base address of all loaded DLL files. 23:11.610 --> 23:15.250 This is the KData structure. 23:15.730 --> 23:28.410 And offset 324 is a point to the module structure. 23:28.770 --> 23:32.130 And the module structure is the chain structure. 23:32.770 --> 23:39.090 The offset 4 will point to the next module. 23:39.090 --> 23:40.030 So what is the point to the module structure ? 23:40.350 --> 23:49.610 Well, the point to the module structure is in the kernel space. 23:50.490 --> 24:01.250 So this program only... this program only executed in the kernel mode. 24:01.250 --> 24:06.010 The user mode... it will fail in the user mode. 24:06.970 --> 24:17.450 Well, the most of the PC ROMs were built with the full kernel mode option. 24:17.930 --> 24:22.810 That's the applications all running kernel mode. 24:27.030 --> 24:36.090 So... so this small program will execute in the most of the pocket PC. 24:38.970 --> 24:50.470 I used this program to call the virtual base address of the core DLL is 1F6000. 24:50.730 --> 24:57.990 But when I use the EBC debug to look into, this address is invalid. 24:57.990 --> 25:03.750 The valid data is from 1F61000. 25:05.030 --> 25:23.430 I think maybe the Windows C is just for the purpose to... purpose over memory and start time and then load the head of the DLL file. 25:35.120 --> 25:36.040 Okay. 25:36.080 --> 25:43.900 The VNCE4.dust uses ordinals to find the API address. 25:43.900 --> 25:54.020 But I think use API name to find the... to find the API address is more reliable for share code. 25:54.020 --> 26:02.320 Because the API name won't change even if the core DLL file is changed. 26:06.280 --> 26:18.220 Well, we can... because we have the export table position and the base address of the core DLL. 26:18.220 --> 26:36.280 So we can use the... we can compare the image export directly to find the API address via API name. 26:36.280 --> 26:47.840 To save size, we can use the hash technology that from the LSD's V32 assembly components. 26:50.940 --> 26:58.640 And this is... this graph is ripped from LSD's V32 assembly components too. 26:58.640 --> 27:07.720 And it shows the way to locate the base address via API name. 27:11.780 --> 27:15.140 Well, let's move on next part. 27:15.220 --> 27:21.260 The test ASM is our final share code. 27:26.540 --> 27:29.580 It constructs with three parts. 27:29.580 --> 27:48.340 First, it will call get export section to get the virtual base address of the core DLL and its relative virtual address over export table position. 27:48.420 --> 28:01.820 And then it uses find function to find the API address via the hash value over the API name. 28:01.820 --> 28:14.960 And then stores the... find the... store the API address to the... its own hash value position. 28:15.500 --> 28:23.180 The last part is our implementation of our share code. 28:23.180 --> 28:36.400 It will change the register key over Bluetooth and then use kernel IO control to soft restart it. 28:45.030 --> 28:55.290 This share code will open the Bluetooth over some... we 29:08.460 --> 29:19.580 must notice the some... some assembly LDR pseudo instruction. 29:19.840 --> 29:23.400 Here, what I comment of this instructions. 29:27.040 --> 29:37.770 Because... because this pseudo instruction will be this in the EVC debug. 29:37.770 --> 29:40.810 It depend on the program. 29:41.790 --> 29:49.530 So, it won't get the FFF C800 in the share code. 29:50.730 --> 29:55.210 So, this instruction will make the share code fail. 29:55.210 --> 30:02.330 And the next instruction will be this in the EVC debug. 30:02.330 --> 30:04.190 It's okay. 30:05.210 --> 30:20.130 Well, in Windows CE, the R3 and... R0 and R3 use the first to fourth parameters of the API. 30:20.950 --> 30:31.110 If the... if the parameter is larger than four, the other parameters will store in the stack. 30:31.110 --> 30:35.250 So, we must pay attention while writing share code. 30:35.250 --> 30:36.150 Because the... 30:36.150 --> 30:42.590 because the share code always in the stack... stack memories. 30:45.430 --> 30:52.690 Well, EVC debugger has some bugs that make... make debugger difficult. 30:53.030 --> 31:03.110 The first, EVC will change the stack contents when the stack... in the end of the function. 31:03.210 --> 31:09.330 Well, it's... it's difficult to debug the buff overflow. 31:09.830 --> 31:14.350 Because the share code may be changed. 31:14.970 --> 31:25.570 And the instruction or the break point may be changed to E600010 in EVC sometimes. 31:25.570 --> 31:29.130 Well, it's... it's very bothering. 31:30.010 --> 31:43.030 And EVC allows the code to modify the text segment without error while... while using break point or you... 31:43.030 --> 31:47.250 when you step by step to debug into. 31:47.470 --> 31:50.210 But sometimes it's useful. 31:50.510 --> 32:00.890 Well, the... the... for the ARM debugger also have this... also have this bugs. 32:00.890 --> 32:09.270 So, I think maybe this is a bug of the debugger API over Windows CE. 32:12.710 --> 32:14.470 Maybe. 32:15.710 --> 32:20.070 Well, let's move on to the next part. 32:20.070 --> 32:28.610 The above share code we talked is complicated and it can't run in user mode. 32:28.710 --> 32:35.850 Is there any... is there any other method to implement share code? 32:36.230 --> 32:43.650 Well, let's look at an API implemented in the core DLL. 33:02.970 --> 33:05.690 Well, let's look at the power of the system. 33:05.690 --> 33:08.530 It has no parameters. 33:10.450 --> 33:22.410 The first... the system will check the... check the kthread info structure. 33:26.110 --> 33:46.940 And the kthread info is initialized in the MD created thread two function in the... in the MD... in the MD ARM.c. 33:49.810 --> 34:04.510 If the... if the application running kernel mode, this value will... the kthread info will be set with one. 34:04.510 --> 34:10.950 Otherwise, this value is saved zero. 34:15.510 --> 34:22.170 So, it tests this memory is one. 34:22.170 --> 34:45.130 Because the... if this... if this... if kthread info is one, then the system will use the API... API set table to find the real... real implement... implementation in the kernel space. 34:45.310 --> 34:49.150 If you... if your application is running... 34:49.570 --> 35:03.210 running kernel mode and this... this instruction will execute the... the R1 is the... is start from the eight... blah, blah, blah. 35:03.210 --> 35:06.290 It's in the kernel space. 35:06.810 --> 35:15.750 Otherwise, if the... if the kthread info is zero, the system will use this. 35:17.110 --> 35:25.330 This is... is the system call over Windows C. 35:25.810 --> 35:38.670 The system call number is from F... F0000 to F001000. 35:38.690 --> 35:52.750 There is a formula to... to determine the API... determine the system call number. 35:54.350 --> 35:56.240 It's like this. 35:59.050 --> 36:06.990 So... use this formula, we can calculate the system call number. 36:07.810 --> 36:12.130 Well, let's calculate the kernel IO control. 36:12.330 --> 36:15.950 Kernel IO control is in the... 36:22.220 --> 36:29.460 is defined in the k... kvim32.c. 36:29.460 --> 36:33.080 And the API set is... is zero. 36:33.080 --> 36:36.820 And the index is 99. 36:38.920 --> 36:43.440 So... so 36:48.840 --> 36:55.340 we calculated the system call number is like this. 36:57.940 --> 36:59.860 F0000FE74. 37:00.300 --> 37:14.780 Well, it's a... it's a... the system call number is more stable... more stable than the API address that implement in the core DL. 37:15.280 --> 37:29.260 Because... because the variable compile the ROM, the... the API address is a variable. 37:29.500 --> 37:33.540 So this... this share code is very simple. 37:37.180 --> 37:52.500 It only uses the system call to system call to... so... so this... this share code will... can execute in the user mode. 37:53.000 --> 37:55.680 But also the kernel mode. 37:56.020 --> 38:00.660 So I think this share code will use in the smartphone. 38:00.660 --> 38:09.860 The smartphone... the smartphones ROM not build... not build with the full kernel mode option. 38:09.860 --> 38:19.780 And the Microsoft device emulators ROM has... has no this option too. 38:19.980 --> 38:21.140 I tested this... 38:22.160 --> 38:32.920 this... this share code success in the Microsoft device emulator and my demonstrated device. 38:38.860 --> 38:39.780 Okay. 38:39.780 --> 38:42.680 Let's move on to the next part. 38:47.750 --> 38:59.610 The hello CPP is my... is my demonstrated vulnerable program. 39:01.090 --> 39:14.370 And it... it reads the... it reads the bin file of the root... root directory by F read. 39:14.370 --> 39:25.070 And then read this... read the file to the stack... stack variable buff. 39:25.070 --> 39:31.430 And the... the buff is only 512 bytes. 39:31.430 --> 39:41.610 So if the bin file is larger than 512 bytes, the... the program will overflow. 39:42.110 --> 39:48.330 And the print F and get a chart is just for test. 39:48.330 --> 39:55.190 They have no effect without the console DL in Windows directory. 39:55.830 --> 39:56.950 The console DL... 39:56.950 --> 40:08.610 the console DL can obtain from Windows mobile and developer power toy or from the pocket console. 40:39.950 --> 40:43.610 Windows C uses BL to... 40:43.610 --> 40:47.690 to call a function. 40:48.370 --> 40:52.290 And in the hello function, 40:59.520 --> 41:03.240 this is the first instruction. 41:04.080 --> 41:07.280 The store AOR to SP. 41:07.280 --> 41:23.440 It will store the AOR address to the stack port... to the stack... to the stack which contains the hello callers address. 41:23.780 --> 41:25.100 And... 41:31.070 --> 41:42.790 and the AODMIRSP2PC is the latest instruction in the hello function. 41:43.430 --> 41:45.250 It... this... 41:45.250 --> 41:56.630 this instruction will load the... load the AOR rest that is stored in the stack to the PC rest. 41:56.630 --> 42:05.450 And then the program will flow to the... will flow to the remain function. 42:05.450 --> 42:09.170 It will... then it will return. 42:09.930 --> 42:16.210 So overflow the AOR rest that stored in the stack. 42:16.210 --> 42:22.330 We will obtain the control while the function returned. 42:35.420 --> 42:46.060 The variables memory... the variables memory address that allocated by the program is corresponding to the loaded slot. 42:46.060 --> 42:48.940 Both the stack and the heap. 42:49.660 --> 42:57.440 The process may be loaded into the different slot each start time. 42:59.240 --> 43:05.600 So the base address of the slot always alters. 43:06.380 --> 43:12.660 But we know that the slot zero is mapped from the current process slot. 43:12.660 --> 43:16.420 So it's a stack address is stable. 43:16.440 --> 43:22.080 Anyway you can use the... use a jumper... jumper address. 43:22.080 --> 43:29.840 Jumper instruction address to let your... let the program flow to your shellcode. 43:32.080 --> 43:38.080 Well I tried two methods to construct the exploit path. 43:38.080 --> 43:41.140 The first is like this. 43:44.200 --> 43:53.440 The first... the start is the pad instructions and then is the return address. 43:53.740 --> 44:01.880 That we overflow it and then this return address is our... is pointed to our shellcode. 44:01.980 --> 44:08.240 Well, this is... this exploit path is larger. 44:12.120 --> 44:18.660 The PDA is frozen when the hello program is executed. 44:19.820 --> 44:24.200 I think maybe there are two reasons. 44:24.200 --> 44:38.660 The first is that the stack of Windows C is small and maybe the overflow destroyed the 2KB guard on the top of the stack boundary. 44:38.740 --> 44:45.180 So I changed it to another method to construct the exploit path. 44:49.670 --> 44:51.220 It's like this. 44:51.220 --> 45:05.780 I moved the shellcode in the start position and then the last is the... is the return address that pointed to our shellcode. 45:06.700 --> 45:13.240 Well, I used this method of success. 45:13.240 --> 45:15.660 I'll demonstrate it. 45:16.180 --> 45:18.900 Okay. 45:19.960 --> 45:33.900 The first... the Bluetooth is closed and I'll... I'll execute hello. 45:38.180 --> 45:48.600 It will print the... it will print the address of the path and the size. 45:48.600 --> 46:00.140 When I press any key, the... the device is restarting. 46:00.780 --> 46:07.720 Well, it has restarted. 46:19.460 --> 46:26.140 Well, after the system restart, the Bluetooth is open. 46:26.800 --> 46:31.640 Well, I'll... I'll close it because it's danger. 46:36.460 --> 46:37.900 Okay. 46:37.900 --> 46:41.840 Let's talk something about the decoding shellcode. 46:41.840 --> 46:47.920 The above shellcode that we talked is the concept shellcode. 46:47.920 --> 46:50.660 It contains a lot of zero. 46:51.000 --> 47:04.120 Well, the other vulnerable programs may be filled with a special characters before the stream buffer flow in some situations. 47:04.160 --> 47:07.600 For example, overflowed by SDR copy. 47:12.260 --> 47:30.580 It's difficult and inconvenient to write a shellcode without a special... without a special characters because if you use the R0, the opcode will contain the... will contain this zero. 47:31.520 --> 47:36.160 So, we think about the decoding shellcode. 47:39.550 --> 47:51.490 The newer ARM processor has a hovered architecture which... which separates instruction cache and the data cache. 47:54.410 --> 48:16.970 This feature will improve the performance of the ARM processor but the self-modifying code is not easy to implement because it will affect by the ARM cache architecture and the processes... processor's implementation. 48:26.340 --> 48:32.040 Well, let's look at this... this shellcode. 48:35.080 --> 48:42.920 Well, this is the decoding shellcode for the... for the test. 48:42.920 --> 48:56.260 The last... the last four instructions is... is move the one to the R1 to R4 registers. 48:56.260 --> 49:08.040 And the beginning of... the first four instructions will modify the last instructions. 49:08.040 --> 49:15.140 It will make the value to 99 because the R1 is 99. 49:16.500 --> 49:20.500 So, 49:23.780 --> 49:39.140 the R1 and the two R4 registers will... will get the 99 in my... in my demonstrated device. 49:46.370 --> 49:57.950 Well, we... we can saw the... the last four instructions has modified. 50:02.070 --> 50:24.030 But... but it will need more... need more NOP instructions between the decoding... decoded shellcode and... and the real shellcode in the Intel X... Intel X scale processors. 50:24.210 --> 50:25.770 You can try it. 50:25.770 --> 50:31.390 And maybe only the R1 get the 99. 50:31.630 --> 50:48.670 I think maybe the... the ARMV file architecture has... has six pipelines and... and my demonstrated device only has... is the ARMV4. 50:48.670 --> 50:52.710 It has... it has five pipelines. 50:52.710 --> 51:03.050 Maybe the pipelines modify... effect the result. 51:03.370 --> 51:08.770 Well, let's look at another... 51:08.770 --> 51:11.970 another method. 51:20.420 --> 51:37.400 Well, in this method, the last four MOV instructions were... were encoded with the exclusive OR with the 88. 51:37.700 --> 51:45.740 And the start is... is... is the decode... is the decoding shellcode. 51:45.740 --> 51:55.920 It has a loop to... is that... to load... to load the encoded shellcode. 51:55.920 --> 52:03.580 To... to load one byte of encoded shellcode and... and then decode it. 52:04.580 --> 52:09.700 Then start it to the original position. 52:13.500 --> 52:34.220 Well... well, the R1 to R4 registers won't get the... the 1, even if you add a lot of instructions. 52:44.550 --> 52:54.090 Well, we saw the last four instructions is... is decoded. 52:54.090 --> 52:59.250 But they don't get the 1. 53:01.030 --> 53:12.730 So... so I think maybe the load instructions will trigger the cache... some trick... some feature over the cache architecture. 53:12.730 --> 53:22.570 So we must... need the... need to flush the I-cache or D-cache after... 53:22.570 --> 53:26.530 after the shellcode decode. 53:26.870 --> 53:34.070 Well, I think... the first I think about the system interrupt. 53:34.190 --> 53:43.230 I... I used the system interrupt success in the AX power PC and the Spark. 53:43.230 --> 53:51.030 But the SWI instructions in the Windows C is just nonsense. 53:57.890 --> 54:14.390 The... the SWI handle defined in the ARM trap is... it's... it's just a... moves the AOR rest to the PC. 54:14.390 --> 54:17.450 So it's just a... not instruction. 54:17.450 --> 54:23.370 Well, I tried to... I have to try another method. 54:24.250 --> 54:31.610 Because the pocket PC ROMs were built with the full kernel mode option. 54:31.610 --> 54:35.470 The applications running the kernel mode. 54:35.470 --> 54:44.110 So I think about the MCR instructions to flush the I-cache and the D-cache. 54:46.250 --> 54:52.910 The MCR instruction can access the... in the kernel mode only. 54:52.990 --> 55:01.110 But... but unfortunately, this... this method all failed. 55:17.400 --> 55:20.680 Okay, let's move on to the last part. 55:21.340 --> 55:28.180 The codes we talked about are the real life buffer flow example in Windows C. 55:28.180 --> 55:34.480 It's simple, but I think this technology will be improved in the future. 55:36.020 --> 55:44.020 Because the instruction cache and the decoding shellcode is not good enough. 55:44.580 --> 55:49.620 Well, the internet and the handset devices are growing quickly. 55:50.400 --> 55:56.400 The threats to PDAs and the mobiles becomes more and more serious. 55:57.580 --> 56:09.020 The patch of Windows C is more difficult and dangerous because the... the entire operating system is in the ROM. 56:09.020 --> 56:10.500 Contained in the ROM. 56:10.500 --> 56:29.200 And if you... if you want to patch the system for completely, you must flush the system... the system... you must flush the system... you must flush the... the ROM. 56:29.200 --> 56:38.940 And it is... it is danger and... it is danger and difficult for the normal customers. 56:42.680 --> 56:47.180 Well, I consulted a lot of people on the internet. 56:47.180 --> 56:49.120 It's all listed here. 56:51.580 --> 56:58.540 I'll show my special appreciation to Nestle, who helped... who helped me a lot. 56:58.820 --> 57:01.940 Well, that's the end of my presentation. 57:01.940 --> 57:03.400 Hope you enjoyed. 57:03.740 --> 57:06.020 And sorry my lame English. 57:06.020 --> 57:07.160 Thank you. 57:07.160 --> 57:07.340 Thank you.