TW Cell Phones

Tammy Worcester

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.

More info

Tammy Worcester

About EasySploit: EasySploit is Metasploit automation tool to use Metasploit Framework EASIER and FASTER than EVER.

EasySploit's options:

Windows --> test.exe (payload and listener)
Android --> test.apk (payload and listener)
Linux --> test.py (payload and listener)
MacOS --> test.jar (payload and listener)
Web --> test.php (payload and listener)
Scan if a target is vulnerable to ms17_010 (EnternalBlue)
Exploit Windows 7/2008 x64 ONLY by IP (ms17_010_eternalblue)
Exploit Windows Vista/XP/2000/2003 ONLY by IP (ms17_010_psexec)
Exploit Windows with a link (HTA Server)
Contact with me - My accounts

EasySploit's installation
You must install Metasploit Framework first.
For Arch Linux-based distros, enter this command: sudo pacman -S metasploit

For other Linux distros, enter these command to install Metasploit Framework: And then, enter these commands to install EasySploit:

How to use EasySploit? (EasySploit video series tutorials)

Disclaimer about EasySploit:

Usage of EASYSPLOIT for attacking targets without prior mutual consent is ILLEGAL. Developers are not responsible for any damage caused by this script. EASYSPLOIT is intented ONLY FOR EDUCATIONAL PURPOSES!!! STAY LEGAL!!!

You might like these similar tools:

You can support KALI LINUX TRICKS from Patreon.

Download EasySploit

Continue reading

Tammy Worcester

Some of you likely recall the talk back in 2016 or so of updating the OWASP Foundation website to not appear so much like a...well, a wiki. That talk was carried forward into 2017 and 2018 and, with each year, the proposal got pushed ahead as there were other, deeper projects to tackle. With the arrival of 2019 and a firm project plan under the guidance of Mike McCamon, Executive Director, we are finally moving toward a functioning, modern website that will be a whole lot less...wiki-like. The journey has been circuitous and, while we are not anywhere near complete, we have a set plan in place to bring it to fruition within the calendar year (second quarter of the year, actually).

TLDR: How Can You Help?

There are certainly ways in which you can get involved now. For instance, we are looking for a clean way to get wiki pages into GitHub markdown format for archival. I have done some work here but there are parsing issues with some of the tools. Do you know a good tool or have you done similar work? Also, are you or do you know a good designer, someone familiar with GitHub pages that can provide some useful help and feedback along the way? A Jekyll expert to help code a theme with a handful of templates would be a great addition. In addition, we could use website server admins who could help with assigning redirects to maintain search integrity. Finally, there will be a great many pages to move that we will also eventually need community involvement in.

So, What Have We Done?

Thus far we have researched various ideas for standing up a new site, including modifying the current wiki, spinning up our own web server, contracting a third party to host and build a new site, and also using existing infrastructure with our own content to launch a new face for OWASP. Our discussions led us to a familiar place, one that nearly every developer in the OWASP space is familiar with: GitHub.

In our conversations with GitHub, it became readily apparent that using the platform would be a win for the Foundation as well as GitHub. Nearly everyone who runs a project at OWASP (documentation or otherwise) uses GitHub. Because our target audience is also mostly developers we know that they are also very comfortable with the platform. And while GitHub has a number of high profile companies using their GitHub Pages, the use of the platform as the basis for the entire website of the number one non-profit foundation in the application security sector is a big draw.

We have run with that GitHub Pages idea and have spent internal manpower on a proof of concept. This proof of concept is less about the UX of the site than the functionality, the ability to utilize the authentication systems, and the ability to utilize automation to push out changes quickly.

Where Are We Now?

We are doing the final stages of website architecture. We are also planning what needs to be in the site, how the pieces will integrate with current projects and chapters, and how we might utilize the community to integrate the pieces so that we have a visually and functionally cohesive website that spans across multiple repositories.

What Is Next?

We will soon be looking for a modern website design that is responsive and clean. We will begin using the knowledge gained from our proof of concept to build out the internals of the website and then we will start implementing the highest traffic pages and administrative areas into the new platform. Once we have the big-ticket items moved we will start looking at what is left and moving over those pieces. The eventual goal would be to have a new, modern website for the future of OWASP while keeping the wiki as an archive of really useful information.

We hope you are as excited as we are about the future of the OWASP Foundation website and will join us as we move toward a modern web presence. If you have any questions or would like to volunteer your time, experience or knowledge, please contact me at harold.blankenship@owasp.com

TW Cell Phones

Monday, August 31, 2020

Reversing Rust String And Str Datatypes

Rust string data-types

Imports and functions

Main function

Source code

Dynamic analysis

More info

Sunday, August 30, 2020

EasySploit: A Metasploit Automation Bash Scripts To Use Metasploit Framework Easier And Faster Than Ever

Continue reading

OWASP Web 2.0 Project Update

TLDR: How Can You Help?

So, What Have We Done?

Where Are We Now?

What Is Next?

Read more

Followers

Blog Archive

About Me