Minggu, 07 Juni 2020

The RastaLabs Experience

Introduction


It was 20 November, and I was just starting to wonder what I would do during the next month. I had already left my previous job, and the new one would only start in January. Playing with PS4 all month might sound fun for some people, but I knew I would get bored quickly.

Even though I have some limited red teaming experience, I always felt that I wanted to explore the excitement of getting Domain Admin – again. I got my first DA in ˜2010 using pass-the-hash, but that was a loooong time ago, and things change quickly.
While reading the backlogs of one of the many Slack rooms, I noticed that certain chat rooms were praising RastaLabs. Looking at the lab description, I felt "this is it, this is exactly what I need." How hard could it be, I have a whole month ahead of me, surely I will finish it before Christmas. Boy, was I wrong.



The one-time fee of starting the lab is 90 GBP which includes the first month, then every additional month costs 20 GBP. I felt like I was stealing money from Rastamouse and Hackthebox... How can it be so cheap? Sometimes cheap indicates low quality, but not in this case.



My experience


Regarding my previous experience, I already took OSCP, OSCE, SLAE (Securitytube Linux Assembly Expert), and PSP (Powershell for Pentesters), all of which helped me a lot during the lab. I also had some limited red teaming experience. I had more-than-average experience with AV evasion, and I already had experience with the new post-exploit frameworks like Covenant and Powershell Empire. As for writing exploits, I knew how a buffer overflow or a format string attack worked, but I lacked practice in bypassing ASLR and NX. I basically had zero experience with Mimikatz on Windows 10. I used Mimikatz back in 2012, but probably not since. I also had a lot of knowledge on how to do X and Y, on useful tools and hot techniques, but I lacked recent experience with them. Finally, I am usually the last when it comes to speed in hacking, but I have always balanced my lack of speed with perseverance.

RastaLabs starts in 3,2,1 ...


So I paid the initial entry fee, got the VPN connection pack, connected to the lab, and got my first flag after ... 4 days. And there were 17 of them in total. This was the first time I started to worry. I did everything to keep myself on the wrong track, stupid things like assuming incorrect lab network addresses, scanning too few machines, finding the incorrect breadcrumbs via OSINT, trying to exploit a patched web service (as most OSCPers would do), etc. I was also continually struggling with the tools I was using, as I never knew whether they were buggy, or I was misusing them, or this is just not the way to get the flag. I am sure someone with luck and experience could have done this stage in 2-3 hours, but hey, I was there to gain experience.

During the lab, whenever I got stuck with the same problem for more than 30-40 hours and my frustration was running high, I pinged Rastamouse on the official RastaLabs support channel on https://mm.netsecfocus.com/. I usually approached him like "Hi, I tried X, Y, and Z but no luck", then he replied "yeah, try Y harder". This kind of information was usually all I needed, and 2-3 hours later I was back on track again. His help was always enough, but never too much to spoil the fun. The availability and professionalism of Rastamouse was 10/10. Huge multi-billion dollar companies fail to provide good enough support, this one guy here was always there to help. Amazing. I highly recommend joining the Mattermost channel – it will help you a lot to see that you are not the only one stuck with problems. But please do not DM him or the channel if you have not already tried harder.

What's really lovely in the lab is that you can expect real-world scenarios with "RastaLabs employees" working on their computer, reading emails, browsing the web, etc. I believe it is not a spoiler here that at some point in time you have to deliver malware that evades the MS Defender AV on the machine. Yes, there is a real working Defender on the machines, and although it is a bit out of date, it might catch your default payload very quickly. As I previously mentioned, luckily I had recent experience with AV evasion, so this part was not new to me. I highly recommend setting up your own Win10 with the latest Defender updates and testing your payload on it first. If it works there, it will work in the lab. This part can be especially frustrating, because the only feedback you get from the lab is that nothing is happening, and there is no way to debug it. Test your solution locally first.

Powershell Empire turned out to be an excellent solution for me, the only functionality it lacked was Port Forwarding. But you can drop other tools to do this job efficiently.

A little help: even if you manage to deliver your payload and you have a working C&C, it does not mean your task with AV evasion is over. It is highly probable that Defender will block your post-exploit codes. To bypass this, read all the blog posts from Rastamouse about AMSI bypass. This is important.

Lateral movement


When you finally get your first shell back ...



A whole new world starts. From now on, you will spend significant time on password cracking, lateral movement, persistence, and figuring out how Windows AD works.
In the past, I played a lot of CTF, and from time to time I got the feeling "yeah, even though this challenge was fun, it was not realistic". This never happened during RastaLabs. All the challenges and solutions were 100% realistic, and as the "Ars poetica" of RastaLabs states:



...which is sooooo true. None of the tasks involve any exploit of any CVE. You need a different mindset for this lab. You need to think about misconfigurations, crackable passwords, privilege abuse, and similar issues. But I believe this lab is still harder to own than 90% of the organizations out there. The only help is that there are no blue-teamers killing our shells.

About the architecture of the lab: When connecting to the lab with VPN, you basically found yourself in a network you might label as "Internet", with your target network being behind a firewall, just as a proper corporate network should be.
There are a bunch of workstations – Win10 only, and some servers like fileserver, exchange, DC, SQL server, etc. The majority of servers are Windows Server 2016, and there is one Linux server. The two sites are adequately separated and firewalled.

As time passed, I was getting more and more flags, and I started to feel the power. Then the rollercoaster experience started. I was useless, I knew nothing. Getting the flag, I was god. One hour later, I was useless.



For example, I spent a significant amount of time trying to get GUI access to the workstations. In the end, I managed to get that, just to find out I did not achieve anything with it. For unknown reasons, none of the frameworks I tried had a working VNC, so I set up my own, and it was pain.

On December 18, I finally got Domain Admin privileges. So my estimation to "finish the lab" in one month was not that far off. Except that I was far from finishing it, as I still had to find five other flags I was missing. You might ask "you already have DA, how hard could it be to find the remaining five?". Spoiler alert, it was hard. Or to be more precise, not hard, just challenging, and time-consuming. This was also a time when connections on Mattermost RastaLabs channel helped me a lot. Hints like "flag X is on machine Y" helped me keep motivated, yet it did not spoil the fun. Without hints like this, I would not have written this post but would have been stuck with multiple flags.

About exploitation


And there was the infamous challenge, "ROP the night away." This was totally different from the other 16. I believe this image explains it all:


If you are not friends with GDB, well, you will have a hard time. If you don't have lots of hands-on experience with NX bypass - a.k.a ROP - like me, you will have a hard time with this challenge. The binary exploit challenges during OSCP and OSCE exams are nowhere near as complex as this one. If you have OSEE, you will be fine. For this challenge, I used GDB-Peda and Python pwntools – check them out in case you are not familiar with them. For me, solving this challenge took about 40 hours. Experienced CTF people could probably solve it in 4 hours or less.

Conclusion


I would not recommend taking this lab for total beginners *. I also do not recommend doing the lab if you only have limited time per day, which is especially true if you are working on your home computer. I probably would have saved hours or even days if I had set up a dedicated server in the cloud for this lab. The issue was that the lab workstations were rebooted every day, which meant that I always lost my shells. "Persistence FTW", you might say, but if your C&C is down when the workstation reboots, you are screwed. "Scheduled tasks FTW", you might say, but unless you have a strict schedule on when you start your computer, you will end up with a bunch of scheduled tasks just to get back the shell whenever you start your computer. Day after day I spent the first hour getting back to where I had been the day before. And I just figured out at the end of the lab why some of my scheduled tasks were not working ...

I would be really interested to see how much time I spent connected to the lab. Probably it was around 200–250 hours in total, which I believe is more than I spent on OSCP and OSCE combined. But it was totally worth it. I really feel the power now that I learned so many useful things.

But if you consider that the price of the one-month lab is 20 GBP, it is still a very cheap option to practice your skills. 
* It is totally OK to do the lab in 6 months, in case you start as a beginner. That is still just 190 GBP for the months of lab access, and you will gain a lot of experience during this time. You will probably have a hard time reaching the point when you have a working shell, but it is OK. You can find every information on Google, you just need time, patience and willingness to get there.

Anyway, it is still an option not to aim to "get all the flags". Even just by getting the first two flags, you will gain significant experience in "getting a foothold". But for me, not getting all the flags was never an option.



If you are still unconvinced, check these other blog posts:

Or see what others wrote about RastaLabs.


Footnote


In case you start the lab, please, pretty please, follow the rules, and do not spoil the fun for others. Do not leave your tools around, do not keep shared drives open, do not leave FLAGs around. Leave the machine as it was. If you have to upload a file, put it in a folder others won't easily find. This is a necessary mindset when it comes to real-world red teaming. Don't forget to drop a party parrot into the chat whenever you or someone else gets a new flag. And don't forget:
OSCP has no power here. Cry harder!

I will probably keep my subscription to the lab and try new things, new post-exploit frameworks. I would like to thank @_rastamouse for this great experience, @superkojiman for the ROP challenge. Hackthebox for hosting the lab with excellent uptime.
As for @gentilkiwi and @harmj0y, these two guys probably advanced red-teaming more than everyone else combined together. pwntools from @gallopsled was also really helpful. And I will be forever grateful to Bradley from finance for his continuous support whenever I lost my shells.
Related word

DOWNLOAD XSSTRIKE – ADVANCED XSS EXPLOITATION SUITE

XSSTRIKE – ADVANCED XSS EXPLOITATION SUITE

XSStrike is really advanced XSS exploitation and detection suite, which contains a very powerful XSS fuzzer and provides no false positive results using fuzzy matching. XSStrike is the first XSS scanner that generates its own payloads. Download xsstrike and test it out.
It also has built in an artificial intelligent enough to detect and break out of various contexts.

FEATURES:

  • Powerful Fuzzing Engine
  • Context Breaking Intelligence
  • AI Payload Generation
  • GET & POST Methods Support
  • Cookie Support
  • WAF Fingerprinting
  • Handcrafted Payloads to Filter and WAF Evasion
  • Hidden Parameter Discovery
  • Accurate Results

DOWNLOAD XSSTRIKE – ADVANCED XSS EXPLOITATION SUITE

Click here to download xsstrike.
Continue reading

Parrot Security OS 4.7 Released With New Linux Kernel, Menu Structure, Tools Improvements And Many Changes


In Sep 18 2019, Parrot Security OS 4.7 has released, with many new following changes below.

Latest Linux 5.2.x series
   The new ISO files of Parrot 4.7 are being released only now, but we were the first Debian derivative distribution to introduce Linux 5.1 and 5.2 to all our users, and now ParrotSec team is ready to offer it also with our ISO files rebild cycle to support more devices and integrate all the latest linux features from the beginning.

New sandbox behavior (opt-in rather than opt-out)
   Sandboxing is a great thing, and ParrotSec team was in the first line when they introduced our custom Firejail and AppArmor solution for the first time many years ago. We still want to improve such feature and ParrotSec team has a whole team dedicated to improve sandboxing and hardening of the Parrot Security OS system, but ParrotSec team had to face the many users with issues caused by the restrictions of our sandbox.

   In Parrot Security OS 4.7 the sandbox is disabled by default, and users can decide wether to start an application sandboxed or not. You can easily start the sandboxed version of an installed program from the /sandbox/ folder or from a dedicated menu that ParrotSec team plans to improve in the future (meanwhile the search feature of the bottom menu will fit all your needs), or you can re-enable it by default by using the firecfg tool.

New menu structure and tools improvements
   The pentesting menu structure was refactored and re-designed to make tools easier to access in a more logical hierarchical structure. New tools were also added to the project, and ParrotSec team plans to add even more in the future. Not all of them are going to be pre-installed, but a good set of tools in our repository enables pentesters to build up the perfect pentest system for their specific needs, regardless the default package selection picked by ParrotSec team.

Domain changes
   To reflect the neutrality of a distro that started as a pentest-only system and became more general purpose later with Parro Home, the community voted through a democratic process to switch to parrotlinux.org as the new default domain of the project.

   ParrotSec team will still use ParrotSec.org for other things (included the old email addresses), and they introduced other project domains to handle specific parts of the infrastructure.

Repository changes
   ParrotSec team is preparing to integrate a future LTS branch, so they decided to rename the current repository from stable to rolling. Nothing changes for the end user, and the current Parrot Security OS branch will continue to behave the same as before, but now with a different name to better reflect the rolling release nature of the system, waiting for the LTS edition to join the Parrot Security OS family along side the rolling branch in a similar way OpenSUSE does.

New MATE 1.22 release: Parrot Security OS 4.7 ships with the latest MATE 1.22 desktop environment.

Miscellaneous: New Firefox Browser 69, the latest Radare2 and cutter versions and many other important upgrades are all aboard as expected in a properly developed rolling release distro.

How to upgrade to the lastest Parrot Security OS version
   You can update your existing Parrot Security OS system with this command:
sudo parrot-upgrade

   Or use the raw apt command
sudo apt update
sudo apt full-upgrade


   Don't forget to use this command regularly (at least once a week) to receive the latest security updates and bugfixes from the Parrot Security OS repository.

   Or you can download the latest release from official download page.

Related posts

Reversing Rust String And Str Datatypes

Lets build an app that uses several data-types in order to see how is stored from a low level perspective.

Rust string data-types

The two first main objects are "str" and String, lets check also the constructors.




Imports and functions

Even such a basic program links several libraries and occupy 2,568Kb,  it's really not using the imports and expots the runtime functions even the main. 


Even a simple string operation needs 544 functions on rust:


Main function

If you expected see a clear main function I regret to say that rust doesn't seem a real low-level language In spite of having a full control of the memory.


Ghidra turns crazy when tries to do the recursive parsing of the rust code, and finally we have the libc _start function, the endless loop after main is the way Ghidra decompiles the HLT instruction.


If we jump to main, we see a function call, the first parameter is rust_main as I named it below:



If we search "hello world" on the Defined Strings sections, matches at the end of a large string


After doing "clear code bytes" we can see the string and the reference:


We can see that the literal is stored in an non null terminated string, or most likely an array of bytes. we have a bunch of byte arrays and pointed from the code to the beginning.
Let's follow the ref.  [ctrl]+[shift]+[f] and we got the references that points to the rust main function.


After several naming thanks to the Ghidra comments that identify the rust runtime functions, the rust main looks more understandable.
See below the ref to "hello world" that is passed to the string allocated hard-coding the size, because is non-null terminated string and there is no way to size this, this also helps to the rust performance, and avoid the c/c++ problems when you forgot the write the null byte for example miscalculating the size on a memcpy.


Regarding the string object, the allocator internals will reveal the structure in static.
alloc_string function call a function that calls a function that calls a function and so on, so this is the stack (also on static using the Ghidra code comments)

1. _$LT$alloc..string..String$u20$as$u20$core..convert..From$LT$$RF$str$GT$$GT$::from::h752d6ce1f15e4125
2. alloc::str::_$LT$impl$u20$alloc..borrow..ToOwned$u20$for$u20$str$GT$::to_owned::h649c495e0f441934
3. alloc::slice::_$LT$impl$u20$alloc..borrow..ToOwned$u20$for$u20$$u5b$T$u5d$$GT$::to_owned::h1eac45d28
4. alloc::slice::_$LT$impl$u20$$u5b$T$u5d$$GT$::to_vec::h25257986b8057640
5. alloc::slice::hack::to_vec::h37a40daa915357ad
6. core::slice::_$LT$impl$u20$$u5b$T$u5d$$GT$::len::h2af5e6c76291f524
7. alloc::vec::Vec$LT$T$GT$::extend_from_slice::h190290413e8e57a2
8. _$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$alloc..vec..SpecExtend$LT$$RF$T$C$core..slice..Iter$LT$T$GT$$GT$$GT$::spec_extend::h451c2f92a49f9caa
...


Well I'm not gonna talk about the performance impact on stack but really to program well reusing code grants the maintainability and its good, and I'm sure that the rust developed had measured that and don't compensate to hardcode directly every constructor.

At this point we have two options, check the rust source code, or try to figure out the string object in dynamic with gdb.

Source code

Let's explain this group of substructures having rust source code in the hand.
The string object is defined at string.rs and it's simply an u8 type vector.



And the definition of vector can be found at vec.rs  and is composed by a raw vector an the len which is the usize datatype.



The RawVector is a struct that helds the pointer to the null terminated string stored on an Unique object, and also contains the allocation pointer, here raw_vec.rs definition.



The cap field is the capacity of the allocation and a is the allocator:



Finally the Unique object structure contains a pointer to the null terminated string, and also a one byte marker core::marker::PhantomData



Dynamic analysis

The first parameter of the constructor is the interesting one, and in x64 arch is on RDI register, the extrange sequence RDI,RSI,RDX,RCX it sounds like ACDC with a bit of imagination (di-si-d-c)

So the RDI parámeter is the pointer to the string object:



So RDI contains the stack address pointer that points the the heap address 0x5578f030.
Remember to disable ASLR to correlate the addresses with Ghidra, there is also a plugin to do the synchronization.

Having symbols we can do:
p mystring

and we get the following structure:

String::String {
  vec: alloc::vec::Vec {
    buf: alloc::raw_vec::RawVec {
      ptr: core::ptr::unique::Unique {
        pointer: 0x555555790130 "hello world\000",
        _marker: core::marker::PhantomData
     },
     cap: 11,
     a: alloc::alloc::Global
   },
   len: 11
  }
}

If the binary was compiled with symbols we can walk the substructures in this way:

(gdb) p mystring.vec.buf.ptr
$6 = core::ptr::unique::Unique {pointer: 0x555555790130 "hello world\000", _marker: core::marker::PhantomData}

(gdb) p mystring.vec.len

$8 = 11

If we try to get the pointer of each substructure we would find out that the the pointer is the same:


If we look at this pointer, we have two dwords that are the pointer to the null terminated string, and also 0xb which is the size, this structure is a vector.


The pionter to the c string is 0x555555790130




This seems the c++ string but, let's look a bit deeper:

RawVector
  Vector:
  (gdb) x/wx 0x7fffffffdf50
  0x7fffffffdf50: 0x55790130  -> low dword c string pointer
  0x7fffffffdf54: 0x00005555  -> hight dword c string pointer
  0x7fffffffdf58: 0x0000000b  -> len

0x7fffffffdf5c: 0x00000000
0x7fffffffdf60: 0x0000000b  -> low cap (capacity)
0x7fffffffdf64: 0x00000000  -> hight cap
0x7fffffffdf68: 0xf722fe27  -> low a  (allocator)
0x7fffffffdf6c: 0x00007fff  -> hight a
0x7fffffffdf70: 0x00000005 

So in this case the whole object is in stack except the null-terminated string.




Related links

  1. Hacking Resources
  2. Hacking
  3. How To Pentest A Website With Kali
  4. Pentest Vs Red Team
  5. Hacker Attack
  6. Hacking To The Gate
  7. Hacking Quotes
  8. Pentest Keys
  9. Pentest Uk
  10. Hacking Page
  11. Hacker Website
  12. Pentestmonkey

Hacking All The Cars - Part 1


A step by step lab based mini course on analyzing your car network


I wanted to learn about hacking cars. As usual I searched around the internet and didn't find any comprehensive resources on how to do this, just bits and pieces of the same info over and over which is frustrating. I am not a car hacking expert, I just like to hack stuff. This mini course will run in a fully simulated lab environment available from open garages, which means in 5 minutes from now you can follow along and hack cars without ever bricking your girlfriends car. Since you obviously wouldn't attack your own Lambo, totally use your girlfriends Prius. 

Below are the topics covered in this blog  series so you can decide if you want to read further: 

Whats covered in this car hacking mini course: 

Setting up Virtual Environments for testing
Sniffing CAN Traffic
Parsing CAN Traffic
Reverse Engineering CAN IDs 
Denial of service attacks
Replaying/Injecting Traffic
Coding your own CAN Socket Tools in python
Targeted attacks against your cars components
Transitioning this to attacking a real car with hardware

The first thing we are going to do before we get into any car hacking specifics such as "WTF is CAN?", is get your lab up and running. We are going to run a simple simulated CAN Bus network which controls various features of your simulated car. Its better to learn by doing then sit here and recite a bunch of car network lingo at you and hope you remember it.  

I also don't want you to buy a bunch of hardware and jack into your real car right away. Instead there are options that can get you started hacking cars RIGHT NOW by following along with this tutorial. This will also serve to take away the fear of hacking your actual car by understanding what your doing first. 


Video Playlist: 




Setting up your Lab: 

First things first, set yourself up with an Ubuntu VMware install, and load it up. Optionally you could use a Kali Iinux VM, however, that thing drives me nuts with copy paste issues and I think Kayak was giving me install problems. So support is on you if you would like to use Kali. However, I do know Kali will work fine with OpenGarages virtual car.. So feel free to use it for that if you have it handy and want to get started right away. 


Install PreReq Libraries: 

Once you load this up you are going to want to install CAN utilities and pre-requisite libraries. This is really easy to do with the following Apt-get commands:
sudo apt-get update
sudo apt-get install libsdl2-dev libsdl2-image-dev can-utils  

Then we are going to pull down the ICSimulator repo: 


Starting the simulator: 

Once this is done we can startup the simulator by changing directories to the downloaded repo and running the following 2 commands, which will setup a virtual CAN interface and a simulator GUI Cluster: 

Run the setup Script to get the vcan0 interface up: 
root@kali:~/ICSim# ./setup_vcan.sh 
root@kali:~/ICSim# ./icsim vcan0

On a new terminal tab we will open up our simulators controller with the following command,
root@kali:~/ICSim#./controls vcan0

Note: that the controller must be the in-focus GUI screen to send keyboard commands to the simulator. 






How to Use the Simulator: 

The simulator has a speedometer with Right and Left turn signals, doors etc.  Below are the list of commands to control the simulator when the Control panel is in focus. Give them each a try and note the changes to the simulator. 
Up and Down keys control the gauges clusters speedometer
Left and Right keys Control the Blinkers
Right Shift + X, A or B open doors 
Left Shift + X, A or be Close doors

Try a few of the above commands for example Right Shift +X and you will see the interface change like so, notice the open door graphic: 


Awesome, thanks to OpenGarages you now you have your very own car to hack

Notice in the setup commands above we used a VCan0 interface. Run Ifconfig and you will now see that you indeed have a new network interface that speaks to the CAN network over VCan0. 

ficti0n@ubuntu:~/Desktop/ICSim$ ifconfig vcan0
vcan0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          UP RUNNING NOARP  MTU:16  Metric:1
          RX packets:558904 errors:0 dropped:0 overruns:0 frame:0
          TX packets:558904 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:3663935 (3.6 MB)  TX bytes:3663935 (3.6 MB)


Car networks run on a variety of protocols most prevalent being CAN. You can think of a CAN Bus like an old school networking hub where everyone can see everyone elses traffic. This is true to some extent although you may not see all of the cars traffic if its not connected to that particular bus your plugged into. You can think of CAN traffic kind of like UDP in that its send and forget, the main difference being parts of the CAN bus network don't actually have addresses and everything runs off arbitration IDs and priorities. Thats enough background to get you doing rather then reading.

With a little knowledge out of the way lets check if we can see our CAN traffic from our virtual car via the CanDump utility, which you installed as part of CanUtils package above. Using the following command on the vcan0 interface our simulator uses you can view a stream of traffic: 

ficti0n@ubuntu:~/Desktop/ICSim$ candump vcan0



Above we can see a bunch of CAN frames, and if we perform actions on the vehicle we will see changes to data values in the CanDump output.  However this may happen very fast, and we may not be able to see if for example we unlocked our simulators door. This is because things are changing constantly in the cars IDLE state. One single value changing may not stand out enough for us to take notice or may scroll so fast we cant see it. 


Capture and Replay CAN Actions: 

One option would be to perform an action and replay it, we should see the actions happen again in the replay if the traffic for the action we recorded is on the same bus network our device is plugged into. There are loads of networks within a car and its not guaranteed our network tap for example an OBD2 port plugin is connected to the same network as door we opened.  Or the door may not be connected to the network at all depending on your car and its age or how its configured. 

Replaying dumps with CanPlayer: 
Another useful tool included with CanUtils package is CanPlayer for replaying traffic. If the functionality we are trying to capture is on the same Bus as the adaptor plugged into the car, or in this case our Virtual CAN interface, we can use CanDump to save traffic to a file. We then use CanPlayer to replay the traffic on the network. For example lets run CanDump and open a door and then replay the functionality with CanPlayer. 

Lab 1 Steps: 

  1. Run CanDump
  2. Right Shift + X to open a door
  3. Cancel CanDump (ctrl+c)
  4. Left Shift + X to close the door
  5. Run can player with the saved dump and it will replay the traffic and open the door

Recording the door opening:  (-l for logging) 
ficti0n@ubuntu:~/Desktop/ICSim$ candump -l vcan0

Replaying the CanDump file:  (use the file your can dump created) 
ficti0n@ubuntu:~/Desktop/ICSim$ canplayer -I candump-2018-04-06_154441.log 

Nice, so if all went well you should see that your door is now open again. If this did not happen when attacking a real car, just try to replay it again. CAN networks are not like TCP/IP, they are more like UDP in that you send out your request and its not expecting a response. So if it gets lost then it gets lost and you have to resend. Perhaps something with higher priority on the network was sending at the time of your replay and your traffic was overshadowed by it.   




Interacting with the Can Bus and Reversing Traffic: 

So thats cool, but what about actually understanding what is going on with this traffic, CanDump is not very useful for this, is scrolls by to quickly for us to learn much from.  Instead we can use CanSniffer with colorized output to show us the bytes within packets that change. Below is an example of CanSniffer Traffic: 

To startup can sniffer run the following: 
ficti0n@ubuntu:~/Desktop/ICSim$ cansniffer -c vcan0




You will see 3 fields, Time, ID  and Data. Its pretty easy to figure out what these are based on thier name. The most important part for our usage in this blog are the ID and the Data fields.  

The ID field is the frame ID which is loosely associated with the device on the network which is effected by the frame being sent. The ID to also determines the priority of the frame on the network.  The lower the number of the CAN-ID the higher priority it has on the network and more likely it will be handled first.  The data field is the data being sent to change some parameter like unlocking a door or updating output. You will notice that some of the bytes are highlighted RED. The values in red are the values that are changing during the idle state you are currently in. 


Determine which ID and Byte controls the throttle: 

So with the terminal sniffing window open put the simulator and the controller into the foreground, with the controller being the window you have clicked and selected.  Pay attention to the CanSniffer output while hitting the UP ARROW and look for a value that was white but is now Red and increasing in value as the throttle goes up.  This might take you a few minutes of paying attention to whats going on to see. 

The following 2 pictures show ID 244 in the IDLE state followed by pressing the up button to increase the speed. You will notice a byte has turned red and is increasing in value through a range of HEX values 0-F. It will continue to enumerate through values till it reaches its max speed. 





The byte in ID 244 which is changing is the value while the throttle is engaged, so 244 associated in some way with the increasing speed.   The throttle speed is a good value to start with as it keeps increasing its value when pressed making it easier to spot while viewing the CanSniffer output.  


Singling out Values with Filters: 

If you would like to single out the throttle value then click the terminal window and press -000000 followed by the Enter key which will clear out all of the values scrolling. Then press +244 followed by the Enter key which will add back the throttle ID. You can now click the controller again and increase the speed with your Up arrow button without all the noise clouding your view.  You will instead as shown below only have ID 244 in your output: 




To get back all of the IDs again click the terminal window and input +000000 followed by the Enter key.   Now you should see all of the output as before.  Essentially 000000 means include everything. But when you put a minus in front of it then it negates everything and clears your terminal window filtering out all values. 


Determine Blinker ID: 

Now lets figure out another ID for the blinkers. If you hit the left or right arrow with the controls window selected you will notice a whole new ID appears in the list, ID 188 shown in the picture below which is associated with the blinker. 




This ID was not listed before as it was not in use within the data output until you pressed the blinker control.  Lets single this value out by pressing -000000 followed by +188.  Just like in the throttle example your terminal should only show ID 188, initially it will show with 00 byte values. 

 As you press the left and the right blinker you will see the first Byte change from 00 to 01 or 02. If neither is pressed as in the screenshot above it will be 00. Its kind of hard to have the controller in focus and get a screenshot at the same time but the ID will remain visible as 00 until it times out and disappears from the list when not active. However with it filtered out as above you can get a better view of things and it wont disappear.  


Time for YOU to do some Protocol Reversing:

This lab will give you a good idea how to reverse all of the functionality of the car and associate each action with the proper ID and BYTE. This way you can create a map of intended functionality changes you wish to make.  Above we have done a few walk throughs with you on how to determine which byte and ID is associated with an action. Now its time to map everything out yourself with all the remaining functionality before moving on to attacking individual components.  


Lab Work Suggestion: 


  1. Take out a piece of paper and a pencil
  2. Try unlocking and locking doors and write down the ID which controls this action (remember your filters)
  3. Try unlocking each door and write down the BYTES needed for each door to open
  4. Try locking each doors and what Bytes change and what are their values, write them down
  5. Do the same thing for the blinkers left and right (Might be different then what I did above) 
  6. What ID is the speedometer using?  What byte changes the speed? 


Attacking Functionality Directly: 

With all of the functionality mapped out we can now try to target various devices in the network directly without interacting with the controllers GUI. Maybe we broke into the car via cellular OnStar connection  or the center console units BLE connection which was connected to the CAN network in some way.  
After an exploit we have direct access to the CAN network and we would like to perform actions. Or maybe you have installed a wireless device into an OBD2 port under the dashboard you have remote access to the automobile. 

Using the data from the CAN network reversing lab above we can call these actions directly with the proper CAN-ID and Byte.  Since we are remote to the target we can't just reach over and grab the steering wheel or hit the throttle we will instead send your CAN frame to make the change.
One way we can do this is via the CanSend utility. Lets take our information from our lab above and make the left turn signal flash with the following ID 188 for the turn signal by changing the first byte to 01 indicating the left signal is pressed. CanSend uses the format ID#Data. You will see this below when sending the turn signal via CanSend. 

ficti0n@ubuntu:~/Desktop/ICSim$ cansend vcan0 188#01000000 



You should have noticed that the left signal flashed. If not pay more attention and give it another try or make sure you used the correct ID and changed the correct byte.  So lets do the same thing with the throttle and try to set the speed to something with ID 244 that we determined was the throttle. 

ficti0n@ubuntu:~/Desktop/ICSim$ cansend vcan0 244#00000011F6 

My guess is that nothing happened because its so fast the needle is not going to jump to that value. So instead lets try repeating this over and over again with a bash loop which simply says that while True keep sending the throttle value of 11 which equates to about 30mph: 

ficti0n@ubuntu:~/Desktop/ICSim$ while true; do cansend vcan0 244#00000011F6;  done




Yes thats much better, you may notice the needle jumping back and forth a bit. The reason the needle is bouncing back and forth is because the normal CAN traffic is sent telling the car its actually set to 00 in between your frames saying its 30mph.  But it worked and you have now changed the speed the car sees and you have flashed the blinker without using the cars normal blinker controls. Pretty cool right? 


Monitor the CAN Bus and react to it: 

Another way to handle this issue is to monitor the CAN network and when it sees an ID sent it will automatically send the corresponding ID with a different value.. Lets give that a try to modify our speed output by monitoring for changes. Below we are simply running CanDump and parsing for ID 244 in the log output which is the throttle value that tells the car the speed. When a device in the car reports ID 244 and its value we will immediately resend our own value saying the speed is 30mph with the value 11.  See below command and try this out. 

ficti0n@ubuntu:~/Desktop/ICSim$ candump vcan0 | grep " 244 " | while read line; do cansend vcan0 244#00000011F6; done

With this running after a few seconds you will see the speed adjust to around 30MPH once it captures a legitimate CAN-ID 244 from the network traffic and sends its own value right after.  

Ok cool, so now while the above command is still running click the controller window and start holding down the Up arrow with the controller in focus.. After a few seconds or so when the speed gets above 30MPH you will see the needle fighting for the real higher value and adjusting back to 30MPH as your command keeps sending its on value as a replacement to the real speed. 

So thats one way of monitoring the network and reacting to what you see in a very crude manner.  Maybe someone stole your car and you want to monitor for an open door and if they try to open the door it immediately locks them in. 


Conclusion and whats next: 

I am not an expert car hacker but I hope you enjoyed this. Thats about as far as I want to go into this subject today, in the next blog we will get into how to code python to perform actions on the CAN network to manipulate things in a similar way.  With your own code you are not limited to the functionality of the tools you are provided and can do whatever you want. This is much more powerful then just using the CanUtils pre defined tools. Later on I will also get into the hardware side of things if you would like to try this on a real car where things are more complicated and things can go wrong. 

Related links


Menu