[00:04.000 --> 00:12.840] Okay, I'm from China. The title of my presentation is Hacking Windows C. It's about the security [00:12.840 --> 00:23.200] problems of PDAs and mobiles. My presentation is constructed with eight parts. First of all, [00:23.200 --> 00:30.580] I'll make a brief introduction of Windows C, because ARM processors is the most useful [00:30.580 --> 00:40.700] processor in PDAs and mobiles, so I'll introduce the ARM processor's architecture. [00:41.540 --> 00:47.560] You know, understanding memory management is very important for Buffalo Flow. The second, [00:47.560 --> 00:57.540] I'll introduce memory management with graphics. Compared with other Windows systems, Windows [00:57.540 --> 01:06.040] C chooses processes in a different way. Then I'll introduce the features of processes and [01:06.040 --> 01:21.360] threads of Windows C. The Windows C API search technology is funny. I'll introduce how to [01:21.360 --> 01:29.820] write shellcode using this method. And I will also introduce the implementation of system code [01:30.360 --> 01:39.380] and use it to write shellcode. After this, I'll demonstrate a simple Buffalo Flow. Well, I [01:39.380 --> 01:49.380] think this technology will be improved in the future. Then I'll talk something about decoding [01:49.380 --> 01:55.820] shellcode. The decoding shellcode will make the real shellcode more universal, but ARM [01:56.380 --> 02:04.320] processor's cache architecture makes it funny. At last, I'll conclude my presentation. Okay, [02:04.320 --> 02:11.900] let's move on to the next part, the first part. Windows C is a very popular embedded operating [02:11.900 --> 02:24.320] system for PDAs and mobiles. The name is developed by Microsoft. Because of the familiar [02:24.320 --> 02:33.280] APIs, Windows developers can easily develop applications for Windows C. Maybe this is a very [02:33.280 --> 02:40.860] important reason that makes Windows C popular. Windows C file is the latest version, but [02:41.740 --> 02:51.480] Windows C.net is the most useful version, and my presentation is based on this version. Maybe [02:51.480 --> 02:59.360] for marketing reasons, there is Windows mobile software for pocket PC and a smartphone in [02:59.360 --> 03:07.960] Microsoft's website and MSDN, but they are all based on the core of Windows C. By default, [03:07.960 --> 03:17.060] Windows C is in little Indian mode and it supports several processes. Almost all of the [03:17.060 --> 03:28.800] embedded devices will use ARM CPU. ARM processor is a typical RISC processor, which [03:28.800 --> 03:36.720] implements a load store architecture. Only load and store instructions can access memory. [03:36.720 --> 03:47.640] Data operating instructions operate on RISC contents only. There are six major versions of [03:47.640 --> 04:05.420] ARM architecture. The demonstrated device has a Samsung S3 C2410 processor, which has [04:05.420 --> 04:16.380] an ARM 9 core and the architecture version is an ARM V4T. More and more PDAs are using Intel X [04:16.380 --> 04:29.120] scale processor, which architecture version is V5TE. ARM processors support seven [04:29.120 --> 04:39.000] processor modes, depending on the architecture version. These modes are user, FIQ, IRQ, [04:39.000 --> 04:49.520] supervisor, undefined, abort and system. The system mode requires ARM architecture V4 and above. [04:49.520 --> 04:58.460] All modes except the user mode are referred to privileged mode. Applications usually are running [04:58.460 --> 05:11.100] user mode, but on the pocket PC, all applications appear to be running in kernel mode. I'll talk [05:11.100 --> 05:25.220] about it later. Windows ARM processor has 39 registers. These registers are arranged in [05:25.220 --> 05:36.540] partially overlapping banks. There's different registers for each processor mode. The bank [05:36.540 --> 05:44.220] registers give rapid context switching for dealing with processor exception and [05:46.200 --> 05:56.700] privileged operations. In ARM architecture V3 and above, there are 30 general purpose registers, [05:56.700 --> 06:08.220] the program counter register, the current program status register and the file saved program [06:08.220 --> 06:18.620] status register. 15 general purpose registers are visible at any one time, depending on the [06:18.620 --> 06:31.060] processor mode. By convention, R13 is used as a stack point in ARM assembly language. The C [06:31.060 --> 06:42.540] and the C++ compilers always use R13 as a stack point. In user mode and system mode, R14 is [06:42.540 --> 06:54.520] used as a link register, which stores the return address while a subroutine call is made. The [06:56.580 --> 07:06.540] program counter register is accessed as R15. It can access directly by data processing [07:06.540 --> 07:16.440] instructions. This feature is different from other processors and it is useful for code [07:16.440 --> 07:27.680] location while writing show code. You know, understanding memory management is very important for [07:27.680 --> 07:37.020] buffer overflow. But Windows C, but compared to other Windows systems, Windows C chooses memory [07:37.020 --> 07:49.320] management in a different way. Windows C uses ROM and RAM. The ROM in the Windows C system is [07:49.320 --> 07:56.860] just like a small read on a hard disk. It stores the entire operating system as well as the [07:56.860 --> 08:07.880] applications that are bundled in the system. The data, um, the data can maintain inside the [08:07.880 --> 08:17.480] ROM without power or battery. The RAM in a Windows C system is divided into two areas. The [08:17.480 --> 08:25.680] program memory and object store. The object store can be considered something like a [08:25.680 --> 08:37.200] permanent virtual RAM disk. It's unlike a RAM disk in the PC. It can maintain the files [08:37.200 --> 08:46.360] in it, uh, even if the system turned off. That, that is the reason that, this is the reason that [08:47.180 --> 08:55.080] Windows C devices typically have a main battery and a backup battery. They provide the power to [08:55.080 --> 09:05.460] my, to the RAM to maintain the files stored in it. Even when the user hit the reset button, the [09:05.460 --> 09:14.820] Windows C kernel starts up looking for previously created object store. Um, the system will [09:14.820 --> 09:29.380] use that store if it finds one. Another area of Windows C RAM is program memory. Program [09:29.380 --> 09:37.720] memory is just like the RAM in the PC. Uh, it stores the heaps and the stacks that, uh, the [09:37.720 --> 09:47.260] application, for applications that are running. Um, the, the dividing of the, between the [09:47.260 --> 09:55.840] object store and the program memory is adjustable. The user can move the dividing line, uh, by [09:55.840 --> 10:05.620] the system control panel applet. Windows C is a, um, 32-bit operating system, so it supports [10:05.620 --> 10:16.000] 4GB virtual address space. Let's look at this graph. This is the, um, 4GB virtual address space [10:16.000 --> 10:34.130] layout. The upper 2GB is, uh, used for, used by, is a kernel space used by a system for its own [10:34.130 --> 10:43.890] data. And the lower 2GB is a user space. From this address, uh, to below this address, [10:43.890 --> 10:53.650] the memories are used to, um, um, uh, larger memory, larger memory allocation. Such a, uh, [10:53.650 --> 11:02.750] it's used by the, uh, such as memory mapped files. Um, um, object store is loaded here. And from [11:02.750 --> 11:12.710] zero to below, this, uh, uh, this memory is, uh, divided into 33 slots. Each of which is a [11:12.710 --> 11:26.980] 32MB. The slot 1 is, uh, uh, XIP, uh, executed in place. This is a new feature, uh, of the [11:26.980 --> 11:43.400] Windows C.net. Uh, it expanded the application's virtual address space from 32MB to 64MB. Well, [11:43.400 --> 11:55.500] this graph is, uh, is the slot 0 virtual address space layout. Slot 0 is very important. It's, [11:55.500 --> 12:09.180] uh, used by the current active process. The first 64KB is, uh, reserved by the OS. And the [12:09.180 --> 12:21.000] following is the process's code, code and data. Um, stacks and heaps are arranged here. [12:21.980 --> 12:36.550] DLL files are loaded into the top, uh, top address. Well, let's move on to the next part. Um, [12:36.550 --> 12:43.530] uh, compared with other, uh, system, Windows C.net chooses processes in a different way. Windows [12:43.530 --> 12:51.770] C.net limits, uh, 32 processes being run at any one time. Uh, when the system starts, at least [12:51.770 --> 13:04.310] four processes are created. Um, let's look at the previous, uh, graph. NKEXE, uh, which [13:04.310 --> 13:16.610] provides the kernel service. It's always loaded into the slot 97. Um, filesystem.exe, which [13:16.610 --> 13:28.590] provides the filesystem service. It's always in slot 2. Device.exe, which, uh, which, uh, [13:28.590 --> 13:40.490] load and maintains the device drivers for system. It's in slot 3 normally. And, uh, GWES.exe, which [13:40.490 --> 14:00.130] provides GUI support. The other processes are also created such as explorer. Um, the, uh, [14:00.130 --> 14:08.170] other Windows system. Each process, at least, has a primary thread, uh, associated it, uh, up [14:08.170 --> 14:18.170] on start. Uh, if it never, never created one. One process, uh, can create any number of threads [14:18.170 --> 14:27.590] only limited by the available memory. Um, each thread belongs to a particular, uh, process and [14:27.590 --> 14:37.490] shares the same memory. But the, uh, set prog permissions API, uh, can give the, um, current [14:37.490 --> 14:48.450] thread access any, any process. 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:07.230] And DL files loaded into the top address of the, um, uh, uh, uh, address space. And then [15:07.230 --> 15:16.690] followed by the stack and the default process heap. After this, then execute it. Uh, when the, uh, [15:16.690 --> 15:24.570] when the process is, the thread is scheduled, the system will copy, uh, copy from its slot to slot [15:24.570 --> 15:34.410] zero. It's not a real copy operation, it's just mapped into the slot zero. Uh, this is mapped [15:34.410 --> 15:52.210] back to the original slot allocated to the process if the process becomes inactive. Process, uh, [15:52.210 --> 16:00.730] allocated stack for each thread. The default size is, uh, 64 KB, uh, depending on the link [16:00.730 --> 16:09.270] parameter when the, uh, program is compiled. This, uh, this size can, can, can be modified. The [16:09.270 --> 16:16.670] top two KB is used to guard against the stack overflow. We can't destroy this memory, [16:16.670 --> 16:26.710] otherwise the device will freeze. And the remainder, uh, available for use. Um, variables [16:26.710 --> 16:34.850] declared inside the function are allocated in the stack. Um, thread stack memory is reclaimed [16:34.850 --> 16:45.810] when it terminates. Well, let's move on to the next part. Um, before, before exploit, we must [16:45.810 --> 16:54.810] have, uh, share code to run on the Windows CE. Um, Windows CE implements, uh, V32 [16:55.580 --> 17:05.870] compatibility. The core DLL provides the entry points for, uh, for the, for almost all the APIs [17:05.870 --> 17:19.360] that implement, uh, that in the core DLL. Um, um, um, we must, uh, search the, uh, necessary [17:19.360 --> 17:29.680] API addresses, um, and then you use this, uh, uh, API address, APIs to implement our share code. [17:29.680 --> 17:39.240] The traditional method to implement, uh, uh, share code, uh, in the, uh, other Windows system [17:39.240 --> 17:51.320] is to, uh, locate the kernel 32 or NTDL, uh, via PB structure and then search, uh, search [17:51.320 --> 18:01.900] necessary APIs via, uh, P head structure. Well, is there any structure like, um, PB on the [18:01.900 --> 18:11.480] Windows CE? The answer is yes. That's, um, the kernel, the, uh, K data structure will satisfy [18:11.480 --> 18:26.140] those. The defined in NK arm.h. Uh, K data structure is, uh, is a very important kernel, uh, [18:26.140 --> 18:35.320] kernel structure can be accessed from user mode by fixed, uh, address, uh, K user, uh, P user [18:35.320 --> 18:46.940] K data. Um, the value over, uh, the value over P user K data is defined in the, uh, K functs. [18:46.940 --> 19:01.940] It's in the normal SDK. Um, uh, the value, uh, the P user K data is, uh, FFFC800 in ARM [19:01.940 --> 19:05.300] processors and, uh, file 8, uh, file 8, uh, file 8, uh, file 8, uh, file 8, uh, file 8, uh, file 8, [19:05.300 --> 19:23.140] 800 on the, uh, other CPUs. Well, let's look at the last member of, uh, K data structure. Um, it's [19:23.140 --> 19:44.160] offset 300 from the start of K data structure. Um... There is, uh, the, uh, the, uh, the, um, [19:44.180 --> 19:54.100] AIN4 is a DWORD array and there is a point to the module list [19:54.100 --> 20:07.440] index 9. So offset 3 to 4 from the FFFC800 is the point to the [20:07.440 --> 20:13.840] module list. Well, let's look at the module structure. [20:13.840 --> 20:28.580] The first member is defined in kernel header file. The second [20:28.580 --> 20:36.100] member is P mode. It's a point to the next module of the module [20:36.100 --> 20:50.140] chain. The third member is LPSZ mode name. It's a module name [20:50.140 --> 20:57.700] string. So we can locate the core DLL by comparing the unicode [20:57.700 --> 21:10.270] string of its name. Well, we also notice the E32 member. Let's [21:10.270 --> 21:18.810] look at this. E32 member is the E32 structure. It's defined in [21:18.810 --> 21:24.390] kernel header file. The third member is P HDR. Well, let's look [21:24.390 --> 21:33.790] into the E32 structure. The E32 V base will tell us the virtual [21:33.790 --> 21:40.070] base address of the module. So we can locate the virtual base [21:40.070 --> 21:46.910] address of the core DLL. We also notice the last member is E32 [21:47.960 --> 21:54.410] unit. It's an info structure and the info structure has two [21:54.410 --> 22:00.230] members. The first is the virtual relative address and the second [22:00.230 --> 22:10.590] is the size. And the little extra is defined in the P HDR. The [22:10.590 --> 22:20.690] start of P HDR. Six members used by NK. And the first is the [22:20.990 --> 22:29.170] export table position. So from now on, we got the [22:29.170 --> 22:36.150] virtual base address of the core DLL and its export table [22:36.150 --> 22:42.530] relative address of the export table position. [22:45.090 --> 23:03.950] And I wrote a small... I wrote a small program to list all the [23:03.950 --> 23:12.610] virtual base address of all loaded DLL files. This is the [23:13.190 --> 23:26.570] KData structure. And offset 324 is a point to the module [23:26.570 --> 23:30.550] structure. And the module structure is the chain [23:30.550 --> 23:39.090] structure. The offset 4 will point to the next module. [23:39.090 --> 23:44.750] So what is the point to the module structure? Well, the [23:44.750 --> 23:53.390] point to the module structure is in the kernel space. So this [23:53.390 --> 24:00.270] program only... this program only executed in the kernel [24:00.270 --> 24:08.390] mode. The user mode... it will fail in the user mode. Well, [24:09.250 --> 24:16.010] the most of the PC ROMs were built with the full kernel mode [24:16.010 --> 24:22.810] option. That's the applications all running kernel mode. [24:27.030 --> 24:34.450] So... so this small program will execute in the most of the [24:34.450 --> 24:44.870] pocket PC. I used this program to call the virtual base [24:44.870 --> 24:52.790] address of the core DLL is 1F6000. But when I use the [24:52.790 --> 24:58.570] EBC debug to look into, this address is invalid. The valid [24:58.570 --> 25:09.010] data is from 1F61000. I think maybe the Windows C is just for [25:09.010 --> 25:17.710] the purpose to... purpose over memory and start time and then [25:17.710 --> 25:39.420] load the head of the DLL file. Okay. The VNCE4.dust uses [25:40.590 --> 25:47.400] ordinals to find the API address. But I think use API [25:47.400 --> 25:52.580] name to find the... to find the API address is more reliable [25:52.580 --> 25:57.600] for share code. Because the API name won't change even if the [25:58.660 --> 26:02.320] core DLL file is changed. [26:06.280 --> 26:14.420] Well, we can... because we have the export table position and [26:14.420 --> 26:23.360] the base address of the core DLL. So we can use the... we can [26:23.360 --> 26:33.060] compare the image export directly to find the API [26:33.060 --> 26:39.720] address via API name. To save size, we can use the hash [26:39.720 --> 26:51.160] technology that from the LSD's V32 assembly components. And [26:51.400 --> 26:56.820] this is... this graph is ripped from LSD's V32 assembly [26:56.820 --> 27:04.220] components too. And it shows the way to locate the base [27:04.220 --> 27:07.720] address via API name. [27:11.780 --> 27:19.700] Well, let's move on next part. The test ASM is our final [27:19.700 --> 27:31.840] share code. It constructs with three parts. First, it will [27:31.840 --> 27:40.400] call get export section to get the virtual base address of the [27:40.400 --> 27:46.900] core DLL and its relative virtual address over export table [27:46.900 --> 27:57.320] position. And then it uses find function to find the API [27:57.320 --> 28:03.960] address via the hash value over the API name. And then stores [28:05.270 --> 28:12.560] the... find the... store the API address to the... its own hash [28:12.560 --> 28:21.720] value position. The last part is our implementation of our [28:21.720 --> 28:29.800] share code. It will change the register key over Bluetooth and [28:29.800 --> 28:45.550] then use kernel IO control to soft restart it. This share [28:45.550 --> 29:10.620] code will open the Bluetooth over some... we must notice the [29:13.220 --> 29:20.700] some... some assembly LDR pseudo instruction. Here, what I [29:20.700 --> 29:33.430] comment of this instructions. Because... because this pseudo [29:33.430 --> 29:39.170] instruction will be this in the EVC debug. It depend on the [29:39.170 --> 29:51.810] program. So, it won't get the FFF C800 in the share code. So, [29:51.810 --> 29:57.210] this instruction will make the share code fail. And the next [29:58.170 --> 30:07.770] instruction will be this in the EVC debug. It's okay. Well, in [30:07.770 --> 30:17.450] Windows CE, the R3 and... R0 and R3 use the first to fourth [30:17.450 --> 30:25.590] parameters of the API. If the... if the parameter is larger than [30:25.590 --> 30:32.390] four, the other parameters will store in the stack. So, we must [30:32.390 --> 30:36.150] pay attention while writing share code. Because the... [30:36.150 --> 30:42.590] because the share code always in the stack... stack memories. [30:45.430 --> 30:51.430] Well, EVC debugger has some bugs that make... make debugger [30:51.430 --> 30:57.970] difficult. The first, EVC will change the stack contents when [30:57.970 --> 31:04.990] the stack... in the end of the function. Well, it's... it's [31:04.990 --> 31:12.090] difficult to debug the buff overflow. Because the share [31:12.090 --> 31:17.650] code may be changed. And the instruction or the break point [31:17.650 --> 31:26.990] may be changed to E600010 in EVC sometimes. Well, it's... it's [31:26.990 --> 31:34.230] very bothering. And EVC allows the code to modify the text [31:34.750 --> 31:43.030] segment without error while... while using break point or you... [31:43.030 --> 31:49.030] when you step by step to debug into. But sometimes it's [31:49.030 --> 31:57.310] useful. Well, the... the... for the ARM debugger also have [31:57.310 --> 32:04.250] this... also have this bugs. So, I think maybe this is a bug of [32:04.250 --> 32:19.090] the debugger API over Windows CE. Maybe. Well, let's move on [32:19.090 --> 32:23.070] to the next part. The above share code we talked is [32:23.070 --> 32:30.510] complicated and it can't run in user mode. Is there any... is [32:30.510 --> 32:36.710] there any other method to implement share code? Well, [32:36.710 --> 33:03.930] let's look at an API implemented in the core DLL. Well, let's [33:03.930 --> 33:11.330] look at the power of the system. It has no parameters. The [33:11.930 --> 33:20.750] first... the system will check the... check the kthread info [33:20.750 --> 33:31.370] structure. And the kthread info is initialized in the MD [33:31.370 --> 33:44.060] created thread two function in the... in the MD... in the MD [33:44.060 --> 33:56.330] ARM.c. If the... if the application running kernel [33:56.330 --> 34:02.930] mode, this value will... the kthread info will be set with [34:02.930 --> 34:18.930] one. Otherwise, this value is saved zero. So, it tests this [34:19.670 --> 34:28.930] memory is one. Because the... if this... if this... if kthread [34:28.930 --> 34:36.810] info is one, then the system will use the API... API set table [34:36.810 --> 34:42.950] to find the real... real implement... implementation in [34:42.950 --> 34:49.150] the kernel space. If you... if your application is running... [34:49.570 --> 34:56.750] running kernel mode and this... this instruction will execute [34:56.750 --> 35:02.850] the... the R1 is the... is start from the eight... blah, blah, [35:02.850 --> 35:08.810] blah. It's in the kernel space. Otherwise, if the... if the [35:08.810 --> 35:20.370] kthread info is zero, the system will use this. This is... is the [35:20.370 --> 35:29.890] system call over Windows C. The system call number is from [35:29.890 --> 35:44.050] F... F0000 to F001000. There is a formula to... to determine [35:44.050 --> 35:56.240] the API... determine the system call number. It's like this. [35:59.050 --> 36:05.650] So... use this formula, we can calculate the system call [36:05.650 --> 36:12.910] number. Well, let's calculate the kernel IO control. Kernel IO [36:12.910 --> 36:30.640] control is in the... is defined in the k... kvim32.c. And the [36:30.640 --> 36:49.540] API set is... is zero. And the index is 99. So... so we [36:49.540 --> 36:59.860] calculated the system call number is like this. F0000FE74. [37:00.300 --> 37:05.720] Well, it's a... it's a... the system call number is more [37:05.720 --> 37:13.580] stable... more stable than the API address that implement in [37:13.580 --> 37:23.580] the core DL. Because... because the variable compile the ROM, [37:24.760 --> 37:30.980] the... the API address is a variable. So this... this [37:30.980 --> 37:42.220] share code is very simple. It only uses the system call to [37:42.220 --> 37:49.580] system call to... so... so this... this share code will... can [37:49.580 --> 37:56.740] execute in the user mode. But also the kernel mode. So I [37:56.740 --> 38:00.840] think this share code will use in the smartphone. The [38:00.840 --> 38:06.620] smartphone... the smartphones ROM not build... not build with [38:06.620 --> 38:12.820] the full kernel mode option. And the Microsoft device [38:12.820 --> 38:21.140] emulators ROM has... has no this option too. I tested this... [38:22.160 --> 38:28.900] this... this share code success in the Microsoft device [38:28.900 --> 38:40.880] emulator and my demonstrated device. Okay. Let's move on to [38:40.880 --> 38:55.390] the next part. The hello CPP is my... is my demonstrated [38:55.390 --> 39:05.970] vulnerable program. And it... it reads the... it reads the [39:05.970 --> 39:15.690] bin file of the root... root directory by F read. And then [39:16.010 --> 39:25.070] read this... read the file to the stack... stack variable buff. [39:25.070 --> 39:33.030] And the... the buff is only 512 bytes. So if the bin file is [39:33.030 --> 39:42.590] larger than 512 bytes, the... the program will overflow. And [39:42.590 --> 39:49.030] the print F and get a chart is just for test. They have no [39:49.030 --> 39:56.950] effect without the console DL in Windows directory. The console DL... [39:56.950 --> 40:03.150] the console DL can obtain from Windows mobile and developer [40:03.150 --> 40:43.610] power toy or from the pocket console. Windows C uses BL to... [40:43.610 --> 41:00.780] to call a function. And in the hello function, this is the [41:00.780 --> 41:09.700] first instruction. The store AOR to SP. It will store the AOR [41:09.700 --> 41:18.060] address to the stack port... to the stack... to the stack which [41:18.060 --> 41:36.970] contains the hello callers address. And... and the AODMIRSP2PC [41:36.970 --> 41:45.250] is the latest instruction in the hello function. It... this... [41:45.250 --> 41:52.670] this instruction will load the... load the AOR rest that is [41:52.670 --> 41:58.750] stored in the stack to the PC rest. And then the program will [41:58.750 --> 42:07.170] flow to the... will flow to the remain function. It will... then [42:07.170 --> 42:15.370] it will return. So overflow the AOR rest that stored in the [42:15.370 --> 42:35.640] stack. We will obtain the control while the function returned. The [42:35.640 --> 42:41.300] variables memory... the variables memory address that allocated by [42:41.300 --> 42:47.220] the program is corresponding to the loaded slot. Both the stack [42:47.220 --> 42:54.560] and the heap. The process may be loaded into the different slot [42:55.220 --> 43:05.600] each start time. So the base address of the slot always alters. [43:06.380 --> 43:10.780] But we know that the slot zero is mapped from the current [43:10.780 --> 43:17.320] process slot. So it's a stack address is stable. Anyway you can [43:17.320 --> 43:22.780] use the... use a jumper... jumper address. Jumper instruction [43:22.780 --> 43:29.840] address to let your... let the program flow to your shellcode. [43:32.080 --> 43:38.220] Well I tried two methods to construct the exploit path. The [43:38.220 --> 43:48.380] first is like this. The first... the start is the pad instructions [43:48.380 --> 43:56.600] and then is the return address. That we overflow it and then this [43:57.260 --> 44:04.080] return address is our... is pointed to our shellcode. Well, this [44:04.080 --> 44:14.740] is... this exploit path is larger. The PDA is frozen when the [44:14.740 --> 44:24.200] hello program is executed. I think maybe there are two reasons. [44:24.200 --> 44:31.780] The first is that the stack of Windows C is small and maybe the [44:31.780 --> 44:38.660] 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:56.720] It's like this. I moved the shellcode in the start position and then [44:56.720 --> 45:03.800] the last is the... is the return address that pointed to our [45:04.340 --> 45:14.100] shellcode. Well, I used this method of success. I'll demonstrate [45:14.100 --> 45:30.100] it. Okay. The first... the Bluetooth is closed and I'll... I'll [45:31.040 --> 45:45.480] execute hello. It will print the... it will print the address of the [45:45.480 --> 45:57.920] path and the size. When I press any key, the... the device is [45:57.920 --> 46:22.520] restarting. Well, it has restarted. Well, after the system [46:22.520 --> 46:30.020] restart, the Bluetooth is open. Well, I'll... I'll close it because [46:30.020 --> 46:41.840] it's danger. Okay. Let's talk something about the decoding shellcode. [46:41.840 --> 46:48.000] The above shellcode that we talked is the concept shellcode. It [46:48.000 --> 46:57.100] contains a lot of zero. Well, the other vulnerable programs may be filled [46:57.100 --> 47:02.560] with a special characters before the stream buffer flow in some [47:02.560 --> 47:13.880] situations. For example, overflowed by SDR copy. It's difficult and [47:13.880 --> 47:19.800] inconvenient to write a shellcode without a special... without a special [47:19.800 --> 47:27.840] characters because if you use the R0, the opcode will contain the... will [47:27.840 --> 47:40.510] contain this zero. So, we think about the decoding shellcode. The [47:40.510 --> 47:47.590] newer ARM processor has a hovered architecture which... which separates [47:48.070 --> 47:57.070] instruction cache and the data cache. This feature will improve the [47:57.070 --> 48:04.130] performance of the ARM processor but the self-modifying code is not easy to [48:04.130 --> 48:12.130] implement because it will affect by the ARM cache architecture and the [48:12.130 --> 48:30.240] processes... processor's implementation. Well, let's look at this... this [48:30.240 --> 48:42.920] shellcode. Well, this is the decoding shellcode for the... for the test. [48:42.920 --> 48:54.400] The last... the last four instructions is... is move the one to the R1 to R4 [48:54.420 --> 49:05.480] registers. And the beginning of... the first four instructions will modify the [49:05.480 --> 49:24.480] last instructions. It will make the value to 99 because the R1 is 99. So, the R1 [49:24.480 --> 49:39.140] and the two R4 registers will... will get the 99 in my... in my demonstrated device. [49:46.370 --> 50:05.910] Well, we... we can saw the... the last four instructions has modified. But... but it [50:05.910 --> 50:13.470] will need more... need more NOP instructions between the decoding... decoded shellcode [50:13.470 --> 50:25.770] and... and the real shellcode in the Intel X... Intel X scale processors. You can try it. [50:25.770 --> 50:41.230] And maybe only the R1 get the 99. I think maybe the... the ARMV file architecture has... has [50:41.230 --> 50:50.770] six pipelines and... and my demonstrated device only has... is the ARMV4. It has... it has [50:50.770 --> 51:08.770] five pipelines. Maybe the pipelines modify... effect the result. Well, let's look at another... [51:08.770 --> 51:32.820] another method. Well, in this method, the last four MOV instructions were... were encoded [51:32.820 --> 51:44.900] with the exclusive OR with the 88. And the start is... is... is the decode... is the decoding [51:44.900 --> 51:56.660] shellcode. It has a loop to... is that... to load... to load the encoded shellcode. To... to load [51:56.660 --> 52:09.700] one byte of encoded shellcode and... and then decode it. Then start it to the original position. [52:13.500 --> 52:31.500] Well... well, the R1 to R4 registers won't get the... the 1, even if you add a lot of [52:31.500 --> 52:59.250] instructions. Well, we saw the last four instructions is... is decoded. But they don't get the 1. [53:01.030 --> 53:10.070] So... so I think maybe the load instructions will trigger the cache... some trick... some feature [53:10.070 --> 53:22.570] over the cache architecture. So we must... need the... need to flush the I-cache or D-cache after... [53:22.570 --> 53:35.470] after the shellcode decode. Well, I think... the first I think about the system interrupt. I... I [53:35.470 --> 53:46.670] used the system interrupt success in the AX power PC and the Spark. But the SWI instructions in [53:46.670 --> 54:08.350] the Windows C is just nonsense. The... the SWI handle defined in the ARM trap is... it's... it's [54:08.350 --> 54:20.710] just a... moves the AOR rest to the PC. So it's just a... not instruction. Well, I tried to... I [54:20.710 --> 54:29.990] have to try another method. Because the pocket PC ROMs were built with the full kernel mode [54:30.710 --> 54:40.490] option. The applications running the kernel mode. So I think about the MCR instructions to [54:40.490 --> 54:51.610] flush the I-cache and the D-cache. The MCR instruction can access the... in the kernel mode [54:51.610 --> 55:19.600] only. But... but unfortunately, this... this method all failed. Okay, let's move on to the last [55:19.600 --> 55:29.500] part. The codes we talked about are the real life buffer flow example in Windows C. It's simple, but [55:29.500 --> 55:40.900] I think this technology will be improved in the future. Because the instruction cache and the [55:40.900 --> 55:48.620] decoding shellcode is not good enough. Well, the internet and the handset devices are growing [55:48.620 --> 55:58.580] quickly. The threats to PDAs and the mobiles becomes more and more serious. The patch of [55:58.580 --> 56:08.500] Windows C is more difficult and dangerous because the... the entire operating system is in the [56:08.500 --> 56:16.440] ROM. Contained in the ROM. And if you... if you want to patch the system for completely, you [56:16.440 --> 56:28.180] must flush the system... the system... you must flush the system... you must flush the... the [56:28.180 --> 56:44.060] ROM. And it is... it is danger and... it is danger and difficult for the normal customers. Well, I [56:44.060 --> 56:53.400] consulted a lot of people on the internet. It's all listed here. I'll show my special [56:54.080 --> 57:01.940] appreciation to Nestle, who helped... who helped me a lot. Well, that's the end of my presentation. [57:01.940 --> 57:07.160] Hope you enjoyed. And sorry my lame English. Thank you. [57:07.160 --> 57:07.340] Thank you.