1
00:00:04,000 --> 00:00:07,260
Okay, I'm from China.

2
00:00:07,260 --> 00:00:10,460
The title of my presentation is Hacking Windows C.

3
00:00:10,460 --> 00:00:16,260
It's about the security problems of PDAs and mobiles.

4
00:00:17,620 --> 00:00:22,100
My presentation is constructed with eight parts.

5
00:00:22,100 --> 00: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.

6
00:00:41,540 --> 00:00:46,820
You know, understanding memory management is very important for Buffalo Flow.

7
00:00:46,820 --> 00:00:53,020
The second, I'll introduce memory management with graphics.

8
00:00:53,500 --> 00:01:01,060
Compared with other Windows systems, Windows C chooses processes in a different way.

9
00:01:01,500 --> 00:01:08,900
Then I'll introduce the features of processes and threads of Windows C.

10
00:01:09,700 --> 00:01:16,200
The Windows C API search technology is funny.

11
00:01:16,240 --> 00:01:24,780
I'll introduce how to write shellcode using this method.

12
00:01:24,860 --> 00:01:33,220
And I will also introduce the implementation of system code and use it to write shellcode.

13
00:01:33,220 --> 00:01:38,340
After this, I'll demonstrate a simple Buffalo Flow.

14
00:01:38,580 --> 00:01:44,260
Well, I think this technology will be improved in the future.

15
00:01:44,900 --> 00:01:50,220
Then I'll talk something about decoding shellcode.

16
00:01:50,220 --> 00:01:59,620
The decoding shellcode will make the real shellcode more universal, but ARM processor's cache architecture makes it funny.

17
00:02:00,240 --> 00:02:03,200
At last, I'll conclude my presentation.

18
00:02:03,960 --> 00:02:07,420
Okay, let's move on to the next part, the first part.

19
00:02:08,400 --> 00:02:15,440
Windows C is a very popular embedded operating system for PDAs and mobiles.

20
00:02:15,440 --> 00:02:19,100
The name is developed by Microsoft.

21
00:02:20,860 --> 00:02:31,280
Because of the familiar APIs, Windows developers can easily develop applications for Windows C.

22
00:02:31,280 --> 00:02:37,200
Maybe this is a very important reason that makes Windows C popular.

23
00:02:37,480 --> 00: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.

24
00:02:51,060 --> 00: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.

25
00:03:06,060 --> 00:03:13,440
By default, Windows C is in little Indian mode and it supports several processes.

26
00:03:15,160 --> 00:03:22,620
Almost all of the embedded devices will use ARM CPU.

27
00:03:23,080 --> 00:03:32,540
ARM processor is a typical RISC processor, which implements a load store architecture.

28
00:03:32,540 --> 00:03:36,720
Only load and store instructions can access memory.

29
00:03:36,720 --> 00:03:44,340
Data operating instructions operate on RISC contents only.

30
00:03:44,980 --> 00:03:50,560
There are six major versions of ARM architecture.

31
00:03:50,720 --> 00: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.

32
00:04:12,180 --> 00:04:23,100
More and more PDAs are using Intel X scale processor, which architecture version is V5TE.

33
00:04:24,680 --> 00:04:33,940
ARM processors support seven processor modes, depending on the architecture version.

34
00:04:34,540 --> 00:04:43,420
These modes are user, FIQ, IRQ, supervisor, undefined, abort and system.

35
00:04:43,420 --> 00:04:49,520
The system mode requires ARM architecture V4 and above.

36
00:04:49,520 --> 00:04:55,280
All modes except the user mode are referred to privileged mode.

37
00:04:55,840 --> 00:05:09,700
Applications usually are running user mode, but on the pocket PC, all applications appear to be running in kernel mode.

38
00:05:09,960 --> 00:05:14,000
I'll talk about it later.

39
00:05:15,840 --> 00:05:22,340
Windows ARM processor has 39 registers.

40
00:05:22,340 --> 00:05:28,160
These registers are arranged in partially overlapping banks.

41
00:05:28,760 --> 00:05:33,860
There's different registers for each processor mode.

42
00:05:34,820 --> 00:05:49,520
The bank registers give rapid context switching for dealing with processor exception and privileged operations.

43
00:05:50,320 --> 00: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.

44
00:06:12,080 --> 00:06:21,000
15 general purpose registers are visible at any one time, depending on the processor mode.

45
00:06:21,520 --> 00:06:30,700
By convention, R13 is used as a stack point in ARM assembly language.

46
00:06:30,700 --> 00:06:37,420
The C and the C++ compilers always use R13 as a stack point.

47
00:06:39,300 --> 00: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.

48
00:06:54,460 --> 00:07:01,440
The program counter register is accessed as R15.

49
00:07:01,700 --> 00:07:08,640
It can access directly by data processing instructions.

50
00:07:09,200 --> 00:07:19,440
This feature is different from other processors and it is useful for code location while writing show code.

51
00:07:23,060 --> 00:07:29,780
You know, understanding memory management is very important for buffer overflow.

52
00:07:30,320 --> 00:07:40,160
But Windows C, but compared to other Windows systems, Windows C chooses memory management in a different way.

53
00:07:40,160 --> 00:07:44,100
Windows C uses ROM and RAM.

54
00:07:44,100 --> 00:07:52,740
The ROM in the Windows C system is just like a small read on a hard disk.

55
00:07:52,740 --> 00:08:02,020
It stores the entire operating system as well as the applications that are bundled in the system.

56
00:08:02,300 --> 00:08:11,140
The data, um, the data can maintain inside the ROM without power or battery.

57
00:08:11,580 --> 00:08:17,100
The RAM in a Windows C system is divided into two areas.

58
00:08:17,100 --> 00:08:20,760
The program memory and object store.

59
00:08:20,760 --> 00:08:27,980
The object store can be considered something like a permanent virtual RAM disk.

60
00:08:28,060 --> 00:08:33,400
It's unlike a RAM disk in the PC.

61
00:08:34,880 --> 00:08:42,260
It can maintain the files in it, uh, even if the system turned off.

62
00:08:42,260 --> 00: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.

63
00:08:52,480 --> 00:09:01,160
They provide the power to my, to the RAM to maintain the files stored in it.

64
00:09:01,500 --> 00:09:10,940
Even when the user hit the reset button, the Windows C kernel starts up looking for previously created object store.

65
00:09:11,360 --> 00:09:18,200
Um, the system will use that store if it finds one.

66
00:09:20,900 --> 00:09:29,000
Another area of Windows C RAM is program memory.

67
00:09:29,000 --> 00:09:32,900
Program memory is just like the RAM in the PC.

68
00:09:33,100 --> 00:09:41,460
Uh, it stores the heaps and the stacks that, uh, the application, for applications that are running.

69
00:09:41,780 --> 00:09:51,440
Um, the, the dividing of the, between the object store and the program memory is adjustable.

70
00:09:51,440 --> 00:09:58,960
The user can move the dividing line, uh, by the system control panel applet.

71
00:09:59,940 --> 00:10:08,900
Windows C is a, um, 32-bit operating system, so it supports 4GB virtual address space.

72
00:10:09,260 --> 00:10:12,120
Let's look at this graph.

73
00:10:12,120 --> 00:10:17,120
This is the, um, 4GB virtual address space layout.

74
00:10:26,030 --> 00:10:35,110
The upper 2GB is, uh, used for, used by, is a kernel space used by a system for its own data.

75
00:10:35,110 --> 00:10:38,230
And the lower 2GB is a user space.

76
00:10:38,630 --> 00:10:52,150
From this address, uh, to below this address, the memories are used to, um, um, uh, larger memory, larger memory allocation.

77
00:10:52,150 --> 00:10:57,890
Such a, uh, it's used by the, uh, such as memory mapped files.

78
00:10:58,050 --> 00:11:01,730
Um, um, object store is loaded here.

79
00:11:01,730 --> 00:11:11,170
And from zero to below, this, uh, uh, this memory is, uh, divided into 33 slots.

80
00:11:11,690 --> 00:11:14,610
Each of which is a 32MB.

81
00:11:17,980 --> 00:11:24,220
The slot 1 is, uh, uh, XIP, uh, executed in place.

82
00:11:24,220 --> 00:11:28,920
This is a new feature, uh, of the Windows C.net.

83
00:11:29,120 --> 00:11:38,660
Uh, it expanded the application's virtual address space from 32MB to 64MB.

84
00:11:42,460 --> 00:11:52,800
Well, this graph is, uh, is the slot 0 virtual address space layout.

85
00:11:52,800 --> 00:11:55,280
Slot 0 is very important.

86
00:11:55,280 --> 00:12:01,180
It's, uh, used by the current active process.

87
00:12:01,980 --> 00:12:07,360
The first 64KB is, uh, reserved by the OS.

88
00:12:07,360 --> 00:12:14,380
And the following is the process's code, code and data.

89
00:12:16,680 --> 00:12:21,000
Um, stacks and heaps are arranged here.

90
00:12:21,980 --> 00:12:26,260
DLL files are loaded into the top, uh, top address.

91
00:12:31,350 --> 00:12:34,350
Well, let's move on to the next part.

92
00:12:34,810 --> 00:12:43,310
Um, uh, compared with other, uh, system, Windows C.net chooses processes in a different way.

93
00:12:43,330 --> 00:12:48,890
Windows C.net limits, uh, 32 processes being run at any one time.

94
00:12:48,990 --> 00:12:54,770
Uh, when the system starts, at least four processes are created.

95
00:12:54,850 --> 00:13:00,530
Um, let's look at the previous, uh, graph.

96
00:13:02,490 --> 00:13:07,310
NKEXE, uh, which provides the kernel service.

97
00:13:07,310 --> 00:13:12,150
It's always loaded into the slot 97.

98
00:13:12,690 --> 00:13:20,590
Um, filesystem.exe, which provides the filesystem service.

99
00:13:20,590 --> 00:13:23,570
It's always in slot 2.

100
00:13:23,730 --> 00:13:34,010
Device.exe, which, uh, which, uh, load and maintains the device drivers for system.

101
00:13:34,010 --> 00:13:36,630
It's in slot 3 normally.

102
00:13:36,630 --> 00:13:43,470
And, uh, GWES.exe, which provides GUI support.

103
00:13:44,070 --> 00:13:50,150
The other processes are also created such as explorer.

104
00:13:53,010 --> 00:14:01,950
Um, the, uh, other Windows system.

105
00:14:02,210 --> 00:14:09,630
Each process, at least, has a primary thread, uh, associated it, uh, up on start.

106
00:14:09,670 --> 00:14:12,890
Uh, if it never, never created one.

107
00:14:13,650 --> 00:14:21,890
One process, uh, can create any number of threads only limited by the available memory.

108
00:14:22,270 --> 00:14:29,970
Um, each thread belongs to a particular, uh, process and shares the same memory.

109
00:14:29,970 --> 00:14:41,070
But the, uh, set prog permissions API, uh, can give the, um, current thread access any, any process.

110
00:14:42,030 --> 00:14:48,450
Each thread has an ID, a private stack, and a set of registers.

111
00:14:48,450 --> 00:14:58,450
When the process is, uh, loaded, uh, the system will assign the next, uh, available slot to it.

112
00:14:58,450 --> 00:15:06,430
And DL files loaded into the top address of the, um, uh, uh, uh, address space.

113
00:15:06,430 --> 00:15:10,830
And then followed by the stack and the default process heap.

114
00:15:10,830 --> 00:15:13,830
After this, then execute it.

115
00:15:14,750 --> 00: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.

116
00:15:25,650 --> 00:15:32,690
It's not a real copy operation, it's just mapped into the slot zero.

117
00:15:33,190 --> 00:15:41,610
Uh, this is mapped back to the original slot allocated to the process if the process becomes inactive.

118
00:15:50,730 --> 00:15:55,310
Process, uh, allocated stack for each thread.

119
00:15:55,350 --> 00:16:04,290
The default size is, uh, 64 KB, uh, depending on the link parameter when the, uh, program is compiled.

120
00:16:04,290 --> 00:16:08,730
This, uh, this size can, can, can be modified.

121
00:16:09,070 --> 00:16:14,690
The top two KB is used to guard against the stack overflow.

122
00:16:14,690 --> 00:16:21,010
We can't destroy this memory, otherwise the device will freeze.

123
00:16:21,890 --> 00:16:25,270
And the remainder, uh, available for use.

124
00:16:25,270 --> 00:16:31,510
Um, variables declared inside the function are allocated in the stack.

125
00:16:32,010 --> 00:16:37,510
Um, thread stack memory is reclaimed when it terminates.

126
00:16:39,770 --> 00:16:42,830
Well, let's move on to the next part.

127
00:16:42,830 --> 00:16:50,250
Um, before, before exploit, we must have, uh, share code to run on the Windows CE.

128
00:16:50,250 --> 00:16:56,810
Um, Windows CE implements, uh, V32 compatibility.

129
00:16:56,850 --> 00: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.

130
00:17:10,110 --> 00: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.

131
00:17:29,680 --> 00: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.

132
00:17:56,380 --> 00:18:02,740
Well, is there any structure like, um, PB on the Windows CE?

133
00:18:02,740 --> 00:18:05,020
The answer is yes.

134
00:18:05,020 --> 00:18:12,480
That's, um, the kernel, the, uh, K data structure will satisfy those.

135
00:18:13,500 --> 00:18:17,780
The defined in NK arm.h.

136
00:18:20,360 --> 00: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.

137
00:18:36,680 --> 00:18:46,940
Um, the value over, uh, the value over P user K data is defined in the, uh, K functs.

138
00:18:46,940 --> 00:18:49,280
It's in the normal SDK.

139
00:18:49,580 --> 00: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.

140
00:19:14,740 --> 00:19:21,120
Well, let's look at the last member of, uh, K data structure.

141
00:19:21,120 --> 00:19:28,840
Um, it's offset 300 from the start of K data structure.

142
00:19:32,240 --> 00:19:36,200
Um... There is, uh,

143
00:19:41,120 --> 00: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.

144
00:19:56,440 --> 00:20:09,340
So offset 3 to 4 from the FFFC800 is the point to the module list.

145
00:20:09,800 --> 00:20:13,840
Well, let's look at the module structure.

146
00:20:13,840 --> 00:20:18,120
The first member is defined in kernel header file.

147
00:20:26,840 --> 00:20:31,360
The second member is P mode.

148
00:20:31,360 --> 00:20:37,400
It's a point to the next module of the module chain.

149
00:20:39,100 --> 00:20:45,040
The third member is LPSZ mode name.

150
00:20:45,420 --> 00:20:51,300
It's a module name string.

151
00:20:51,300 --> 00:21:01,460
So we can locate the core DLL by comparing the unicode string of its name.

152
00:21:04,110 --> 00:21:08,450
Well, we also notice the E32 member.

153
00:21:09,290 --> 00:21:11,910
Let's look at this.

154
00:21:12,810 --> 00:21:17,590
E32 member is the E32 structure.

155
00:21:17,590 --> 00:21:18,810
It's defined in kernel header file .

156
00:21:18,810 --> 00:21:22,030
The third member is P HDR.

157
00:21:23,330 --> 00:21:28,450
Well, let's look into the E32 structure.

158
00:21:28,450 --> 00:21:36,090
The E32 V base will tell us the virtual base address of the module.

159
00:21:36,110 --> 00:21:42,590
So we can locate the virtual base address of the core DLL.

160
00:21:42,890 --> 00:21:49,130
We also notice the last member is E32 unit.

161
00:21:50,170 --> 00:21:55,110
It's an info structure and the info structure has two members.

162
00:21:55,110 --> 00:22:01,950
The first is the virtual relative address and the second is the size.

163
00:22:03,150 --> 00:22:10,230
And the little extra is defined in the P HDR.

164
00:22:10,450 --> 00:22:12,710
The start of P HDR.

165
00:22:13,730 --> 00:22:18,570
Six members used by NK.

166
00:22:18,570 --> 00:22:23,170
And the first is the export table position.

167
00:22:23,370 --> 00: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.

168
00:22:45,090 --> 00: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.

169
00:23:11,610 --> 00:23:15,250
This is the KData structure.

170
00:23:15,730 --> 00:23:28,410
And offset 324 is a point to the module structure.

171
00:23:28,770 --> 00:23:32,130
And the module structure is the chain structure.

172
00:23:32,770 --> 00:23:39,090
The offset 4 will point to the next module.

173
00:23:39,090 --> 00:23:40,030
So what is the point to the module structure ?

174
00:23:40,350 --> 00:23:49,610
Well, the point to the module structure is in the kernel space.

175
00:23:50,490 --> 00:24:01,250
So this program only... this program only executed in the kernel mode.

176
00:24:01,250 --> 00:24:06,010
The user mode... it will fail in the user mode.

177
00:24:06,970 --> 00:24:17,450
Well, the most of the PC ROMs were built with the full kernel mode option.

178
00:24:17,930 --> 00:24:22,810
That's the applications all running kernel mode.

179
00:24:27,030 --> 00:24:36,090
So... so this small program will execute in the most of the pocket PC.

180
00:24:38,970 --> 00:24:50,470
I used this program to call the virtual base address of the core DLL is 1F6000.

181
00:24:50,730 --> 00:24:57,990
But when I use the EBC debug to look into, this address is invalid.

182
00:24:57,990 --> 00:25:03,750
The valid data is from 1F61000.

183
00:25:05,030 --> 00: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.

184
00:25:35,120 --> 00:25:36,040
Okay.

185
00:25:36,080 --> 00:25:43,900
The VNCE4.dust uses ordinals to find the API address.

186
00:25:43,900 --> 00:25:54,020
But I think use API name to find the... to find the API address is more reliable for share code.

187
00:25:54,020 --> 00:26:02,320
Because the API name won't change even if the core DLL file is changed.

188
00:26:06,280 --> 00:26:18,220
Well, we can... because we have the export table position and the base address of the core DLL.

189
00:26:18,220 --> 00:26:36,280
So we can use the... we can compare the image export directly to find the API address via API name.

190
00:26:36,280 --> 00:26:47,840
To save size, we can use the hash technology that from the LSD's V32 assembly components.

191
00:26:50,940 --> 00:26:58,640
And this is... this graph is ripped from LSD's V32 assembly components too.

192
00:26:58,640 --> 00:27:07,720
And it shows the way to locate the base address via API name.

193
00:27:11,780 --> 00:27:15,140
Well, let's move on next part.

194
00:27:15,220 --> 00:27:21,260
The test ASM is our final share code.

195
00:27:26,540 --> 00:27:29,580
It constructs with three parts.

196
00:27:29,580 --> 00: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.

197
00:27:48,420 --> 00:28:01,820
And then it uses find function to find the API address via the hash value over the API name.

198
00:28:01,820 --> 00:28:14,960
And then stores the... find the... store the API address to the... its own hash value position.

199
00:28:15,500 --> 00:28:23,180
The last part is our implementation of our share code.

200
00:28:23,180 --> 00:28:36,400
It will change the register key over Bluetooth and then use kernel IO control to soft restart it.

201
00:28:45,030 --> 00:28:55,290
This share code will open the Bluetooth over some... we

202
00:29:08,460 --> 00:29:19,580
must notice the some... some assembly LDR pseudo instruction.

203
00:29:19,840 --> 00:29:23,400
Here, what I comment of this instructions.

204
00:29:27,040 --> 00:29:37,770
Because... because this pseudo instruction will be this in the EVC debug.

205
00:29:37,770 --> 00:29:40,810
It depend on the program.

206
00:29:41,790 --> 00:29:49,530
So, it won't get the FFF C800 in the share code.

207
00:29:50,730 --> 00:29:55,210
So, this instruction will make the share code fail.

208
00:29:55,210 --> 00:30:02,330
And the next instruction will be this in the EVC debug.

209
00:30:02,330 --> 00:30:04,190
It's okay.

210
00:30:05,210 --> 00:30:20,130
Well, in Windows CE, the R3 and... R0 and R3 use the first to fourth parameters of the API.

211
00:30:20,950 --> 00:30:31,110
If the... if the parameter is larger than four, the other parameters will store in the stack.

212
00:30:31,110 --> 00:30:35,250
So, we must pay attention while writing share code.

213
00:30:35,250 --> 00:30:36,150
Because the...

214
00:30:36,150 --> 00:30:42,590
because the share code always in the stack... stack memories.

215
00:30:45,430 --> 00:30:52,690
Well, EVC debugger has some bugs that make... make debugger difficult.

216
00:30:53,030 --> 00:31:03,110
The first, EVC will change the stack contents when the stack... in the end of the function.

217
00:31:03,210 --> 00:31:09,330
Well, it's... it's difficult to debug the buff overflow.

218
00:31:09,830 --> 00:31:14,350
Because the share code may be changed.

219
00:31:14,970 --> 00:31:25,570
And the instruction or the break point may be changed to E600010 in EVC sometimes.

220
00:31:25,570 --> 00:31:29,130
Well, it's... it's very bothering.

221
00:31:30,010 --> 00:31:43,030
And EVC allows the code to modify the text segment without error while... while using break point or you...

222
00:31:43,030 --> 00:31:47,250
when you step by step to debug into.

223
00:31:47,470 --> 00:31:50,210
But sometimes it's useful.

224
00:31:50,510 --> 00:32:00,890
Well, the... the... for the ARM debugger also have this... also have this bugs.

225
00:32:00,890 --> 00:32:09,270
So, I think maybe this is a bug of the debugger API over Windows CE.

226
00:32:12,710 --> 00:32:14,470
Maybe.

227
00:32:15,710 --> 00:32:20,070
Well, let's move on to the next part.

228
00:32:20,070 --> 00:32:28,610
The above share code we talked is complicated and it can't run in user mode.

229
00:32:28,710 --> 00:32:35,850
Is there any... is there any other method to implement share code?

230
00:32:36,230 --> 00:32:43,650
Well, let's look at an API implemented in the core DLL.

231
00:33:02,970 --> 00:33:05,690
Well, let's look at the power of the system.

232
00:33:05,690 --> 00:33:08,530
It has no parameters.

233
00:33:10,450 --> 00:33:22,410
The first... the system will check the... check the kthread info structure.

234
00:33:26,110 --> 00: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.

235
00:33:49,810 --> 00:34:04,510
If the... if the application running kernel mode, this value will... the kthread info will be set with one.

236
00:34:04,510 --> 00:34:10,950
Otherwise, this value is saved zero.

237
00:34:15,510 --> 00:34:22,170
So, it tests this memory is one.

238
00:34:22,170 --> 00: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.

239
00:34:45,310 --> 00:34:49,150
If you... if your application is running...

240
00:34:49,570 --> 00: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.

241
00:35:03,210 --> 00:35:06,290
It's in the kernel space.

242
00:35:06,810 --> 00:35:15,750
Otherwise, if the... if the kthread info is zero, the system will use this.

243
00:35:17,110 --> 00:35:25,330
This is... is the system call over Windows C.

244
00:35:25,810 --> 00:35:38,670
The system call number is from F... F0000 to F001000.

245
00:35:38,690 --> 00:35:52,750
There is a formula to... to determine the API... determine the system call number.

246
00:35:54,350 --> 00:35:56,240
It's like this.

247
00:35:59,050 --> 00:36:06,990
So... use this formula, we can calculate the system call number.

248
00:36:07,810 --> 00:36:12,130
Well, let's calculate the kernel IO control.

249
00:36:12,330 --> 00:36:15,950
Kernel IO control is in the...

250
00:36:22,220 --> 00:36:29,460
is defined in the k... kvim32.c.

251
00:36:29,460 --> 00:36:33,080
And the API set is... is zero.

252
00:36:33,080 --> 00:36:36,820
And the index is 99.

253
00:36:38,920 --> 00:36:43,440
So... so

254
00:36:48,840 --> 00:36:55,340
we calculated the system call number is like this.

255
00:36:57,940 --> 00:36:59,860
F0000FE74.

256
00:37:00,300 --> 00: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.

257
00:37:15,280 --> 00:37:29,260
Because... because the variable compile the ROM, the... the API address is a variable.

258
00:37:29,500 --> 00:37:33,540
So this... this share code is very simple.

259
00:37:37,180 --> 00: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.

260
00:37:53,000 --> 00:37:55,680
But also the kernel mode.

261
00:37:56,020 --> 00:38:00,660
So I think this share code will use in the smartphone.

262
00:38:00,660 --> 00:38:09,860
The smartphone... the smartphones ROM not build... not build with the full kernel mode option.

263
00:38:09,860 --> 00:38:19,780
And the Microsoft device emulators ROM has... has no this option too.

264
00:38:19,980 --> 00:38:21,140
I tested this...

265
00:38:22,160 --> 00:38:32,920
this... this share code success in the Microsoft device emulator and my demonstrated device.

266
00:38:38,860 --> 00:38:39,780
Okay.

267
00:38:39,780 --> 00:38:42,680
Let's move on to the next part.

268
00:38:47,750 --> 00:38:59,610
The hello CPP is my... is my demonstrated vulnerable program.

269
00:39:01,090 --> 00:39:14,370
And it... it reads the... it reads the bin file of the root... root directory by F read.

270
00:39:14,370 --> 00:39:25,070
And then read this... read the file to the stack... stack variable buff.

271
00:39:25,070 --> 00:39:31,430
And the... the buff is only 512 bytes.

272
00:39:31,430 --> 00:39:41,610
So if the bin file is larger than 512 bytes, the... the program will overflow.

273
00:39:42,110 --> 00:39:48,330
And the print F and get a chart is just for test.

274
00:39:48,330 --> 00:39:55,190
They have no effect without the console DL in Windows directory.

275
00:39:55,830 --> 00:39:56,950
The console DL...

276
00:39:56,950 --> 00:40:08,610
the console DL can obtain from Windows mobile and developer power toy or from the pocket console.

277
00:40:39,950 --> 00:40:43,610
Windows C uses BL to...

278
00:40:43,610 --> 00:40:47,690
to call a function.

279
00:40:48,370 --> 00:40:52,290
And in the hello function,

280
00:40:59,520 --> 00:41:03,240
this is the first instruction.

281
00:41:04,080 --> 00:41:07,280
The store AOR to SP.

282
00:41:07,280 --> 00: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.

283
00:41:23,780 --> 00:41:25,100
And...

284
00:41:31,070 --> 00:41:42,790
and the AODMIRSP2PC is the latest instruction in the hello function.

285
00:41:43,430 --> 00:41:45,250
It... this...

286
00:41:45,250 --> 00:41:56,630
this instruction will load the... load the AOR rest that is stored in the stack to the PC rest.

287
00:41:56,630 --> 00:42:05,450
And then the program will flow to the... will flow to the remain function.

288
00:42:05,450 --> 00:42:09,170
It will... then it will return.

289
00:42:09,930 --> 00:42:16,210
So overflow the AOR rest that stored in the stack.

290
00:42:16,210 --> 00:42:22,330
We will obtain the control while the function returned.

291
00:42:35,420 --> 00:42:46,060
The variables memory... the variables memory address that allocated by the program is corresponding to the loaded slot.

292
00:42:46,060 --> 00:42:48,940
Both the stack and the heap.

293
00:42:49,660 --> 00:42:57,440
The process may be loaded into the different slot each start time.

294
00:42:59,240 --> 00:43:05,600
So the base address of the slot always alters.

295
00:43:06,380 --> 00:43:12,660
But we know that the slot zero is mapped from the current process slot.

296
00:43:12,660 --> 00:43:16,420
So it's a stack address is stable.

297
00:43:16,440 --> 00:43:22,080
Anyway you can use the... use a jumper... jumper address.

298
00:43:22,080 --> 00:43:29,840
Jumper instruction address to let your... let the program flow to your shellcode.

299
00:43:32,080 --> 00:43:38,080
Well I tried two methods to construct the exploit path.

300
00:43:38,080 --> 00:43:41,140
The first is like this.

301
00:43:44,200 --> 00:43:53,440
The first... the start is the pad instructions and then is the return address.

302
00:43:53,740 --> 00:44:01,880
That we overflow it and then this return address is our... is pointed to our shellcode.

303
00:44:01,980 --> 00:44:08,240
Well, this is... this exploit path is larger.

304
00:44:12,120 --> 00:44:18,660
The PDA is frozen when the hello program is executed.

305
00:44:19,820 --> 00:44:24,200
I think maybe there are two reasons.

306
00:44:24,200 --> 00: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.

307
00:44:38,740 --> 00:44:45,180
So I changed it to another method to construct the exploit path.

308
00:44:49,670 --> 00:44:51,220
It's like this.

309
00:44:51,220 --> 00: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.

310
00:45:06,700 --> 00:45:13,240
Well, I used this method of success.

311
00:45:13,240 --> 00:45:15,660
I'll demonstrate it.

312
00:45:16,180 --> 00:45:18,900
Okay.

313
00:45:19,960 --> 00:45:33,900
The first... the Bluetooth is closed and I'll... I'll execute hello.

314
00:45:38,180 --> 00:45:48,600
It will print the... it will print the address of the path and the size.

315
00:45:48,600 --> 00:46:00,140
When I press any key, the... the device is restarting.

316
00:46:00,780 --> 00:46:07,720
Well, it has restarted.

317
00:46:19,460 --> 00:46:26,140
Well, after the system restart, the Bluetooth is open.

318
00:46:26,800 --> 00:46:31,640
Well, I'll... I'll close it because it's danger.

319
00:46:36,460 --> 00:46:37,900
Okay.

320
00:46:37,900 --> 00:46:41,840
Let's talk something about the decoding shellcode.

321
00:46:41,840 --> 00:46:47,920
The above shellcode that we talked is the concept shellcode.

322
00:46:47,920 --> 00:46:50,660
It contains a lot of zero.

323
00:46:51,000 --> 00:47:04,120
Well, the other vulnerable programs may be filled with a special characters before the stream buffer flow in some situations.

324
00:47:04,160 --> 00:47:07,600
For example, overflowed by SDR copy.

325
00:47:12,260 --> 00: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.

326
00:47:31,520 --> 00:47:36,160
So, we think about the decoding shellcode.

327
00:47:39,550 --> 00:47:51,490
The newer ARM processor has a hovered architecture which... which separates instruction cache and the data cache.

328
00:47:54,410 --> 00: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.

329
00:48:26,340 --> 00:48:32,040
Well, let's look at this... this shellcode.

330
00:48:35,080 --> 00:48:42,920
Well, this is the decoding shellcode for the... for the test.

331
00:48:42,920 --> 00:48:56,260
The last... the last four instructions is... is move the one to the R1 to R4 registers.

332
00:48:56,260 --> 00:49:08,040
And the beginning of... the first four instructions will modify the last instructions.

333
00:49:08,040 --> 00:49:15,140
It will make the value to 99 because the R1 is 99.

334
00:49:16,500 --> 00:49:20,500
So,

335
00:49:23,780 --> 00:49:39,140
the R1 and the two R4 registers will... will get the 99 in my... in my demonstrated device.

336
00:49:46,370 --> 00:49:57,950
Well, we... we can saw the... the last four instructions has modified.

337
00:50:02,070 --> 00: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.

338
00:50:24,210 --> 00:50:25,770
You can try it.

339
00:50:25,770 --> 00:50:31,390
And maybe only the R1 get the 99.

340
00:50:31,630 --> 00: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.

341
00:50:48,670 --> 00:50:52,710
It has... it has five pipelines.

342
00:50:52,710 --> 00:51:03,050
Maybe the pipelines modify... effect the result.

343
00:51:03,370 --> 00:51:08,770
Well, let's look at another...

344
00:51:08,770 --> 00:51:11,970
another method.

345
00:51:20,420 --> 00:51:37,400
Well, in this method, the last four MOV instructions were... were encoded with the exclusive OR with the 88.

346
00:51:37,700 --> 00:51:45,740
And the start is... is... is the decode... is the decoding shellcode.

347
00:51:45,740 --> 00:51:55,920
It has a loop to... is that... to load... to load the encoded shellcode.

348
00:51:55,920 --> 00:52:03,580
To... to load one byte of encoded shellcode and... and then decode it.

349
00:52:04,580 --> 00:52:09,700
Then start it to the original position.

350
00:52:13,500 --> 00:52:34,220
Well... well, the R1 to R4 registers won't get the... the 1, even if you add a lot of instructions.

351
00:52:44,550 --> 00:52:54,090
Well, we saw the last four instructions is... is decoded.

352
00:52:54,090 --> 00:52:59,250
But they don't get the 1.

353
00:53:01,030 --> 00:53:12,730
So... so I think maybe the load instructions will trigger the cache... some trick... some feature over the cache architecture.

354
00:53:12,730 --> 00:53:22,570
So we must... need the... need to flush the I-cache or D-cache after...

355
00:53:22,570 --> 00:53:26,530
after the shellcode decode.

356
00:53:26,870 --> 00:53:34,070
Well, I think... the first I think about the system interrupt.

357
00:53:34,190 --> 00:53:43,230
I... I used the system interrupt success in the AX power PC and the Spark.

358
00:53:43,230 --> 00:53:51,030
But the SWI instructions in the Windows C is just nonsense.

359
00:53:57,890 --> 00: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.

360
00:54:14,390 --> 00:54:17,450
So it's just a... not instruction.

361
00:54:17,450 --> 00:54:23,370
Well, I tried to... I have to try another method.

362
00:54:24,250 --> 00:54:31,610
Because the pocket PC ROMs were built with the full kernel mode option.

363
00:54:31,610 --> 00:54:35,470
The applications running the kernel mode.

364
00:54:35,470 --> 00:54:44,110
So I think about the MCR instructions to flush the I-cache and the D-cache.

365
00:54:46,250 --> 00:54:52,910
The MCR instruction can access the... in the kernel mode only.

366
00:54:52,990 --> 00:55:01,110
But... but unfortunately, this... this method all failed.

367
00:55:17,400 --> 00:55:20,680
Okay, let's move on to the last part.

368
00:55:21,340 --> 00:55:28,180
The codes we talked about are the real life buffer flow example in Windows C.

369
00:55:28,180 --> 00:55:34,480
It's simple, but I think this technology will be improved in the future.

370
00:55:36,020 --> 00:55:44,020
Because the instruction cache and the decoding shellcode is not good enough.

371
00:55:44,580 --> 00:55:49,620
Well, the internet and the handset devices are growing quickly.

372
00:55:50,400 --> 00:55:56,400
The threats to PDAs and the mobiles becomes more and more serious.

373
00:55:57,580 --> 00:56:09,020
The patch of Windows C is more difficult and dangerous because the... the entire operating system is in the ROM.

374
00:56:09,020 --> 00:56:10,500
Contained in the ROM.

375
00:56:10,500 --> 00: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.

376
00:56:29,200 --> 00:56:38,940
And it is... it is danger and... it is danger and difficult for the normal customers.

377
00:56:42,680 --> 00:56:47,180
Well, I consulted a lot of people on the internet.

378
00:56:47,180 --> 00:56:49,120
It's all listed here.

379
00:56:51,580 --> 00:56:58,540
I'll show my special appreciation to Nestle, who helped... who helped me a lot.

380
00:56:58,820 --> 00:57:01,940
Well, that's the end of my presentation.

381
00:57:01,940 --> 00:57:03,400
Hope you enjoyed.

382
00:57:03,740 --> 00:57:06,020
And sorry my lame English.

383
00:57:06,020 --> 00:57:07,160
Thank you.

384
00:57:07,160 --> 00:57:07,340
Thank you.