• Keine Ergebnisse gefunden

Pybox - A python sandbox

N/A
N/A
Protected

Academic year: 2022

Aktie "Pybox - A python sandbox"

Copied!
12
0
0

Wird geladen.... (Jetzt Volltext ansehen)

Volltext

(1)

Universit¨at Mannheim Felix C. Freiling

Friedrich-Alexander-Universit¨at Erlangen-N¨urnberg

Abstract:The application of dynamic malware analysis in order to automate the mo- nitoring of malware behavior has become increasingly important. For this purpose, so-calledsandboxesare used. They provide the functionality to execute malware in a secure, controlled environment and observe its activities during runtime. While a va- riety of sandbox software, such as the GFI Sandbox (formerly CWSandbox) or the Joe Sandbox, is available, most solutions are closed-source. We present the design, im- plementation and evaluation of PyBox, a flexible and open-source sandbox written in Python. The application of a Python based analysis environment offers the opportunity of performing malware analyses on various operating systems as Python is available for almost every existing platform.

1 Introduction

The growing amount, variety, and complexity of malicious software (malware) poses ma- jor challenges for today’s IT security specialists. It is often necessary to analyze different types of malware in order to understand and assess the resulting threats. However, since manual reverse engineering is time consuming,dynamic malware analysishas become a standard analysis approach in practice. In a dynamic analysis, malware is executed in a controlled environment and all actions during runtime such as changes in the registry or access to the network are recorded. A log file provides the analyst with a first and often sufficient overview over the basic functionality of the malware.

1.1 Related Work

Several sandbox solutions have been developed for Windows systems in the past. CW- Sandbox [WHF07] is a widely used sandbox tool which is now commercially available under the name “GFI Sandbox” [Sof]. While it is possible to use the sandbox over a web interface as part of a research project [Fri], the sandbox software itself is closed source.

The basic idea of CWSandbox is to “hook” specific Windows API calls, i.e., to divert

Contact author. Address: Am Wolfsmantel 46, 91058 Erlangen, Germany.

(2)

control flow into own code in user mode before executing the original API call.

A tool similar to CWSandbox isJoe Sandbox [joe11]. The primary difference to CW- Sandbox lies in the way how malware is observed. While CWSandbox applies user-mode hooking, the behavior engine of Joe Sandbox is implemented as a Windows driver and therefore runs in kernel mode. So in addition to being able to monitor malware running in kernel mode, it is also much more difficult for malware to detect the analysis environment.

Still, Joe Sandbox is also a commercial closed-source system.

While not being commercial, Anubis (formerly known as TTAnalyze) [BMKK06] is a sandbox system for research. However, Anubis is not open-source and can only be acces- sed through a web frontend1.

Leder and Plohmann [LP10] developed a user-mode sandbox which is open-source [PL].

The idea of their system is to inject an entire Python interpreter into the process to be monitored. The monitoring functionality is then provided through external Python scripts.

In contrast to CWSandbox, this provides more flexibility and a higher degree of configu- rability. The major drawback of this approach is the severe performance overhead that is introduced.

Another open-source sandbox solution isCuckoo[Cla10], which is developed by the Ho- neynet Project. Cuckoo is a complete and therefore also rather complex framework for malware analysis including control of virtual machines to execute malicious software on.

1.2 Contribution

In this paper, we describe the design and implementation of an open-source sandbox called PyBox(Python Sandbox). PyBox combines ideas from existing sandbox systems to create a unique and expandable tool for automated malware analysis:

PyBox implements user-mode API hooking to monitor the behavior of executed software, i.e., it injects adynamic-link library(DLL) into created processes in order to intercept API calls and the according arguments.

PyBox allows execution control (resume, abort) during runtime.

PyBox itself uses a programming interface based on Python for improved flexibility.

The main novelty of PyBox compared to existing sandboxes is the fact that it is open source as well as its flexibility. While comparable closed source software may work well in business environments, PyBox as an open source product targets to be used in research as a building block for new malware analysis tools in the future. This way, researchers can extend PyBox’s functionality and build customized solutions for their special analysis targets or work together to create a more powerful and portable analysis tool. The required flexibility is achieved by using Python as programming language for the analysis tool.

Due to its easy to understand syntax Python is widely used and available for almost every

1Seehttp://anubis.iseclab.org/.

(3)

platform. Therefore, the interface can be used to analyze targets on various systems by providing the respective hook libraries. Python also offers the required low-level support to interact with operating systems as well as integration with the used virtualization software.

All this renders Python a perfect choice for our analysis tool. PyBox can be downloaded from the PyBox homepage [pyb].

After giving a short background on the techniques used by PyBox in Section 2, we briefly describe the design requirements of PyBox in Section 3. We give an overview of the im- plementation in Section 4 and present a brief functional evaluation in Section 5. Section 6 concludes the paper.

2 Background

This section provides some general background on techniques used by PyBox.

2.1 Inline API Hooking

Hooking is a concept used to gain control of a program’s execution flow without chan- ging and recompiling its source code. This is achieved by intercepting function calls and redirecting them to infiltrated customized code.

PyBox implements so-calledinline API hooking[HB08, Eng07] to monitor software be- havior. The complete process is displayed in Figure 1. Inline hooks directly overwrite the function’s code bytes in memory. In particular, only the first few instructions are replaced with a five byte jump instruction to the actual hook function. The replaced instructions are stored in thetrampoline function, which is used as a new entry point to the original API call. Within the hook function the logging of information or modification of arguments can take place before the original API function is executed.

2.2 DLL Injection

In order to make use of hooked API functions within the process space of the software that we want to analyze, we first need to inject code into the target process. The mecha- nism we apply for this purpose is calledDLL injection. We instrument the API functions CreateRemoteThreadandLoadLibrarythat enable us to create a new thread in the target process and load a DLL file which in turn installs the hook functions.

(4)

Abbildung 1: Inline hooking [Eng07, p. 33]

3 Design of PyBox

The PyBox analysis environment consists of three major parts: a virtual machine, the ana- lysis toolPyBox.py, and the hook librarypbMonitor.dll. Each is described in more detail in the following paragraphs. A schematic overview of the different parts of PyBox and their interaction is displayed in Figure 2.

Virtual Machine. Using a virtual machine as a basis for malware analysis guarantees a secure and controlled environment in which the malware can be executed and the original system state can be restored afterwards. Inside the virtual machine we can observe system activity of a certain target software during runtime.

Analysis Tool. The analysis tool, calledPyBox.py, acts as the hook server. The hook server is responsible for setup adjustments according to the settings defined in the con- figuration files, target process creation, and hook library injection. During the execution of malicious software, it also receives and processes the log data from the hooked API functions and in the end generates a final behavior report.

Hook Library. The hook librarypbMonitor.dllimplements the actual hooking and monitoring functionality. It is responsible for installing the specified hooks, monitoring the system calls, and creating log entries, which are then sent to the hook server. Therefore, the hook library and the hook server have to interact with each other very closely by means ofinter-process communication(IPC). This way information exchange between the two processes is straightforward.

The hook librarypbMonitor.dllis the only component implemented inVisual C++.

(5)

Abbildung 2: Schematic overview of PyBox analysis process

In this case we have chosen C++ as programming language because Python cannot create DLL files and we have to make much use of various API functions provided by Windows.

This requires the use of specific C data structures and is therefore more comfortable to program in C++.

4 Implementation Excerpts

Describing the complete implementation of PyBox would be out of the scope of this paper.

We therefore focus on a few details only. For more information see Sch¨onbein [Sch11].

4.1 Callbacks and Trampolines

The callback function allows us to execute our own customized code within the address space of the target process. Hence, we implement the monitoring functionality here and send the resulting data to the PyBox analysis tool.

r e t u r n t y p e c a l l i n g c o n v e n t i o n c a l l b a c k f u n c t i o n ( arg1 , . . . , argn ) { r e t u r n t y p e s t a t u s ;

i n f o = o b t a i n i f o r m a t i o n ( arg1 , . . . , argn ) ; i f ( p r e v e n t e x e c u t i o n == f a l s e)

{ s t a t u s = t r a m p o l i n e f u n c t i o n ( arg1 , . . . , argn ) ; }

(6)

e l s e

{ s t a t u s = c u s t o m i z e d r e t u r n v a l u e ; }c r e a t e l o g e n t r y ( i n f o ) ;

return s t a t u s ; }

Listing 1: Callback function structure

The basic structure of such a callback function is depicted in Listing 1. The variables namedprevent executionandcustomized return valuerepresent settings that have been specified by the user beforehand. The value ofprevent execution determines whether or not the trampoline function is called in order to execute the original API function. In case it is not called, a custom value is returned. Finally, the function create log entrynotifies the analysis environment about the API function that was executed and the arguments that were used.

In order to describe the usage of callback functions in more detail, we present the imple- mentation of a sample callback function in the following. The functionNtCreateFile2 is provided by the native API. It is usually called in order to create a new file or to open an existing one. The interface requires eleven arguments that all have to be passed for a function call. The most important ones are described in the following:

FileHandleis a pointer to a file handle corresponding to the created or opened file after the function has been executed.

DesiredAccessdefines the requested access rights concerning the file.

ObjectAttributesis a pointer to a structure containing information about the requested file such as the file name and its path.

AllocationSizeis an optional pointer to the size of the initial allocation in case a file is created or overwritten. This pointer can also be NULL implying that no allocation size is specified.

FileAttributescontains flags specifying the file’s attributes. Such attributes can for example mark a file as read-only or hidden.

The corresponding callback function is shown in Listing 2.

16 NTSTATUS NTAPI N t C r e a t e F i l e c a l l b a c k (

17 o u t PHANDLE FileHandle ,

18 i n ACCESS MASK DesiredAccess ,

19 i n POBJECT ATTRIBUTES O b j e c t A t t r i b u t e s ,

20 o u t PIO STATUS BLOCK I o S t a t u s B l o c k ,

21 i n o p t PLARGE INTEGER A l l o c a t i o n S i z e ,

22 i n ULONG F i l e A t t r i b u t e s ,

23 i n ULONG ShareAccess ,

24 i n ULONG C r e a t e D i s p o s i t i o n ,

25 i n ULONG C r e a t e O p t i o n s ,

26 i n o p t PVOID EaBuffer ,

2http://msdn.microsoft.com/en-us/library/ff566424(v=vs.85).aspx

(7)

27 i n ULONG EaLength

28 )

29 {

30 NTSTATUS s t a t u s ;

31 . . .

57 i f ( h o o k s e t t i n g s [ 0 ] . p r e v e n t E x e c u t i o n == FALSE)

58 {

59 / / C a l l t r a m p o l i n e f u n c t i o n

60 s t a t u s = N t C r e a t e F i l e t r a m p o l i n e ( F ile Han dle , DesiredAccess ,

O b j e c t A t t r i b u t e s , I o S t a t u s B l o c k , A l l o c a t i o n S i z e , F i l e A t t r i b u t e s , ShareAccess , C r e a t e D i s p o s i t i o n , C r e a t e O p t i o n s , EaBuffer , EaLength ) ;

61 e x e c u t e d = 1 ;

62 }

63 e l s e

64 {

65 / / Get c u s t o m i z e d r e t u r n v a l u e

66 s t a t u s = (NTSTATUS) h o o k s e t t i n g s [ 0 ] . r e t u r n V a l u e ;

67 }

68

69 / / Create log e n t r y and r e t u r n

70 SOCKET ADDRESS INFO s a i = {0};

71 c r e a t e L o g ( 0 , o b j e c t , L” ” , ” ” , executed , DesiredAccess , F i l e A t t r i b u t e s , ShareAccess , C r e a t e D i s p o s i t i o n , C r e a t e O p t i o n s , s a i , s t a t u s ) ;

72 return s t a t u s ;

73 }

Listing 2: TheNtCreateFilecallback function

As soon as all required information is gathered, it is determined whether the original API is to call as well, or if a predefined value should be returned. This check is implemented in line 57. Finally, the callback function returns the value ofstatus(line 72) to the object that has called the API function.

An important piece of information that is passed to the createLog function in li- ne 71, is the file path of the target file associated with the API call. All informati- on concerning the target file of aNtCreateFile call can be found in the argument ObjectAttributes. This structure contains the two fields providing the information we are looking for:RootDirectoryandObjectName. In order to obtain the comple- te path to a target file, we simply have to combine these two parts. The resulting string is stored in the variableobjectand finally used to create the associated log entry.

4.2 Detection Prevention

More recent malware samples implement methods to inspect the system environment they are executed in, to detect analysis software. Since we do not want malware to behave differently than on a usual personal computer, we need to avoid easy detection of the PyBox analysis environment.

Possible techniques applied by malware in order to examine the system are to list all run- ning processes or to scan the file system. Often, certain API functions are applied in order to implement the required detection techniques. In PyBox, we consider two different me- thods. The first method is to use the API functionCreateToolhelp32Snapshotin

(8)

order to create a snapshot containing a list of all running processes and to parse this list using the API functionsProcess32FirstandProcess32Next. The second method considered is to use the API functionsFindFirstFileandFindNextFilein order to scan the filesystem.

We use the the hooking functionality to intercept these API functions and successfully hide files and processes of PyBox. If an object returned by one of the above mentioned API functions belongs to the analysis framework, the corresponding trampoline function will be called again until it returns an object which does not belong to the analysis framework or until there is no more object left in the list to be queried. In this way, PyBox is basically invisible to other processes of the analysis system, in particular to the examined target process, too.

4.3 PyBox Analysis Tool

The PyBox analysis tool is the interface between the hook library and the analyst. It ena- bles the following tasks: configuration management, process creation, library injection, data processing, and report generation.

Abbildung 3: PyBox analysis tool layout

In order to fulfil these tasks, PyBox includes various packages, modules and configuration files, as illustrated in Figure 3.

In the upper part of Figure 3, the five packages belonging to the PyBox analysis tool are de- picted. The packagesetupis responsible for reading the provided configuration files and for extracting their information. Furthermore, it converts this information into objects that can be used by the analysis tool. The packageprocessallows to execute process-related operations such as the creation of the target process. Additionally, it provides required process-specific information. The DLL injection method is implemented in the package injection. The final report generation operations are made available by the package report. More precisely, it offers the functionality to process the data received from the monitored process and turn them into a XML-based report. The communication and inter-

(9)

action with the target process is implemented in the packageipc.

The lower part of Figure 3 displays the two configuration files namedpybox.cfgand hooks.cfg. The filepybox.cfgdefines settings that are required by the analysis fra- mework to work. In particular it contains the path to the hook library, which is injected into the target process. In contrast, the filehooks.cfginfluences the execution of the hook library inside the target process. More specifically, it defines which hooks to install and, thus, which API functions to monitor.

During the start of the execution ofPyBox.py, all hooks are read and mapped to an array of C data structures that are present both in the PyBox main application and the hook library. Each hook has a specific identification number by which it can be identified. Once the array is created out of the configuration file, the hook library can obtain the array and install all specified hooks. More details about logging and the generation of the the XML report can be found in Sch¨onbein [Sch11].

5 Evaluation

In order to test the functionality of PyBox, we have tested the analysis environment ex- amining different malware samples. Due to space restrictions, in this section, we present only one example. More examples can be found in Sch¨onbein [Sch11].

The malware sample analyzed here can be categorized as back door, trojan horse, or bot.

Its common name is “Backdoor.Knocker”. Information about this threat is provided by VirusTotal [Vir], Prevx [Pre], and ThreatExpert [Thr]. ThreatExpert refers to it asBack- door.Knocker. Its purpose is to frequently send information such as the IP address or open ports of the infected system to its home server.

During the analysis run of this sample it did not come to an end. Therefore, the analysis process terminated the target process after the specified time-out interval of two minutes.

227<N t C r e a t e F i l e C r e a t e D i s p o s i t i o n =”0 x00000005 ” C r e a t e O p t i o n s =”0 x00000064 ”

D e s i r e d A c c e s s =”0 x40110080 ” Executed =”YES” F i l e A t t r i b u t e s =”0 x00000020 ” O b j e c t =” C:\WINDOWS\system32\c s s r s s . exe ” ReturnValue =”0 x00000000 ” ShareAccess =”0 x00000000 ” Timestamp=” 3115 ” />

228<N t W r i t e F i l e Executed =”YES” Length=” 20928 ” O b j e c t =”WINDOWS\system32\

c s s r s s . exe ” ReturnValue =”0 x00000000 ” Timestamp=” 3116 ” />

Listing 3: Extract from the file management section of the malware sample’s analysis report The first interesting aspect of the behavior report is in line 227 of Listing 3. The file section documents that the target process has created a file in the Windows system folder and written data to it. The file has been named cssrss.exe. These entries also indicate malicious behavior as the file name is very similar to the file name csrss.exe. The latter is the executable of theClient Server Run-Time Subsystem(CSRSS), which is an important part of the Windows operating system. It seems that the analyzed object is named similar to a system process to hide its presence.

(10)

1211 <NtOpenKey D e s i r e d A c c e s s =”0 x00000002 ” Executed =”YES” O b j e c t =”REGISTRY\

MACHINE\SYSTEM\C o n t r o l S e t 0 0 1\S e r v i c e s\SharedAccess\P a r a m e t e r s\ F i r e w a l l P o l i c y\S t a n d a r d P r o f i l e ” ReturnValue =”0 x00000000 ” Timestamp

=” 3121 ” />

1212 <NtSetValueKey D e s i r e d A c c e s s =”0 x00000000 ” Executed =”YES” O b j e c t =”

REGISTRY\MACHINE\SYSTEM\C o n t r o l S e t 0 0 1\S e r v i c e s\SharedAccess\ P a r a m e t e r s\F i r e w a l l P o l i c y\S t a n d a r d P r o f i l e ” ReturnValue =”0 x00000000

” Timestamp=” 3121 ” ValueName=” E n a b l e F i r e w a l l ” ValueType=”4” />

1213 <NtOpenKey D e s i r e d A c c e s s =”0 x00000002 ” Executed =”YES” O b j e c t =”REGISTRY\

MACHINE\SYSTEM\C o n t r o l S e t 0 0 1\S e r v i c e s\SharedAccess\P a r a m e t e r s\ F i r e w a l l P o l i c y\S t a n d a r d P r o f i l e\A u t h o r i z e d A p p l i c a t i o n s\L i s t ” ReturnValue =”0 x00000000 ” Timestamp=” 3121 ” />

1214 <NtSetValueKey D e s i r e d A c c e s s =”0 x00000000 ” Executed =”YES” O b j e c t =”

REGISTRY\MACHINE\SYSTEM\C o n t r o l S e t 0 0 1\S e r v i c e s\SharedAccess\ P a r a m e t e r s\F i r e w a l l P o l i c y\S t a n d a r d P r o f i l e\A u t h o r i z e d A p p l i c a t i o n s\ L i s t ” ReturnValue =”0 x00000000 ” Timestamp=” 3122 ” ValueName=” b i n a r y ”

ValueType=”1” />

Listing 4: Extract from the registry section of the malware sample’s analysis report The behavior report’s registry section also contains many entries, which have to be con- sidered. The process queries various information about system and network services as well as about the operating system such as the system’s version. One particularly noticea- ble part of the registry section is depicted in Listing 4. The report reveals that the target process uses registry API functions to change the valueEnableFirewall(line 1212) and furthermore to add its executable file to the list of authorized applications (line 1214).

These entries are clear evidence that the application tries to disable security mechanisms and thus performs malicious behavior unwanted by the system’s user.

6 Conclusion and Future Work

Given the available commercial dynamic analysis tools on the market, PyBox is the first publicly available open-source tool which written in a flexible and platform independent programming language. This allows PyBox to be easily improved in many ways.

In PyBox we currently only hook native API functions to monitor the behavior of malware samples. But different Windows versions often use very different native API functions.

Therefore, the hook library has to be extended in order to provide compatibility with va- rious Windows versions.

An approach for extending the functionality of PyBox is to add further hooks to the analy- sis framework in order to monitor more types of activity. Furthermore, the analysis tool’s report generation can be extended by mapping provided numeric values such as file crea- tion flags to strings that describe the meaning of the activated flags in order to simplify the interpretation of the report. A third approach is to implement a hook library for other operating systems such as Android and thus provide the opportunity to analyze malware samples designed to attack mobile devices. In order to provide more flexibility and exten-

(11)

dibility for malware analyses we could incorporate the functionality of a C compiler. We could use a special Python script and create the hook library’s code out of existing code fragments according to the configured settings specified by the analyst. Thus, we would implement a modular solution that automatically compiles a separate, customized hook library that can be injected into the remote process to be monitored. In doing so, we would have a more flexible solution, which also considers the performance criterion.

Literatur

[BMKK06] Ulrich Bayer, Andreas Moser, Christopher Kr¨ugel und Engin Kirda. Dynamic Analysis of Malicious Code.Journal in Computer Virology, 2(1):67–77, 2006.

[Cla10] Claudio Guarnieri and Dario Fernandes. Cuckoo - Automated Malware Analysis Sys- tem.http://www.cuckoobox.org/, February 2010.

[Eng07] Markus Engelberth. APIoskop: API-Hooking for Intrusion Detec- tion. Diplomarbeit, RWTH Aachen, September 2007. http:

//www1.informatik.uni-erlangen.de/filepool/thesis/

diplomarbeit-2007-engelberth.pdf.

[Fri] Friedrich-Alexander University Erlangen-Nuremberg. Malware Analysis System.

http://mwanalysis.org. Retrieved November 2011.

[HB08] Greg Hoglund und James Butler.Rootkits : Subverting the Windows Kernel. Addison- Wesley, 6. edition, 2008.

[joe11] How does Joe Sandbox work?, 2011. http://www.joesecurity.org/

products.php?index=3, Retrieved May 2011.

[LP10] Felix Leder und Daniel Plohmann. PyBox — A Python approach to sandboxing. In Sebastian Schmerl und Simon Hunke, Hrsg.,Proceedings of the Fifth GI SIG SIDAR Graduate Workshop on Reactive Security (SPRING), Seite 4. University of Bonn, Juli 2010. https://eldorado.tu-dortmund.de/bitstream/2003/27336/

1/BookOfAbstracts_Spring5_2010.pdf.

[PL] Daniel Plohmann und Felix Leder. pyboxed — A user-level framework for rootkit-like monitoring of processes.http://code.google.com/p/pyboxed/. Retrieved November 2011.

[Pre] Prevx. Cssrss.exe. http://info.prevx.com/aboutprogramtext.asp?

PX5=3E583C9DC0F87CBE51EE002CBE6AE800476D2E00, Retrieved April 2011.

[pyb] PyBox – A Python Sandbox. http://www1.informatik.uni-erlangen.

de/content/pybox-python-sandbox. Retrieved November 2011.

[Sch11] Christian Sch¨onbein. PyBox - A Python Sandbox. Diploma Thesis, University of Mannheim, May 2011. http://www1.informatik.uni-erlangen.de/

filepool/thesis/diplomarbeit-2011-schoenbein.pdf.

[Sei09] Justin Seitz. Gray Hat Python: Python Programming for Hackers and Reverse Engi- neers. No Starch Press, San Francisco, CA, USA, 2009.

(12)

[Sof] GFI Software. Malware Analysis with GFI SandBox (formerly CWSandbox).http:

//www.gfi.com/malware-analysis-tool. Retrieved November 2011.

[Thr] ThreatExpert. ThreatExpert Report: Trojan.Flush.G, Hacktool.Rootkit, Downloader- BIU.sys. http://www.threatexpert.com/report.aspx?md5=

3cdb8dc27af1739121b1385f36c40ce9, Retrieved April 2011.

[Vir] VirusTotal. http://www.virustotal.com/file-scan/report.html?

id=9e9efb4321ffe9ce9483dc32c37323bada352e2dccc179fcf4ba66 dba99fdebf-1233827064, Retrieved April 2011.

[WHF07] Carsten Willems, Thorsten Holz und Felix Freiling. Toward Automated Dynamic Mal- ware Analysis Using CWSandbox.IEEE Security and Privacy, 5:32–39, 2007.

Referenzen

ÄHNLICHE DOKUMENTE

Wählt man hier die neueste Android Version, so können alle neuen Features verwendet werden, aber die Applikation läuft nicht mehr auf Geräten, auf wel- chen eine

Durch Verwendung dieser API für die Zugriffe auf die Signaturkarten kann eine Anwendung ohne Berücksichtigung der Unterschiede der verschiedenen Signaturkarten entwickelt werden,

• Processors (e.g. Learners) can provide anytime services. • Implemented as

Auslaufphase wird selbständig geritten und gehört nicht zur Aufgabenstellung. Das Ausführen der Aufgabenstellung geschieht mit dem eigenen Pferd. Die Aufgabenstellung wird einzeln

B) Standard MFC-DLL mit statischer Bindung (nicht in Standard Edition) MFC-Bibliothek ist Teil der DLL, C- Schnittstelle}. C) Standard MFC-DLL mit dynamischer Bindung,

Viene inoltre illustrata la cronologia dell’attività di rac- colta dei principali tipi di polline da parte delle api e dunque il periodo di fioritura delle prin- cipali

In Kooperation mit der Staats- und Universitätsbibliothek Hamburg entstand die studentische Open-Access-Zeitschrift „API Magazin“, welche Studierenden, Lehrenden und

Just like there is a difference between describing a house and describing a Universe, there is a difference between writing a code and producing an API..?. What is