TIME

NEPAL QATAR BELFAST, UK MALAYSIA DUBAI

Friday, May 22, 2020

Removing Windows 8/8.1 Password With CHNTPW



[Update] If you want to recover Windows 8/8.1 passwords instead of removing them see this tutorial

So we are back. About a Year ago I wrote a post on how to remove Windows Password using CHNTPW but many readers complained that it was not working on Windows 8. I tried myself on many it worked but once I also got stuck. So I did a little work around. In this tutorial I'm going to show you how to remove Windows 8/8.1 passwords using CHNTPW. Well it's little bit tedious than the older one but believe me it's fun too.


Background:

Let's get started with a little bit background. Windows OSs have a User known as Administrator which is hidden by default. This user is there for security reasons (maybe it's the way around). Most of the users who use Windows are lame, sorry to say that but I'm not talking about you, they don't even know that such an invisible account exists so it is almost everytime without a password. But this Administrator user is a SU (Super User), that means you work wonders once you get access to this account. So our first task will be to make it visible and then we'll access it and using it's power privilages we'll remove password of other accounts (which is not really neccessary cuz you can access any user folder or file using Administrator Account).


Requirements:

1. Physical Access to the Victems computer.
2. A Live Bootable Kali/Backtrack Linux Pendrive or DVD.
    (You can downoad Kali Linux here)


Steps:

1. Plug in the Live Bootable Pendrive/DVD into to victim's computer and then boot from it.

2. After accessing kali linux (I'm using Kali Linux) from victim's computer open a terminal.

3. Now we have to mount the drive on which the victim's OS is loaded. In my case it is sda2. So in order to mount that drive I'll type the command:
mount /dev/sda2 /media/temp



this means that I'm mounting the drive in folder /media/temp if you haven't created a temp folder in /media then you must create one by typing these command:
cd /
mkdir /media/temp

4. After mounting the OS we need to access the SAM file and make visible Administrator account using chntpw. It's so simple lemme show you how.
first we'll navigate to /media/temp/Windows/System32/config:
cd /media/temp/Windows/System32/config

now we display the list of users on our victim's computer:
chntpw SAM -l



You'll see an Administrator User there which is disabled. Now we'll enable that:
chntpw SAM -u Administrator



now type 4 and hit return



press 'y' to save changes to SAM file.



OK voila! the hard part is done.

5. Now restart your Computer and take out your Pendrive/DVD from your computer and boot into windows 8 OS. You should be able to see Administrator User on Logon screen now. If not then look for a backward pointing Arrow besides the user Login Picture. Click on that Arrow and you should see an Administrator User. Click on the Administrator Account and wait for a while until windows 8 sets it up.

6. After a while you get Access to the computer and you can access anything. Enjoy :)

7. What you want to remove the password? I don't think it's a stealth mode idea, is it? OK I'll tell you how to do that but It's not a good hacker way of doing.
Open up the command prompt, simple way to do it is:

Press Ctrl + 'x' and then Press 'a' and if prompted click yes.
After that Enter following commands:

net user
(This command will display all users on computer)

net user "User Name" newPassword 
(This Command will change the Password of User Name user to newPassword).
OK you're done now logout and enter the new password. It will work for sure.

8. If you want to disable the Administrator Account again then type in command prompt:
net user Administrator /active:no

I tried it on Windows 8/8.1 all versions and it works. Guess what it works on all windows OSs.

Hope you enjoyed this tutorial. Don't forget to share it and yes always read the Disclaimer.

More info


  1. House Hacking
  2. Que Es Hacker En Informatica
  3. Tecnicas De Hacking
  4. Curso Completo De Hacking Ético
  5. Curso Hacker

Reversing C++ String And QString

After the rust string overview of its internal substructures, let's see if c++ QString storage is more light, but first we'r going to take a look to the c++ standard string object:



At first sight we can see the allocation and deallocation created by the clang++ compiler, and the DAT_00400d34 is the string.

If we use same algorithm than the rust code but in c++:



We have a different decompilation layout. Note that the Ghidra scans very fast the c++ binaries, and with rust binaries gets crazy for a while.
Locating main is also very simple in a c++ compiled binary, indeed is more  low-level than rust.


The byte array is initialized with a simply move instruction:
        00400c4b 48 b8 68        MOV        RAX,0x6f77206f6c6c6568

And basic_string generates the string, in the case of rust this was carazy endless set of calls, detected by ghidra as a runtime, but nevertheless the basic_string is an external imported function not included on the binary.

(gdb) x/x 0x7fffffffe1d0
0x7fffffffe1d0: 0xffffe1e0            low str ptr
0x7fffffffe1d4: 0x00007fff           hight str ptr
0x7fffffffe1d8: 0x0000000b        sz
0x7fffffffe1dc: 0x00000000
0x7fffffffe1e0: 0x6c6c6568         "hello world"
0x7fffffffe1e4: 0x6f77206f
0x7fffffffe1e8: 0x00646c72
0x7fffffffe1ec: 0x00000000        null terminated
(gdb) x/s 0x7fffffffe1e0
0x7fffffffe1e0: "hello world"

The string is on the stack, and it's very curious to see what happens if there are two followed strings like these:

  auto s = string(cstr);
  string s2 = "test";

Clang puts toguether both stack strings:
[ptr1][sz1][string1][null][string2][null][ptr2][sz2]

C++ QString datatype

Let's see the great and featured QString object defined on qstring.cpp and qstring.h

Some QString methods use the QCharRef class whose definition is below:

class Q_EXPORT QCharRef {
friend class QString;
QString& s;
uint p;
Searching for the properties on the QString class I've realized that one improvement that  rust and golang does is the separation from properties and methods, so in the large QString class the methods are  hidden among the hundreds of methods, but basically the storage is a QStringData *;

After removing the methods of QStringData class definition we have this:

struct Q_EXPORT QStringData : public QShared {
    QChar *unicode;
    char *ascii;
#ifdef Q_OS_MAC9
    uint len;
#else
    uint len : 30;

5 BEST HACKING BOOKS 2018

Most of the people don't go with videos and read books for learning. Book reading is a really effective way to learn and understand how things work. There are plenty of books about computers, security, penetration testing and hacking. Every book shows a different angle how things work and how to make system secure and how it can be penetrated by hackers. So, here I have gathered a few of the best hacking books of 2018 available on the market.

BEST HACKING BOOKS OF 2018

There are hundreds of books about hacking, but I have streamlined few of best hacking books of 2018.

1. THE HACKER'S PLAYBOOK PRACTICAL GUIDE TO PENETRATION

This handbook is about experting yourself with the hacking techniques in the hacker's way. This is about penetration testing that how hackers play their techniques and how we can counter them.

CONTENTS

  • Introduction
  • Pregame – The Setup
  • Setting Up a Penetration Testing Box
  • Before the Snap – Scanning the Network
  • The Drive – Exploiting Scanner Findings
  • The Throw – Manual Web Application Findings
  • The Lateral Pass – Moving Through the Network
  • The Screen – Social Engineering
  • The Onside Kick – Attacks that Require Physical Access
  • The Quarterback Sneak – Evading AV
  • Special Teams – Cracking, Exploits, Tricks
  • Post Game Analysis – Reporting
Download the Hacker's Playbook Practical Guide to Penetration.

2. ANDROID HACKER'S HANDBOOK

The Android Hacker's Handbook is about how the android devices can be hacked. Authors chose to write this book because the field of mobile security research is so "sparsely charted" with disparate and conflicted information (in the form of resources and techniques).

CONTENTS

  • Chapter 1 Looking at the Ecosystem
  • Chapter 2 Android Security Design and Architecture
  • Chapter 3 Rooting Your Device
  • Chapter 4 Reviewing Application Security
  • Chapter 5 Understanding Android's Attack Surface
  • Chapter 6 Finding Vulnerabilities with Fuzz Testing
  • Chapter 7 Debugging and Analyzing Vulnerabilities
  • Chapter 8 Exploiting User Space Software
  • Chapter 9 Return Oriented Programming
  • Chapter 10 Hacking and Attacking the Kernel
  • Chapter 11 Attacking the Radio Interface Layer
  • Chapter 12 Exploit Mitigations
  • Chapter 13 Hardware Attacks
Download Android Hacker's Handbook.

3. PENETRATION TESTING: A HANDS-ON INTRODUCTION TO HACKING

This book is an effective practical guide to penetration testing tools and techniques. How to penetrate and hack into systems. This book covers beginner level to highly advanced penetration and hacking techniques.

CONTENTS

  • Chapter 1: Setting Up Your Virtual Lab
  • Chapter 2: Using Kali Linux
  • Chapter 3: Programming
  • Chapter 4: Using the Metasploit Framework
  • Chapter 5: Information Gathering
  • Chapter 6: Finding Vulnerabilities
  • Chapter 7: Capturing Traffic
  • Chapter 8: Exploitation
  • Chapter 9: Password Attacks
  • Chapter 10: Client-Side Exploitation
  • Chapter 11: Social Engineering
  • Chapter 12: Bypassing Antivirus Applications
  • Chapter 13: Post Exploitation
  • Chapter 14: Web Application Testing
  • Chapter 15: Wireless Attacks
  • Chapter 16: A Stack-Based Buffer Overflow in Linux
  • Chapter 17: A Stack-Based Buffer Overflow in Windows
  • Chapter 18: Structured Exception Handler Overwrites
  • Chapter 19: Fuzzing, Porting Exploits, and Metasploit Modules
  • Chapter 20: Using the Smartphone Pentesting Framework
Download Penetration Testing: A Hands-On Introduction To Hacking.

4. THE SHELLCODER'S HANDBOOK

This book is about learning shellcode's of the OS and how OS can be exploited. This book is all about discovering and exploiting security holes in devices to take over.
Authors: Chris Anley, John Heasman, Felix "FX" Linder, Gerardo Richarte.

CONTENTS

  • Stack Overflows
  • Shellcode
  • Introduction to Format String Bugs
  • Windows Shellcode
  • Windows Overflows
  • Overcoming Filters
  • Introduction to Solaris Exploitation
  • OS X Shellcode
  • Cisco IOS Exploitation
  • Protection Mechanisms
  • Establishing a Working Environment
  • Fault Injection
  • The Art of Fuzzing
  • Beyond Recognition: A Real Vulnerability versus a Bug
  • Instrumented Investigation: A Manual Approach
  • Tracing for Vulnerabilities
  • Binary Auditing: Hacking Closed Source Software
  • Alternative Payload Strategies
  • Writing Exploits that Work in the Wild
  • Attacking Database Software
  • Unix Kernel Overflows
  • Exploiting Unix Kernel Vulnerabilities
  • Hacking the Windows Kernel
Download The ShellCoder's HandBook.

5. THE HACKER'S HANDBOOK WEB APPLICATION SECURITY FLAWS

This handbook is about finding and exploiting the web applications.
Authors: Dafydd Stuttard, Marcus Pinto.

CONTENTS

  • Chapter 1 Web Application (In)security
  • Chapter 2 Core Defense Mechanisms
  • Chapter 3 Web Application Technologies
  • Chapter 4 Mapping the Application
  • Chapter 5 Bypassing Client-Side Controls
  • Chapter 6 Attacking Authentication
  • Chapter 7 Attacking Session Management
  • Chapter 8 Attacking Access Controls
  • Chapter 9 Attacking Data Stores
  • Chapter 10 Attacking Back-End Components
  • Chapter 11 Attacking Application Logic
  • Chapter 12 Attacking Users: Cross-Site Scripting
  • Chapter 13 Attacking Users: Other Techniques
  • Chapter 14 Automating Customized Attacks
  • Chapter 15 Exploiting Information Disclosure
  • Chapter 16 Attacking Native Compiled Applications
  • Chapter 17 Attacking Application Architecture
  • Chapter 18 Attacking the Application Server
  • Chapter 19 Finding Vulnerabilities in Source Code
  • Chapter 20 A Web Application Hacker's Toolkit
  • Chapter 21 A Web Application Hacker's Methodology
So, these are the top 5 best hacking books on the market. There may be more fascinating books in the future that make take place in the top list. But for now, these are the best hacking books. Read and share your experience with these books.

Read more


Gridcoin - The Bad

In this post we will show why Gridcoin is insecure and probably will never achieve better security. Therefore, we are going to explain two critical implementation vulnerabilities and our experience with the core developer in the process of the responsible disclosure. 
    In our last blog post we described the Gridcoin architecture and the design vulnerability we found and fixed (the good). Now we come to the process of responsibly disclosing our findings and try to fix the two implementation vulnerabilities (the bad).

    Update (15.08.2017):
    After the talk at WOOT'17 serveral other developers of Gridcoin quickly reached out to us and told us that there was a change in responsibility internally in the Gridcoin-Dev team. Thus, we are going to wait for their response and then change this blog post accordingly. So stay tuned :)

    Update (16.08.2017):
    We are currently in touch with the whole dev team of Gridcoin and it seems that they are going to fix the vulnerabilities with the next release.


    TL;DR
    The whole Gridcoin currency is seriously insecure against attacks and should not be trusted anymore; unless some developers are in place, which have a profound background in protocol and application security.

    What is Gridcoin?

    Gridcoin is an altcoin, which is in active development since 2013. It claims to provide a high sustainability, as it has very low energy requirements in comparison to Bitcoin. It rewards users for contributing computation power to scientific projects, published on the BOINC project platform. Although Gridcoin is not as widespread as Bitcoin, its draft is very appealing as it attempts to  eliminate Bitcoin's core problems. It possesses a market capitalization of $13,530,738 as of August the 4th 2017 and its users contributed approximately 5% of the total scientific BOINC work done before October 2016.

    A detailed description of the Gridcoin architecture and technical terms used in this blog post are explained in our last blog post.

    The Issues

    Currently there are 2 implementation vulnerabilities in the source code, and we can mount the following attacks against Gridcoin:
    1. We can steal the block creation reward from many Gridcoin minters
    2. We can efficiently prevent many Gridcoin minters from claiming their block creation reward (DoS attack)
    So why do we not just open up an issue online explaining the problems?

    Because we already fixed a critical design issue in Gridcoin last year and tried to help them to fix the new issues. Unfortunately, they do not seem to have an interest in securing Gridcoin and thus leave us no other choice than fully disclosing the findings.

    In order to explain the vulnerabilities we will take a look at the current Gridcoin source code (version 3.5.9.8).

    WARNING: Due to the high number of source code lines in the source files, it can take a while until your browser shows the right line.

    Stealing the BOINC block reward

    The developer implemented our countermeasures in order to prevent our attack from the last blog post. Unfortunately, they did not look at their implementation from an attacker's perspective. Otherwise, they would have found out that they conduct not check, if the signature over the last block hash really is done over the last block hash. But we come to that in a minute. First lets take a look at the code flow:

    In the figure the called-by-graph can be seen for the function VerifyCPIDSignature.
    1. CheckBlock → DeserializeBoincBlock [Source]
      • Here we deserialize the BOINC data structure from the first transaction
    2. CheckBlock → IsCPIDValidv2 [Source]
      • Then we call a function to verify the CPID used in the block. Due to the massive changes over the last years, there are 3 possible verify functions. We are interested in the last one (VerifyCPIDSignature), for the reason that it is the current verification function.
    3. IsCPIDValidv2 → VerifyCPIDSignature [Source]
    4. VerifyCPIDSignature → CheckMessageSignature [Source, Source]
    In the last function the real signature verification is conducted [Source]. When we closely take a look at the function parameter, we see the message (std::string sMsg)  and the signature (std::string sSig) variables, which are checked. But where does this values come from?


    If we go backwards in the function call graph we see that in VerifyCPIDSignature the sMsg is the string sConcatMessage, which is a concatenation of the sCPID and the sBlockHash.
    We are interested where the sBlockHash value comes from, due to the fact that this one is the only changing value in the signature generation.
    When we go backwards, we see that the value originate from the deserialization of the BOINC structure (MiningCPID& mc) and is the variable mc.lastblockhash [Source, Source]. But wait a second, is this value ever checked whether it contains the real last block hash?

    No, it is not....

    So they just look if the stored values there end up in a valid signature.

    Thus, we just need to wait for one valid block from a researcher and copy the signature, the last block hash value, the CPID and adjust every other dynamic value, like the RAC. Consequently, we are able to claim the reward of other BOINC users. This simple bug allows us again to steal the reward of every Gridcoin researcher, like there was never a countermeasure.

    Lock out Gridcoin researcher
    The following vulnerability allows an attacker under specific circumstances to register a key pair for a CPID, even if the CPID was previously tied to another key pair. Thus, the attacker locks out a legit researcher and prevent him from claiming BOINC reward in his minted blocks.

    Reminder: A beacon is valid for 5 months, afterwards a new beacon must be sent with the same public key and CPID.

    Therefore, we need to take a look at the functions, which process the beacon information. Every time there is a block, which contains beacon information, it is processed the following way (click image for higher resolution):


    In the figure the called-by-graph can be seen for the function GetBeaconPublicKey.
    We now show the source code path:
    • ProcessBlock → CheckBlock [Source]
    • CheckBlock → LoadAdminMessages [Source]
    • LoadAdminMessages → MemorizeMessages [Source]
    • MemorizeMessages → GetBeaconPublicKey [Source]
    In the last function GetBeaconPublicKey there are different paths to process a beacon depending on the public key, the CPID, and the time since both were associated to each other.
    For the following explanation we assume that we have an existing association (bound) between a CPID A and a public key pubK_A for 4 months.
    1. First public key for a CPID received [Source]
      • The initial situation, when pubK_A was sent and bind to CPID  A (4 months ago)
    2. Existing public key for a CPID was sent [Source]
      • The case that pubK_A was resent for a CPID A, before the 5 months are passed by
    3. Other public key for a CPID was sent [Source]
      • The case, if a different public key pubK_B for the CPID A was sent via beacon.
    4. The existing public key for the CPID is expired
      • After 5 months a refresh for the association between A and pubK_A is required.
    When an incoming beacon is processed, a look up is made, if there already exists a public key for the CPID used in the beacon. If yes, it is compared to the public key used in the beacon (case 2 and 3).
    If no public key exists (case 1) the new public key is bound to the CPID.

    If a public key exists, but it was not refreshed directly 12.960.000 seconds (5 months [Source]) after the last beacon advertisement of the public key and CPID, it is handled as no public key would exist [Source].

    Thus, case 1 and 4 are treated identical, if the public key is expired, allowing an attacker to register his public key for an arbitrary CPID with expired public key. In practice this allows an attacker to lock out a Gridcoin user from the minting process of new blocks and further allows the attacker to claim reward for BOINC work he never did.

    There is a countermeasure, which allows a user to delete his last beacon (identified by the CPID) . Therefore, the user sends 1 GRC to a special address (SAuJGrxn724SVmpYNxb8gsi3tDgnFhTES9) from an GRC address associated to this CPID [Source]. We did not look into this mechanism in more detail, because it only can be used to remove our attack beacon, but does not prevent the attack.

    The responsible disclosure process

    As part of our work as researchers we all have had the pleasure to responsible disclose the findings to developer or companies.

    For the reasons that we wanted to give the developer some time to fix the design vulnerabilities, described in the last blog post, we did not issue a ticket at the Gridcoin Github project. Instead we contacted the developer at September the 14th 2016 via email and got a response one day later (2016/09/15). They proposed a variation of our countermeasure and dropped the signature in the advertising beacon, which would result in further security issues. We sent another email (2016/09/15) explained to them, why it is not wise to change our countermeasures and drop the signature in the advertising beacon.
    Unfortunately, we did not receive a response. We tried it again on October the 31th 2016. They again did not respond, but we saw in the source code that they made some promising changes. Due to some other projects we did not look into the code until May 2017. At this point we found the two implementation vulnerabilities. We contacted the developer twice via email (5th and 16th of May 2017) again, but never received a response. Thus, we decided to wait for the WOOT notification to pass by and then fully disclose the findings. We thus have no other choice then to say that:

    The whole Gridcoin cryptocurrency is seriously insecure against attacks and should not be trusted anymore; unless some developers are in place, which have a profound background in protocol and application security.

    Further Reading
    A more detailed description of the Gridcoin architecture, the old design issue and the fix will be presented at WOOT'17. Some days after the conference the paper will be available online.

    More information


    1. Hacking Smart Tv
    2. Elladodelmal
    3. Cosas De Hackers