Mimi's Blog

Did a little bit of work

PatchGuard is a defense mechanism in the Windows kernel, which is used to check whether key data structures and codes in the kernel have been tampered with by malware or drivers. If an exception is found, PatchGuard will directly use the error code CRITICAL_STRUCTURE_CORRUPTION perhaps KERNEL_SECURITY_CHECK_FAILURE Trigger the blue screen. When doing security research on the Windows kernel, if you need to hook key functions in the kernel, you must first close PatchGuard, or the test process will be affected.

At present, the most mature way to close PatchGuard is to use EfiGuard . EfiGuard is an EFI firmware that can hijack the Windows Boot Manager in advance when the system starts, thereby enabling dynamic patching of the Windows kernel and preventing the execution of the relevant code initialized by PatchGuard. There are many ways to use EfiGuard, which are described in detail below.

Download EfiGuard

The binary EFI file of EfiGuard can be downloaded directly from the Release page of GitHub. After decompression, you will get Loader.efi and EfiGuardDxe.efi Two files. They are the EFI firmware we need. Next Loader.efi Rename to bootx64.efi , we also directly use bootx64.efi File.

Prepare the environment

Next, you need to ensure that the BIOS of the current machine is set to start through UEFI, and that the Windows Boot Manager startup item is recognized. Generally, newly installed Windows systems meet this requirement. However, the author also found in the experiment that the boot item of some pre installed Windows systems in laptops does not include the Windows Boot Manager, but only a disk such as NVMe0. Although the Windows system can be started, loading EfiGuard directly at this time may cause startup failure.

 Windows Boot Manager does not exist

At this time, you need to repair the startup item manually. The simpler solution is to use Dism++and other tools to repair the boot. Open Dism++, click "Boot Repair" in "Restore Function", and then add the Windows Boot Manager startup item again. After completion, you can restart to determine whether the BIOS recognizes the Windows Boot Manager.

Deploy EfiGuard

Start through ordinary USB flash disk

The easiest way is to refer to the EfiGuard document and create it on the USB stick /EFI/Boot/ Directory, and then bootx64.efi and EfiGuardDxe.efi Two files are copied to this directory. After that, insert the USB stick into the computer to be tested, and then select the USB stick to start. If everything is normal, EfiGuard will automatically load at startup and output a large number of logs (characterized by green text).

Launch via Ventoy

Ventoy can also be used to load EfiGuard. take bootx64.efi and EfiGuardDxe.efi The two files are copied to the root directory of the U disk where Ventoy is installed. Then, restart the computer and select Start via Ventoy. After entering the Ventoy page, first click EfiGuardDxe.efi , it will automatically load the driver and return to the Ventoy menu. After that, click again bootx64.efi EfiGuard will start to work, complete the system startup and close PatchGuard.

background

Enigma is an encryption device used by the German army in World War II. It has three rotatable rotors, a fixed reflector, patch panel, keyboard, light panel and other components. The patch panel can exchange two letters, and the rotor can map one letter to another. This is achieved through circuits. After the user clicks the key on the keyboard to input the plaintext letters, the current generated by the battery in the machine will pass through the patch panel, three rotors and reflector, then turn back, and through the three rotors and patch panel again, the bulb corresponding to the ciphertext letters on the light panel will be lit. Each time the key is pressed, the rotor rotates and carries when it reaches a specific position. Therefore, every time the encryption is performed, the connected circuit will change, making the encryption process of the Enigma machine difficult to crack. For Enigma's implementation and software simulator, refer to the previous article Build an Enigma cipher machine by yourself

In the late World War II, the Enigma machine used by the German army allowed the operator to select 3 rotors from multiple rotors. Each rotor had 26 initial positions, and 10 groups of letters could be exchanged on the patch panel. This creates a huge key space, which seems to make the Enigma machine indestructible. However, Polish mathematician Rejewski discovered the weakness of Enigma's operation process in the 1930s and designed a cracking method for it. After the outbreak of World War II, relevant technologies were shared with the allied intelligence agencies, but the German army also strengthened the security of Enigma password. British mathematician and computer scientist Turing further designed the known plaintext attack method, successfully cracked the Enigma machine, and made an important contribution to the victory of the world anti fascist war. The author reproduced the methods used by Rejewski and Turing to crack Enigma machine, and will introduce them in detail in this article.

Algorithm principle

Rejewski's cracking method

In the 1930s, the operation process of Enigma machine was: everyone would use the same daily key every day, but the daily key was not used to encrypt information; When sending a message, the operator needs to randomly generate a three letter message key first. The operator will first use the daily key, input the information key twice, and the six letter ciphertext generated will be the beginning. Then, the operator adjusts the rotor of the machine to the rotor position corresponding to the information key and starts to encrypt the information. The reason for entering the information key twice is to avoid errors due to interference in the information transmission. If the receiver finds that the first six letters of plaintext decoded by the daily key are not in the same format twice, it can find the problem. However, repetition is the enemy of encryption, which Rejewski keenly observed. The first letter and the fourth letter are encrypted in the same plaintext. When the first letter is entered, the settings of the rotor are the same day key. Therefore, all ciphertext encrypted by Enigma machine received on a certain day will meet the following rules:

  • If the first letter is A, the fourth letter is E;
  • If the first letter is B, the fourth letter is L;
  • If the first letter is C, the fourth letter is C;
A B C D E F G H I J K L M N
E L C O N W D I A P K S Z H

Table: Corresponding table of the first letter and the fourth letter of ciphertext (part)

List the results as shown in the above table. Rejewski found that there are some "chains" in the letters in the table. For example, the letter A in the previous row corresponds to the letter E in the next row, the letter E in the previous row corresponds to the letter N in the next row, and so on, and finally returns to the letter A. Thus, the letter chain AENHI is generated. At the same time, you can also find other letter chains: BLSJP, C, DOFWVG, K, MZURTY, Q, X. If the initial state of the machine is the same, then the letter chain obtained is naturally the same. More importantly, Rejewski found that the existence of patch panels only changes the letters in the letter chain, but does not affect the length of each letter chain.
For example, in the above scenario, add an additional wire between A and C, then the original AENHI chain will become CENHI, and the C chain will become A chain; But the length of the two chains is constant. Therefore, the length feature of the letter chain is an invariant under the action of the patch panel, which is only related to the initial position of the rotor, so the action of the patch panel can be decoupled from the initial position of the rotor. The Polish decoding team spent one year in pre calculation and obtained the corresponding relationship between the initial position of all rotors and the length of the letter chain. After receiving the new ciphertext, the decider can look up the table and compare the length of the letter chain with the pre calculated result to obtain the possible initial position of the rotor. After successfully recovering the initial position of the rotor, the decider can decrypt the ciphertext, and then further analyze the status of the patch board. The specific algorithm principle is as follows.

 one
two
three
four
five
six
seven
eight
nine
ten
eleven
twelve
thirteen
fourteen
fifteen
sixteen
seventeen
eighteen
nineteen
twenty
twenty-one
twenty-two
twenty-three
twenty-four
twenty-five
twenty-six
twenty-seven
twenty-eight
twenty-nine
thirty
thirty-one
thirty-two
thirty-three
thirty-four
thirty-five
 Input: Table T corresponding to the first 6 ciphertext letters
Exporting: solution solutions

Pre calculation stage:
----------------------------------------
#Enigma machine simulated by Polish Bomba machine
E ← Enigma()

#Stored database for later table lookup
Database ← Map()

for each S in PossibleSettings:
E.setPosition(S)
C ← FindChainsByEnigma(E)
Database.store(S, C)

Cracking process:
----------------------------------------
Solutions ← Set()

for each S in PossibleSettings:
Matched ← true

for i ← 1 to 3:
Chain ← FindChainsInTableRow(T[i], T[i+3])
Expected ← Database.get(S + i)

if Chain ≠ Expected:
#The letter chain failed to pass the inspection
Matched ← false

if Matched = true:
#The letter chain corresponding to the current initial state has passed the inspection
#Add possible solutions to the solution set
Solutions.add(S)
Read the full text »

SDRPlay RSP1 is a cost-effective SDR receiver that supports a frequency range from 1kHz to 2GHz, and is suitable for radio reception, spectrum analysis, signal detection and other application scenarios. The author recently purchased one for research. Although it is a domestic improved version, the main chip model is the same as the original RSP1, so the same driver and software can be used. However, many easy-to-use PC software only support Windows system, and it still needs a lot of effort to configure a suitable environment on Mac. This article will introduce the specific methods of using SDRPlay RSP1 on Mac.

Using SDRuno

SDRPlay officially provides a wealth of software support, among which SDRuno has the most complete functions. Unfortunately, it is only Windows version, and because of the driver problem, it needs to use a virtual machine to run on the Mac. If you want to use SDRuno, you need to install the Windows system through software such as VMWare Fusion or Parallel Desktop, and then install SDRuno in the Windows system. After that, connect the SDRPlay RSP1 device to the Mac and transparently transmit it to the virtual machine via USB to identify the device.

Using SDR++

SDR++is an open source SDR software that supports a variety of devices, including SDRPlay RSP1. Its interface is simple and powerful. It supports a variety of operating systems, including Windows, Linux and macOS. It is very convenient to use SDR++on macOS From GitHub repository Download the corresponding installation package and use it after installation. SDR++supports multiple devices, which can be selected from the Source drop-down menu in the sidebar. However, on macOS, SDR++installed by default cannot recognize SDRPlay RSP1. It can be found from the document that the support for SDRPlay RSP1 requires installation sdrplay_source Plug in. This plug-in is included in the Release version, but it depends on the SDRplay API and needs to be installed manually.

SDRPlay API is an official set of APIs provided by SDRPlay to support the use of SDRPlay devices in third-party software. It can be accessed from Download from SDRPlay official website . After downloading, complete the installation, and relevant resources will be stored in /usr/local/sdrplay/ and /usr/local/lib/ Directory. However, when SDR++was started again, it was found that SDRPlay RSP1 was still not recognized. This is because SDR++has written the address of the dynamic library file to be loaded, which needs to be manually copied:

 one
 cp /usr/local/lib/libsdrplay_api.so.3 /Applications/SDR++.app/Contents/Frameworks/

After that, start SDR++again to see the SDRPlay RSP1 device in the Source drop-down menu.

 Using SDRPlay RSP1 in SDR++

Note that if other applications occupy the device, the No device available prompt will appear in the sidebar. At this time, you need to close the application that occupies the device, then plug and unplug the device again, restart SDR++, and then select the device again.

Other software

In addition to the highlighted SDRuno and SDR++, some other software also supports the use of SDRPlay RSP1 on Mac, such as SDRconnect CubicSDR Etc. SDRconnect is also officially provided by SDRPlay. Compared with SDRuno, it supports more systems and can be easily used on the macOS. However, its functions are relatively weak, lacking some advanced functions, and there are some bugs in the interface. The latest version 1.0.4 at the time of writing of this article will have the problem of dislocation when dragging the molecular box of the part. The use experience is general. CubicSDR is an open source software that supports multiple SDR devices, but the code has not been updated for a long time. In general, SDR++is the best choice for using SDRPlay RSP1 on macOS. If you don't mind using virtual machines, SDRuno is also a good choice.

Proxmark3 is an RFID tool that supports a variety of protocols and frequency bands and is commonly used in research, cracking, copying, security testing and other scenarios of IC and ID cards. The hardware of Proxmark3 includes the main control board and antenna. The main control board has an ARM architecture processor and an FPGA for modulation and demodulation. The software includes the firmware running on the ARM processor and the client software running on the computer. Both versions need to be matched to work. There are many businesses selling Proxmark3 on Taobao, and the software will be included. However, the author notes that the original Proxmark3 software is open source based on the GPL protocol, but the software provided by the seller is usually only in binary form and does not contain source code, which is suspected of violating the open source protocol. In order to support the cause of open source, the author directly purchased Proxmark3 hardware from idle fish at a lower price and tried to write firmware by himself.

Proxmark3 software, which is more active in the community, is maintained by the RfidResearchGroup team. Its warehouse address is https://github.com/RfidResearchGroup/proxmark3 Since Chris "Iceman" Herrmann is the main developer, this version is usually called the Iceman version.

Iceman software supports many different Proxmark3 hardware, including RDV4, Easy, etc. Before compiling and using Proxmark3, you need to confirm the hardware version of Proxmark3. If the hardware and software versions do not match, the firmware may be burned or an error may be reported during use. In this case, recompile the software and burn the correct firmware. For the appearance of Proxmark3 of different versions, refer to the following figure, which is taken from Proxmark3 website . Proxmark3 Easy is a common version in the market. The RDV4 version is more powerful, but the price is also higher, usually more than 1000 yuan.

Different

Compile the Iceman version of Proxmark3 software

Iceman software can be compiled and run on Linux, Windows, macOS and other systems. This article takes Linux as an example.

First, clone the warehouse locally:

 one
 git clone https://github.com/RfidResearchGroup/proxmark3

Then enter the directory and execute the compilation command:

 one
two
three
 cd proxmark3
make clean
make all PLATFORM=PM3GENERIC

make all The default configuration is to compile software that is compatible with the RDV4 hardware version. However, Proxmark3, a common product on the market, is not this hardware version. Therefore, it is necessary to specify PLATFORM Parameter, set the compilation target to PM3GENERIC , that is, Generic Proxmark3 platforms.

After compilation, the firmware to be burned will be generated in recovery Directory. client The directory will appear proxmark3 Executable, which is client software, is a command line tool. Under the warehouse root directory pm3 The script will execute proxmark3 The subsequent operations of this article are also based on this tool. If you want to use the graphical interface, you need to download additional GUI programs separately.

Read the full text »

In the "Photo" App on macOS, photos can be easily managed through the smart album function. When creating an intelligent album, you can set a series of rules to filter photos according to camera model, shooting date and other conditions, and then add these photos to the album. When new photos are added to the album, eligible photos will also be automatically added to the smart album.

Smart

However, the conditions supported by the current intelligent album still have some limitations. For example, the author wants to filter out photos from the iPhone 6S. Even if the camera model rule is set, a large number of phone screenshots are not included. The reason for the problem is that the EXIF of the phone screenshot does not contain the camera model information. If you need to filter these screenshots, it is better to use the resolution as the judgment basis. Unfortunately, the intelligent album does not support filtering the resolution at present. There are many similar requirements. Is there any way to deal with them through automation? The answer is yes. It can be achieved by using AppleScript programming.

AppleScript is a script language that comes with the macOS system, and can be used to control the system's built-in applications to achieve automatic operation. For the Photos app, AppleScript can be used to obtain photo information, create photo albums, add photos, and so on. The following is a simple example for filtering screenshots of iPhone 6S and adding them to an album called iPhone 6S Screenshot.

To run this script, open the Script Editor app, paste the script into the editor, and then click Run.

 one
two
three
four
five
six
seven
eight
nine
ten
eleven
twelve
thirteen
fourteen
fifteen
sixteen
seventeen
eighteen
nineteen
twenty
twenty-one
twenty-two
twenty-three
twenty-four
twenty-five
twenty-six
twenty-seven
twenty-eight
twenty-nine
thirty
thirty-one
thirty-two
thirty-three
thirty-four
thirty-five
thirty-six
thirty-seven
thirty-eight
 tell  application  "Photos"
log "Start..."

--Create a new album. If the album already exists, use the existing album
if not (exists album "iPhone 6S Screenshot" ) then
make new album named "iPhone 6S Screenshot"
end if
set targetAlbum to album "iPhone 6S Screenshot"

--Define target resolution
set targetWidth to seven hundred and fifty
set targetHeight to one thousand three hundred and thirty-four

--Initialize picture list
set imageList to {}

--Get all photos
set allPhotos to every media item

--Cycle to check the resolution of each photo
repeat with aPhoto in allPhotos
if width of aPhoto is targetWidth and height of aPhoto is targetHeight then
--Print photo information, such as file name
log "Matching photo: " & filename of aPhoto & ", Date: " & date of aPhoto
--Add photos that match the resolution to the list
set end of imageList to aPhoto
end if
end repeat

--If the list is not empty, add photos to the album
if ( count of imageList) > zero then
--Print the number of eligible photos
log "Number of matching photos: " & ( count of imageList)
add imageList to targetAlbum
else
log "No matching photos found."
end if
end tell

If all goes well, the matching photo information will be displayed in the output window of the script editor. After running, the Photo app will also pop up a prompt to let the user confirm the operation.

This example is just a simple example, which can be expanded according to the needs in practical applications, such as adding more filter conditions, automated photo processing, etc. The existing large model can also help write the code of AppleScript. However, when operating other apps through AppleScript automation, incorrect code logic may cause data loss, so you need to carefully check the code and make a backup.

0%