start	end	text
4000	12840	Okay, I'm from China. The title of my presentation is Hacking Windows C. It's about the security
12840	23200	problems of PDAs and mobiles. My presentation is constructed with eight parts. First of all,
23200	30580	I'll make a brief introduction of Windows C, because ARM processors is the most useful
30580	40700	processor in PDAs and mobiles, so I'll introduce the ARM processor's architecture.
41540	47560	You know, understanding memory management is very important for Buffalo Flow. The second,
47560	57540	I'll introduce memory management with graphics. Compared with other Windows systems, Windows
57540	66040	C chooses processes in a different way. Then I'll introduce the features of processes and
66040	81360	threads of Windows C. The Windows C API search technology is funny. I'll introduce how to
81360	89820	write shellcode using this method. And I will also introduce the implementation of system code
90360	99380	and use it to write shellcode. After this, I'll demonstrate a simple Buffalo Flow. Well, I
99380	109380	think this technology will be improved in the future. Then I'll talk something about decoding
109380	115820	shellcode. The decoding shellcode will make the real shellcode more universal, but ARM
116380	124320	processor's cache architecture makes it funny. At last, I'll conclude my presentation. Okay,
124320	131900	let's move on to the next part, the first part. Windows C is a very popular embedded operating
131900	144320	system for PDAs and mobiles. The name is developed by Microsoft. Because of the familiar
144320	153280	APIs, Windows developers can easily develop applications for Windows C. Maybe this is a very
153280	160860	important reason that makes Windows C popular. Windows C file is the latest version, but
161740	171480	Windows C.net is the most useful version, and my presentation is based on this version. Maybe
171480	179360	for marketing reasons, there is Windows mobile software for pocket PC and a smartphone in
179360	187960	Microsoft's website and MSDN, but they are all based on the core of Windows C. By default,
187960	197060	Windows C is in little Indian mode and it supports several processes. Almost all of the
197060	208800	embedded devices will use ARM CPU. ARM processor is a typical RISC processor, which
208800	216720	implements a load store architecture. Only load and store instructions can access memory.
216720	227640	Data operating instructions operate on RISC contents only. There are six major versions of
227640	245420	ARM architecture. The demonstrated device has a Samsung S3 C2410 processor, which has
245420	256380	an ARM 9 core and the architecture version is an ARM V4T. More and more PDAs are using Intel X
256380	269120	scale processor, which architecture version is V5TE. ARM processors support seven
269120	279000	processor modes, depending on the architecture version. These modes are user, FIQ, IRQ,
279000	289520	supervisor, undefined, abort and system. The system mode requires ARM architecture V4 and above.
289520	298460	All modes except the user mode are referred to privileged mode. Applications usually are running
298460	311100	user mode, but on the pocket PC, all applications appear to be running in kernel mode. I'll talk
311100	325220	about it later. Windows ARM processor has 39 registers. These registers are arranged in
325220	336540	partially overlapping banks. There's different registers for each processor mode. The bank
336540	344220	registers give rapid context switching for dealing with processor exception and
346200	356700	privileged operations. In ARM architecture V3 and above, there are 30 general purpose registers,
356700	368220	the program counter register, the current program status register and the file saved program
368220	378620	status register. 15 general purpose registers are visible at any one time, depending on the
378620	391060	processor mode. By convention, R13 is used as a stack point in ARM assembly language. The C
391060	402540	and the C++ compilers always use R13 as a stack point. In user mode and system mode, R14 is
402540	414520	used as a link register, which stores the return address while a subroutine call is made. The
416580	426540	program counter register is accessed as R15. It can access directly by data processing
426540	436440	instructions. This feature is different from other processors and it is useful for code
436440	447680	location while writing show code. You know, understanding memory management is very important for
447680	457020	buffer overflow. But Windows C, but compared to other Windows systems, Windows C chooses memory
457020	469320	management in a different way. Windows C uses ROM and RAM. The ROM in the Windows C system is
469320	476860	just like a small read on a hard disk. It stores the entire operating system as well as the
476860	487880	applications that are bundled in the system. The data, um, the data can maintain inside the
487880	497480	ROM without power or battery. The RAM in a Windows C system is divided into two areas. The
497480	505680	program memory and object store. The object store can be considered something like a
505680	517200	permanent virtual RAM disk. It's unlike a RAM disk in the PC. It can maintain the files
517200	526360	in it, uh, even if the system turned off. That, that is the reason that, this is the reason that
527180	535080	Windows C devices typically have a main battery and a backup battery. They provide the power to
535080	545460	my, to the RAM to maintain the files stored in it. Even when the user hit the reset button, the
545460	554820	Windows C kernel starts up looking for previously created object store. Um, the system will
554820	569380	use that store if it finds one. Another area of Windows C RAM is program memory. Program
569380	577720	memory is just like the RAM in the PC. Uh, it stores the heaps and the stacks that, uh, the
577720	587260	application, for applications that are running. Um, the, the dividing of the, between the
587260	595840	object store and the program memory is adjustable. The user can move the dividing line, uh, by
595840	605620	the system control panel applet. Windows C is a, um, 32-bit operating system, so it supports
605620	616000	4GB virtual address space. Let's look at this graph. This is the, um, 4GB virtual address space
616000	634130	layout. The upper 2GB is, uh, used for, used by, is a kernel space used by a system for its own
634130	643890	data. And the lower 2GB is a user space. From this address, uh, to below this address,
643890	653650	the memories are used to, um, um, uh, larger memory, larger memory allocation. Such a, uh,
653650	662750	it's used by the, uh, such as memory mapped files. Um, um, object store is loaded here. And from
662750	672710	zero to below, this, uh, uh, this memory is, uh, divided into 33 slots. Each of which is a
672710	686980	32MB. The slot 1 is, uh, uh, XIP, uh, executed in place. This is a new feature, uh, of the
686980	703400	Windows C.net. Uh, it expanded the application's virtual address space from 32MB to 64MB. Well,
703400	715500	this graph is, uh, is the slot 0 virtual address space layout. Slot 0 is very important. It's,
715500	729180	uh, used by the current active process. The first 64KB is, uh, reserved by the OS. And the
729180	741000	following is the process's code, code and data. Um, stacks and heaps are arranged here.
741980	756550	DLL files are loaded into the top, uh, top address. Well, let's move on to the next part. Um,
756550	763530	uh, compared with other, uh, system, Windows C.net chooses processes in a different way. Windows
763530	771770	C.net limits, uh, 32 processes being run at any one time. Uh, when the system starts, at least
771770	784310	four processes are created. Um, let's look at the previous, uh, graph. NKEXE, uh, which
784310	796610	provides the kernel service. It's always loaded into the slot 97. Um, filesystem.exe, which
796610	808590	provides the filesystem service. It's always in slot 2. Device.exe, which, uh, which, uh,
808590	820490	load and maintains the device drivers for system. It's in slot 3 normally. And, uh, GWES.exe, which
820490	840130	provides GUI support. The other processes are also created such as explorer. Um, the, uh,
840130	848170	other Windows system. Each process, at least, has a primary thread, uh, associated it, uh, up
848170	858170	on start. Uh, if it never, never created one. One process, uh, can create any number of threads
858170	867590	only limited by the available memory. Um, each thread belongs to a particular, uh, process and
867590	877490	shares the same memory. But the, uh, set prog permissions API, uh, can give the, um, current
877490	888450	thread access any, any process. Each thread has an ID, a private stack, and a set of registers.
888450	898450	When the process is, uh, loaded, uh, the system will assign the next, uh, available slot to it.
898450	907230	And DL files loaded into the top address of the, um, uh, uh, uh, address space. And then
907230	916690	followed by the stack and the default process heap. After this, then execute it. Uh, when the, uh,
916690	924570	when the process is, the thread is scheduled, the system will copy, uh, copy from its slot to slot
924570	934410	zero. It's not a real copy operation, it's just mapped into the slot zero. Uh, this is mapped
934410	952210	back to the original slot allocated to the process if the process becomes inactive. Process, uh,
952210	960730	allocated stack for each thread. The default size is, uh, 64 KB, uh, depending on the link
960730	969270	parameter when the, uh, program is compiled. This, uh, this size can, can, can be modified. The
969270	976670	top two KB is used to guard against the stack overflow. We can't destroy this memory,
976670	986710	otherwise the device will freeze. And the remainder, uh, available for use. Um, variables
986710	994850	declared inside the function are allocated in the stack. Um, thread stack memory is reclaimed
994850	1005810	when it terminates. Well, let's move on to the next part. Um, before, before exploit, we must
1005810	1014810	have, uh, share code to run on the Windows CE. Um, Windows CE implements, uh, V32
1015580	1025870	compatibility. The core DLL provides the entry points for, uh, for the, for almost all the APIs
1025870	1039360	that implement, uh, that in the core DLL. Um, um, um, we must, uh, search the, uh, necessary
1039360	1049680	API addresses, um, and then you use this, uh, uh, API address, APIs to implement our share code.
1049680	1059240	The traditional method to implement, uh, uh, share code, uh, in the, uh, other Windows system
1059240	1071320	is to, uh, locate the kernel 32 or NTDL, uh, via PB structure and then search, uh, search
1071320	1081900	necessary APIs via, uh, P head structure. Well, is there any structure like, um, PB on the
1081900	1091480	Windows CE? The answer is yes. That's, um, the kernel, the, uh, K data structure will satisfy
1091480	1106140	those. The defined in NK arm.h. Uh, K data structure is, uh, is a very important kernel, uh,
1106140	1115320	kernel structure can be accessed from user mode by fixed, uh, address, uh, K user, uh, P user
1115320	1126940	K data. Um, the value over, uh, the value over P user K data is defined in the, uh, K functs.
1126940	1141940	It's in the normal SDK. Um, uh, the value, uh, the P user K data is, uh, FFFC800 in ARM
1141940	1145300	processors and, uh, file 8, uh, file 8, uh, file 8, uh, file 8, uh, file 8, uh, file 8, uh, file 8,
1145300	1163140	800 on the, uh, other CPUs. Well, let's look at the last member of, uh, K data structure. Um, it's
1163140	1184160	offset 300 from the start of K data structure. Um... There is, uh, the, uh, the, uh, the, um,
1184180	1194100	AIN4 is a DWORD array and there is a point to the module list
1194100	1207440	index 9. So offset 3 to 4 from the FFFC800 is the point to the
1207440	1213840	module list. Well, let's look at the module structure.
1213840	1228580	The first member is defined in kernel header file. The second
1228580	1236100	member is P mode. It's a point to the next module of the module
1236100	1250140	chain. The third member is LPSZ mode name. It's a module name
1250140	1257700	string. So we can locate the core DLL by comparing the unicode
1257700	1270270	string of its name. Well, we also notice the E32 member. Let's
1270270	1278810	look at this. E32 member is the E32 structure. It's defined in
1278810	1284390	kernel header file. The third member is P HDR. Well, let's look
1284390	1293790	into the E32 structure. The E32 V base will tell us the virtual
1293790	1300070	base address of the module. So we can locate the virtual base
1300070	1306910	address of the core DLL. We also notice the last member is E32
1307960	1314410	unit. It's an info structure and the info structure has two
1314410	1320230	members. The first is the virtual relative address and the second
1320230	1330590	is the size. And the little extra is defined in the P HDR. The
1330590	1340690	start of P HDR. Six members used by NK. And the first is the
1340990	1349170	export table position. So from now on, we got the
1349170	1356150	virtual base address of the core DLL and its export table
1356150	1362530	relative address of the export table position.
1365090	1383950	And I wrote a small... I wrote a small program to list all the
1383950	1392610	virtual base address of all loaded DLL files. This is the
1393190	1406570	KData structure. And offset 324 is a point to the module
1406570	1410550	structure. And the module structure is the chain
1410550	1419090	structure. The offset 4 will point to the next module.
1419090	1424750	So what is the point to the module structure? Well, the
1424750	1433390	point to the module structure is in the kernel space. So this
1433390	1440270	program only... this program only executed in the kernel
1440270	1448390	mode. The user mode... it will fail in the user mode. Well,
1449250	1456010	the most of the PC ROMs were built with the full kernel mode
1456010	1462810	option. That's the applications all running kernel mode.
1467030	1474450	So... so this small program will execute in the most of the
1474450	1484870	pocket PC. I used this program to call the virtual base
1484870	1492790	address of the core DLL is 1F6000. But when I use the
1492790	1498570	EBC debug to look into, this address is invalid. The valid
1498570	1509010	data is from 1F61000. I think maybe the Windows C is just for
1509010	1517710	the purpose to... purpose over memory and start time and then
1517710	1539420	load the head of the DLL file. Okay. The VNCE4.dust uses
1540590	1547400	ordinals to find the API address. But I think use API
1547400	1552580	name to find the... to find the API address is more reliable
1552580	1557600	for share code. Because the API name won't change even if the
1558660	1562320	core DLL file is changed.
1566280	1574420	Well, we can... because we have the export table position and
1574420	1583360	the base address of the core DLL. So we can use the... we can
1583360	1593060	compare the image export directly to find the API
1593060	1599720	address via API name. To save size, we can use the hash
1599720	1611160	technology that from the LSD's V32 assembly components. And
1611400	1616820	this is... this graph is ripped from LSD's V32 assembly
1616820	1624220	components too. And it shows the way to locate the base
1624220	1627720	address via API name.
1631780	1639700	Well, let's move on next part. The test ASM is our final
1639700	1651840	share code. It constructs with three parts. First, it will
1651840	1660400	call get export section to get the virtual base address of the
1660400	1666900	core DLL and its relative virtual address over export table
1666900	1677320	position. And then it uses find function to find the API
1677320	1683960	address via the hash value over the API name. And then stores
1685270	1692560	the... find the... store the API address to the... its own hash
1692560	1701720	value position. The last part is our implementation of our
1701720	1709800	share code. It will change the register key over Bluetooth and
1709800	1725550	then use kernel IO control to soft restart it. This share
1725550	1750620	code will open the Bluetooth over some... we must notice the
1753220	1760700	some... some assembly LDR pseudo instruction. Here, what I
1760700	1773430	comment of this instructions. Because... because this pseudo
1773430	1779170	instruction will be this in the EVC debug. It depend on the
1779170	1791810	program. So, it won't get the FFF C800 in the share code. So,
1791810	1797210	this instruction will make the share code fail. And the next
1798170	1807770	instruction will be this in the EVC debug. It's okay. Well, in
1807770	1817450	Windows CE, the R3 and... R0 and R3 use the first to fourth
1817450	1825590	parameters of the API. If the... if the parameter is larger than
1825590	1832390	four, the other parameters will store in the stack. So, we must
1832390	1836150	pay attention while writing share code. Because the...
1836150	1842590	because the share code always in the stack... stack memories.
1845430	1851430	Well, EVC debugger has some bugs that make... make debugger
1851430	1857970	difficult. The first, EVC will change the stack contents when
1857970	1864990	the stack... in the end of the function. Well, it's... it's
1864990	1872090	difficult to debug the buff overflow. Because the share
1872090	1877650	code may be changed. And the instruction or the break point
1877650	1886990	may be changed to E600010 in EVC sometimes. Well, it's... it's
1886990	1894230	very bothering. And EVC allows the code to modify the text
1894750	1903030	segment without error while... while using break point or you...
1903030	1909030	when you step by step to debug into. But sometimes it's
1909030	1917310	useful. Well, the... the... for the ARM debugger also have
1917310	1924250	this... also have this bugs. So, I think maybe this is a bug of
1924250	1939090	the debugger API over Windows CE. Maybe. Well, let's move on
1939090	1943070	to the next part. The above share code we talked is
1943070	1950510	complicated and it can't run in user mode. Is there any... is
1950510	1956710	there any other method to implement share code? Well,
1956710	1983930	let's look at an API implemented in the core DLL. Well, let's
1983930	1991330	look at the power of the system. It has no parameters. The
1991930	2000750	first... the system will check the... check the kthread info
2000750	2011370	structure. And the kthread info is initialized in the MD
2011370	2024060	created thread two function in the... in the MD... in the MD
2024060	2036330	ARM.c. If the... if the application running kernel
2036330	2042930	mode, this value will... the kthread info will be set with
2042930	2058930	one. Otherwise, this value is saved zero. So, it tests this
2059670	2068930	memory is one. Because the... if this... if this... if kthread
2068930	2076810	info is one, then the system will use the API... API set table
2076810	2082950	to find the real... real implement... implementation in
2082950	2089150	the kernel space. If you... if your application is running...
2089570	2096750	running kernel mode and this... this instruction will execute
2096750	2102850	the... the R1 is the... is start from the eight... blah, blah,
2102850	2108810	blah. It's in the kernel space. Otherwise, if the... if the
2108810	2120370	kthread info is zero, the system will use this. This is... is the
2120370	2129890	system call over Windows C. The system call number is from
2129890	2144050	F... F0000 to F001000. There is a formula to... to determine
2144050	2156240	the API... determine the system call number. It's like this.
2159050	2165650	So... use this formula, we can calculate the system call
2165650	2172910	number. Well, let's calculate the kernel IO control. Kernel IO
2172910	2190640	control is in the... is defined in the k... kvim32.c. And the
2190640	2209540	API set is... is zero. And the index is 99. So... so we
2209540	2219860	calculated the system call number is like this. F0000FE74.
2220300	2225720	Well, it's a... it's a... the system call number is more
2225720	2233580	stable... more stable than the API address that implement in
2233580	2243580	the core DL. Because... because the variable compile the ROM,
2244760	2250980	the... the API address is a variable. So this... this
2250980	2262220	share code is very simple. It only uses the system call to
2262220	2269580	system call to... so... so this... this share code will... can
2269580	2276740	execute in the user mode. But also the kernel mode. So I
2276740	2280840	think this share code will use in the smartphone. The
2280840	2286620	smartphone... the smartphones ROM not build... not build with
2286620	2292820	the full kernel mode option. And the Microsoft device
2292820	2301140	emulators ROM has... has no this option too. I tested this...
2302160	2308900	this... this share code success in the Microsoft device
2308900	2320880	emulator and my demonstrated device. Okay. Let's move on to
2320880	2335390	the next part. The hello CPP is my... is my demonstrated
2335390	2345970	vulnerable program. And it... it reads the... it reads the
2345970	2355690	bin file of the root... root directory by F read. And then
2356010	2365070	read this... read the file to the stack... stack variable buff.
2365070	2373030	And the... the buff is only 512 bytes. So if the bin file is
2373030	2382590	larger than 512 bytes, the... the program will overflow. And
2382590	2389030	the print F and get a chart is just for test. They have no
2389030	2396950	effect without the console DL in Windows directory. The console DL...
2396950	2403150	the console DL can obtain from Windows mobile and developer
2403150	2443610	power toy or from the pocket console. Windows C uses BL to...
2443610	2460780	to call a function. And in the hello function, this is the
2460780	2469700	first instruction. The store AOR to SP. It will store the AOR
2469700	2478060	address to the stack port... to the stack... to the stack which
2478060	2496970	contains the hello callers address. And... and the AODMIRSP2PC
2496970	2505250	is the latest instruction in the hello function. It... this...
2505250	2512670	this instruction will load the... load the AOR rest that is
2512670	2518750	stored in the stack to the PC rest. And then the program will
2518750	2527170	flow to the... will flow to the remain function. It will... then
2527170	2535370	it will return. So overflow the AOR rest that stored in the
2535370	2555640	stack. We will obtain the control while the function returned. The
2555640	2561300	variables memory... the variables memory address that allocated by
2561300	2567220	the program is corresponding to the loaded slot. Both the stack
2567220	2574560	and the heap. The process may be loaded into the different slot
2575220	2585600	each start time. So the base address of the slot always alters.
2586380	2590780	But we know that the slot zero is mapped from the current
2590780	2597320	process slot. So it's a stack address is stable. Anyway you can
2597320	2602780	use the... use a jumper... jumper address. Jumper instruction
2602780	2609840	address to let your... let the program flow to your shellcode.
2612080	2618220	Well I tried two methods to construct the exploit path. The
2618220	2628380	first is like this. The first... the start is the pad instructions
2628380	2636600	and then is the return address. That we overflow it and then this
2637260	2644080	return address is our... is pointed to our shellcode. Well, this
2644080	2654740	is... this exploit path is larger. The PDA is frozen when the
2654740	2664200	hello program is executed. I think maybe there are two reasons.
2664200	2671780	The first is that the stack of Windows C is small and maybe the
2671780	2678660	overflow destroyed the 2KB guard on the top of the stack boundary.
2678740	2685180	So I changed it to another method to construct the exploit path.
2689670	2696720	It's like this. I moved the shellcode in the start position and then
2696720	2703800	the last is the... is the return address that pointed to our
2704340	2714100	shellcode. Well, I used this method of success. I'll demonstrate
2714100	2730100	it. Okay. The first... the Bluetooth is closed and I'll... I'll
2731040	2745480	execute hello. It will print the... it will print the address of the
2745480	2757920	path and the size. When I press any key, the... the device is
2757920	2782520	restarting. Well, it has restarted. Well, after the system
2782520	2790020	restart, the Bluetooth is open. Well, I'll... I'll close it because
2790020	2801840	it's danger. Okay. Let's talk something about the decoding shellcode.
2801840	2808000	The above shellcode that we talked is the concept shellcode. It
2808000	2817100	contains a lot of zero. Well, the other vulnerable programs may be filled
2817100	2822560	with a special characters before the stream buffer flow in some
2822560	2833880	situations. For example, overflowed by SDR copy. It's difficult and
2833880	2839800	inconvenient to write a shellcode without a special... without a special
2839800	2847840	characters because if you use the R0, the opcode will contain the... will
2847840	2860510	contain this zero. So, we think about the decoding shellcode. The
2860510	2867590	newer ARM processor has a hovered architecture which... which separates
2868070	2877070	instruction cache and the data cache. This feature will improve the
2877070	2884130	performance of the ARM processor but the self-modifying code is not easy to
2884130	2892130	implement because it will affect by the ARM cache architecture and the
2892130	2910240	processes... processor's implementation. Well, let's look at this... this
2910240	2922920	shellcode. Well, this is the decoding shellcode for the... for the test.
2922920	2934400	The last... the last four instructions is... is move the one to the R1 to R4
2934420	2945480	registers. And the beginning of... the first four instructions will modify the
2945480	2964480	last instructions. It will make the value to 99 because the R1 is 99. So, the R1
2964480	2979140	and the two R4 registers will... will get the 99 in my... in my demonstrated device.
2986370	3005910	Well, we... we can saw the... the last four instructions has modified. But... but it
3005910	3013470	will need more... need more NOP instructions between the decoding... decoded shellcode
3013470	3025770	and... and the real shellcode in the Intel X... Intel X scale processors. You can try it.
3025770	3041230	And maybe only the R1 get the 99. I think maybe the... the ARMV file architecture has... has
3041230	3050770	six pipelines and... and my demonstrated device only has... is the ARMV4. It has... it has
3050770	3068770	five pipelines. Maybe the pipelines modify... effect the result. Well, let's look at another...
3068770	3092820	another method. Well, in this method, the last four MOV instructions were... were encoded
3092820	3104900	with the exclusive OR with the 88. And the start is... is... is the decode... is the decoding
3104900	3116660	shellcode. It has a loop to... is that... to load... to load the encoded shellcode. To... to load
3116660	3129700	one byte of encoded shellcode and... and then decode it. Then start it to the original position.
3133500	3151500	Well... well, the R1 to R4 registers won't get the... the 1, even if you add a lot of
3151500	3179250	instructions. Well, we saw the last four instructions is... is decoded. But they don't get the 1.
3181030	3190070	So... so I think maybe the load instructions will trigger the cache... some trick... some feature
3190070	3202570	over the cache architecture. So we must... need the... need to flush the I-cache or D-cache after...
3202570	3215470	after the shellcode decode. Well, I think... the first I think about the system interrupt. I... I
3215470	3226670	used the system interrupt success in the AX power PC and the Spark. But the SWI instructions in
3226670	3248350	the Windows C is just nonsense. The... the SWI handle defined in the ARM trap is... it's... it's
3248350	3260710	just a... moves the AOR rest to the PC. So it's just a... not instruction. Well, I tried to... I
3260710	3269990	have to try another method. Because the pocket PC ROMs were built with the full kernel mode
3270710	3280490	option. The applications running the kernel mode. So I think about the MCR instructions to
3280490	3291610	flush the I-cache and the D-cache. The MCR instruction can access the... in the kernel mode
3291610	3319600	only. But... but unfortunately, this... this method all failed. Okay, let's move on to the last
3319600	3329500	part. The codes we talked about are the real life buffer flow example in Windows C. It's simple, but
3329500	3340900	I think this technology will be improved in the future. Because the instruction cache and the
3340900	3348620	decoding shellcode is not good enough. Well, the internet and the handset devices are growing
3348620	3358580	quickly. The threats to PDAs and the mobiles becomes more and more serious. The patch of
3358580	3368500	Windows C is more difficult and dangerous because the... the entire operating system is in the
3368500	3376440	ROM. Contained in the ROM. And if you... if you want to patch the system for completely, you
3376440	3388180	must flush the system... the system... you must flush the system... you must flush the... the
3388180	3404060	ROM. And it is... it is danger and... it is danger and difficult for the normal customers. Well, I
3404060	3413400	consulted a lot of people on the internet. It's all listed here. I'll show my special
3414080	3421940	appreciation to Nestle, who helped... who helped me a lot. Well, that's the end of my presentation.
3421940	3427160	Hope you enjoyed. And sorry my lame English. Thank you.
3427160	3427340	Thank you.