hacking.art

A short reminder:

1. Decompiling: means the possibility to restore human readable high-level source code. This is possible for example with Java applications.
This results in something like:


public static void main(){
  system.out.println("Hello World");
}

2. Disassembly: means to translate the zeroes and ones executed by the CPU into a little bit more human recognizable form: assembly instructions.
For example it could result in this:


0000000000001149 <main>:
  1149:       f3 0f 1e fa             endbr64
  114d:       55                      push   rbp
  114e:       48 89 e5                mov    rbp,rsp
  1151:       48 8d 3d ac 0e 00 00    lea    rdi,[rip+0xeac]
  1158:       e8 f3 fe ff ff          call   1050 <puts@plt>
  115d:       b8 00 00 00 00          mov    eax,0x0
  1162:       5d                      pop    rbp
  1163:       c3                      ret

GetProfileStringA
IsWindowUnicode
DefDlgProcA
DrawFocusRect
ExcludeUpdateRgn
UnregisterClassA
GetTextExtentPointA
CreateDIBitmap
cZC
password
login to area
EmperorEight
waiting for billboard data
write
send
message board
write
previous
next
TimerEnd
TimerStart
command
open
shell
http
Classes
DefaultIcon
HtmlDefBrowser
Iexplore.exe
Netscape.exe
App Paths
CurrentVersion
Windows
Microsoft
SOFTWARE
the new password has to be different
old
new
change password!
please
only 0 - 9 and A - Z (big)
only  A - Z (big)
only 0 - 9
not accepted, password length = %d, 
h---h.de
defuser
nohost
waiting for 
chatserver 
response
stop 
start 
memo
login
crack control / chat  area %d
NNNN
GGGG
crack:
from:
Empereig.ttf
io.krcf.org
offline
OFFLINE
cshh
area %d           last crack: %s
connective force attack: open way to public
xxxxx
no connection!
check settings in the dialup dialog
connecting (%d/10)
defaultuser
------ AREA CRACKED ------
%02d/%02d/%04d %02d:%02d 
password
an alphanumeric (big letters)
an alpha only (big letters)
a numeric
Password Error
retry with 
NuNicks.txt
CONNECTION FAILED
http://h---h.de/intro.html
Hanging up 
RAS Connection
%02d.%02d.%02d %02d:%02d:%02d 
snm.hgkz.ch
provider
username
phone
already online / via LAN
remember password
dialup
Disconnected
Authenticated
Modem busy!
\hh.ctrl
cfa.info
INFO
NO_LEGAL_INFO
TRUE
\info\index.htm
START_INFO
MAINCLIENT
SUPER
AUTORUN
TESTSHOW
NODIAL
CREATEUID
OFFLINE
TEST
CONNECT
UID
CRACKRIGHT%d
CRACKLEFT%d
REMEMBER_PASS
LAN
HHNICK
HHUSER
PASSWORD
USERNAME_PROVIDER
MAIL
TEL
PROVIDER
FALSE
\hh.info
\cfa
Programs
Programme
xtra
XXXXXXXX
USER %s %s %s :hhCrackUser
NICK %s
PRIVMSG
Welcome
PONG
PING
JOIN #%d
PART #%d
PRIVMSG #%d :%s
QUIT 
HELLO "%s" "%s" "%s" "%s" 
BYE
ALPHANUM
ALPHA
NUM
LOGIN %d %s 
TRY %d %s 
TEXT %d "%s"
PASSWORD %d "%s" "%s" 
SUPER  %s
LOGOUT  
POST  "%s" 
BILLBOARD
ENDTRY
LOAD ERROR
SAVE ERROR
HELP ERROR bad number of arguments
HELP ERROR unknown command
GETPASSWORD ERROR bad area:  
GETPASSWORD ERROR bad number of arguments:  
GETPASSWORD ERROR no arguments
GETPASSWORD ERROR no superuser status
WHO ERROR nick  not known
WHO ERROR bad number of arguments
WHO ERROR no superuser status
NEWS ERROR no arguments
TEXT ERROR no permission
TEXT ERROR bad area
TEXT ERROR bad number of arguments:  
TEXT ERROR no arguments
LOGOUT ERROR not logged in
LOGIN ERROR bad password
LOGIN ERROR invalid password
LOGIN ERROR bad area:  
LOGIN ERROR bad number of arguments:  
LOGIN ERROR no arguments
LOGIN ERROR already logged in
SUPER ERROR bad super user password
SUPER ERROR bad number of arguments
SUPER ERROR no arguments
PASSWORD ERROR Not allowed
PASSWORD ERROR bad password
PASSWORD ERROR already changed by 
PASSWORD ERROR same password
PASSWORD ERROR Invalid password
PASSWORD ERROR Not logged in
PASSWORD ERROR bad area
PASSWORD ERROR bad number of arguments: 
PASSWORD ERROR no arguments
HELLO ERROR nickname  exists
HELLO ERROR bad number of arguments 
HELLO ERROR registered already
HELLO ERROR no arguments
ERROR command not understood
ERROR internal error; report to administrator
ERROR Please log in first
LOAD OK
SAVE OK
NEWTEXT  
CRACKED  
HELP OK
GETPASSWORD OK 
WHO OK 
NEWS OK
TEXT OK 
LOGOUT OK
LOGIN OK cracked
SUPER OK super user status
PASSWORD OK set password
QUIT OK
BYE OK
EXIT OK
HELLO OK           
000 Crack Server at  (V [experimental]) ready.
Unknown Error
PING
Courier New
format = 3
format = 2
format = 1
send
offset = %d, del = %d
lastlog.txt
MOXX
nickname
GROON
User
please enter nickname
first character of nickname must be alphabetic
login 
Connected
PasswordExpired
RetryAuthentication
CallbackSetByCaller
Interactive/PAUSED
SubEntryDisconnected
SubEntryConnected
Projected
WaitForCallback
WaitForModemReset
PrepareForCallback
ReAuthenticate
AuthAck
AuthLinkSpeed
AuthProject
AuthChangePassword
AuthCallback
AuthRetry
AuthNotify
Authenticate
AllDevicesConnected
DeviceConnected
ConnectDevice
PortOpened
OpenPort
RasGetErrorStringA
RasHangUpA
RasDialA
RasGetEntryDialParamsA
RasEnumConnectionsA
RasGetConnectStatusA
RasEnumEntriesA

The program communicates via network
A series of "passwords" are tested
There is a "crack server" to which the passwords are sent
It needs some kind of protocol for communication with the crack server
There is a chat with other participants
If a password is correct, an messagebox gets available to post text
and so on...

This in mind, it is interesting how some words in the Strings output appear to be like commands or code fragments.

LOGIN, GETPASSWORD, PING, etc.

These strings suggest that it is some kind of protocol wich is used for communication by cfa and it's server counterpart.

So, maybe it is possible to provide our own server which sends commands to the cfa and interact with it.

This would be an important step to bring the cfa back to live.

In the following, we will therefore focus on learning as much as possible about the protocol.

More questions are: at wich particular points input is processed?
What input does the program expect?
Can we write a simple server substitute poc to interact with the program?

To answer these questions we have to bring our analysis to the next level. Let's take a look what the cfa.exe tries to send and receive while running.

Dynamic analysis means running the program and observing it's behaviour and interactions. For example, whether the program tries to read or write files from the system.

Another important behaviour is the connection establishment in the network. Does the programm connect to a specific host oder URL in the internet? If so, which protocols are used? Is it calling a website or is it connecting to a FTP server for example.

Besides the raw data that is sent through the observed interfaces and over the wire, we can also learn about the program itself and it's functionality. That said is it very interesting which functions are not (yet) reachable, maybe because more informations are needed to understand how to get to a specific path.

A simplified setup could look like this:

Basically there is a Windows system running the cfa.exe and some other systems in the network to interact with. The analysis tools are installed on Windows. The following programs are used:

Wireshark
Procmon
x32dbg (more about this later)

More tools could for example be:

Regshot (compare Registry before and after the start of a program)
Process Explorer (Running Process relationships)

But they propably wouldn't add much value here and therefore weren't used.

The already shown systems in the network are somewhat preempted at this point. To find out what network connections are needed, we should first run the cfa and observe it's connection attempts.

The shown setup could be quickly and easy implemented with a virtualization technology like VirtualBox.

Now it is almost time for a first test run of cfa.exe.

To directly have some info to analyse we let Procmon run in the background. Process Monitor is an advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity.

When starting Procmon it shows a lot of processes. We can let it run a few seconds and then stop the capture. All the captured processes have nothing to do with cfa.exe, because we didn't even start it yet. These are all some windows stuff. With rightcklick we can choose and exclude all processes we don't want to see.

At second we use Wireshark to capture network traffic. Also Wireshark displays some noise traffic we are not interested in because Windows always does some surveillance shit in the background. But we can filter this traffic out later on.

Finally when Wireshark and Procmon are ready we start the cfa.exe.

Trying to connect to a not existing or reachable server the cfa gets stuck in a loop.

In Wireshark we can use the "dns" filter (just type dns in the filter) and see that it tries to connect to io.krcf.org which is resolved to 183.181.86.71.

If we call this IP or domain directly in the browser, it's responding with a short text saying that this URL is invalid - in japanese (according to google translate).

Doesn't look like io.krcf.org or the resolved IP still belongs to Knowbotic Research.

Nevertheless this is an important hint for us, because now we can redirect the dns to our own server.

Another puzzle piece to find in Wireshark is an attampt to connect to port 6666.

But let's first also take a look at the system interactions captured by Procmon.

Again, some by-catch has to be excluded, then it can be analyzed what exactly cfa.exe did. A lot is happening with the Windows Registry but also some interaction with the filesystem. For example the program tries to open a file named "hh.ctrl" and a file named "hh.info".

The "hh.info" file can be found at "C:\Users\yawe\AppData\Local\VirtualStore\Program Files\cfa\" and include some configurations shown in the following:

If we want to exploit bugs in the program this may be an insertion point. But let's for now focus again on the networking aspects.

Similar to Linux there is a "hosts" file on Windows. Domain names and corresponding IP adresses can be manually written into this file. Before the system performs a DNS lookup it checks if there are entries in the "hosts" file. If it finds a to-be-lookuped name in there, it will take the IP address from the file and connect to it, instead to the "real" one from a DNS server in the internet.

On Windows the file can be found here: C:\Windows\System32\drivers\etc\hosts.txt

To open it admin privileges are required.

Now we can add IPs from our local network and let the needed domains point to them.

HINT: The following second host can also be found with Wireshark after the server at "io.krcf.org" is already reachable (meaning a port is open/netcat listener running at 6666). It then tries to reach "h---h.de" at port 6667.

The content of our "hosts" file now should look like the following. Both domain names point to a VM with the IP 192.168.0.130 in our local network.

At the server at wich the traffic should be received, we start a simple netcat listener for a quick first test. The needed ports are 6666 and 6667.

With this setup we start the cfa one more time. If we are fortunate the program already reacts different when we send back some data after receiving the connection.

Indeed! We enter the interface of the cfa with four windows. There we can click and open the chat window. Let's just write something in a few places.

Data is received at our server. Part of it are the strings written in the cfa, others are part of the protocol. What that means we hopfully will find out soon.

In the cfa interface nevertheless all windows showing the word "offline". Just to listen on a port is seems not to be sufficient. The cfa needs a valid answer to it's requests.

Also at port 6667 some data was received and we can see the protocol strings sent.

NICK, USER, PART, QUIT

Searching these strings in our favourite online search engine, reveals that this is almost certainly part of an IRC chat.

At https://datatracker.ietf.org/doc/html/rfc1459 it is easy to search for "Command: " using the full text search (Ctrl-f), which quickly reveals the possible IRC commands. Compared to the received strings from cfa some intersections become visible.

This means we already know about one protocol the cfa uses. The program implements the IRC protocol at least patially and it should be possible to chat with others this way.

Knowing this we can install our own IRC server an try to chat with the cfa.

One of the first search results to setup up IRC was this: https://ubuntu.com/tutorials/irc-server#1-overview. There is no particular reason why I chose this manual, you could use any other.

Installing inspircd we have to make a few configuration changes which are documented here

And after a little bit of trial and error (for example the servers hostname has to be "h---h.de") we can actually chat with the cfa. The following is a quick proof of concept:

There is another interaction that can be found in the cfa. With a click on the X in the bottom right corner, the cfa opens a web browser and tries to load the manual webpage. This is the request it sent:

We can also redirect this to our own webserver as mentioned before and host intro.html to display our own page into the cfa. Unfortunately it looks like the cfa is using the system browser for this. Meaning it is propably not easily exploitable (like webstalker).

Now the main thing that is still missing is the so-called "crack server", which seems to be able to unlock most of the functionality in the cfa.

Communication already works via the IRC server. However, we haven't gotten far with decrypting the other protocol for the crack server. So let's start writing a simple Python script that listens on the port and responds with some test data. With a little trick we can work on a part of the server without having to stop and restart it all the time. For this we can simply include a file as a library (File 2: myfuzz.py), in which we define different responses to test manually.

Don't take this PoC code too serious please... :)

So far all analysis techniques are like looking at something from the outside. During the advanced analysis we will cut open the application as in an autopsy. This will give us a deeper understanding of the programs inner workings.

This type of reverse engineering requires very specialized knowledge. With little prior knowledge, it is not easy to decipher the codes. But with a little patience it is possible. And especially by constantly reading everything that you do not understand again and again. That's why I wrote a little x86 Cheat sheet, for example, where I can quickly look up the basics.

In the end, it is absolutely not necessary to understand every single instruction. The goal is mainly to understand the connections and structures and to get a general impression of the functionalities and possibilities.

The tools that can be used for this are for example:

Some may prefer to use IDA Pro, but that's too expensive for me.

One of the most important things about this type of reverse engineering is to understand the functions involved. The problem here is that the original names of the functions have unfortunately not survived. With meaningful function names, the whole thing would be much easier. Because then you would already know what it is about when you look at the assembler code and can make assumptions more easily. But unfortunately we are not so lucky here. Anyway.

The functions that Binary Ninja recognizes are all named after the memory address where they start.

Aaaaalright.

We will use the "x32dbg" debugger, which is the 32 bit version of x64dbg.

During the static analysis of the assembler code we could already gain a little insight into internal functions of the cfa. We have discovered a few potentially interesting functions and noted their memory addresses. Now we can set breakpoints at these addresses in the debugger and see what the program does at runtime.

Keep the following in mind:

eax is the return value of a function
parameters of a function are pushed to the stack before the call (possibly also into EDX & EDX)
---> Binary Ninja shows which calling convention is used
---> for example __stdcall or __fastcall

The goal is to understand what input data is processed and how.

Which branches are executed in the program flow?

What data is needed to change the program flow?

The first thing we want to look at in more detail is why is the crack is server shown as "offline" even when we have a simple Python server running. The cfa apparently needs a valid response.

To find out more about this, we can start looking at which functions it probably makes the most sense to set a breakpoint. Maybe the following functions could give us more clues:

00408f30 connect crackserver @ io.krfc.org
0040a0b0 load area
0040b290 log in at Crack Server
0040b740 connect and interact with CrackServer

And now follows a short manual for: RUNNING CODE FROM YEAR 2000!!!

It's been 22 years since the code was written. On a modern system it is an eternal fiddling, maybe even a completely hopeless project to get the code to work. Perhaps it could even be completely rewritten faster.

So what to do?

God, bless Linux!

1. Donwload ancient Debian ISO
2. Install it (as VM)
3. Add archive sources:
deb http://archive.debian.org/debian/ sarge main non-free contrib
deb-src http://archive.debian.org/debian/ sarge main non-free contrib
4. install python:
apt-get update
apt-get install python
5. Make two minor adjustments in the server code:
start.py line 38: IP_ADDRESS = '192.168.0.31'
start.py line 204: # comment out this line os.setegid (gid)
6. run it
python start.py

Knowbotic Research

Connective Force Attack

Simple Static

Simple Dynamic

First Server PoC

Advanced Static

Advanced Dynamic

CRACKSERVERHH