It builds in a (derived) RAZZLE/DAZZLE/WDK/DDK/VC++DOS build environment AND it outputs NTOSKRNL.EXE which can then be used to DIRECTLY AND COMPLETELY replace/file-overwrite/slip-stream/patch/pre-install-by-WAIK+WINPE; ie: either way you look at it YOU GET NTOSKRNL.EXE WITH WHATEVER CODE WRITTEN IN IT (including your rootkit/custom code) AND IT WILL WORK. Because this is RING 0 the entire system is yours. In fact: if you look at how NTLDR/OSLOADER+NTDETECT (or even EFI/DEC-ALPHA/MAC systems) boot up --> there is a lot of initialzation done before the actual "system process" and/or "idle thread" and/or "worker threads" are created. This includes the actual creation of the object manager and the HAL and CPU code as well as 'DOS' switches that are passed to NTOSKRNL.EXE in command line fashion. But yes: WINDOWS/NT sees everything as OBJECTS. And to do this it must create an OBJECT ORIENTED ENVIRONMENT (OBJECT MANAGER) first. THEN it creates the SYSTEM PROCESS and flows on from there. Also look at SINGULARITY: this bootstraps up the .NET (C#) FRAMEWORK and COMMON LANGUAGE RUNTIME/INFRASTRUCTURE and BYTECODE-INTERPRETER/MANAGEMENT and then allows a 'MANAGED' KERNEL (C# WRITTEN/.NET) TO EXECUTE. Very interesting concepts. Put these two together and think: imagine a NTOSKRNL.EXE that had it's object manager hacked so that it 'SAW' the objects of other machine's (IE: other enumerated system's object manager tree is fleshed out along with registry by loader/strapper/kernel and pooled) and then THE FINAL SERVER MACHINE OF - SAY - TEN MACHINES - (the first nine are SLAVES whose objects are 'donated' and who run nothing but NTOSKRNL.EXE and HAL+DRIVERS) ---> [THE FINAL SERVER...] gets all these objects (RAM, DEVICES, FILES, DRIVERS, PROCESSES, MEMORY, ADDRESS, INTERRUPTS, PROCESSORS, ETC). and maybe in a NUMA fashion or TERMINAL-SERVER (\Windows ? \Sessions ? \Winsta* \Global \??) merge-multiple-sessions-and-object_trees TYPE FASHION: gives a SINGLE SYSTEM IMAGE SUPER WINDOWS ???
You could definetley get there. Just look at AZURE. But anyway: yes: the ultimate goal here is to
FIRST CREATE A NTOSKRNL.EXE THAT CAN REPLACE THE REAL FILE ON ANY RTM/RETAIL/STANDARD SERVER 2003 DISTRIBUTION AND DO THE FOLLOWING: THE BEST BACKDOOR/FULL CONTROL/ULTIMATE WOULD BASICALLY BE THIS: TO BE ABLE TO LIVE DEBUG+DISASSEMBLE+SEND-SYSTEM-CALLS DIRECTLY. THIS IS HOW IT WILL BE DONE: PUT CODE INTO NTOSKRNL.EXE BEFORE SYSTEM PROCESS IS EVEN CREATED. COULD EVEN DO THINGS BEFORE THE 'PROCESS' AND 'THREAD' AND 'PROCESSOR' CONCEPTS (OBJECTS) ARE EVEN DEFINED... NO HASHING OR CRYPTOGRAPHY OR EVEN TRUSTED PLATFORM MODULE (UNLESS SPECIFICALLY DESIGNED TO TARGET THIS FILE - BUT JUST LOOK AT THE V1-XBOX !) COULD GET AROUND THIS BECAUSE NTOSKRNL.EXE ***IS THE OS*** ITSELF !!! SO YOU CAN DEFINE EXACTLY WHAT CRYPTO/HASHING/NSA-STYLE-STUFF EVEN MEANS !!! THE CPU/SYSTEM/FIRMWARE ARE 'BLANK' SO TO SPEAK. AND IN RESPECT TO THE SOURCE TREE NOT BEING THE FULL CODE OF WINDOWS 2003 WELL ***IT IS*** FOR ALL INTENTS AND PURPOSES AND THE OTHER CODE IS NOT MISSING BUT JUST PARTIALLY PRE-COMPILED INTO .OBJ FILES WHICH ARE MORE SYMBOLIC THAN ANY DEBUG FILES SO IT IS ***VERY*** EASY TO DISASSEMBLE AND GET FULL CODE; NOT TO MENTION IF YOU COMBINE RESEARCH KERNEL WITH LEAKED NT4, WIN2K, AND TINYKRNL (tinykrnl.org), and MSDOS-leaks, and BIOS-leaks, and even some REACTOS and EFI/BIOS; YES YOU ARE THERE ! ESPECIALLY NT4+WIN2K+WRK ! JUST LOOK AT THE CODE IN NT4 TREE ! IT IS MORE THAN COMPLETE; MAYBE A BIT MESSY; BUT IT HAS ALL THE BOOT-CODE AND INIT CODE (NTOS) AND EVEN SHELL; EVERYTHING TO THIS DAY IS BASED ON THAT \private\ntos\ TREE IN SOME WAY... THANKS stevewo !!!!!!!!!!! ANYWAY: THE ULTIMATE WILL BE THIS: USING TECH/CONCEPT/VIRT
No comments:
Post a Comment