Avr 242019
 

How to rebuild libvmdk (and possibly any VC project) so that it depends on msvcrt.dll and no longer on msvcrtxxx.dll.

Copy/paste from this post for archiving.

-first install VC2008 express (but should be OK with VC2010 express and possibly newer VS platforms)

-install WDK 7.1

-modify your VC2008 IDE settings search paths (include and libraries) by adding WDK 7.1 paths first in the list

XuK0hGN.png

seLkgHG.png

-add msvcrt « legacy translator » library (msvcrt_win2000.obj) to Linker -> Input -> Additional Dependencies for both DLL projects (zlib and libvmdk)

ExRxofS.png

-add specific preprocessor definitions to zlib project :

vsnprintf=_vsnprintf;snwprintf=_snwprintf;open=_open;read=_read;close=_close;write=_write

neDR5uv.png?1

And voila :)

You should end up with the below, i.e a dependency to a msvcrt.dll

lcahBQh.png

Fév 222019
 

Still playing with Windivert (see original article here), this time we will intercept inbound dns traffic and will modify the IP address in DNS replies containing A records.

The program will dynamically look for hostname to ip couples in a config.ini file.

Say that you want labalec.fr to resolve to 192.168.1.144, then you would create the below ini file and launch intercept-dns 53.


[labalec.fr]
ip=192.168.1.144

Additionally, if you set a dos environement variable like set layer=forward, then you can also use this program in a man-in-the-middle attack (which could lead to another article) to divert forwarded traffic.

The source and binary is available on my github.

The code still has some limitations :
-non existing dns a records replies are not handled
-only replies with one answer are handled

Fév 182019
 

Last article of a series of 4 articles.

This time, we will push it a bit further on the certificate side (using SAN field) as modern browsers like Chrome demand this field :

-divert dns traffic to a rogue local dns server : see here

-spoof a remote hostname with our local ip (using tool in step above) – these 2 steps could be skipped if you modify your local hosts file.

-setup a https server locally with a « self signed » certificate (see below)

First our root ca (dont forget to add in your ca store):
openssl genrsa -out rootCA.key 2048
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem

Lets add it to our root certificate authorities : certutil -enterprise -f -v -addstore « root » rootCA.pem

Second our CSR:
modify our openssl.cnf accordingly : add subjectAltName=DNS:fakedomain.com,DNS:*.fakedomain.com under section v3_req
set the path to your your cnf file with set OPENSSL_CONF=c:\_apps\OpenSSL\ssl\openssl.cnf
generate your csr
openssl genrsa -out device.key 2048
openssl req -new -key device.key -out fakedomain.csr

About the CN, enter « fakedomain.com »

Last, our CRT (the trick is is to point at your cnf or else the SAN field will not be taken care of)
openssl x509 -req -in fakedomain.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out fakedomain.crt -days 500 -sha256 -extfile c:\_apps\openssl\ssl\openssl.cnf

And tada, launch your chrome browser and browse https://www.fakedomain.com/ and chrome will be happy.

Fév 172019
 

Previously we have built a HTTP server.
This time, lets build a HTTPS server.

The main difference compared to previous article is that this time, we need an object of type TIdServerIOHandlerSSLOpenSSL to provide certificates details and to handle the ssl part (client hello, server hello, etc).

Main code below.


IdServerIOHandlerSSLOpenSSL1.SSLOptions.CertFile := 'device.crt';
IdServerIOHandlerSSLOpenSSL1.SSLOptions.KeyFile := 'device.key';
//IdServerIOHandlerSSLOpenSSL1.SSLOptions.RootCertFile := 'rootca.pem'; //optional since cert is signed with rootca is added to local ca authorities
IdServerIOHandlerSSLOpenSSL1.SSLOptions.Mode := sslmServer;
IdServerIOHandlerSSLOpenSSL1.SSLOptions.VerifyMode := [];
IdServerIOHandlerSSLOpenSSL1.SSLOptions.VerifyDepth := 0;
if rbtlsv12.Checked then IdServerIOHandlerSSLOpenSSL1.SSLOptions.SSLVersions := [sslvTLSv1_2];
if rbtlsv11.Checked then IdServerIOHandlerSSLOpenSSL1.SSLOptions.SSLVersions := [sslvTLSv1_1];
if rbtlsv10.Checked then IdServerIOHandlerSSLOpenSSL1.SSLOptions.SSLVersions := [sslvTLSv1];
if rbsslv3.Checked then IdServerIOHandlerSSLOpenSSL1.SSLOptions.SSLVersions := [sslvSSLv3 ];
IdServerIOHandlerSSLOpenSSL1.OnGetPassword := GetPassword; //not needed if we dont have a password on our cert

IdTCPServer1.DefaultPort := SERVER_PORT;
IdTCPServer1.IOHandler := IdServerIOHandlerSSLOpenSSL1;
IdTCPServer1.OnConnect := ServerConnect;
IdTCPServer1.OnExecute := ServerExecute;
IdTCPServer1.Active := True;

memResults.Lines.Add ('start');

Code is on github.

About the certificate part:
-generate the root ca (and add it to your client root ca’s)
openssl genrsa -out rootCA.key 2048
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem

-generate a csr (only the CN field matters and must match your local site – example : localhost or 127.0.0.1).
openssl genrsa -out device.key 2048
openssl req -new -key device.key -out device.csr

-use the root ca to generate a client cert from a csr
openssl x509 -req -in device.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out device.crt -days 500 -sha256

Fév 172019
 

In a previous article, we had built a transparent proxy for tcp (outbound) connections.

In short any tcp outbound connection on port_x would be redirected to ip:port_z.

Main usage was to implement a transparent proxy for http traffic (applications would « transparently » be redirected to a proxy accepting « intercepted » traffic).

This time, lets do the same for (outbound) UDP.

One possible scenario : intercept all outbound dns traffic and redirect to another dns server.

Syntax:

proxy-tcp 1.0 by erwan2212@gmail.com
proxy-tcp original_port new_port new_ip [local]
remember that if you divert to a local app, this local app could be diverted as well.

Example : proxy-udp 53 53 192.168.1.144 local
With a rogue dns server running locally (skip the ‘local’ if the rogue server is running on another host).

Note the warning about diverting to a local app.
For instance, you could be running your local rogue server locally but then since this rogue server will also perform dns queries, you would end up in catch 22 situation.
Possible workarounds :
-have your rogue server « escape » the filter and use a remote udp port different than the filtered one (i.e something different than 53) OR a different protocol (i.e something different than UDP)
-review the code and filter on the original dns server
-review the code and exclude the dns server used by the rogue server

Source code and binaries can be found on my github.

Déc 282018
 

Since windows XP, windows has a built-in host-based firewall.
A decent firewall where one can allow or block traffic based on executable and/or source/destination/protocol.

Thus, you may not always have access to the MMC (wf.msc) and the console GUI is not always straightforward but rather wizard oriented.

Windows Firewall GUI is a « one window does it all » standalone executable running on windows 7 up to latest windows 10 version.

Probably more important, as the GUI is quite simple and possibly redundant with existing windows functionalities, source code is available (on my github) as well so others may build onto it.

One can :
-view all rules at once
-sort and export to HTML
-delete a rule
-add a rule
-enable/disable a rule
-enable/disable the firewall
-turn on/off logging (dropped packets)
-open and monitor the windows firewall log
-get current profile (domain/private/public)
-get default inbound/outbound action for current profile
-restore local windows firewall defaults

Download here.

Déc 162018
 

In a previous article, I showed how to setup a « proxy » for ImDisk thru devio to mount an EWF file.

This time, lets do it with a VHDI file (using external libyal library).

The command lines for the proxy and ImDisk are below :

To launch the proxy : devio –dll=proxy.dll;dllopen shm:test_proxy c:\test.vhd.

To use the proxy from ImDisk : imdisk -a -t proxy -o shm -o ro -f test_proxy -m Z: .

proxy_VHDI

Nov 022018
 

See previous article to understand why and what.

Previously we have created our differencing / child disks.

Lets first set our iscsi target with Starwind San Free by creating two targets and attaching one disk in each target.





Then lets boot our diskless computers over the network with TinyPXE Server.

We will use the below ipxe scripts (one for each network booting computer).
Replace ‘X’ below with the target number (1 or 2) on line 3 and 5.

#!ipxe
clear net0.dhcp/gateway:ipv4
set initiator-iqn iqn.2006-11.X
set keep-san 1
sanboot --keep iscsi:${next-server}:tcp:3260:0:iqn.2008-08.com.starwindsoftware:erwan-pc2-childX

And here we go, we have X diskless computers booted over the network using differencing disks on the iscsi target.

 Posted by at 19 h 23 min