There are many goodware and malware developed in pascal, and we will see that the binary generated by the pascal compilers is fascinating, not only because the small and clean generated binaries, or the clarity of the pascal code, but also the good performance. In Linux we have Lazarus which is a good free IDE like Delphi and Kylix the free pascal IDE for windows.
The program:
program strtest; var cstr: array[0..10] of char; s, s2: ShortString; begin cstr := 'hello world'; s := cstr; s2 := 'test'; WriteLn(cstr + ' ' + s + ' ' + s2); end.
We are going to compile it with freepascal and lazarus, and just the binary size differs a lot:
And surprisingly turbopascal binaries are extremely light. Lets start with lazarus:
Logically it imports from user32.dll some display functions, it also import the kernel32.dll functions and suspiciously the string operations of oleaut32.dll
And our starting point is a function called entry that calls the console initialization and retrieve some console configurations, and then start a labyrinth of function calls.
On functions 10000e8e0 there is the function that calls the main function.
I named execute_param2 because the second param is a function pointer that is gonna be executed without parameters, it sounds like main calling typical strategy. And here we are, it's clearly the user code pascal main function.
What it seems is that function 100001800 returns an string object, then is called its constructor to initialize the string, then the string is passed to other functions that prints it to the screen.
This function executes the method 0x1c0 of the object until the byte 0x89 is a null byte. What the hell is doing here? First of all let's create the function main:
Simply right button create function:
After a bit of work on Ghidra here we have the main:
Note that the struct member so high like 0x1b0 are not created by default, we should import a .h file with an struct or class definition, and locate the constructor just on that position.
The mysterious function was printing byte a byte until null byte, the algorithm the compiler implemented in asm is not as optimized as turbopascal's.
In Windbg we can see the string object in eax after being created but before being initialized:
Just before executing the print function, the RCX parameter is the string object and it still identical:
Let's see the constructor code. The constructor address can be guessed on static walking the reverse-cross-references to main, but I located it in debugging it in dynamic analysis.
The constructor reads only a pointer stored on the string object on the position 0x98.
And we have that the pointer at 0x98 is compared with the address of the literal, so now we know that this pointer points to the string. The sentence *string_x98 = literal confirms it, and there is not memory copy, it only points reusing the literal.
Freepascal
The starting labyrinth is bigger than Lazarus so I had to begin the maze from the end, searching the string "hello world" and then finding the string references:
There are two ways to follow the references in Ghidra, one is [ctrl] + [shift] + F but there is other trick which is simply clicking the green references texts on the disassembly.
At the beginning I doubted and put the name possible_main, but it's clearly the pascal user code main function.
The char array initialization Is converted by freepascal compiler to an runtime initialization using mov instructions.
Reducing the coverage on dynamic we arrive to the writeln function:
EAX helds a pointer to a struct, and the member 0x24 performs the printing. In this cases the function can be tracked easily in dynamic executing the sample.
And lands at 0x004059b0 where we see the WriteFile, the stdout descriptor, the text and the size supplied by parameter.
there is an interesting logic of what happens if WriteFile() couldn't write all the bytes, but this is other scope. Lets see how this functions is called and how text and size are supplied to figure out the string object.
EBX helds the string object and there are two pointers, a pointer to the string on 0x18 and the length in 0x18, lets verify it on windbg.
And here we have the string object, 0x0000001e is the length, and 0x001de8a68 is the pointer.
The term cyber security refers to the technologies and processes designed to defend computer system, software, networks & user data from unauthorized access, also from threats distributed through the internet by cybercriminals,terrorist groups of hacker.
Main types of cybersecurity are
Critical infrastructure security
Application security
Network Security
Cloud Security
Internet of things security.
These are the main types of cybersecurity used by cybersecurity expert to any organisation for safe and protect thier data from hack by a hacker.
Top Skills Required to become Cybersecurity Expert-
Problem Solving Skills
Communication Skill
Technical Strength & Aptitude
Desire to learn
Attention to Detail
Knowledge of security across various platforms
Knowledge of Hacking
Fundamental Computer Forensic Skill.
These skills are essential for become a cybersecurity expert.
Cyber cell and IT cell these are the department in our india which provide cybersecurity and looks into the matters related to cyber crimes to stop the crime because in this digitilization world cyber crime increasing day by day so our government of india also takes the immediate action to prevent the cybercrimes with the help of these departments and also arrest the victim and file a complain against him/her with the help of cyberlaw in our constitution.
Bob was tasked to break into XYZcorporation, so he pulled up the facility on google maps to see what the layout was. He was looking for any possible entry paths into the company headquarters. Online maps showed that the whole facility was surrounded by a security access gate. Not much else could be determined remotely so bob decided to take a drive to the facility and get a closer look.
Bob parked down the street in view of the entry gate. Upon arrival he noted the gate was un-manned and cars were rolling up to the gate typing in an access code or simply driving up to the gate as it opening automatically.Interestingly there was some kind of wireless technology in use.
How do we go from watching a car go through a gate, to having a physical device that opens the gate?
We will take a look at reversing a signal from an actual gate to program a remote with the proper RF signal.Learning how to perform these steps manually to get a better understanding of how RF remotes work in conjunction with automating processes with RFCrack.
In the the previous blogs, we sniffed signals and replayed them to perform actions. In this blog we are going to take a look at a signal and reverse it to create a physical device that will act as a replacement for the original device. Depending on the scenario this may be a better approach if you plan to enter the facility off hours when there is no signal to capture or you don't want to look suspicious.
Recon:
Lets first use the scanning functionality in RFCrack to find known frequencies. Weneed to understand the frequencies that gates usually use. This way we can set our scanner to a limited number of frequencies to rotate through. The smaller rage of frequencies used will provide a better chance of capturing a signal when a car opens the target gate. This would be beneficial if the scanning device is left unattended within a dropbox created with something like a Kali on a Raspberry Pi. One could access it from a good distance away by setting up a wifi hotspot or cellular connection.
Based on research remotes tend to use 315Mhz, 390Mhz, 433Mhz and a few other frequencies. So in our case we will start up RFCrack on those likely used frequencies and just let it run. We can also look up the FCID of our clicker to see what Frequencies manufactures are using. Although not standardized, similar technologies tend to use similar configurations. Below is from the data sheet located at https://fccid.io/HBW7922/Test-Report/test-report-1755584 which indicates that if this gate is compatible with a universal remote it should be using the 300,310, 315, 372, 390 Frequencies. Most notably the 310, 315 and 390 as the others are only on a couple configurations.
RFCrack Scanning:
Since the most used ranges are 310, 315, 390 within our universal clicker, lets set RFCrack scanner to rotate through those and scan for signals.If a number of cars go through the gate and there are no captures we can adjust the scanner later over our wifi connection from a distance.
Currently Scanning: 433000000 To cancel hit enter and wait a few seconds
Example of logging output:
From the above output you will see that a frequency was found on 390. However, if you had left this running for a few hours you could easily see all of the output in the log file located in your RFCrack/scanning_logs directory.For example the following captures were found in the log file in an easily parseable format:
Analyzing the signal to determine toggle switches:
Ok sweet, now we have a valid signal which will open the gate. Of course we could just replay this and open the gate, but we are going to create a physical device we can pass along to whoever needs entry regardless if they understand RF. No need to fumble around with a computer and look suspicious.Also replaying a signal with RFCrack is just to easy, nothing new to learn taking the easy route.
The first thing we are going to do is graph the capture and take a look at the wave pattern it creates. This can give us a lot of clues that might prove beneficial in figuring out the toggle switch pattern found in remotes. There are a few ways we can do this. If you don't have a yardstick at home you can capture the initial signal with your cheap RTL-SDR dongle as we did in the first RF blog. We could then open it in audacity. This signal is shown below.
Let RFCrack Plot the Signal For you:
The other option is let RFCrack help you out by taking a signal from the log output above and let RFCrack plot it for you.This saves time and allows you to use only one piece of hardware for all of the work.This can easily be done with the following command:
From the graph output we see 2 distinct crest lengths and some junk at either end we can throw away. These 2 unique crests correspond to our toggle switch positions of up/down giving us the following 2 possible scenarios using a 9 toggle switch remote based on the 9 crests above:
Possible toggle switch scenarios:
down down up up up down down down down
up up down down down up up up up
Configuring a remote:
Proper toggle switch configuration allows us to program a universal remote that sends a signal to the gate. However even with the proper toggle switch configuration the remote has many different signals it sends based on the manufacturer or type of signal.In order to figure out which configuration the gate is using without physically watching the gate open, we will rely on local signal analysis/comparison.
Programming a remote is done by clicking the device with the proper toggle switch configuration until the gate opens and the correct manufacturer is configured. Since we don't have access to the gate after capturing the initial signal we will instead compare each signal from he remote to the original captured signal.
Comparing Signals:
This can be done a few ways, one way is to use an RTLSDR and capture all of the presses followed by visually comparing the output in audacity. Instead I prefer to use one tool and automate this process with RFCrack so that on each click of the device we can compare a signal with the original capture. Since there are multiple signals sent with each click it will analyze all of them and provide a percent likelihood of match of all the signals in that click followed by a comparing the highest % match graph for visual confirmation. If you are seeing a 80-90% match you should have the correct signal match.
Note:Not every click will show output as some clicks will be on different frequencies, these don't matter since our recon confirmed the gate is communicating on 390Mhz.
In order to analyze the signals in real time you will need to open up your clicker and set the proper toggle switch settings followed by setting up a sniffer and live analysis with RFCrack:
Open up 2 terminals and use the following commands:
#Setup a sniffer on 390mhz Setup sniffer:python RFCrack.py -k -c -f 390000000.
#Monitor the log file, and provide the gates original signal Setup Analysis: python RFCrack.py -c -u 1f0fffe0fffc01ff803ff007fe0fffc1fff83fff07ffe0007c -n.
Cmd switches used
-k = known frequency
-c = compare mode
-f = frequency
-n = no yardstick needed for analysis
Make sure your remote is configured for one of the possible toggle configurations determined above. In the below example I am using the first configuration, any extra toggles left in the down position: (down down up up up down down down down)
Analyze Your Clicks:
Now with the two terminals open and running click the reset switch to the bottom left and hold till it flashes. Then keep clicking the left button and viewing the output in the sniffing analysis terminal which will provide the comparisons as graphs are loaded to validate the output.If you click the device and no output is seen, all that means is that the device is communicating on a frequency which we are not listening on.We don't care about those signals since they don't pertain to our target.
At around the 11th click you will see high likelihood of a match and a graph which is near identical. A few click outputs are shown below with the graph from the last output with a 97% match.It will always graph the highest percentage within a click.Sometimes there will be blank graphs when the data is wacky and doesn't work so well. This is fine since we don't care about wacky data.
You will notice the previous clicks did not show even close to a match, so its pretty easy to determine which is the right manufacture and setup for your target gate. Now just click the right hand button on the remote and it should be configured with the gates setup even though you are in another location setting up for your test.
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
----------Start Signals In Press--------------
Percent Chance of Match for press is: 0.05
Percent Chance of Match for press is: 0.14
Percent Chance of Match for press is: 0.14
Percent Chance of Match for press is: 0.12
----------End Signals In Press------------
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
----------Start Signals In Press--------------
Percent Chance of Match for press is: 0.14
Percent Chance of Match for press is: 0.20
Percent Chance of Match for press is: 0.19
Percent Chance of Match for press is: 0.25
----------End Signals In Press------------
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
----------Start Signals In Press--------------
Percent Chance of Match for press is: 0.93
Percent Chance of Match for press is: 0.93
Percent Chance of Match for press is: 0.97
Percent Chance of Match for press is: 0.90
Percent Chance of Match for press is: 0.88
Percent Chance of Match for press is: 0.44
----------End Signals In Press------------
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
Graph Comparison Output for 97% Match:
Conclusion:
You have now walked through successfully reversing a toggle switch remote for a security gate. You took a raw signal and created a working device using only a Yardstick and RFCrack.This was just a quick tutorial on leveraging the skillsets you gained in previous blogs in order to learn how to analyzeRF signals within embedded devices. There are many scenarios these same techniques could assist in.We also covered a few new features in RF crack regarding logging, graphing and comparing signals.These are just a few of the features which have been added since the initial release. For more info and other features check the wiki.
When we published our research on network printer security at the beginning of the year, one major point of criticism was that the tested printers models had been quite old. This is a legitimate argument. Most of the evaluated devices had been in use at our university for years and one may raise the question if new printers share the same weaknesses.
35 year old bugs features
The key point here is that we exploited PostScript and PJL interpreters. Both printer languages are ancient, de-facto standards and still supported by almost any laser printer out there. And as it seems, they are not going to disappear anytime soon. Recently, we got the chance to test a $2,799 HP PageWide Color Flow MFP 586 brand-new high-end printer. Like its various predecessors, the device was vulnerable to the following attacks:
Capture print jobs of other users if they used PostScript as a printer driver; This is done by first infecting the device with PostScript code
Manipulate printouts of other users (overlay graphics, introduce misspellings, etc.) by infecting the device with PostScript malware
List, read from and write to files on the printers file system with PostScript as well as PJL functions; limited to certain directories
Recover passwords for PostScript and PJL credentials; This is not an attack per se but the implementation makes brute-force rather easy
Launch denial of Service attacks of various kinds:
Note that the product was tested in the default configuration. To be fair, one has to say that the HP PageWide Color Flow MFP 586 allows strong, Kerberos based user authentication. The permission to print, and therefore to attack the device, can be be limited to certain employees, if configured correctly. The attacks can be easily reproduced using our PRET software. We informed HP's Software Security Response Team (SSRT) in February.
Conclusion: Christian Slater is right
PostScript and PJL based security weaknesses have been present in laser printers for decades. Both languages make no clear distinction between page description and printer control functionality. Using the very same channel for data (to be printed) and code (to control the device) makes printers insecure by design. Manufacturers however are hard to blame. When the languages were invented, printers used to be connected to a computer's parallel or serial port. No one probably thought about taking over a printer from the web (actually the WWW did not even exist, when PostScript was invented back in 1982). So, what to do? Cutting support for established and reliable languages like PostScript from one day to the next would break compatibility with existing printer drivers. As long as we have legacy languages, we need workarounds to mitigate the risks. Otherwise, "The Wolf" like scenarios can get very real in your office…
In general decompilers are not friendly with c++ let's analyse a simple program to get familiar with it. Let's implement a simple code that loads a file into a vector and then save the vector with following functions:
err
load
save
main
Lets identify the typical way in C++ to print to stdout with the operator "<<"
The basic_ostream is initialized writing the word "error" to the cout, and then the operator<< again to add the endl.
The Main function simply calls "vec = load(filename)" but the compiler modified it and passed the vector pointer as a parámeter. Then it bulds and prints "loaded " << size << " users". And finally saves the vector to /tmp/pwd and print "saved". Most of the mess is basically the operator "<<" to concat and print values. Also note that the vectors and strings are automatically deallocated when exit the function.
And here is the code:
Let's take a look to the load function, which iterates the ifs.getline() and push to the vector. First of all there is a mess on the function definition, __return_storage_ptr is the vector. the ifstream object ifs is initialized as a basic_ifstream and then operator! checks if it wasn't possible to open the file and in that case calls err() We see the memset and a loop, getline read a cstr like line from the file, and then is converted to a string before pushing it to the vector. lVar1 is the stack canary value.
In this situations dont obfuscate with the vector pointer vec initialization at the begining, in this case the logic is quite clear.
The function save is a bit more tricky, but it's no more than a vector iteration and ofs writing. Looping a simple "for (auto s : *vec)" in the decompiler is quite dense, but we can see clearly two write, the second write DAT_0010400b is a "\n"
As we see, save implememtation is quite straightforward.
How do I get started with bug bounty hunting? How do I improve my skills?
These are some simple steps that every bug bounty hunter can use to get started and improve their skills:
Learn to make it; then break it! A major chunk of the hacker's mindset consists of wanting to learn more. In order to really exploit issues and discover further potential vulnerabilities, hackers are encouraged to learn to build what they are targeting. By doing this, there is a greater likelihood that hacker will understand the component being targeted and where most issues appear. For example, when people ask me how to take over a sub-domain, I make sure they understand the Domain Name System (DNS) first and let them set up their own website to play around attempting to "claim" that domain.
Read books. Lots of books. One way to get better is by reading fellow hunters' and hackers' write-ups. Follow /r/netsec and Twitter for fantastic write-ups ranging from a variety of security-related topics that will not only motivate you but help you improve. For a list of good books to read, please refer to "What books should I read?".
Join discussions and ask questions. As you may be aware, the information security community is full of interesting discussions ranging from breaches to surveillance, and further. The bug bounty community consists of hunters, security analysts, and platform staff helping one and another get better at what they do. There are two very popular bug bounty forums: Bug Bounty Forum and Bug Bounty World.
Participate in open source projects; learn to code. Go to https://github.com/explore or https://gitlab.com/explore/projects and pick a project to contribute to. By doing so you will improve your general coding and communication skills. On top of that, read https://learnpythonthehardway.org/ and https://linuxjourney.com/.
Help others. If you can teach it, you have mastered it. Once you discover something new and believe others would benefit from learning about your discovery, publish a write-up about it. Not only will you help others, you will learn to really master the topic because you can actually explain it properly.
Smile when you get feedback and use it to your advantage. The bug bounty community is full of people wanting to help others so do not be surprised if someone gives you some constructive feedback about your work. Learn from your mistakes and in doing so use it to your advantage. I have a little physical notebook where I keep track of the little things that I learnt during the day and the feedback that people gave me.
Learn to approach a target. The first step when approaching a target is always going to be reconnaissance — preliminary gathering of information about the target. If the target is a web application, start by browsing around like a normal user and get to know the website's purpose. Then you can start enumerating endpoints such as sub-domains, ports and web paths.
A woodsman was once asked, "What would you do if you had just five minutes to chop down a tree?" He answered, "I would spend the first two and a half minutes sharpening my axe." As you progress, you will start to notice patterns and find yourself refining your hunting methodology. You will probably also start automating a lot of the repetitive tasks.
Yesterday, on the 3rd anniversary of the infamous global WannaCry ransomware outbreak for which North Korea was blamed, the U.S. government released information about three new malware strains used by state-sponsored North Korean hackers. Called COPPERHEDGE, TAINTEDSCRIBE, and PEBBLEDASH, the malware variants are capable of remote reconnaissance and exfiltration of sensitive information from
