Tuesday, 29 January 2019


I completed a Bachelor of Engineering with Honours specialising in Telecommunications and Digital Systems between 1995 - 1999.
I worked as a Design and then Senior Engineer in Network Development and Optimisation for OnAir Networks and then later in Terminal Interworking within Cellular Engineering. I loved it.
After 9 months of maternity leave I tendered my resignation to care for my 3 children that I opted to have within 3.5 years to ensure I wasn't too long out of work.
I completed a Masters in Computer Networking, multiple Cisco certifications and a couple of security certifications.
I've worked as a Network & Security specialist from 2009 until current.
I am currently working as the Director of a highly technical section.
This is my history and here is what I've learnt from spending the last 0x001A years as a minority in my career.

  • My view of women in STEM events has evolved throughout my career. I've had times I hated them. Times I thought they achieved nothing and were a waste of time. I still see my former thoughts echo'd back in other tech women that just want to do their jobs. Today - they are not everything, but they raise awareness that there is a lack of women in tech roles and if only one more female is enabled from an event, then they are worth it. 
  • When you meet another woman in tech, it can sometimes feel awkward. I'm so used to working with men that when I get to work with a female, I'm not so sure how to act. Some women love having an ally others will see you as competition. And some people will compare the only two women on the team, with comments like "Jenny is more technical than Sally". Don't compete with other women. We have enough to deal with.
  • When you start a new role, its harder to get credibility than a male. Not getting good projects, not being given full TACACS access, questioned on new engagements - it happens. As a female, its easier not to move around as much. Because once you've proven yourself and its understood you know your job very well - its easier to stay where you are. But don't. Put yourself out there - believe in yourself. 
  • You will be mansplained to - multiple times. It's frustrating when that tech director painfully explains how to use ls on a linux system. This isn't a reflection on you, this is a reflection on them. This is their embarrassment not yours. Don't take this responsibility on, its not yours. Move on and ignore them.
  • There is an expectation that because you are female that you have better social skills, higher emotional intelligence and can represent and lead other generations. This is sexist. I had someone tell me that as a female I had a duty to behave better, kinder and nicer than everyone else. I don't. I'm shy, I'm introvert and I don't owe any more to the community than any other person doing their job in tech.
  • Take credit for your work. For many years I would allow other people to take credit for my work. When my name was forgotten in the credits, I would dismiss it and say it was okay. It's not okay. Don't be modest and accepting - women have the right to be as proud of their work as men do. If they say, "Sorry we forgot to give you credit", don't say its okay - tell them to correct the situation and do the right thing. Women are adverse to boastfulness. Don't be afraid of being proud of your work.
  • Remember why you're doing it. You will have bad days. You will be undermined and minimised. You will be talked over and mansplained. You will be dismissed as attending the "partners program" at tech conferences - the partners program being for wives and girlfriends of attendees. Forget all that and remember why you are here. When this happens, I put on my headphones, I sit at my computer and I lose myself in my tech. Because no matter what people say or think - this is my job, this is what I love doing and this is what I will continue doing.
Now get out there and do your tech jobs ladies!!

Sunday, 27 January 2019

RFC: Hacker Roadtrip -draft only

This is a schedule detailing a camping roadtrip from Canberra to TuskCon in May 2019 and is currently open for comments and feedback and may change.

The schedule is open to anyone that wants to join for all or part of the journey (at your own cost, with your own equipment)

Wednesday 8th May 2019

Meet at InfoSect at 9am - Unit 2, 9 Beaconsfield Street Fyshwick ACT 2609
Ready to drive

Drive 6 hours 35 mins

Arrive at Crowdy Gap campground and spend the night

Thursday 9th May 2019

Meet at Crowdy Gap campground 10am - ready to drive

Drive 5 hours 22 mins

Arrive at Wooyung Beach campground and spend the night

Friday  10th May 2019

Meet at Wooyung Beach campground 10am - ready to drive

Drive 2 hours 43 mins

Arrive at Cotton Tree Holiday Park and spend 3 nights there for TuskCon

Monday 13th May 2019

Meet at Cotton Tree Holiday Part at 10am - ready to drive

Drive 2 hours 43 mins

Arrive at Wooyung Beach campground and spend the night

Tuesday 14th May 2019

Meet at Wooyung Beach campgroud at 10am - ready to drive

Drive 5 hrs 22 mins

Arrive at Crowdy Gap campground and spend the night

Wednesday 15th May 2019

Meet at Crowdy Gap campground at 10am - ready to drive

Drive home

Sunday, 24 June 2018

OzSecCon 2018

On 2-3rd of June 2018 I attended OzSecCon in Melbourne. I'm not really a locksport enthusiast by any stretch of the imagination, I'm happy to fiddle with a lock and pick during social night - but I don't go out of my way to find the locksport village at a conference. However - the atmosphere at OzSecon was overall amazing. Notwithstanding, it is hosted by Topy - the Australian who has lugged his locksport stores up, down, east and west across Australia, at his own personal expense, hosting the locksport villages at AusCert, Ruxcon, PlatypusCon, BSides Canberra and probably many more I'm forgetting. He is the drive behind growing Locksport in Australia - so if you are remotely into Locksport, OzSecCon is where you should be.

I've done a brief writeup of the talks and workshops I attended below.


‘Keynote: Red Teaming’, by Jek Hyde

Jek works on Walmart Red team. She made it clear that her position on the red team is to achieve physical access - not work on computers. She referred to herself as a “Professional burglar”. She discussed secure facilities syndrome - in which facilities tend to be very hard to get into but once in, is all soft and squishy on the inside due to wanting to promote a good culture. She did a walkthrough of a pentest she did in Canada. Started with dumpster diving. Found out about meeting, made a fake pass, wore fake pregnant belly, used a Bose cloner to clone a pass and got in.
Installed keyloggers, Dropbox, rubby ducky & listening devices. Heard a lady going out for lunch and used her office to gain access to systems. Key takeaway point was that physical and logical are treated separately when they affect each other so much and should be looked at together.

‘Manipulation aids in opening safe locks’, by Jaakko Fagerlund

 Jaakko is from Finland and is a machinist by trade and loves breaking all things mechanical.
Discussed through the techniques of cracking dial combination safes. The wheels within the dial can be different shapes and graphing (turning the wheel through each number). Right contact point (sloped) is the one that is most useful to measure. Showed graphs on the non-roundness of wheels - 0.5mm deviation at some points. Exploits are based on dialing tolerances, cheap electronics, reading wheels in the order W3, W2, W1.
Advanced exploits use electronics to graph the wheel pack, ultimate way is a manipulation robot (autodialler with a microphone - softdrill)


‘Cognitive biases and how to be less wrong’, by Alex Hogue

Alex discussed base rate rejection. He explained that people are more likely to look at the evidence without looking at the base rate. Eg. creaks in a plane == evidence of impeding crash despite base rate of crashes being low
He also discussed confirmation bias. Eg. Verifying your hypothesis only with tests that will result in positive confirmation. This can be beaten by using null hypothesis - proving yourself wrong.
Availability Heuristic - if there are more examples in public media, then people assume it is more common eg. Ransomware. Leads to “after a disaster we prepare more”
Others: scarcity bias, loss aversion, sunk-cost fallacy, the halo effect, outcome bias, inattentional blindless, bias bias, cognitive dissidence creates more bias.
Alex concluded with a very entertaining slight of hand routine done to a volunteer from the audience.

‘Tamper resistance bypasses’, by Connor and Emily Morrison

Covered different types of tamper evident seals with some recorded demos of removing them









‘How to disappear completely’, by Attacus

Atticus provided an overview of “Senseface” - which is a product that detects faces. She showed an admin interface of a Westfield Info booth that records faces estimating gender and age for advertising purchases. Atticus discussed Detection vs Recognition. Detection is allowed without consent because it doesn’t relate to personal or sensitive information. She spoke about the Identity-matching Services Bill 2018 - the Capability will be provided to Home Affairs for national security, identity safety etc. She noted that the Attorney-General's department is in discussion about selling facial records to private companies.
Second part of talk moved to techniques of avoid facial recognition. Talked about how facial recognition worked and old school mitigation techniques include, wearing a balaclava, wearing sunglasses or pulling weird faces to avoid facial recognition.
cvdazzle.com - Adam Harvey, ahprojects.com provides solutions to avoiding facial recognition.

‘Back in time: Finnish lock industry’, by Thomas Covenant

Thomas covered off the history of locks in Finland, which is a leading region of lock production because of the rockiness of the country.
Karelian locks (a region ceded to the Soviet Union from Finland) date back to medieval Finland.
She talked through wooden locks, development of metal and ornamental locks and the spiritual beliefs around locks keeping people safe.
1920s industrialisation heralded Abloy locks in Finland. Designed by Finnish man who repaired a cash till, and saw the rotating disks. 1918 patent registered, sold in 1919 for 34 euros


‘The ALC Galaxy Lock: an in-depth look’, by Adam Foster

Adam talked about how he bought and disassembled a galaxy lock, released by the Australian Lock Company (ALC). He discussed how it worked and possible ways to attack it. He stated that he had managed to pick it but he hadn't recorded it and couldn’t replicate.

‘Challenge locks’, by nullwolf

Nullwolf started off explaining reasons why you would build challenge locks - Reddit lock-picking awards profile flair for building challenge locks. He covered off on the rules for building a challenge lock eg. At least 6 modifications, working key
Covered shopping list required.
Using a dremel to do pin sculpting



Impressioning Workshop

I attempted the impressioning workshop... twice! I was terrible at it. But I learnt a lot about the technique and skill involved to impression a key.








Milling your own cutaway lock 

This is when I realised the value of OzSecCon being run at Melbourne Polytech. Access to all the machining tools allowed a live demo of creating cut away locks (plus many more machining demos that I missed). @anarchy_won did the demo and was patient and willing to answer any questions we had on mill types, techniques and other hints. It was fantastic seeing his passion and knowledge.

As well as the talks and workshops, OzSecCon had an inclusive and welcoming environment. I was greeted with friendliness and helpfulness the whole conference. I attended the female lunch and the Friday night party - both were really enjoyable. The party was catered with Turkish and a neverending bartab!

Overall, I've heard the locksport community likened to what the computer hacker community was 20 years ago. A little edgy and considered borderline inappropriate. However, like the trailblazers that made computer hacking mainstream, OzSecCon is breaking down barriers and making this important topic visible and accessible to everyone. Well done Topy & the OzSecCon Crew!!

Tuesday, 12 June 2018

Kernel Hacking to achieve custom FC frames - incomplete

This post covers the incomplete work I did on trying to modify FC drivers to send custom FC frames. I hope someone can pick it up and use it because I don't think I have time to finish it.


To determine what symbols have been exported by the kernel, run:


library functions -> run in user space
system calls -> run in kernel mode

Connecting to the SAN:

[425303.444353] lpfc 0000:07:00.0: 0:1303 Link Up Event x1 received Data: x1 xf7 x10 x0 x0 x0 0
[425305.532359] scsi 6:0:0:1: Direct-Access     LIO-ORG  storage1         4.0  PQ: 0 ANSI: 5
[425305.532945] sd 6:0:0:1: Attached scsi generic sg1 type 0
[425305.534874] sd 6:0:0:1: [sdb] 1048576000 512-byte logical blocks: (537 GB/500 GiB)
[425305.534878] sd 6:0:0:1: [sdb] 4096-byte physical blocks
[425305.535976] sd 6:0:0:1: [sdb] Write Protect is off
[425305.535981] sd 6:0:0:1: [sdb] Mode Sense: 43 00 10 08
[425305.536109] sd 6:0:0:1: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
[425305.605769]  sdb: sdb1
[425305.606899] sd 6:0:0:1: [sdb] Attached SCSI disk
[root@localhost new-modules]# ls -la /dev/sdb*
brw-rw----. 1 root disk 8, 16 May 12 16:10 /dev/sdb

brw-rw----. 1 root disk 8, 17 May 12 16:10 /dev/sdb1

From within: /usr/src/linux/Documentation/devices.txt
  8 block       SCSI disk devices (0-15)
                  0 = /dev/sda          First SCSI disk whole disk
                 16 = /dev/sdb          Second SCSI disk whole disk
                 32 = /dev/sdc          Third SCSI disk whole disk
                240 = /dev/sdp          Sixteenth SCSI disk whole disk

                Partitions are handled in the same way as for IDE
                disks (see major number 3) except that the limit on

                partitions is 15.

Finding the Link Up Event within the driver:

[root@localhost lpfc]# grep "Link Up Event" *
lpfc_hbadisc.c:                                 "1303 Link Up Event x%x received  

Function that brings the link up:
lpfc_mbx_cmpl_read_topology(struct lpfc_hba *phba, LPFC_MBOXQ_t *pmb)
        struct lpfc_vport *vport = pmb->vport;
        struct Scsi_Host  *shost = lpfc_shost_from_vport(vport);
        struct lpfc_mbx_read_top *la;
        MAILBOX_t *mb = &pmb->u.mb;
        struct lpfc_dmabuf *mp = (struct lpfc_dmabuf *) (pmb->context1);
                        lpfc_printf_log(phba, KERN_ERR, LOG_LINK_EVENT,
                                        "1303 Link Up Event x%x received "
                                        "Data: x%x x%x x%x x%x x%x x%x %d\n",
                                        la->eventTag, phba->fc_eventTag,
                                        bf_get(lpfc_mbx_read_top_link_spd, la),
                                        bf_get(lpfc_mbx_read_top_mm, la),
                                        bf_get(lpfc_mbx_read_top_fa, la),

Looking for file operations in the driver:

[root@localhost lpfc]# grep fops *

lpfc_init.c:    .fops = &lpfc_mgmt_fop,

vi lpfc_init.c
static const struct file_operations lpfc_mgmt_fop = {
        .owner = THIS_MODULE,

static struct miscdevice lpfc_mgmt_dev = {
        .minor = MISC_DYNAMIC_MINOR,
        .name = "lpfcmgmt",
        .fops = &lpfc_mgmt_fop,

[root@localhost lpfc]# cat /proc/kallsyms | grep lpfc_mgmt_fop

ffffffffa0162c60 r lpfc_mgmt_fop        [lpfc]

Setting up kernel source to modify drivers:

[kylie@localhost ~]$ uname -r

[kylie@localhost ~]$ koji download-build --arch=src kernel-4.4.8-300.fc23.x86_64
kernel-4.4.8-300.fc23.src.rpm                                                              | 168 MB  00:02:26 !!!

[kylie@localhost ~]$ ls
kernel  kernel-4.4.8-300.fc23.src.rpm  rpmbuild

[kylie@localhost ~]$ su -c 'dnf builddep kernel-4.4.8-300.fc23.src.rpm'



Different tact - using fcoe

1. Using fcoe tools to setup a ethernet interface with DCB to enable fcoe:

This example configures interface eth3 to automatically connect to storage over a discovered VLAN.

1) Configure FCoE on the interface
     # cd /etc/fcoe/
     # cp cfg-ethx cfg-eth3

2) Start lldpad and configure the interface for DCB.
    # service lldpad start
    # dcbtool sc eth3 dcb on
    # dcbtool sc eth3 pfc e:1
    # dcbtool sc eth3 app:fcoe e:1

As a convenience there is a script that will confirm if DCB has been configured correctly for FCoE. The script is run as follows,

    <fcoe-utils source>/debug/dcbcheck.sh eth3
    (note: this is on the root device, not the VLAN)

Follow the suggestions and repeatedly run the script until it states that DCB is configured correctly.

3) Start fcoe
    # service fcoe start
      After a few moments your storage should appear (assuming everything is
      configured correctly on the fabric)

4) Setup lldpad and fcoe to start when booting
     # chkconfig lldpad on
     # chkconfig fcoe on

2. Connect port to an FCoE switch set to span another port

need to source an FCoE switch... maybe on in datacentre? :/

3. Record the traffic

Use scapy to record a pcap - or record via wireshark

4. Replay traffic

Use scapy to replay traffic on the FCoE enable ethernet interface

5. Make changes to FC frames

Monday, 28 May 2018

BGP route injection - extending VIRL externally

This simulation a demonstration of route injection in a BGP network with 6 AS' - which I demonstrated at CrikeyCon 2018. However, at that time I hadn't been able to extend outside of the VIRL environment so had to browse via wget commands on the server CLI.

Today I had the time to configure my VIRL instance to extend to outside the environment to external devices (in this case a Windows VM).

In retrospect, this wasn't very difficult. But there is very little clear documentation on how to do this. The steps to achieve this were.

1. Configure the flat network under the VIRL Web GUI. Here we specify the IP address range of the external network and the interface on the VIRL VM/machine that we want to link to the external connection. Note down the flat network address.

3. On the VIRL CLI we now find the bridged interface that has been allocated the flat IP Address

 virl@virl:~$ ifconfig
br1       Link encap:Ethernet  HWaddr 00:0c:29:37:1c:0e
          inet addr:  Bcast:  Mask:

4. Then make sure eth1 has been associated to the appropriate bridge

virl@virl:~$ brctl show
bridge name     bridge id               STP enabled     interfaces
br1             8000.000c29371c0e       no              dummy1

if this isn't the case use the command brctl addif br1 eth1 and check again

5. Add a flat device to your simulation. If connecting to a linux server and wanting to access the rest of the network, make sure you enable routing (ipv4_forward & iptables rules).

6. Ensure the network is configured to use the flat network that you've just setup

7. When the simulation starts you should be able to attach to eth2 however you intend to, and ping/ssh to every device in your simulation (provided you have setup routing within the simulation to enable this)

I wish someone had walked me through this last Feb when I was fairly time poor - but now it's done. I hope it helps someone. Happy simulating!!

Sunday, 6 May 2018

Getting Familiar with Scapy

Getting Familiar with Scapy


Navigating Classes/Layers:

Check the details of each class/layer using ls():

>>> ls(IP)
version    : BitField             = (4)
ihl        : BitField             = (None)
tos        : XByteField           = (0)
len        : ShortField           = (None)
id         : ShortField           = (1)
flags      : FlagsField           = (0)
frag       : BitField             = (0)
ttl        : ByteField            = (64)
proto      : ByteEnumField        = (0)
chksum     : XShortField          = (None)
src        : Emph                 = (None)
dst        : Emph                 = ('')
options    : PacketListField      = ([])

Check commands available using lsc()

Format is command(packet)

Sending a Packet:

>>> pkt=IP(dst="google.com")/ICMP()

sr - send & receive
srp - send & receive layer 2

>>> sr1(pkt)
Begin emission:
..................Finished to send 1 packets.
Received 426 packets, got 0 answers, remaining 1 packets

sr1 = send and receive 1 packet, will send one and wait for one response

Using just send will just send and not wait for a response
>>> send(pkt)
Sent 1 packets.

Using sendp will send the packet at layer 2 (all classes with p are at the layer 2 level)
>>> sendp(pkt)
Sent 1 packets.

To see the result, sr always has tuples
>>> (ans,unans) = sr(IP(dst='google.com')/ICMP())

>>> pkts = IP(dst='')
>>> [pkt for pkt in pkts]
[<IP  dst= |>, <IP  dst= |>, <IP  dst= |>, <IP  dst= |>, <IP  dst= |>, <IP  dst= |>, <IP  dst= |>, <IP  dst= |>, <IP  dst= |>, <IP  dst= |>, <IP  dst= |>, <IP  dst= |>, <IP  dst= |>, <IP  dst= |>, <IP  dst= |>, <IP  dst= |>]

Reading/logging traffic:

Sniff packets on the interface:

>>> pkts = sniff(count=24)>>> pkts
<Sniffed: TCP:19 UDP:4 ICMP:0 Other:1>

Write the packets to a pcap file:

>>> wrpcap('./cap.pcap', pkts)

Write the pcap file back to a rpkts variable:

>>> rpkts = rdpcap('./cap.pcap')
>>> rpkts
<cap.pcap: TCP:19 UDP:4 ICMP:0 Other:1>

Use str() and hexdump() to also see the raw packet


verify which fields will be fuzzed by doing something similar to:

>>> (IP(dst='')/fuzz(UDP()/BOOTP())).show()

State machine!!

Network Fuzzing with AFL

Download, extract and make afl:
tar xvzf afl-latest.tgz
cd afl-2.35b/
Download, extract and make wireshark with afl:

tar xaf wireshark-2.2.1.tar.bz2

cd /usr/bin
ln -s /usr/libexec/gcc/x86_64-redhat-linux/5.3.1/cc1 cc1plus

CC=/root/afl-2.35b/afl-gcc CXX=/root/afl-2.35b/afl-g++ ./configure
make clean all

Capture and save SNMP packets with wireshark on alternate box:

/root/afl-2.35b/afl-fuzz -m 500 -f /root/afl-2.35b/mutated-data/data.pcap -i /root/afl-2.35b/testcases/pcap/snmp/ -o /root/afl-2.35b/findings_dir/ .libs/tshark -a @@

First appearance, it seems afl is mutating the PCAP structure not the SNMP structure:
Look at dictionary definitions for snmp and let it run for longer to see if some better results are generated.

Get better input via using snmpwalk