Author: AaLl86

Hello there!
It has been a very long time since I last updated this blog (at least 3 years or more). Since my last post a lot of things have happened, which I summarize here:

• On January 2018 I moved to Seattle (WA), from Italy, with the idea to work in the Windows Kernel Core team. Furthermore, I officially started a very ambitious project with Alex Ionescu: being one of the main author of the new Windows Internals book. A part of the huge cultural difference between Seattle and Milano (and, trust in me, adapting to the new culture was really hard for me), my life was proceding well, split between the 2 places (I miss home a lot)…
• Around June 2019, my team split and I got promoted to Senior Core OS Engineer on the brand-new ™ Security Core Team, where I got the main responsibility on a component of Windows called Secure Kernel (a lot of my readers know what it is XD).
• In the meantime, the work on the book was proceeding pretty slow, due to some problems not directly related to me (which I do not want to talk about here). Furthermore, multiple articles, and, before Covid, a couple of conferences talks have been release by myself, especially on Retpoline, Import Optimization, HotPatch and KDP….

Well, after three (reeeallyy 3) long years of work (in such a lot of looong nights) we are super excited to announce that in a non-precise day between the 15th and 21st of September 2021, the new Windows Internals book (7th Edition Part 2) will be finally available in its paper copy.

Never in my life I have been part of such-an-ambitious project: a lot of sections have been rewritten, others have been fully updated, and a brand-new chapter has been designed, all targeting Windows 10 21H1 and the new incoming Windows 11 kernel. I am so proud that we were able to include the following important new content:

• Hardware side-channel vulnerabilities (which, some of them I took forever to fully understand), a completely brand-new WoW64 (including x86 on ARM64), WNF and Packaged applications, all part of Chapter 8
• A new chapter about the Hypervisor, Virtualization stack and Virtualization-based security (VBS). I’ve personally written this chapter. It includes nitty-gritty details (never discussed before) on how the Hypervisor and Secure Kernel internally work.
• The Windows registry and Windows services sections have been fully updated to include new concepts directly related to Windows 10, like the registry hive reorganization, virtualization, user and packaged services and so on. Chapter 10 includes also a rewritten section on UBPM, ETW (rewritten from scratch) and, last but not least, DTrace (which has been proven to be a super-powerful tool for tracing).
• Chapter 11 includes a brand-new section on the resilient file system (ReFS). Furthermore the new features of NTFS (since Windows 7) have been all introduced and described in details (like the online check-disk). Not to mention an introduction on the next generation low-level storage solution, Spaces.
• Lastly, also Chapter 12 has been completely rewritten. In the year 2021 there was no way that we would have release a section regarding the old BIOS systems. Melancholy readers should still read the old edition :-).

You can order your copy on the official Microsoft Press website (link), or, of course, on Amazon (link) 🙂

I want to say a big “Thank you” to all the people that helped me in this big journey, internal to Microsoft and even external. Thanks also to Mark Russinovich for having written the Foreward. And, of course, thanks also to Alex for including me in this big project. I hope that you guys enjoy it!

On a side note, the next month my company created the Giving Month, a month where all people are encouraged to give something to charity. Microsoft will match the donation, with the goal to help people that are less fortunate than us. I was thinking to collect all the signatures of the Windows’ developers, put them in a copy of the book, and sell it on Ebay as a unique and original piece. Finally, donate the earns coming from the sell to Cancer research. I am asking to the readers…. is this something that caught your interest? Which, rephrased, mean… would you like to put an offer on it if the idea goes through? (I still need to discuss it)

ps. I still need to buy a certificate for the website and pass some time to find a decent theme for it. If someone is willing to help please contact me 🙂

Hello folks!

Long time no updating my blog.
The work, book, and a minimum of social life are killing my free time 🙂

So, here we go…
… on last 17th June 2018 I gave a talk at the BSides Conference in my own city, Milano.
It was really nice to return back home, see my family and friends, even if for a small amount of time.

The talk was about Intel TXT, aka Trusted Execution Technology, that Intel has implemented in his own CPUs.
Windows uses Intel TXT for 3 reasons:

• Providing the auto-unlocking of the encrypted Bitlocker boot drive
• Measured Boot
• Windows Defender System Guard (aka the Trusted Boot implementation in Windows)

The entire presentation is available here:
https://www.andrea-allievi.com/files/Intel_Txt_Windows_BSides_2018.ppsx

The presentation is for a technical audience, so I was expecting some basic knowledge about OSs. After the conference, I have received some advises (of course well accepted) saying that I’ve put too many details in the slides. I would love to hear from the readers what they think about…
In the meantime I am restarting with a new Book’s Chapter, and preparing an interesting presentation for the new BlueHat edition.

So, as usually, stay tuned! 🙂

Andrea

Hi All!
 
It has been a long time since I have not updated this blog.
As usual a lot of things are going on, and the free time is always very tight 🙂
Today I just want to share with my readers the results of my reverse engineering work that I did on HyperV and I have presented in the last edition of the Recon Conference in Montreal.
This edition (May 2017) was quite good, with some interesting talks. We had some good time there, and I have even learnt something.

I presented a talk named “The HyperV Architecture and its Memory Manager”. Apart of my damn English accent, I think that I had some good feedback about the technical level of the talk. I would like to share here the slides:

www.andrea-allievi.com/files/Recon_2017_Montreal_HyperV_public.pptx

I take the occasion even to say that our Intel Processor Driver has been improved. Now it fully supports HyperV Root partitions (this was my demo in the Conference) and runs quite good.
I do not know if I can publish the new source code (I need an approval before), but at the time of this writing I have published the compiled code into our GitHub repository.

https://github.com/intelpt/WindowsIntelPT/tree/master/Compiled_IntelPt

Richard has pinpointed to me some bugs of the IDA plugin and on the driver. I have even improved those.

Few days ago, our friend Alex (@aionescu), has suggested me an interesting reading:
www.cyberark.com/threat-research-blog/ghosthook-bypassing-patchguard-processor-trace-based-hooking/

Basically these guys have done a smart hack with Intel PT, filling a Topa table almost entirely, and setting the Trace by IP…
I am still trying this technique, but potentially it should work. I have only some concern about the timing in which the PMI interrupt will be delivered (this is why it is not considered a threat).
According to the Intel Manual indeed: “This interrupt is not precise, and it is thus likely that writes to the next region will occur by the time the interrupt is taken”

Long story short: Some other tests are needed.

Like a bonus content I would like to show a funny fact:

Am I perhaps saying that someone is copying something from someone else? Of course not. This method have been idealized by Cyberark, and uses a “side effect” of the PT PMI Interrupt. The method is original and belongs to them, … but at least THERE IS SOMETHING that is common.

Stay tuned!
Cheers,
Andrea

ps. Again I say that this is my personal blog. I would like to precise that all the impressions, thoughts and information contained here are mine, and not official company statements.

In this week I have flew home, after spending few weeks in Seattle for the Blue Hat and some meeting with the team (and even for some fun in the night, I admit 😉 ). For whoever doesn’t know, starting from the September 2016 I am a Security Researcher of the Threat Intelligence Center of Microsoft Ltd (MSTIC).

BlueHat was great. Me and my friend Richard Johnson (@richinseattle) have presented a talk regarding our last research work about the Intel Processor Trace. I have idealized, tested and developed the first Windows PT driver, and he has researched the way to use the driver in his high-speed fuzzer project (FuzzFlow).

At the time of this writing, the driver is stable and works well (much more than I expected). You can find it in the Repository built by Rich:

https://github.com/talos-vulndev/TalosIntelPtDriver

 We have received tons of comments and questions regarding our work. Here I would like to clarify some of these.
 

 Question 1. Is the technology ready to trace Kernel Mode code?

The answer is Yes, even though at the time of the presentation I have not inserted this feature directly in the driver’s code, with some simple modifications you could be able to trace Kernel Mode code, Hypervisor and even SMM.

Last week I had passed something like 17 hours in 2 flights from Seattle to Milano (my native city) and, due to the fact that I didn’t know how to stay calm, I have decided to start the implementation of a new version of the driver with a complete support for kernel mode tracing.

The usage is quite simple:

1. Import the “TalosIntelPtDriver.lib” and “KernelTracing.h” files in your kernel mode driver project (I have not any kind of wish to explain how)
2. Allocate the needed buffer descriptor using IntelPtAllocBuffer function:

NTSTATUS IntelPtAllocBuffer(PPT_BUFFER_DESCRIPTOR * pBuffDesc, QWORD qwSize, BOOLEAN bUseTopa, BOOLEAN bSetStdPmi = TRUE);

3. Allocate and fill a PT_TRACE_DESC structure with the needed parameters for tracing
4. Start the tracing in the current execution processor using the IntelPtStartTracing routine:

NTSTATUS IntelPtStartTracing(PT_TRACE_DESC traceDesc, PT_BUFFER_DESCRIPTOR * pBuffDesc);

5. Run the kernel code that you prefer (always in the same processor that has called the IntelPtStartTracing routine) and when finished, call IntelPtStopTrace function
6. Free any allocated buffer using IntelPtFreeBuffer

 
Using these 6 steps, and a trick, I was able to do 2 cool things:

1. Get a full trace of a test driver.

How? It was not easy. Using the proper Structure Exception Handlers, I was able to insert a special “bad-opcode” byte in the beginning of the target driver’s entry point. I caught the exception from the monitoring driver, started the Processor Trace, modified the bad opcode and resumed the execution. In this way, I succeeded in tracing a full-blown driver initialization and unload functions.

Of course, you have to design some simple kernel code to dump the PT binary buffer in a file, but this is a very-easy task 🙂

2. Get a full trace of an “already-loaded” kernel module.

Easier than the previous case but much more time-consuming. Indeed, I passed the following few days in Cheltenham implementing the Kernel tracing support from User-mode. After succeeded in modifying the driver architecture (very long task), I simply created a big buffer, grabbed the target module start and end address, and started PT using the “tracing by IP” modality and the new Kernel Tracing feature.

Feeding the buffer to my IDA plugin yields interesting and cool results (My IDA plugin is doing his job greatly, even if I still continue to hate Python 🙂 ) :

 

As said, I have even inserted in the user-mode code, the possibility to trace kernel mode software, even if I think that it could be a security flaw. Someone has tried to convince me that, if the user is an Administrator, it could be allowed to trace kernel-mode code. What do you think? I will appreciate if the readers could tell me what do they think.
 

Question 2. Does Microsoft plan to implement Intel PT in Windows 10?

I really have no idea. I am still too new and usually I can’t reveal this kind of information without an explicit permission. The only thing that I know is that I will love to work with Skywing, Skape or some Kernel guys to implement this inside the Windows OS.
 

Question 3. Do you guys plan to release the Slides and the IDA plugin?

While the driver code is already online (still not the one with Kernel Mode support, I was working on the sanitization of this code), after speaking with my current manager (Cristian), he allowed me to release the IDA plugin and the Test user application.

You can find the IDA plugin here:
https://github.com/intelpt/IntelPt_Compiled/tree/master/plugin

You can find even the latest beta compiled version of the Kernel driver and test application here:
https://github.com/intelpt/IntelPt_Compiled/

(It still requires the Test Signing Mode enabled)

Keep an eye opened on this repository. More things will arrive soon 🙂

For the recording and the slides of the talk, it depends on the BlueHat organizers. I have no plan to publish it for the global public. If you are interested send me an email to info@andrea-allievi.com or ask to the conference organizers (bluehat@microsoft.com) for all the information.
 

Question 4: Why don’t I publish the signed driver used in the demo?

I have bought a personal digital signature but I still don’t want to risk to publish a vulnerable driver that could be used for disable the OS protections or similar. If Rich, Zer0mem, Nicolas or some great hacker will try to exploit the code, I will be sure that it won’t contain any vulnerability. At that time I will publish the signed one.

 

Question 5: Ok, all this stuff is great, but what about real usage in multi-processor environment?

This is not an easy task. We are currently working on implementing this. But I would like to invite the interested reader to the next Recon Conference (if Hugo will accept us of course). In that talk I will explain how we have overcame this problem, how I have used the new features to analyse some Malware, and Rich will introduce the new features of his FuzzFlow. We’ll wait some smart security researcher! 🙂

In conclusion, this is definitively a damn interesting technology, with a lot of useful real case usage. Mixed with a Hypervisor (my implementation is still private, check the Satoshi or Alex Ionescu Hypervisor for example), we can definitively create even an off-line post execution engine used for tracing step-by-step whatever software we would like.

I wait some tips by the readers for the future improvements other than the Multi-Processor support. In the next European Recon conference (if we will be accepted of course), we would like to show the multi-processor execution and some real cases of its usage (fuzzing for example) with Intel PT.

I am even working on a quick video movie that shows how to use this.

 

11/26/2016 Update:
As some of you have allow me to notice this (thanks @long123king and @hacksysteam), at the time of this writing, no Type-1 (bare-metal) hypervisors are compatible with the Intel PT driver. This is because the CPUID (leaf 7 and 20) instruction is trapped by the Hypervisor and the PT bits are stripped down. Furthermore, based on our test, even the VM-Exit caused by the acquiring/modification of the PT-related Model Specific Register (MSR) are caught and invalidated.

To proper work with the Windows Intel PT Driver, you need to disable vSphere ESXi, HyperV (and even Device Guard, that deeply rely on it) or any Type-1 hypervisor (not VmWare Workstation, that is a Type-2 Hypervisor).

For HyperV you can use the procedure described here:

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2146361

Keep in mind that this will lower the overall security of your system if Device Guard will be disabled.

As usual, stay tuned!

Cheers,
Andrea

Hi All!
Recently I stumbled upon the new ZeroAccess dropper.
In the “KernelMode.info” community, on the 3rd January 2016, R136a1 has posted the new sample.
The dropper is quite innovative. I was working on some Crypto stuff, and still have no time to deepen analyse it, but I have realized that Kryptoslogic has been already written an introductive analysis (Great job buddies).

I have realized that this is the time to present here an old analysis paper I have written in the fall of October 2013. This document was not published due to some bureaucratic issues originated from my old company. Now I don’t still have this restrinctions and I can freely present here.
Is an old analysis about the new (for that time) ZeroAccess implementation:
Sirefef 2013 Analysis

The analysis is the integral one, and contains even the comments from the fall of the year 2013.
Hope that you enjoy it.

Andrea

ps. In the meantime I am even updating the “Resource” page of my blog… 🙂 Stay tuned!

Hi All!
Before starting, I would like to say that, as usual, all the thoughts and info inside this post are my opinions and don’t belong to my company.
Tomorrow will be the day of the public presentation of Windows 10. In this post I would like to say something about some very interested features of the new OS. I think indeed that this release brings a lot of new innovative features (from a Security view-point).

The MS goal was originally to make the new OS one of the most secure version ever released. Have they been able to accomplish this goal? I have made some preliminary tests.
Why a normal user should update?
The most interesting new features are in my opinion the following:

1. New Driver Signing Enforcement for UEFI systems with Secure Boot
2. A brand-new Kernel Patch Protection implementation (v10 :-))
3. Windows Hello (a technology that uses biometrics like your face, iris, or your fingerprint) to launch Windows 10
4. Control Flow Guard, and some other new security mitigations
5. Implementation of some cryptographic functions directly in Kernel Mode using hardware support
6. VSM, aka Virtual Secure Mode – The usage of tiny Virtual Machines to isolate some critical processes (this feature is known even as Device Guard)
7. Protected Processes – new light-levels that, used in conjunction with Device Guard, could resist even to Kernel Mode attacks

Two of these points need to be deepen.
First of all I should say something about the new Windows 10 Driver Signing Enforcement. According to the Microsoft post and the OSR articles (1 and 2) all new Windows 10 kernel mode drivers must be submitted to and digitally signed by the Windows Hardware Developer Center (with a Microsoft digital-signature).
This mean that a driver developer (like me) should do 3 things before distribute his kernel software:

1. Sign the driver package with his certificate
2. Upload the signed driver to MS Hardware Dev Center and agree on some contract details
3. Download the new cross signed files (by the owner and MS)

There is a big noise in the Kernel Dev community, even because MS accepts only the submissions that have a valid Extended Validation (“EV”) Code Signing Certificate (that costs a lot), and not the standard code signing certificate.

Even though the process is very cumbersome and intrusive (think about all the small companies and individual developers) it works: a DSE/Patchguard bypass method like the one that I have presented in the last NoSuchCon conference will not work anymore. MS in this way can control even the stolen certificates, and block the loading of drivers signed by bad guys.

The second feature that I would like to explain is the “Virtual Secure Mode” (aka VSM or Device Guard). VSM is a technology that uses Micro-Vm to isolate some critical (and protected) processes like the LSA Autority process (LSASS.EXE). In this way an attacker, even if he was able to break inside the system, couldn’t obtain the NTLM hash of the login password and can’t attack other network workstation or other applications.
This feature is really powerful (think about the power brought by the isolated protected processes). It is composed by at least 3 kernel modules:

1. securekernel.exe – The new Secure Kernel
2. skci.dll – Code integrity driver for the Secure Kernel
3. cng.sys – The new Next Generation Kernel Cryptography module

The new feature could be enabled ONLY in the Enterprise Edition (see this link) and is incompatible with many drivers (in my personal case the video adapter has started to work with the standard VGA driver when I enabled it).

In summary should you update to the new OS?
In my opinion definitively YES.
The Kernel guys of MS have made an awesome work to raise the bar of the Security of their OS.
The characteristic that I really don’t like is related to the sealing of the OS itself. The enhanced DSE, mixed with Patchguard and Secure Boot technologies make the OS very sealed (like MAC-OS) and limit a lot the power user freedom. But this is a drawback of the equation!

What do you think?

My 2 cents,
Andrea

Hi All!
After 6 months of inactivity I found the time to update my blog. Today I would like to speak about the last NoSuchCon Conference in Paris, where I have had the pleasure to be a speaker.
The presented project has been the following one:
“Understanding and defeating Windows 8.1 Kernel Patch Protections: it’s all about gong fu! (part 2)”

The talk analyses in details the Kernel Patch Protection implementation of the latest 64 bit version of Windows 8.1, and presents a technology developed entirely by me to disarm it.
Furthermore I have showed another innovative method to use the Patchguard own code to protect an eventual attacker rootkit. I have demonstrated its functionality by showing a working exploit as a proof of concept.

The entire publication is the results of the 3 months of work that I did reversing and analysing the Kernel Patch Protection code of Windows 8.1.
The introductive articles have been published in our old VRT blog:

1. Snake Campaign: A few words about the Uroburos Rootkit
2. Exceptional behavior: the Windows 8.1 X64 SEH Implementation
3. The Windows 8.1 Kernel Patch Protection

I am very happy because my talk has been quite a success. I have received some mails, contacts and requests for all kind of info related my disarm methods, and so on…
Furthermore, an italian specialistic newspaper has written a small article about my project:
Sicurezza di Windows 8.1 usata per proteggere un rootkit
(thanks to Valerio Porcu for the publication)

The NSC conference of this year was very good. I have attended a lot of interesting talks, like the following:

• Benjamin Delpy – Mimikatz Project
• My colleague Richard Johnson – Fuzzing and Patch Analysis: SAGEly Advice
• Peter Hlavaty – Attack on the Core
• Alex Ionescu – Breaking protected processes (very interesting talk)

Furthermore I’ve had the chance to meet a lot of skilled and clever researchers. I have even finally seen in person some of my colleagues: Richard, Ryan, Yves, Emmanuel (and my brother, who lives in Paris). We have had great times all together… Thanks guys!

Now I plan to reverse and analyse the Kernel Patch Protection code of Windows 10, and I hope to find a way even to disarm the last upgrade of this kind of protection. My target is to present the project to the next REcon conference in Montreal. I hope that I will be accepted! (and maybe even my girlfriend will follow me this time)

The talk’s recording has been uploaded to Youtube:
NSC #2 – Andrea Allievi – Understanding and defeating Windows 8.1 patch protections

Stay tuned!

Hi All!
I am proud to annunce that, starting form 10th March 2014, I have started a new Job.
I am a Security Engineer (this time without “Senior” adjective unfortunately) in the Malware Research Team of Sourcefire.
Sourcefire is a great company that deals with Network security solution, hardware and software, and it’s the creator of SNORT IDS and ClamAv antivirus.
It has been acquired in the last year by Cisco System Inc.

Welcome Sourcefire!

I hope that this new “adventure” will be fine. I am looking forward to release my first analysis for SourceFire team…

Andrea

In these days that I was currently quite free, I have took the occasion to deepen a feature of all X64 systems… Indeed last month, when I was analysing a sample of Expiro File infector, I encountered an instruction like this:

mov r11, gs:10h

Of course, according to the code context, and to my previous x86 experience, the previous opcode will move the content of current Teb (thread environment block) Stack limit field, in r11 register.
But how this is implemented in a X64 CPU?

According to Intel manuals (System Programming Guide, Chapter 3.2.4):
“In 64-bit mode, segmentation is generally (but not completely) disabled, creating a flat 64-bit linear-address space. The processor treats the segment base of CS, DS, ES, SS as zero, creating a linear address that is equal to the effective address. The FS and GS segments are exceptions. These segment registers (which hold the segment base) can be used as an additional base registers in linear address calculations. They facilitate addressing local data and certain operating system data structures.”

It seems that 64 bit segments and their descriptor tables are now useless. FS and GS segments are exceptions. I have dumped a GDT from a live 64 bit system, then developed a specific driver to perform some analysis. Here are the results:

According to the previous picture, it seems that all x64 segments are used only for memory protection (Ring 0-3 protections). But, one important question arise: how is possible that GS segment base address is 0? It is indeed very improbable that TEB could be located at address 0x00000000.

The following snapshot demonstrate that all segments are exploited in X64 architecture only for memory protection, meanwhile standard x86 segments are used for full segmentation as in the previous x86 architecture:

So far so good… Now it’s time to understand why FS and GS segments work in the way as they do for 64 bit long mode. The answer to the question resides in Windows X64 Syscall handler. Intel manual states that SYSCALL new instruction transfers execution control to the address found in IA32_LSTAR model specific register (and changes CPU current privilege level). IA32_LSTAR register points to “KiSystemCall64” Nt kernel routine. Whenever a native API is called from user mode, Ntdll code exploits SYSCALL instruction to perform Kernel transition. The transition is managed by “KiSystemCall64” procedure.

This routine first invokes “swapgs” instruction. According to Intel manuals: “SWAPGS exchanges the current GS base register value with the value contained in MSR address C0000102H (IA32_KERNEL_GS_BASE). The SWAPGS instruction is a privileged instruction intended for use by system software”. Based on our test, the latter information is not 100% accurate. The value of GS base register actually equals to the value contained in IA32_GS_BASE model specific register. In x64 Windows systems, these MSR contains:

• IA32_KERNEL_GS_BASE – Pointer to current processor control region (PCR)
• IA32_GS_BASE – Pointer to current execution thread TEB
• IA32_FS_BASE – Currently unused in Windows x64. Its value equals to the base address of 32 bit FS segment descriptor (located in GDT). In 64 bit executables an instruction like “MOV RAX, FS:[10h]” causes an access violation

The test driver I have developed confirms all the previous conclusions. As a matter of fact, Windows operating system, when working in 64 long mode, has GS segment that always points to current thread TEB (in user mode), whereas in kernel mode points to current processor PCR.

Adding a segment descriptor, and doing some other tests, confirms again that X64 GDT is used in long mode only for memory protections. In 32 bit compatibility mode, all segments are used as normal for memory segmentation.

Returning to Windows System call handler, its job is quite easy: as the reader can see, the user-mode stack pointer is saved in PCR data structure, Kernel stack pointer is then retrieved, all GP registers (and MMX flag register) are pushed on the stack and user-mode debug environment is saved (if needed). Execution control is transferred to “KiSystemServiceStart”. The latter routine is the key of System service dispatch feature: first, it calculates the right system table pointer (if the native API number is above 0x1000, then the required function is a Win32 gdi graphics one, otherwise a standard Nt kernel API). It retrieves the right native API pointer from table, copies all remaining stack parameters (KiSystemServiceCopyStart) and finally calls kernel API. Noteworthy is that Windows 8 & 8.1 Syscall dispatch is totally changed from older Microsoft operating systems. Deep describe these new features is behind the scope of this brief paper…

A printable “pdf” version of this article is available here.

Hi all!

I am still alive 🙂 . I am proud to release here my last analysis about a multi-architecture file infector. It’s name is Expiro. This analysis is the first I made as an independent security researcher and it’s not related to any company. I hope that it can be useful for all others security researchers like me.

Here is the complete document:
www.andrea-allievi.com/files/Expiro_Analysis_2013.pdf

I have deep inspected Expiro dropper because I was very curious to deep understand what a new polymorphic file infector can do. By the way I have found a lot of weak point in its infection code…
Enjoy the analysis, and please let me know what do you think about it, feel free even to send me any comments and suggestions…